本文共 4824 字,大约阅读时间需要 16 分钟。
本文介绍如何利用 IBM® Rational® Software Architect 7.0.0.2 或之后的版本中包含的 UML-to-SOA 转换工具,将软件服务的 UML 模型转化为具体领域的面向服务体系架构(service-oriented architecture,SOA)模型。该转换可以作为所有针对具体软件实现和运行时的转换扩展的基础。UML-to-SOA 转换一般将 UML 模型作为源,并创建具体领域的 SOA 输出物。转换输出完全依赖于所选择的转换扩展。总的来说,转换扩展生成可以部署到运行时计算机或服务器上的具体领域的软件工件。然后扩展可以作为其他工具的输入,进行进一步开发和部署。
IBM® Rational® Software Architect 中的 UML-to-SOA 的转换工具包括基于 Service Component Architecture(SCA)的 SOA 转换工具,它使用 Service Component Definition Language(SCDL)来表示元数据。UML-to-SOA 转换工具将生成准备导入到 IBM® WebSphere® Integration Developer 6.0.2 或之后版本中,用于进一步开发、测试,和部署的输出。除了公共的转换配置选项外,UML-to-SOA 转换工具还提供具体的配置属性。
图 1 展示了 UML-to-SOA 转换的结构。
UML-to-SOA 转换工具是由 UML-to-SCDL 转换扩展而来,它负责创建 SCDL 模块和库工程。
包含于 Rational Software Architect 中的 UML-to-SCDL 转换工具提供四种不同的扩展,并且有两组扩展:
UML-to-BPEL 转换工具使用 UML-to-WSDL 转换和 UML-to-XSD 转换来创建 WSDL(Web Service Description Language,Web 服务描述语言)端口类型和 XSD Schema Datatypes。同样的,UML-to-WSDL 转换使用 UML-to-XSD 转换来创建 XSD Schema Datatypes。
UML-to-SOA 转换用于处理软件服务的 UML 模型。
UML-to-SOA 转换的预期的源是一个完整的应用或没有应用 UML 2.0 Profile for Software Services 的 UML 模型。换句话说,转换可以将一个或多个表示服务提供者的 UML 包或个别的 UML 组件作为源。如果将 UML 模型或包选为源,那么 UML-to-SOA 转换就导航到所选的模型或包,并为每个服务提供者创建必要的 SCDL 工件。UML-to-SOA 转换支持选择多个 UML 元素作为转换的源。
图 2 是 UML 模型(在左边)的片段,用 CreditManager 服务提供者的外部视图展示 CreditManager 服务提供者和 UML 类图(在右边)。
UML-to-SOA 转换生成输出,导入到 IBM WebSphere Integration Developer 6.0.2 和之后版本中用于进一步开发、测试,和部署。转换可以接受工作区中任意工程为目标。
提示:
您可以创建新的目标工程,如果需要需要一个目标工程,在 Transformation Configuration 编辑器中的 Source and Target 页面中单击 Create New Target Container。对每个服务提供者,转换创建一个模块工程。除了典型的工程文件以外,例如 manifest.mf、.project、.classpath,和 .runtime,转换还创建 sca.module 文件,加上扩展名为 component、export,和 import 的表示 SCDL 模块中的各种元素的文件。模块工程引用了一个或多个包含对接口和业务对象的定义的库工程。
图 3 展示了 UML-to-SOA 转换工具所创建的模块工程的典型结构。这是个展开的视图,展示了 UML-to-SOA 转换所创建的 com.acme.creditmanagement.CreditManager 模块工程。
对于每个 UML 接口,转换会创建一个单独的 WSDL 文件。对于每个 UML 参数类型(数据类型),除了 UML 基本类型和内嵌于 XSD 中的简单类型,转换会创建单独的 XSD 文件。根据转换源的结构,会在单个 Library 工程或多个 Library 工程中创建 WSDL 和 XSD 资源。图 4 展示了 UML-to-SOA 转换所创建的 CreditManagement 库工程。
以下表介绍了源和输出对象之间的映射。
源 | 输出 |
---|---|
拥有至少一个所提供的接口的 UML 组件 | WID 模块工程SCDL 模块 |
拥有至少一个所提供的接口 的 UML 组件,其所拥有的行为是作为 UML Activity | WID 模块工程SCDL 模块工程实现 BPEL 的 SCDL 组件 |
通过 UML 展示出的所提供的接口表示服务提供者的 UML 组件的端口 | SCDL 导出 |
通过表示软件服务的 UML 组件的 UML 端口展示出的所需的接口 | SCDL 导入 |
表示软件服务的 UML 组件的 UML 部件 | SCDL 组件 |
内部或外部端口所引用的所提供的接口 | SCDL 接口WSDL 接口 |
内部或外部端口所引用的所需的接口 | SCDL 引用WSDL 接口 |
所引用的接口的 UML 方法 | SCDL 方法 |
UML 接口或 WSDL PortType 所引用的数据类型 | XSD 数据类型 |
UML 连接器 | SCDL 线 |
根据特殊的软件服务的设计,UML-to-SOA 转换生成不同类型的 SCDL 模块。关于用 UML 设计软件服务的详情可以在前面的关于 SOA 建模的文章中找到。
图 5 是 UML 模型的一个片段,显示了将 Customer Order Handling UML 活动作为所拥有的行为的 UML 组件所表示的 Customer Order Handling 服务提供者。
对于服务提供者的设计,转换创建包含实现 BPEL 的单个 SCDL 组件的 SCDL 模块工程(参见图 6)。要了解将 UML 活动映射为 BPEL 过程的详细情况,请参见引自中,标题为“从 UML 到 BPEL”的来自 SOA 建模系列的文章。
图 7 展示了 UML 组成结构图,它展示了 Customer Order Handling 服务提供者的分解。
在这种情况下,转换为服务提供者的每个 UML 部分创建 SCDL 组件,并且从而将这些组件捆绑到代表服务提供者的 UML 组件的内部结构上(参见图 8)。
由 UML 组件通过 UML 端口提供的,代表服务提供者的所有接口成为 SCDL 导出。通过 UML 端口显露出的所有所需的接口成为 SCDL 导入。在该实例中,通过 myRole 端口所显露的提供了的 CustomerOrderHandling 接口用于生成 myRoleExport.export 文件。OrderVerification、PaymentHandling、CustomerServiceRepresentative,和 AccountManager 端口用于创建相应的导入文件。
一些数据类型库成为了特殊行业的推荐的或官方的标准。举例来说,Health Level Seven(HL7),它是在卫生保健领域中执行的许多 ANSI 认可的标准开发组织(ANSI-accredited Standards Developing Organizations)之一,提供 XSD 格式的临床和管理数据标准。在许多情况下,对具体行业的类型和数据集的使用是软件的关键需求。
要实现该需求,软件服务的 UML 模型可能使用对现有 XSD 类型的引用。在这种情况下,UML-to-SCDL 转换创建一个库工程,并且将包含被引用的 XSD 数据类型的 XSD 资源从其父工程中拷贝到库工程中,包括文件夹结构和所有用 XSD include 或 XSD import 引用的 XSD 方案。创建的库工程的名字与包含最初被引用的 XSD 方案的工程的名字相同。如果被包含或被导入的 XSD 方案在不同的工程中,那么转换将创建相应的库工程,并且在需要处添加工程依赖。
软件服务的 UML 模型用与现有的 XSD 数据类型相似的方式使用对现有 WSDL 端口类型的引用。转换对 WSDL 端口类型的引用的处理方式与对 XSD 数据类型的一样。利用通过 XSD include 或 XSD import 引用的 WSDL 导入和 XSD 方法,转换为在 UML 模型及所有被引用的 WSDL 文件中引用的 WSDL 端口类型创建所有必要的库工程。
UML-to-SOA 转换通过引用现有 Java 接口和类作为源来支持软件服务的 UML 模型。这令您能够将新的服务设计为已经拥有 Java 实现并且通过 Java 接口来显露的现有服务的聚集或组合。当转换在解析源模块的过程中遇到 Java 接口或类时,它创建 Java 工程的副本。副本包含 Java 源代码,以及它所依赖的所有 Java 工程,这些被转移到被选为转换目标容器的工程中。
要创建、完成,并测试 Web 应用程序,转换输出必须被导入到 WebSphere Integration Developer 中(通过选择 File > Import > Existing Projects into the Workspace)。所有被转换创建的工程必须被一个个导入到 WebSphere Integration Developer 工作区中。被导入的工程包含依赖关系。如果以错误的顺序导入工程,那么构建可能有错。在这种情况下,简单地清除并重新构建所有被导入的工程。
然后,在 WebSphere Integration Developer 中完成这些任务:
您可以在本系列最后一篇文章中(向 SOA 转换:第 4 部分. UML 到 BPEL)找到更多关于 SOA 转换的信息。同样,要了解额外的信息,务必查看中的引用和链接。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14789789/viewspace-420465/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-420465/