WebSphere Integration Developer 指导教程 第3部分.docx
《WebSphere Integration Developer 指导教程 第3部分.docx》由会员分享，可在线阅读，更多相关《WebSphere Integration Developer 指导教程 第3部分.docx（20页珍藏版）》请在冰豆网上搜索。
WebSphereIntegrationDeveloper指导教程第3部分
WebSphereIntegrationDeveloper指导教程第1部分
WebSphereIntegrationDeveloper指导教程第1部分WebSphereIntegrationDeveloper概览
引言
本系列文章提供了通过WebSphereIntegrationDeveloper进行应用程序开发的指导教程。
这第一篇文章对WebSphereIntegrationDeveloper及其主要概念进行了简要概述。
后续文章将会对每一个概念以及相关的构造工具进行深入的研究。
我们将逐一介绍本产品中的每个领域，了解其功能及作用，最后您将有机会亲自构建整个应用程序的下一部分。
以后的文章中涉及到的一些主题包括：
SOA开发
构建和组装简单应用程序
业务流程、状态机和规则
人工任务
EIS连接支持
中介和选择器
尽管这些文章之间是相辅相成的，但当深入研究到重要的某一特定部分时，会发现其实每篇文章自成一体。
什么是WebSphereIntegrationDeveloper？
您也许想知道什么是WebSphereIntegrationDeveloper，以及它为什么值得关注。
现在的公司正面临着企业集成、系统自动化以及建立各种与客户沟通新渠道的日益紧迫的压力。
公司需要灵活的、基于标准的产品和解决方案。
在集成活动的过程中通常会遇到一些问题，包括：
两个或更多异构的企业信息系统（EIS）之间的数据同步。
从使用者到多个生产者的智能代理产品请求。
向全球存储库发布产品数据，从而使得使用者能够访问并利用这些信息。
发布工作的范围可以从创建可用产品的目录到参与全球在线市场。
使用拱型流程（overarchingprocess）协调多个现有的业务流程。
从订单接收到库存管理和供应链管理，对订单处理流程进行管理。
制定、审批和上报工作任务，从而高效地处理客户请求。
通过不断改变控制业务的规则和决策，动态地应对业务环境的变化。
WebSphereIntegrationDeveloper可以解决上述这些类型和其他类型的应用程序集成问题。
就其基础而言，WebSphereIntegrationDeveloper建立在工业标准（尤其是WSDL、XSD、BPEL、Java™和UML）的基础上，同时也处于不断改进的标准的前沿（TuscanyServiceComponentArchitecture就是一个好的例子）。
要在这些标准的基础之上构建应用程序，可以使用一系列可视化构造工具和更高层次的概念，后者将允许专注于解决业务问题，而不必去编写大量的J2EE代码或者做一个精通WSDL的专家。
其实并不需要浸淫于这些标准之中，就能够实现它们。
从WebSphereIntegrationDeveloper的角度来看，面向服务的体系结构是指可以把精力集中于系统中的关键组件、可视化地构建它们、可视化地建立它们之间的联系，然后结束工作并使用WebSphereProcessServer来运行该系统。
此后，还可以进行可视化的单元测试以及调试整个应用程序或者其中的单个部分。
WebSphereIntegrationDeveloper支持自顶向下、自底向上和中间相遇三种构造方法。
可以从顶层，即设计层开始，布置整体构想，然后逐渐地深入并实现各个部件（服务）。
或者，可以采取自底向上的方式，分别实现这些服务，然后将它们组合成更大的应用程序。
更有可能的是，可以使用中间相遇的开发方法，也许首先布置初始的高层次设计，然后使用EnterpriseMetadataDiscovery工具来研究企业信息系统，并且定义各种与之相连的服务。
可能还想引入并重用业务合作伙伴所提供的外部Web服务。
谁在使用WebSphereIntegrationDeveloper？
也许我们真正应该问的是，WebSphereIntegrationDeveloper的用户究竟担任什么样的角色，还有在整个开发过程中，用户什么时候使用这些工具呢？
WebSphereIntegrationDeveloper面向集成专家。
这些用户并不是Java、WSDL或者XSD专家。
他们专注于集成应用程序以及解决前面讨论过的各类问题，当然，他们希望这些工作尽可能的简单。
图1显示了集成专家与其他用户角色的技术集合之间的关系。
图1.WebSphereIntegrationDeveloper用户
应用程序的开发过程在不同的开发阶段涉及到许多用户角色。
需要注意的是，我们提到的角色指的是做某项工作所涉及到的能力，而一个公司中的某个人实际上可能同时担任多个角色。
图2显示了软件开发过程中通常需要集成专家参与的部分。
集成专家从业务分析人员手中接过任务，开发集成应用程序，对其进行测试和调试，最后在通过了所有的测试并完成了集成任务后，将其部署到产品服务器。
图2.集成专家在开发中参与的工作
现在是做好准备并开始学习关于WebSphereIntegrationDeveloper的基本概念和工具的教程的时候了。
在后续的文章中，我们将关注各种元素的重要性和价值，并说明在构建示例应用程序的过程中如何使用这些概念或工具。
现在，我们先对各个部分做一个快速的浏览。
选择路线——服务实现类型
业务流程
业务状态机
业务规则和决策表
选择器
接口映射和业务对象映射
人工任务
Web服务
企业信息系统服务
Java/EJB——针对Java爱好者
重要的里程碑——业务对象
关系
可视代码段
中介服务
将其组合在一起
模块和组件
组装关系图
选择路线——服务实现类型
服务是面向服务的体系结构中的主要构造块。
WebSphereIntegrationDeveloper包括一套丰富的服务构建工具，它们能够解决各种可能碰到的问题。
在大多数情况下，可以通过可视化的构造工具，使用前面提到的几种服务实现类型来构建服务，有了这些构造工具，在使用WebSphereIntegrationDeveloper开发应用程序时，并不要求是一个专家程序员。
除了Java或者EJB服务之外，大部分服务可以通过可视化构造工具来构建。
可以使用这些Java和EJB服务来利用现有的Java应用程序，或者，如果您的组织中有一些Java狂热爱好者，可以使用IBMRational®ApplicationDeveloper来构建Java服务。
可以使用各种编程模式来实现服务，从业务过程流方式的BPEL流程，到状态机方式的事件管理，以及到声明性业务规则方式。
.对某种模式的熟悉程度和问题的本质将决定所选择的实现方式。
比如，有些问题使用状态机比使用声明性规则具有更加简洁的表述。
让我们了解一下这些不同的服务类型，并讨论在不同的情况下应该如何选择更好的服务类型。
业务流程
业务流程为协调企业服务和描述业务逻辑提供了基本的手段。
业务流程由一系列按照指定顺序执行的（串行或并行）活动或步骤组成。
业务流程编辑器是让您能够依据BPEL标准快速地编辑业务流程的可视化构造工具。
业务流程本身也是一个服务。
可以使用它来协调可重用的子流程或者其他具有不同实现类型的服务。
业务流程的一个重要特点是其长期性和与人的交互性。
流程的生命期可能非常短，在高度自动化的系统中这种情况很常见。
流程也有可能运行非常长的时间，也许几天甚至几个月，并等待人类用户完成某项与活动相关联的特定工作之后才能继续运行。
例如，业务流程可能需要耐心地等待管理人员批准一项旅行请求。
图3展示了如何使用业务流程编辑器来构造简单的旅行登记业务流程。
图3.业务流程编辑器
业务状态机
业务状态机是事件驱动的业务事务，该业务事务定义了应用软件中给定部分的一组状态。
状态机根据接收到的外部事件从一个有效状态转移到下一个有效状态。
对于一个给定事件，使用各种条件来决定新的有效状态。
售货机可以作为一个简单的例子，当它接收到足够的钱则转换到激活选择按钮的状态。
在做出选择之后，它就转变到分发商品（比如说一个巧克力棒）的状态。
可以使用状态机编辑器来构造业务状态机，它与业务流程编辑器一样是可视化的编辑工具，并且几乎不需要具有Java编程经验。
可以使用业务状态机和业务流程来协调应用程序的各个部分。
二者之间有一些细微的差别，这使得它们在解决某些类型的问题时各有所长。
状态机非常适合于循环模式或者那些能自然地想到一组有效状态的情况。
这一点非常重要，因为在状态机中，实际在一个状态中并不进行任何动作，而仅仅是等待转移到下一个状态的信号并随后发生状态转移。
当状态机从一个状态转移到另一个状态的过程中，它可以完成一些工作，比如售货机的例子中将巧克力棒分发给顾客。
与之相反，业务流程则是在其活动中完成工作。
它们非常适合于顺序执行或者并发执行的任务。
与业务流程相似，业务状态机能够调用其他实现类型的服务，并且能够将自身作为服务来调用。
图4显示了使用业务状态机编辑器所构造的业务状态机
图4.业务状态机编辑器
对于那些熟悉UML的用户，业务状态机是UML状态机的子集，而且它更适合于业务用户。
业务规则
业务规则描述并实现了业务策略和实践。
规则可以增强业务策略、制定决策、或从现有的数据中推理出新的数据。
通常有两种不同的指定形式：
规则集或者是决策表。
如果这些解释听起来更像一堆专业用语，那么请看下面的这个例子。
业务规则通常形如：
如果是金卡客户，并且在本公司消费长达十年之久，那么可以给予他们百分之十的折扣。
这条业务规则是一个简单的if－then规则。
如果规则计算为真，则执行一个动作，在本例中是给予客户折扣。
业务规则集由一组业务规则组成，这组规则在复杂业务逻辑的实现中具有很强的灵活性。
决策表则用来处理基本的业务规则逻辑。
它虽不如规则集那样灵活，但是用来描述简单的规则逻辑时能带来极大的便利。
经常旅行的人会比较熟悉下面这个关于决策表的经典例子。
假设想要避开寒冷并花光所有的频繁飞行积分去夏威夷。
您会查看一张表，分别找到居住城市和夏威夷所在的行和列，这个交叉处所显示的正是这趟旅程所需的积分数。
这仅仅只是能用决策表轻松描述的业务规则逻辑中的一种。
它向我们展示了业务规则的一个重要特点：
它是动态的，换言之，它具有随着业务环境的改变做出反应的能力。
可以使用业务规则来动态地修改产品服务器上的重要业务参数，并使它们立即生效。
例如，假设在一个反常的暖冬季节里，飞往热带目的地的航线无人问津。
您决定降低到夏威夷所需的频繁飞行积分。
那么只需通过查看表格并修改相应的值，就可以轻松地在业务运行过程中完成这项任务。
在本文后面的内容中，我们将概述WebSphereBusinessMonitor，可以用这个产品来实时监控业务，从而通过调整业务规则策略来对关键的观测结果和条件做出反应。
总而言之，在下列任何情况下都应该使用业务规则来进行决策制定：
希望在运行的服务器上在运行时对结果进行更改。
决策本身就是以表的形式呈现。
决策本身就是以一系列简单选择项的形式呈现，即可以很容易地看作为“if-then”语句。
图5显示了如何使用决策表编辑器来创建决策表。
图5.决策表编辑器
选择器
选择器提供了一种简单的方法来响应服务请求，并将其路由至另一个处理该请求的服务。
路由路径可以随着时间的不同而不同。
可以使用选择器来根据日期调用不同的服务实现。
例如，假设希望在线圣诞卡业务在十二月二十五号之前使用常规销售服务，而在此日期之后则进行大幅度的折扣服务。
可以使用可视化的选择器编辑器来构建一个选择器，该选择器将截获业务请求，并且在圣诞节前提供常规服务而在节后选择折扣服务。
图6展示了如何创建这样的选择器。
与业务规则类似，可以在产品服务器上动态地改变选择器。
可以根据不断变化的业务需求来修改服务目标和日期参数。
图6.选择器编辑器
接口映射
有些时候，可能有两个服务由于无法理解相同的操作集合而不能够彼此进行通信。
这种窘境常常使人感到沮丧，此时可以使用接口映射这个简单的解决方案。
接口映射描述了如何将一种服务的操作转换为另一服务的操作。
我们将在将其组合在一起部分中对接口进行讨论。
在对两个接口进行映射时，首先映射它们的操作，然后映射它们的输入和输出消息。
如果输入和输出消息具有不同的数据类型，应该使用数据映射（将在接下来的部分中介绍）来映射这两种类型。
图7显示了如何使用接口映射编辑器来构造接口映射。
图7.接口映射编辑器
业务对象映射
业务对象映射，也称作数据映射，用来将业务数据从一种类型转换为另一种类型。
在协调异构系统时，甚至在正常业务逻辑的某个部分，常常需要将一个业务对象（请参见重要的里程碑——业务对象）映射成另一个业务对象。
使用业务对象映射编辑器，可以图形化地创建映射来将一个业务对象及其字段转换为另一个业务对象，如图8所示。
举个简单的例子，假设需要将一个姓名从员工信息服务传递到旅行登记服务。
假设这个业务寄宿于一个老式笨重的系统上，它返回一个由逗号分隔的字符串，然而旅行登记服务需要三个独立的字段（名字/姓氏/中间名）。
本例中的映射过程将接收全名作为输入，然后将其分隔为所需的三个部分。
编辑器为各种需要用到的映射（比如串连）提供了方便快捷的机制，并且提供了使用Java或可视代码段（后者用得更多）来定义自定义转换的方法。
业务对象映射支持业务对象之间1-to-n、m-to-1和m-to-n的映射。
图8.业务对象映射编辑器
人工任务
人工任务是由人来完成的非常简单的一组工作。
通常，这类任务涉及到与其他服务的交互，因而成为了更大业务目标中的一项任务。
可以使用WebSphereIntegrationDeveloper和WebSphereProcessServer在无法及时处理的情况下，上报或委派人工任务。
可以根据系统（比如LDAP）中定义的组织结构，将这些任务分配给个人或者小组（例如管理人员）。
可以使用可视化人工任务编辑器来创建人工任务，如图9所示。
图9.人工任务编辑器
Web服务
我们所提到的服务都是出类拔萃的服务，不过到目前为止它们只能在其他的WebSphere的应用程序中进行访问。
然而，可以很方便地作为Web服务公开前面列出的任何服务类型。
我们将在组装关系图部分对其进行解释。
甚至可以更进一步，使用WebSphereIntegrationDeveloper从RationalApplicationDeveloper中继承而来的功能创建标准的Web服务。
可以在想进一步了解相关产品以及本文结束处列出的参考资料中找到更多的信息。
企业信息系统（EIS）服务
由于您的公司很可能依赖于一个以上EIS，因此可以很容易地将其应用程序转变为服务。
可以通过EnterpriseServiceDiscovery向导来完成这项任务，该向导使用了标准的J2C资源适配器来连接和查询后端系统（比如CICS®或PeopleSoft）。
与WebSphereIntegrationDeveloper一起提供的有两个资源适配器，一个用于CICSECI，另一个用于IMS™。
图10显示了如何根据PeopleSoft服务器上的数据，为定购单服务创建一项操作。
当完成向导中的各个步骤后，就得到了允许访问EIS的服务，就像访问任何其他的服务一样。
图10.EnterpriseServiceDiscovery向导
Java和EJB服务
正如我们前面提到的，如果您的公司中有一些经验丰富的Java开发人员，那么还可以创建或者重用普通老式的Java对象或者EJB作为服务的实现。
在Java代码中调用其他的服务，就如同在可视化编辑器中使用它们一样的简单。
如果打算使用Java代码像业务流程部分中那样进行旅行社合作伙伴服务调用（请回顾图3中所显示的登记旅行活动中进行的这种调用），那么代码应与如下所示类似：
result=locateService_TravelAgencyPartner（）.placeTripOrder（travelRequest）;
每个引用都会生成相应的helper代码，它将使得服务调用变得简单（在组装关系图中创建引用，我们将对其进行简单说明）。
重要的里程碑——业务对象
回到业务对象映射部分中，我们介绍了如何在各种业务对象中进行映射，以实现不同服务之间能够互相理解。
在这一部分中，我们将介绍什么是业务对象。
业务对象是业务应用程序中的主要部分。
示例业务对象中包括客户订单、客户和库存项。
业务对象由一组字段和它们的值构成。
一个字段可以反过来转变成为另一个业务对象。
例如，Order业务对象可以具有一个客户字段，而这个字段又可以反过来转变为Customer业务对象。
可以使用业务对象编辑器创建业务对象，该编辑器为业务对象提供图形化的视图。
如果更喜欢使用键盘来快速的填写表格，那么可以使用编辑器的表格方式来处理业务对象。
图11.业务对象编辑器
关系
关系将两个（或更多）物理表现形式不同而语义上相同的业务对象关联起来。
假设EIS1中的员工名称以全名的形式表现，而EIS2中也有员工，但是其名称存储为姓氏和名字两个字段。
如果这两个系统中包含的是相同的员工，那么可以使用关系来表明这一点。
现在如果更新其中一个系统中员工的信息，那么可以很方便的更新该员工在另一个系统中的信息。
通过建立这两个系统间的关系，即声明了实际上完全相同的员工。
可以使用可视化的关系编辑器来创建关系，如图12所示。
图12.关系编辑器
可视代码段
有时在业务流程、状态机或者其他的服务中，可能需要编写一些细节逻辑。
可以使用WebSphereIntegrationDeveloper在许多地方完成自定义代码，尽管完全可以随意使用Java代码，但有个非常流行的选择就是使用可视代码段编辑器。
该编辑器允许更细致地描述逻辑层次，而无需去编写底层的Java代码文本。
图13显示了一种简单的方法，在前面图9中介绍的人工任务之后，可使用这种方法来决定执行选项中的哪一个分支。
图13.可视代码段编辑器
中介服务
中介服务截获并修改了在现有服务及其客户端之间传递的消息。
中介服务通过包含中介流的中介模块来实现。
例如，假设有两种客户正在使用股票行情服务：
普通成员（不需付费）和贵宾成员。
该服务委派了两个不同的服务以获取股票价格：
一个提供延迟的报价，而另一个则提供实时报价。
可以使用中介流来将贵宾成员的请求路由到即时报价服务，而将其他的请求路由到延迟报价服务。
图14显示了如何使用中介流编辑器来创建这样的中介。
图14.中介流编辑器
将其组合在一起
既然熟悉了实现服务的各种方式，接下来我们将说明在一个可部署的完整应用程序中如何将它们组合在一起。
模块和组件
所创建的任何服务都是可置入组装关系图中的一个组件（请参阅接下来的部分）。
这些组件组合在一起就形成了模块，而模块可以被部署到WebSphereProcessServer（稍后进行更详细的介绍）。
这些组件的重要特性是它们的接口。
接口允许其他的服务与该服务进行沟通，并且接口使用WSDL或者Java来定义。
所以，组件需要有一个接口，而且其他的实现必须遵循这个接口。
如果组件的接口与引用所需的接口相匹配，那么可以将一个组件的任何引用连接到任何其他的组件。
如前所述，不必为已经存在的服务定义其实现，比如Web服务（它具有WSDL接口映射）或者EIS应用程序（ServiceDiscovery向导为其创建了合适的接口）。
在这个例子中，使用导入，这样就可以用和任何其他组件相同的方式来进行引用。
它在外部进行实现的这个事实是透明的，只需使用该引用即可。
同样，当在WebSphere之外或者对WebSphere中的其他应用程序公开服务时，只需添加具有合适的接口的导出，并将它连接到想要公开的组件。
指定绑定来进行导入和导出，而它们的属性决定了如何访问该服务。
例如，如果导入中有一项Web服务绑定，就需要为其指定端点及端口。
组装关系图
组装关系图用来将模块中服务组件连接到一起。
图15显示了使用EmployeeToPersonnelSystemMap的组装关系图。
其中有一个CheckEmployee流程，而它将使用EmployeeEIS。
使用该图，可以保留这项引用（更重要的是，保留它所使用的业务逻辑），并且通过中介将它连接到PersonnelSystem。
CheckEmployee组件中显示的EmployeeSystemPartner引用对应于流程中相同的引用。
图15.组装关系图编辑器
想进一步了解相关产品？
WebSphereIntegrationDeveloper补充了一些其他IBMWebSphere业务集成产品来辅助面向服务的应用程序的开发。
其中最主要的是WebSphereBusinessModeler、WebSphereProcessServer和WebSphereBusinessMonitor。
让我们逐个地简单了解一下这些产品，并介绍WebSphereIntegrationDeveloper如何与它们协调工作。
WebSphereBusinessModeler
尽管可以直接使用WebSphereIntegrationDeveloper来开始构建面向服务的应用程序，但首先使用WebSphereBusinessModeler来对业务流程进行建模，可能会更有帮助。
使用WebSphereBusinessModeler对业务流程进行建模，可以在实现技术解决方案之前，帮助获得对业务的更好的理解，验证增强功能和转换功能，并发现流程改进的潜在领域或者现有流程中隐藏的价值。
除了帮助实现解决方案奠定基础，WebSphereBusinessModeler还提供了其他的好处，比如为流程遵循性提供所需的信息、文档和培训，并允许运行模拟程序来发现流程中的可改进之处（产品的高级版本中包含了该模拟工具）。
可以使用WebSphereBusinessModeler来定义公司资源，比如现有的信息系统、设备、员工和业务项（如发票和文件），并将它们集成到流程模型中。
而在更高的层次上，可以使用WebSphereBusinessModeler来对关系和企业中的不同实体间的交互进行建模。
与WebSphereIntegrationDeveloper一样，WebSphereBusinessModeler也可被掌握不同技能的人员使用。
WebSphereBusinessModeler允许了解业务的人员在开始实现之前进行建模工作。
例如，需要在更高层次上对业务进行建模的业务分析人员可以使用基本模式完成该任务，而更具技术经验的人员可以使用中级或高级用户模式来指定更深入的细节或者更复杂的业务逻辑。
在完成业务流程建模之后，可以将该模型提交到开发平台进行实现。
可以使用WebSphereIntegrationDeveloper来导入模型，并使用它们来构建和测试一套完整的SOA应用程序。
RationalApplicationDeveloper
WebSphereIntegrationDeveloper构建于
升级会员 