2. 定义服务的基本元素

    在相关的准备工作完成以后，我们将逐步开始接触服务的实现，首先我们会定义服务的基本元素，包括服务的消息格式和服务接口的定义，以及服务的分组。

    2.1 定义业务对象和服务接口

    在前面的系列文章中，我们经过分析已经能够给出服务之间的规约，现在是时候要开始在开发环境中实现这些定义了。

    在项目实施中，我们通常基于一些表格形式的规约进行开发，这些表格的定义基本上是以业务人员为主，是侧重于真实的业务数据的定义，可能会和以前的业务系统的实现有差别，但是请不要怀疑，毕竟，SOA系统并不是以前的业务系统的简单重构，而是需要我们从业务（Business）服务的角度，规划和设计企业的IT架构。

    这里给出一些示例：表4和表5。

    表4：服务消息规约示例

　  表5： 服务接口规约示例

    
　
　  2.1.1 业务对象

    业务对象（Business Object）简称BO，在某种程度上你可以认为BO就是SDO一种特例，关于BO的信息，请参考参考资料《深入了解WPS中的业务对象Business Object》。

    示例中的一个业务对象在WID中的定义如图2下所示。

    图2：Address业务对象。　

    
 
　  在使用WID实施SOA解决方案时，我们推荐将所有的公用的业务对象和服务接口实现于一个Library项目中，供所有需要的模块引用。对于模块内部的私有业务对象和接口，则由模块自己管理。

    BO之间的关系可能有如下几种，我们这里简单讨论处理这些关系的时候需要注意的要点：

    1 引用

    在WID中，虽然在业务集成视图提供了可视化的编辑BO的方式，但你仍然会不时的打开BO对应的XSD定义文件，进行一些手工的操作。

    例如，如果你在业务对象A中引用业务对象B，后来又删除了该引用，你仍然需要手工删除业务对象A对应的XSD的import。在SOA迭代的开发过程中，BO之间的关系会经常的发生变化，开发人员必须保证开发工具的视图和定义BO的XSD之间的一致。

    2 继承

    请注意WID支持BO之间的继承关系，其实现是通过XSD的extension来实现的，WSDL中的消息也是通过XSD来定义的，因此也支持继承。在一个复杂的系统中，业务对象不可能都是一个独立的存在，因此在定义BO的时候，你可能需要考虑继承。并且，我们更关注模块之间共享的BO，这些BO作为消息线索，将串联起主要的业务流程，具有非常明显的业务含义。

    例如：我们可能考虑一个抽象的汽车业务对象，派生出客车，货车等不同的业务对象，其对应的贷款规则可能会有变化，通过在流程中组件之间使用抽象的汽车类型，而某些组件内部使用具体类型，我们可以灵活处理，并且类型发生变化时并不影响主要的业务流程。

    3 映射

    在更为复杂的情况下，WID 支持BO之间的Mapping和Transformer ，从而支持接口之间的Mapping，当然，你也可以使用Mediation模块里面的XSLTTransform来实现消息的转换。

    例如保险系统的查询接口，需要使用保险人的姓名，地区，和身份证证件号作为输入，我们可以定义一个保险人查询条件业务对象，使用贷款申请人到保险人的映射来自动完成转换。

    实际项目中，在使用WID工具定义业务对象同时，应当尽量将所有的变更记录在案，并和设计文档保持同步。你可以采用自动化的方法，将注释保留在代码中，使用工具生成文档，这样自动保证设计文档和实现的同步。对于定义BO的注释，我们推荐在属性页的注释面板中添加适当的注释，对于在系统间流动的BO，会被不同的开发人员引用，适当的注释可以大量减少你的口舌。对于业务对象中属性，需要考虑到是不是数组，以及是不是必需等问题，我们应该合理的使用这些定义，可以在早期测试的时候发现很多问题。在项目实现过程中，一个微小属性的变化可能带来一系列的问题，因为BO中的属性是强类型的，并且通常会和WSDL接口和Java代码产生很紧密的关联，所以我们应当尽量的事先考虑周全。