导读：
使用IBM技术解决SOA集成体系结构 使用IBM技术解决SOA集成体系结构
使用IBM技术解决SOA集成体系结构
一．SOA体系结构
SOA 体系结构形式目的是提供企业业务解决方案，这些业务解决方案可以 按需扩展或改变。SOA 解决方案由可重用的服务组成，带有定义良好且符合标准的已发布接口。SOA 提供了一种机制，通过这种机制，可以集成现有的遗留应用程序，而不管它们的平台或语言。
从概念上讲，SOA 中有三个主要的抽象级别：
操作：代表单个逻辑工作单元的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA 操作与面向对象的方法相比。都有特定的结构化接口，并且返回结构化的响应。完全同方法一样，特定操作的执行可能涉及调用附加的操作。
服务：代表操作的逻辑分组。例如，如果我们将 CustomerProfiling视为服务，则 按照电话号码查找客户、 按照名称和邮政编码列出顾客和 保存新客户的数据就代表相关的操作。
业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。业务流程的例子有： 接纳新员工、 出售产品或服务和 完成订单。业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程编排。典型的情况是调用已编排服务来响应业务事件。
二．IBM的SOI思想概述
2.1企业集成的新方法SOI
以服务为中心的集成，简称 SOI。 它可以定义为：在以服务为中心的体系架构（SOA）中，通过服务的交互来集成各企业的 IT 资源，如分布的应用或者数据，帮助企业 IT 部门将已有但老旧而不灵活的系统集成起来，释放其中功能或数据为可重用的服务与业务流程。
SOI 继承和发展了传统的 EAI，比较而言，SOI 的好处在于:
定义良好而又基于标准的接口 - 服务的描述易于理解，而且标准一致
实现技术和位置的透明 - 提供服务功能的应用，它的位置以及所使用的实现技术被接口所屏蔽，事实上，不需要一个固定的服务提供者
灵活性 - 只要服务的接口不变，服务的提供者和服务的使用者都可以变化而不影响彼此，从而将变化带来的影响减少到了最少
重用能力
渐进式集成 - 在 SOI 中，通过将若干已有系统的相关功能转化为服务来进行集成。随着这些项目的进行，可重用的服务越来越多，最终，新的集成需求将绝大多数可以通过已有的服务来完成。所以，我们可以从当前重要的集成需求开始来封装已有系统的功能和开发必要的新服务，以渐进的方式逐步地扩展到整个企业范围内的集成。更重要的是，由于服务的灵活性，即使已有系统迁移到新的技术平台，甚至是被替代，都不会影响到依赖于这个应用所提供功能的那些应用，从而保证了集成对变化的适应能力，使得业务灵活性有一个坚实的基础。这也意味着从传统规模大、投入大、周期长、见效慢、风险高、专有技术，转向小步快跑、见效迅速、风险低、基于标准的集成方式。这对于如今面对业务需求快速变化的 IT 机构来说，SOI 在投入和工程方面的好处，是非常吸引人的
2.2 SOI解决方案
IBM的 Websphere 业务集成参考架构(见图1，以下称参考架构)是典型的以服务为中心的企业集成架构。
以服务为中心的企业集成采用"关注点分离"(Separation of Concern)的方法规划企业集成中的各种架构元素，同时从服务视角规划每种架构元素提供的服务，以及服务如何被组合在一起完成某种类型的集成。这里架构元素提供的服务既包括狭义的服务（WSDL描述），也包括广义的服务（某种能力）。从服务为中心的视角看来，企业集成的架构按图1所示的方式划分为六大类：
业务逻辑服务(Business Logic Service)：包括用于实现业务逻辑的服务，和执行业务逻辑的能力。这其中包括业务应用服务(Business Application Service)、业务伙伴服务(Partner Service)以及应用和信息资产(Application and Information asset)。
控制服务(Control Service)：包括实现人(people),流程(process)和信息(information)集成的服务，以及执行这些集成逻辑的能力。
连接服务(Connectivity Service)：连接服务通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。
业务创新和优化服务(Business Innovation and Optimization Service)：用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的市场。
开发服务(Development Service)：贯彻整个软件开发生命周期的开发平台，从需求分析，到建模、设计、开发、测试，维护全面的工具支持。
IT服务管理(IT Service Management)：支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。
2.2.1 连接服务 - 企业服务总线
企业服务总线(Enterprise Service Bus)，简称ESB, 是过去消息中间件的发展，ESB 采用了"总线"这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态地互联互通。
ESB 的基本特征和能力包括：描述服务的元数据和服务注册管理；在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式，异步模式等；发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。
ESB 所提供的基于标准的连接服务，将应用中实现的功能或者数据资源转化为服务请求者能以标准的方式来访问的服务；当请求者来请求一个服务时，ESB 中这种中介转化过程可能简单到什么也没有，也可能要很复杂的中介服务支持，包括动态地查找、选择一个服务，消息的传递、路由和转换、协议的转换。这种中介过程，是 ESB 借助于服务注册管理以及问题域相关的知识（如业务方面的一些规则等）自动进行的，不需要服务请求者和提供者介入，从而实现了解耦服务请求者和提供者的技术基础，使得服务请求者不需要关心服务提供者的位置和具体实现技术，双方在保持接口不变的情况下，各自可以独立地演变。
所以，ESB 采用总线结构模式简化了应用之间的集成拓扑，通过源自实践的模式，提供了基于标准的通用连接服务，使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互，从而在不同层次上使得SOI 解决方案是一个松散耦合、灵活的架构。
ESB 是一种架构模式，不能简单地等同于特定的技术或者产品，但实现 ESB 确实需要各种产品在运行时和工具方面的支持。IBM 有很好的产品支持，运行时支持包括 WebSphere ESB 和 WebSphere Message Broker；而工具方面 IBM 则有 WebSphere Integration Developer，支持用户以图形界面的方式来完成相关的开发任务，如发布服务，使用各种模式，转换消息，定义路由等等。
2.2.2 业务逻辑服务
整合已有应用 - 应用和信息访问服务。已有应用和信息是实现业务逻辑和业务数据的重要资产。通过集成已有的应用和信息将可以在已有企业系统上实现更多增值服务，所以集成已有应用和信息是企业集成中重要的一环。
以服务为中心的企业集成通过应用和信息访问服务(Application and Information Access Service)来实现对已有应用和信息集成。它通过各种适配器技术将已有系统中的业务逻辑和业务数据包装成企业服务总线支持的协议和数据格式。通过企业服务总线，这些被包装起来的业务逻辑和数据就可以方便的参与上层的业务流程，从而已有应用系统的能力可以得以继续发挥。这里的已有应用包括遗留应用、预包装的应用和各种企业数据存储。在参考架构中，主要有两类访问服务：
可接入服务(On-Ramp Service): 通过各种消息通信模式(单向、请求/应答和轮询)将业务逻辑和业务数据包装成企业服务总线可以访问的功能。
事件发现服务(Event Detect Service) : 提供事件通知服务将已有应用和数据中的变化通过事件框架发布到企业服务总线上。
整合新开发的应用 - 业务应用服务。和已有应用和数据类似，新开发的应用也作为重要的业务逻辑成为企业集成的目标。以服务为中心的企业集成通过业务应用服务(Business Application Service)实现新应用集成。一方面业务应用服务帮助程序员开发可重用、可维护和灵活的业务逻辑组件，另一方面，它也提供运行时的集成提供对业务逻辑组件的自治管理。在参考架构中，有三类业务应用服务：
组件服务(Component Service)：为可重用的组件提供应用的运行时容器管理服务，如对象持久化、组件安全管理和事务管理等。
核心服务(Core Service)：提供运行时的服务，包括内存管理、对象实例化和对象池、性能管理和负载均衡、可用性管理等。
接口服务(Interface Service)：提供和其他企业系统集成的接口，如其他企业应用，数据库、消息系统和管理框架。
整合客户和业务伙伴（B2C/B2B）－伙伴服务。以服务为中心的企业集成通过伙伴服务提供与企业外部的B2B的集成能力。因为业务伙伴系统的异构性，伙伴服务需要支持多种传输协议和数据格式。在参考架构中，提供如下服务：
社区服务(Community Service): 用于管理和企业贸易的业务伙伴，支持以交易中心(Trade Hub)为主的集中式管理和以伙伴为中心的自我管理。
文档服务(Document Service)：用于支持和业务伙伴交换的文档格式，以及交互的流程和状态管理，支持主流的RosettaNet、EDI和AS1/AS2等。
协议服务(Protocol Service)：为文档的交互提供传输层的支持，包括认证和路由等。
2.2.3 控制服务
数据整合－信息服务。企业数据的分布性和异构性是应用系统方便访问企业数据和在企业数据之上提供增值服务的主要障碍。数据集成和聚合技术在这种背景下诞生，用于提供对分布式数据和异构数据的透明访问。
以服务为中心的企业集成通过信息服务提供集成数据的能力，目前主要包括如下集中信息服务：
联邦服务(Federation Service): 联邦服务提供将各种类型的数据聚合的能力，它既支持关系型数据，也支持象XML数据、文本数据和内容数据等非关系型数据。同时，所有的数据仍然在自己本身的方式管理。
复制服务(Replication Service)：复制服务提供远程数据的本地访问能力，它通过自动的实时复制和数据转换，在本地维护一个数据源的副本。本地数据和数据源在技术实现上可以是独立的。
转换服务(Transformation Service)：转换服务用于数据源格式到目标格式的转换，可以是批量的，或者是基于记录的。
搜索服务(Search Service)：提供对企业数据的查询和检索服务，既支持数据库等结构化数据，也支持象PDF等非结构化数据。
流程整合- 流程服务。企业部门内部的IT系统通过将业务活动自动化来提高业务活动的效率。但是这些部门的业务活动并不是独立的，而是和其他部门的活动彼此关联的。勿容置疑，将彼此关联的业务活动组成自动化流程可以进一步提高业务活动的效率。业务流程集成正是在这一背景下诞生的。
以服务为中心的企业集成通过流程服务来完成业务流程集成。在业务流程集成中，粒度的业务逻辑被组合成业务流程。流程服务提供自动执行这些业务流程的能力。在参考架构中，流程服务包括如下内容：
编排服务(Choreography Service): 编排服务通过预定义的流程逻辑控制流程中业务活动的执行，并帮助业务流程从错误中恢复。
事务服务(Transaction Service)：事务服务用于保证流程执行中的事务特性(ACID)。对于短流程，通常采用传统的两阶段提交技术，对于长流程，一般采用补偿的方法。
人工服务(Staff Service)：人工服务用于将人工的活动集成到流程中，一方面它通过关联的交互服务使得人工可以参与到流程执行中，另一方面它需要管理由于人工参与带来的管理任务如：任务分派，授权和监管等。
用户访问整合 - 交互服务。将适当的信息，在适当的时间，传递给适当的人是一直是信息技术追求的目标。用户访问集成是实现这一目标的重要一环，它负责将信息系统中的信息传递给客户，不管它在那里，它以什么样的设备接入。
以服务为中心的企业集成通过交互服务来实现用户访问集成。参考架构中的交互服务包括如下类型：
交付服务(Delivery Service): 交付服务提供运行时的交互框架，它通过各种技术支持同样的交互逻辑可以在多种方式(图形界面、语音和普及计算消息)和设备(桌面、PDA、无线终端等)上运行，比如通过页面聚合和标签翻译使得同一个Portlet可以在桌面浏览器和PDA浏览器上展现。
体验服务(Experience Service): 通过用户为中心的服务增强用户体验, 其中的技术包括：个性化、协作、单点登录等。
资源服务(Resource Service): 提供运行时交互组件的管理，如安全配置、界面皮肤等。
三．案例分析
3.1系统架构设计
3.1.1 案例背景
凤凰医疗设备有限公司是一家专门制造和营销专业医疗器械和实验仪器仪表等仪器的民营企业，其购销客户和网络遍布全国各地。凤凰成立于2000年。
2004年凤凰公司引进并在公司内部成功实施了某ERP系统（部署在凤凰企业内部的Web应用），主要用于凤凰公司的财务管理，其中包括产品库存及订单管理等。ERP的实施大幅度地提高了公司的管理效率。
随着公司业务规模的扩大和产品质量的提升，凤凰公司的客户数量越来越大。凤凰公司不得不考虑使用客户关系管理系统（CRM）来进一步提高销售人员的工作效率。于是，2005年8月份凤凰公司引进并成功应用了某客户关系管理系统（CRM）。CRM通过订阅的方式来提供客户关系管理服务，凤凰的销售人员在任何时间和地点只需要通过普通的Web浏览器就可以使用和管理客户及销售信息，包括客户信息，商机，业务机会，以及客户及销售信息分析图表等。
现在凤凰公司的财务和销售人员分别在ERP和CRM系统上工作，工作效率有很大提高。但是公司目前也面临挑战：一方面，ERP和CRM中分别维护产品和客户信息，而公司规定ERP必须作为这些信息的主数据源，ERP中的这些信息需要随时同步到CRM中去；另一方面，CRM中维护的业务机会和ERP中维护的销售订单有着非常紧密的关系，凤凰公司希望能够把业务机会和销售订单有效地整合起来，而进一步提高业务运作的效率。
3.1.2 业务环境分析
本文以销售订单管理系统的业务机会管理流程为例，说明如何用以服务为中心的企业集成技术一步一步解决该公司面临的企业集成问题。
业务机会管理是指与潜在客户进行谈判确定业务机会，创建销售订单请求，发送到ERP系统。首先销售人员开始进行客户查询处理发现潜在客户，否则将建立新客户并将所得的客户信息存储在CRM中的客户管理中。然后从ERP系统中提取产品相关信息进行产品选择，再由客户信息和产品信息生成业务机会。业务机会的信息会存储在CRM系统中，并随时由销售人员更改业务机会的信息和业务机会的状态。当业务机会成功时，业务机会中的信息会通过订单请求的方式，发到ERP系统中，等待财务人员进行处理。
图 3.1.1 业务机会流程图
图3.1.1是一个业务机会管理的业务流程图。由图可见，业务机会流程依次有下列活动：
（1） 从CRM中获取客户信息；（自动活动）
（2） 从ERP中获取产品信息；（自动活动）
（3） 生成业务机会信息；（自动活动）
（4） 业务机会谈判；（人工活动）
（5） 生成销售订单请求；（自动活动）
（6） 发送销售订单请求给ERP系统；（人工活动）
实际上，如果对每个业务活动划分更细的话我们将得到更多的活动。可以更多的考虑，当CRM中有该客户信息时，直接使用客户信息建立业务机会，当CRM中不存在该客户信息时，要求创建客户存入CRM中，然后再进行业务机会的创建。因此，这里可以将CRM的客户信息管理服务用到流程中。以服务为中心的企业集成通过服务建模过程发现这些可重用的服务，并通过流程模型将这些服务组装在一起。
3.1.3 服务建模
IBM推荐使用组件业务建模(Component Business Model)和面向服务的建模和架构(Service-Oriented Model and Architecture)两种方法学建立业务的组件模型，服务模型和流程模型。
服务模型是服务建模的主要结果。业务机会管理相关的服务模型如图3.1.2所示。和业务机会流程相关的有三个业务组件：
图3.1.2 业务机会管理相关模型
销售订单管理（Business Chance Management）:负责业务机会管理，销售订单管理以及库存管理等业务活动。
CRM客户管理（CRM）：负责客户信息的管理。
ERP产品信息管理（ERP Products Management）：负责产品相关信息的管理。
这三个业务组件分别输出如下服务：
1) 业务机会流程: 由销售订单管理输出，主要用于业务机会管理流程的编排；
2) 业务机会信息生成: 由销售订单管理输出，主要用于生成由客户信息和产品信息生成的业务机会信息；
3) 业务机会谈判：由销售订单管理输出，用于与客户协商确定业务机会内容；
4) 销售订单请求信息生成：由销售订单管理输出，用于生成由业务机会得到的销售订单请求信息；
5) 发送销售订单请求信息：由销售订单管理输出，用于向ERP系统发送销售订单请求，同时通知财务人员进行销售订单处理；
6) 获取产品信息：由ERP产品信息管理输出，用于获取产品信息列表；
7）获取客户信息：由CRM客户信息管理输出，用于获取客户信息；
8）创建客户信息：由CRM客户信息管理输出，用于创建客户信息；
在服务建模确定系统相关的服务输出后，我们还需要确定服务在当前环境下的实现方式。在我们的案例中，获取产品信息和获取客户信息被实现为信息服务，业务机会流程被实现为流程服务，通过BPEL4WS方式实现；业务机会信息生成、销售订单请求信息生成被实现为业务应用服务；创建客户信息、业务机会谈判和发送销售订单请求信息服务都是Staff Service。
3.1.4 IT环境分析
IT环境分析是调查现有应用技术特点的重要手段。在我们的示例中，IT环境分析主要用于调查现有应用，为决定服务模型中服务的实现方式提供技术依据。同时，它也是架构设计的重要依据。
在案例中，信息服务以及业务应用服务都被假设为已经设计好的Web服务，我们只需要根据流程调用Web服务方式实现。所以，这里弱化了一些企业服务集成的概念。主要技术实现重点放在了构造组件模块、Portal实现流程服务及人工交互服务、ESB实现总线调用Web服务方面。
3.1.5 高层架构设计
根据需求和设计阶段的业务模型和现有IT环境调研结果，业务机会管理的高层架构被设计了出来。如图：
图3.1.3业务机会管理系统架构
（1） 流程服务
业务人员使用BPEL来进行流程编排，创建需要的业务流程。然后通过该流程可以从Web服务中得到需要的服务，完成业务功能。这样，使业务的变更和扩展得到很好的解决。Process Server为流程编排和选择提供了运行的环境。通过Process Server的管理我们能够选择适合的业务去完成系统功能。
使用IBM WeSphere Business Integration Modeler, Advanced Edition 进行业务建模和编排BPEL4WS业务流程,生成描述文件,在 IBM Websphere Process Server中执行。
（2） 交互服务
分为两种，一类是与业务流程交互，触发流程开始运行；一类是人工服务，通过Portal展示让人工服务参与到流程的交互中去，比如我们的创建客户信息以及业务机会谈判都是需要通过用户使用Portal页面来进行与人工任务的交互来完成需要的业务流程。
在Portal展示中使用IBM Rational Application Developer for Websphere Software进行开发,并运行在IBM Websphere Portal Server服务器平台上,为系统提供前台展示和交互服务。
（3） ESB
在设计中的传输服务用来完成服务消息的传输，因为在这个系统中设计的服务是用WSDL进行服务描述的，所以传输服务是用来统一传输协议。这里基本上使用的是SOAP/HTTP协议。
在设计中的中介服务允许动态处理消息传输、动态路由和服务绑定解析服务。当服务消息传递给ESB时，中介服务会通过服务解析对消息进行解析，然后根据解析出来的消息触发信息进行服务路由，以完成动态路由及消息传输。所以在服务定义时，我们要考虑定义服务的触发信息以符合ESB的功能。
本系统底层使用WebSphere V6 Messaging Resources作为消息传递引擎,使用IBM WebSphere Application Server 作为ESB服务器,支持ESB的扩展功能.
3.1.6 开发角色
表3.1.1 角色划分和工具支持
角色 开发方法和工具 任务
业务分析员 WebSphere Integration Developer 进行流程建模
CBM
架构人员 Rational Software Architect 利用SOMA进行服务建模
SOMA 系统架构设计和建模
整合开发人员A WebSphere Integration Developer 服务组件建模
整合开发人员B WebSphere Portal Server Toolkit Portlet开发
整合开发人员C WebSphere Process Server 部署流程，人工任务及
服务组件
整合开发人员D WebSphere Application Server 建立服务总线
3.2利用portal执行业务流程与人工任务
3.3 SCA服务模型
3.3.1 SCA定义
IBM提出了一种新的服务组件模型。这是一种全新的、跟语言无关的编程模型，它提供了一种统一的调用方式，从而使得客户可以把不同的组件类型，比如EJB, 流程组件，人工交互组件等都可以通过一种标准的接口来封装和调用。结合SDO的数据模型，这种服务组件的编程模型可以大大的简化客户的编程，提高应用的灵活性，这就是面向服务组件的架构（Service Component Architecture，SCA）。
这种方式使得客户的企业应用具有良好的分层架构，能够很好的分离应用的业务逻辑和IT逻辑，不但易于应用的构建，也易于应用的更改和部署。
3.3.2 SCA中的基本概念
（1）服务组件
服务组件是SCA中的基本组成元素和基本构建单位，也是具体实现业务逻辑的地方。我们可以非常容易地把传统的服务流程，无状态会话BEAN等包装成SCA中的服务组件。 SCA服务组件的主要接口规范是基于WSDL的，为了给Java编程人员提供一个比较直接的接口，SCA的部分服务组件也提供了Java接口。因此，使用服务组件的客户端可以选择使用WSDL接口或Java接口。
如图所示，服务组件提供给别的服务调用的入口叫Interface（接口）。而服务组件本身可能也需要调用别的服务，这个调用出口叫Reference（引用）。无论是接口还是引用，其调用规范都是WSDL或Java接口。
图3.3.1 SCA 服务组件接口模型
WebSphere Process Server利用了SCA的这种组件架构，提供了一些与业务联系比较紧密的组件，比如业务流程，人工任务，业务状态机，业务规则等。用户可以直接利用这些服务组件，构建自己的业务流程或其它业务集成的应用。在WebSphere Process Server V6.0.1中，服务组件及SCA在架构中的作用如图 3.3.2所示
图3.3.2 WebSphere Process Server V6.0.1的架构环境
（2）服务模块
服务模块由一个或多个具有内在业务联系的服务组件构成。把几个服务组件放在一个模块中，或者把哪些服务组件放在一起主要取决于业务需求和部署上灵活性的要求。模块是SCA中的运行单位，一个SCA模块背后对应的是一个J2EE的企业应用项目。在WID中构建一个模块就相当于构建一个项目。另外，由于模块是一个单独部署的单元，这给应用的部署带来很大的灵活性。比如，只要保持模块接口不变，我们很容易通过重新部署新的模块而替换原有的业务逻辑，而不影响应用的其它部分。
图3.3.3 服务模块模型
（3）导入和导出
用户实际的应用经常是比较复杂的，因此实际的应用通常需要多个模块才能满足要求，而且这些模块之间又往往存在相互调用的关系。
另外模块中服务组件除了调用别的服务组件之外，也需要调用已有的一些应用，或者是让一些已有的应用来调用模块的服务，而这些应用可能不是基于SCA架构的。为了解决上述问题，在模块中引入了两个端点，一个是导入（Import），它的作用是使得模块中的服务组件可以调用模块外部的服务。另一个是导出（Export），它的作用是使得模块外部的应用可以调用模块中的服务组件。
由于涉及到模块内外的调用，因此需要指定专门的绑定信息。这些绑定信息包括了目标服务或源服务的调用方式，位置信息，调用的方法等。在WebSphere Process Server V6.0中，导入端点提供了四种绑定方式，包括：JMS绑定，Web Service绑定，SCA绑定和无状态会话BEAN的绑定。导出端点提供了三种绑定方式，包括：JMS绑定，Web Service绑定和SCA绑定。对于SCA模块之间的调用，我们可以非常方便的把绑定方式设置为SCA绑定，但是对于非SCA模块与SCA模块之间的调用我们只能选择其它绑定方式。
图3.3.4 SCA导入和导出
（4）数据对象
SCA提供了一个用于定义业务服务的通用模型。服务数据对象 (SDO) 提供了一种用通用模型来表示数据的方法。可以将 SCA 组件组合在一起，并且通过传递 SDO 来以一种中立的方式相互交换数据。SDO 体系结构中的基本概念是数据对象，它是用于存放基元类型的数据或其他数据对象的数据结构。数据对象还存放对元数据的引用，元数据提供有关包含在数据对象中的数据的信息。
在 SDO 编程模型中，数据对象是以 commonj.sdo.DataObject Java 接口定义表示的。该接口包含方法定义，通过方法定义，客户机可以获取和设置与数据对象相关联的属性。SDO 体系结构中的另一个重要概念是数据图，它是封装一组数据对象的结构。对于包含在数据图中的顶层数据对象，可以从根数据对象开始遍历引用来到达所有子数据对象。数据图中的另一个重要功能是更改摘要，用于记录关于在处理过程中已经更改的图中的数据对象和属性的信息。
WebSphere Process Server 通过业务对象实现 SDO 规范。SCA 组件可以通过传递业务对象来交换数据，如图 3.3.5 所示。
图3.3.5 WebSphere Process Server 业务对象
3.3.3 用SCA解决案例
1. 创建 SCA 模块。
2. 创建业务对象。
3. 定义服务接口。
4. 生成组件并提供实现。
3.4 ESB服务实现
IBM WebSphere Application Server V6介绍了新的消息传递引擎，它包括许多构建企业服务总线必须的功能特性。
3.4.1 Messaging Resources 提供ESB 功能
WebSphere Application Server V6有用Java编写的全新的消息传递引擎。从J2EE角度看，该引擎成为应用程序服务器的缺省JMS提供程序。任何运用J2EE 消息传递的应用程序组件（例如，消息驱动bean）都能够运用这一引擎。
WebSphere V6 Messaging Resources 支持排队、发布/预订、以及Web 服务，并且在这种情况下为一些关键的消息传递和交互模式提供平台。这样就建立了"集成总线"的概念；消息产生者和消息消费者之间通过与总线交互进行通信，而不是彼此直接通信。这一级别的间接寻址能够在不影响应用程序组件的情况下使集中管理与监控功能结合在一个局部实体中。
新平台的重要特性就是使用各种协议向总线发送消息以及从总线接收消息。例如，在HTTP上消息能够作为基于SOAP协议的Web服务请求消息发送到总线上。接下来总线可以将消息转发至JMS消费者，例如消息驱动bean。消息的消费者和生产者因此完全降低了耦合度，包括消息以及传输协议在内。这样的耦合度的降低是ESB 的核心优点。
提供支持的各种协议以及那些协议的格式转换是通过使用公用信息表示法而受到支持的，消息在流入总线时被转换为信息表示法。然而，在协议层和应用层常常需要其它形式的转换。例如，消费者也许将订单号称为PO_NUM，而生产者也许将其称之为PurchaseOrderNumber，所以必须编写提供那种转换的定制转换。
3.4.2 三种核心组件：总线，目的地，以及中介
位于其核心位置，消息传递引擎由三种主要组件组成：
总线，充当消息的主要传输机制。消息的消费者和生产者并不直接交换消息；他们从总线上发送和接收消息。总线可分布在许多处理器和机器上时，应用程序与单总线实体进行交互。管理员也可以配置一些单独应用程序的总线实例。
每条总线包括目的地列表。目的地是每一条发送到总线上的消息的逻辑目标。消息的发送端与接收端就这样区分开的：消息发送到目的地，将从接收端接收。WebSphere V6 Messaging Resources提灵活的消息传递支持，包括了发送关于不同目的地的不同质量服务的能力。重要的是，在接收端没有消费消息之前也能够将消息从一个目的地路由到另一个目的地。这样使得无需影响发送端和接收端就可以将消息的路径选择逻辑封装到总线中去。这一功能能够实现基于SOA的ESB的主要特性之一：分离业务。消息的处理(路由选择)是通过总线做到的，并且没有扰乱任何业务逻辑。
第三种组件，中介，有助于分离业务。中介是经常与目的地相联系的一部分代码。中介代码在遍历目的地时对消息产生影响。
中介中两种最普通的功能：
（1） 将信息数据从一种消息内容格式转换为另一种。如果消息的发送端和接收端支持的消息格式不完全相同，可以编写中介来完成必要的转换运用。
（2） 进行路由判定。中介能够读入消息的内容，基于这一内容，将消息路由到不同的目的地。
目的地和中介的组合让您可以当消息在集成总线中传播时管理消息，从而为构建ESB 提供重要功能。
3.4.3 Web 服务
Web 服务技术全部是关于应用程序之间交换消息的，因此WebSphere V6 Messaging Resources对Web服务的支持很有意义。消息发送者能够很容易地成为Web服务客户机/请求程序，并且消息的消费者可以成为Web服务的提供程序。
WebSphere Application Server管理控制台中支持的WebSphere V6 Messaging Resources拥有享用总线中服务和生成构件（专用侦听器和目的地）的Web服务描述语言（WSDL）文件的向导。这些向导能够接收来自Web服务请求程序的Web服务消息及向Web服务提供程序发送Web服务消息。
HTTP上的SOAP以及JMS Web服务上的SOAP都受到支持。目的地是用于表现Web服务客户机以及总线中的提供程序。中介能够影响Web服务消息。因此，WebSphere V6 Messaging Resources使得Web服务消息能够得到管理与监听，包括动态路由选择以及转换方法，在总线中仅仅作为另一种消息类型。
此外，此处的目的是降低服务请求程序和提供程序的耦合度，所以附加的服务及管理质量能够应用于总线。总线上的Web服务可能就像各种其它平台的Web服务一样被调用。变化在于SOAP 请求消息将会发送到总线上的目的地，而不是直接发送到服务。
从开发的角度看，客户机无法分辨出差别。客户机所需的唯一变化就是将URL地址从真实的服务改变为总线中的服务目的地。服务提供程序无需任何改变，并且服务可能是经由总线或直接通过Web服务客户机调用。服务中的业务逻辑并没受到影响。
3.4.4 多重协议，多重API
总线目的地起到了虚拟连接到总线上的资源的主要方法的作用。这包括使用多重协议及API访问那些资源的能力；消息能够由一个协议发送到总线并且经由另一个协议可以获得其消费者。
客户机应该不必分辨出资源的定位，与什么协议彼此相应，以及什么API应该用于向其发送消息。这一切都能通过总线得以解决。在总线上配置作为目的地的资源使得这一目标有实现的可能。使用HTTP上的SOAP可以将消息发送到目的地，只是命名一些可能性。在任意的协议上消息的消费者也能够接收相同的消息，与其怎样到达总线无关。
3.4.5 通用的消息格式
在总线中以协议独立的方式管理消息需要也是协议独立的数据表示格式。对于WebSphere消息传送引擎来说，按照这样的格式选择服务数据对象（SDO）。
SDO描述了以独立于数据源的方式表示数据的方法。消息的SDO模型用于表示关于消息的数据，例如长度、格式、头信息等等。每一条到达总线的信息都转换成SDO对象图。总线中的中介使用SDO程序设计模型操纵消息中的数据。
一切SDO的使用都是关于协议独立的。总线没有将消息的内容转换成规范数据模型；如果有必要进行标准化，可以编写定制中介。
3.4.6 案例实现
1．创建总线
图3.4.1 WebSphere Application Server 管理控制台中的新总线
总线需要被分配到运行着一个或多个应用程序的服务器上。对于大多数开发工作来说，创建并把单独的总线成员分配到总线上。当添加了总线成员，该 WebSphere 实例中将会创建消息传递引擎，它拥有自己的消息数据存储。
2. 设置 Web 服务
为了能够接收 Web 服务请求、将消息转换为中介中的 SOAP 消息、以及发送Web 服务请求，WebSphere Messaging Resources 要求某些设置来启用总线。服务集成总线的 Web 服务特征在WebSphere Application Server V6 信息中心中称为 SIBWS。
WebSphere Messaging Resources 将所有输入的消息转换为服务信息对象（SDO）。SDO 存储库用于存储 WSDL 定义并且 SIBus 将这些定义用作 Web 服务支持的一部分。因此，需要创建 SDO 存储库。
此外，为了总线可以从客户端接收 Web 服务请求，总线需要用端点监听器进行配置；端点监听器通过特定的端口监听输入的 Web 服务消息。为 HTTP 上的 SOAP 和 JMS 上的 SOAP 设置的端点监听器。为了启用总线发送 Web 服务请求，总线必须以资源适配器配置。
(1) 安装 SDO 存储库
wsadmin -f installSdoRepository.jacl -createDb node1 server1
(2) 安装 SIbus Web 服务资源适配器
至于充当 Web 服务请求程序的总线，向接收程序发送 Web 服务消息，它必须以资源适配器来配置。设置 SIBWS 应用程序和安装资源适配器的脚本是由 WebSphere Application Server 提供的
wsadmin -f ../util/sibwsInstall.jacl INSTALL_RA -installRoot "C:/Program Files/IBM/WebSphere/AppServer" -nodeName node1
(3) 安装以及配置端点监听器
端点监听器需要对于每一个希望使用的协议进行安装和配置，这样做是为了将 Web 服务请求接收到总线上。为了这些端点监听器可以运行，需要安装 SIBWS 应用程序。
wsadmin -f ../util/sibwsInstall.jacl INSTALL -installRoot "C:/Program Files/IBM/WebSphere/AppServer" -serverName server1 -nodeName node1
脚本同安装资源适配器所用的是相同的，sibwsInstall.jacl，用于安装端点监听器，只是以不同的参数。在安装之后，每个端点监听器都需要管理控制台中的附加的配置。为每个协议设置了两个端点监听器。可以将一个用于将来自外部客户端的请求纳入总线，并且将第二个用于来自内部客户端的请求。
wsadmin -f ../util/ sibwsInstall.jacl INSTALL_HTTP -installRoot "C:/Program Files/IBM/WebSphere/AppServer" -serverName server1 -nodeName node
图3.4.2 管理控制台中的Enterprise Applications
图3.4.3 端点监听器的配置
3. SIBus Web 服务
WebSphere V6 Messaging Resources 支持从SOAP 客户机接收SOAP 请求，并且能够使用目的地、中介和附加总线构件将SOAP 请求发送到SOAP 提供者。系统集成总线(SIBus) 允许将Web 服务消息——包括动态路由和变换——作为另一种消息类型。将ESB 用于Web 服务的目的在于将服务的请求者和提供者分离，这样就可以将服务和管理应用于总线。对Web 服务的编程模型没有任何影响；任何SOAP 请求者或提供者都可以用于总线。
SIBus Web 服务支持由入站服务（处理发送到总线中的SOAP 消息）和出站服务（将SOAP 消息发送到Web 服务提供者）组成。WebSphere Application Server 管理控制台中的SIBus 支持有向导，可以将Web 服务描述语言(WSDL) 文件用于服务和生成入站和出站服务的构件。在Web 服务中，WSDL是定义和处理消息的关键。
（1）出站服务
出站服务表示总线上的外部服务，可以通过它将SOAP 消息从总线发送到Web 服务提供者。使用出站服务，总线可以在任何平台上调用根据SOAP 标准实现且符合WS-I 基本概要的服务。总线中的出站服务充当外部Web 服务的请求者。
为了定义出站服务，需要运行WebSphere 管理控制台中的入站服务创建向导，并为外部服务提供一个WSDL 文档。该向导创建一个对应于WSDL 中的服务元素的出站服务目的地，以及WSDL 中每个端口的出站端口。出站服务目的地表示总线上的Web 服务。其他目的地将SOAP 消息发送到该出站服务目的地，以便通过出站端口目的地发送到Web 服务提供者。
总线支持出站服务的三个协议：
SOAP/JMS
SOAP/HTTP
用于EJB 的RMI/IIOP。
服务的WSDL 文件具有每个受支持的协议的绑定和端口定义。如果多个端口可用，则在出站服务向导中指定缺省端口，并且为路由中介提供逻辑以选择用于消息实例的端口。
在图中：
SOAP 消息将发送到服务目的地(Service Destination)。
服务目的地将其路由到端口目的地(Port Destination)。
端口目的地将其发送到正在使用的协议的总线Invoker 模块。
总线Invoker 模块通过WSDL 文件中的端点地址将SOAP 消息发送到Web 服务提供者。
图3.4.4 出站服务
（a）首先，要在总线中选择创建出站服务。
图3.4.5 总线配置
（b）然后，定位目标服务WSDL。
图3.4.6 定位目标服务WSDL
（c）接着，要选择一个服务进行处理。
图3.4.7 选择服务
（d）选择端口，它可用作为出站服务的一部分。这里只有一个端口需要检查。如果有多个端口，则有一个或多个端口需要检查。
图3.4.8 选择端口
（e）命名出站服务目的地。为将要创建的服务、服务目的地和端口目的地提供名称。如果有多个端口，则在这一步定义缺省端口和端口选择中介。
图3.4.9 命名出站服务目的地
（f）为端口目的地选择指派的总线成员。在我这个案例中，每个端口目的地只有一个指派的成员。
图3.4.10 为端口目的地选择指派的总线成员
出站服务的创建已经完成了，已经创建了两个目的地，一个是出站服务目的地，一个是出站端口目的地。
图3.4.11 出站服务
图3.4.12 目的地
现在我们可以将符合PackageTrackingService WSDL 规范的SOAP 消息发送到PackageTrackingOutboundService 目的地，然后该消息将通过PackageTrackingOutboundPort 端口目的地路由到外部服务提供者。
（2）入站服务
入站服务接受从SOAP 请求者发送到总线内的SOAP 消息。可以像调用来自各种平台的任何其他Web 服务一样调用总线服务。入站服务使用总线上的服务目的地（只是一个充当入站服务目的地的队列目的地）。
需要运行WebSphere 管理控制台中的出站服务创建向导，并提供一个WSDL 文件和一个现有的目的地。每个入站服务对应于WSDL 文档中的一个服务元素。。
通过为Web 服务准备好总线，包括安装和配置端点侦听器。端点侦听器为总线上要调用的服务提供物理位置。支持SOAP/HTTP 和SOAP/JMS，并且为每个协议提供了两个侦听器。这可以为从Intranet 到Internet 的消息配置不同的端点侦听器，可配置客户用来将数据发送到公司的HTTP 端点侦听器。每个端点都有一个不同的URL，请求者可将其用于协议。
在入站服务向导中，指定服务将使用哪一个端点侦听器。为每个选定的端点侦听器创建入站端口。在WSDL 文档中，入站端口等同于端口元素。
如图中：
Web 服务客户机将SOAP 消息发送到端点侦听器(Endpoint Listener)。
端点侦听器使用入站端口和入站服务(Inbound Service) 定义的信息将消息发送到与Inbound Service 相关的服务目的地(Service Destination)。
如果服务WSDL 有一个已定义的响应，则应答消息(Reply Message) 将会发送到与端点侦听器相关的预定义应答队列。
端点侦听器将等待应答消息，并将其发送回客户机。
图3.4.13 出站服务
实现入站服务，需要提供WSDL 文档和目的地。入站服务将使用WSDL 文档中的portType 和绑定来生成一个新的WSDL 文档，该文档具有所提供的portType、绑定以及在向导中选择的端点侦听器的端点地址。必须定义好入站服务将“使用”的目的地。
在这个场景中，我们需要选择是将出站Web 服务目的地重新用于入站服务目的地，还是创建一个新的入站服务目的地。如果选择将出站目的地重新用于入站服务，那么消息将自动从入站服务流向出站服务。但是，我们只能为每个目的地部署一个中介。
也可选择创建一个单独的队列目的地，将入站服务指派给该目的地，并将入站服务目的地转发路由路径置于出站服务目的地。就有了入站服务和出站服务的单独中介。此外，这一设计还更明确地分离了所涉及的服务。分离服务的设计正是场景所要实现的。
（a）首先，选择服务目的地。
图3.4.14 选择服务目的地
（b）从模板WSDL 中选择服务。
图3.4.15 从模板WSDL 中选择服务
（c）命名入站服务并选择端点侦听器。
（d）定义发布属性。
这样我们就能够在入站服务中看到新创建的服务。
图3.4.16 入站服务
（4） 路由及发布入站服务。
（a）入站服务需要将SOAP 请求路由到出站服务。使用入站服务的转发路由路径来完成这一步，可以通过声明的方式在管理控制台进行设置：
图3.4.17 默认路由路径
（b）入站服务向导为入站服务生成了一个新的WSDL 文件，客户机将使用该文件来调用总线上的服务。该WSDL 在总线上组合入站服务的portType 和端点侦听器的绑定和端点地址。这里将为入站服务导出WSDL：
本文转自
http://soa.5d6d.com/thread-57-1-1.html
使用IBM技术解决SOA集成体系结构 使用IBM技术解决SOA集成体系结构
使用IBM技术解决SOA集成体系结构
一．SOA体系结构
SOA 体系结构形式目的是提供企业业务解决方案，这些业务解决方案可以 按需扩展或改变。SOA 解决方案由可重用的服务组成，带有定义良好且符合标准的已发布接口。SOA 提供了一种机制，通过这种机制，可以集成现有的遗留应用程序，而不管它们的平台或语言。
从概念上讲，SOA 中有三个主要的抽象级别：
操作：代表单个逻辑工作单元的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA 操作与面向对象的方法相比。都有特定的结构化接口，并且返回结构化的响应。完全同方法一样，特定操作的执行可能涉及调用附加的操作。
服务：代表操作的逻辑分组。例如，如果我们将 CustomerProfiling视为服务，则 按照电话号码查找客户、 按照名称和邮政编码列出顾客和 保存新客户的数据就代表相关的操作。
业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。业务流程的例子有： 接纳新员工、 出售产品或服务和 完成订单。业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程编排。典型的情况是调用已编排服务来响应业务事件。
二．IBM的SOI思想概述
2.1企业集成的新方法SOI
以服务为中心的集成，简称 SOI。 它可以定义为：在以服务为中心的体系架构（SOA）中，通过服务的交互来集成各企业的 IT 资源，如分布的应用或者数据，帮助企业 IT 部门将已有但老旧而不灵活的系统集成起来，释放其中功能或数据为可重用的服务与业务流程。
SOI 继承和发展了传统的 EAI，比较而言，SOI 的好处在于:
定义良好而又基于标准的接口 - 服务的描述易于理解，而且标准一致
实现技术和位置的透明 - 提供服务功能的应用，它的位置以及所使用的实现技术被接口所屏蔽，事实上，不需要一个固定的服务提供者
灵活性 - 只要服务的接口不变，服务的提供者和服务的使用者都可以变化而不影响彼此，从而将变化带来的影响减少到了最少
重用能力
渐进式集成 - 在 SOI 中，通过将若干已有系统的相关功能转化为服务来进行集成。随着这些项目的进行，可重用的服务越来越多，最终，新的集成需求将绝大多数可以通过已有的服务来完成。所以，我们可以从当前重要的集成需求开始来封装已有系统的功能和开发必要的新服务，以渐进的方式逐步地扩展到整个企业范围内的集成。更重要的是，由于服务的灵活性，即使已有系统迁移到新的技术平台，甚至是被替代，都不会影响到依赖于这个应用所提供功能的那些应用，从而保证了集成对变化的适应能力，使得业务灵活性有一个坚实的基础。这也意味着从传统规模大、投入大、周期长、见效慢、风险高、专有技术，转向小步快跑、见效迅速、风险低、基于标准的集成方式。这对于如今面对业务需求快速变化的 IT 机构来说，SOI 在投入和工程方面的好处，是非常吸引人的
2.2 SOI解决方案
IBM的 Websphere 业务集成参考架构(见图1，以下称参考架构)是典型的以服务为中心的企业集成架构。
以服务为中心的企业集成采用"关注点分离"(Separation of Concern)的方法规划企业集成中的各种架构元素，同时从服务视角规划每种架构元素提供的服务，以及服务如何被组合在一起完成某种类型的集成。这里架构元素提供的服务既包括狭义的服务（WSDL描述），也包括广义的服务（某种能力）。从服务为中心的视角看来，企业集成的架构按图1所示的方式划分为六大类：
业务逻辑服务(Business Logic Service)：包括用于实现业务逻辑的服务，和执行业务逻辑的能力。这其中包括业务应用服务(Business Application Service)、业务伙伴服务(Partner Service)以及应用和信息资产(Application and Information asset)。
控制服务(Control Service)：包括实现人(people),流程(process)和信息(information)集成的服务，以及执行这些集成逻辑的能力。
连接服务(Connectivity Service)：连接服务通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。
业务创新和优化服务(Business Innovation and Optimization Service)：用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的市场。
开发服务(Development Service)：贯彻整个软件开发生命周期的开发平台，从需求分析，到建模、设计、开发、测试，维护全面的工具支持。
IT服务管理(IT Service Management)：支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。
2.2.1 连接服务 - 企业服务总线
企业服务总线(Enterprise Service Bus)，简称ESB, 是过去消息中间件的发展，ESB 采用了"总线"这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态地互联互通。
ESB 的基本特征和能力包括：描述服务的元数据和服务注册管理；在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式，异步模式等；发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。
ESB 所提供的基于标准的连接服务，将应用中实现的功能或者数据资源转化为服务请求者能以标准的方式来访问的服务；当请求者来请求一个服务时，ESB 中这种中介转化过程可能简单到什么也没有，也可能要很复杂的中介服务支持，包括动态地查找、选择一个服务，消息的传递、路由和转换、协议的转换。这种中介过程，是 ESB 借助于服务注册管理以及问题域相关的知识（如业务方面的一些规则等）自动进行的，不需要服务请求者和提供者介入，从而实现了解耦服务请求者和提供者的技术基础，使得服务请求者不需要关心服务提供者的位置和具体实现技术，双方在保持接口不变的情况下，各自可以独立地演变。
所以，ESB 采用总线结构模式简化了应用之间的集成拓扑，通过源自实践的模式，提供了基于标准的通用连接服务，使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互，从而在不同层次上使得SOI 解决方案是一个松散耦合、灵活的架构。
ESB 是一种架构模式，不能简单地等同于特定的技术或者产品，但实现 ESB 确实需要各种产品在运行时和工具方面的支持。IBM 有很好的产品支持，运行时支持包括 WebSphere ESB 和 WebSphere Message Broker；而工具方面 IBM 则有 WebSphere Integration Developer，支持用户以图形界面的方式来完成相关的开发任务，如发布服务，使用各种模式，转换消息，定义路由等等。
2.2.2 业务逻辑服务
整合已有应用 - 应用和信息访问服务。已有应用和信息是实现业务逻辑和业务数据的重要资产。通过集成已有的应用和信息将可以在已有企业系统上实现更多增值服务，所以集成已有应用和信息是企业集成中重要的一环。
以服务为中心的企业集成通过应用和信息访问服务(Application and Information Access Service)来实现对已有应用和信息集成。它通过各种适配器技术将已有系统中的业务逻辑和业务数据包装成企业服务总线支持的协议和数据格式。通过企业服务总线，这些被包装起来的业务逻辑和数据就可以方便的参与上层的业务流程，从而已有应用系统的能力可以得以继续发挥。这里的已有应用包括遗留应用、预包装的应用和各种企业数据存储。在参考架构中，主要有两类访问服务：
可接入服务(On-Ramp Service): 通过各种消息通信模式(单向、请求/应答和轮询)将业务逻辑和业务数据包装成企业服务总线可以访问的功能。
事件发现服务(Event Detect Service) : 提供事件通知服务将已有应用和数据中的变化通过事件框架发布到企业服务总线上。
整合新开发的应用 - 业务应用服务。和已有应用和数据类似，新开发的应用也作为重要的业务逻辑成为企业集成的目标。以服务为中心的企业集成通过业务应用服务(Business Application Service)实现新应用集成。一方面业务应用服务帮助程序员开发可重用、可维护和灵活的业务逻辑组件，另一方面，它也提供运行时的集成提供对业务逻辑组件的自治管理。在参考架构中，有三类业务应用服务：
组件服务(Component Service)：为可重用的组件提供应用的运行时容器管理服务，如对象持久化、组件安全管理和事务管理等。
核心服务(Core Service)：提供运行时的服务，包括内存管理、对象实例化和对象池、性能管理和负载均衡、可用性管理等。
接口服务(Interface Service)：提供和其他企业系统集成的接口，如其他企业应用，数据库、消息系统和管理框架。
整合客户和业务伙伴（B2C/B2B）－伙伴服务。以服务为中心的企业集成通过伙伴服务提供与企业外部的B2B的集成能力。因为业务伙伴系统的异构性，伙伴服务需要支持多种传输协议和数据格式。在参考架构中，提供如下服务：
社区服务(Community Service): 用于管理和企业贸易的业务伙伴，支持以交易中心(Trade Hub)为主的集中式管理和以伙伴为中心的自我管理。
文档服务(Document Service)：用于支持和业务伙伴交换的文档格式，以及交互的流程和状态管理，支持主流的RosettaNet、EDI和AS1/AS2等。
协议服务(Protocol Service)：为文档的交互提供传输层的支持，包括认证和路由等。
2.2.3 控制服务
数据整合－信息服务。企业数据的分布性和异构性是应用系统方便访问企业数据和在企业数据之上提供增值服务的主要障碍。数据集成和聚合技术在这种背景下诞生，用于提供对分布式数据和异构数据的透明访问。
以服务为中心的企业集成通过信息服务提供集成数据的能力，目前主要包括如下集中信息服务：
联邦服务(Federation Service): 联邦服务提供将各种类型的数据聚合的能力，它既支持关系型数据，也支持象XML数据、文本数据和内容数据等非关系型数据。同时，所有的数据仍然在自己本身的方式管理。
复制服务(Replication Service)：复制服务提供远程数据的本地访问能力，它通过自动的实时复制和数据转换，在本地维护一个数据源的副本。本地数据和数据源在技术实现上可以是独立的。
转换服务(Transformation Service)：转换服务用于数据源格式到目标格式的转换，可以是批量的，或者是基于记录的。
搜索服务(Search Service)：提供对企业数据的查询和检索服务，既支持数据库等结构化数据，也支持象PDF等非结构化数据。
流程整合- 流程服务。企业部门内部的IT系统通过将业务活动自动化来提高业务活动的效率。但是这些部门的业务活动并不是独立的，而是和其他部门的活动彼此关联的。勿容置疑，将彼此关联的业务活动组成自动化流程可以进一步提高业务活动的效率。业务流程集成正是在这一背景下诞生的。
以服务为中心的企业集成通过流程服务来完成业务流程集成。在业务流程集成中，粒度的业务逻辑被组合成业务流程。流程服务提供自动执行这些业务流程的能力。在参考架构中，流程服务包括如下内容：
编排服务(Choreography Service): 编排服务通过预定义的流程逻辑控制流程中业务活动的执行，并帮助业务流程从错误中恢复。
事务服务(Transaction Service)：事务服务用于保证流程执行中的事务特性(ACID)。对于短流程，通常采用传统的两阶段提交技术，对于长流程，一般采用补偿的方法。
人工服务(Staff Service)：人工服务用于将人工的活动集成到流程中，一方面它通过关联的交互服务使得人工可以参与到流程执行中，另一方面它需要管理由于人工参与带来的管理任务如：任务分派，授权和监管等。
用户访问整合 - 交互服务。将适当的信息，在适当的时间，传递给适当的人是一直是信息技术追求的目标。用户访问集成是实现这一目标的重要一环，它负责将信息系统中的信息传递给客户，不管它在那里，它以什么样的设备接入。
以服务为中心的企业集成通过交互服务来实现用户访问集成。参考架构中的交互服务包括如下类型：
交付服务(Delivery Service): 交付服务提供运行时的交互框架，它通过各种技术支持同样的交互逻辑可以在多种方式(图形界面、语音和普及计算消息)和设备(桌面、PDA、无线终端等)上运行，比如通过页面聚合和标签翻译使得同一个Portlet可以在桌面浏览器和PDA浏览器上展现。
体验服务(Experience Service): 通过用户为中心的服务增强用户体验, 其中的技术包括：个性化、协作、单点登录等。
资源服务(Resource Service): 提供运行时交互组件的管理，如安全配置、界面皮肤等。
三．案例分析
3.1系统架构设计
3.1.1 案例背景
凤凰医疗设备有限公司是一家专门制造和营销专业医疗器械和实验仪器仪表等仪器的民营企业，其购销客户和网络遍布全国各地。凤凰成立于2000年。
2004年凤凰公司引进并在公司内部成功实施了某ERP系统（部署在凤凰企业内部的Web应用），主要用于凤凰公司的财务管理，其中包括产品库存及订单管理等。ERP的实施大幅度地提高了公司的管理效率。
随着公司业务规模的扩大和产品质量的提升，凤凰公司的客户数量越来越大。凤凰公司不得不考虑使用客户关系管理系统（CRM）来进一步提高销售人员的工作效率。于是，2005年8月份凤凰公司引进并成功应用了某客户关系管理系统（CRM）。CRM通过订阅的方式来提供客户关系管理服务，凤凰的销售人员在任何时间和地点只需要通过普通的Web浏览器就可以使用和管理客户及销售信息，包括客户信息，商机，业务机会，以及客户及销售信息分析图表等。
现在凤凰公司的财务和销售人员分别在ERP和CRM系统上工作，工作效率有很大提高。但是公司目前也面临挑战：一方面，ERP和CRM中分别维护产品和客户信息，而公司规定ERP必须作为这些信息的主数据源，ERP中的这些信息需要随时同步到CRM中去；另一方面，CRM中维护的业务机会和ERP中维护的销售订单有着非常紧密的关系，凤凰公司希望能够把业务机会和销售订单有效地整合起来，而进一步提高业务运作的效率。
3.1.2 业务环境分析
本文以销售订单管理系统的业务机会管理流程为例，说明如何用以服务为中心的企业集成技术一步一步解决该公司面临的企业集成问题。
业务机会管理是指与潜在客户进行谈判确定业务机会，创建销售订单请求，发送到ERP系统。首先销售人员开始进行客户查询处理发现潜在客户，否则将建立新客户并将所得的客户信息存储在CRM中的客户管理中。然后从ERP系统中提取产品相关信息进行产品选择，再由客户信息和产品信息生成业务机会。业务机会的信息会存储在CRM系统中，并随时由销售人员更改业务机会的信息和业务机会的状态。当业务机会成功时，业务机会中的信息会通过订单请求的方式，发到ERP系统中，等待财务人员进行处理。
图 3.1.1 业务机会流程图
图3.1.1是一个业务机会管理的业务流程图。由图可见，业务机会流程依次有下列活动：
（1） 从CRM中获取客户信息；（自动活动）
（2） 从ERP中获取产品信息；（自动活动）
（3） 生成业务机会信息；（自动活动）
（4） 业务机会谈判；（人工活动）
（5） 生成销售订单请求；（自动活动）
（6） 发送销售订单请求给ERP系统；（人工活动）
实际上，如果对每个业务活动划分更细的话我们将得到更多的活动。可以更多的考虑，当CRM中有该客户信息时，直接使用客户信息建立业务机会，当CRM中不存在该客户信息时，要求创建客户存入CRM中，然后再进行业务机会的创建。因此，这里可以将CRM的客户信息管理服务用到流程中。以服务为中心的企业集成通过服务建模过程发现这些可重用的服务，并通过流程模型将这些服务组装在一起。
3.1.3 服务建模
IBM推荐使用组件业务建模(Component Business Model)和面向服务的建模和架构(Service-Oriented Model and Architecture)两种方法学建立业务的组件模型，服务模型和流程模型。
服务模型是服务建模的主要结果。业务机会管理相关的服务模型如图3.1.2所示。和业务机会流程相关的有三个业务组件：
图3.1.2 业务机会管理相关模型
销售订单管理（Business Chance Management）:负责业务机会管理，销售订单管理以及库存管理等业务活动。
CRM客户管理（CRM）：负责客户信息的管理。
ERP产品信息管理（ERP Products Management）：负责产品相关信息的管理。
这三个业务组件分别输出如下服务：
1) 业务机会流程: 由销售订单管理输出，主要用于业务机会管理流程的编排；
2) 业务机会信息生成: 由销售订单管理输出，主要用于生成由客户信息和产品信息生成的业务机会信息；
3) 业务机会谈判：由销售订单管理输出，用于与客户协商确定业务机会内容；
4) 销售订单请求信息生成：由销售订单管理输出，用于生成由业务机会得到的销售订单请求信息；
5) 发送销售订单请求信息：由销售订单管理输出，用于向ERP系统发送销售订单请求，同时通知财务人员进行销售订单处理；
6) 获取产品信息：由ERP产品信息管理输出，用于获取产品信息列表；
7）获取客户信息：由CRM客户信息管理输出，用于获取客户信息；
8）创建客户信息：由CRM客户信息管理输出，用于创建客户信息；
在服务建模确定系统相关的服务输出后，我们还需要确定服务在当前环境下的实现方式。在我们的案例中，获取产品信息和获取客户信息被实现为信息服务，业务机会流程被实现为流程服务，通过BPEL4WS方式实现；业务机会信息生成、销售订单请求信息生成被实现为业务应用服务；创建客户信息、业务机会谈判和发送销售订单请求信息服务都是Staff Service。
3.1.4 IT环境分析
IT环境分析是调查现有应用技术特点的重要手段。在我们的示例中，IT环境分析主要用于调查现有应用，为决定服务模型中服务的实现方式提供技术依据。同时，它也是架构设计的重要依据。
在案例中，信息服务以及业务应用服务都被假设为已经设计好的Web服务，我们只需要根据流程调用Web服务方式实现。所以，这里弱化了一些企业服务集成的概念。主要技术实现重点放在了构造组件模块、Portal实现流程服务及人工交互服务、ESB实现总线调用Web服务方面。
3.1.5 高层架构设计
根据需求和设计阶段的业务模型和现有IT环境调研结果，业务机会管理的高层架构被设计了出来。如图：
图3.1.3业务机会管理系统架构
（1） 流程服务
业务人员使用BPEL来进行流程编排，创建需要的业务流程。然后通过该流程可以从Web服务中得到需要的服务，完成业务功能。这样，使业务的变更和扩展得到很好的解决。Process Server为流程编排和选择提供了运行的环境。通过Process Server的管理我们能够选择适合的业务去完成系统功能。
使用IBM WeSphere Business Integration Modeler, Advanced Edition 进行业务建模和编排BPEL4WS业务流程,生成描述文件,在 IBM Websphere Process Server中执行。
（2） 交互服务
分为两种，一类是与业务流程交互，触发流程开始运行；一类是人工服务，通过Portal展示让人工服务参与到流程的交互中去，比如我们的创建客户信息以及业务机会谈判都是需要通过用户使用Portal页面来进行与人工任务的交互来完成需要的业务流程。
在Portal展示中使用IBM Rational Application Developer for Websphere Software进行开发,并运行在IBM Websphere Portal Server服务器平台上,为系统提供前台展示和交互服务。
（3） ESB
在设计中的传输服务用来完成服务消息的传输，因为在这个系统中设计的服务是用WSDL进行服务描述的，所以传输服务是用来统一传输协议。这里基本上使用的是SOAP/HTTP协议。
在设计中的中介服务允许动态处理消息传输、动态路由和服务绑定解析服务。当服务消息传递给ESB时，中介服务会通过服务解析对消息进行解析，然后根据解析出来的消息触发信息进行服务路由，以完成动态路由及消息传输。所以在服务定义时，我们要考虑定义服务的触发信息以符合ESB的功能。
本系统底层使用WebSphere V6 Messaging Resources作为消息传递引擎,使用IBM WebSphere Application Server 作为ESB服务器,支持ESB的扩展功能.
3.1.6 开发角色
表3.1.1 角色划分和工具支持
角色 开发方法和工具 任务
业务分析员 WebSphere Integration Developer 进行流程建模
CBM
架构人员 Rational Software Architect 利用SOMA进行服务建模
SOMA 系统架构设计和建模
整合开发人员A WebSphere Integration Developer 服务组件建模
整合开发人员B WebSphere Portal Server Toolkit Portlet开发
整合开发人员C WebSphere Process Server 部署流程，人工任务及
服务组件
整合开发人员D WebSphere Application Server 建立服务总线
3.2利用portal执行业务流程与人工任务
3.3 SCA服务模型
3.3.1 SCA定义
IBM提出了一种新的服务组件模型。这是一种全新的、跟语言无关的编程模型，它提供了一种统一的调用方式，从而使得客户可以把不同的组件类型，比如EJB, 流程组件，人工交互组件等都可以通过一种标准的接口来封装和调用。结合SDO的数据模型，这种服务组件的编程模型可以大大的简化客户的编程，提高应用的灵活性，这就是面向服务组件的架构（Service Component Architecture，SCA）。
这种方式使得客户的企业应用具有良好的分层架构，能够很好的分离应用的业务逻辑和IT逻辑，不但易于应用的构建，也易于应用的更改和部署。
3.3.2 SCA中的基本概念
（1）服务组件
服务组件是SCA中的基本组成元素和基本构建单位，也是具体实现业务逻辑的地方。我们可以非常容易地把传统的服务流程，无状态会话BEAN等包装成SCA中的服务组件。 SCA服务组件的主要接口规范是基于WSDL的，为了给Java编程人员提供一个比较直接的接口，SCA的部分服务组件也提供了Java接口。因此，使用服务组件的客户端可以选择使用WSDL接口或Java接口。
如图所示，服务组件提供给别的服务调用的入口叫Interface（接口）。而服务组件本身可能也需要调用别的服务，这个调用出口叫Reference（引用）。无论是接口还是引用，其调用规范都是WSDL或Java接口。
图3.3.1 SCA 服务组件接口模型
WebSphere Process Server利用了SCA的这种组件架构，提供了一些与业务联系比较紧密的组件，比如业务流程，人工任务，业务状态机，业务规则等。用户可以直接利用这些服务组件，构建自己的业务流程或其它业务集成的应用。在WebSphere Process Server V6.0.1中，服务组件及SCA在架构中的作用如图 3.3.2所示
图3.3.2 WebSphere Process Server V6.0.1的架构环境
（2）服务模块
服务模块由一个或多个具有内在业务联系的服务组件构成。把几个服务组件放在一个模块中，或者把哪些服务组件放在一起主要取决于业务需求和部署上灵活性的要求。模块是SCA中的运行单位，一个SCA模块背后对应的是一个J2EE的企业应用项目。在WID中构建一个模块就相当于构建一个项目。另外，由于模块是一个单独部署的单元，这给应用的部署带来很大的灵活性。比如，只要保持模块接口不变，我们很容易通过重新部署新的模块而替换原有的业务逻辑，而不影响应用的其它部分。
图3.3.3 服务模块模型
（3）导入和导出
用户实际的应用经常是比较复杂的，因此实际的应用通常需要多个模块才能满足要求，而且这些模块之间又往往存在相互调用的关系。
另外模块中服务组件除了调用别的服务组件之外，也需要调用已有的一些应用，或者是让一些已有的应用来调用模块的服务，而这些应用可能不是基于SCA架构的。为了解决上述问题，在模块中引入了两个端点，一个是导入（Import），它的作用是使得模块中的服务组件可以调用模块外部的服务。另一个是导出（Export），它的作用是使得模块外部的应用可以调用模块中的服务组件。
由于涉及到模块内外的调用，因此需要指定专门的绑定信息。这些绑定信息包括了目标服务或源服务的调用方式，位置信息，调用的方法等。在WebSphere Process Server V6.0中，导入端点提供了四种绑定方式，包括：JMS绑定，Web Service绑定，SCA绑定和无状态会话BEAN的绑定。导出端点提供了三种绑定方式，包括：JMS绑定，Web Service绑定和SCA绑定。对于SCA模块之间的调用，我们可以非常方便的把绑定方式设置为SCA绑定，但是对于非SCA模块与SCA模块之间的调用我们只能选择其它绑定方式。
图3.3.4 SCA导入和导出
（4）数据对象
SCA提供了一个用于定义业务服务的通用模型。服务数据对象 (SDO) 提供了一种用通用模型来表示数据的方法。可以将 SCA 组件组合在一起，并且通过传递 SDO 来以一种中立的方式相互交换数据。SDO 体系结构中的基本概念是数据对象，它是用于存放基元类型的数据或其他数据对象的数据结构。数据对象还存放对元数据的引用，元数据提供有关包含在数据对象中的数据的信息。
在 SDO 编程模型中，数据对象是以 commonj.sdo.DataObject Java 接口定义表示的。该接口包含方法定义，通过方法定义，客户机可以获取和设置与数据对象相关联的属性。SDO 体系结构中的另一个重要概念是数据图，它是封装一组数据对象的结构。对于包含在数据图中的顶层数据对象，可以从根数据对象开始遍历引用来到达所有子数据对象。数据图中的另一个重要功能是更改摘要，用于记录关于在处理过程中已经更改的图中的数据对象和属性的信息。
WebSphere Process Server 通过业务对象实现 SDO 规范。SCA 组件可以通过传递业务对象来交换数据，如图 3.3.5 所示。
图3.3.5 WebSphere Process Server 业务对象
3.3.3 用SCA解决案例
1. 创建 SCA 模块。
2. 创建业务对象。
3. 定义服务接口。
4. 生成组件并提供实现。
3.4 ESB服务实现
IBM WebSphere Application Server V6介绍了新的消息传递引擎，它包括许多构建企业服务总线必须的功能特性。
3.4.1 Messaging Resources 提供ESB 功能
WebSphere Application Server V6有用Java编写的全新的消息传递引擎。从J2EE角度看，该引擎成为应用程序服务器的缺省JMS提供程序。任何运用J2EE 消息传递的应用程序组件（例如，消息驱动bean）都能够运用这一引擎。
WebSphere V6 Messaging Resources 支持排队、发布/预订、以及Web 服务，并且在这种情况下为一些关键的消息传递和交互模式提供平台。这样就建立了"集成总线"的概念；消息产生者和消息消费者之间通过与总线交互进行通信，而不是彼此直接通信。这一级别的间接寻址能够在不影响应用程序组件的情况下使集中管理与监控功能结合在一个局部实体中。
新平台的重要特性就是使用各种协议向总线发送消息以及从总线接收消息。例如，在HTTP上消息能够作为基于SOAP协议的Web服务请求消息发送到总线上。接下来总线可以将消息转发至JMS消费者，例如消息驱动bean。消息的消费者和生产者因此完全降低了耦合度，包括消息以及传输协议在内。这样的耦合度的降低是ESB 的核心优点。
提供支持的各种协议以及那些协议的格式转换是通过使用公用信息表示法而受到支持的，消息在流入总线时被转换为信息表示法。然而，在协议层和应用层常常需要其它形式的转换。例如，消费者也许将订单号称为PO_NUM，而生产者也许将其称之为PurchaseOrderNumber，所以必须编写提供那种转换的定制转换。
3.4.2 三种核心组件：总线，目的地，以及中介
位于其核心位置，消息传递引擎由三种主要组件组成：
总线，充当消息的主要传输机制。消息的消费者和生产者并不直接交换消息；他们从总线上发送和接收消息。总线可分布在许多处理器和机器上时，应用程序与单总线实体进行交互。管理员也可以配置一些单独应用程序的总线实例。
每条总线包括目的地列表。目的地是每一条发送到总线上的消息的逻辑目标。消息的发送端与接收端就这样区分开的：消息发送到目的地，将从接收端接收。WebSphere V6 Messaging Resources提灵活的消息传递支持，包括了发送关于不同目的地的不同质量服务的能力。重要的是，在接收端没有消费消息之前也能够将消息从一个目的地路由到另一个目的地。这样使得无需影响发送端和接收端就可以将消息的路径选择逻辑封装到总线中去。这一功能能够实现基于SOA的ESB的主要特性之一：分离业务。消息的处理(路由选择)是通过总线做到的，并且没有扰乱任何业务逻辑。
第三种组件，中介，有助于分离业务。中介是经常与目的地相联系的一部分代码。中介代码在遍历目的地时对消息产生影响。
中介中两种最普通的功能：
（1） 将信息数据从一种消息内容格式转换为另一种。如果消息的发送端和接收端支持的消息格式不完全相同，可以编写中介来完成必要的转换运用。
（2） 进行路由判定。中介能够读入消息的内容，基于这一内容，将消息路由到不同的目的地。
目的地和中介的组合让您可以当消息在集成总线中传播时管理消息，从而为构建ESB 提供重要功能。
3.4.3 Web 服务
Web 服务技术全部是关于应用程序之间交换消息的，因此WebSphere V6 Messaging Resources对Web服务的支持很有意义。消息发送者能够很容易地成为Web服务客户机/请求程序，并且消息的消费者可以成为Web服务的提供程序。
WebSphere Application Server管理控制台中支持的WebSphere V6 Messaging Resources拥有享用总线中服务和生成构件（专用侦听器和目的地）的Web服务描述语言（WSDL）文件的向导。这些向导能够接收来自Web服务请求程序的Web服务消息及向Web服务提供程序发送Web服务消息。
HTTP上的SOAP以及JMS Web服务上的SOAP都受到支持。目的地是用于表现Web服务客户机以及总线中的提供程序。中介能够影响Web服务消息。因此，WebSphere V6 Messaging Resources使得Web服务消息能够得到管理与监听，包括动态路由选择以及转换方法，在总线中仅仅作为另一种消息类型。
此外，此处的目的是降低服务请求程序和提供程序的耦合度，所以附加的服务及管理质量能够应用于总线。总线上的Web服务可能就像各种其它平台的Web服务一样被调用。变化在于SOAP 请求消息将会发送到总线上的目的地，而不是直接发送到服务。
从开发的角度看，客户机无法分辨出差别。客户机所需的唯一变化就是将URL地址从真实的服务改变为总线中的服务目的地。服务提供程序无需任何改变，并且服务可能是经由总线或直接通过Web服务客户机调用。服务中的业务逻辑并没受到影响。
3.4.4 多重协议，多重API
总线目的地起到了虚拟连接到总线上的资源的主要方法的作用。这包括使用多重协议及API访问那些资源的能力；消息能够由一个协议发送到总线并且经由另一个协议可以获得其消费者。
客户机应该不必分辨出资源的定位，与什么协议彼此相应，以及什么API应该用于向其发送消息。这一切都能通过总线得以解决。在总线上配置作为目的地的资源使得这一目标有实现的可能。使用HTTP上的SOAP可以将消息发送到目的地，只是命名一些可能性。在任意的协议上消息的消费者也能够接收相同的消息，与其怎样到达总线无关。
3.4.5 通用的消息格式
在总线中以协议独立的方式管理消息需要也是协议独立的数据表示格式。对于WebSphere消息传送引擎来说，按照这样的格式选择服务数据对象（SDO）。
SDO描述了以独立于数据源的方式表示数据的方法。消息的SDO模型用于表示关于消息的数据，例如长度、格式、头信息等等。每一条到达总线的信息都转换成SDO对象图。总线中的中介使用SDO程序设计模型操纵消息中的数据。
一切SDO的使用都是关于协议独立的。总线没有将消息的内容转换成规范数据模型；如果有必要进行标准化，可以编写定制中介。
3.4.6 案例实现
1．创建总线
图3.4.1 WebSphere Application Server 管理控制台中的新总线
总线需要被分配到运行着一个或多个应用程序的服务器上。对于大多数开发工作来说，创建并把单独的总线成员分配到总线上。当添加了总线成员，该 WebSphere 实例中将会创建消息传递引擎，它拥有自己的消息数据存储。
2. 设置 Web 服务
为了能够接收 Web 服务请求、将消息转换为中介中的 SOAP 消息、以及发送Web 服务请求，WebSphere Messaging Resources 要求某些设置来启用总线。服务集成总线的 Web 服务特征在WebSphere Application Server V6 信息中心中称为 SIBWS。
WebSphere Messaging Resources 将所有输入的消息转换为服务信息对象（SDO）。SDO 存储库用于存储 WSDL 定义并且 SIBus 将这些定义用作 Web 服务支持的一部分。因此，需要创建 SDO 存储库。
此外，为了总线可以从客户端接收 Web 服务请求，总线需要用端点监听器进行配置；端点监听器通过特定的端口监听输入的 Web 服务消息。为 HTTP 上的 SOAP 和 JMS 上的 SOAP 设置的端点监听器。为了启用总线发送 Web 服务请求，总线必须以资源适配器配置。
(1) 安装 SDO 存储库
wsadmin -f installSdoRepository.jacl -createDb node1 server1
(2) 安装 SIbus Web 服务资源适配器
至于充当 Web 服务请求程序的总线，向接收程序发送 Web 服务消息，它必须以资源适配器来配置。设置 SIBWS 应用程序和安装资源适配器的脚本是由 WebSphere Application Server 提供的
wsadmin -f ../util/sibwsInstall.jacl INSTALL_RA -installRoot "C:/Program Files/IBM/WebSphere/AppServer" -nodeName node1
(3) 安装以及配置端点监听器
端点监听器需要对于每一个希望使用的协议进行安装和配置，这样做是为了将 Web 服务请求接收到总线上。为了这些端点监听器可以运行，需要安装 SIBWS 应用程序。
wsadmin -f ../util/sibwsInstall.jacl INSTALL -installRoot "C:/Program Files/IBM/WebSphere/AppServer" -serverName server1 -nodeName node1
脚本同安装资源适配器所用的是相同的，sibwsInstall.jacl，用于安装端点监听器，只是以不同的参数。在安装之后，每个端点监听器都需要管理控制台中的附加的配置。为每个协议设置了两个端点监听器。可以将一个用于将来自外部客户端的请求纳入总线，并且将第二个用于来自内部客户端的请求。
wsadmin -f ../util/ sibwsInstall.jacl INSTALL_HTTP -installRoot "C:/Program Files/IBM/WebSphere/AppServer" -serverName server1 -nodeName node
图3.4.2 管理控制台中的Enterprise Applications
图3.4.3 端点监听器的配置
3. SIBus Web 服务
WebSphere V6 Messaging Resources 支持从SOAP 客户机接收SOAP 请求，并且能够使用目的地、中介和附加总线构件将SOAP 请求发送到SOAP 提供者。系统集成总线(SIBus) 允许将Web 服务消息——包括动态路由和变换——作为另一种消息类型。将ESB 用于Web 服务的目的在于将服务的请求者和提供者分离，这样就可以将服务和管理应用于总线。对Web 服务的编程模型没有任何影响；任何SOAP 请求者或提供者都可以用于总线。
SIBus Web 服务支持由入站服务（处理发送到总线中的SOAP 消息）和出站服务（将SOAP 消息发送到Web 服务提供者）组成。WebSphere Application Server 管理控制台中的SIBus 支持有向导，可以将Web 服务描述语言(WSDL) 文件用于服务和生成入站和出站服务的构件。在Web 服务中，WSDL是定义和处理消息的关键。
（1）出站服务
出站服务表示总线上的外部服务，可以通过它将SOAP 消息从总线发送到Web 服务提供者。使用出站服务，总线可以在任何平台上调用根据SOAP 标准实现且符合WS-I 基本概要的服务。总线中的出站服务充当外部Web 服务的请求者。
为了定义出站服务，需要运行WebSphere 管理控制台中的入站服务创建向导，并为外部服务提供一个WSDL 文档。该向导创建一个对应于WSDL 中的服务元素的出站服务目的地，以及WSDL 中每个端口的出站端口。出站服务目的地表示总线上的Web 服务。其他目的地将SOAP 消息发送到该出站服务目的地，以便通过出站端口目的地发送到Web 服务提供者。
总线支持出站服务的三个协议：
SOAP/JMS
SOAP/HTTP
用于EJB 的RMI/IIOP。
服务的WSDL 文件具有每个受支持的协议的绑定和端口定义。如果多个端口可用，则在出站服务向导中指定缺省端口，并且为路由中介提供逻辑以选择用于消息实例的端口。
在图中：
SOAP 消息将发送到服务目的地(Service Destination)。
服务目的地将其路由到端口目的地(Port Destination)。
端口目的地将其发送到正在使用的协议的总线Invoker 模块。
总线Invoker 模块通过WSDL 文件中的端点地址将SOAP 消息发送到Web 服务提供者。
图3.4.4 出站服务
（a）首先，要在总线中选择创建出站服务。
图3.4.5 总线配置
（b）然后，定位目标服务WSDL。
图3.4.6 定位目标服务WSDL
（c）接着，要选择一个服务进行处理。
图3.4.7 选择服务
（d）选择端口，它可用作为出站服务的一部分。这里只有一个端口需要检查。如果有多个端口，则有一个或多个端口需要检查。
图3.4.8 选择端口
（e）命名出站服务目的地。为将要创建的服务、服务目的地和端口目的地提供名称。如果有多个端口，则在这一步定义缺省端口和端口选择中介。
图3.4.9 命名出站服务目的地
（f）为端口目的地选择指派的总线成员。在我这个案例中，每个端口目的地只有一个指派的成员。
图3.4.10 为端口目的地选择指派的总线成员
出站服务的创建已经完成了，已经创建了两个目的地，一个是出站服务目的地，一个是出站端口目的地。
图3.4.11 出站服务
图3.4.12 目的地
现在我们可以将符合PackageTrackingService WSDL 规范的SOAP 消息发送到PackageTrackingOutboundService 目的地，然后该消息将通过PackageTrackingOutboundPort 端口目的地路由到外部服务提供者。
（2）入站服务
入站服务接受从SOAP 请求者发送到总线内的SOAP 消息。可以像调用来自各种平台的任何其他Web 服务一样调用总线服务。入站服务使用总线上的服务目的地（只是一个充当入站服务目的地的队列目的地）。
需要运行WebSphere 管理控制台中的出站服务创建向导，并提供一个WSDL 文件和一个现有的目的地。每个入站服务对应于WSDL 文档中的一个服务元素。。
通过为Web 服务准备好总线，包括安装和配置端点侦听器。端点侦听器为总线上要调用的服务提供物理位置。支持SOAP/HTTP 和SOAP/JMS，并且为每个协议提供了两个侦听器。这可以为从Intranet 到Internet 的消息配置不同的端点侦听器，可配置客户用来将数据发送到公司的HTTP 端点侦听器。每个端点都有一个不同的URL，请求者可将其用于协议。
在入站服务向导中，指定服务将使用哪一个端点侦听器。为每个选定的端点侦听器创建入站端口。在WSDL 文档中，入站端口等同于端口元素。
如图中：
Web 服务客户机将SOAP 消息发送到端点侦听器(Endpoint Listener)。
端点侦听器使用入站端口和入站服务(Inbound Service) 定义的信息将消息发送到与Inbound Service 相关的服务目的地(Service Destination)。
如果服务WSDL 有一个已定义的响应，则应答消息(Reply Message) 将会发送到与端点侦听器相关的预定义应答队列。
端点侦听器将等待应答消息，并将其发送回客户机。
图3.4.13 出站服务
实现入站服务，需要提供WSDL 文档和目的地。入站服务将使用WSDL 文档中的portType 和绑定来生成一个新的WSDL 文档，该文档具有所提供的portType、绑定以及在向导中选择的端点侦听器的端点地址。必须定义好入站服务将“使用”的目的地。
在这个场景中，我们需要选择是将出站Web 服务目的地重新用于入站服务目的地，还是创建一个新的入站服务目的地。如果选择将出站目的地重新用于入站服务，那么消息将自动从入站服务流向出站服务。但是，我们只能为每个目的地部署一个中介。
也可选择创建一个单独的队列目的地，将入站服务指派给该目的地，并将入站服务目的地转发路由路径置于出站服务目的地。就有了入站服务和出站服务的单独中介。此外，这一设计还更明确地分离了所涉及的服务。分离服务的设计正是场景所要实现的。
（a）首先，选择服务目的地。
图3.4.14 选择服务目的地
（b）从模板WSDL 中选择服务。
图3.4.15 从模板WSDL 中选择服务
（c）命名入站服务并选择端点侦听器。
（d）定义发布属性。
这样我们就能够在入站服务中看到新创建的服务。
图3.4.16 入站服务
（4） 路由及发布入站服务。
（a）入站服务需要将SOAP 请求路由到出站服务。使用入站服务的转发路由路径来完成这一步，可以通过声明的方式在管理控制台进行设置：
图3.4.17 默认路由路径
（b）入站服务向导为入站服务生成了一个新的WSDL 文件，客户机将使用该文件来调用总线上的服务。该WSDL 在总线上组合入站服务的portType 和端点侦听器的绑定和端点地址。这里将为入站服务导出WSDL：
本文转自
http://soa.5d6d.com/thread-57-1-1.html
扫一扫
334
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
