XXX产品平台技术构架(我的早期IT运动...)

XXX产品平台技术构架
（基于Web的应用研发）
一、综述
本产品旨在解决电子政务的需求而研发的跨平台、整合的电子政务系统。本系统是基于多层构架并实现为B/S结构的表现形式。在该技术架构中，拟用J2EE相关技术来构架并实现电子政务的分布计算与应用的需求。在这个实现中，我们抽象出不同的政务模型和业务的源生数据，并形成基础的数据（库）源，然后根据不同的业务类型，按照实际的情况，定制不同的业务流程，从而根据自我定制的业务流程和源生数据来驱动整个政务系统的稳健运行。整个的结构可以看作是由这样的几块构成：表单/视图（表现层）、业务逻辑（政务引擎驱动层）、数据模型（数据或模型管理层）。
二、J2EE平台技术简介
J2EE是个标准的体系结构，它面向使用java程序设计语言进行的基于Web应用的企业应用的开发与部署，同时也是一种平台无关的分布应用或计算的企业应用解决方案。下面对这种体系结构从两方面进行说明：
1、 J2EE基本框架



注：上面的各种模型将在后面平台技术应用中进行综合和取舍讨论

2、J2EE主要技术构成
1、JSP-------------------------------------表示逻辑
2、Servlet---------------------------------表示逻辑或控制
3、JDBC-----------------------------------数据库连结和访问
4、JTA-------------------------------------java事务管理（API）
5、JNDI-----------------------------------对象名字的中央注册（java名字和目录接口）
6、RMI------------------------------------RMI远程对象的分布执行（远程方法调用）
7、EJB------------------------------------实现业务逻辑（企业JavaBeans）
8、JMS-----------------------------------协调分布执行（java消息服务）
9、JavaMail-----------------------------邮件服务-用于联接E-Mail系统
……
Servlet：服务端的java代码，相当于客户端的Applet，用于响应客户机的请求。默认情况下，Servlet采用一种无状态的请求-响应处理方式。典型情况下，请求是由Web浏览器生成的，所有请求均采用Http协议。Servlet通常是通过Web服务器根据统一资源定位器（URL）来确定的。典型情况下，Servlet代码需要读取请求对象中的详细请求信息，并根据请求信息中的要求，，生成响应信息，然后放到响应对象中，Web服务器吧响应对象转换成Http响应信息，最终会送到客户机。
Jsp：识开发人员能够快速的建立动态的个人化的Web内容。客户机发出Http请求，Web服务器按一定规则执行适当的JSP页面，然后把响应信息发送给请求者。在Web服务器第一次挑选某个Jsp页面为客户机请求提供服务前，首先把Jsp页面转换成Servlet，生成的Servlet开始执行，并可为当前或后续的其它请求提供服务。所以基本上讲，Jsp仅仅是个更有效地的建立Servlet的方法。
JDBC：Java Database Connetivity，是J2EE访问应用数据库资源的标准。是和ODBC相似的一种通用的、标准的访问接口。它有四种类型：第一种JDBC驱动程序为JDBC-ODBC桥；第二种JDBC驱动程序直接吧JDBC API映射到数据库厂商提供的专属的客户机API。第三种JDBC驱动程序支持三层的JDBC的访问方式。第四种JDBC驱动程序是纯Java的，直接和数据库实例进行交互。
JTA：Java Transaction API，允许Web开发人员访问数据库系统，或任何数据存储系统中的事务功能。事务处理可以协调单个数据库操作或多个数据库操作，以确保所有的数据源保持数据的准确和一致。JTA定义的高级的事务管理规范，用于分布式应用的资源管理。
JNDI：（Java Naming and Directory Interface）是Java标准的中央注册机制，提供名字和目录服务。JNDI用于管理创建分布式应用式所需的核心组件对象。当开发人员需要建立一个访问远程对象的应用时，JNDI可以为应用提供一种找到所需远程对象的方法。
RMI：（Remote Method Invocation）,是Java应用访问远程Java对象的标准，Java应用使用RMI访问远程对象。RMI提供一种分布的应用框架，是远程客户机可以和远程方法和服务进行交互。远程主机可以使用RMI对外宣布远程对象上的方法，对象可以位于网络的任何节点上。
EJB：企业JavaBean，是企业级的Java标准，用于建立服务器端的业务逻辑。EJB通常存在于EJB容器中，这种容器提供的服务包括事务支持、安全和并发处理等功能。EJB有：实体EJB、消息驱动的EJB、有状态会话EJB和无状态会话EJB
JMS：Java Message Service,为开发人员提供的用于企业级的消息处理机制的标准Java API，是Java应用和组件能够发送和接受消息（排队机制、电对点通信、发布和订阅等）
JavaMail：支持简单的电子邮件和消息处理服务，允许联接到任何标准的电子邮件系统中。

上面就是J2EE体系中的主要的技术标准和应用原理，下面，将根据上述的模型和应用原理，并结合公司的（发展）研发目标而不是任务，来构架产品的平台技术需求和实现。

三、平台技术架构
1、 J2EE体系的模型综合
对于其编程模型来说，可以说是指导实现分布应用的人员，应该依照这个模型来逐步的实现分布功能，并要对其进行一定的功能外保工作，以便能协调整体整体的分布计算和应用。从上面的J2EE体系的应用模型来看，在这个体系模型中，非常的重视业务逻辑（规则）的设计，也既是把实际应用中的业务逻辑抽象出单独的业务逻辑或业务规则层。这样，在应用相关的分布计算技术，诸如EJB+Web Server等，就很容易的构架出分布应用系统结构。另外，由于把业务规则单独的作为一逻辑应用层，也是非常的符合公司产品研发方向，并且和容易的作进一步的扩展。这也是IT应用的潮流和热点。所以，可以从J2EE体系模型中我们选择一种来作为我们研发实现的目标或方向。当然，在实际的设计中，还是要应用到其它的模型技术的，比如对Applet的应用。

2、 业务逻辑的抽象
根据对政务应用的实际情况，我们抽象出不同的政务模型和相关政务的源生数据，并形成一种“原子库”，然后再根据“原子库”来抽象和派生应用的业务逻辑，形成一种自己的政务引擎（至少应该包括业务处理和信息交互两部分的功能实现），也就是说我们把政务上的业务应用，抽象为政务引擎 ，通过政务引擎 来完成政务处理和相关应用的整合。具体可以业务规则包装为EJB，而信息的交互可以通过Web服务或JMS来实现，而对于“原子库”的形成，我们通过提供独立的工具来完成，这样也更容易对源生数据进行扩展。当然，政务引擎设计也是可扩展，要具有良好的伸缩型。如果一种应用产品的伸缩性差，绝对不是很好的产品。

3、 产品平台实现的技术方案
通过以上的讨论，我们可以选择J2EE平台下的一种实现方案，并采用MVC的这种应用结构来实现产品的研发。下面，我们就给出这一设想下的技术架构模型：

防火墙

（Dist Government Affair Engine）
对于上面的技术方案的实现细节，不做祥述，在这里，简单介绍一下MVC 模式。MVC包括三类对象。Model是应用对象，View是它在屏幕上的表示，Controller定义用户界面对用户输入的响应方式。之所以整体架构采用MVC(Model View Controller) 模式，是因为：
1). 将表示层（View）和逻辑层(Model)分开的一个优越性，在于容易在某种数
据的基础上，增加多种表现或者改变某种形式。
2). 逻辑层(Model)以及表示层(View)分开以后，使得它们各自能够独立的变
化。进而使得可维护性，可以扩展性，可测试性方面得到很大的改善。
3). 将控制层(Controller)和表示层（View）可以动态的决定表示的形式。
4). 将控制层(Controller)和逻辑层（Model）可以使得用户的输入和数据处理之间
的关系可以灵活决定。
可以说MVC模式可将“分离显示逻辑与业务逻辑”发挥的淋漓尽致。关于MVC的具体论述，可以参考其它的专业的资料或是Struts体系结构介绍。

4、 经济、技术的可行性论证
对公司来说，由于J2EE体系结构下的应用开发还是比较新颖的，尤其是跨平台的分布式应用研发，对这研发过程的一切可能性风险，都要尽可能的充分估计。但纵观当前的电子政务市场，我们的研发选择无疑是激动人心和大有前途的。如果从公司的长远发展目标和未来的应用（包括各种商业性、政务型以及非营利性等）整合来看，这将是我们最正确的选择。也就是，这种应用的市场潜值非常大，只要做的好，肯定回报丰厚。从另一方面来看，若要在这种应用上有所作为，这需要公司的经济投入。在技术上，我们不得不承认在J2EE方面很弱：包括技术上的和实施经验上的等。要解决这方面的问题，可以从两方面来考虑：一是自身加强技术攻关和人才转型；二是引进专业人才。我的建议是从这两方面入手，这样既可利用现有人力，又可加快研发进度，并能促进公司的整体技术和应用实力的发展，这将是个不错的选择。总的来说，整个方案有很大的伸缩性，也同样具有可实施性。但在研发实施中，有很多问题需要解决，所谓“攻欲其善，必先利其器”。

上海XXX系统技术有限公司 2003-6-20