最广泛的Web组件软件开发技术

我们目睹了软件在商业、工业、管理和研究领域日益膨胀的应用。软件已不再处于技术体系的边缘，已成为许多应用领域中的重要因素。软件的功能在竞争中日渐成为市场上的决定性因素，如在服装行业、汽车行业、服务行业和教育领域等。日益增长的软件用户并不都是专家，这些趋势对软件提出了新的要求。可用性、稳健性、易于安装和集成性正变为软件最为重要的特征。由于软件可用性涉及领域很广，不同领域中对集成的要求呈现增长趋势。通常把在不同管理层次的数据和过程集成方式称为垂直统一管理，把来源于不同领域的相类似的数据类型和过程的集成称为横向结合。

这一系列变动导致了软件变得越来越庞大和复杂。传统的软件开发致力于处理日益增长的复杂性和作为一个系统对外部软件、交付期限和资金预算的依赖，往往忽略了系统进化或升级方面的要求。这已导致了一系列的问题：大多数项目不能在交付期限内完成，超出了预算，不能达到质量要求和持续增长的软件维护费用。为了应对这样的挑战，软件开发应该能够处理软件的复杂性，并能迅速地接受新的挑战。如果新的软件产品在开始开发时就是乱写(没有规划和分析)，那么它们肯定达不到最后的目标。解决这类问题的关键是可重用性。从这个从角度上看，基于组件的软件开发(Component Based Development，CBD)应该是最好的解决途径。这包括对软件复杂性更有效率的管理，快速地推向市场，更高的生产力(开发效率)，提高的质量，更为连贯的一致性和更为广泛的可用性。下面介绍几种最具代表性，最广泛的组件技术。

CORBA组件系统
什么是CORBA
随着互联网技术的日益成熟，公众及商业企业正享受着高速、低价网络信息传输所带来的高品质数字生活。但是，由于网络规模的不断扩大以及计算机硬件技术水平的飞速提高，给传统的应用软件系统的实现方式带来了巨大的挑战。
公共对象请求代理体系结构(Common 0bject Request Broker Architecture，CORBA)，是由对象管理组织(Object Management Group，OMG)提出的应用软件体系结构和对象技术规范，其核心是一套标准的语言、接口和协议，以支持异构分布应用程序间的互操作性及独立于平台和编程语言的对象重用。CORBA在不同平台、不同语言之间实现对象通信的模型，它为分布式应用环境下对象资源共享、代码重用、可移植和对象间相互访问建立了通用标准，同样也为在大量硬件、软件之间实现互操作提供了良好的解决方案。CORBA已经被证实是近年网络技术发展中最重要的革新之一，它致力于解决当前信息系统的两大难题：
①难以快速集成现有硬件系统和新的应用；②开发用户／服务器程序困难。
正是基于面向对象技术的发展和成熟、用户／服务器软件系统模式的普遍应用以及集成已有系统等方面的需求，推动了CORBA技术的成熟与发展。作为面向对象系统的对象通信的核心，CORBA为当今网络计算环境带来了真正意义上的互联。
CORBA同时也是一个分布式对象技术的规范，它是针对多种对象系统在分布式计算环境中如何以对象方式集成而提出的，它为对象管理定义了一个对象模型——OMG参考模型(OMG Reference Model)及其框架结构。该模型由ORB、对象服务、公共设施、领域接口及应用接口5个主要部分组成。该模型及其框架结构将面向对象技术与用户／Ill曼务器计算模式结合起来，有效地解决了对象封装和分布式计算环境中资源共享、代码可重用、可移植以及应用间的互操作性等问题。从最顶层看，CORBA规范指的是对象管理结构(ObjectManagement Architecture，OMA)。

(1)对象请求代理(ORB)。是整个CORBA系统的核心，它的功能类似于计算机硬件系统中总线的功能，它提供了用户和服务对象之间进行信息传送的通路。ORB的作用包括：接受用户发出的服务请求，完成请求在服务对象端的映射；自动设定路由寻找服务对象；向服务对象提交用户参数；携带服务对象计算结果返回用户端。
(2)CORBA对象服务。CORBA对象服务(Object Services)是为实现对象而提供的基本服务集合，是为创建对象、对象访问控制、对象生命期控制、对象引用等提供的一套基本的功能服务。对象服务是为方便应用程序开发人员开发服务对象的必要的系统服务。在构建任何分布式应用时经常会使用到这些服务，而且这些服务独立于应用领域。例如，生命周期服务定义了对象的创建、删除、复制和移动的方法，但它不规定如何在应用中实现这些对象。
C()RBA对象服务由OMG COSS规范规定。COSS规范由一组接口(Interface)和服务行为描述构成，其接口一般使用OMG接口定义语言nterface Definition Language，IDL)描述。目前COSS规范包括如下内容：命名服务(Naming Service)、事件服务(EventService)、生命周期服务(Life Cycle Service)、持久对象服务(Persistent object Service)、并发控制服务(Concurrency Control Service)、外部化服务(Externalization Service)、关系服务(Relationship Service)、查询服务(Query Service)、许可服务(Licensing Service)、属性服务(Property Service)、安全服务(Security Service)和时间服务(Time Service)等。
(3)CORBA公共设施。CORBA公共设施(Common Facilities)提供了一组更高层的函数，这些函数包括用户界面、信息管理等方面的通信设施，为终端用户提供一组共享服务接口，例如综合文档、系统管理和电子邮件服务等。这些服务不像对象服务那么基本。
(4)CORBA领域接口。CORBA领域接口(Domain Interface)与特定的应用领域有关，例如制造业、金融业、通信行业等。
(5)应用接口。应用接口(Application Interface)是由应用程序开发商利用CORBA开发的，为其应用程序服务的接I=I。OMG组织不对它实施标准化工作。应用接口位于参考模型的最高层。

CORBA体系结构
下面介绍CORBA工作的基本原理。ORB是建立对象之间用户／服务器关系的中间件。它使得某个对象可以透明地向其他对象发出请求或接受其他对象的响应。ORB通过接口定义语言(Interface Definition Language，IDI。)程序框架或者动态程序框架来定位响应的代码实现、传递参数以及对对象实现的传送控制。控制和适配器都有其特定的程序框架，在执行请求时，对象实现可以通过对象适配器获得ORB提供的服务，这一请求完成后，控制权和输出结果返回用户。
用户通过访问对象引用，了解对象的类型以及所需执行的操作，并在此基础上执行请求。用户通过发送请求使用对象所实现的服务，用户方可以有三种具体实现方式：使用静态OMG IDL存根，使用动态调用接口，以及为了调用某些特殊功能，用户可能需要与ORB进行直接交互。用户端可以看到的接口有：静态OMG IDL存根、动态调用接t：l、ORB接口和接口库。其中静态OML IDL存根为用户提供静态调用方式，这些经过预编译的IDL存根定义了用户程序如何调用服务器程序的相应服务，从用户角度看，就如同一般的调用，是远程服务器对象的代理；动态调用接口允许用户在运行过程中查找并加以调用：ORB接口是一个包含本地服务的接口，这些服务可以直接为应用程序所使用。接口库是一个运行库，包含由IDL定义接口的机器可读版本，接口库还是ORB的一个动态元数据库，ORB上的组件可以动态访问、存储、修改元数据。
对象的实现同样有三种方式：通过OMG IDL产生程序框架(Skeleton)、通过动态程序框架(Dynamic Skeleton)接收作为上行调用的请求以及在处理请求或其他任何时候，对象实现均可以调用对象适配器和()RB。
服务器能看到的CORBA系统接口有：服务器程序框架、动态程序框架接口、对象适配器、ORB接口和实现库。其中服务器程序框架为服务器程序的每个服务提供静态接口，同静态OMG IDI。存根一样，服务器程序框架也是由IDL编译器产生的；动态程序框架接口允许对象调用的动态处理；对象适配器位于ORB核心通信服务顶端，代替服务对象接受服务请求；ORB接口可以直接为应用程序所使用；实现库存储服务器程序支持的类、实例化对象等。对象的实现可以选择合适的适配器，对象适配器的选择由对象所需要的服务而定。

下面对CORBA的各个组成部分分别加以介绍。
1．对象请求代理ORB
ORB提供了对请求与回答的通信机制，使CORBA应用开发者无须关心具体通信细节，而把注意力集中到实际的应用程序逻辑中去。总的来说，ORB的作用包括：①接收用户发出的服务请求，完成请求在服务对象端的映射；②自动设定路由寻找服务对象；③提交用户参数；④携带服务对象计算结果返回用户端。当用户向服务对象发出事务请求时，用户是向服务对象发出请求的实体，服务对象应包括该方法的数据资源以及实现代码。对象请求代理的作用就是定位服务对象，接收用户发出的服务请求并将服务对象执行的结果返回给用户。请求发出后，用户对象采用轮询等方式来获取服务对象计算的结果。
在ORB结构中，ORB并不需要作为一个单独的组件来实现，而是通过一系列接口和接口定义中说明要实现操作的类型，确定提供的服务和实现用户与服务对象通信的方式。通过IDL接口定义、接口库或适配器的协调，ORB可以向用户机和具备服务功能的对象实现
提供服务。作为CORBA体系结构的核心，ORB可以实现如下三种类型的接口：对于所有的ORB实现具有相同的操作；针对特定类型对象的操作；与对象实现类型有关的操作。
CORBA规范中定义了两种对象请求的实现方式：即动态调用接口(DynamicInvocation Interface，DII)方式和通过OMG IDL文件经编译后在用户端生成的存根方式。这两种实现方式的区别在于通过OMG IDI。存根文件方式实现的调用请求中，用户能够访问的服务对象方法取决于服务对象所支持的接口；而动态调用接口调用方式则与服务对象的接口无关。尽管实现调用请求的方式有所区别，但用户发出的请求服务调用的语义是相同的，服务对象不去分析服务请求提出的方式。ORB通过IDL存根方式或动态调用接口(DID方式定位服务对象的实现代码、传递服务对象应用参数以及完成对请求传送方式的控制。服务对象的实现通过对象适配器提供对用户请求的服务。

2．0MG IDL
在CORBA中，用户和服务对象通信的基本信息都包含在接口中，接口定义了某类对象能够施加的操作。OMG的IDL用于定义CORBA对象的接口，它独立于具体的平台和编程语言，但可以向多种编程语言进行映射。从本质上来讲，OMG IDL接口定义语言不是作为程序设计语言体现在CORBA体系结构中的，而是用来描述产生对象调用请求的用户对象和服务对象之间的接口语言。0MG IDL文件描述数据类型和方法框架，而服务对象则为一个指定的对象实现提供上述数据和方法。0MG IDL文件描述了服务器提供的服务功能，用户机可以根据该接口文件描述的方法向服务器提出业务请求。在大多数coRBA产品中都提供IDL到相关编程语言的编译器。程序设计人员只需要将定义的接口文件输入编译器，设定编译选项后，就可以得到与程序设计语言相关的接口框架文件和辅助文件。 在语法规则方面，类似于C++或Java中关于接口或对象的定义，OMG IDI。增加了一些构造方法支持IDL特有的方法调用机制。OMG IDI。只是一种说明性的语言，支持C++语言中的常量、类型和方法的声明。采用0MG IDL这样的说明性语言，其目的在于克服特定编程语言在软件系统集成及互操作方面的限制，这正是CORBA的诱人之处，同时也体现了采用CORBA构造分布式应用程序在网络时代的强大生命力。

3．对象适配器
对象适配器是为服务对象端管理对象引用和实现而引入的。对象适配器介于ORB内核和对象实现之间，负责服务对象的注册、对象引用的创建和解释、服务进程的激活和结束以及用户请求的分发。在CORBA规范中要求系统实现时对象适配器完成如下功能：
①生成并解释对象的引用，把用户端的对象引用映射到服务对象的功能中。
②激活或撤销对象的实现。
③注册服务功能的实现。
④确保对象引用的安全性。
⑤完成对服务对象方法的调用。
对象适配器是对象实现访问ORB的主要方式，通过对象适配器，oRB可以定制接口，为一组特定的对象提供服务。它又可分为：基本对象适配器(Basic Object Adapter，BOA)和易移植对象适配器(Portable Object Adapter，POA)。基本对象适配器是CORBA中定义的在分布式应用程序设计中常用的对象适配器。其工作方式是ORB将服务请求的参数及操作控制权传递给BOA，由BOA将执行结果返回给ORB。BOA用服务对象框架将ORB和对象实现中的方法联系在一起，服务对象框架中的相应方法将对BOA方法的请求调用映射为服务对象中的方法。
易移植对象适配器POA像BOA一样，可以启动每一个方法的服务器程序、每一个对象的分离程序和某个对象类型所有实例的共享程序。POA同样支持静态框架和动态框架接口。POA还引入了一些新的特性，但必须为对象接口(或实现类型)的每一个实现提供一个实例管理器，实例管理器创建伺服程序或特殊实现的运行实例，POA调用实例管理器上的操作，按需创建伺服程序。POA提供了伺服程序在不同CORBA厂家的ORB实现之间的可移植性。一个服务器应用程序中可能包含多个POA实例，以便支持不同特性的CORBA对象或多种伺服程序的实现类型。

4．接口库和实现库
接口库是存储相关对象接口定义的模块。CORBA引人接口库的目的在于使服务对象能够提供持久的对象服务。将接口信息存入接口仓库后，如果用户端应用提交动态调用请求，ORB可以根据接口库中的接口信息及分布环境下数据对象的描述，获取请求调用所需的信息。接口库作为CORBA系统的组成部分，管理和提供到OMG IDL映射接口定义的访问。接口库中信息的重要作用是连接各个ORB，当请求将对象从一个ORB传递给另一个ORB时，接收端ORB需要创建一个新对象来代表所传递的对象，这就需要在接收端ORB的接口仓库中匹配接口信息。通过从服务请求端ORB的接口仓库中获得接口标识，就可以在接收端的接口仓库中匹配到该接口。接口库由一组接口库对象组成，代表接口库中的接口信息。接口库提供各种操作来完成接口的寻址、管理等功能。在实现过程中，可以选择对象永久存在还是引用时再创建等方式。实现仓库是存储与ORB对象的实现有关信息的模块。如果认为对象实现可以共享，则可以将实现功能放入实现仓库中，从而创建基于库的ORB。

5．上下文对象
上下文对象包含用户机、运行环境或者在请求中没有作为参数进行传递的信息，上下文对象是一组由标识符和相应字符串构成的列表，程序设计人员可以用定义在上下文接口的操作来创建和操作上下文对象。
上下文对象可以以永久或临时方式存储，用户机应用程序用上下文对象来获取运行环境；而ORB用上下文对象中的信息来决定服务器的定位及被请求方法激活。

6．用户桩
用户桩是用户端的代码，用户应用程序通过用户桩向服务器应用程序发送请求。用户方存根为用户提供静态调用方式。这些经过预编译的IDL码根定义了用户程序如何调用服务器程序的相应服务。用户方的存根负责把用户的请求进行编码发送到对象实现端，并对接收到的处理结果进行解码，把结果或异常信息返回给用户，从用户角度看，就如同是一个本地调用，是远程服务器的代理。存根是一段程序代码，为接口的每一种操作提供一种虚实现，具有以下特点：①存根是自动生成的，不需程序员的参与，ORB根据IDL的接口定义生成相应的用户端存根和服务器端静态框架；②存根是静态的，一经生成便不再改变，除非改变相应的IDL并重新生成；③存根是与ORB的具体实现相关的，不同的ORB厂商会有不同的ORB实现，即使相同的IDL接口定义也可能生成不同的存根。而用户端的动态调用接口则通过指定目标对象的引用、操作、属性及被传送的参数来动态创建和调用对服务对象的请求，并发送到对象实现方。在这种调用方式下，用户往往不知道服务对象的接口信息，首先通过查询或者其他手段获得服务对象的接口描述信息，然后自行调用ORB的方法来构造用户请求，并发送到对象实现方。

7．服务端程序框架
服务方的程序框架是在对象实现方与用户方存根相对应的实现机制上，服务方的程序框架对用户请求进行解码，定位所要求的对象的方法，执行该方法并把执行结果或异常信息编码后发送回用户。这种调用适用于在用户执行前服务已知的情况，通常称为静态调用方式，它支持同步请求调用。

COM+组件系统
COM+并不是COM的新版本，可以把它理解为COM的新发展，或者为C()M更高层次上的应用。COM+的底层结构仍然以CoM为基础，它几乎包容了CoM的所有内容。有一种说法这样认为，COM+是COM、DCOM和MTS(Microsoft Transaction Server)的集成，这种说法有一定的道理，因为COM+确实综合了这些技术要素。但更为重要的一点是，COM+倡导了一种新的概念，它把COM组件软件提升到应用层面而不再是底层的软件结构，它通过操作系统的各种支持，使组件对象模型建立在应用层上，把所有组件的底层细节留给操作系统，因此，COM+与操作系统的结合更加紧密。
CoM是个开放的组件标准，它有很强的扩充和扩展能力，从COM到DCOM，再到MTS的发展过程也充分说明了这一点。虽然C()M已经改变了Windows程序员的应用开发模式，把组件的概念融入到Windows应用中，但由于种种原因，DCOM和MTS的许多优越性还没有为广大的Windows程序所认识。MTS针对企业应用和Web应用的特点，在COM／DCOM的基础上又添加了许多功能和特性，包括事务性、安全模型、管理和配置等，MTS使COM成为一个完整的组件体系结构。由于历史的原因，COM、DCOM和MTS相互之间并不很融洽，难以形成统一的整体，不过，这种状况很快就要结束，因为cOM+把这三者有效地统一起来，形成一个全新的、功能强大的组件体系结构，并且把DCOM和MTS的各种优势以更为简洁的方式带给Windows程序员和用户。

1．Windows DNA策略
在介绍COM+结构之前，首先介绍Windows DNA(Distributed Internet ApplicationArchitecture)策略，因为COM+将在DNA策略中扮演重要的角色。Windows DNA是Microsoft多年积累下来的技术精华集合起来而形成的一个完整的、多层结构的企业应用总体方案，它使Windows真正成为企业应用平台。Microsoft在MTS的基础上提出了多层软件结构的概念。从大的方面来讲，一个企业应用或者分布式应用可以分为表现层、业务层和数据层。表现层为应用的用户端部分，它负责与用户进行交互；业务层构成了应用的业务逻辑规则，它是应用的核心，通常由一些MTS组件构成；数据层为后台数据库，它既可以位于专用的数据服务器，也可以与业务层在同一台服务器上。
MTS主要位于中间层，它为业务组件提供了一个运行和管理的统一环境。Windows DNA的结构如图6．3所示。
(1)表示层负责应用程序与用户之间的直接交互，主要有两种类型的用户机：即基于可执行文件的应用程序和基于网络浏览器的web用户，它们分别采用DCOM和HTTP与事务逻辑层进行通信。
(2)事务逻辑层是整个应用程序的关键，它负责系统的工作流程和业务处理。在事务逻辑层，Windows DNA包含一组功能很强的集成应用程序服务。这些服务相互之问和与底层的操作系统之间紧密集成，并通过COM以一种统一的方式进行展示。这些服务包括：
•Web服务，通过IIS实现。
•事务和组件服务，通过MTS实现。
•服务器端脚本编程技术，通过驻留于IIS的ASP或ASP．NET来实现。
•异步消息通信服务，通过MSMQ来实现。
(3)数据层负责系统数据的存储和管理，它主要是通过关系型或xml数据库管理系统来实现。事务逻辑层使用ADo／OLEDB访问其中存储的数据。

2．COM+基本结构
COM+通过把COM、DCOM和MTS统一起来，形成了真正适合于企业应用的构件。
COM+不仅集成了COM、DCOM和MTS的许多特性，而且新增了一些非常重要的系统服务，并提供了一个比MTS更好的构件管理界面。
CoM+提供的新特性包括：
(1)COM+目录。
COM和MTS使用Windows的系统注册表来保存构件的所有配置信息，而COM+的做法与前两者不同，它把大多数构件信息保存在一个称为COM+目录(C()M+Catalog)的新的数据库中。
(2)负载平衡。
COM+提供的负载平衡服务可以以透明的方式实现动态的负载平衡。灵活、可靠地在集群中调节各个服务器节点所分配的负载，增加了系统的可伸缩性和灵活性。
(3)内存数据库(IMDB)。
IMDB(In Memory Database)是一个驻留在内存中的支持事务特性的数据库系统，它可以优化数据查询和数据获取，为COM+应用程序提供快速的数据访问。
(4)对象池。
在应用程序运行时，已经发现构件对象的创建和释放都是开销很大的操作，为了提高效率，c0M+把创建的对象实例保留在对象池中，在用户请求该对象时，可以直接把对象池中现成的对象实例提供给用户，在用户不再使用该对象实例时，将其放回到对象池中，以备下次使用。对象池的使用减小了构件对象创建和释放的开销，提高了运行效率。
(5)队列化构件。
COM+构件除了支持基于RPC连接的同步调用方式，还可以通过低层的消息系统MSMQ(Microsoft Message Queue Server，Microsoft消息队列服务系统)支持异步调用方式。队列化构件使得在用户程序和构件没有建立连接时，以异步的方式进行通信，提高了系统的可靠性和可扩展性。
(6)新的事件模型。
COM+的事件模型改进了COM所采用的可连接对象机制的紧耦合方式，提供了建立在发布者和订阅者概念之上的松耦合方式。发布者负责提供事件信息，订阅者负责消费事件信息，来自不同发布者的事件信息存储在COM+事件数据库中，而订阅者可以通过注册说明它们希望接收到的事件信息。当发布者激发事件时，CoM+事件服务把该事件信息发送给订阅了该事件信息的订阅者。
(7)构件管理和配置。
COM+提供了一个比MTS更友好的构件的管理和配置环境。COM+管理程序(COM+Explorer)采用通用的MMC标准界面，通过COM+管理程序，用户可以灵活方便地设置COM+应用和COM+构件的属性。

J2EE组件系统
J2EE是sun公司在Java技术的基础上提出的企业级应用解决方案。要想了解J2EE就必须先了解什么是Java。大部分Java初学者可能会认为Java与C++一样，仅是一种编程语言而已，但实际上这只是一种狭义的理解。从目前的发展趋势来看，Java已经成为一门十分庞杂的技术体系，这个技术体系以Java语言为核心。此外，还包括Java—appIet，RMI-IIOP，JavaIDI。／CORBA，JavaBeans，Servlet，JSP，JDBC，JNDL，EJB和Javamail等，而J2EE正是在Java语言的基础上整合了这些关键技术而形成的一个新的框架。它提供了一个多层次的分布式应用模型和一系列开发技术规范。多层次分布式应用模型是指根据功能把应用逻辑分成多个层次，每个层次支持相应的服务器和组件，组件在分布式服务器的组件容器中运行(如Servlet组件在Servlet容器上运行，EJB组件在EJB容器上运行)，容器间通过相关的协议进行通信，实现组件间的相互调用。遵从这个规范的开发者将得到行业的广泛支持，使企业级应用的开发变得简单、快速。
1．J2EE的体系结构
JgEE的体系结构是多层的分布式体系结构，应用逻辑按功能划分为不同的组件，组件根据自己所在的层分布在不同的机器上(也可以放在同一台机器上)，克服了两层模式的弊端。在传统模式中，用户充当了过多的角色而显得臃肿，在这种模式中，一次部署时容易，但是难以升级或改进，伸展性也不理想，而且常基于某种专有协议(通常是某种数据库协议)，它使得重用业务逻辑(业务过程)和界面逻辑非常困难。现在，J2EE的多层企业级应用能够为不同的各种服务提供一个独立的层。以下是J2EE的典型4层结构。
(1)运行在J2EE用户端机器上的用户层组件。
用户端层用来实现企业级应用系统的操作界面和显示层。另外，某些用户端程序也可实现业务逻辑。可分为基于Web的和非基于Web的用户端两种情况。基于Web的情况下主要作为企业Web服务器的浏览器。非基于Web的用户层则是独立的应用程序，可以完成瘦用户机无法完成的任务。
(2)运行在服务器上的Web层组件。
为企业提供web服务，包括企业信息发布等。web层由Web组件组成。J2EE Web组件包括JSP页面和Servlets。Web层也可以包括一些JavaBeans。Web层主要用来处理用户请求，调用相应的逻辑块，并把结果以动态网页的形式返回到用户端。
(3)运行在服务器上的业务逻辑层组件。
业务层也叫EJB层或应用层，它由EJB服务器和EJB组件组成。一般情况下许多开发商把Web服务器和EJB服务器产品结合在一起发布，称为应用服务器。EJB层用来实现企业级信息系统的业务逻辑。这是企业级应用的核心，由运行在业务层中的EJB来处理。一个Bean从用户端接收数据、处理，然后把数据送到企业信息系统层存储起来。同样，一个Bean也可以从企业信息系统取出数据，发送到用户端程序。业务层中的EJB要运行在容器中，容器解决了底层的问题，如事务处理、生命周期、状态管理、多线程安全管理、资源池等。
(4)运行在EIS服务器上的企业信息系统层软件。
处理企业系统软件，包括企业基础系统、数据库系统及其他遗留的系统。J2EE将来的版本支持连接架构(Connector Architecture)。它是连接J2EE平台和企业信息系统层的标准API。

2．J2EE的特点
(1)多层模型。J2EE提供了多层应用和程序模型，意味着应用程序的不同部分运行在不同的设备上。
(2)基于容器的组件管理。J2EE基于组件的开发模型的中枢是容器的概念，容器提供组件运行时环境，组件可以期望它们服务在任何J2EE平台上都有效。
(3)对用户组件的支持。J2EE的用户层提供了对多种用户机类型的支持，可以在企业防火墙之内和防火墙之外。
(4)对商业逻辑组件的支持。在J2EE的平台中，EJB组件实现中间层的商业逻辑，EJB组件或应用程序的开发者，将精力集中在商业逻辑的开发上，将复杂的服务器交由EJB服务器处理。
(5)对J2EE标准的支持。J2EE定义了一系列的相关规范，J2EE平台必须支持规范。

Web Service基础
Web Service技术的出现，顺应了两个方面的需求与发展：一方面。随着十万、百万级软组件在庆用系统中获得使用，对可复用的软组件的标准化提出更高的要求。组件技术在不同组件的信息交换，跨平台和编程语言等方面实现了标准化，但对于组件接口的定义和组件之间的通信机制却没有定义统一的标准。Web Service在此基础上更进一步，能过WSDL语言使接口描述标准化，通过标准的HTTP／S()AP通信协议使组件之间的通信机制更加标准化。另一方面。互联网技术的发展，使得可以的软件资源越来越丰富，软件之间的耦合度越来越松散，web Service通过服务发现机制进一步适应了这种需求。webService不仅是一个基于复用组件技术的升级，它还带来了软件工程领域革命性的变革，它改变了我们开发、发布和管理软件的方式，也发展了传统的分布式计算机模式，XaaS、云计算、务联网(The Internet of Serive)也为了当前热门的计算技术。限于篇幅，本节将仅讨论Web Service基础，包括基本概念及基于Web Service的重用模式。
1．Web Service基本概念
Web Service是一个或者一组应用程序，向外界提供一个能够通过Web进行调用的API。Web Service的主要目标是在现有的各种异构平台的基础上构筑一个通用的与平台和语言无关的技术层。多种不同平台上的应用依靠这个技术层来实施彼此的连接和集成。
Web Service技术具有以下特点：
(1)完好的封装性。Web Service是一种部署在web上的对象，具备对象的良好封装性。对使用者而言，它能且仅能看到该对象提供的功能列表。
(2)松散耦合。当一个Web Service的实现发生变更甚至是当Web Service的实现平台发生转移时，调用者不会感到有变化。
(3)使用标准协议规范。在Web Service中所有的技术实现都基于开放的标准协议规范。
(4)高度可集成能力。由于Web Service采用标准Web协议作为组件界面描述和协同描述规范，完全屏蔽了不同软件平台的差异，任何软件都可以通过标准的协议进行互操作。实现了在当前环境下最高的可集成性。
实现了在当前环境下最高的可集成性。
一个完整的Web Service包括三种逻辑组件：服务提 供者、服务代理和服务请求者，如图6．5所示。在图中，各 组件分别对应不同的角色。服务提供者提供服务。并进行 注册以使服务可用；服务代理起中介作用。它是服务的注 册场所，充当服务提供者和服务请求者之间的媒介：服务 请求者可在应用程序中通过向服务代理请求服务。调用所 需服务。

与Web Service相关的操作主要有：
(1)发布——服务提供者向代理发布所提供的服务。该操作对服务进行一定的描述并发布到代理服务器上进行注册。在发布操作中，服务提供者可以决定发布(注册)或者不发布(移去)服务。
(2)发现一一服务请求者向代理发出服务查询请求。服务代理提供规范的接口来接收服务请求者的查询请求。通常的方法是，服务请求方根据通用的行业分类标准浏览或通过关键字搜索，并逐步缩小查找范围，直到找到满足所需要的服务。
(3)绑定一服务的具体实现。分析从注册服务器中得到的调用该服务所需的详细绑定信息(服务的访问路径、调用的参数、返回结果、传输协议、安全要求等)，根据这些信息，服务请求方就可以编程实现对服务的远程调用。
实现Web Service的异类基本结构以及在整个Web中实现Web Service的关键是实现支持简单数据描述格式的技术。这种格式就是XMI。。数据独立性是XML的主要特征。由于XML文档只描述数据，因此任何理解XMI。的应用程序(不管其编程语言或平台如何)都可以以各种不同的方式对其格式化。Web Service必须使用XMI。来完成三件事情：基本的缆线格式、服务描述以及“服务发现”。Web Service使用SOAP作为它的标准通信协议。SOAP(Simple 0bject Access Protoc01)在通信的最低级别。系统需要使用同一语言，特别是作为通信双方的应用程序需要遵守同一套通信规则：如何表示不同的数据类型(例如：是整数还是数组)，以及如何表示命令(即需要对数据进行何种操作)。另外，在必要的时候应用程序还需对该语言进行适当的扩展。简单对象访问协议(SOAP)是XML的实施工具。它提供了一套公共规则集。该规则集说明了如何表示并扩展数据和命令。wSDL(WebService描述语言)是描述Web服务的XML格式语言。它用来定义Web Service并描述如何访问这些服务。WSDL文档把Web Service定义为一组在包含面向文档或面向过程信息的消息上执行操作的端口。其中操作(operation)和消息(message)采用抽象方式进行描述。然后把它们绑定到具体的网络协议和消息格式上来定义一个具体的端口。多个相关的具体端口结合在一起就构成了服务(service)双方应用程序。在得到了如何表示数据类型和命令的规则后，需要对所接收的特定数据和命令进行有效的描述。仅仅说已接收到整数是不够的；例如，在接收到两个整数后，应用程序必须明确表述它可以对这两个整数执行乘法运算操作。一旦部署了Web服务，潜在用户就必须能够发现它在什么地方以及它如何工作。统一描述、发现和集成的UDDI(Universal Dessription，Discovery，and Integration)是一种规范，它定义了一项基于SOAP的协议，用于更新和查询Web服务信息库。UDDI是一套面向Web服务的信息注册中心的实际标准和规范。创建UDDI注册中心的目的是实现Web服务的发布和发现。利用UDDI规范在Web上建立发现服务。这些发现服务为所有请求者提供了一致的接口，使得已经发布的Web服务能够让请求者得以发现。UDDI可以发布并发现Web服务，最大限度地访问站点并获得最终的成功。

2．基于Web Service的重用模式
随着软件重用技术的发展与可重用粒度的增大，对软件管理提出了许多新要求，如组织的管理方法如何适应复用的需求、开发人员知识更新与心理因素保证、知识产权以及商业秘密等问题。此外，软件重用还必须解决目前在应用与实现过程中存在的三个核心问题或原则：一是存在性原则，即必须存在可以复用的对象资源；二是可发现性原则，即需要向用户提供查找所需复用对象的有效手段；三是标准化原则，即为使用者提供被复用对象的标准使用方法。尽管实现软件复用的各种技术因素和非技术因素是互相联系的，但这三个基本问题是实现真正成功的软件复用的核心与基础。

Web Service的体系结构模型由资源对象、服务对象、角色对象、协议栈和指令方法5个要素构成，其中，服务对象是对资源对象的抽象和封装，并通过Web服务的形式向外部提供由WSDL描述的通用组件接口。提供者将创建的服务注册并发布到UDDI中心后，服务请求者就可以通过UDDI中心进行查找和引用，最后实现与提供者的绑定、调用与显示。另外，由于消息的传输与响应以及接口的描述都是利用基于XML的协议完成，一方面实现了真正意义上的跨平台和语言无关性；另一方面，有效地解决了软件重用过程中存在着的三个核心问题，即通过服务的创建与发布实现了存在性原则；利用UDDI提供的发布与查询机制为用户提供了有效的发现手段；另外，通过一系列的标准协议集为使用者提供了对服务对象的标准使用方法，从而为分布式松耦合环境下软件与数据的重用提供有效手段。

与CORBA技术一样，Web Service作为一种开放系统重用模式，可有效地解决目前分布式、异构环境中的互操作问题。但丽者在应用方式与使用范围中存在一些差异，在实现上cORBA技术对特定操作系统、程序设计语言或者对象模型专用协议有相应的限制和要求，并侧重于解决Intranet尺度范围内的分布式系统中进行互操作的问题；而Web Service技术则是建立在XMI。与Internet标准协议的基础之上，使用基于文本的消息传送模型进行通信，主要侧重于解决目前基于Internet大尺度范围内的互操作问题。Web Service通过对业务逻辑的有效封装、发布、查找与绑定机制，利用一系列标准化协议的支持，将提供者所生产的服务通过UDDI注册并发布后，供请求者来选择重用，在解决传统软件重用过程中存在的三个核心问题的同时，由于服务可对不同粒度的应用逻辑进行封装，从而实现了系统级的较大粒度重用，并通过软件与数据资源的透明化重用，提高了软件开发与部署的效率和成本。

本章小结
本章首先介绍了基于组件的软件开发技术，分别介绍了CORBA，COM+和J2EE三种组件系统，介绍了它们的体系结构和工作原理；然后介绍了基于Web Service的软件开发技术，重点描述了基于Web Service的重用模式。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com