服務組件架構

服務組件架構（Service Component Architecture，簡稱SCA，也譯作服務構件架構， 服務組件體系結構）是新出現的但非常重要的由主要的Java EE技術廠商鼓吹的技術規範，提倡者認為SCA能夠適合發布符合面向服務架構的原則的應用。

支持者

支援的廠商包括：

• 最初的成員 BEA，IBM，IONA Technologies，甲骨文公司，SAP公司，Sybase，Xcalia （頁面存檔備份，存於網際網路檔案館）和Zend Technologies。
• 2006年7月26日宣布加入的成員： Cape Clear，Interface21，普元軟體，Progress Software，Red Hat，Rogue Wave Software，Software AG，昇陽電腦公司和TIBCO軟體公司。

定義

發布的規範 在許多方面看起來都很模糊不清，但是隨著新規範 的演變，SCA迅速地成熟起來（但某些方面仍然存在致命問題）。規範指出使用SCA設計的應用程式應當具有以下特性：

• 將服務的實現和服務的組合與基礎設施能力相分離。
• 應該能與多數語言一起工作包括C++，Java，COBOL和PHP，以及XML，BPEL。 XSLT。
• 需要能夠與不同的訊息構造一起工作， 包括單向，非同步，呼叫-返回，通知。
• 基礎設施能力，例如安全事務，和可靠訊息的使用應該能夠通過編寫元資料應用。
• 資料應以服務資料對象標識。
• 在SCA中定義的組件應該很容易重用。
• 服務的本地呼叫應該更加緊耦合，減少為了在網路上傳輸而建立和解析訊息的開支。

進一步分析

Gartner集團曾發布研究結果，認為SCA以及服務資料對象 (SDO)技術已經成熟將被快速的採用。

優勢：

• 迎合所有現存的Java平台技術和C++（然而SCA的C++組件模型定義存在致命問題）
• 較少的技術依賴性 - 不需要依賴於Java程式設計語言和XML技術
• 使用服務資料對象，服務資料對象是SOA的資料訪問的唯一工業標準。
• 缺少微軟的支援，使得潛在使用者可以在大量提供商之中選擇SOA解決方案。b

劣勢：

• 缺少微軟的支援，這減少了SCA與大量潛在使用者的關係。
• 規範並未解決SOA應用的效能問題，這將持續阻礙SCA被採用。

實現

• Fabric3 （頁面存檔備份，存於網際網路檔案館）
• Rogue Wave HydraSCA
• Covansys的服務組建架構框架
• Apache Tuscany
• Paremus Infiniflow （頁面存檔備份，存於網際網路檔案館）：分散式的，動態的，輕量級的SCA和OSGi執行平台
• Newton開源的分散式SCA和OSGi
• SCA and SDO for PHP
• PocoCapsule SCA組裝容器（C++） 該GPL開源實現基於控制反轉（IoC）及領域特定建模（DSM），並附帶豐富的應用實例（包括SCA著名的BigBank）

參見

• 語意服務導向架構

外部連結

• SCA 0.9版規範 （頁面存檔備份，存於網際網路檔案館）
• SCA 0.96版規範
• Open Service Oriented Architecture .org -- SCA規範相關資訊的官方網站
• Apache SCA規範的開源實現 （頁面存檔備份，存於網際網路檔案館）
• SCA Announcements at OASIS web site （頁面存檔備份，存於網際網路檔案館）
• Service Data Objects initial work by BEA and IBM
• Comparing WCF and SCA （頁面存檔備份，存於網際網路檔案館）
• Summary of SCA （頁面存檔備份，存於網際網路檔案館）
• BPEL in SCA assembly （頁面存檔備份，存於網際網路檔案館）
• PocoCapsule SCA組裝容器（C++） 該GPL開源實現基於控制反轉（IoC）及領域特定建模（DSM），並附豐富的應用實例（包括SCA著名的BigBank）
• Eclipse STP SCA Tools （頁面存檔備份，存於網際網路檔案館）
• SCA被認為是有害的！