Windows LiveWindows Live™
 
 
James's profileJames の BlogPhotosBlogListsMore Tools Help

Blog
    11/9/2005

    SOA面面觀

    SOA面面觀
    文/iThome (記者) 2004-04-19

    SOA不是新的概念，卻因為Web Services的出現，舊瓶裝新酒而成了當紅炸子雞。然而，用得好，不如用得巧，雖然Web Services是平價的解決方案，卻不是萬靈丹，用對地方才能發揮SOA的效益。若盲目地「為Web Services而Web Services」的話，可有排頭吃了。



    近兩年來SOA（Service-Oriented Architecture；服務導向的架構）是被資訊產業喊得震天價響的當紅炸子雞，事實上，SOA並不是新的概念，早在十幾年前DCOM及CORBA規格中的ORBs（Object Request Brokers）即SOA的應用。Gartner預計，到2006年將有超過 60%的企業，會考慮以SOA作為建立關鍵業務應用的基本原則。SOA及SODA（Service-Oriented Development of Application；服務導向的軟體開發模式）在未來幾年將逐漸成為主流。 Web之所以大行其道，鬆散藕合是關鍵

    網際網路最初是為了分享學術及科學上的研究成果，第一份HTML網頁是由單純的文字與超連結組成，不久之後，內含圖形與其他多媒體資料的能力，很快地就被加到視覺化的Web身上。瀏覽器讓網際網路在短短幾年間，成為橫跨全球的資料庫。



    然而，對企業而言，重要的商業資訊都儲存於資料庫而非文件中，隨著時間的演進，維護大量的靜態HTML網頁，將成為繁瑣的任務。因此CGI、ASP、JSP等動態網頁技術應運而生，網站成了資料查詢、線上交易等服務的提供者，開始執行應用程式的任務。當任務變得愈來愈重要，便出現新一代的中介軟體－應用伺服器，介於前端表現層及後端資訊系統之間，兼顧安全性、穩定性、可用性、延展性及效能等各方面要求，擔任執行商業邏輯的角色。



    網際網路之所以成功，BEA技術經理蕭百齡認為：「遵循開放標準，帶來鬆散藕合（Loose Coupling）的模式是最重要的關鍵。」然而網路的應用必須依賴瀏覽器，又顯得被僵化地限制，因此人們開始思考更中立的方式，讓消費端可自行決定如何處理及呈現服務端所提供的資訊。



    XML就是在這樣的時空背景下產生的技術，目的在於提供一個精準描述資料的機制，以彌補HTML太過著重資料呈現的特質。Web Services讓服務端提供的資訊，除了瀏覽器外，手機、IA家電、其他伺服器上的服務，甚至辦公室文書軟體都成了潛在的資訊消費者。



    業務導向的組裝式系統
    傳統應用導向開發的軟體，試圖在各個領域提供解決方案，產生ERP、CRM、SCM及PLM等，獨立、訊息不交流且難以整合的系統。然而量身訂作自行建置的成本過高，因此企業多選擇套裝的解決方案，再自行加以客製化。然而由於套裝系統的架構僵硬，缺乏變動的彈性，往往是使用者屈就系統功能，而非系統配合使用者的習慣，這也是導入系統時，容易遭遇使用者因習慣改變而反彈的原因。



    「開發即整合，整合即開發」是SOA的新思維，顛覆傳統應用導向的思維，強調的「服務」是以業務為主軸，提供各項資訊基本應用功能，以拉近資訊系統與業務之間的距離，而著眼於貫穿資訊孤島，提供可排列組合的各項服務。



    將系統功能模組轉換成各種服務後，透過BPM橫向貫穿ERP、CRM、SCM及PLM等，企業對內和對外各種系統，串連服務成為請採購等各類商業流程。未來業務需求或商業流程改變時，將保有調整的最佳彈性。



    SODA也確保應用系統以先天即能互相整合的方式來設計，讓企業所開發的新應用系統能輕易地與其他系統整合，迅速藉由新的或現有的「服務」來建立組合式的應用系統，並賦予因應未來整合所需要的彈性。



    臺灣IBM公司軟體事業處商業整合產品專員董俊賢說明：「SOA類似硬體IC的概念，再透過流程串連各種服務，組合成解決方案。」過去軟體設計無法實現IC模組的概念，是因為各家使用專屬的技術及規格，使得模組受到特定技術的箝制；而今在開放標準下，整合不再是夢想。



    Services未必是Web 「Services」
    要建構有效的SOA，必須先清楚了解「Service」這個專有名詞的意義，Service是一個定義明確且獨立運作的功能，且與其他Services的內容及狀態沒有相依性。



    董俊賢強調：「SOA是架構性的概念，不能窄化SOA的定義，Services指的並不一定是Web Services。」Services是物件導向的延伸，過去SmallTalk、CORBA到後來微軟的DCOM及J2EE的EJB和JavaBean等都是SOA的應用。由於使用專屬的語言，所以無法互通，直到Web Services的出現，才露出整合的曙光。



    DCOM是微軟執行遠端呼叫的專屬機制，雖然與Web Services同樣是跨語言的技術，卻僅支援Visual C++、Visual Basic及C#等語言，受到微軟平臺的綑綁，便限制了應用範圍。最新的.NET Remoting也是.NET平臺SOA的應用，但也僅限於.NET平臺。



    事實上，CORBA與Web Services類似，擁有跨平臺及程式語言能力，且成熟度較高，但必須付出較高的學習成本。CORBA仰賴IDL解譯資料，但一般人難以理解IDL的內容，開發人員必須學習IDL，困難度因而成為阻礙發展的金箍咒，影響市場的接受度。相較之下Web Services的XML可讀性高，且多數開發Web Services的工具均可自動產生WSDL。再加上CORBA的架構必須在每個用戶端安裝IDL的解譯器，所以只適合企業內部網路的應用。



    SOA大放異彩的原因，與XML及Web Services的成熟有絕對的關係，由於遵循開放標準，而帶來鬆散藕合的架構，SOA的架構將不再受到特定技術或產品緊密的綑綁。BPM是串連服務的神經系統

    在SOA的架構中，BPM（Business Process Management；企業流程管理）扮演串連各種服務形成企業流程或資訊流的角色，也可說是流程管理的解決方案，由流程模型建置、流程分析、流程模擬、流程執行、流程監控及流程管理等功能組成。但實現BPM未必需要搭配BPM產品，董俊賢強調：「BPM這個專有名詞，是為解決整合的問題而提出的概念，並非產品。」傳統以紙本傳遞，或土法煉鋼撰寫程式的方法，也是BPM的作法。套裝化BPM產品的目的，是為減少撰寫程式的負擔，並降低維護與管理的成本。



    BPM若要成為SOA架構中，串連服務的神經系統，除了要支援Web Services，及提供連接既有系統的配接器之外，還必須使用相同的標準，BPM產品才有互通的可能。在戰國時代百家爭鳴的標準中，OASIS的BPEL是大家認為比較可能成為主流的標準。



    不過企業仍然存有疑慮，即使各家BPM產品都支援BPEL，然而會不會上演類似J2EE的情況，在標準之外加入專屬的規格，因而破壞了相容性。蕭百齡表示：「各廠商或許有提供額外加值的功能，但最基本的相容性可以透過認證，確保跨BPM產品對 BPEL 格式匯出/匯入的相容性。」這就類似現在WS-I推的Basic Profile觀念，只要遵循指導方針，即可以產業標準為基礎，開發及建置具互通性的BPEL格式。



    另一個擔憂是使用BPEL與合作夥伴串接流程，會不會洩露內部流程？事實上，只要遵循建置B2B流程的最佳實作，訂定Public和Private Processes，內部與外部的介面是完全隔開的。



    SOA的好處
    開發軟體時，建置健全的服務層，將帶來更好的投資報酬率。每個Service對應到明確的商業領域，當系統產生新的需求時，只需開發新的元件提供額外的服務。由於各項服務擁有明確的獨立性，所以其生命周期很有可能比最初的系統還長久。



    SOA的Services位置必須透明，應用程式將Services以目錄管理，在執行階段才動態結合在一起。這樣的特性促使更好的延展性，因為負載平衡機制可在不知道Services用戶端的情況下，轉送要求到多個Instance。也因為這樣的透明度，可以在多臺伺服器的Instance建立相同的Services，如果部分網路或某臺伺服器出現問題，使用者的要求可重新指派到其他伺服器的Services，使得系統擁有更好的穩定性。



    既然Services存放位置的透明度是SOA的特性，程式可攜性即可實現。用戶端無需在意服務的所在地點，因此企業可彈性地移動服務到不同的地方，甚至提供合作夥伴或客戶使用。



    SOA促使應用程式分為多層式的架構，每一層都有專門的技術，開發人員將專業分工，負責應用程式不同部分。企業得利於不再過度仰賴高成本的獨門人才，可使用經驗較少的大眾人才。



    以單一或主從架構建置系統，安全機制一般由前端處理，企業甚至沒有導入資料庫的安全控管機制，因為管理多重的安全機制太過困難。而一個服務可能提供多個應用程式使用，因此有獨立完整的安全機制，應用程式將有用戶端及服務端的雙重認證，可強化安全性。



    Services有公開的介面可方便執行單元測試，開發人員可使用工具製作測試案例，以確認Services的獨立性可被任何應用程式使用。除錯是軟體考古學中相當困難的任務，藉由將商業邏輯集中於Services層，系統的可維護性將大幅提升，因為開發人員將更容易找到及更正錯誤的部分。



    完整的測試通常意謂著更少的缺失及更好的品質。開發人員將逐漸建構一系列有用Services，企業將了解這些Services是可再利用資產，可以各種方式組裝，新的應用程式將因此而更快被開發出來。



    程式碼的再利用是最常被討論的議題，然而由於程式語言及平臺的不相容，一直很難達成這個理想。元件及Services比較容易被再利用，開發人員不需要再煩惱編譯器的版本、平臺或其他可能影響的因素。



    多層式的架構也代表可獨立作業，只要在專案開始時建立好介面溝通的契約，各層的開發人員可同時進行自各的開發工作，縮短開發時程。.NET與Java在SOA方面的表現

    微軟在Windows Server 2003上市的同時，也結合.NET Framework、IIS 6.0及Visual Studio .NET提出「應用伺服器」的解決方案。Visual Studio .NET是相當方便的Web Services開發工具，並強調獨門的C#及VB.NET語法簡捷且API完整，可強化開發導入的速度。在未來以Web Services為基礎開發的Longhorn作業系統，搭配.NET的Whitehorse及Indigo新套件，將提供更有效率的Web Services開發環境。



    BEA WebLogic 8.1以應用伺服器為基礎平臺，結合Portal伺服器提供更好的使用者經驗；資料的彙整與管理也是重要的問題，Liquid Data是EII（Enterprise Information Integration；企業資料整合）解決方案，企業可透過標準XML查詢資料；企業內部與外部合作夥伴應用程式的整合，可透過BEA Integration Framework，以BPM、B2Bi及EAI解決方案完成。



    過去WebLogic必須搭配Borland JBuilder，才能開發Web Services。WebLogic Workshop則是所有解決方案共同的開發平臺， 自從前年推出第一代以來，被許多分析機構評為最簡單的Web Services開發工具。BEA認為J2EE就像DOS一樣，很重要卻也很枯燥，微軟的Windows作業系統之所以起飛的原因，就是因為高階圖形化的介面。不是每個人都需要學DOS，也不是每個人都需要了解艱澀難懂的J2EE，WorkShop即提供簡單容易使用的圖形使用者介面，即使一般使用者，也可利用WorkShop開發Web Services、設計Portal及組裝流程。



    IBM則基於SOA整個架構，針對企業在資源整合方面，提出ESB （Enterprise Services Bus）架構，以提供企業在導入SOA架構時方便管理及提升效率的基礎架構。 在ESB下提供企業內部或外部不論在企業流程、資料或系統，透過企業入口網站、B2B或 Web Services加以整合。



    IBM從2003年起開始將其相關的產品都加以提升支援ESB架構。在基於J2EE 架構WebSphere應用伺服器建構解決方案，MQ及WBI Borkers負責BPM的部分，再搭配入口網站伺服器、Web Services應用機制、WebSphere Business Integration為流程整合、DB2 Information Integrator是即時異質資料庫整合機制，及WebShpere Business Integration Adapters為B2B的配接器。



    對於企業既有的系統，Siebel、SAP及Oracle等ERP系統目前都已支援Web Services，多數應用伺服器及BPM工具均提供配接器（Adapter），至於自行開發的系統，由於開發工具普遍支援Web Services，只要有繼續維護，都可透過工具將元件轉換成Web Services。



    SOA對EDI與EAI的影響
    過去企業透過EDI（Electronic Data Interchange；電子資料交換），運用協定的標準與資料格式，經電子化傳遞方式，與合作夥伴及客戶交換訊息。以EAI（Enterprise Application Integration）整合內部的系統，減少重複輸入的機會。當SOA出現後，對EDI及EAI會造成什麼樣的衝擊？



    蕭百齡認為：「SOA 的精髓不是在取代什麼，而是要整合。」既有的EDI、EAI方式，及大型主機或ERP系統會繼續存在，但可以整合在SOA的架構之下。SOA可說是解決EAI課題的新方法，可取代舊式做法，而改以開放標準的Web services為溝通協定。董俊賢也表示:「SOA只是實作EDI及EAI的一種新的作法。」



    臺灣微軟.NET顧問經理李啟後表示：「以SOA的架構串連企業應用程式，相較於傳統EAI的技術，是比較經濟的作法。」隨著時間的演進，SOA所帶來的好處與價值，將超越傳統EAI投資。BEA則認為：「SOA是EAI的進一步應用，若一開始就考慮SOA，未來就沒有整合的問題，而是彈性組裝的系統。」傳統EAI整合各自獨立的系統難度高，往往需要藉助顧問服務，導致成本太高。SOA可減少建置與維護的門檻，降低專業工匠的需求，提高效率並降低成本。



    不過，Borland資深產品經理李匡正分析：「SOA很有機會取代傳統EDI的作法，但在EAI方面SOA並不是萬靈丹。」過去EDI建置的成本太高，無法普及到下游的廠商；而SOA是平價的EDI，且內建支援的開發工具較多，所以很有機會取代EDI。不過EAI屬於企業內部的資訊整合，是相當專業的領域，雖然SOA是低成本的EAI解決方案，但由於Web Services效能較差，除非是時效性要求不嚴苛的系統，否則Web Services的SOA架構不見得是最佳的解決方案。 SOA的關鍵原則

    Web Services雖是最新SOA架構應用的實作，但正確的設計觀念與周詳的導入規畫才是SOA的關鍵。掌握使用Web Services的技巧，才能發揮潛在的價值，否則將適得其反。蕭百齡表示：「在實作和設計上必須把握關鍵原則：鬆散藕合和正確的顆粒大小。」



    鬆散藕合白話文的意思就是立場中立，Web Services是異質系統溝通的介面，為避免被專屬技術緊密綑綁，或單方面調整時會衝擊雙方的溝通，介面要越中立越好。此外，中立的介面也進一步提升重複使用的機率，讓資源可以共享，增加開發的價值。



    顆粒大小也是抽象的概念，SOA強調業務導向，與過去設計函式（Function）或方法（Method）小顆粒的作法不同，在設計上XML傳遞的資料內容，應朝向設計業務上有意義的單元。



    由於適用Web Services的範圍、介面的長相及所謂顆粒大小的問題，是一門學問，而企業對SOA及Web Services的應用，目前並沒有清楚的概念與足夠的實際經驗，為避免「為Web Services而Web Services」，企業可能會尋求顧問服務。不過蕭百齡認為：「採用SOA架構，中大型企業會得利最多。」所以企業應不假外求，培養內部的建築師，組成專業的規畫團隊與業務單位充分溝通，才能有效降低專案失敗的機率。



    用對地方才能發揮效益
    根據Gartner Group的調查分析，J2EE將逐漸取代CORBA，這不代表CORBA就此消失，因為J2EE的規格中包含CORBA的架構，所以也可以說J2EE延續CORBA的應用；COM及COM+將逐漸由.NET取代，而.NET及J2EE的互通即透過Web Services。事實上，CORBA、DCOM也均有存在的價值，未來將存在於企業內部；Web Services則善長網際網路的溝通。



    SOA舊瓶裝新酒，在近兩年成為當紅的技術名詞，無非是與Web Services的崛起有關，雖然Web Services目前仍不算成熟，不過以其公開標準、跨平臺、成本低廉及鬆散藕合的特性，將是促成SOA引領風騷的主因。



    李啟後表示:「臺灣敏感的經濟型態，隨著全球趨勢脈動，企業特別需要SOA的架構，以因應靈活變動的需求。」企業的資訊系統需要更靈活的架構，以因應瞬息萬變的需求，才能發揮展現IT的價值。



    不過，一窩蜂的趕流行，可能勞民傷財也不見得有好的效果。Web Services不是萬靈丹，用在對的地方才能發揮真正的效益，蕭百齡認為：「單一系統或語言的溝通，Web Services不見得是最好的候選人；跨企業、系統或程式語言的交流，Web Services便是優先考量。」當然企業也不能忽略效能問題，效能要求嚴苛的系統，可考慮其他解決方案。文⊙李延華
    2:05:43 PM | Add a comment | Permalink | Blog it | SOA
    9/2/2005

    IBM : 服務導向架構中的資訊管理，第 1 部分: 發現 SOA 中的資訊管理角色


    標題 IBM : 服務導向架構中的資訊管理，第 1 部分: 發現 SOA 中的資訊管理角色

    學習資訊管理、它對服務導向架構（Service-Oriented Architecture，SOA）的重要性以及資訊管理和 SOA 之間的關係。然後我們研究將這些具有挑戰性的問題和重新設計應用到 SOA 中的資訊管理的優點。本文中（本系列文章包含兩部分，本文是第一部分），作者將資訊管理分為幾個不同的服務，並且提供了對於這些服務的高級概述。本文的目標讀者是架構師、資料建模者、資料庫管理員以及那些想要利用資訊管理功能的開發者，他們將該功能用於基於 SOA 的建模、架構、設計以及實作。

    了解更多資訊
    http://www-128.ibm.com/developerworks/tw/library/ws-soa-ims/

    IBM developerWorks 台灣
    IBM 為開發人員提供的資源
    http://www.ibm.com/developerworks/tw
    1:02:01 PM | Add a comment | Permalink | Blog it | SOA
    6/24/2005

    服務導向架構 (Service Oriented Architecture) 應用

    服務導向架構 (Service Oriented Architecture) 應用專欄：
    服務導向架構 (Service Oriented Architecture) 應用

    作者：簡西村(台灣微軟開發工具暨平台推廣處資訊平台策略顧問)

    貼近商業流程的新一代資訊架構: SOA

    服務導向架構 (SOA, Service Oriented Architecture) 是一種新興的系統架構模型，其主要概念是針對企業需求組合而成的一組軟體元件。組合的元素通常包括：軟體元件、服務及流程三個部份，當企業面對外部要求時，流程定義外部要求的處理步驟；服務包括特定步驟的所有程式元件，而元件則負責執行工作的程式。例如，當企業面對顧客訂單要求時，流程訂定訂單的處理步驟，服務則包括信用查詢、庫存查詢及接單作業等等，元件則是指真正完成信用查詢、庫存查詢等工作的程式。由例子中可見，SOA 的系統組成與企業的經營管理基本單元十分接近，如此高階的應用系統發展模式可使得發展者更專注於企業需求的滿足 (coarse grain)，而不僅僅是資訊技術的應用 (fine grain)。SOA 已成為現今軟體發展的重要技術，透過 SOA 讓異質系統整合變得容易，程式再用度也提高。不必自行開發或擁有所有程式元件，發展者可以視需要組合網路上最好的服務。不受限於特定廠商的產品功能或是平台，達到真正的開放性 (Openness)。

    從分散式元件架構到 SOA

    概念上，SOA 如同物件導向、軟體元件等軟體技術一般，運用小的零組件組合成應用系統。但 SOA 強調的是如何將彼此關係鬆散的應用系統功能元件在網路上發行、組合及使用。SOA 具有下列技術特性：

    • 分散式架構 (Distributed) － SOA 的組成元件是由許多分散在網路上的系統組合而來，可能是區域網路，也可能是來自廣域網路。例如網路服務技術 (Web Services) 就是運作 Internet HTTP Protocol 來相互連結的 SOA。如此的作法，也使得網路服務技術很快的就成為所有支援 Internet 的系統平台均能使用的技術。

    • •關係鬆散的界面 (Loosely coupled) －傳統的系統主要是將應用系統功能需求切割成相互關聯的小零組件，模組、物件或元件，發展者要花費極大的心力了解零組件是如何設計及使用，以確保不會違反零組件連接關係限制。如此一來，若要以不同零組件替換原始設計，就成為一件困難的事。SOA 的作法是以界面標準來組合系統，只要符合界面要求，零組件可以任意替換，大幅提高系統變更的彈性度。

    • 依據開放的標準 (Open standard) － 使用開放標準是 SOA 的核心特色，過去的軟體元件平台如 CORBA、DCOM、RMI、J2EE 採用專屬 Protocol 作為元件連結的規範，使得不同平台的元件無法相通。SOA 則著重於標準與互動性，將可避免不同平台 (.NET Web Services 與 Java Web Services) 所開發程式間相互整合的困擾。

    • 以流程角度出發 (Process centric) － 在建構系統時，首先了解特定工作的流程要求，並將其切割成服務界面 (包括輸入與輸出資料格式)，如此其他的發展者就可以依據服務界面開發 (或選擇) 合適的元件來完成工作。

    Web Services 是目前的技術中可以用來實現 SOA 的主要介面標準，以下提出幾個應用方向:

    A. EAI(Enterprise Application Integration) 透過資訊化以及 ERP 的導入，把銷售、庫存、生產排程、MRP、採購及財務等企業主要的機能整合成單一系統。SOA 針對 EAI 技術上能提供更標準的做法。實作上可以將 API 封裝成 Web Services 介面來使用 (Peer to Peer)，建構一個 Common Bus 的環境來作為整合平台。

    B. B2Bi(Business to Business integration) 以技術面來說，B2Bi 包含流程管理技術 (Business Process and Modeling)、傳輸與通訊協定技術 (HTTP, SMTP, TCP/IP)、實作技術規格 (Implementation Framework Specification) 與加密技術等。目前 Microsoft BizTalk Server 已經運用 Web Services 技術於 B2Bi 技術領域。簡單來說，B2Bi 整合技術考量的幾個因素與重點是 ：Open Standard、Secure 與 Reliable。至於 Web Services 提供了 B2B 最大的能力是 Visibility & Velocity

    1. Data Visibility: 目前的 B2Bi 在既定的國際標準如 RosettaNet 的規範下，資訊的交換僅能處理既定的格式與資料。然對於變化快速的商業模式，有價資訊的分享便得極為重要。透過 Web Services 來提供 data service 是持續掌握供應鏈優勢的關鍵。

    2. Data Velocity: B2Bi 最關心的議題就是 trading partner 的 data 是否是即時資料。在強調零庫存、價格波動大的產業，資訊的即時性非常重要。以 RosettaNet 來說，資訊的來回只能規範到 24 小時之內。在 Web Services 以 SOAP 協定取用服務的特性下，很容易讓資訊取得即時化。

    C. BPM(Business Process Management) 在強調企業電子化的時代，以 Business Process 的調整與變動的彈性與否已成為影響企業成功的關鍵因素。因此以流程進行整合的 BPM 是企業進行系統整合時的一種工具。傳統應用均以 workflow based 的工具來進行流程管控。即使以 BPM 工具來進行流程管理也免不了有系統整合與資訊處理的議題。Web Services 提供一種新的整合方式，以往 Flow engine 之間沒有標準的串接方式。不論是以 API 直接呼叫或是以資料庫來進行整合。而 BPM 領域目前已經從 in house process improvement 走到跨企業的 business partner process improvement，其中整合的議題更為困難。

    利用 Web Services 技術作為 BPM 底層的協定將能解決跨流程 (企業內跨系統與跨部門或是跨企業間)流程控管的技術問題。透過 Web Services 一方面將企業內系統整合流程化以及商業流程電子化。也同時能將客戶或是廠商的流程結合進企業流程中提高協同運作的程度。而同時也能將自己具有競爭力的流程 expose 出去供企業夥伴使用。(如圖一)利用電子商務形成虛擬企業的境界也將因 Web Services 於 BPM 的應用得以實現。

    圖 1

    在 SOA 架構下，運用 Web Services 來作為主要標準，整個發展與演化將可分成三大階段(如圖二):

    圖 2

    • 第一階段
      簡單型 Web Services (Simple Web Services): 由最基本的 Web Services 功能元件做起，此階段主要以 Web Services 型元件的大量開發為主，透過基本服務如資訊查詢與非交易型服務作為 Web Services 的第一步，簡單但好用的服務元件。最簡單的作法就是將現有元件封裝 (wrapping) 成 Web Services 介面。

    • 第二階段
      1. 組合型 Web Services (Composite Web Services): 衍生性 Web Services 即組合型 Web Services，服務能透過組裝與串流的方式形成更複雜的功能。此時，流程的概念已經引入於系統架構中。

      2. 企業級應用 (Enterprise Web Services): Web Services 在安全、管理與交易機制等技術標準成熟，企業內也將大量使用 Web Services 技術於企業內系統整合、企業內應用系統服務化與企業間的服務。

    • 第三階段
      產業協同 (Collaborative Web Services): 利用更複雜更動態的 Web Servces 來支援 business agility。企業間透過 Web Services 進行即時地、動態地商業協同運作。交易的協商與確認透過即時與自動化處理於整個價值鏈運作上。而協同合作的行為就發生在這個價值鏈的兩兩互動中。

    目前 Microsoft 以Microsoft .NET 平台做為 SOA 主要的開發與執行平台。隨著 WS-* 系列標準的訂定，Web Services 技術也愈趨成熟。Microsoft 在下一代系統 Longhorn 所提供的藍圖中，也將 WS-* 相關技術納入產品中。

    11:11:03 AM | Add a comment | Permalink | Blog it | SOA
    3/28/2005

    客戶真的需要SOA嗎？

    客戶真的需要SOA嗎？

    出處:Taiwna.CNET.com:企業應用:IT技術

    Michael Liebow著．唐慧文譯　　2005/02/22

    2005年才剛開始，服務導向架構(SOA)就已經具有成為年度熱門話題的架式。

    產業界的博學之士已思索各式各樣的問題，並提出種種預測。2005年會是SOA竄紅的年頭嗎？今年會是客戶採用SOA的年頭嗎？SOA會是這一年眾人最津津樂道的名詞嗎？會不會也變成最誇大不實的名詞呢？

    容我再添一項：客戶真的需要SOA嗎？

    所有關於SOA的討論幾乎都集中在彈性、把應用程式拆解成服務、模組化、再利用、可得性提高以及服務的管理上。SOA可切割、執行任何你交辦的任務，而且做得更快、更有效率，成本也比以往用過的其他方法來得低廉。這一切究竟有何意義？這些討論通常都是空論，未觸及企業真正需要因應的實際商業問題或商機。這種情況可能導致SOA陷入只為使用技術而使用技術的危險。上一回這種情況發生時，造成景氣衰頹，現在資訊工業好不容易才走出不景氣、開始復甦。

    有沒有客戶說，他們最擔心的是無法憑應用程式打造服務？這種客戶我倒沒見過。環繞SOA的討論忽略了客戶今天真正需要解決的實際商業問題。電信公司和無線服務提供者擔心顧客流失。製藥公司日以繼夜研發救命的新藥，設法讓藥品快一點上市。醫院希望病歷能夠時時更新，好讓醫師在緊要關頭需要查閱病歷時俯拾即得。

    我們需要展開不同類型的討論。這種討論的重點必須是：解決實際商業問題，對協助客戶轉型到能迅速回應市場環境變遷的隨選（on demand）業務，究竟有多重要。SOA可協助達此目標，憑仗的是提供一個可互通的、可調適的和有彈性的產業標準架構，但最重要的則是與商業緊密相連。幾乎任一種產業標準運用成功的論點，對SOA來說都適用。標準讓企業更容易做生意，而且產生規模效率。

    對SOA可能衍生的利益一無所知的商業領袖，可能在市場上失去競爭優勢，被更靈活、懂得善用這種強大新興技術的競爭對手超越。SOA提供的商業價值極大，分析師預期，短短兩年之後，企業為了取得SOA帶來的利益，將在軟體與服務上投資210億美元。

    SOA被策略性地擺在商業與科技交接處的中心，好讓企業能迅速適應瞬息萬變的環境。SOA讓IT部門跟上商業任務的腳步，作法是從基本的應用程式與IT系統中萃取商業流程，並加以自動化。把商業流程自IT分離出來，會產生極大的商業彈性，讓企業領導者加強控制公司內部的交易，以及公司與商業夥伴、供應商乃至於顧客的交易。

    幾乎每家公司內部的每個商業流程都與科技有關聯。有了SOA，一個組織即可對員工、顧客和商業夥伴提供服務，無須像從前的專屬方案那般投入大量的時間與金錢。因為人人都依循同一套標準，企業就能夠快速反應、彈性應變而且具有競爭力。橫跨整個企業部署SOA，會釋出IT資源，有助於確保科技投資集中在能夠帶動業績成長的核心功能。

    客戶著手建構SOA時，必須根據業務的需求而行。務必發展出一套詳細的計畫，認清公司為支援改良式商業流程所需要發展或加入的服務為何，並訂定優先順序。一家公司——或更明確地說，一個IT部門——不能只是憑空猜測哪些服務可帶來最大的附加價值，必須有一套系統性的作法，始能發展出一份部署服務導向架構的藍圖。

    這種作法有助於確定依商業流程模型訂定的目標得以確實落實，並以有效率的方式產生最大的成效。橫跨整個企業部署SOA，會釋出IT資源，有助於確保科技投資集中在能夠帶動業績成長的核心功能。

    回到我剛開始的問題，我懷疑我今年或未來會碰到任何一個主動要求非SOA不可的客戶。 SOA是一份藍圖，是一種達到目標的手段。客戶需要的是彈性，以便把營收擴大到極至、提供更好的客戶服務、降低成本，並協助符合法令的規定。SOA正是協助他們達到那些目標的一種產業標準。

    (Michael Liebow是IBM Global Services網路服務部副總裁)

    2:08:14 PM | Add a comment | Permalink | Blog it | SOA
    1/13/2005

    服務導向架構(Service Oriented Architecture)應用專欄：

    運用服務導向於企業應用架構設計

    作者：簡西村 (台灣微軟開發工具暨平台推廣處資訊平台策略顧問)

    2005 年 1 月

    由於服務導向 (Service-Oriented, SO) 以服務的思維將所有現有資源 (包含既存應用系統與元件) 以服務型式重新看待，服務之間的溝通以 message 形式來進行交換，以鬆散耦合 (loosely-couple) 的型態解決了以往在跨系統(企業內以及企業間)的分散式系統整合問題。然，這是否宣告物件導向 (Object-Oriented, OO) 時代即將結束而服務導向將取而代之？答案是否定的。在企業面對整合與改變的常態中，OO 以及 SO 將同時扮演中重要的角色。

    Service-Oriented vs. Object-Oriented

    要談 SO 與 OO 這兩個看起來好像沒什麼關聯的東西之異同，要從 OO 談起。說到程式開發，早期大家都是一隻程式寫到底。需要重新使用的 procedure 或是 function 也是洋洋灑灑的嵌在一隻主程式中。透過程式庫把重用性高的程式碼抽離出來變成共用程式庫。方便自己也方便他人。然而，只有同一種程式語言的所編譯而成的程式才能呼叫程式庫。到了 OO 的時代，透過物件化的分析讓可重用的程式變成了元件。元件如何切割與再用有一套方法。元件化的好處是可重用性提高許多，而寫程式已經稍稍可以組裝一些元件來使用。市場上也開始有商業化的元件提供。

    網路的盛起讓商業模式起了很大的變化。企業內利用網路來連結各個應用系統以及交易伙伴間進行線上商業行為變得愈來愈普遍。整合的需求也愈來愈大。以往以 OO 形式存在的系統，一旦面對跨系統的整合問題都得還是面臨許多的限制與包袱，如:

    • 程式語言的選擇 (Programming laguage)
    • 物件分析模型 (Object Modelling)
    • 應用系統平台 (Application Server Platform)
    此時最大的問題在於，大家都想提出一個整合其他系統的方案。然科技創新日新月異，要當最後的整合者讓所有應用系統與平台往單一平台去 converge。是萬萬不可行的。

    透過元件服務化把分散式元件架構上的限制去除，只留下呼叫者與被呼叫者間的使用協定 (agreement) 以及呼叫 / 傳回參數 (message)。元件透過重新封裝後，以單元性服務 (elementary service) 型態存在，透過服務組裝形成更複雜的整合服務，或是更貼近商業流程的商業服務。以服務導向為基礎的系統分析與企業的經營管理分析十分接近，這樣的發展模式可使得發展者更專注於企業需求的滿足，而不僅僅是資訊技術的開發。同時又能不受限於特定廠商的產品功能或是平台，達到真正的開放性。服務導向架構的效果會在所有的資源逐步服務化之後顯現。當可供使用的服務具有一定的量之後，透過服務的重新組裝將使應用系統開發的時間快速縮短，也能隨著需求彈性的調整與改變。整個服務導向架構的導入過程是逐步漸進的方式。同時也能包容既有的 IT 系統。

    整個演進過程如圖一。

    圖 1
    圖 1

    服務的訊息傳輸架構 (Message Process Infrastructure)

    服務間以訊息作為傳輸的準則是服務導向的特色。然此時訊息傳輸已經是透過 Internet，系統之間已經超過了單一企業內的範疇，因此處理的問題也頗為繁瑣。其中包含訊息傳輸的可靠性 (reliability)、訊息傳送的安全性與不可否認性以及訊息的繞送 (routing) 等等。目前實作上普遍使用 Web Services 相關標準與技術做為 SOA 的實作技術。透過 WSA (Web Services Architecture) 提供訊息處理的框架 (如圖二)。

    圖 2
    圖 2

    以 WSA 作為訊息處理機制是目前業界支援 SOA 的主流方向，WSA 包含了底層傳輸層的協定、基礎層以及應用層。傳輸層規範了 HTTP/TCP/UDP/SMTP 等傳輸通訊協定，基礎層處理了 Web Services 跨系統間主要的問題如安全性、可靠性以及交易完整性等，同時包含了訊息格式以及資料格式訂定。應用層處理了流程管理 (如即將成為主流的 BPEL, Business Process Execution Language) 與 Services Management 議題 (以服務導向為基礎的管理也是個有趣的議題，這部份留到下回分解)。

    主要的業界標準 (WS-*) 也透過 WS-I 來做為協商的組織。然而現存的 IT 環境中或許已經存在許多的訊息格式。如 EDI 電子資料交換、各家的 message queue 以及與 ERP 或是其他應用系統整合之格式等。一個設計完善的 SOA 訊息處理機制與架構必須能與現有訊息格式整合。以微軟的伺服器軟體產品來說，以 BizTalk server 為主要支援的產品，除了處理既有系統的整合與流程管理，也同時支援 Web services enablement 以及 BPEL 流程管理標準。

    SOA 企業應用架構

    Microsoft 在 .NET 應用架構中提出支援企業運用 SOA 架構的藍圖 (如圖三)。

    圖 3
    圖 3

    這個架構跟以往多層式 (N-tiers) 架構或是對比於 J2EE blueprint 差異不多。值得一提的是，Microsoft 特別針對 SOA 的部份做了強化。針對每個層次間增加了服務存取介面 (如圖三中：Business Tier 的 Services Interfaces 以及 Data Tier 的 Service Agents)。

    以處理最複雜程序的 Business Tier 之間來看，除了以往與前端介面透過 ASP.NET 來呼叫，也提供 Services Interfaces 讓其他 Service Client 來使用 Business Tier 的 Service。如此一來，對內這個部門或團隊寫好的服務程式就可以讓其他單位來使用。對外可以提供其他企業夥伴來使用。類似案例如 Google 搜尋服務、 Amazon 查詢服務等。以處理商業流程來看 Business Tier，透過服務導向的設計將商業流程直接 build in 成 Service Flow 就很容易由 workflow 來執行與管理相關服務之整合與串流。(如圖四)

    圖 4
    圖 4

    結語

    企業應用 SOA 作為主要架構，最後幾點建議供作參考:

    • 以 layer 的觀點來建構 components，將平台架構上的元件與模組以層次化的設計與架構來思考之。
    • 透過營運共通性的架構來做為一致性的管理與營運標準，共通性的架構包含網路的架構、資訊安全的設計規範以及營運管理準則等。
    • 以業務需求與流程的角度來分析應用系統，同時利用服務的概念來進行實際系統的分析。
    • 以 SOA 架構為中心，儘可能整合與利用現有系統與資源。將現有資產與資源服務化提供服務。

    意見與支援

     您有任何問題、意見或建議嗎？您可以透過下列電子郵件與作者連絡：
     htchien@microsoft.com

    9:11:53 AM | Add a comment | Permalink | Blog it | SOA