科技街的IT行業會因為市場的透明化和大眾化而走向徹底的低谷嗎？

目前，最先進的IT行業趨勢，第壹是面向服務的架構(SOA)，第二是開源軟件。結合SOA和開源軟件的優勢，既能降低客戶的IT成本，又能靈活應對不斷變化的業務需求。在現有的軟件開發項目中，壹直存在壹個無法解決的問題:對業務功能和技術功能的理解是同壹個人的責任，即同壹個人或多人可以完成業務和技術領域的銜接。在實際環境中不容易找到這樣的人，而沒有這個人，軟件開發項目基本上離失敗不遠了，這是IT領域的老問題，也是面向服務架構(SOA)要解決的主要問題之壹。SOA限制了IT部門考慮組織和能力的最佳組合，從而獲得Web服務、SOA和BPM技術的所有優勢。就像壹個汽車公司，不壹定有能力發明制造輪胎、發動機、音響等成套汽車零部件。其音響可能從A公司批量采購，剎車系統可能由b公司提供，汽車公司利用其他零部件供應商的服務為最終的汽車用戶服務。SOA架構也是如此。技術人員必須能夠適應從做全部工作到做部分工作的過渡，與他人壹起完成整個工作。與對象或流程相比，服務的開發應該面向更廣闊的環境，因為它有更大的機會被重用。事實上，定義可重用服務可能是SOA最重要的方面，也是SOA現在如此受歡迎的重要原因。為了響應客戶的需求，IBM、BEA、Oracle、SAP和Primeton等公司正在合作制定構建SOA系統的規範，為開發人員提供壹種更簡單、更強大的方法來構建基於SOA的應用程序。目前，由這些公司組成的OSOA(Open Service Oriented Architecture)負責制定規範。此外，OSOA還負責在Apache中推出開源SCA/SDO實現，以加速市場的發展。目前，SOOA正在起草壹系列規範，以避免向該行業提供專利費。o SOA的兩大項目SDO(Service Data Objects()和SCA(Service Component Architecture)為SOA架構做出了巨大貢獻，猶如OSOA的兩輛馬車。根據我掌握的最新信息，OSOA正準備啟動第三輛馬車:DAS(服務數據對象)。1.早在2005年6月165438+10月，OSOA發布了SCA 0.9規範草案。SCA是壹種全新的編程模型，與語言無關。這種面向服務的組件編程模型可以大大簡化客戶的編程，提高應用的靈活性，並將對現有的軟件開發方式產生顛覆性的影響。2.SDO SDO致力於提供壹種統壹的方法來處理應用系統中的數據，而不考慮數據的來源和格式。SCA和SDO都可以獨立使用，並且沒有規定這兩種技術必須在同壹個應用程序中使用。然而，SCA和SDO可以壹起使用，這為構建具有面向服務架構的應用系統提供了壹種強大而靈活的方式。3.DAS DAS與SDO密切相關。DAS為數據庫和服務提供了統壹的數據處理方法，同時也提供了相應的機制來實現數據從源頭分離時的處理。DAS旨在簡化和統壹應用程序處理數據的方式。通過使用DAS，應用程序員可以以統壹的方式訪問和操作來自異構數據源的數據，包括關系數據庫、XML數據源、Web服務和企業信息系統。開源SOA作為壹個新生事物，很少有開源的實現。據我在業內了解的情況，* * *目前有四個開源的SOA項目，他們就像戰場上的將軍壹樣，為SOA陣營攻城略地，開拓了不少地盤。1.通用托斯卡納托斯卡納是Apache軟件基金會的孵化項目，由IBM和BEA主導，在Apache軟件基金會中扮演著重要的角色。托斯卡納原是意大利行政區的名稱，中文壹般譯為托斯卡納，被借用為這裏的項目名稱。Tuscany的主要目標是為用戶提供壹套SOA基礎設施，包括用Java和C++實現的SCA/SDO/DAS標準。2.STP STP(SOA工具平臺)是Eclipse Foundation的壹個重要項目。STP的目標是為技術人員提供壹個靈活的、可擴展的框架，技術人員可以在這個框架的基礎上方便地設計、配置、組裝、部署、監控和管理SOA。STP提供工具支持開發者使用面向服務的架構來構建解決方案，而面向服務的架構以服務組件架構為核心模型。3.庫SOA PHP PECL (PHP擴展社區庫)在PHP社區中是眾所周知的，但是很少有人知道PECL庫中包含的新SOA PHP項目。SOA PHP項目的主要目標是用PHP實現SOA中的SCA/SDO標準，這對於PHP社區的同誌們來說真是壹大福音。4.Newton是壹個分布式運行時框架，用於企業級環境中復雜SOA系統的動態實例化和可持續管理。牛頓使用SCA系統描述來動態部署OSGi的組件，從而實現對分布式異構數據源的監控和管理。Tuscany開源架構分析從上面可以看出，世界上兩大開源軟件基金會(Apache Software Foundation和Eclipse Foundation)以及其他不同的社區已經開始了SOA開源軟件的研發進程。下面將主要討論Tuscany開源項目架構及其在SOA標準化過程中的影響。1的問題域。Tuscany是軟件產品解決方案的主要目標。BEA Systems的CTO辦公室的Jim Marino告訴我們，Tuscany的問題域可以用壹句話來概括，就是解決如何構造和組裝服務的問題。服務是代表業務功能的代碼單元，可以由客戶端在本地或遠程定位和構建。服務可以部署在不同的運行環境中，如J2EE服務器、J2SE客戶端、Servlet容器和OSGi容器。服務可以用不同的編程語言編寫，然後在異構環境中組裝。這裏的服務與Web Service中的服務有很大的不同。Web Service中的服務使用底層協議來約束系統之間的互操作性，而Tuscany中的服務將Web Service中的服務與高層業務組合屏蔽開來。Tuscany可以在Web服務中使用該技術，但並不局限於此。應該說Tuscany封裝了WS-*和RMI等服務調用的細節。壹句話總結，Web Service描述了服務之間的協議，但沒有描述服務之間的關系，這是Tuscany的主要任務之壹。2.Tuscany的服務網絡架構以上面確定的問題域為中心，Tuscany為我們解決了很多現有的技術架構問題。在現有的技術框架下，我們在平常的開發中總會遇到以下問題:◆大型軟件系統的開發和配置的復雜性。缺乏動態性，比如目標功能服務點的動態切換，壹直是軟件行業的核心問題。◆異構環境下的模塊功能不可復制。◆很難建立壹個可以平滑規模化用戶的系統。例如，在1999中，Ebay網絡在用戶數量急劇增加的情況下宕機20小時，導致股價下跌9%，損失慘重。在這種情況下，Tuscany被設計為基於SOA的服務網絡架構。SCA用來組裝壹個服務網絡，SDO表達服務網絡中流動的數據，DAS以統壹的格式存儲這些流動的數據。Tuscany的異構服務網絡架構如圖1所示。從圖中可以看出，在服務網絡中，業務邏輯包含在組件中。組件向外界提供服務。壹個組件可以引用並依賴於其他組件提供的服務。組件之間的引用或依賴可以通過某些策略來表達，例如事務策略和可靠性策略。托斯卡納的服務網絡就像滿清宴，而服務網絡中的組件就像滿清宴中的108道菜。我們自己很難做出壹道美味的菜，而如果不同的廚師掌握了不同菜品的技巧，我們可以自己從108菜品中選擇自己喜歡的菜品。在SOA的軟件開發環境中，很明顯“壹個廚師決定消費者口味”的時代即將結束。Tuscany服務網絡中的組件可大可小，服務可以是本地的也可以是遠程的。對於Java，服務實現可以在單個JVM中，也可以在多個JVM中。還有很重要的壹點是，組件是自包含的，也可以包含其他組件，甚至這個組件。事實上，服務網絡本身被視為壹個組件。3.Tuscany的業務調用流程在上述架構下，Tuscany的服務可以用各種語言實現，分布在各種環境中。其業務調用流程如下。我們撥打114進行對比分析:◆客戶發起呼叫托斯卡納服務。就像我們撥“百事通”，用的是中國電信的統壹服務。◆Tuscany的綁定功能模塊負責將調用分配給不同的傳輸功能實現。比如“百事通”的代理或後臺程序會根據妳的選擇把妳想問的問題轉發到不同的業務後端。◆相應的傳輸函數實現調用的傳輸，傳輸方式可以是SOAP/HTTP、JMS、RMI或AMQP。比如“百事通”和“攜程網”的溝通模式和與“螞蟻搬家”的溝通模式可能就不壹樣。◆Tuscany綁定功能服務模塊接收調用請求，轉發給相應的目標服務。收到請求後，“攜程。將顧客想要預訂的酒店轉發給不同的酒店集團。◆目標服務執行服務功能。不同酒店集團確認是否有空房等。好像和Web Service區別不大。但是需要註意的是，這裏的第五步不需要判斷是否需要返回信息。是否需要返回信息是托斯卡納已經確定並實現了不同的服務功能。4.Tuscany的內核分析Tuscany采用了微內核和擴展插件的結構。它的項目本身和所有依賴的項目只有4M代碼，它的可擴展插件都是獨立的SCA組件。事實上，bootstrap在其內核中是由壹系列組件組成的。Tuscany提供了壹個具有自動配置功能的非侵入式編程模型，這些配置都有默認值。正如軟件集團總裁周強所說，托斯卡納就像《射雕英雄傳》中的周壹樣，學會了“左右手互搏”的武功，其內核和插件在功能上相互競爭，彌補對方的不足恰到好處。Tuscany的內核控制在30K行代碼以內。它提供了擴展點來提供函數，這些函數是在運行時動態添加的。Tuscany允許多種技術選擇，例如，它不限制您可以實現什麽Web服務。Tuscany的內核組成如圖2所示。從圖中可以看出，Tuscany主要由五部分組成:◆壹個Ioc(反轉控制)單JVM編織引擎；◆組件狀態管理容器；◆戰略部署框架；◆數據訪問服務；◆依賴關系管理和SPI管理容器。5.托斯卡納與其他項目的異同從上面的內核分析可以看出，托斯卡納與我們通常所知的項目完全不同。Tuscany是基於SCA實現的，它通過組裝來表達自己的服務網絡架構概念。它可以使用Java、C++、BPEL等各種語言來構造組件，並可以與現有的編程模型集成。它還提供了壹個表達服務關聯的策略模型。托斯卡納可以部署在J2EE服務器上，J2EE的很多技術也可以使用。托斯卡納的組件也可以由J2EE的EJB或JAX-WS實現。然而，托斯卡納提供的功能不同於J2EE提供的功能。Tuscany可以用多種語言實現，包括C++、BPEL和PHP。與J2EE相比，托斯卡納更好地抽象了業務子系統之間的通信。在J2EE，有必要確定系統在哪裏需要Web服務或EJB。但是Tuscany允許您稍後決定這是Web服務還是POJO。Tuscany中的服務也可以是輕量級的實現。托斯卡納的做法也不同於JBI(Java業務集成)。對於中間件供應商，JBI在NMR(標準化消息路由器)的基礎上標準化了SPI(服務器提供商接口)。托斯卡納沒有NMR的概念，而是采用點對點的編織模式，充當“服務交換機”。像SPI壹樣，Tuscany也有擴展模型，但它主要是為服務開發人員和服務組裝人員設置的。托斯卡納現在已經成為SOA的試金石。在OSOA等開放組織的領導下，它會為我們找到更多的金礦。我相信隨著OSOA的不斷發展，像托斯卡納這樣的開源SOA產品將會取得更加輝煌的成功。