层 5：访问或表现层。尽管这一层经常超出了围绕 SOA 讨论的范围，但是它却变得越来越有意义。在这里我描述它因为标准越来越集中，比如用于 Remote Portlets Version 2.0 的 Web 服务和其他技术，这些技术追求在应用程序接口或者表现层来利用 Web 服务。你可以把它作为将来的层用来满足将来的解决方案的需求。注意到以下这两点是非常重要的：SOA 将用户接口从组件中分离出来；最终你需要提供从访问路线到服务或者合成服务的端到端解决方案。
层 6：集成（ESB）。这一层使服务可以集成，通过引入一系列可靠的性能的集合，比如智能路由，协议中介和其他转化机制，经常被描述为 ESB（参阅 参考资料）。Web Services Description Language（WSDL）制定了绑定，其包含提供服务的地址。另一方面，ESB 为集成提供了位置独立机制。
层 7：QoS。这一层提供了监视，管理和维持诸如安全，性能和可用性等 QoS 的能力。这是一个通过 sense-and-respond 机制和监测 SOA 应用程序健康的工具来进行的后台处理过程，包括 WS-Management 和其他相关协议的所有的重要的标准实现以及为 SOA 实现服务质量的标准。
通过什么步骤来进行基于服务的建模和架构
本节描述了如何利用遗留的投资，来 联合自顶向下的，业务驱动的手段和自底向上的手段。
基于服务的建模手段提供了建模、分析、设计技术和活动来定义 SOA 的基础。它通过在 SOA 的每一层定义元素以及在每一层作严格的架构决策来起到帮助作用。它通过联合服务鉴别的自顶向下、业务驱动方式和通过利用遗留资产和系统引导服务鉴别来实现这一点。
这样，高级别的业务过程功能性为大粒度的服务更加的具体化。小粒度的服务 -- 这些可以帮助实现高级别的服务 -- 通过检查遗留功能性和决定如何创建适配器、封装器，或者组合遗留系统来具体化系统内经常调用的期望功能性可以来鉴别。
最后，使用 针对服务的建模，你使用 跨部分手段来削减候选的可能已经被确定的服务的绝对数量。一个比较明智的手段应该是首先按照自顶向下来做，接下来进行目标服务建模，最后是自底向上的现有资产的遗留分析。消息是：你将项目的范围定义至一个可管理、实现的集合越快，你就能更快的通过聚焦在关键服务来公开组成 SOA 基础的服务描述来实现价值。
这个功能性业务需求和遗留系统中现有投资利用的结合，为那些想要快速赢得和移植他们的企业到一个现代的 SOA 的组织提供了有效的解决方案。通过基于服务的集成的软件应用程序的联合因此变得具备可能性。
基于服务的集成是 Enterprise Application Integration（EAI）的一个进化，在 EAI 中，所有的连接通过位置透明的 ESB 概念被基于标准的链接替换，并提供了一系列灵活的路由、中介和转化能力。
基于服务的建模：服务的分析和设计
迄今为止，我已经通过描述 SOA 设定了阶段。我同样展示了要想构建 SOA，你需要在你 SOA 的每个层中做关键架构决策，并且你的设计必须反映一系列依赖业务的服务和关于他们如何通过编排来合成到应用程序的决策。
与对象不同，你在 SOA 中需要考虑两个观点；他们是服务消费者和服务提供者。服务代理目前不是主流，并且在后面的部分终将被涉及到。
SOA 的设计策略并不从“自底向上”开始，这是 Web 基于服务途径常有的事情。你必须记住，SOA 更加有战略意义，并更加依赖于业务。Web 服务是 SOA 的巧妙实现。许多关键的活动和决策存在不仅仅影响集成架构，而且还影响企业和应用程序架构。他们包含两个 图 4 中描述的消费者和提供者的活动.
文章来源于领测软件测试网 https://www.ltesting.net/
