平台开发技术考虑

1.客户端设计

使用基于Applet的访问框架,客户端需要下载一个30M左右的jre,界面元素由Swing实现,可以参照NC的实现.

优点: A学习曲线平滑,不需要大规模的进行技术培训,目前人员大多都有过Swing的开发经历. B 界面表现性较传统Web页面优势较大,可以实现非常复杂的界面展现. C 显示的效率比较高,虽然web开发也已经实现了MVC的设计模式,但基于请求响应的开发方式有时无法满足大数据量下的应用. D 可以借鉴NC的实现方式,而且有很多代码可以使用.

缺点: A 客户端需要下载jre. B 第一次启动会比较慢,但以后会快很多.

2.客户端与应用服务器的数据传输

目前可以考虑的方案:

A 使用EJB的RMI-IIOP协议进行数据传输,为SUN的专属协议,无法穿透部署有防火墙的网络环境,需要使用EJB3的所有技术,平台依赖性较大.

B 使用开源领域的传输协议,此类协议都是通过http协议进行数据传输,比如: hessian,burlap以及Spring集成的HttpInvoker..由于使用了http协议,可以穿透防火墙进行数据传输.同时对于java-to-java的数据传输效率很高,基本上可以媲美EJB使用的RMI协议.在JavaEye上面也有了对Hessian等传输协议的讨论http://www.iteye.com/topic/129194.

以上两种方案可以看出,使用开源领域的技术可以得到比RMI要好的效果,同时由于是开源的,如果需要还可以进行修改或加入加密逻辑,建议优先使用.

3.应用服务器的选择

可供选择的方案:JBoss,GlassFish等,Tomcat不建议使用.GlassFish是SUN官方的开源JavaEE参考实现,对于JavaEE的各种技术支持的较好,比如JPA、JMS、JCA、统一事务管理等服务.而JBoss属于老牌的开源应用服务器,能够非常好的和各种其他开源项目进行集成,比如:Spring2.0,Hibernate等,而且旗下也有很多易用的扩展,比如扩展JSF界面体验的ajax2jsf可以增加jsf对ajax的支持,spring-deploy可以在jndi级别对spring2.0进行集成,同时JBoss还对Java MBean进行了一流的支持,应为JBoss的开发就是基于MBean的.所以如果远程技术是基于Spring的优先考虑JBoss,而如果是基于EJB3.0,则可以优先考虑GlassFish,毕竟是Sun的官方实现.

4.加密

因为是做自己的开发平台,加密的环节是必不可少的,目前JVM已经进行了开源,加密的逻辑在软件中的位置也有了更多的选择,比如在类加载器中、在JVM中等方式,如果在类加载器中进行加密,可以简单的使用一些常见的反编译软件(小颖)就可以进行破解,当然如果采用了代码混淆,反编译的难度可能对大很多.如果在JVM级别进行加密,不仅可以实现自己的字节码形式还可以通过修改java.exe文件,进行最底层的加密控制(C语言实现).

5.EJB or Spring

两种技术是目前比较流行的,使用比例当然是Spring高于EJB3.0,毕竟EJB3.0刚发布没有多久,但较以前的版本已经有了很大的改变,特别是吸取了很多开源的思想,比如将Hibernate、TopLink进行标准化,出现了JPA标准,控制反转IOC的应用等,但真正实施的项目还很少…而Spring在web开发领域已经占了很大的份额,优势是易于使用,同时可以集成EJB的所有服务事务、JCA、JMS等,特别是BeanFactory可以节省很多的开发工作,而且实现了代码的组装,无需硬编码.当然EJB3也通过Java注释技术实现了类似的功能,可以使用Java的强类型特性,出错率较低,但随着Spring开发工具的完善,已经可以实现xml文件中的代码提示..

我认为最佳的应用模式应该是基于Spring的POJO模型,使用EJB3.0的无状态会话Bean进行方法调用,这样的模型可以最大限度的集成JavaEE的企业服务,也可以使用Spring集成的开源企业服务实现.如需要可以提供实现结构图.

6.业务模型

看了金蝶EAS的BOS实现,可以借鉴它的想法:将系统的基础档案进行抽象,形成若干个可以拿来就用的业务组件,和NC基于表的建模形式不同,BOS可以对一个单据进行完全的自定义,包括字段、位置等,类似于报表工具的设计模块,想iReport的设计界面,就是可以进行拖放操作,最后形成一个完全自定义的单据.我认为实现方法是:将NC单据模板中的表定义前移,移到最终用户,最终用户在通过拖拽进行界面定义保存后,动态根据定义单据上的字段形成一个实体模型,最终持久化到表中(通过一个表存放动态定义表的字段).这样就比NC先进了一步,NC的单据模板是给一定层次的实施顾问使用的,因为需要首先要进行表的定义,数据格式的选取、VO的对照、数据字典的生成等等比较专业的操作,而基于业务组件设计把工作更近了一步,把表的定义进行了抽象,变为最终用户可以操作的图形界面,然后由后台逻辑进行生成,真正实现了软件客户化,而不是NC的软件二次开发化….实现的难点:业务组件的抽象(必须尽可能提供丰富的内置业务组件),设计界面的实现(拖拽,属性编辑<可以有开源组件使用>),持久化策略(如何效率较高的实现?)等.可能使用的技术:JavaBean(抽象组件)、属性编辑器(设置组件)、反射(返回组件属性)、动态代理或AOP(事务、日志等基础工作).

7.其他

7.1远程协议的自主实现:要求较高,关键不是如何实现,而是如何高效的实现…

7.2缓存:代码缓存、数据缓存、页面缓存(如果是Web页面)

7.3流程:可以研究OSWORKFLOW的引擎实现.界面实现通过jgraph绘制

7.4报表:是自己实现还是就使用iReport嵌入到平台中

7.5数据交换:这部分应该是平台的一大模块.

随便说几句：
1.平台的重要特征就是其灵活性，完全用Java这样刻严谨的静态语言要实现平台级的灵活性，需要架构人员超强的抽象能力，建议加入对动态脚本语言的支持，推荐Groovy，这样可以大大增加实现动态灵活性的难度；
2.平台在核心架构上，可分为元数据驱动的解释型和代码生成驱动的编译型。前者对动态性支持较强，但要实现源代码级的扩展能力比较困难。后者正好相反。根据第6点的叙述，似乎是两种方式的结合，当然这很好，很先进，但是，必须保证灵活性是双向的，要保证元数据和生成的代码在经过各自变化之后仍能完美协作；
3.我认为平台有三个内容：二次开发平台、集成平台、业务平台，你说的那些主要是针对二次开发平台，但要成为有竞争力的平台，还得有一个良好的集成架构，数据交换的思想有点落后了，不够了，你得实现SOA。有了技术平台还是不够的，起码还得有标准业务构件，才称的上平台，如果能分行业，那就更好了；
4.造平台是个大工程，需要很多人，很多钱，还需要时间的打磨才能逐渐完善，投资回报周期是比较长的。

SOA的实现方式当然好,但只提供一个服务供第三方系统调用还是不够,需要有个功能去获得数据,我说的数据交换也是基于这个考虑.希望可以通过设置基础信息比如地址、服务名等,就可以取得第三方系统的数据...

真巧我也想到这一点，而且，现在还用Axis2制作了一个工具：

异构系统资源共享Universal Information Integration（UII），是类似于IBM信息整合解决方案中的WebSphere Information Integrator（WII）一样的中间件产品，它们都以实现跨数据源的实时查询、存储、缓存；数据的转换、复制、搜索和发布为目的，建起系统间沟通的桥梁，而这个“桥梁”不像直连直通的斜拉桥，更像是连接四面八方的立交桥。

特性：
一，使用UII不需要部署DB2数据库，它使用业界标准来展现数据，自由接入，自由使用。
二，使用方式不同，WII需要提交用SQL编写的查询，用DB2来统一语法，而UII采用将数据库表、字段定义映射成Web Services标记的方式，在操作数据库时，只需要使用统一的Web Services服务，UII自动生成相关的查询并返回用XML封装的结果，不需要编写任何SQL语句。
三，返回结果不同，WII返回符合DB2语法的数据库查询结果集，UII用Web Services返回符合特定行业标准的XML内容。

那你是定义了自己的一套语法来表示数据库的基础信息,然后在UII中进行处理?那应该还需要实现一个sql翻译器啊,才能实现跨数据库操作?

看来jvincent对此也有比较深入的考虑，UII是这样处理的：

一，使用JDBC连接数据库，并查询数据库的结构，包括库、表、字段，将这些信息记录到XML文件中（具体格式略）；
二，在不同的表之间（包括不同的库的表之间）设置关联，将关联关系的定义记录在XML文件中（具体格式略）；
三，建立服务，将分散在不同数据库、表里的字段用表达式转换，然后与服务标记对应，将映射关系的定义记录在XML文件中（具体格式略）；
四，根据以上内容，当客户端发起服务时，就可以根据以上内容生成SQL语句。

是的，当然存在“sql翻译器”，它是UII的核心部分，对外提供时在这个部分使用了混淆器。

目前企业的游离系统很多,一个好的数据交换模块可以决定软件在企业应用的深入程度,所以这个部分还是蛮重要的,考虑的也就多点...

还有一个重要的就是客户端的选择,既要有良好的客户体验,还要便于开发调试..个人比较看好基于Applet的富客户端...

是的，企业应用整合的需求会越来越多。

对于用Applet作为富客户端的做法，觉得这个想法太大胆，除了jre的要求会让使用者却步以外，还需要得到开发人员的支持。

还是采用Web开发框架为基础，在关键功能上使用Applet（比如，流程设计、组织管理等），同时提供网页形式的兼容实现方案，个人意见比较保守。

applet在企业中应用的想法不算大胆，使用上问题不大，我补充一下applet的优缺点。
优点：
1.应用可以很容易发布为三种形式，Application,webstart,applet， 满足不同需求；
2.使用java语言，与服务器端技术一致性好，人员及系统都没有沟通障碍。
缺点：
1.静态编译语言描述界面，在开发效率上有点影响，调试比较慢，改一个东西要过很久才能出的来；
2.还是语言的问题，动态性不足，对于平台非常需要的灵活性上有缺陷；
3.界面反应有些慢，也许在高版本JDK下有改善。

楼主可以评估一下flex。