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 實現服務質量的標準。
?