【IT168 技术文章】

    我看IBM的SOA产品

    下文我对IBM的SOA产品是有些自己不成熟的看法的。在这里拿出来讨论一下。

    我的理解是，IBM的产品和SOA相关的主要是业务集成方面的。在IBM的蓝图中，业务集成方面的主要产品占据了业务进化生命周期的每一个步骤。

    Model     建模  Websphere Business Modeler

    Assemble  装配  Websphere Integration Developer

    Deploy    部署  Websphere Process Server

    Manage    管理  Websphere Business Monitor

    很叫人头疼的是，这里面每一个软件都不是那么容易用的，我大概用WAS Base和ND七八年了，都觉得以上这些软件产品曾经严重挑战了我的理解能力和耐心。下面一一简单说一下。

    1、Websphere Business Modeler 是一个流程建模工具，听起来就只需要画个图表达业务流程那么简单，而其使用绝对跟简单挂不上钩，如果纯粹的业务人员，受过培训也不容易用的好，软件的易用性一直是 IBM 的短板，在我们的客户做产品比较的时候曾被人比下去了。Websphere Business Modeler 原意也是给业务分析人员用的，即是 Business Analyst的角色，好的BA是兼具业务和IT背景的资深人员，这并非每个项目都会配备的角色，但是他的工作总是有人去做的。

    2、Websphere Integration Developer我觉得这是IBM为SOA Methodology 设计的最重要的工具，所有的SOA概念都在这一个工具中得到或多或少的体现，WebSevice, SCA, BPEL, ESB 都有支持，搞得清楚这个，就搞得清楚 IBM 的 SOA。简单来讲就是根据SOA概念来可视化的进行业务集成的开发工具。拖拖放放，再配置一下，就可以几个不同的服务连接集成起来，再整个UI 就可以创建新的Application。可惜这只是理想的说法，实际上也没那么简单。

    3、Websphere Process Server 就是IBM的流程服务器了，该服务器平台构建的次序是这样的 Websphere Application Server -> WAS Network Depolyment -> Websphere ESB Server -> Websphere Process Server。Websphere Process Server本身就是 IBM SOA 的运行平台，WebSevice, SCA, BPEL, ESB 这些内容都可以在上面部署和运行。

    4、Websphere Business Monitor业务流程监控工具，但是可监控的内容比业务流程多。新的 WPS 6.1.2搞了一个Business Space的概念，说是给业务人员监控所用的，可集成Websphere Business Monitor，加上可自定义的 Mashup UI视图，很是炫目，可惜我还没搞清楚。

    当然我们做一个应用系统的时候，还需要应用开发工具，其实应用开发工具是不包含在这里面的，在IBM的规划里面应用开发工具是在 Rational 系列中的（Rational software Architect和Rational Application Developer之类），我用的跟大家一样，Eclipse，通过Websphere Process Server提供的服务和接口调用相关功能。

    如果我们要用IBM Process Server发布一个简单的业务流程应用，而不涉及SOA呢，对不起，SOA特性是Build-In的，不管你用不用，甩也甩不掉。其实我想IBM是否可以搞个 Process Server Express 版本，提供一些更简单的特性和更合理的价格。大概IBM不愿意做这么没技术含量的东西，因为市面上的WorkFlow Engine产品太多了。

    另外 ，在这里面 Websphere Integration Developer 则包括了开发的时候所需的大部分东西，他可以代替 Websphere Business Modeler画BPEL，内建了用于开发测试的ESB Server、WPS，也包含了可以用来模拟、测试、监控的诸多工具，所以如果要学习IBM 的SOA，需得整一个这个。

    有关SOA的目标

    SOA的目标是快速和方便的集成，这个目标依赖于三个方面的内容： 接口（Interface）、接口实现（Implementation）、集成（Integration），如果有些 Java 基于接口编程的概念应该很容易理解

    1、接口（Interface）是服务（Service）的定义，例如 Java Interface， WSDL，定义了服务的输入和输出。

    2、接口的实现（Implementation）则是服务的（Service Component）具体实现了，传统意义上的编码大部分集中在这一块，服务实现包括了Java、BPEL、Business Rules、Human Task等等。*** 要注意 BPEL 在SOA 中只是一个服务组件类型，一种服务的实现方法而已，BPEL Engine当然是在WPS中已有的，这个大概是你所说的流程处理过程架构。

    3、集成（Integration）就是如何连接这些服务，这个工作（包括 【1】接口定义的工作）应该有一个专门的角色：业务集成设计人员（Business Integrater）来完成，WID通过在一个组件中导出（Export），另一个组件中导入（Import）的模式来连接两个服务的。由于接口的消息格式的不同，服务的连接需要转换，WID支持 Message Binding， SCA Binding，Webservice Binding，Http Binding等导入导出绑定，这些的绑定（binding）就允许接口消息转换，这个工作在 WID 里面是有可视化工具进行操作的，所以说没错，服务接口算是可生成的。而不同服务消息传输、转换等工作就是由企业服务总线（ESB）来实现的。这也是 Websphere ESB Server 在这个架构中的作用之一。

    上面的概念其实不难理解，我们用Java 编程的概念放大即可，我们写一个架构良好的java程序供调用是如何写的呢。

    1）定义接口 Interface，写一个接口类

    2）实现这个接口 Implementation，写一个实现类

    3）Import 接口类，就可以从别的java 类中调用该接口定义的方法了。

    可以想象一个应用系统，或者一个应用系统的某个模块就是一个java类，如何把这些java类连接起来，那么SOA就是如何把这些应用系统连接起来的。

    关于MDB

    本身 MDB 是一个异步操作，他的使用场景应该是这样的：

    1、当一个客户端传送一个JMS消息，触发MDB来处理特定操作；

    2、客户端并无需等待消息处理完成，即可自由进行后续的处理；

    3、mdb没有任何返回值，既然mdb调用是异步的，则不能用作需要在执行完后返回值的情况

    4、“在一个MDB没有结束的时候，那消息是不是将一直被占用”，我想这个消息被传送后，容器需要为mdb建立相关的消息上下文，连接等等，你可以说是被占用了，但是不会影响到消息发送者和其他的消息消费者。从这个意义上来讲，也谈不上什么占用。

    5、MDB 可以使用事务，BMT和CMT都可以，如果失败则回滚，并将消息放回队列。当仍然不涉及消息发送者。

    6、使用JMS作为传输机制去从mdb回到消息创建者得到一个反应是可能，这又是另一种做法。

    在上面提到的SOA方法论中，这个应该接近 Interface 接口中 One way operation（只有输入没有输出），然后export 成 Message Binding，这样的场景比较接近MDB被调用的情况。我回头查查 Webspehre Integration Developer 中有没有可以直接对 MDB的实现进行绑定和连接的可视化操作方式