内容


IBM WebSphere 开发者技术期刊

WebSphere Integration Developer 指导教程——第 1 部分

WebSphere Integration Developer 概览

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

此内容是该系列的一部分:IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

摘自 IBM WebSphere 开发者技术期刊

引言

本系列文章提供了通过 WebSphere Integration Developer 进行应用程序开发的指导教程。这第一篇文章对 WebSphere Integration Developer 及其主要概念进行了简要概述。

后续文章将会对每一个概念以及相关的构造工具进行深入的研究。我们将逐一介绍本产品中的每个领域,了解其功能及作用,最后您将有机会亲自构建整个应用程序的下一部分。以后的文章中涉及到的一些主题包括:

  • SOA 开发
  • 构建和组装简单应用程序
  • 业务流程、状态机和规则
  • 人工任务
  • EIS 连接支持
  • 中介和选择器

尽管这些文章之间是相辅相成的,但当深入研究到重要的某一特定部分时,会发现其实每篇文章自成一体。

什么是 WebSphere Integration Developer?

您也许想知道什么是 WebSphere Integration Developer,以及它为什么值得关注。现在的公司正面临着企业集成、系统自动化以及建立各种与客户沟通新渠道的日益紧迫的压力。公司需要灵活的、基于标准的产品和解决方案。

在集成活动的过程中通常会遇到一些问题,包括:

  • 两个或更多异构的企业信息系统 (EIS) 之间的数据同步。
  • 从使用者到多个生产者的智能代理产品请求。
  • 向全球存储库发布产品数据,从而使得使用者能够访问并利用这些信息。发布工作的范围可以从创建可用产品的目录到参与全球在线市场。
  • 使用拱型流程 (overarching process) 协调多个现有的业务流程。
  • 从订单接收到库存管理和供应链管理,对订单处理流程进行管理。
  • 制定、审批和上报工作任务,从而高效地处理客户请求。
  • 通过不断改变控制业务的规则和决策,动态地应对业务环境的变化。

WebSphere Integration Developer 可以解决上述这些类型和其他类型的应用程序集成问题。就其基础而言,WebSphere Integration Developer 建立在工业标准(尤其是 WSDL、XSD、BPEL、Java™ 和 UML)的基础上,同时也处于不断改进的标准的前沿(Tuscany Service Component Architecture 就是一个好的例子)。要在这些标准的基础之上构建应用程序,可以使用一系列可视化构造工具和更高层次的概念,后者将允许专注于解决业务问题,而不必去编写大量的 J2EE 代码或者做一个精通 WSDL 的专家。其实并不需要浸淫于这些标准之中,就能够实现它们。

从 WebSphere Integration Developer 的角度来看,面向服务的体系结构是指可以把精力集中于系统中的关键组件、可视化地构建它们、可视化地建立它们之间的联系,然后结束工作并使用 WebSphere Process Server 来运行该系统。 此后,还可以进行可视化的单元测试以及调试整个应用程序或者其中的单个部分。

WebSphere Integration Developer 支持自顶向下、自底向上和中间相遇三种构造方法。可以从顶层,即设计层开始,布置整体构想,然后逐渐地深入并实现各个部件(服务)。或者,可以采取自底向上的方式,分别实现这些服务,然后将它们组合成更大的应用程序。更有可能的是,可以使用中间相遇的开发方法,也许首先布置初始的高层次设计,然后使用 Enterprise Metadata Discovery 工具来研究企业信息系统,并且定义各种与之相连的服务。可能还想引入并重用业务合作伙伴所提供的外部 Web 服务。

谁在使用 WebSphere Integration Developer?

也许我们真正应该问的是,WebSphere Integration Developer 的用户究竟担任什么样的角色,还有在整个开发过程中,用户什么时候使用这些工具呢?

WebSphere Integration Developer 面向集成专家。这些用户并不是 Java、WSDL 或者 XSD 专家。他们专注于集成应用程序以及解决前面讨论过的各类问题,当然,他们希望这些工作尽可能的简单。图 1 显示了集成专家与其他用户角色的技术集合之间的关系。

图 1. WebSphere Integration Developer 用户
WebSphere Integration Developer 用户
WebSphere Integration Developer 用户

应用程序的开发过程在不同的开发阶段涉及到许多用户角色。需要注意的是,我们提到的角色 指的是做某项工作所涉及到的能力,而一个公司中的某个人实际上可能同时担任多个角色。图 2 显示了软件开发过程中通常需要集成专家参与的部分。集成专家从业务分析人员手中接过任务,开发集成应用程序,对其进行测试和调试,最后在通过了所有的测试并完成了集成任务后,将其部署到产品服务器。

图 2. 集成专家在开发中参与的工作
WebSphere Integration Developer 用户
WebSphere Integration Developer 用户

教程

现在是做好准备并开始学习关于 WebSphere Integration Developer 的基本概念和工具的教程的时候了。在后续的文章中,我们将关注各种元素的重要性和价值,并说明在构建示例应用程序的过程中如何使用这些概念或工具。现在,我们先对各个部分做一个快速的浏览。

选择路线——服务实现类型

服务是面向服务的体系结构中的主要构造块。WebSphere Integration Developer 包括一套丰富的服务构建工具,它们能够解决各种可能碰到的问题。在大多数情况下,可以通过可视化的构造工具,使用前面提到的几种服务实现类型来构建服务,有了这些构造工具,在使用 WebSphere Integration Developer 开发应用程序时,并不要求是一个专家程序员。除了 Java 或者 EJB 服务之外,大部分服务可以通过可视化构造工具来构建。可以使用这些 Java 和 EJB 服务来利用现有的 Java 应用程序,或者,如果您的组织中有一些 Java 狂热爱好者,可以使用 IBM Rational® Application Developer 来构建 Java 服务(请参阅想进一步了解相关产品吗?)。

可以使用各种编程模式来实现服务,从业务过程流方式的 BPEL 流程,到状态机方式的事件管理,以及到声明性业务规则方式。.对某种模式的熟悉程度和问题的本质将决定所选择的实现方式。比如,有些问题使用状态机比使用声明性规则具有更加简洁的表述。让我们了解一下这些不同的服务类型,并讨论在不同的情况下应该如何选择更好的服务类型。

业务流程

业务流程 为协调企业服务和描述业务逻辑提供了基本的手段。业务流程由一系列按照指定顺序执行的(串行或并行)活动或步骤组成。业务流程编辑器是让您能够依据 BPEL 标准快速地编辑业务流程的可视化构造工具。

业务流程本身也是一个服务。可以使用它来协调可重用的子流程或者其他具有不同实现类型的服务。业务流程的一个重要特点是其长期性和与人的交互性。流程的生命期可能非常短,在高度自动化的系统中这种情况很常见。流程也有可能运行非常长的时间,也许几天甚至几个月,并等待人类用户完成某项与活动相关联的特定工作之后才能继续运行。例如,业务流程可能需要耐心地等待管理人员批准一项旅行请求。

图 3 展示了如何使用业务流程编辑器来构造简单的旅行登记业务流程。

图 3. 业务流程编辑器
业务流程编辑器
业务流程编辑器

业务状态机

业务状态机 是事件驱动的业务事务,该业务事务定义了应用软件中给定部分的一组状态。状态机根据接收到的外部事件从一个有效状态转移到下一个有效状态。对于一个给定事件,使用各种条件来决定新的有效状态。售货机可以作为一个简单的例子,当它接收到足够的钱则转换到激活选择按钮的状态。在做出选择之后,它就转变到分发商品(比如说一个巧克力棒)的状态。可以使用状态机编辑器来构造业务状态机,它与业务流程编辑器一样是可视化的编辑工具,并且几乎不需要具有 Java 编程经验。

可以使用业务状态机和业务流程来协调应用程序的各个部分。二者之间有一些细微的差别,这使得它们在解决某些类型的问题时各有所长。状态机非常适合于循环模式或者那些能自然地想到一组有效状态的情况。这一点非常重要,因为在状态机中,实际在一个状态中并不进行任何动作,而仅仅是等待转移到下一个状态的信号并随后发生状态转移。当状态机从一个状态转移到另一个状态的过程中,它可以完成一些工作,比如售货机的例子中将巧克力棒分发给顾客。与之相反,业务流程则是在其活动中完成工作。它们非常适合于顺序执行或者并发执行的任务。与业务流程相似,业务状态机能够调用其他实现类型的服务,并且能够将自身作为服务来调用。图 4 显示了使用业务状态机编辑器所构造的业务状态机

图 4. 业务状态机编辑器
业务状态机编辑器
业务状态机编辑器

对于那些熟悉 UML 的用户,业务状态机是 UML 状态机的子集,而且它更适合于业务用户。

业务规则

业务规则 描述并实现了业务策略和实践。规则可以增强业务策略、制定决策、或从现有的数据中推理出新的数据。通常有两种不同的指定形式:规则集或者是决策表。

如果这些解释听起来更像一堆专业用语,那么请看下面的这个例子。业务规则通常形如:如果是金卡客户,并且在本公司消费长达十年之久,那么可以给予他们百分之十的折扣。这条业务规则是一个简单的 if-then 规则。如果规则计算为真,则执行一个动作,在本例中是给予客户折扣。业务规则集 由一组业务规则组成,这组规则在复杂业务逻辑的实现中具有很强的灵活性。

决策表 则用来处理基本的业务规则逻辑。它虽不如规则集那样灵活,但是用来描述简单的规则逻辑时能带来极大的便利。经常旅行的人会比较熟悉下面这个关于决策表的经典例子。假设想要避开寒冷并花光所有的频繁飞行积分去夏威夷。您会查看一张表,分别找到居住城市和夏威夷所在的行和列,这个交叉处所显示的正是这趟旅程所需的积分数。这仅仅只是能用决策表轻松描述的业务规则逻辑中的一种。

它向我们展示了业务规则的一个重要特点:它是动态的,换言之,它具有随着业务环境的改变做出反应的能力。可以使用业务规则来动态地修改产品服务器上的重要业务参数,并使它们立即生效。例如,假设在一个反常的暖冬季节里,飞往热带目的地的航线无人问津。您决定降低到夏威夷所需的频繁飞行积分。那么只需通过查看表格并修改相应的值,就可以轻松地在业务运行过程中完成这项任务。

在本文后面的内容中,我们将概述 WebSphere Business Monitor,可以用这个产品来实时监控业务,从而通过调整业务规则策略来对关键的观测结果和条件做出反应。

总而言之,在下列任何情况下都应该使用业务规则来进行决策制定:

  • 希望在运行的服务器上在运行时对结果进行更改。
  • 决策本身就是以表的形式呈现。
  • 决策本身就是以一系列简单选择项的形式呈现,即可以很容易地看作为“if-then”语句。

图 5 显示了如何使用决策表编辑器来创建决策表。

图 5. 决策表编辑器
决策表编辑器
决策表编辑器

选择器

选择器 提供了一种简单的方法来响应服务请求,并将其路由至另一个处理该请求的服务。路由路径可以随着时间的不同而不同。可以使用选择器来根据日期调用不同的服务实现。例如,假设希望在线圣诞卡业务在十二月二十五号之前使用常规销售服务,而在此日期之后则进行大幅度的折扣服务。可以使用可视化的选择器编辑器来构建一个选择器,该选择器将截获业务请求,并且在圣诞节前提供常规服务而在节后选择折扣服务。图 6 展示了如何创建这样的选择器。

与业务规则类似,可以在产品服务器上动态地改变选择器。可以根据不断变化的业务需求来修改服务目标和日期参数。

图 6. 选择器编辑器
选择器编辑器
选择器编辑器

接口映射

有些时候,可能有两个服务由于无法理解相同的操作集合而不能够彼此进行通信。这种窘境常常使人感到沮丧,此时可以使用接口映射这个简单的解决方案。接口映射 描述了如何将一种服务的操作转换为另一服务的操作。我们将在将其组合在一起部分中对接口进行讨论。

在对两个接口进行映射时,首先映射它们的操作,然后映射它们的输入和输出消息。如果输入和输出消息具有不同的数据类型,应该使用数据映射 (将在接下来的部分中介绍)来映射这两种类型。图 7 显示了如何使用接口映射编辑器来构造接口映射。

图 7. 接口映射编辑器
接口映射编辑器
接口映射编辑器

业务对象映射

业务对象映射,也称作数据映射,用来将业务数据从一种类型转换为另一种类型。在协调异构系统时,甚至在正常业务逻辑的某个部分,常常需要将一个业务对象(请参见重要的里程碑——业务对象)映射成另一个业务对象。

使用业务对象映射编辑器,可以图形化地创建映射来将一个业务对象及其字段转换为另一个业务对象,如图 8 所示。举个简单的例子,假设需要将一个姓名从员工信息服务传递到旅行登记服务。假设这个业务寄宿于一个老式笨重的系统上,它返回一个由逗号分隔的字符串,然而旅行登记服务需要三个独立的字段(名字/姓氏/中间名)。本例中的映射过程将接收全名作为输入,然后将其分隔为所需的三个部分。编辑器为各种需要用到的映射(比如串连)提供了方便快捷的机制,并且提供了使用 Java 或可视代码段(后者用得更多)来定义自定义转换的方法。

业务对象映射支持业务对象之间 1-to-nm-to-1 和 m-to-n 的映射。

图 8. 业务对象映射编辑器
业务对象映射编辑器
业务对象映射编辑器

人工任务

人工任务是由人来完成的非常简单的一组工作。通常,这类任务涉及到与其他服务的交互,因而成为了更大业务目标中的一项任务。可以使用 WebSphere Integration Developer 和 WebSphere Process Server 在无法及时处理的情况下,上报或委派人工任务。可以根据系统(比如 LDAP)中定义的组织结构,将这些任务分配给个人或者小组(例如管理人员)。

可以使用可视化人工任务编辑器来创建人工任务,如图 9 所示。

图 9. 人工任务编辑器
人工任务编辑器
人工任务编辑器

Web 服务

我们所提到的服务都是出类拔萃的服务,不过到目前为止它们只能在其他的 WebSphere 的应用程序中进行访问。然而,可以很方便地作为 Web 服务公开前面列出的任何服务类型。我们将在组装关系图部分对其进行解释。甚至可以更进一步,使用 WebSphere Integration Developer 从 Rational Application Developer 中继承而来的功能创建标准的 Web 服务。可以在想进一步了解相关产品以及本文结束处列出的参考资料中找到更多的信息。

企业信息系统 (EIS) 服务

由于您的公司很可能依赖于一个以上 EIS,因此可以很容易地将其应用程序转变为服务。可以通过 Enterprise Service Discovery 向导来完成这项任务,该向导使用了标准的 J2C 资源适配器来连接和查询后端系统(比如 CICS ® 或 PeopleSoft)。与 WebSphere Integration Developer 一起提供的有两个资源适配器,一个用于 CICS ECI,另一个用于 IMS™。

图 10 显示了如何根据 PeopleSoft 服务器上的数据,为定购单服务创建一项操作。当完成向导中的各个步骤后,就得到了允许访问 EIS 的服务,就像访问任何其他的服务一样。

图 10. Enterprise Service Discovery 向导
Enterprise Service Discovery 向导
Enterprise Service Discovery 向导

Java 和 EJB 服务

正如我们前面提到的,如果您的公司中有一些经验丰富的 Java 开发人员,那么还可以创建或者重用普通老式的 Java 对象或者 EJB 作为服务的实现。在 Java 代码中调用其他的服务,就如同在可视化编辑器中使用它们一样的简单。如果打算使用 Java 代码像业务流程部分中那样进行旅行社合作伙伴服务调用(请回顾图 3 中所显示的登记旅行活动中进行的这种调用),那么代码应与如下所示类似:

result = locateService_TravelAgencyPartner().placeTripOrder(travelRequest);

每个引用都会生成相应的 helper 代码,它将使得服务调用变得简单(在组装关系图中创建引用,我们将对其进行简单说明)。

重要的里程碑——业务对象

回到业务对象映射部分中,我们介绍了如何在各种业务对象中进行映射,以实现不同服务之间能够互相理解。在这一部分中,我们将介绍什么是业务对象。业务对象 是业务应用程序中的主要部分。示例业务对象中包括客户订单、客户和库存项。业务对象由一组字段和它们的值构成。一个字段可以反过来转变成为另一个业务对象。例如,Order 业务对象可以具有一个客户字段,而这个字段又可以反过来转变为 Customer 业务对象。

可以使用业务对象编辑器创建业务对象,该编辑器为业务对象提供图形化的视图。如果更喜欢使用键盘来快速的填写表格,那么可以使用编辑器的表格方式来处理业务对象。

图 11. 业务对象编辑器
业务对象编辑器
业务对象编辑器

关系

关系 将两个(或更多)物理表现形式不同而语义上相同的业务对象关联起来。假设 EIS1 中的员工名称以全名的形式表现,而 EIS2 中也有员工,但是其名称存储为姓氏和名字两个字段。如果这两个系统中包含的是相同的员工,那么可以使用关系来表明这一点。现在如果更新其中一个系统中员工的信息,那么可以很方便的更新该员工在另一个系统中的信息。通过建立这两个系统间的关系,即声明了实际上完全相同 的员工。

可以使用可视化的关系编辑器来创建关系,如图 12 所示。

图 12. 关系编辑器
关系编辑器
关系编辑器

可视代码段

有时在业务流程、状态机或者其他的服务中,可能需要编写一些细节逻辑。可以使用 WebSphere Integration Developer 在许多地方完成自定义代码,尽管完全可以随意使用 Java 代码,但有个非常流行的选择就是使用可视代码段编辑器。该编辑器允许更细致地描述逻辑层次,而无需去编写底层的 Java 代码文本。

图 13 显示了一种简单的方法,在前面图 9 中介绍的人工任务之后,可使用这种方法来决定执行选项中的哪一个分支。

图 13. 可视代码段编辑器
可视代码段编辑器
可视代码段编辑器

中介服务

中介服务 截获并修改了在现有服务及其客户端之间传递的消息。中介服务通过包含中介流 的中介模块来实现。例如,假设有两种客户正在使用股票行情服务:普通成员(不需付费)和贵宾成员。该服务委派了两个不同的服务以获取股票价格:一个提供延迟的报价,而另一个则提供实时报价。可以使用中介流来将贵宾成员的请求路由到即时报价服务,而将其他的请求路由到延迟报价服务。图 14 显示了如何使用中介流编辑器来创建这样的中介。

图 14. 中介流编辑器
中介流编辑器
中介流编辑器

将其组合在一起

既然熟悉了实现服务的各种方式,接下来我们将说明在一个可部署的完整应用程序中如何将它们组合在一起。

模块和组件

所创建的任何服务都是可置入组装关系图中的一个组件 (请参阅接下来的部分)。这些组件组合在一起就形成了模块,而模块可以被部署到 WebSphere Process Server(稍后进行更详细的介绍)。

这些组件的重要特性是它们的接口。接口 允许其他的服务与该服务进行沟通,并且接口使用 WSDL 或者 Java 来定义。所以,组件需要有一个接口,而且其他的实现必须遵循这个接口。如果组件的接口与引用所需的接口相匹配,那么可以将一个组件的任何引用连接到任何其他的组件。

如前所述,不必为已经存在的服务定义其实现,比如 Web 服务(它具有 WSDL 接口映射)或者 EIS 应用程序(Service Discovery 向导为其创建了合适的接口)。在这个例子中,使用导入,这样就可以用和任何其他组件相同的方式来进行引用。它在外部进行实现的这个事实是透明的,只需使用该引用即可。同样,当在 WebSphere 之外或者对 WebSphere 中的其他应用程序公开服务时,只需添加具有合适的接口的导出,并将它连接到想要公开的组件。指定绑定来进行导入和导出,而它们的属性决定了如何访问该服务。例如,如果导入中有一项 Web 服务绑定,就需要为其指定端点及端口。

组装关系图

组装关系图 用来将模块中服务组件连接到一起。图 15 显示了使用 EmployeeToPersonnelSystemMap 的组装关系图。其中有一个 CheckEmployee 流程,而它将使用 Employee EIS。使用该图,可以保留这项引用(更重要的是,保留它所使用的业务逻辑),并且通过中介将它连接到 PersonnelSystem。CheckEmployee 组件中显示的 EmployeeSystemPartner 引用对应于流程中相同的引用。

图 15. 组装关系图编辑器
组装关系图编辑器
组装关系图编辑器

想进一步了解相关产品?

WebSphere Integration Developer 补充了一些其他 IBM WebSphere 业务集成产品来辅助面向服务的应用程序的开发。其中最主要的是 WebSphere Business Modeler、WebSphere Process Server 和 WebSphere Business Monitor。让我们逐个地简单了解一下这些产品,并介绍 WebSphere Integration Developer 如何与它们协调工作。

WebSphere Business Modeler

尽管可以直接使用 WebSphere Integration Developer 来开始构建面向服务的应用程序,但首先使用 WebSphere Business Modeler 来对业务流程进行建模,可能会更有帮助。使用 WebSphere Business Modeler 对业务流程进行建模,可以在实现技术解决方案之前,帮助获得对业务的更好的理解,验证增强功能和转换功能,并发现流程改进的潜在领域或者现有流程中隐藏的价值。

除了帮助实现解决方案奠定基础,WebSphere Business Modeler 还提供了其他的好处,比如为流程遵循性提供所需的信息、文档和培训,并允许运行模拟程序来发现流程中的可改进之处(产品的高级版本中包含了该模拟工具)。可以使用 WebSphere Business Modeler 来定义公司资源,比如现有的信息系统、设备、员工和业务项(如发票和文件),并将它们集成到流程模型中。而在更高的层次上,可以使用 WebSphere Business Modeler 来对关系和企业中的不同实体间的交互进行建模。

与 WebSphere Integration Developer 一样,WebSphere Business Modeler 也可被掌握不同技能的人员使用。WebSphere Business Modeler 允许了解业务的人员在开始实现之前进行建模工作。例如,需要在更高层次上对业务进行建模的业务分析人员可以使用基本模式完成该任务,而更具技术经验的人员可以使用中级或高级用户模式来指定更深入的细节或者更复杂的业务逻辑。

在完成业务流程建模之后,可以将该模型提交到开发平台进行实现。可以使用 WebSphere Integration Developer 来导入模型,并使用它们来构建和测试一套完整的 SOA 应用程序。

Rational Application Developer

WebSphere Integration Developer 构建于 Rational Application Developer 之上。Rational Application Developer 是可满足各种开发需求的开发环境,包括简单的 Java 应用程序、复杂的 Web 接口和门户、以及 EJB 和数据访问组件。而 Rational Application Developer 构建于 Eclipse 之上,Eclipse 是开发应用程序和创建应用程序开发工具的开放源代码平台。

因此,当需要为服务开发门户或者 Web 客户端应用程序时,可以启用 WebSphere Integration Developer 中的附加特性,而这些特性可以在 Rational Application Developer 工具包中找到。还可以使用 Rational Application Developer 工具将服务作为 Web 服务公开。实际上,可以在 J2EE 的层次上对应用程序进行额外的开发。

WebSphere Process Server

在实现阶段完成后,可以使用 WebSphere Integration Developer 将应用程序部署到 WebSphere Process Server。WebSphere Process Server 是基于 WebSphere Application Server 的面向服务的体系结构集成平台。它由经过检验的业务集成概念、应用服务器技术和最新的公开标准发展而来。通过对使用 WebSphere Integration Developer 开发的应用程序中各种服务组件类型提供执行时间支持,它在帮助业务处理不断变化的环境的过程中扮演了关键的角色。

可以将基于标准的 Business Process Execution Language (BPEL) 的应用程序部署到任何 BPEL 兼容的服务器,而 WebSphere Integration Developer 所提供的开发工具允许充分地利用 WebSphere Process Server 的附加功能。这些功能包括支持业务流程中人工参与部分的人工任务、事件驱动流程的业务状态机、用来实现流程中按需变化的业务规则,以及启用动态业务流程的选择器。

WebSphere Process Server 由 WebSphere Enterprise Service Bus 驱动,后者除了允许一个真正面向服务的体系结构的执行外,还提供了 J2EE Connector architecture (JCA)、Web 服务连接和 Java Message Service (JMS) 消息的支持。

WebSphere Business Monitor

当完成应用程序并在 WebSphere Process Server 上运行时,将需要获取关于它们的信息来帮助识别问题、发现错误,以及决定是否需要对流程进行改进。这正是 WebSphere Business Monitor 派上用场的领域。WebSphere Business Monitor 利用 Common Event Infrastructure 收集来自 WebSphere Process Server 事件。从这些事件中,它能够根据业务度量模型计算关键性能指标 (KPIs: Key Performance Indicators) 和度量值。

利用创建的流程模型,通过 WebSphere Business Modeler 提供的业务度量编辑器来创建业务度量模型。这些模型定义了度量和度量点、事件筛选和关联、以及想要监视的业务数据源。监视服务器在收到和处理来自服务器的事件时将使用这些模型。

WebSphere Business Monitor 的仪表板客户端组件允许用户使用自定义的视图集来监视业务性能。这些视图将根据业务度量模型,以不同的表现方式显示出活动流程实例及其状态、报告、KPI 和 KPI 记分卡、以及报警。自适应行为管理程序不仅能通过仪表板发送通知,还可以根据规定的条件通过电子邮件、寻呼机或者手机来发送通知。

最后,WebSphere Business Monitor 允许导出监视数据值,可以将它们导入 WebSphere Business Modeler 来对业务流程进行持续的改进。

总结

我们简要介绍了 WebSphere Integration Developer 及其关键概念。可以看出,这个环境是高度可视化的,并且强调了应用程序的高级概念。这种体验常常描述为指向单击集成

在后续的文章中,我们将对每个概念的详细分析,并且在此基础上创建一个示例。通过阅读本系列中的文章,可以了解完整的应用程序集成的实现过程。第 2 部分将会刊登在下个月的 WebSphere Technical Journal 中,其中将介绍 WebSphere Integration Developer 中的 SOA 开发,包括如何构建简单的 SOA 应用程序。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=109142
ArticleTitle=IBM WebSphere 开发者技术期刊: WebSphere Integration Developer 指导教程——第 1 部分
publish-date=02222006