soa在移動網路面臨挑戰

1. ->為什麼選擇SOA，SOA的優勢

1、 不是沒有系統，而是信息孤島太多； 多數企業在信息化領用投入不少，系統有大有小，什麼OA,什麼ERP，什麼CRM，什麼什麼的，軟體是有了，取 得的效果不明顯，數據彼此不一致，各有各的口徑，集成和共享數據難度大，數據你一套，我一套，就是一個字「暈」 2、 不是沒有數據，而是信息不一致，難以整合； 各自建賬，業務經常重疊，有先有後；數據交互困難，導入導出實在不便；面對同樣的數據，這個系統錄入一次， 那個系統錄入一次，增加的工作量，加大了負擔；什麼許可權，什麼人員架構的，動不動就得這改，那改，別說加大了 工作量，不小心漏了，或是改錯了，找錯就有得整。 3、 業務跨INTERNET動作，技術異構，難以協同； 技術各異，開發語言各有所倚，網路協議也採用的不一樣；即使對接了，各自的配合程度，提供的介面，技術的 水平參差不齊，這些協調工作都有得你受。 4、 業務變化快，僵化的IT基礎設施難以迅速響應。
審批流程，工作流常常因為人員變動或調整產生變動，需要快速調整和適應變化；審批流這還是小事，業務流程這個可 是大事了，業務流程的人口和走向是直接導致一個軟體是否可以有效適應企業變化的業務流程的也一個標准，所以不管
是大，或小的軟體，系統也好，這個可是檢驗軟體的適應性的最高標准。 1、松耦合，可編排，靈活性大，適應企業個性化需求 2、組件重用，模型重用，實現快速，調整靈活 3、標准化，快速化 SOA的優點和優勢 1、支持多種客戶類型 藉助精確定義的服務介面和對XML、WEB服務標準的支持，可以支持多種客戶類型，包括PDA、手機等新型訪問渠道。 2、更易維護 我們使用高性能的鬆散耦合關系及對開放標準的採用確保了該特性的實現 3、更好的伸縮性 我們依靠服務設計、開發和部署所採用的架構模型實現伸縮性。可以彼此獨立調整，以滿足服務需求。 4、更高可用性 該特性在於我們採用的鬆散耦合關繫上得以體現。使用者無須了解提供者的實現細節

2. soa是什麼

• SOA

  （面向服務的架構）

面向服務的架構（SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）進行拆分，並通過這些服務之間定義良好的介面和協議聯系起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平台、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。

• 定義介紹

面向服務架構，它可以根據需求通過網路對鬆散耦合的粗粒度應用組件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟體代理交互的人為依賴性。

SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義介面進行通訊，不涉及底層編程介面和通訊模型。SOA可以看作是B/S模型、XML（標准通用標記語言的子集）/Web Service技術之後的自然延伸。

SOA將能夠幫助軟體工程師們站在一個新的高度理解企業級架構中的各種組件的開發、部署形式，它將幫助企業系統架構者以更迅速、更可靠、更具重用性架構整個業務系統。較之以往，以SOA架構的系統能夠更加從容地面對業務的急劇變化。

SOA系統是一種企業通用性架構。

3. 微服務架構 vs SOA架構

一、面向服務的架構SOA

面向服務的架構是一種軟體體系結構，應用程序的不同組件通過網路上的通信協議向其他組件提供服務。通信可以是簡單的數據傳遞，也可以是兩個或多個服務彼此協調連接。這些獨特的服務執行一些小功能，例如驗證付款、創建用戶 帳戶 或提供社交登錄等。

面向服務的架構不太關於如何對應用程序進行模塊化構建，更多的是關於如何通過分布式、單獨維護和部署的軟體組件的集成來組成應用程序。這些通過技術和標准來實現，通過技術和標准使得組件能夠更容易地通過網路（尤其是IP網路）進行通信和協作。

SOA架構中有兩個主要角色： 服務提供者（Provider）和服務使用者（Consumer）。 而軟體代理則可以 扮演這 兩個角色。該Consumer層是用戶（人、應用程序或第三方的其它組件）與SOA交互的點，和Provider層則由SOA架構內的所有服務所構成。

SOA首先在90年代中期得名，當時一家名為Gartner Group的公司認識到了這個軟體架構的新趨勢，並在全球推廣。通過這樣做，他們設法大大加快了這種架構模式的採用和進一步發展。然而，使用分布式服務作為軟體體系結構的最早記錄可追溯到二十世紀80年代初。

二、微服務架構

微服務架構在某種程度上是面向服務的架構SOA繼續發展的下一步。基本上，這種架構類型是開發軟體，網路或移動應用程序作為獨立服務套件（又稱微服務）的一種特殊方式。這些服務的創建僅限於一個特定的業務功能，如用戶管理、用戶角色、電子商務車、搜索引擎、社交媒體登錄等。此外，它們是完全獨立的，也就是說它們可以寫入不同的編程語言並使用不同的資料庫。集中式服務管理幾乎不存在，微服務使用輕量級HTTP、REST或Thrift API進行通信。

這個詞本身起源於2011年5月在威尼斯附近舉行的軟體架構師研討會。他們第一次使用「微服務」這個術語來描述參與者看到的一個共同的架構風格，其中許多參會者都在 探索 相似的內容。2012年5月，同一個團隊決定將「微服務」作為最合適的名稱。然而實際上，微軟、亞馬遜、Netflix和Facebook等主要的 科技 公司已經在微服務架構方面工作了十多年。

乍一看，微服務架構似乎談論的是與SOA相同的事情。不過，如果引用微軟服務領域的先驅Martin Flower的話，他曾經說過，「我們應該把SOA看作微服務的超集」。

那麼，差異在哪裡呢？可以說，兩種架構比起不同的架構有更多的相似之處，然而，它們是兩種不同類型的架構。下面會詳細分析這一點。

三、SOA vs. MicroServices

下面進一步解釋下表所述的不同之處：

開發方面 - 在這兩種體系結構中，可以使用不同的編程語言和工具開發服務，從而將技術多樣性帶入開發團隊。開發可以在多個團隊中組織，但是在SOA中，每個團隊都需要了解常見的通信機制。另一方面，使用微服務，服務可以獨立於其他服務運行和部署。因此，頻繁部署新版本的微服務或獨立擴展服務會更容易。您可以在這里進一步閱讀有關微服務的這些好處。

「上下文邊界」 - SOA鼓勵組件的共享，而微服務嘗試通過「上下文邊界」來最小化共享。上下文邊界是指以最小的依賴關系將組件及其數據耦合為單個單元。由於SOA依靠多個服務來完成業務請求，構建在SOA上的系統可能比微服務要慢。

通信 - 在SOA中， ESB可能成為影響整個系統的單一故障點。由於每個服務都通過ESB進行通信，如果其中一個服務變慢，可能會阻塞ESB並請求該服務。另一方面，微服務在容錯方面要好得多。例如，如果一個微服務存在內存錯誤，那麼只有該微服務會受到影響。所有其他微服務將繼續定期處理請求。

互操作性 - SOA 通過消息中間件組件促進了多種異構協議的使用。微服務試圖通過減少集成選擇的數量來簡化架構模式。 因此，如果您想要在異構環境中使用不同協議來集成多個系統，則需要考慮SOA。如果您的所有服務都可以通過相同的遠程訪問協議訪問，那麼微服務對您來說是一個更好的選擇。

大小Size - 最後一點但並非最不重要的一點，SOA和微服務的主要區別在於規模和范圍。微服務架構中的前綴「微」是指內部組件的粒度，意味著它們必須比SOA架構的服務往往要小得多。微服務中的服務組件通常有一個單一的目的，他們做得很好。另一方面，在SOA服務中通​​常包含更多的業務功能，並且通常將它們實現為完整的子系統。

四、結論

我們不能簡單地說一種架構比另一種架構更好。這主要取決於您正在構建的應用程序的目的。SOA更適合需要與許多其他應用程序集成的大型復雜企業應用程序環境。這就是說，小型應用程序不適合SOA架構，因為它們不需要消息中間件組件。而微服務架構，在另一方面，是更適合於較小和良好的分割，基於Web的系統。另外，如果您正在開發移動或Web應用程序，那麼微服務作為開發人員可以為您提供更大的控制權。最後，我們可以得出結論，因為它們服務於不同的目的，微服務和SOA確實是不同類型的體系結構。

4. 未來SOA可以更好地發展嗎

如果沒有這么大量而且復雜的SOA 標准存在，SOA可以更好地發展嗎？ 可能在現在的你我眼中都或多或少的有了對標準的依賴和重視。試想，難道SOA的發展是因為這些標准才變的更好的？ 就像更簡單的腳本語言一樣，Java和Java EE也是由於標准過多而造成了隔閡。如果SOA標准和規格繼續到增多而且變得越來越復雜的話，SOA將遭受一樣命運。我們已經看到專業IT人員為SOA標准尋找的出路――很簡單的REST Web服務。標准到了應該進行精簡的時候了。 要想阻止SOA標準的出台真的是件很不容易的事。很多時候，標準的出台和支持都是存在政治利益，是為了支持軟體提供商的營銷計劃而指定的。那些僥幸出台的標准為開發者造成了巨大影響，所以，其結果就是希望出台沒有缺陷的標准並使它成為最適用的標准。在大量SOA標准出台之前，我還是應該重新審視SOA標准，對現有的SOA標准做一下徹底的分析和研究。這就是本系列文章的主旨。 我們將關注主要的SOA標准並努力找到哪些標準是可被採用的。不過可惜這不是容易的任務。明確哪些標准本應是大量普及的標准，現在卻僅僅小范圍使用，不被大眾接受使用，給人的感覺就像被冷落怠慢或者沒有歸屬感一樣。可是，現在有大量已經存在的SOA標准而且這些標准經常改變，所以對它們一一地討論和研究是根本不可能的。所有標准又有不同的版本所以整個標准體系非常復雜。這篇文章裡面大概提到70多個單獨標准，當然，對於一線的IT工作人員來講，要想同時考慮符合所有標準是很難的事。 這一系列文章將努力引導我們詳細審視現有的SOA標准。它將列舉出一些得到共識的標准，或者提出一些標准中值得注意的地方。它將比較相似的標准，並試著將它們之間的關鍵部分的不同點區分開本文將列舉SOA標准，同時介紹支持這些標準的標准組織。以後的文章將更加深入的剖析人們關注的大多數SOA標准。我們將按照類別考察這些標准，努力分析它們之間的相似之處和不同點。最終詳細介紹現存的標准，使您和您的企業能更好的了解現在使用的標准。 我們這里要討論的一些標准本身並不是真正的標准，而技術規范。它們是技術規范、API、協議和一些SOA概念的集合。為了充分地比較SOA標准，我們將與其他的標准及相似的技術概念進行對比。因此，希望你暫時能模糊掉標准、技術規范、API和協議等等之間的區別，以便於我們更好本著這個主題進行討論。 主要的標准組織 制定了這么多的標准，當然存在著很多標准組織。這些各自為政的組織可能會混淆標准本身。所以，在我們回顧標准前，最好先了解一下現有的標准組織。按照這個方法，回顧的那些標准只對應於那些主要的標准組織。就像前面討論標准時一樣，當然也確實存在著大量標准組織，不過，我們為了簡化問題，在這里只詳細介紹一些主要的標准組織。這些組織並不是都發布了SOA標准，但是它們都參與技術性標準的發布。很多偉大的當代技術人都是這些組織的參與人。那就讓我們去了解一下它們吧。 下面的圖表中列出了一些主要的標准組織。在這，我又使用了「標准」這一術語，當然，它還是涵蓋了一些技術說明、API等在內。OASIS 的Peter Roden幫助我完成原始的圖表，為了方便討論，我又稍微的做了一下調整和平衡。 主要的標准組織： 最近，參與SOA標准制定的較有影響的組織包括： W3C——世界廣域網聯盟 OASIS——結構化信息標准促進組織 WS-I——網路服務協作組織 OSOA ——開放式SOA 簡要的介紹一下這些組織，這些描述大部分來自於其所屬於組織的網站。 W3C: W3C通過定義相關的說明和指導來促進網路技術的發展，即讓軟體和工具充分的發掘網路的潛能。為了發揮網路的最大潛能，最基礎的網路技術必須要求硬體與軟體之間相互兼容。W3C將這個目標稱之為「網路共融化」。通過發布公開化，非私有化和為網路語言和協議提供標准，W3C制止和避免了很多因為網路混亂而產生的市場混亂。W3C由Tim Berners-Lee於1994年創立。 OASIS: 結構化信息標准促進組織OASIS 是非營利性的國際化組織，推動了電子商務標準的發展，合並和實施。此組織制定了比其他組織更多的網路服務標准，這些標准主要是關於安全性，電子商務和標准化的問題，為公共服務使用的行業應用作出了貢獻。OASIS最初在1993年由SGML Open改制而成，並將其名稱在1998年改為OASIS。 WS-I: WS-I是一個特許的工業化組織，主要是通過平台，操作系統和編程語言來推進網路服務互通性。 其主旨是針對現今過多的網路服務標准。在WS-I內存在的兩種工作標准， 基礎分布標准(BP)包括連接分布標准和基礎安全分布標准(BSP)。 JCP: 在1998年作為開放的，為修訂和發展JAVA技術的技術說明推出，同時設計實行和測試。JCP已經促進了在JAVA平台上進行開發的國際化。 OSOA: OSOA是一個代表工業領導者們的意圖的組織，定義了為迎合正在挖掘出服務向導體系的的特點和優勢的企業開發人員而定義的一種自然程序化模型語言。這個研究會並不是一個標准組織，而是那些希望得到用於快速開發的程序模型並且投入應用的買家們而設置的。最初成立的時候，其主要向一些正規的標准體，例如OASIS或W3C提供一些技術說明用於將來標准制定的參考。這些企業的合作夥伴正在為兩個重要的項目而工作服務成分建築(SCA)和服務數據對象(SOD)。 對SOA標准進行基礎的分類，我們用以下方法去定義和比較一些通用的標准： 附件類–為在信息中包含了數據擴展而設置的標准 發現類–為描述和定位服務的標准. 事件類–不使用請求-回答模式而使用事件模式來請求服務的標准 綜合類- 為互連系統系統協同工作而制定的標准 經營類-為控制、監視和管理服務而設置的標准。 建模類–為設計SOA體系和元素而服務的標准這些標准也包含了那些保證模型建立的正確的標准。 協議類–定義了信息系統和體系結構框架的標准。 處理類- 使服務支持狀態，數據傳輸和時事性的標准，經常涉及到安全和時事信息。 安全類- 為SOA信息安全和服務認證而制定的標准。 一些標准系列為了應付在SOA框架、網路服務或其他專業領域中遺留下來的缺陷而制定的。例如：網路服務並沒有包括數據的信息化，技術事件的相應，處理事件和安全等方面。這些功能是一些像JMS、CORBA和IIOP本身所具有的屬性和特點，但是並沒有在網路服務中自然的存在。因此很多的標准嘗試在網路服務中加入信息處理進程。其他的一些標准組織則更加的具有戰略眼光，例如格式類和管理類標准便為中間件添加了新的屬性。格式化促使商業進程信息化，但是管理類標准需要在近期的商業環境中響應政府管理命令。於是，最終一些標准過於絕對，想為SOA體系建立一個通用的建模技術說明。這些只是我個人對這些標準的觀點和認識，為了讓其他人更方便的理解和處理現有的服務。 以下的表格中列舉了現有的最普遍和實用的SOA標准。今後我們還會更進一步的探求某個標准，分類理解他們，並將這些信息轉達給客戶那些標准要被採用。但是我們剛剛開始做底層工作，一個確實很長的SOA標准標單被列出來，如下： 在接下來的文章中，我們將稍微深刻的剖析一些種類的標准。我們將對比相互競爭的標准，找出他們各自的優勢。我們還可以預測一下標准間競爭的結果，試著分析指出哪個將被採用而那個將被淘汰。 SOA的存在依靠標準的梳理，因此我們必須學會怎樣利用它們，而不是盲目的擴大它。SOA實施 SOA實施的五大優勢和四大挑戰 六成CIO贊同SOA實施的關鍵是服務構造 SOA實施先易後難大局為先 建立服務水平協議確保SOA實施 劉爾洪先生：服務構造是SOA實施的關鍵 SOA實施的優勢和挑戰 SOA實施 困難重重 尋找SOA實施真正阻礙 SOA實施要找對切入點 SOA實施必須注重治理 SOA實施四大關鍵點 SOA實施關鍵：構建服務組合 SOA里的Erlang和並發 SOA失敗的十大人為因素及改善建議（二） SOA失敗的十大人為因素及改善建議（一） 為什麼現在是實施沒有平台SOA的最佳時機（二） 為什麼現在是實施沒有平台SOA的最佳時機（一） 企業用什麼技術轉向SOA？ SOA演變過程 數據管理是企業成功實施SOA的關鍵 鏈接到WCF和Dublin的新AmberPoint序列 與未來有約SOA發展五大預測 有關SOA將死的謠言……（二） 有關SOA將死的謠言……（一） SOA架構實施錦囊：把脈SOA應從評估開始 SOA是死了還是僅僅處於休眠狀態？ IT花費見漲 SOA價值何在 阻礙SOA成功實施的三大因素 SOA應用的阻礙是領導的不重視 最好的SOA領航員並非一開始做好服務（二） 最好的SOA領航員並非一開始做好服務（一） 中國的SOA之路緣何只能自己走

5. 問一下soa的知識

SOA定義

下面是作者給SOA下的一個定義：SOA是指為了解決在Internet環境下業務集成的需要，通過連接能完成特定任務的獨立功能實體實現的一種軟體系統架構。從這個定義中我希望表達的前提有下面兩點：

1) 軟體系統架構：SOA不是一種語言，也不是一種具體的技術而是一種軟體系統架構，它嘗試給出在特定環境下推薦採用的一種架構，從這個角度上來說，它更像一種模式(Pattern)。因此它與很多已有的軟體技術比如面向對象技術，是互補的而非互斥的。它們分別面向不同的應用場景，用來滿足不同的特定需求。

2) SOA的使用范圍：需求決定同時也限制功能。SOA並不是包治百病的萬靈丹，它最主要的應用場合在於解決在Internet環境下的不同商業應用之間的業務集成問題。在下面我們會詳細討論Internet的各種特點如何決定SOA的特點，這里我們只需要先簡單回顧一下Internet環境區別於Intranet環境的幾個特點：

a) 大量異構系統並存，計算機硬體工作方式不同，操作系統不同、編程語言也不同；

b) 大量、頻繁的數據傳輸仍然速度緩慢並且不穩定；

c) 版本升級無法完成，我們根本就無法知道互聯網上有哪些機器直接或者間接的使用某個服務。

基於上面的前提，下面就讓我們一起看一下SOA的基本特徵。

SOA三大基本特徵

1 獨立的功能實體

在Internet這樣鬆散的使用環境中，任何訪問請求都有可能出錯，因此任何企圖通過Internet進行控制的結構都會面臨嚴重的穩定性問題。SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的組件技術，如.NET Remoting，EJB，COM或者CORBA，都需要有一個宿主(Host或者Server)來存放和管理這些功能實體；當這些宿主運行結束時這些組件的壽命也隨之結束。這樣當宿主本身或者其它功能部分出現問題的時候，在該宿主上運行的其它應用服務就會受到影響。

SOA架構中非常強調實體自我管理和恢復能力。常見的用來進行自我恢復的技術，比如事務處理(Transaction)，消息隊列(Message Queue)，冗餘部署(Rendant Deployment)和集群系統(Cluster)在SOA中都起到至關重要的作用。

2 大數據量低頻率訪問

對於.NET Remoting，EJB或者XML-RPC這些傳統的分布式計算模型而言，他們的服務提供都是通過函數調用的方式進行的，一個功能的完成往往需要通過客戶端和伺服器來回很多次函數調用才能完成。在Intranet的環境下，這些調用給系統的響應速度和穩定性帶來的影響都可以忽略不計，但是在Internet環境下這些因素往往是決定整個系統是否能正常工作的一個關鍵決定因素。因此SOA系統推薦採用大數據量的方式一次性進行信息交換。

3 基於文本的消息傳遞

由於Internet中大量異構系統的存在決定了SOA系統必須採用基於文本而非二進制的消息傳遞方式。在COM、CORBA這些傳統的組件模型中，從伺服器端傳往客戶端的是一個二進制編碼的對象，在客戶端通過調用這個對象的方法來完成某些功能；但是在Internet環境下，不同語言，不同平台對數據、甚至是一些基本數據類型定義不同，給不同的服務之間傳遞對象帶來的很大困難。由於基於文本的消息本身是不包含任何處理邏輯和數據類型的，因此服務間只傳遞文本，對數據的處理依賴於接收端的方式可以幫忙繞過兼容性這個的大泥坑。

此外，對於一個服務來說，Internet與區域網最大的一個區別就是在Internet上的版本管理極其困難，傳統軟體採用的升級方式在這種鬆散的分布式環境中幾乎無法進行。採用基於文本的消息傳遞方式，數據處理端可以只選擇性的處理自己理解的那部分數據，而忽略其它的數據，從而得到的非常理想的兼容性。

HTTP協議：一個典型的SOA實現

每一項新技術都是在一些舊的技術基礎上發展出來的。正如XML根本思想來自於在60年代就已經出現的早期標記性語言一樣，SOA雖然這兩年才出現，但是它所表達的觀念應該說在網路這種分布式系統結構出現不久就已經廣泛應用了。例如我們最熟悉的HTTP協議就是一個非常典型的SOA架構設計。HTTP協議的工作過程簡單敘述如下：

1) 客戶端，通常是通過瀏覽器，向伺服器端以文本的方式發送一個請求，索取一個Web頁面；

2) 伺服器端接收到這個請求之後，根據請求的內容進行處理並且返回一個符合HTML語法的文本；

3) 客戶端接收到伺服器端的響應文本後調用本地的程序，通常還是瀏覽器，把返回的HTML文本的內容展現出來。

下面來看一下HTTP協議如何滿足了SOA的特點：

* 獨立的功能實體：作為伺服器端的Web伺服器是絕對不會因為客戶端的狀況變化而改變的，它總是非常穩定地按照自己的內在邏輯運行，響應外部的請求，管理自己的資源和數據。這里一個非常好的例子就是Web伺服器對緩存(Cache)的處理，很多Web伺服器為了提高性能都或多或少的對數據進行緩存，但是緩存數據、刷新數據這些於客戶端完全無關的操作完全由伺服器端獨立完成，完全不受客戶端的影響。

* 大數據量低頻率訪問：對於一個HTTP請求來說，客戶端與伺服器之間訪問的邊界非常簡單：就是一個請求，一個響應，沒有任何其它的信息往返。無論客戶端申請的網頁上除了文字之外還有什麼信息，對於客戶端來說，它發出的請求只是簡單的告訴Web伺服器它所需要的網頁的位置；至於為了生成這個網頁，伺服器端是否需要訪問資料庫，執行Servlet或者其它的CGI程序對客戶端而言，都是完全透明的。

* 基於文本的消息傳遞：迄今為止兼容性最好的系統可能就是HTTP協議支撐的大部分的web應用了，我們可以在Windows平台下用IE查看互聯網上一個Linux＋Apache伺服器上的由Perl腳本自動生成的網頁。這里的關鍵就是所有內容都是以格式化的文本方式傳遞的，不管Perl腳本如何執行，只要它的輸出是符合HTML規范的網頁，就可以被客戶端的瀏覽器解釋。而由於不同的操作系統上對於相同的HTML的解釋遵循相同的規范，因此不同操作系統下仍然能夠看到一致的用戶界面。

我們上面基本描述了SOA作為一種軟體架構有哪些特點，下面讓我們一起看看Web Service與SOA的關系。

SOA與Web Service

Web Service是就現在而言最適合實現SOA的一些技術的集合，事實上最近SOA的火爆在很大程度上歸功於Web Service標準的成熟和應用的普及為廣泛的實現SOA架構提供了基礎。下面讓我們看看Web Service中的各種協議是如何互相工作來滿足SOA所需的特點的：

* 獨立的功能實體：通過UDDI的目錄查找，我們可以動態改變一個服務的提供方而無需影響客戶端的應用程序配置。所有的訪問都通過SOAP訪問進行，只要WSDL介面封裝良好，外界客戶端是根本沒有辦法直接訪問伺服器端的數據的。

* 大數據量低頻率訪問：通過使用WSDL和基於文本(Literal)的SOAP請求，我們可以實現能一次性接收大量數據的介面。這里需要著重指出的是SOAP請求分文本方式和遠程調用(RPC)兩種方式，正如上文已經提到的，採用遠程調用方式的SOAP請求並不符合這點要求。但是令人遺憾的是現有的大多數SOAP請求採用的仍然是遠程調用(RPC)方式，在某些平台上，例如IBM WebSphere的早期版本，甚至沒有提供文本方式的SOAP支持。

* 基於文本的消息傳遞：Web Service所有的通訊是通過SOAP進行的，而SOAP是基於XML的，不同版本之間可以使用不同的DTD或者XML Schema加以辨別和區分。因此只需要我們為不同的版本提供不同的處理就可以輕松實現版本控制的目標。

SOA對於軟體架構設計的影響

無論您現在的系統是否牽涉到基於Internet的業務集成，採用SOA推薦的架構都對提高您系統的擴展性有很大幫助，下面是在系統中引入SOA後需要在軟體架構方面做出的改變：

* 使用基於文本方式的SOAP調用，擺脫遠程調用中出現的函數參數類型等與數據無關的信息，保證所有SOAP傳遞的都是有意義的商業數據。依賴於Schema，而不是類定義對這些數據進行解釋。

* 傳統的三層Web應用將可能變成四層結構：傳統意義上的商業邏輯層將被進一步劃分為存放每個會話(Session)信息的客戶邏輯層和與狀態無關Sateless的SOA層。

來自網站:"ERP總設計師"

6. SOA服務需具有什麼特性

只要服務介面保持穩定，抽象出來的介面就能讓提供者和消費者獨立演變。所以基於SOA服務的信息化系統可以提供與業務更貼合的信息化服務，更便利的解決跨行業、跨部門的信息資源互聯互通，推動重要信息資源的開發利用，並可以支撐和促進各行業相關的業務變革和發展。
事實，實現介面的穩定性是SOA服務面臨的最大挑戰。因為業務服務介面的作用不只是確定了系統的邊界。業務服務對業務流程的一部分進行了封裝，建立了被封裝部分和其餘部分之間的介面。以「銷售訂單管理服務」為例，它封裝了業務流程中創建和維護銷售訂單的部分。由此看出，在定義業務服務時，既是為系統也是為業務流程搭建架構。可見信息與業務流程的運轉息息相關，即便最簡單的服務也管理著一些信息。服務的定義決定了它要管理的信息，並使其區別於其他系統組件和服務所管理的信息。「銷售訂單管理服務」是銷售訂單信息的記錄系統，但不管理倉庫庫存。通過這種方式，業務服務完成了對信息的模塊化的分解。界定了每個模塊的服務范圍。不同模塊之問的數據需求即為模塊需要提供的服務。
由此，SOA服務需具有以下特性：
（1）SOA服務用消息進行通信，應具有平台的語法和語義文件，該消息通常使用XMLSchema來定義。在企業內部，SOA服務通常是利用一個目錄列表角色的登記處來進行維護。應用程序再在登記處查尋並調用某項服務。統一描述、定義和集成是服務登記的標准，每項SOA服務都有一個與之相關的服務品質（Qualityofservice，QOS）。QOS的一些關鍵元素有安全需求（例如認證和授權），可靠通信（是指確保消息「僅且僅僅」發送一次，從而過濾重復信息。），以及誰能調用服務的策略。
（2）SOA服務把業務組件分成基本的構建模塊，就像通過標准化軟體介面實現lT基礎設施的模塊化，從而使業務流程可以與IT流程相匹配。

7. SOA的為何選擇SOA

不同種類的操作系統，應用軟體，系統軟體和應用基礎結構（application infrastructure）相互交織，這便是IT企業的現狀。一些現存的應用程序被用來處理當前的業務流程（business processes），因此從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程序和應用基礎結構（application infrastructure）的投資來解決新的業務需求，為客戶，商業夥伴以及供應商提供新的互動渠道，並呈現一個可以支持有機業務（organic business）的構架。SOA憑借其松耦合的特性，使得企業可以按照模塊化的方式來添加新服務或更新現有服務，以解決新的業務需要，提供選擇從而可以通過不同的渠道提供服務，並可以把企業現有的或已有的應用作為服務， 從而保護了現有的IT基礎建設投資。
如圖1的例子所示，一個使用SOA的企業，可以使用一組現有的應用來創建一個供應鏈復合應用（supply chain composite application），這些現有的應用通過標准介面來提供功能。
為了實現SOA，企業需要一個服務架構，圖2顯示了一個例子：
在圖2中， 服務消費者（service consumer）可以通過發送消息來調用服務。這些消息由一個服務匯流排（service bus）轉換後發送給適當的服務實現。這種服務架構可以提供一個業務規則引擎（business rules engine），該引擎容許業務規則被合並在一個服務里或多個服務里。這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，類似審核，列表（billing），日誌等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控制請求（regulatory requirement），例如Sarbanes Oxley（SOX），並且可以在不影響其他服務的情況下更改某項服務。 要運行，管理SOA應用程序，企業需要SOA基礎，這是SOA平台的一個部分。SOA基礎必須支持所有的相關標准，和需要的運行時容器。圖3所示的是一個典型的SOA基礎結構。
SOAP， WSDL， UDDI
WSDL，UDDI和SOAP是SOA基礎的基礎部件。WSDL用來描述服務；UDDI用來注冊和查找服務；而SOAP，作為傳輸層，用來在消費者和服務提供者之間傳送消息。SOAP是Web服務的默認機制，其他的技術為可以服務實現其他類型的綁定。一個消費者可以在UDDI注冊表（registry）查找服務，取得服務的WSDL描述，然後通過SOAP來調用服務。
WS-I Basic Profile
WS-I Basic Profile，由Web服務互用性組織（Web Services Interoperability Organization）提供，是SOA服務測試與互用性所需要的核心構件。服務提供者可以使用Basic Profile測試程序來測試服務在不同平台和技術上的互用性。
J2EE 和 .Net
盡管J2EE和.NET平台是開發SOA應用程序常用的平台，但SOA不僅限於此。像J2EE這類平台，不僅為開發者自然而然地參與到SOA中來提供了一個平台，還通過他們內在的特性，將可擴展性，可靠性，可用性以及性能引入了SOA世界。新的規范，例如 JAXB（Java API for XML Binding），用於將XML文檔定位到Java類；JAXR（Java API for XML Registry）用來規范對UDDI注冊表（registry）的操作；XML-RPC（Java API for XML-based Remote Procere Call）在J2EE1.4中用來調用遠程服務，這使得開發和部署可移植於標准J2EE容器的Web服務變得容易，與此同時，實現了跨平台（如。NET）的服務互用。 隨著企業服務的增長，所使用的服務和業務進程的數量也隨之增加，一個用來讓系統管理員管理所有運行在多相環境下的服務的管理系統就顯得尤為重要。WSDM（Web Services for Distributed Management）規定了任何根據WSDM實現的服務都可以由一個WSDM適應（WSDM-compliant）的管理方案來管理。
其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-Coordination 和 WS-Transaction 標准中描述， 這些都是OASIS 的工作。 A. 平衡最初的舊系統投資(Leverage initial investment)：
組織過去所投資的系統、軟硬體，如果能再利用等於賦予其新的價值，這也替組織降低成本並增加競爭力。
B. 基礎建設的便利性(Infrastructure Commoditization)：
讓所有的應用程式能相互溝通(互通性)。
C. 快速的接近市場(Faster time-to-market)：
服務的重復使用(再利用)，來縮短過去的組織流程，更快速的提供服務來接近市場。
D. 減少支出(Rece Cost)：
服務的重復使用，可降低開發成本。因為開發新系統的成本，大部份比更新舊有系統來的花費大。
E. 減低風險(Risk mitigation)：
開發新系統的風險遠大於更新舊系統。
F. 持續改善商業流程的循環(Continuous improvement cycle for business process)
G. 中心流程處理(Process-centric processing) 一，SOA可通過互聯網伺服器發布，從而突破企業內網的限制，實現與供應鏈上下游夥伴業務的緊密結合。通過SOA架構，企業可以與其業務夥伴直接建立新渠道，建立新夥伴的成本得以降低。
二，SOA與平台無關，減少了業務應用實現的限制。要將企業的業務夥伴整合到企業的「大」業務系統中，對其業務夥伴具體採用什麼技術沒有限制。
三， SOA具有低耦合性特點，業務夥伴對整個業務系統的影響較低。在企業與各業務夥伴關系不斷發生變化的情況下，節省的費用會越來越多。
四， SOA具有可按模塊分階段進行實施的優勢。可以成功一步再做下一步，將實施對企業的沖擊減少到最小。
五， SOA的實施可能並不具有成本顯著性。這要分三種情況加以討論：
(1) 當企業從零開始構建業務系統時，採用SOA架構與不採用SOA架構成本可看做是相同的。
(2) 當企業業務發展或發生企業重組等變化而原有系統不能滿足需要，而需要重構業務系統時，採用SOA架構與不採用SOA架構成本可看做是相同的。
(3) 當企業業務發生緩慢變化並可預見到將來需要重構業務系統時，由於可以按模塊分階段逐步實施SOA以適應變化的需要，這樣企業不需一下投入一大筆經費進行系統改造，而是根據企業業務發展情況和資金情況逐步投入，緩解了信息投入的壓力。 IDC負責企業平台研究的副總裁Michelle Bailey說，最近的IDC的研究表明，到2011年，18%以上的全部新伺服器都將採用虛擬化技術，對於伺服器硬體供應商來說，這是一個年收入達220億美元的市場機會。
對於企業來說，日益增長的挑戰是如何管理和保證虛擬環境的安全，因為隨著機構採用虛擬化技術，傳統的管理物理伺服器蔓延的挑戰正在轉向管理虛擬機蔓延的挑戰。機構將需要可靠的、穩定的、安全的和可管理的虛擬化解決方案。
綠色IT一直被列為頭號的戰略技術和2008年大多數機構的趨勢。據IDC稱，虛擬化的綠色的好處不僅是減少伺服器佔地面積，而是還包括減少碳排放量和耗電量。這些好處正在成為重要的好處。
據IDC對亞太地區綠色IT的調查，75%的受訪者對於IT部門沒有綠色IT政策。然而，80%以上的受訪者認為他們的IT供應商的「綠色」在未來幾年將更加重要。
虛擬化在這方面將發揮重要作用，一些企業將採用更環保的方法經營業務以便贏得政府部門的合同。其它機構正在採用虛擬化技術以便得到節省電源的好處和減少碳排放量的獎勵。
同時，一些企業管理者和市場研究人士也對虛擬化的未來發展發表了看法：
Avnet公司營銷經理Michael Costigan：
盡管虛擬化有巨大的潛力，許多轉銷商不知道這種有潛力的新技術的實際狀況。機構能夠獲得顯著的能量和計算效率，同時提高技術的應用率和靈活性。
為了幫助你的客戶認識到這些好處並且為你的企業建立強大的市場佔有率，你需要了解這個強大的新技術的細節，了解需要採取什麼有效手段識別和利用虛擬化的真正機會。
虛擬化正在用來解決范圍日益廣泛的商業目標和挑戰，如伺服器整合/保留、業務持續性、測試/開發優化、軟體開發與發布以及桌面管理和安全。
人們對於虛擬化的未來顯然非常感興趣。但是，還有許多言過其實的宣傳。第一波x86伺服器虛擬化的應用一直集中在伺服器整合方面，重點是減少資本開支 (也就是伺服器開支)以及電源和冷卻等運營開支。在未來的五年裡，機構將超越伺服器整合尋求如何利用虛擬化技術得到其它的好處，如重點減少運營成本(也就是物理管理成本)和讓基礎設施更有活力和更靈活，以便改善IT對於不斷變化的商業需求的反應能力。
分析師認為，虛擬化的下一個大事將是高可用性和災難恢復工具。災難恢復在歷史上一直是非常難管理的。虛擬化將提供一個節省成本的和容易管理的災難恢復解決方案。
虛擬桌面基礎設施、資源平衡和應用程序級高可用性可能是其它的未來應用實例。這些解決方案有一些技術的和經濟的障礙。這些障礙必須要在虛擬化廣泛應用前克服。但是，考慮到虛擬化的重點，這些障礙已經在開始克服。虛擬化還將成為SOA(面向服務的架構)技術應用的推動因素。 面向服務的體系結構基於這些實際活動或業務服務進行組織，而不是形成公司所維護的不同的信息豎井 (Silo)。通過實現 SOA，可以帶來大量好處，包括以下各個方面： *更高的業務和 IT 一致性
*基於組件的系統
*鬆散耦合的組件和系統
*基於網路的基礎設施，允許分散於各地且採用不同技術的資源協同工作
*動態構建的按需應用程序
*更高的代碼重用率
*更好地標准化整個企業內的流程
*更易於集中企業控制

8. 如何認清面向服務架構SOA的真實面目

在經典軟體工程理論中，不管是瀑布方法還是原型方法，都是從需求分析做起，一步一步構建起形形色色的軟體系統。但是，需求變更像一個揮之不去的陰影，時刻伴隨著系統左右。每一個實際應用系統的開發者都飽嘗了在系統進入開發階段、測試階段，甚至上線階段遭遇應接不暇的需求變更的極端痛苦。客戶將變更的需求視為bug(錯誤)是測試上線階段的主要問題。 如何解決這一問題?能否來一場軟體開發和架構的革命?SOA架構的提出，就是被人看成這樣的一場革命。其實質就是要將系統模型與系統實現分割開來。 1.定義 SOA並不是一個新概念，有人就將CORBA和DCOM等組件模型看成SOA架構的前身。早在1996年，Gartner Group就已經提出了SOA的預言，不過那個時候僅僅是一個「預言」，當時的軟體發展水平和信息化程度還不足以支撐這樣的概念走進實質性應用階段。到了近一兩年，SOA的技術實現手段漸漸成熟了。在BEA、IBM等軟體巨頭的極力推動下，才得以慢慢風行起來。Gartner為SOA描述的願景目標是實現實時企業(Real-Time Enterprise)。 關於SOA，目前尚未有一個統一的、業界廣泛接受的定義。一般認為：SOA，面向服務的架構是一個組件模型，它將應用程序的不同功能單元 ----服務(service)，通過服務間定義良好的介面和契約(contract)聯系起來。介面採用中立的方式定義，獨立於具體實現服務的硬體平台、操作系統和編程語言，使得構建在這樣的系統中的服務可以使用統一和標準的方式進行通信。這種具有中立的介面定義(沒有強制綁定到特定的實現上)的特徵稱為服務之間的松耦合。 從這個定義中，我們看到下面兩點： ·軟體系統架構： SOA不是一種語言，也不是一種具體的技術，更不是一種產品，而是一種軟體系統架構，它嘗試給出在特定環境下推薦採用的一種架構，從這個角度上來說，它其實更像一種架構模式(Pattern)，是一種理念架構，是人們面向應用服務的解決方案框架。 ·服務(service)是整個SOA實現的核心。SOA架構的基本元素是服務，SOA 指定一組實體(服務提供者、服務消費者、服務注冊表、服務條款、服務代理和服務契約)，這些實體詳細說明了如何提供和消費服務。遵循 SOA 觀點的系統必須要有服務，這些服務是可互操作的、獨立的、模塊化的、位置明確的、松耦合的並且可以通過網路查找其地址。 2.SOA三種角色的關系 服務是一個自包含的、無狀態(stateless)的實體，可以由多個組件組成。它通過事先定義的界面響應服務請求。它也可以執行諸如編輯和處理事務(transaction)等離散性任務。服務本身並不依賴於其他函數和過程的狀態。用什麼技術實現服務，並不在其定義中加以限制。 服務提供者(service provider)提供符合契約(contract)的服務，並將它們發布到服務代理。 服務請求者(service consumer)也叫服務使用者，它發現並調用其他的軟體服務來提供商業解決方案。從概念上來說，SOA 本質上是將網路、傳輸協議和安全細節留給特定的實現來處理。服務請求者通常稱為客戶端，但是，也可以是終端用戶應用程序或別的服務。 服務代理者(service broker)作為儲存庫、電話黃頁或票據交換所，產生由服務提供者發布的軟體介面。 這三種 SOA 參與者：服務提供者、服務代理者以及服務請求者通過 3 個基本操作：發布(publish)、查找(find)、綁定(bind)相互作用。服務提供者向服務代理者發布服務。服務請求者通過服務代理者查找所需的服務，並綁定到這些服務上。服務提供者和服務請求者之間可以交互。 所謂服務的無狀態，是指服務不依賴於任何事先設定的條件，是狀態無關的(state-free)。在SOA架構中，一個服務不會依賴於其他服務的狀態。 它們從客戶端接受服務請求。因為服務是無狀態的，它們可以被編排(orchestrated)和序列化(sequenced)成多個序列 (有時還採用流水線機制) ，以執行商業邏輯。編排指的是序列化服務並提供數據處理邏輯。但不包括數據的展現功能。 3.SOA特徵 基於上面討論，我們給出SOA的下面一些特徵： ·服務的封裝(encapsulation)。將服務封裝成用於業務流程的可重用組件的應用程序函數。它提供信息或簡化業務數據從一個有效的、一致的狀態向另一個狀態的轉變。封裝隱藏了復雜性。服務的API保持不變，使得用戶遠離具體實施上的變更。 ·服務的重用(reuse)。服務的可重用性設計顯著地降低了成本。為了實現可重用性，服務只工作在特定處理過程的上下文(context)中，獨立於底層實現和客戶需求的變更。 ·服務的互操作(interoperability)。互操作並不是一個新概念。在CORBA、DCOM、web service中就已經採用互操作技術了。在SOA中，通過服務之間既定的通信協議進行互操作。主要有同步和非同步兩種通信機制。SOA提供服務的互操作特性更利於其在多個場合被重用。 ·服務是自治的(Autonomous)功能實體。服務是由組件組成的組合模塊，是自包含和模塊化的。 SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的組件技術，如。NET Remoting， EJB，COM或者CORBA，都需要有一個宿主(Host或者Server)來存放和管理這些功能實體;當這些宿主運行結束時這些組件的壽命也隨之結束。這樣當宿主本身或者其它功能部分出現問題的時候，在該宿主上運行的其它應用服務就會受到影響。 SOA架構中非常強調實體自我管理和恢復能力。常見的用來進行自我恢復的技術，比如事務處理(Transaction)，消息隊列 (Message Queue)，冗餘部署(Rendant Deployment)和集群系統(Cluster)在SOA中都起到至關重要的作用。 ·服務之間的松耦合度(Loosly Coupled)。服務請求者到服務提供者的綁定與服務之間應該是松耦合的。這就意味著，服務請求者不知道提供者實現的技術細節，比如程序設計語言、部署平台，等等。服務請求者往往通過消息調用操作，請求消息和響應，而不是通過使用 API 和文件格式。 這個松耦合使會話一端的軟體可以在不影響另一端的情況下發生改變，前提是消息模式保持不變。在一個極端的情況下，服務提供者可以將以前基於遺留代碼(例如，COBOL)的實現完全用基於 Java 語言的新代碼取代，同時又不對服務請求者造成任何影響。這種情況是真實的，只要新代碼支持相同的通信協議。 ·服務是位置透明的(location transparency)。服務是針對業務需求設計的。需要反應需求的變化，即所謂敏捷(agility)設計。要想真正實現業務與服務的分離。就必須使得服務的設計和部署對用戶來說是完全透明的。也就是說，用戶完全不必知道響應自己需求的服務的位置，甚至不必知道具體是哪個服務參與了響應。 4.三個抽象級 從概念上講，SOA 中有三個主要的抽象級別： ·操作：代表單個邏輯工作單元(LUW)的事務。執行操作通常會導致讀、寫或修改一個或多個持久性數據。SOA 操作可以直接與面向對象 (OO) 的方法相比。它們都有特定的結構化介面，並且返回結構化的響應。完全同方法一樣，特定操作的執行可能涉及調用附加的操作。 ·服務：代表操作的邏輯分組。服務可以分層，以降低耦合度和復雜性。一個服務的粒度(granularity)大小也與系統的性能息息相關。粒度太小，會增加服務間互操作通訊的開銷;粒度太大，又會影響服務面對需求變化的敏捷性。 ·業務流程：為實現特定業務目標而執行的一組長期運行的動作或活動。業務流程通常包括多個業務調用。 在SOA中，業務流程包括依據一組業務規則按照有序序列執行的一系列操作。操作的排序、選擇和執行稱為服務或流程編排。典型的情況是調用已編排服務來響應業務事件。從建模的觀點來看，由此帶來的挑戰是如何描述設計良好的操作、服務和流程抽象的特徵以及如何系統地構造它們。這些涉及服務建模、特徵抽取的問題已經成為現階段人們關注的焦點。

9. SOA的新興變革

隨著全球信息化的浪潮，信息化產業不斷發展、延伸，已經深入了眾多的企業及個人，SOA系統架構的出現，將給信息化帶來一場新的革命。
縱觀信息化建設與應用的歷程，盡管出現過XML（標准通用標記語言的子集）、Unicode、UML等眾多信息標准，但是許多異構系統之間的數據源仍然使用各自獨立的數據格式、元數據以及元模型，這是信息產品提供商一直以來形成的習慣。各個相對獨立的源數據集成一起，往往通過構建一定的數據獲取與計算程序來實現，這樣的做法需要花費大量工作。信息孤島大量存在的事實，使信息化建設的ROI（投資回報率）大大降低，ETL成為集中這些異構數據的有效工具。 ETL常用於從源系統中提取數據，將數據轉換為與目標系統相兼容的格式，然後將其裝載到目標系統中。數據經過獲取、轉換、裝載後，要產生應用價值，還需另外的數據展現工具予以實現，如此復雜的數據應用過程，必定產生高昂的應用成本。
結構化的數據管理尚可通過以上方法，予以實現其集成應用。在非結構化的內容方面，這些具有挑戰性的問題令人生畏。內容管理的應用方案基於不同的信息化應用系統，而且大部分是縱向的以組織部門為界限的。在內容管理市場中，經常使用來自不同廠商的產品來提供這些解決方案。即使是同一個廠商的產品，相互之間的功能也是經常重疊，並且無法集成。
隨著信息化建設的深入，不同應用系統之間的功能界限已趨於模糊。同時企業資源計劃系統和協同商務系統，又需要商業智能的分析展現數據提供用戶操作依據。
在激烈競爭且多變的市場環境下，企業的管理模式很難固化，應用傳統的信息化軟體，當企業要做出一些改動時需要面對巨大的挑戰。
SOA系統架構的出現，信息化變革
微軟大中華區服務部總經理辛兒倫介紹說，從上世紀60年代應用於主機的大型主機系統，到80年代應用於PC的CS 架構，一直到90年度互聯網的出現，系統越來越朝小型化和分布式發展。2000年WebService出現後，SOA被譽為下一代Web服務的基礎框架，已經成為計算機信息領域的一個新的發展方向。
SOA的出現給傳統的信息化產業帶來新的概念，不再是各自獨立的架構形式，能夠輕松的互相聯系組合共享信息。
可復用以往的信息化軟體。基於SOA的協同軟體提供了應用集成功能，能夠將ERP、CRM、HR等異構系統的數據集成。
鬆散耦合方式，只要充分了解業務的進程，就可以不用編寫一行代碼，通過流程圖實現一套我們自己的信息系統。就像已經給你准備好了磚瓦和水泥，只需要想好蓋什麼樣的房子就可以輕松的蓋起。加快開發速度，並且減少了開發和維護的費用。軟體將所有的管理提煉成表單和流程，以記錄管理的內容，指定過程的流轉方向。
更簡便的信息和數據集成。信息集成功能可以將散落在廣域網和區域網上的文檔、目錄、網頁輕松集成，加強了信息的協同相關性。同時，復雜、成本高昂的數據集成，也變成了可以簡單且低成本實現的參數設定。創建了完全集成的信息化應用新領域。
在具體的功能實現上，SOA協同軟體所實現的功能包括了知識管理、流程管理、人事管理、客戶管理、項目管理、應用集成等，從部門角度看涉及了行政、後勤、營銷、物流、生產等。從應用思想上看，SOA協同軟體中的信息管理功能，全面兼顧了貫穿整個企業組織的信息化軟硬體投入。盡管各種IT技術可以用於不同的用途，但是信息管理並沒有任意地將信息分為結構化或者非結構化的部分，因此ERP等結構化管理系統並不是信息化建設的全部；同時，信息管理也沒有將信息化解決方案劃分為部門的視圖，因此僅僅以部分為界限去構建軟體應用功能的思想未必是不可撼動的。基於SOA的協同軟體與 ERP、CRM等傳統應用軟體相比，關鍵的不同在於它可以在合適的時間、合適的地點並且有正當理由向需要它提供服務的任何用戶提供服務。

10. 廣西移動soa介面出錯是什麼意思

是移動的網路出了問題，可以去當地營業廳進行詢問。

中國移動通信集團有限公司是按照國家電信體制改革的總體部署，於2000年4月20日成立的中央企業。2017年12月，中國移動通信集團公司進行公司制改制，企業類型由全民所有制企業變更為國有獨資公司，並更名為中國移動通信集團有限公司。中國移動是一家基於GSM、TDD-LTE、FDD-LTE制式網路的移動通信運營商。

中國移動全資擁有中國移動（香港）集團有限公司，由其控股的中國移動有限公司在國內31個和香港設立全資子公司，並在香港和紐約上市，主要經營移動語音、數據、寬頻、IP電話和多媒體業務，並具有計算機互聯網國際聯網單位經營權和國際出入口經營權。注冊資本3000億人民幣，資產規模近1.7萬億人民幣，員工總數近50萬人。