• 服务 (Web服务定义语言[WSDL])
• Schemas
• 文档类型定义 (DTDs)
• 控件
• Beans
• Enterprise JavaBeans (EJB)
• Portlets
• 转换
• Application Views
• 事件
• 适配器

　　图1 这个示例参考模式基于创建应用程序时利用的公共基础架构，包括业务流程、应用程序互操作性和端点连通性重用组件。

　　图1 显示了一个参考模型的例子。模型中的每一层都要进行简单的介绍。可重用组件的元数据的角色就是帮助IT组织确定可重用组件在什么地方符合他们的参考模型，并确定新应用程序区分优先级开发的需要花费的时间。

　　组件参考模型
　　每个IT组织都发现有一个基于他们团队运作需要和技术经验最优的办法来分类他们的可重用组件。被IT选出来作为组件参考模型的最为重要的特性就是使用一致性。我们来回顾一下组件参考模型的一个例子，先从最普通的级别开始随后深入到业务流程级别。模型中的每一层阐述了在基于SOA的应用程序的演变过程中更高级别的成熟度。组件描述，如在它的元数据中所定义的，应该提供足够的关于组件的信息，使得他的分类能作为组件参考模型中某层的一员。

　　公共基础构件 是支持所有组件的基础，从组件维护的组件信息库到安全、监控、异常处理和现有产品（如OS、WebLogic、MQ、数据库等等）中可用的日志服务。这些产品中的一部分在预实现的基于标准组件的范围之内，这些组件提供广泛开放模式的基础，可以用在整个企业软件项目中。例如，在WebLogic Workshop内部，可以创建JavaServer Pages (JSP)并能定义页面流来控制在网络应用程序各个页面之间浏览。根据胡德理论，Workshop使用 Apache Struts 表示层框架，这样您就不必要创建自己的模型-视图-控制器[MVC]的实现。这样一来，您的组织甚至无需申请就能使用一个可重用实现模式。

　　端点连通性 是允许您提供综合业务服务的基础。需求很明确：从包含需求信息的资源中获得所需要的信息。

　　有时这些信息需要由人来提供。典型的收集信息的机制是通过写在纸张上的、通过网络、通过声音、通过手工收集等等方式形成的表格来收集这些信息。这些表格可以被多个业务流程所使用，这样它们就是可重用组件的候选对象。

　　当这些信息驻留在现有的应用程序中时，提供安全的、事务的、可伸缩的、可管理的（STSM）的连接来连接打包的、定制的和遗留的应用程序变得尤其重要。适配器提供这个功能使得这些终端系统能够相互交互。
具有STSM连接并未使它们能在业务流程中重用，在许多情况下，要求把应用程序信息的内部视图映射到一个信息的公共视图中。因此，包含用来获取所要映射的语法和语义信息的可重用转换也是可重用组件。

　　但是只有这些信息是不充分的，它必须被交付给客户。在编程过程中提供问题隔离的匿名服务的功能可以通过使用集成平台的消息代理功能来实现。这些消息代理服务，像事件驱动和基于内容的路由可以被打包成可重用组件。

　　最终作为SOA核心技术的Web服务是端点连接可重用组件的原型。

　　每一个企业都由自己的业务对象，它们对于定义业务流程是极为重要的。有时这些业务对象作为一个整体驻留在单个应用程序中，但是大多数情况下，业务对象的不同组件驻留在不同的企业应用程序中，并且组合流程需要创建一个对象的完整视图（因此您需要应用程序互操作性组件）。作为存在于所有企业的业务对象的一个例子是客户业务对象。

　　对象的应用程序独立视图称为规范化的业务对象，它在集成过程中使用。从独立应用程序视图进化到规范化的业务对象，需要业务验证和语法规则，以及不同格式之间的转换。通过提供这些业务对象和打包成框架的操作的一组统一视图，这些框架在应用程序开发过程中会利用，以一种独立于打包应用程序的方式（部分业务对象驻留），使企业能够交付外观一致的应用程序。

　　当这些规范化业务对象中的信息用于一个业务流程中，以便展示在一个企业到客户（B2C）门户中的信息时，会提高客户忠诚度、增加保持力和降低服务开销。在一个企业到雇员（B2E）门户，它推进了雇员的生产力和反应能力，这样降低了运作开销，而在一个企业到企业(B2B)门户，它推动了协作的效率并降低了履行订单的成本。

　　业务流程可重用组件是自动化和打包了的业务流程，这一方式下他们可以设计为一个较大业务流程的一部分。它展示了一个元数据驱动的接口，这样使得它能轻易地从别的业务流程中调用他们。两个最通用的业务流程组件的类型是过程自动化和工作流自动化。

　　过程自动化是指一个运行在黑盒环境中的、自动处理跨多个应用程序事务的端到端的过程。工作流自动化作为一个标准的过程组件包含过程而无需人工干预 。过程自动化的例子是一个从存储在单个数据库或者跨多个应用程序中的信息中确定交叉销售机会的流程。工作流自动化的例子是订单的异常批准流程。

　　业务流程组件提供了一个强大的工具来确保标准业务流程在整个企业中一致性。

　　现在，我们看一些元数据的例子。

　　元数据的XML Schema 表示
　　下面部分展示了为所有可重用组件维护的元数据的XML schema表示。正如前面所提到的，有几个元素的定义是直接来自于Dublin Core Metadata Element Set。为了易于区分来自DCMES 的元素，在它们的注释中被标识了一个（DC）。

　　元数据关于可重用组件的定义超出了分类学，它包括了组件描述和组件不同版本的实例化。正如前面提到的，为组件分类学定义的元数据用于标识组件参考模型中的层，元数据资产驻留在这些层中。
本文中展示的设计视图利用了一些形象的线性图，来帮助理解XML schema 文档，图2显示了最常用的图示。

图2 设计视图利用可视线性图来帮助理解XML schema 文档。这在本文中经常用到。

　　组件信息（Component information）。组件信息元素(图3)由三部分组成：描述、分类法和版本，有唯一的定义，唯一的分类法和一个或者多个版本。

图3 组件信息元素由三部分组成：描述、分类学和版本。

　　组件描述（Component description）。组件描述元素（图4）明确地确定了组件在所使用范围内的身份。组件的title是易读的，identifier通常是一个不透明的引用，二者都存储在信息库中。

　　可选的objective是用于描述这一组件定义背后的架构或业务因素。

图4 组件描述元素明确地确定了组件在所使用范围内的身份。

组件分类法（Component taxonomy）分类法(图5)由主题（subject）、类型（type）、格式（format）和可选的许多解决方案（solution）组成。元素主题是组件参考模型中的其中一层，类型元素是类型componentTypeId，它的值是来自于DCMI Type Vocabulary，格式是一个字符串（例如，Internet媒体类型列表[MIME]），而可选方案来源于特定的方案领域，例如自助服务，客户服务改进，信息合理化，扩展企业，或者纵向行业，例如电信，零售，财经服务，保健，制造业和物流等。


图5 分类法由主题、类型、格式和可选的许多解决方案组成。

组件版本（Component version） 在组件的生命周期中，很有可能会有几个版本。图6中的模型可以管理组件的几个版本，能做到这一点的重要原因是确保当组件扩展或者改进时并不是所有用户都必须随其而改变。


图6 组件版本模型能够管理组件和多个版本

　　所有组件的版本共享相同的组件描述和分类法，但是每一个单独的版本包含其自身的版本信息（information），负责人（principals），规格（metrics），文件（files），关系（relationships），备注（comments），语言（languages）和环境（environments）等信息。

　　可选的环境（environments）元素定义了组件在什么环境受到支持，例如WLI 8.1 SP2。

　　有些组件可能需要与用户交互或者可能发送消息到控制台或者日志文件。可选语言（language）元素用于存档组件支持的语言。这个字段也可以存档用于开发该组件的编程语言。

　　现在我们要讨论在组件版本中的其他元素
　　版本信息（Version information）。 信息帮助我们区分组件的各个版本（图7）。名字（name）是适于人阅读的组件版本的标识符，例如“2.0”或“beta3”。为了在信息库中存储组件，标识符（identifier）可能是一个不透明的引用，描述（description）是一些简洁地描述该版本组件功能的语句，为组件保留有有两个时间戳――组件创建的时间和最后一次修改的它的时间。状态（status）定义组件信息库中改进组件的当前阶段。状态可能的取值是PENDING_REVIEW、 APPROVED或者REJECTED。最后，可选关键字（keywords）在查找组件时很有帮助。


图7 信息用于帮助我们确定组件的特定版本。

　　版本负责人（Version principals）。 负责人是组件开发和支持者的实体(图8 )。创建者（creator）是组件的负责作者。发布者（publisher）把组件加入到组件信息库中。这里可以有定义为贡献者（contributor）和支持者（support）的实体。

图8 负责人是组件开发和支持者的实体。

　　版本关系（Version relationships）。 版本关系定义了组件的继承关系和依赖性（图9 ），这一模式支持线性继承，也就是说，每个版本可以有单个父亲（replaces）和单个孩子（isReplacedBy）。如果对于它的操作这个组件依赖于另外一个组件，这些关系存储在必需的（requires）元素中，并且如果这个组件是其他组件的依赖组件，那么这些关系就被存储在isRequiredBy元素中。

图9 版本关系定义了组件的继承关系和依赖性。

　　版本注解（Version comments）。版本注解（(图10)是现有版本用户提供反馈信息的地方。每次用户（user）提供反馈信息，一个时间戳填写时间（entryDate） 连同注释（comment）的文本和注释类型（type）被存储起来。注释的类型被定义为NOTE、BUG和CHANGE_REQUEST。

图 10 版本注解是现有版本用户提供反馈信息的地方。

　　版本规格（Version metrics）版本规格 (图11)用于理解组件的ROI并提供关于期望服务水平的潜在用法，组件的ROI评估通过由于组件重用而产生的时间节约数量来获得，源于devTime和userApplications的数目。为了使这个数字可靠，从信息库中获得组件的过程应该包括获得潜在的用户应用程序。您也需要有一个指明该组件版本不再被应用程序使用的过程。

图11 版本规格用于理解组件的ROI并提供关于期望服务水平的潜在用法。

　　对于正在使用的组件，提供有关服务水平协议（SLA）的期望值是非常重要的。在SLA中有两个主要的服务方面需要进行度量。第一个是关于服务的可用性（availability），这一模式的建议度量方法是提供一个当服务失效（在它正常运转时间内）时修复它所要花费的平均时间值。第二个方面是性能（performance），性能是由响应时间（responseTime）和最大调用（maxInvocations）的值来提供的。所有SOA值都应该分别由服务的用户来提供，而不是服务的提供者。

　　版本文件（Version files）版本文件（参见图12 ）是包含关于组件及其资料的实际资源、位编码或对象比特的文档。组件容器（componentContainer）的URI提供了访问组件的位置，artifactsContainer保存了文档，而可选的sourceControl定义了资源控制系统中资产的位置（location）和版本（version）。

图12 版本文件是包含关于组件及其资料的实际资源、位编码或对象比特的文档。

　　实体标识（Entity identification）实体是参加创建、发布或者组件支持的一组用户（users）和组（groups）（请看 图13）。用户被表示为空白分离的一个用户名列表，而组被表示为空白分离的组名列表。

图13 实体是参加创建、发布或者组件支持的一组用户和组。

　　重用软件开发过程
　　软件开发过程需要包括架构师对设计和代码的检查，架构师在利用可重用组件方面致力于理解、教育和指导开发团队。这会帮助在处理软件组件重用过程中避免两个与使用相关的问题。第一个问题是过分使用——介绍了比实现解决问题所需要的更多的组件。这就会产生诸如增加复杂性和性能问题等期望之外的结果。另一方面，组件的低利用率会产生代码重用的问题，这会导致增加开发时间和开销以及维护问题。给出了企业应用软件的复杂性之后，期望组织中的所有开发人员都能获得组件使用的完美平衡不是一件切实可行的事，因此，为了完成这一目标，架构团队这一角色是是极为重要的。

　　架构团队的责任是：

• 检查组件和开发项目的开发过程
• 在所有开发项目中进行代码检查会话
• 定义验收计划并执行组件的验收测试
• 管理向组件信息库中的提交
• 通过关注在解决方案开发过程中识别正确的模式和合适的组件，提供有关组件利用的培训和教育
• 管理组件的依赖性和生命周期
• 管理组件的参考模型