Terry.Li-彬

看到SOA的一堆名詞，讀者可能會(huì)感到迷惑，有必要結(jié)合實(shí)際的應(yīng)用環(huán)境進(jìn)一步闡釋SOA的相關(guān)概念。

總體框架

圖1所示的就是一個(gè)SOA應(yīng)用系統(tǒng)的大體框架結(jié)構(gòu)。它大體上可以分為五個(gè)部分：

● 展現(xiàn)層（presentation）：圖1中5區(qū)，通過portal等技術(shù)建立展現(xiàn)平臺(tái)，方便用戶在這個(gè)界面上提出服務(wù)請求。

● 業(yè)務(wù)處理建模（business process modeling）：圖1中的4區(qū)，SOA元模型從MDA中繼承了平臺(tái)無關(guān)模型來對(duì)業(yè)務(wù)處理過程建模。這一部分獨(dú)立于服務(wù)設(shè)計(jì)和部署層。模型驅(qū)動(dòng)架構(gòu)MDA（Model Driven Architecture）的主要缺陷是在模型設(shè)計(jì)階段就對(duì)需求有完整的描述，而且沒有需求變更的反饋機(jī)制。SOA通過添加敏捷方法AM來應(yīng)對(duì)需求變更的情況。

● 服務(wù)層(Services): 圖1中的3區(qū)，整個(gè)SOA的核心層，它承上啟下，對(duì)上響應(yīng)業(yè)務(wù)模型，對(duì)下調(diào)用相關(guān)組件群完成業(yè)務(wù)需求,形成“業(yè)務(wù)驅(qū)動(dòng)服務(wù)、服務(wù)驅(qū)動(dòng)技術(shù)”的SOA事務(wù)處理格局。服務(wù)可以根據(jù)粒度分層。雖然細(xì)粒度提供了更多的靈活性，但同時(shí)也意味著交互的模式可能更為復(fù)雜。粗粒度降低了交互復(fù)雜性，但敏捷性卻下降。

● 企業(yè)組件層（enterprise components）：圖1中的2區(qū)，這里是相關(guān)組件發(fā)揮作用的場所。這些組件是平臺(tái)相關(guān)的。因?yàn)榈搅诉@一層，許多底層軟硬件平臺(tái)的特性已經(jīng)不再透明了。

● 系統(tǒng)軟件層(Operational System):圖1中的1區(qū)，這一層包括操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、CRM、ERP、商業(yè)智能(BI)等異構(gòu)系統(tǒng)，是一個(gè)集成的平臺(tái)。

除此之外，諸如QoS、安全性等(圖1中7區(qū))也是SOA架構(gòu)的組成部分。

在上面的介紹中，自上而下有一條線，如圖2所示，由業(yè)務(wù)建模開始，通過定義業(yè)務(wù)過程，得到服務(wù)模型，它是平臺(tái)無關(guān)的，實(shí)現(xiàn)了模型與實(shí)現(xiàn)的分離。再通過設(shè)計(jì)組件群，得到平臺(tái)相關(guān)的組件模型。

實(shí)施原則

Jason Bloomberg在其《Principles of SOA》中指出，SOA的實(shí)踐必須遵循以下原則：

● 業(yè)務(wù)驅(qū)動(dòng)服務(wù)，服務(wù)驅(qū)動(dòng)技術(shù)。從本質(zhì)上說，在抽象層次上，服務(wù)位于業(yè)務(wù)和技術(shù)中間。面向服務(wù)的架構(gòu)設(shè)計(jì)師一方面必須理解在業(yè)務(wù)需求和可以提供的服務(wù)之間的動(dòng)態(tài)關(guān)系;另一方面，同樣要理解服務(wù)與提供這些服務(wù)的底層技術(shù)之間的關(guān)系。

● 業(yè)務(wù)敏捷是基本的業(yè)務(wù)需求。SOA考慮的是下一個(gè)抽象層次：提供響應(yīng)變化需求的能力是新的“元需求”，而不是處理一些業(yè)務(wù)上的固定不變的需求。從硬件系統(tǒng)以上的整個(gè)架構(gòu)都必須滿足業(yè)務(wù)敏捷的需求，因?yàn)椋赟OA中任何的瓶頸都會(huì)影響到整個(gè)IT環(huán)境的靈活性。

● 一個(gè)成功的SOA總在變化之中。SOA工作的場景，更像是一個(gè)活的生物體，而不是像傳統(tǒng)所說的“蓋一棟房子”。IT環(huán)境惟一不變的就是變化，因此面向服務(wù)架構(gòu)設(shè)計(jì)師的工作永遠(yuǎn)不會(huì)結(jié)束。對(duì)于習(xí)慣于蓋房子的設(shè)計(jì)師來說，要轉(zhuǎn)向設(shè)計(jì)一個(gè)活的生物體要求有嶄新的思維方式。SOA的基礎(chǔ)還是一些類似的架構(gòu)準(zhǔn)則。

與其他概念的關(guān)系

1. SOA與Web Services的關(guān)系

SOA構(gòu)架是獨(dú)立于技術(shù)實(shí)現(xiàn)的。SOA并不必用Web Services來實(shí)現(xiàn)，相反，Web Services也并不一定遵循SOA標(biāo)準(zhǔn)。

不過，Web Services的特性十分適合用來實(shí)現(xiàn)SOA架構(gòu)。Web Services 之間能夠交換帶結(jié)構(gòu)的文檔（比如XML），這些文檔可能包含完全異構(gòu)的數(shù)據(jù)信息。這些文檔可以同時(shí)附帶關(guān)于數(shù)據(jù)的數(shù)據(jù)：元數(shù)據(jù)（metadata）。換句話說，Web Services可以有較粗的粒度，這樣較粗的粒度正好可以構(gòu)成SOA中服務(wù)的粒度。

說到底，兩者是相交的圓，SOA服務(wù)和Web Services之間的區(qū)別還在于設(shè)計(jì)。SOA概念并沒有確切地定義服務(wù)具體如何交互，而僅僅定義了服務(wù)如何相互理解。其中的區(qū)別也就是定義如何執(zhí)行流程的戰(zhàn)略與如何執(zhí)行流程的戰(zhàn)術(shù)之間的區(qū)別。而另一方面，Web Services在需要交互的服務(wù)之間如何傳遞消息有具體的指導(dǎo)原則；從戰(zhàn)術(shù)上實(shí)現(xiàn)SOA模型是通過 HTTP傳遞的SOAP消息中最常見的SOA模型。因而，從本質(zhì)上講，Web Services是實(shí)現(xiàn) SOA的具體方式之一。

2. SOA中的服務(wù)與組件對(duì)象（Components Objects）的關(guān)系

相似之處在于：都有一個(gè)或多個(gè)接口，并且，服務(wù)發(fā)布者和使用者都遵守這些接口。

不同之處在于：SOA是關(guān)于模式（schemas）的，組件對(duì)象是關(guān)于對(duì)象類型（object types）的；SOA通過像SOAP這樣的標(biāo)準(zhǔn)消息機(jī)制（messages）來實(shí)現(xiàn)通信，而組件對(duì)象通過方法調(diào)用（method calls）來交互。與CORBA 中的接口定義語言IDL (Interface Definition Language)相比，SOA 在WSDL (Web Services Definition Language) 中采用XML，會(huì)顯得更加普遍和通用。

聯(lián)系之處在于：服務(wù)最終還是通過類和組件對(duì)象來實(shí)現(xiàn)的。

SOA被認(rèn)為是傳統(tǒng)緊耦合的、面向?qū)ο蟮哪Ｐ偷奶娲摺Ｏ裢ㄓ脤?duì)象代理架構(gòu)CORBA (Common Object Request Broker Architecture)和分布式組件對(duì)象模型DCOM (Distributed Component Object Model)。在SOA 中，單個(gè)服務(wù)可以用面向?qū)ο蠓椒▉碓O(shè)計(jì)，但是，整個(gè)SOA的設(shè)計(jì)卻是面向服務(wù)的。下面的表格中給出了SOA與分布式組件架構(gòu)的不同點(diǎn)。

3. SOA與網(wǎng)格計(jì)算（Grid Computing）的關(guān)系

網(wǎng)格計(jì)算（Grid Computing）是利用互聯(lián)網(wǎng)技術(shù)，把分散在不同地理位置的計(jì)算機(jī)組成一臺(tái)虛擬超級(jí)計(jì)算機(jī)。每一臺(tái)參與的計(jì)算機(jī)就是其中的一個(gè)“節(jié)點(diǎn)”，所有的計(jì)算機(jī)就組成了一張節(jié)點(diǎn)網(wǎng)——網(wǎng)格。從實(shí)質(zhì)上來說“網(wǎng)格計(jì)算”是一種分布式應(yīng)用，網(wǎng)格中的每一臺(tái)計(jì)算機(jī)只是完成工作的一個(gè)小部分，雖然單臺(tái)計(jì)算機(jī)的運(yùn)算能力有限，但成千上萬臺(tái)計(jì)算機(jī)組合起來的計(jì)算能力就可以和超級(jí)計(jì)算機(jī)相比了。

網(wǎng)格計(jì)算基于因特網(wǎng)，提供了資源整合和共享的平臺(tái)。十分適合作為SOA架構(gòu)的實(shí)施平臺(tái)。

我們來具體地看一下：

SOA 的構(gòu)建策略：創(chuàng)建一個(gè)面向服務(wù)的計(jì)算SOC（service-based computing）環(huán)境；可以用類似于web services的技術(shù)來設(shè)計(jì)服務(wù)：使用SOAP通信機(jī)制；采用XML數(shù)據(jù)格式；強(qiáng)調(diào)服務(wù)的重用和互操作；最大化的應(yīng)用現(xiàn)有資源；希望有一個(gè)類似于網(wǎng)格計(jì)算環(huán)境的基礎(chǔ)平臺(tái)。

網(wǎng)格作為平臺(tái)的基本特點(diǎn)：網(wǎng)格被視為一個(gè)由各種計(jì)算資源組成的統(tǒng)一環(huán)境，其管理軟件將網(wǎng)格整合成一個(gè)完整而協(xié)調(diào)的透明計(jì)算整體；網(wǎng)格是一個(gè)虛擬的應(yīng)用服務(wù)器;是一個(gè)應(yīng)用實(shí)現(xiàn)和數(shù)據(jù)處理的理想平臺(tái)；服務(wù)在網(wǎng)格中部署和調(diào)用執(zhí)行；商業(yè)邏輯和服務(wù)調(diào)用被當(dāng)成網(wǎng)格程序一樣在平臺(tái)上運(yùn)行；網(wǎng)格為SOC計(jì)算的有效性、快速性、靈活性、伸縮性和計(jì)算環(huán)境的管理提供便利。

SOA帶給企業(yè)什么？

作為需要構(gòu)建SOA應(yīng)用的企業(yè)來說，究竟有些什么好處呢？我們來看一下：

● 集成現(xiàn)有系統(tǒng)，不必另起爐灶。面向服務(wù)的體系結(jié)構(gòu)可以基于現(xiàn)有的系統(tǒng)投資來發(fā)展，而不需要徹底重新創(chuàng)建系統(tǒng)。通過使用適當(dāng)?shù)?SOA 框架并使其用于整個(gè)企業(yè)，可以將業(yè)務(wù)服務(wù)構(gòu)造成現(xiàn)有組件的集合。使用這種新的服務(wù)只需要知道它的接口和名稱。服務(wù)的內(nèi)部細(xì)節(jié)以及在組成服務(wù)的組件之間傳送的數(shù)據(jù)的復(fù)雜性都對(duì)外界隱藏了。這種組件的匿名性使組織能夠利用現(xiàn)有的投資，從而可以通過合并構(gòu)建在不同的機(jī)器上、運(yùn)行在不同的操作系統(tǒng)中、用不同的編程語言開發(fā)的組件來創(chuàng)建服務(wù)。遺留系統(tǒng)可以通過 Web 服務(wù)接口來封裝和訪問。

● 服務(wù)設(shè)計(jì)松耦合， 帶來多方面優(yōu)點(diǎn)。服務(wù)是位置透明的，服務(wù)不必與特定的系統(tǒng)和特定的網(wǎng)絡(luò)相連接。服務(wù)是協(xié)議獨(dú)立的，服務(wù)間的通信框架使得服務(wù)重用成為可能。對(duì)于業(yè)務(wù)需求變化，SOA能夠方便組合松耦合的服務(wù)，以提供更為優(yōu)質(zhì)和快速的響應(yīng)，允許服務(wù)使用者自動(dòng)發(fā)現(xiàn)和連接可用的服務(wù)。松耦合系統(tǒng)架構(gòu)使得服務(wù)更容易被應(yīng)用所集成，或組成其他服務(wù)，同時(shí)提供了良好的應(yīng)用開發(fā)、運(yùn)行時(shí)服務(wù)部屬和服務(wù)管理能力。提供對(duì)服務(wù)使用者的驗(yàn)證（authentication） 授權(quán)（authorization），來加強(qiáng)安全性保障，這一點(diǎn)也優(yōu)于其他緊耦合架構(gòu)。

● 統(tǒng)一了業(yè)務(wù)架構(gòu)，可擴(kuò)展性增強(qiáng)。在所有不同的企業(yè)應(yīng)用程序之間，基礎(chǔ)架構(gòu)的開發(fā)和部署將變得更加一致。現(xiàn)有的組件、新開發(fā)的組件和從廠商購買的組件可以合并在一個(gè)定義良好的 SOA 框架內(nèi)。這樣的組件集合將被作為服務(wù)部署在現(xiàn)有的基礎(chǔ)構(gòu)架中，從而使得可以更多地將基礎(chǔ)架構(gòu)作為一種商品化元素來加以考慮，增強(qiáng)了可擴(kuò)展性。又由于面向服務(wù)的敏捷設(shè)計(jì)，在應(yīng)對(duì)業(yè)務(wù)變更時(shí)，有了更強(qiáng)的“容變性”。

● 加快了開發(fā)速度，減少了開發(fā)成本。組織的 Web 服務(wù)庫將成為采用 SOA 框架的組織的核心資產(chǎn)。使用這些 Web 服務(wù)庫來構(gòu)建和部署服務(wù)將顯著地加快產(chǎn)品的上市速度，因?yàn)閷?duì)現(xiàn)有服務(wù)和組件的新的創(chuàng)造性重用縮短了設(shè)計(jì)、開發(fā)、測試和部署產(chǎn)品的時(shí)間。 SOA 減少了開發(fā)成本，提高了開發(fā)人員的工作效率。

研究表明，一般系統(tǒng)的接口的開發(fā)費(fèi)用占到整個(gè)開發(fā)費(fèi)用的33%，最高的竟達(dá)到了70%。在SOA中，接口的重用會(huì)節(jié)省費(fèi)用60%。而且節(jié)省的費(fèi)用不是一次性的，而是每年。隨著業(yè)務(wù)需求的發(fā)展和新的需求的引入，通過采用 SOA 框架和服務(wù)庫，為現(xiàn)有的和新的應(yīng)用程序增強(qiáng)和創(chuàng)建新的服務(wù)的成本大大地減少了。同樣，開發(fā)團(tuán)隊(duì)的學(xué)習(xí)難度也降低了，因?yàn)樗麄兛赡芤呀?jīng)熟悉了現(xiàn)有的組件。

● 持續(xù)改進(jìn)業(yè)務(wù)過程，降低激變風(fēng)險(xiǎn)。SOA允許清晰地表示流程流，這些流程流通過在特定業(yè)務(wù)服務(wù)中使用的組件的順序來標(biāo)識(shí)。這給商業(yè)用戶提供了監(jiān)視業(yè)務(wù)操作的理想環(huán)境。業(yè)務(wù)建模反映在業(yè)務(wù)服務(wù)中。流程操縱是以一定的模式重組部件（構(gòu)成業(yè)務(wù)服務(wù)的組件）來實(shí)現(xiàn)的。這將進(jìn)一步允許更改流程流，而同時(shí)監(jiān)視產(chǎn)生的結(jié)果，因此促進(jìn)了持續(xù)改進(jìn)。重用現(xiàn)有的組件降低了在增強(qiáng)或創(chuàng)建新的業(yè)務(wù)服務(wù)過程中帶來的風(fēng)險(xiǎn)，也減少了維護(hù)和管理支持服務(wù)基礎(chǔ)架構(gòu)的風(fēng)險(xiǎn)。

圖1是一張SOA技術(shù)實(shí)施的示意圖，其中涉及的主要技術(shù)包括以下幾個(gè)：

1．XML

XML 1.0 (可擴(kuò)展標(biāo)記語言，Extensible Markup Language) 標(biāo)準(zhǔn)是一個(gè)基于文本的 World Wide Web 組織 (W3C) 規(guī)范的標(biāo)記語言。與 HTML 使用標(biāo)簽來描述外觀和數(shù)據(jù)不同，XML 嚴(yán)格地定義了可移植的結(jié)構(gòu)化數(shù)據(jù)。它可以作為定義數(shù)據(jù)描述語言的語言，如標(biāo)記語法或詞匯、交換格式和通信協(xié)議。

2．SOAP

簡單對(duì)象訪問協(xié)議 (Simple Object Access Protocol) 是一個(gè)基于XML的，用于在分布式環(huán)境下交換信息的輕量級(jí)協(xié)議。SOAP 在請求者和提供者對(duì)象之間定義了一個(gè)通信協(xié)議，這樣，在面向?qū)ο缶幊塘餍械沫h(huán)境中，該請求對(duì)象可以在提供的對(duì)象上執(zhí)行遠(yuǎn)程方法調(diào)用。因?yàn)镾OAP是平臺(tái)無關(guān)和廠商無關(guān)的標(biāo)準(zhǔn)，因此盡管SOA并不必須使用SOAP，但在帶有單獨(dú) IT基礎(chǔ)架構(gòu)的合作伙伴之間的松耦合互操作中，SOAP仍然是支持服務(wù)調(diào)用的最好方法。

W3C SOAP 1.2規(guī)范在服務(wù)請求者和服務(wù)提供者之間定義使用XML格式的消息進(jìn)行通信。將應(yīng)用程序請求（在XML中）放入 SOAP 信封中（也是 XML ），并從請求者到提供者發(fā)送應(yīng)用程序請求，提供者發(fā)回的響應(yīng)也采用相同的形式。最近 SOAP 被稱為面向服務(wù)的架構(gòu)協(xié)議 (Services-Oriented Architecture Protocol)。

SOAP的優(yōu)點(diǎn)在于它完全和廠商無關(guān)，相對(duì)于平臺(tái)、操作系統(tǒng)、目標(biāo)模型和編程語言可以獨(dú)立實(shí)現(xiàn)。另外，傳輸和語言綁定以及數(shù)據(jù)編碼的參數(shù)選擇都是由實(shí)現(xiàn)決定的。

3．WSDL

Web服務(wù)描述語言 WSDL (Web Services Description Language) 是一個(gè)提供描述服務(wù)IDL標(biāo)準(zhǔn)方法的XML詞匯。Web 服務(wù)描述語言（WSDL）規(guī)范定義了一個(gè) XML詞匯表，該詞匯表依照請求和響應(yīng)消息，在服務(wù)請求者和服務(wù)提供者之間定義了一種契約。我們能夠?qū)eb服務(wù)定義為軟件，這個(gè)軟件通過描述SOAP消息接口的 WSDL文檔來提供可重用的應(yīng)用程序功能，并使用標(biāo)準(zhǔn)的傳輸協(xié)議來進(jìn)行傳遞。

WSDL描述包含必要的細(xì)節(jié),以便服務(wù)請求者能夠使用特定服務(wù)：

● 請求消息格式

● 響應(yīng)消息格式

● 向何處發(fā)送消息。

WSDL 是基于 XML 的，因此 WSDL 文檔是計(jì)算機(jī)可讀的（machine-readable）。這樣開發(fā)環(huán)境使用WSDL將集成服務(wù)的流程自動(dòng)處理到請求者應(yīng)用程序。例如 WebSphere Studio產(chǎn)生一個(gè)Java的代理對(duì)象，它能夠像本地對(duì)象一樣實(shí)現(xiàn)服務(wù)，但是實(shí)際上代理對(duì)象僅僅處理請求的創(chuàng)建和響應(yīng)消息的解析。不管服務(wù)是否用Java、C#或者其他的語言實(shí)現(xiàn)，生成的Java代理對(duì)象都能夠從WSDL描述中調(diào)用任何的Web服務(wù)。實(shí)際上，WSDL不能像編程語言那樣描述實(shí)現(xiàn)細(xì)節(jié)。

4．UDDI

統(tǒng)一描述、發(fā)現(xiàn)和集成 (Universal Description, Discovery and Integration) 規(guī)范提供了一組公用的 SOAP API，使得服務(wù)代理得以實(shí)現(xiàn)。UDDI為發(fā)布服務(wù)的可用性和發(fā)現(xiàn)所需服務(wù)定義了一個(gè)標(biāo)準(zhǔn)接口（基于 SOAP 消息）。UDDI 實(shí)現(xiàn)將發(fā)布和發(fā)現(xiàn)服務(wù)的 SOAP 請求解釋為用于基本數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)管理功能調(diào)用。

為了發(fā)布和發(fā)現(xiàn)其他SOA服務(wù)，UDDI 通過定義標(biāo)準(zhǔn)的 SOAP 消息來實(shí)現(xiàn)服務(wù)注冊（Service Registry）。注冊是一種服務(wù)代理，它是在 UDDI 上需要發(fā)現(xiàn)服務(wù)的請求者和發(fā)布服務(wù)的提供者之間的中介。一旦請求者決定使用特定的服務(wù)，開發(fā)者通常借助于開發(fā)工具（如Microsoft Visual Studio .NET）并通過創(chuàng)建以發(fā)送請求并處理響應(yīng)的方式訪問服務(wù)的代碼來綁定服務(wù)。

SOA不需要使用UDDI，但由于 UDDI 是建立在SOA上來完成自身工作的，所以UDDI是服務(wù)發(fā)現(xiàn)的一個(gè)好的解決方案。

5．ESB

如圖2所示，企業(yè)服務(wù)總線ESB（Enterprise Service Bus）是SOA架構(gòu)的一個(gè)支柱技術(shù)。 作為一種消息代理架構(gòu)它提供消息隊(duì)列系統(tǒng)，使用諸如SOAP或JMS (Java Message Service)等標(biāo)準(zhǔn)技術(shù)來實(shí)現(xiàn)。

有人把ESB描述成一種開放的、基于標(biāo)準(zhǔn)的消息機(jī)制，通過簡單的標(biāo)準(zhǔn)適配器和接口，來完成粗粒度應(yīng)用（比如服務(wù)）和其他組件之間的互操作。

ESB的主要功能有：通信和消息處理、服務(wù)交互和安全性控制、服務(wù)質(zhì)量和服務(wù)級(jí)別管理、建模、管理和自治、基礎(chǔ)架構(gòu)智能等。

作為一個(gè)具有發(fā)展前景的應(yīng)用系統(tǒng)架構(gòu)，SOA尚處在不斷發(fā)展中，肯定存在許多有待改進(jìn)的地方。隨著標(biāo)準(zhǔn)和實(shí)施技術(shù)的不斷完善，這些問題將迎刃而解，SOA應(yīng)用將更加廣泛。

缺憾之一 : 可靠性(Reliability）

SOA還沒有完全為事務(wù)的最高可靠性——不可否認(rèn)性(nonrepudiation)、消息一定會(huì)被傳送且僅傳送一次（once-and-only-once delivery）以及事務(wù)撤回（rollback）——做好準(zhǔn)備，不過等標(biāo)準(zhǔn)和實(shí)施技術(shù)成熟到可以滿足這一需求的程度并不遙遠(yuǎn)。

缺憾之二 : 安全性（Security）

在過去，訪問控制只需要登錄和驗(yàn)證；而在SOA環(huán)境中，由于一個(gè)應(yīng)用軟件的組件很容易去與屬于不同域的其他組件進(jìn)行對(duì)話，所以確保迥然不同又相互連接的系統(tǒng)之間的安全性就復(fù)雜得多了。

缺憾之三:編排 (Orchestration)

統(tǒng)一協(xié)調(diào)分布式軟件組件以便構(gòu)建有意義的業(yè)務(wù)流程是最復(fù)雜的，但它同時(shí)也最適合面向服務(wù)類型的集成，原因很顯然，建立在SOA上面的應(yīng)用軟件被設(shè)計(jì)成可以按需要拆散、重新組裝的服務(wù)。作為目前業(yè)務(wù)流程管理（BPM）解決方案的核心，編排功能使IT管理人員能夠通過已經(jīng)部署的套裝或自己開發(fā)的應(yīng)用軟件的功能，把新的元應(yīng)用軟件（meta-application）連接起來。 事實(shí)上，最大的難題不是建立模塊化的應(yīng)用軟件，而是改變這些系統(tǒng)表示所處理數(shù)據(jù)的方法。

缺憾之四:遺留系統(tǒng)處理（Legacy support）

SOA中提供集成遺留系統(tǒng)的適配器， 遺留應(yīng)用適配器屏蔽了許多專用性API的復(fù)雜性和晦澀性。一個(gè)設(shè)計(jì)良好的適配器的作用好比是一個(gè)設(shè)計(jì)良好的SOA服務(wù)：它提供了一個(gè)抽象層，把應(yīng)用基礎(chǔ)設(shè)施的其余部分與各種棘手問題隔離開來。一些廠商就專門把遺留應(yīng)用軟件“語義集成”到基于XML的集成構(gòu)架中。 但是集成遺留系統(tǒng)的工作始終是一種挑戰(zhàn)。

缺憾之五 : 語義 Semantics

定義事務(wù)和數(shù)據(jù)的業(yè)務(wù)含義，一直是IT管理人員面臨的最棘手的問題。語義關(guān)系是設(shè)計(jì)良好SOA架構(gòu)的核心要素。 就目前而言，沒有哪一項(xiàng)技術(shù)或軟件產(chǎn)品能夠真正解決語義問題。為針對(duì)特定行業(yè)和功能的流程定義并實(shí)施功能和數(shù)據(jù)模型是一項(xiàng)繁重的任務(wù)，它最終必須由業(yè)務(wù)和IT管理人員共同承擔(dān)。不過，預(yù)制組件和經(jīng)過實(shí)踐證明的咨詢技能可以簡化許多難題。

采用XML技術(shù)也許是一個(gè)不錯(cuò)的主意。許多公司越來越認(rèn)識(shí)到制定本行業(yè)XML標(biāo)準(zhǔn)的重要性。譬如，會(huì)計(jì)行業(yè)已提議用可擴(kuò)展業(yè)務(wù)報(bào)告語言（XBRL）來描述及審查總賬類型的記錄。

重要的是學(xué)會(huì)如何以服務(wù)來表示基本的業(yè)務(wù)流程。改變開發(fā)方式需要文化變遷，相比之下，解決技術(shù)難題只是一種智力操練。

性能（performance）：SOA的第六個(gè)缺憾？

批評(píng)SOA的人士經(jīng)常會(huì)提到性能是阻礙其采用的一個(gè)障礙，但技術(shù)的標(biāo)準(zhǔn)化總需要在速度方面有一些犧牲。這種懷疑觀點(diǎn)通常針對(duì)兩個(gè)方面：SOA的分布性質(zhì)和Web服務(wù)協(xié)議的開銷。

不可否認(rèn)，任何分布式系統(tǒng)的執(zhí)行速度都不如獨(dú)立式系統(tǒng)，這完全是因?yàn)榫W(wǎng)絡(luò)的制約作用造成的。當(dāng)然，有些應(yīng)用軟件無法容忍網(wǎng)絡(luò)引起的延遲，例如那些對(duì)實(shí)時(shí)性要求很高的應(yīng)用軟件。所以在應(yīng)用SOA架構(gòu)之前，搞清楚它的適用范圍就顯得很重要了。

除了上述幾點(diǎn)之外，筆者認(rèn)為還有兩點(diǎn)也頗值得關(guān)注：

松耦合和敏捷性要求之間的權(quán)衡難題:

服務(wù)松耦合設(shè)計(jì)其實(shí)是一把雙刃劍，在帶來應(yīng)變敏捷性的同時(shí)，也給業(yè)務(wù)建模和服務(wù)劃分帶來難題。這就是為什么在SOA討論中，業(yè)務(wù)建模的爭論總是最多的原因。

跨系統(tǒng)集成難題：

面向服務(wù)的體系結(jié)構(gòu)設(shè)計(jì)將跨越計(jì)算機(jī)系統(tǒng)，并且還可能跨越企業(yè)邊界。我們不得不考慮在使用 Internet 時(shí)安全性功能和需求，以及如何鏈接伙伴的安全域。Internet 協(xié)議并不是為可靠性（有保證的提交和提交的順序）而設(shè)計(jì)的，但是我們需要確保消息被提交并被處理一次。當(dāng)這不可能時(shí)，請求者必須知道請求并沒有被處理。