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. 開發(fā)過程
盡管以服務(wù)為中心的企業(yè)集成在開發(fā)階段和普通的應(yīng)用開發(fā)并沒有本質(zhì)的區(qū)別，但是它在角色，職責(zé)、工具和方法還是有不少自己的特色。下圖匯總了本文示例中開發(fā)角色，職責(zé)，開發(fā)方法和工具，僅供大家參考。
?
SOA 的一個架構(gòu)模板
SOA 的一個抽象觀點將它描述為與業(yè)務(wù)過程結(jié)合在一起的合成服務(wù)的部分分層架構(gòu)。 圖 3 呈現(xiàn)了這種類型的架構(gòu)。
服務(wù)和組建之間的關(guān)系是，企業(yè)級的組件（大粒度的企業(yè)或者業(yè)務(wù)線組件）實現(xiàn)該服務(wù)并且負責(zé)提供它們的功能和維持它們的服務(wù)質(zhì)量。通過組合這些公開的服務(wù)到合成的應(yīng)用程序，就可以支持業(yè)務(wù)過程流。綜合的架構(gòu)通過使用 Enterprise Service Bus（ESB）支持這些服務(wù)、組件和流程的路由、中介和轉(zhuǎn)化。為了服務(wù)質(zhì)量和非功能性的需求，必須監(jiān)視和管理已經(jīng)部署的服務(wù)。
圖 3：SOA 層
對于每一層，你都必須做設(shè)計和架構(gòu)決定。因此，為了幫助用文件說明你的 SOA，你可能應(yīng)該創(chuàng)建文檔，由每個層相應(yīng)的部分所組成。
這里是為你的 SOA 架構(gòu)文檔設(shè)計的模板：
- 范圍 <此架構(gòu)適用于企業(yè)的哪個領(lǐng)域>
- 操作系統(tǒng)層
- 打包的應(yīng)用程序
- 自定義應(yīng)用程序
- 架構(gòu)決策
- 企業(yè)組件層
- 企業(yè)組件支持的功能范圍
- <這個企業(yè)組件支持業(yè)務(wù)領(lǐng)域、目標和過程>
- 關(guān)于控制的決策
- <作為這個客戶端組織內(nèi)部企業(yè)組件來選擇某物的標準>
- 架構(gòu)決策
- 服務(wù)層
- 服務(wù)分類表
- 架構(gòu)決策
- 業(yè)務(wù)過程和合成層
- 業(yè)務(wù)過程可以表現(xiàn)為舞蹈編排（choreographies）
- 架構(gòu)決策
- <哪一個過程需要編排在舞蹈編排里面以及哪一個鑲嵌在應(yīng)用程序里面？>
- 訪問或者表現(xiàn)層
- <證明這層中 Web 服務(wù)和 SOA 的含意；即便要。例如，在用戶接口級別上調(diào)用 Web 服務(wù)的 portlet 的使用，以及在此層機能上的含意。>
- 集成層
- <包含 ESB 因素>
- <我們?nèi)绾未_保使用服務(wù)的客戶端系統(tǒng)級的一致性（SLA）和服務(wù)質(zhì)量（QoS）？>
- 安全問題和決策
- 性能問題和決策
- 技術(shù)和標準的局限性以及決策
- 服務(wù)的監(jiān)控和管理
- 描述和決策
現(xiàn)在，讓我們更加仔細的描述一下每一層以及每一層之間的合成。
層 1：操作系統(tǒng)層。本層包含現(xiàn)有的自定義構(gòu)建的應(yīng)用程序，也叫做 遺留系統(tǒng)，包含現(xiàn)有的 CRM 和 ERP 打包應(yīng)用程序，以及 較舊的基于對象的系統(tǒng)實現(xiàn)，還有業(yè)務(wù)智能應(yīng)用程序。SOA 的復(fù)合層架構(gòu)可以利用現(xiàn)有的系統(tǒng)并且用基于服務(wù)的集成技術(shù)來集成它們。
層 2：企業(yè)組件層。本層由那些負責(zé)實現(xiàn)功能和保持公開服務(wù) QoS 的企業(yè)組件組成。這些特殊的組件是企業(yè)和業(yè)務(wù)單元級支持的企業(yè)資產(chǎn)的受管理和控制的集合。 同企業(yè)范圍資產(chǎn)一樣，他們通過架構(gòu)最佳實踐應(yīng)用程序來負責(zé)確保 SLAs 的一致。大多數(shù)情況下，本層使用基于容器的技術(shù)，比如實現(xiàn)組件、負載均衡、高可用性和工作量管理的應(yīng)用服務(wù)器。
層 3：服務(wù)層。業(yè)務(wù)選擇來支持和公開的服務(wù)處在這一層。它們可以被 發(fā)現(xiàn)或者直接靜態(tài)綁定，接下來被調(diào)用，或者可能的話，編排到合成服務(wù)中。這個服務(wù)公開層同樣提供了獲取企業(yè)范圍組件，業(yè)務(wù)單元特定組件，以及有些情況下，特定項目組建的機制，并且以服務(wù)描述的形式具體化了他們的接口子集。因此，企業(yè)組件使用它們接口提供的功能在運行時提供服務(wù)實現(xiàn)。在這一層的接口公開為一個服務(wù)描述，在這層中他們被公開以提供使用。他們可以獨立存在或者作為合成服務(wù)。
層 4：業(yè)務(wù)過程合成或編排層。第三層中公開的服務(wù)的合成和編排在這一層中被定義。通過配合、編排，服務(wù)被綁定成一個流程，并且從而作為單獨的應(yīng)用程序而共同作用。這些應(yīng)用程序支持特殊的用例和業(yè)務(wù)過程。這里，可視的流程合成工具，比如 IBM? WebSphere? Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用來設(shè)計應(yīng)用程序流程。
層 5：訪問或表現(xiàn)層。盡管這一層經(jīng)常超出了圍繞 SOA 討論的范圍，但是它卻變得越來越有意義。在這里我描述它因為標準越來越集中，比如用于 Remote Portlets Version 2.0 的 Web 服務(wù)和其他技術(shù)，這些技術(shù)追求在應(yīng)用程序接口或者表現(xiàn)層來利用 Web 服務(wù)。你可以把它作為將來的層用來滿足將來的解決方案的需求。注意到以下這兩點是非常重要的：SOA 將用戶接口從組件中分離出來；最終你需要提供從訪問路線到服務(wù)或者合成服務(wù)的端到端解決方案。
層 6：集成（ESB）。這一層使服務(wù)可以集成，通過引入一系列可靠的性能的集合，比如智能路由，協(xié)議中介和其他轉(zhuǎn)化機制，經(jīng)常被描述為 ESB（參閱 參考資料）。Web Services Description Language（WSDL）制定了綁定，其包含提供服務(wù)的地址。另一方面，ESB 為集成提供了位置獨立機制。
層 7：QoS。這一層提供了監(jiān)視，管理和維持諸如安全，性能和可用性等 QoS 的能力。這是一個通過 sense-and-respond 機制和監(jiān)測 SOA 應(yīng)用程序健康的工具來進行的后臺處理過程，包括 WS-Management 和其他相關(guān)協(xié)議的所有的重要的標準實現(xiàn)以及為 SOA 實現(xiàn)服務(wù)質(zhì)量的標準。
?