为已确定的服务定义消息规范时,考虑企业的消息标准(如果存在)很重要。如果没有定义消息标准,明智的作法是开发它们。 如果存在行业消息模式,建议您利用它们。 例如,已为金融业、政府、旅游业(OTA XML [Open Travel Alliance,http://www.opentravel.org/online_schema.cfm])定义了 XML 消息传递规范。 此外,OAGIS [开放式应用程序组,http://www.openapplications.org/index.htm] 还提供了不特定于行业的模式。
公用消息格式
公用消息是指在多层体系结构的各层间传送的消息。 通常情况下,用户界面信息被捕获并发送至控制器层,在业务或应用程序层中进行处理,然后再传递到持久层或后端旧系统。 在这些传送过程中,在各个层间交换的同一条消息都可能有不同的格式。 最关键的是在企业内就公用消息格式的标准达成一致,以便在所有不使用企业服务总线(ESB)或格式转换方面的代价很大的情况下克服所有格式转换开销。 ESB 的使用将省去许多协调、变换和路由。 这是 SOA
层模型中描述的集成层。
在某些情况下,它能够就出局消息和入局消息的格式达成一致。 公用消息格式的问题是关键的体系结构决策:您可以选择此处指定的“自己选择”、采用行业模型(如旅游行业的 OTA XML)或采用不特定于行业的模型(如 OAGIS
定义的模型)。 在某些情况下,此决策将使用公用企业消息格式来更新消息中的字段并将其传递到下一层进一步处理。 如果由于政治因素而无法实现此类公用模式,则可以设计将消息转换成内部公用消息格式的适配器。 它们也可以用作 ESB 的一部分。
ISV
考虑事项 :如果消息调用在
ISV 软件包内实现的服务,则可能需要对此类消息加以扩充,这样才能满足 ISV 软件包数据模型内的约束。 此类数据元素可通过分析在 ISV
软件包组件内实现的服务来确定,或通过 ISV 软件包由下至上的服务分析来确定。 由于在服务实现之前这些属性可能无法确定,因此一旦确定,可能需要将它们更新到公用消息。
公用消息格式和数据体系结构
一般而言,服务不应表示任何关于底层数据模型的信息。 而应该用于封装底层数据模型,这些模型的数据存储由实现服务的服务组件使用。 因此,作为查看、编辑、删除、添加搜索以及对数据库的其他操作的服务可能不是很好的候选服务,但可以如现今那样将它们用作底层组件操作。
定义概念、逻辑或物理数据模型的现有数据体系结构是定义公用消息格式所必需的源。 公用消息格式的定义应与数据体系结构工作和数据模型相协调。 此分析将确保实现新服务的服务组件的合适数据存储和模式的可用性。 如果需要向底层系统添加新的数据,则应增强现有的数据体系结构以适应新的服务。
在很多企业中,现有系统通常反映了通过批处理协作的纵向结构与数据岛的存在。 通过服务方法从隔离的数据存储迁移是可能的。 对服务供应商数据源的确定是在服务实现过程中完成的。
ISV 考虑事项:逻辑数据模型需要适应通常包含在 ISV 软件包中的预定义数据模型(通常为隐式)。 因此,在打包的应用程序与现有数据模型之间需要进行消息转移。 这通常是通过 ISV 提供的 API 完成的。 在 SOA 中,这些
ISV 数据模型的适配器变得很重要,尤其是在 ISV 没有通过服务显现其底层数据和功能的情况下。
请注意,在 ISV
数据模型可访问时,可以对模型进行定制以适应支持已确定服务所需的消息。 相反,如果数据模型不可访问,服务消息传递可能受到包含在 ISV
内的数据模型的约束。 也可以采用一种协调机制来解决此问题。 可在此环境中使用协调(例如 ESB 所提供的适配器)来支持与 ISV 软件包的连接。 ISV 数据模型还指示了除实施服务所必需的属性以外的其他属性。
与所有相关服务关联的公用消息格式
公用消息格式必须与各个服务的输入/输出消息的格式一致,因此它们被关联并分配以允许相应的服务在需要时使用并更新它们。 服务可能需要从公用企业消息格式中抽取信息或接收输出。 在“服务公用消息格式”模板中对它们进行了记录。
|