SCA提供了實現面向服務的架構(SOA)
的一個編程模型。
面向服務的架構已經在軟件開發領域存在很多年了。但是當一些組織試圖去定義最佳的實現和管理
技能的時候，為一個特定組織開發一個SOA的細節卻是難以捉摸的。在這篇文章里，我將介紹SOA的一種實現方式——服務-組件架構。
SOA在概念上來說是關于松耦合的行為。業務和系統功能作為大的獨立服務被展現，使得它們以不同的方式在業務流的組合中被使用。這是一個簡單的描述，但實現起來就相當的復雜了。任何使用EAI和分布式
技術的人都能回憶起在一個企業里兜售業務功能的困難。
SOA原理是抽象的，獨立于實現技術。從開發角度來看，定義SOA構成是有幫助的，它使得工程師可以無須求助于技術規范來用具體術語討論開發實現。為了這個目標，開放面向服務的架構（OSOA）組織發布了服務組件架構（SCA）規范1.1(www.osoa.com)。
SCA已經被IBM，BEA，Sun，Software AG，IONA，SAP，和
Oracle以及其他一些公司開發很多年了。可以在IBM，Rogue Wave，Oracle，Tibco，
Apache Software Foundation（Tuscany）和
Eclipse Foundation（SOA Tools Platform）獲取實現。
SCA編程模型
SCA編程模型主要通過提供一個服務的開發，集合，部署的方法，來關注SOA的工程細節。為了和SOA原理一致，SCA通過元數據驅動，語言獨立和容器
獨立來支持異構的實現。只要一個從SCA規范到技術的映射可以被定義，SCA就能被實現。于是，SCA被和多種語言和容器綁定；最近的一個C語言規范以及
形成草案。
目前，SCA映射已經存在于
Java，C++，
Ruby，
Spring，和BPEL及其他語言中。另外，SCA綁定也在web服務，JMS，JCA和其他通信機制中存在。SCA的目標是減少SOA的概念原理到可以在一個具體上下文中討論的具體元素集合。
SCA的好處有：
·使用組件和組合簡化SOA實現
·使用松耦合的組件和參考來支持敏捷特性
·通過一個綜合的調用模型支持事件驅動的行為
·將開發和集合分開，允許技術不可知的組合
建立服務：程序集(Assembly)模型
程序集模型描述了服務是如何被定義和配置的。
組件是SCA模型的核心，可以用支持SCA的任何語言來實現。一經定義，組件可以使用屬性來聲明配置，這將在接下來的實現中映射到accessor和mutator。
下面的是一個
XML聲明的組件。
//例1：組件聲明
(a)
<component name="AddServiceComponent">
<implementation.java class="calculator.AddServiceImpl"/>
</component>
(b)
<component name="CalculatorServiceComponent">
<implementation.java class="calculator.CalculatorServiceImpl"/>
<reference name="addService">AddServiceComponent</reference>
</component>
引用使得組件可以調用其他服務。引用在部署時或運行時被解析。例1（b）顯示了一個例子引用。
組合是組件的群。根據聲明，一個組合可以被作為一個服務或者新的組件使用。因此，SCA模型支持遞歸程序集。
如果你通過將服務元素包含在組合聲明里，那服務本質就是組合。和組件類似，組合和服務可以通過屬性來聲明配置。就像你可以從SCA程序集的元素聲明里看到的一樣，已有的程序可以通過將應用建模為一個組件，組合或者提供一個可調用的程序接口而添加到架構中來。
布線（Wiring）
組件連接是通過布線來完成的，也就暗示了需要定義組件之間的源/目標信息。和其他SCA元素一樣，布線細節可以被聲明設置。SCA布線不需要元和目標是
一個相同的類型（比如Java到WSDL的接口就是可接受的），只要考慮到了諸如遠端性，回調支持，容錯，和異常處理等的兼容性。例3（a）是一個簡單的
布線實例。
//例2：引用聲明
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="CalculatorComposite">
<service name="CalculatorService">
<interface.java interface="calculator.CalculatorService"/>
<reference>CalculatorServiceComponent</reference>
</service>
<component name="CalculatorServiceComponent">
<implementation.java class="calculator.CalculatorServiceImpl"/>
<reference name="addService">AddServiceComponent</reference>
...
</component>
<component name="AddServiceComponent">
<implementation.java class="calculator.AddServiceImpl"/>
</component>
...
</composite>
//例3：（a）引用中的直接布線（b）和一個web服務綁定的引用
(a)
<reference name="stockQuoteService"
target="StockQuoteMediatorComponent"/>
(b)
<reference name="HelloWorldService">
<interface.java interface="helloworld.HelloWorldService"
callbackInterface="helloworld.HelloWorldCallback"/>
<interface.wsdl xmlns:wsdli="http://www.w3.org/2006/01/wsdl-instance" interface=
"http://helloworld#wsdl.interface(HelloWorld)"
callbackInterface="http://helloworld#wsdl.interface(HelloWorldCallback)"
wsdli:wsdlLocation="http://helloworld wsdl/helloworld.wsdl" />
<binding.ws endpoint=
"http://helloworld#wsdl.endpoint(HelloWorldService/HelloWorldSoapPort)"
location="wsdl/helloworld.wsdl" />
</reference>
為了簡化開發，SCA支持“自動布線”。只要應用是明確的，容器就應該能在運行時布線組件。
Binding
SCA模型通過綁定支持服務之間的通信，這在很多技術中存在了。為了和規范一致，所有的實現必須支持一個SCA服務綁定和Web服務綁定。綁定是被服務
和應用使用的。服務使用綁定來定義它們如何被調用；引用使用它們來聲明它們如何調用一個服務。例3（b）是一個使用web服務綁定的例子。
服務質量：策略框架
為了關注服務質量（
QoS）和非功能化的需求，SCA模型提供了一個策略框架。策略可以用來定義
安全，可用性和交易，以及其他需求。策略可以和每個組件關聯在一起。服務和應用可以擁有多個策略來允許不同方式的訪問。策略框架的主要元素是Intents, Profiles和Policy Sets。
Intents是在一個組件實現上的QoS限制的抽象描述。比如，消息需要是
加密的。一個用“confidentility”命名的Intent可以如例4（a）中被定義。
//例4：（a）Intent聲明；（b）Profile聲明
(a)
<intent name="confidentiality" constrains="sca:binding">
<description>
Communication through this binding must prevent
unauthorized users from reading the messages.
</description>
</intent>
(b)
<sca:profile intents="sec.confidentiality rel.reliability"/>
Profiles是Intent名字的聚合。一個Profile中應用的Intents被映射到Policy Sets中的實現。例4（b）是一個Profile聲明。
Policy Sets和Intents實現相關。它們在程序集模型里聲明技術相關的元素限制。例5是一個和Confidentility Intent相關的Policy Set。這個例子使用了intentMap元素，表明一個給定的Intent的另一種實現。
//例5：使用一個intentMap和WS-PolicyAttachment的Policy Set
<policySet name="SecureMessagingPolicies"
provides="confidentiality"
appliesTo="binding.ws"
xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<intentMap provides="confidentiality"
default="transport">
<qualifier name="transport">
<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wsa:EndpointReference xmlns:myStore="..." >
<wsa:Address>http://myStore.example.com/acct
</wsa:Address>
<wsa:PortType>
myStore:myPortType
</wsa:PortType>
<wsa:ServiceName>
myStore:InventoryService
</wsa:ServiceName>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wsp:PolicyReference
URI="http://myStore.example.com/policies.xml" />
</wsp:PolicyAttachment>
<wsp:PolicyAttachment>
...
</wsp:PolicyAttachment>
</qualifier>
<qualifier name="message">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject for
"message" alternative" -->
...
</wsp:PolicyAttachment>
</qualifier>
</intentMap>
</policySet>
Policy Set包含了一個技術的規范，包括綁定，源，目標的細節。如果被要求使用一個公用密鑰體系，Policy
Set可以包含一些加密方法，信任關系和密鑰存儲的信息。WS-Policy和WS-PolicyAttachment是最好的Plicy
Set聲明的格式。然而，支持其他語言（比如XACML和所有權語言）是可能的，依賴于容器實現。
Intents通過組件元數據連接到組件上。例6給出了一個對服務聲明的對連接認證和可靠性intents。
//例6：連接在服務上的Profile
<sca:service name="mySpecialService">
<sca:interface.wsdl portType="..." />
<sca:profile intents="sec.authentication rel.reliabilty"/>
</sca:service>
在寫此文時，Policy Sets和Intents是包含在一個全局定義文件里的，它被通過Intent或Profile引用到一個程序集描述器文件。
數據訪問：服務數據對象
服務數據對象（SDO）并不是SCA模型合適的部分，但卻是最好的SCA數據架構。SDO基于非連接數據圖的概念。SDO架構保持了數據對象的樹或圖，可
以通過API訪問。這個架構允許強類型和弱類型數據模型，因此支持靜態和動態的數據訪問機制。SDO架構并不對相關的查詢語言進行假設。為了分開程序代碼
和數據訪問代碼，架構鼓勵使用數據訪問服務（DAS）來操作圖
（incubator.apache.org/tuscany/das_index.html）。通過增加元數據，SDO也支持運行時數據圖的查看。既然
架構在理念上已經和XML同時設計，它也提供了豐富的操作XML的機制。事實上，為了實際使用考慮，一個SDO的數據結構最好是XML文檔。在寫此文時，SDO規范是2.1版本。
總結
SCA嘗試基于SOA的概念去創建一個簡單，強壯的編程模型。它的價值存在于概念的簡單，程序集和QoS的聲明式方式。通過集合時間和運行不行和松耦合
策略，SCA無須組件的先驗知識來創建一個服務。這反過來也使得服務組件和結合開發者可以單獨工作。和SDO結合，一個廠商中立的SOA方案是可能的——
模型設計者從早先的模型中看到了其弱點——通過提供一個干凈的程序集和QoS的區分。如果Apache Tuscany
Project是一個SCA生存能力的驗證，那么一個直接（盡管不是必須簡單）的SOA實現是被保證了的。