支持者
支持的廠商包括：
最初的成員 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的目的是使用戶在構建企業套用時有一個不再直接面對具體的技術細節的層次，而是通過服務組件的方式來構建套用。這種方式也使得客戶的企業套用具有良好的分層架構，能夠很好的分離套用的業務邏輯和IT邏輯，不但易於套用的構建，也易於套用的更改和部署。
定義
發布的規範在許多方面看起來都很模糊不清，但是隨著新規範的演變，SCA迅速地成熟起來（但某些方面仍然存在致命問題）。規範指出使用SCA設計的應用程式應當具有以下特性：
將服務的實現和服務的組合與基礎設施能力相分離。
應該能與多數語言一起工作包括C++，Java，COBOL和PHP，以及XML，BPEL。 XSLT。
需要能夠與不同的訊息構造一起工作， 包括單向，異步，調用-返回，通知。
基礎設施能力，例如安全事務，和可靠訊息的使用應該能夠通過編寫元數據套用。
數據應以服務數據對象標識。
在SCA中定義的組件應該很容易重用。
服務的本地調用應該更加緊耦合，減少為了在網路上傳輸而創建和解析訊息的開支。
進一步分析
Gartner集團曾發布研究結果，認為SCA以及服務數據對象 (SDO)技術已經成熟將被快速的採用。
優勢
迎合所有現存的Java平台技術和C++（然而SCA的C++組件模型定義存在致命問題）
較少的技術依賴性 - 不需要依賴於Java程式設計語言和XML技術
使用服務數據對象，服務數據對象是SOA的數據訪問的唯一工業標準。
缺少微軟的支持，使得潛在用戶可以在大量提供商之中選擇SOA解決方案。
劣勢
缺少微軟的支持，這減少了SCA與大量潛在用戶的關係。
規範並未解決SOA套用的性能問題，這將持續阻礙SCA被採用。
服務組件架構服務
CICS支持兩種類型的SCA應用程式：基於通道的和基於XML的，這兩種應用程式可以通過EXEC CICS INVOKE SERVICE命令調用。
有趣的是，應用程式編程參考手冊（Application Program Reference Manual，APRM）指出，程式設計師應該使用INVOKE SERVICE命令代替INVOKE WEBSERVICE，這似乎是基於XML的服務可能是Web服務的超集或泛化的信號，實際上，APG中談到了使用Web服務綁定Web服務描述語言（Web Service Description Language，WSDL），這意味著在SCA中，當域跨平台時，Web服務淪落到成為常規服務的一個特例。
基於通道的服務非常簡單，SCDL定義了容器或通信區域（COMMAREA）看起來的樣子，組件的實現是目標程式名，調用者使用INVOKE SERVICE命令，指定包括輸入數據，服務URL，以及服務操作的通道，在識別服務後，CICS只需要簡單地連結到程式。
基於XML的服務更多的是扮演我們已經使用過的Web服務，當調用者調用服務時，CICS傳遞信息給請求程式和提供程式管道，如果沒有為服務定義管道，CICS會臨時分配一個，所有信息都順著管道傳遞，普通訊息處理程式像以前那樣控制和處理訊息，最後，CICS調用目標程式執行業務功能。
