<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    posts - 14, comments - 1, trackbacks - 0, articles - 0
      BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

    SOA and Web services 新手入門[轉]

    Posted on 2006-09-20 11:39 家有小貓's Java Blog 閱讀(350) 評論(0)  編輯  收藏 所屬分類: SOA

    什么是面向服務的體系結構(SOA)?


    面向服務的體系結構(service-oriented architecture,SOA)是一個組件模型,它將應用程序的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的,它應該獨立于實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行交互。

    這種具有中立的接口定義(沒有強制綁定到特定的實現上)的特征稱為服務之間的松耦合。 松耦合系統的好處有兩點,一點是它的靈活性,另一點是,當組成整個應用程序的每個服務的內部結構和實現逐漸地發生改變時,它能夠繼續存在。而另一方面,緊 耦合意味著應用程序的不同組件之間的接口與其功能和結構是緊密相連的,因而當需要對部分或整個應用程序進行某種形式的更改時,它們就顯得非常脆弱。

    對松耦合的系統的需要來源于業務應用程序需要根據業務的需要變得更加靈活,以適應不斷變化的環境,比如經常改變的政策、業務級別、業務重點、合作伙伴關系、行業地位以及其他與業務有關的因素,這些因素甚至會影響業務的性質。我們稱能夠靈活地適應環境變化的業務為按需(On demand)業務,在按需業務中,一旦需要,就可以對完成或執行任務的方式進行必要的更改。

    雖 然面向服務的體系結構不是一個新鮮事物,但它卻是更傳統的面向對象的模型的替代模型,面向對象的模型是緊耦合的,已經存在二十多年了。雖然基于 SOA 的系統并不排除使用面向對象的設計來構建單個服務,但是其整體設計卻是面向服務的。由于它考慮到了系統內的對象,所以雖然 SOA 是基于對象的,但是作為一個整體,它卻不是面向對象的。不同之處在于接口本身。SOA 系統原型的一個典型例子是通用對象請求代理體系結構(Common Object Request Broker Architecture,CORBA),它已經出現很長時間了,其定義的概念與 SOA 相似。

    然而,現在的 SOA 已經有所不同了,因為它依賴于一些更新的進展,這些進展是以可擴展標記語言(eXtensible Markup Language,XML)為基礎的。通過使用基于 XML 的語言(稱為 Web 服務描述語言(Web Services Definition Language,WSDL))來描述接口,服務已經轉到更動態且更靈活的接口系統中,非以前 CORBA 中的接口描述語言(Interface Definition Language,IDL)可比了。

    Web 服務并不是實現 SOA 的惟一方式。前面剛講的 CORBA 是另一種方式,這樣就有了面向消息的中間件(Message-Oriented Middleware)系統,比如 IBM 的 MQseries。但是為了建立體系結構模型,您所需要的并不只是服務描述。您需要定義整個應用程序如何在服務之間執行其工作流。您尤其需要找到業務的操 作和業務中所使用的軟件的操作之間的轉換點。因此,SOA 應該能夠將業務的商業流程與它們的技術流程聯系起來,并且映射這兩者之間的關系。例如,給供應商付款的操作是商業流程,而更新您的零件數據庫,以包括進新 供應的貨物卻是技術流程。因而,工作流還可以在 SOA 的設計中扮演重要的角色。

    此外,動態業務的工作流不僅可以包括部門之間的操作,甚至還可以包括與不為您控制的外部合作伙伴進行的操作。因此,為了提高效率,您需要定義應該如何得知服務之間的關系的策略,這種策略常常采用服務級協定和操作策略的形式。

    最后,所有這些都必須處于一個信任和可靠的環境之中,以同預期的一樣根據約定的條款來執行流程。因此,安全、信任和可靠的消息傳遞應該在任何 SOA 中都起著重要的作用。

    我可以用面向服務的體系結構做什么?


    對 SOA 的需要來源于需要使業務 IT 系統變得更加靈活,以適應業務中的改變。通過允許強定義的關系和依然靈活的特定實現,IT 系統既可以利用現有系統的功能,又可以準備在以后做一些改變來滿足它們之間交互的需要。

    下 面舉一個具體的例子。一個服裝零售組織擁有 500 家國際連鎖店,它們常常需要更改設計來趕上時尚的潮流。這可能意味著不僅需要更改樣式和顏色,甚至還可能需要更換布料、制造商和可交付的產品。如果零售商 和制造商之間的系統不兼容,那么從一個供應商到另一個供應商的更換可能就是一個非常復雜的軟件流程。通過利用 WSDL 接口在操作方面的靈活性,每個公司都可以將它們的現有系統保持現狀,而僅僅匹配 WSDL 接口并制訂新的服務級協定,這樣就不必完全重構它們的軟件系統了。這是業務的水平改變,也就是說,它們改變的是合作伙伴,而所有的業務操作基本上都保持不變。這里,業務接口可以作少許改變,而內部操作卻不需要改變,之所以這樣做,僅僅是為了能夠與外部合作伙伴一起工作。

    另一種形式是內部改變, 在這種改變中,零售組織現在決定它還將把連鎖零售商店內的一些地方出租給專賣流行衣服的小商店,這可以看作是采用店中店(store-in-store) 的業務模型。這里,雖然公司的大多數業務操作都保持不變,但是它們現在需要新的內部軟件來處理這樣的出租安排。盡管在內部軟件系統可以承受全面的檢修,但 是它們需要在這樣做的同時不會對與現有的供應商系統的交互產生大的影響。在這種情況下,SOA 模型保持原封不動,而內部實現卻發生了變化。雖然可以將新的方面添加到 SOA 模型中來加入新的出租安排的職責,但是正常的零售管理系統繼續如往常一樣。

    為了延續內部改變的觀念,IT 經理可能會發現,軟件的新配置還可以以另外的一種方式加以使用,比如出租粘貼海報的地方以供廣告之用。這里,新的業務提議是通過在新的設計中重用靈活的 SOA 模型得出的。這是來自 SOA 模型的新成果,并且還是一個新的機會,而這樣的新機會在以前可能是不會有的。

    垂 直改變也是可能的,在這種改變中,零售商從銷售他們自己的服裝完全轉變到專門通過店中店模型出租地方。如果垂直改變完全從最底層開始的話,就會帶來 SOA 模型結構的顯著改變,與之一起改變的還可能有新的系統、軟件、流程以及關系。在這種情況下,SOA 模型的好處是它從業務操作和流程的角度考慮問題而不是從應用程序和程序的角度考慮問題,這使得業務管理可以根據業務的操作清楚地確定什么需要添加、修改或 刪除。然后可以將軟件系統構造為適合業務處理的方式,而不是在許多現有的軟件平臺上常常看到的其他方式。

    正如您可以看到的,在這里,改變和 SOA 系統適應改變的能力是最重要的部分。對于開發人員來說,這樣的改變無論是在他們工作的范圍之內還是在他們工作的范圍之外都有可能發生,這取決于是否有改變 需要知道接口是如何定義的以及它們相互之間如何進行交互。與開發人員不同的是,架構師的作用就是引起對 SOA 模型大的改變。這種分工,就是讓開發人員集中精力于創建作為服務定義的功能單元,而讓架構師和建模人員集中精力于如何將這些單元適當地組織在一起,它已經 有十多年的歷史了,通常用統一建模語言(Universal Modeling Language,UML),并且描述成模型驅動的體系結構(Model-Driven Architecture,MDA)。

    構成 SOA 的技術是什么?


    SOA 本身是應該如何將軟件組織在一起的抽象概念。它依賴于用 XML 和 Web 服務實現并以軟件的形式存在的更加具體的觀念和技術。此外,它還需要安全性、策略管理、可靠消息傳遞以及會計系統的支持,從而有效地工作。您還可以通過分 布式事務處理和分布式軟件狀態管理來進一步地改善它。

    SOA 服務和 Web 服務之間的區別在于設計。SOA 概念并沒有確切地定義服務具體如何交互,而僅僅定義了服務如何相互理解以及如何交互。其中的區別也就是定義如何執行流程的戰略與如何執行流程的戰術之間的 區別。而另一方面,Web 服務在需要交互的服務之間如何傳遞消息有具體的指導原則;從戰術上實現 SOA 模型是通過 HTTP 傳遞的 SOAP 消息中最常見的 SOA 模型。因而,從本質上講,Web 是實現 SOA 的具體方式之一。

    盡 管我們覺得 Web 服務是實現 SOA 的最好方式,但是 SOA 并不局限于 Web 服務。其他使用 WSDL 直接實現服務接口并且通過 XML 消息進行通信的協議也可以包括在 SOA 之中。正如在別處指出的,CORBA 和 IBM 的 MQ 系統通過使用能夠處理 WSDL 的新特征也可以參與到 SOA 中來。如果兩個服務需要交換數據,那么它們還會需要使用相同的消息傳遞協議,但是數據接口允許相同的信息交換。

    既為了建立所有這些信息的適當控制,又為了應用安全性、策略、可靠性以及會計方面的要求,在 SOA 體系結構的框架中加入了一個新的軟件對象。這個對象就是企業服務總線(Enterprise Service Bus,ESB), 它使用許多可能的消息傳遞協議來負責適當的控制、流甚至還可能是服務之間所有消息的傳輸。雖然 ESB 并不是絕對必需的,但它卻是在 SOA 中正確管理您的業務流程至關重要的組件。ESB 本身可以是單個引擎,甚至還可以是由許多同級和下級 ESB 組成的分布式系統,這些 ESB 一起工作,以保持 SOA 系統的運行。在概念上,它是從早期比如消息隊列和分布式事務計算這些計算機科學概念所建立的存儲轉發機制發展而來的。

    從 開發人員的角度來說,他們使用的工具必須知道 SOA 的能力,并允許開發人員有效地使用 SOA 對象。這將設計 SOA 模型、開發服務和服務對象以及測試 SOA 應用程序這些過程包括進來并組成一個整體。因而,開發人員的工作必須為面向服務的應用程序設計/開發(Service-Oriented Application Design/Development,SOAD)做好準備。

    SOA 與其他技術的關系如何?


    SOA 可以與許多其他技術結合在一起使用,然而,組件的封裝和聚合在其中扮演著重要的角色。如前所述,SOA 可以是一個簡單對象、復雜對象、對象的集合、包含許多對象的流程、包含其他流程的流程,甚至還可以是輸出單一結果的應用程序的整體集合。在服務之外,它可 以看作是單個實體,但是在其自身中,它可以具有任何級別的復雜性(如果必要的話)。出于性能方面的考慮,大多數 SOA 服務并沒有下降到單一對象的粒度,并且更適合于大中型組件。

    除了可能離不開 XML 和 WSDL 之外,SOA 并不是特定于語言的。可以用任何編程語言來實現服務,只要這種編程語言可以生成服務并且可以與 WSDL 結合在一起使用就可以了。SOAP 本身并不是絕對需要的,但它是通用的消息傳遞系統。因此,可以使用幾乎任何一種編程語言和支持 WSDL 的平臺來實現 SOA 中的成員服務。

    基 于通用對象請求代理體系結構(Common Object Broker Request Architecture,CORBA)的應用程序有許多組件必須連接到 SOA 中。雖然 CORBA 中的接口描述語言(Interface Description Language,IDL)在概念上類似于 WSDL,但它不是嚴格的,因而首先需要將其映射到 WSDL。另外,需要使用更高級的 SOA 協議(比如用于流程和策略管理的協議),而不是 CORBA 中的類似的概念。請記住,這是 CORBA 組件(表示為服務)需要與 SOA 服務交互的情況;在 CORBA 模型中,所有的獨立子集仍然可以像以前一樣工作。

    由對象管理組 (Object Management Group)提出并在許多 IBM Rational 產品中得以實現的模型驅動體系結構在一個更抽象的層次上與 SOA 的概念具有很強的相關性。MDA 基于這樣的概念,任何軟件流程都可以定義為模型甚至是元模型(即模型的模型),然后可以將這些模型和元模型轉換成應用程序的實際組件。因此,MDA 創建了一個模型,這個模型先編譯成軟件應用程序,而軟件應用程序接著又編譯成可執行程序,這樣就可以在平臺上運行了。MDA 并不區分服務和對象這兩個概念,但是它確實允許模型由其他子集模型本身組成,這類似于 BPEL(SOA 的一個核心組件)中的流程聚合的概念。

    SOA 和 Web 服務是獨立于編程語言的,但 Java 是主要的開發語言之一。可以使用定義良好的 Java 接口以及各種協議豐富的 Java 實現為正在構建這個模型的開發人員提供了優勢。Java 在此擔當了開發每個服務的功能、管理數據對象和與其他在邏輯上封裝在服務內的對象進行交互的角色。

    SOA 與 Web 的另一個重要的關系是自主計算和網格計算的概念。自主計算的概念應用于管理分布式服務體系結構的范圍,具體來說,就是幫助維護策略和服務級協議以及 SOA 系統的總穩定性。

    另 外,網格計算可以以兩個級別與 SOA 系統一起使用。網格是分布式計算的一種形式,它利用分布式特性和服務之間的交互來為 SOA 應用程序提供計算支持。在這種情況下,網格起到了框架的作用,其中實現了一些或所有單獨的服務。因此,SOA 應用程序可以是網格服務的消費者。

    在 另一方面,網格本身也可以構建在 SOA 之上。在這種情況下,每個操作系統服務都是構成整個 SOA 應用程序的成員,而 SOA 應用程序就是網格本身。因此,單獨的網格組件既可以使用 Web 服務進行通信,又可以以 SOA 的方式進行交互??偠灾?,網格系統可以是 SOA 本身,也可以提供服務來在其上構建應用程序級 SOA 模型。

    我可以如何構建SOA系統?


    利用 SOA 的好處不僅是一個軟件開發流程,而且還是一個業務開發流程。采用 SOA 有四個層次,您的實現可以跨越從創建特定的軟件服務到將您的業務模型全面轉換到按需系統的過程。要獲得進一步的信息,您應該閱讀這一部分的末尾列出的文章 “The Four levels of SOA Adoption” 。

    第一個層次是最簡單的,因為它只需創建單獨的服務。在這一部分列出的 “SOA 新手入門 ” 中對此進行了詳細解釋,并且提供了更多的資源。

    在第二個層次中,您不僅可以創建服務,而且可以開始將業務功能集成到 SOA 中。這涉及多個層次的集成,其中包括應用程序集成、信息集成、流程集成和整個系統集成。 Migrating to a Service-Oriented Architecture 是一篇重要的文章,介紹了這個層次中的問題。

    第三個層次涉及將您的企業 IT 基礎設施轉換到 SOA 模型,而采用 SOA 的第四個層次集中于轉換您的業務模型,以使之成為按需就緒的模型。

    從 IT 專業人員的角度來看(與業務層相比),要創建 SOA 應用程序,您通常將經歷四個階段:構建、部署、使用和管理。在構建階段中,您可以定義業務模型或流程、軟件模型和 SOA 模型。之后,您就可以創建一組服務,這組服務可以與已發布的通用接口一起重用。

    在部署階段,您提取創建的服務,并把它們放在一個可執行、可管理的環境之中。在使用階段,您根據前面所講的 SOA 和軟件模型來裝配應用程序,并且測試其軟件質量以及非功能性需求,比如性能、可伸縮性等等。應用程序現在已經準備完畢并且可用于用戶。最后的管理階段是一個長期的過程,在這個階段中,您可以監控并管理安全性和使用,以及在許多與您可能已經為 SOA 制訂好的服務級協定或策略相對應的方面比較其性能。

    這些是 SOA 的生命周期的概念階段。為了使對應于這些階段的實際工作角色具體化,有許多角色需要加入到 SOA 應用程序的創建之中。這些角色可能從事相同的工作,也可能跨多個團隊成員甚至多個團隊。在 Rational Unified Process ( RUP )中所劃分的角色非常好地表達了角色概念。

    RUP 角色包括項目經理、分析員、架構師、建模人員、開發人員、測試人員以及部署和操作人員。 SOA 幾乎完全照搬了這種角色劃分方法,惟一不同之處在于, SOA 建模人員角色的工作是提取概念性軟件模型,并且根據 IT 基礎設施的 SOA 模型和資源來對其進行測試。開發人員角色還可以包括二級角色像裝配人員(在使用階段),裝配人員的角色是提取單獨的服務,并且根據定義好的模型構建實際的 SOA 應用程序。不管是顯式的還是隱式的,這些角色都存在于支持 SOA 的企業之中。


    個人體會:

    ??? SOA 的松耦合特性能夠適應業務需求的靈活性,當服務內部結構及實現發生改變時它能夠繼續存在從而降低了軟件二次開發的成本。 SOA 就好比是一個服務中介將不同系統、不同平臺上的操作通過它聯系起來,而實現各種服務和數據的交互,滿足市場快速變化的需求.

    主站蜘蛛池模板: 国产a级特黄的片子视频免费| 亚洲精品专区在线观看| 成人毛片免费观看视频| 四虎永久精品免费观看| 亚洲精品国产日韩| 免费污视频在线观看| 亚洲码国产精品高潮在线| 成全视频高清免费观看电视剧| 国产成人99久久亚洲综合精品| 9久久免费国产精品特黄| 亚洲人成图片小说网站| 国产成人精品免费久久久久| 精品久久久久久久免费人妻| 精品无码专区亚洲| 最近免费中文字幕大全| 亚洲国产aⅴ成人精品无吗| 免费欧洲毛片A级视频无风险| 日韩在线视频播放免费视频完整版| 18禁免费无码无遮挡不卡网站| 亚洲成a人片在线观看日本| 青娱乐在线视频免费观看| 亚洲国产成人五月综合网| 国产精品美女免费视频观看| 国产小视频在线观看免费| 一级特级女人18毛片免费视频| 日本xxwwxxww在线视频免费| 一级毛片免费在线| 亚洲国产精品久久久久婷婷软件| xvideos永久免费入口| 久久伊人久久亚洲综合| 中文字幕乱码一区二区免费| 亚洲一欧洲中文字幕在线| 麻花传媒剧在线mv免费观看| 亚洲午夜无码久久久久软件 | 亚洲av乱码一区二区三区香蕉| 午夜精品在线免费观看| 亚洲日韩精品无码专区加勒比☆ | 亚洲精品无码精品mV在线观看| 免费无码午夜福利片69| 免费看国产一级片| 免费无码中文字幕A级毛片|