Table 1. SOA layers of adoption
|
Adoption level
|
Name
|
Description
|
| 1 |
Implementing individual Web services |
Creating services from tasks contained in new or existing applications |
| 2 |
Service-oriented integration of business functions |
Integrating services across multiple applications inside and outside the enterprise for a business objective |
| 3 |
Enterprise-wide IT transformation |
An architected implementation enabling integration across business functions throughout an enterprise |
| 4 |
On Demand Business Transformation |
Broad transformation of existing business models or the deployment of new business models |
Table 2. The six approaches to SOA
|
Approach
|
Description (typical project owner characterization)
|
Qualifications
|
| Business process driven |
My business processes need to tap into resources, and each activity requires the invocation of IT functionality; I want that functionality to be available in a flexible, replaceable way. |
Top-down |
| Tool-based MDA |
I want to define a model (business model) and then let my tools generate the detail for me. |
Top-down |
| Wrap legacy |
I have existing systems I have been investing heaviliy on, but they are not resilient. I want new functionality added quickly, but these systems are partitioned. They are silos where functions are locked into them. |
Bottom-up |
| Componentize legacy |
Decompose the monolithic legacy systems into modules using compiler-based tools. |
Bottom-up |
| Data-driven |
Provide access to information using services without having to expose schemas or implementation decisions on the provider side. |
Data-focused |
| Message-driven |
"Just want to have these systems integrate, communicate, over standard, non-proprietary protocols." |
Service-Oriented Integration of Applications and Systems |
Table 3. Patterns and their corresponding benefits
|
Context
|
Pattern
|
Applicability
|
| Silo; concentrated functionality |
Hard-coded (not a pattern, but a point in time state) |
Point in time; low risk; low-changing, high-performance systems |
| Distributed; multi-point of access |
Point-to-point exposure |
Expose existing functionality rapidly; unlock value fast; access embedded functionality |
| Wrap a legacy function and make it callable through Web services |
Service adaptor |
Consumer needs access to functionality that is not service-enabled ( access to a legacy system through a service invocation, for example -- a Web service) |
| Access a service using its proxy if you do not have direct access to the service provider?s service description and are unable to directly invoke the service |
Service proxy |
Provides consumers with an SOA interface |
| Provide flexibility in the choice of the service provider |
Remote service strategy |
Provides flexibility in changing service providers based on quality of service or functionality considerations. This opens up possibilities in expediting mergers and acquisitions and flexible alteration of the provider when you consolidate application portfolios. |
| Eliminate redundant functionality; refactor and consolidate or, in some cases, replace existing systems |
Single point of access |
Provides one access point to a number of potential variants in functionality. A service strategy often requires a single point of access. |
| One project or LOB at a time, yet relies on others for some functions not yet exposed as services |
Virtual provider |
Non-existent providers; ramp up service critical mass |
| Single point of access |
Service integrator |
Routing, transformation |
| General enterprise integration approach |
Enterprise service bus |
Mediation; routing; transformation, policies, rules, events; inside the organization or between partners in ecosystem/value-net |
| The Nirvana of SOA; dynamic reconfiguration through context-aware services relying on business domain specific capabilities |
Integrated service ecosystem |
Provides dynamic configuration capabilities to a set of semantically interrelated industry specific business partners that leverage and recombine the ecosystem capabilities to provide greater value to themselves and the ecosystem as a whole |
Often an initial challenge is the concrete determination of the value proposition for using SOA within a project, line of business, or organization. This has to do with flexibility and the ability to alter the actual service provider who implements a service once their quality of service dwindles or they fail to provide the required functionality. This flexibility, which is the primary value of SOA, is overcome by understanding the steps in achieving flexibility through a remote service strategy. There are two more challenges that we describe and overcome with the use of patterns presented here.
SOA is a journey of gradual, small transformations that increasingly decouple service descriptions from service implementations offered by multiple service providers. The solutions below are descriptions of how these issues have been recurrently solved and may serve as a pattern to help you on your next project. Like any other pattern, these must also be adapted to fit the context and the forces that shape your individual problem space: the tradeoffs and considerations of your project, whether organizational or technical, make a difference, and you can determine if you need to skip a step from one pattern to another or to partially implement the pattern
The purely object-oriented strategy pattern primarily relies on inheritance-based polymorphism to create a family of interchangeable algorithms that are swapped out based on context. Rather than have an object hierarchy, in an SOA context, we need to be able to change the service provider with minimal or no impact on the consumer?s perception of the service, thus varying the actual implementer of the service description. The implementer may, in most cases, be a provider of a remote unit of functionality, somewhere in the internal network or Internet. Therefore, for
example, a service provider for a VerifyAddress service in an OrderEntry application may need to be changed because our quality of service needs have changed due to higher transaction volumes or security constraints. Or, the provider has decided to charge twice the amount for the same basic service, which we have relied on, in the past. Now, we would like to have the flexibility of changing service providers with IT and Business impunity, which means minimal changes to IT systems and no impact on the business or customer experience in their online shopping experience.
以上是今天看得两篇英文文章中一些摘要，文章很长，说实话没看太明白。只能在文章中找一些比较重要的东西贴在这，希望能有用。
原文链接：http://www-128.ibm.com/developerworks/webservices/library/ws-soa-soi/
http://www-128.ibm.com/developerworks/webservices/library/ws-soa-soi2/
6. 开发过程
尽管以服务为中心的企业集成在开发阶段和普通的应用开发并没有本质的区别，但是它在角色，职责、工具和方法还是有不少自己的特色。下图汇总了本文示例中开发角色，职责，开发方法和工具，仅供大家参考。
SOA 的一个架构模板
SOA 的一个抽象观点将它描述为与业务过程结合在一起的合成服务的部分分层架构。 图 3 呈现了这种类型的架构。
服务和组建之间的关系是，企业级的组件（大粒度的企业或者业务线组件）实现该服务并且负责提供它们的功能和维持它们的服务质量。通过组合这些公开的服务到合成的应用程序，就可以支持业务过程流。综合的架构通过使用 Enterprise Service Bus（ESB）支持这些服务、组件和流程的路由、中介和转化。为了服务质量和非功能性的需求，必须监视和管理已经部署的服务。
图 3：SOA 层
对于每一层，你都必须做设计和架构决定。因此，为了帮助用文件说明你的 SOA，你可能应该创建文档，由每个层相应的部分所组成。
这里是为你的 SOA 架构文档设计的模板：
- 范围 <此架构适用于企业的哪个领域>
- 操作系统层
- 打包的应用程序
- 自定义应用程序
- 架构决策
- 企业组件层
- 企业组件支持的功能范围
- <这个企业组件支持业务领域、目标和过程>
- 关于控制的决策
- <作为这个客户端组织内部企业组件来选择某物的标准>
- 架构决策
- 服务层
- 服务分类表
- 架构决策
- 业务过程和合成层
- 业务过程可以表现为舞蹈编排（choreographies）
- 架构决策
- <哪一个过程需要编排在舞蹈编排里面以及哪一个镶嵌在应用程序里面？>
- 访问或者表现层
- <证明这层中 Web 服务和 SOA 的含意；即便要。例如，在用户接口级别上调用 Web 服务的 portlet 的使用，以及在此层机能上的含意。>
- 集成层
- <包含 ESB 因素>
- <我们如何确保使用服务的客户端系统级的一致性（SLA）和服务质量（QoS）？>
- 安全问题和决策
- 性能问题和决策
- 技术和标准的局限性以及决策
- 服务的监控和管理
- 描述和决策
现在，让我们更加仔细的描述一下每一层以及每一层之间的合成。
层 1：操作系统层。本层包含现有的自定义构建的应用程序，也叫做 遗留系统，包含现有的 CRM 和 ERP 打包应用程序，以及 较旧的基于对象的系统实现，还有业务智能应用程序。SOA 的复合层架构可以利用现有的系统并且用基于服务的集成技术来集成它们。
层 2：企业组件层。本层由那些负责实现功能和保持公开服务 QoS 的企业组件组成。这些特殊的组件是企业和业务单元级支持的企业资产的受管理和控制的集合。 同企业范围资产一样，他们通过架构最佳实践应用程序来负责确保 SLAs 的一致。大多数情况下，本层使用基于容器的技术，比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。
层 3：服务层。业务选择来支持和公开的服务处在这一层。它们可以被 发现或者直接静态绑定，接下来被调用，或者可能的话，编排到合成服务中。这个服务公开层同样提供了获取企业范围组件，业务单元特定组件，以及有些情况下，特定项目组建的机制，并且以服务描述的形式具体化了他们的接口子集。因此，企业组件使用它们接口提供的功能在运行时提供服务实现。在这一层的接口公开为一个服务描述，在这层中他们被公开以提供使用。他们可以独立存在或者作为合成服务。
层 4：业务过程合成或编排层。第三层中公开的服务的合成和编排在这一层中被定义。通过配合、编排，服务被绑定成一个流程，并且从而作为单独的应用程序而共同作用。这些应用程序支持特殊的用例和业务过程。这里，可视的流程合成工具，比如 IBM® WebSphere® Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用来设计应用程序流程。
层 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 实现服务质量的标准。