Service Component Architecture
Service Component Architecture (SCA) is a software technology designed to provide a model for composing applications that follow service-oriented architecture principles. The technology, created by major software vendors, including IBM, Oracle Corporation and TIBCO Software, encompasses a wide range of technologies and as such is specified in independent specifications to maintain programming language and application environment neutrality. Many times it uses an enterprise service bus (ESB).
The original partners announced on November 30, 2005 were: BEA Systems, IBM, IONA Technologies, Oracle Corporation, SAP AG, Sybase, Xcalia and Zend Technologies. Additional members announced on July 26, 2006 were Cape Clear, Interface21, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, Software AG, Sun Microsystems and TIBCO Software. Siemens AG joined the collaboration of companies working on the technology on September 18, 2006.
In addition to the partners, the SCA community had some formal supporters.
On March 21, 2007, the OSOA Collaboration released the first version of specification. The specifications said that an application designed with SCA should have:
- Decoupling of application business logic from the details of its invoked service calls
- Target services in a multitude of languages including C++, Java, COBOL, and PHP as well as XML, BPEL, and XSLT
- The ability to work with various communications constructs including one-way, asynchronous, call-return, and notification
- The ability to "bind" to legacy components or services, accessed normally by technologies such as Web Services, EJB, JMS, JCA, RMI, RPC, CORBA and others
- The ability to declare (outside of business logic) the quality of service requirements, such as security, transactions and the use of reliable messaging
- Data could be represented in Service Data Objects
SCA, therefore, was promoted to offer flexibility for composite applications, flexibly incorporating reusable components in an SOA programming style.
- caters for all existing Java platform technologies and C++
- less technology dependence – does not have to rely on the Java programming language or XML
- Service Data Objects is a technology specification for data access
- Specification does not address performance of SOA applications, which continues to be a detractor of adoption.
- Focusing on portability (instead of interoperability), making it vulnerable to repeating CORBA's mistakes.
SCA was said to provide interoperability through an approach called "Activation". It is the method that provides the highest degree of component autonomy, compared to older "mediation" (e.g., JBI) or "Invocation" method used in JCA, as explained by an architect at SAP.
The SCA Assembly Model consists of a series of artifacts, which are defined by elements contained in XML files. An SCA runtime may have other non-standard representations of the artifacts represented by these XML files, and may allow for the configuration of systems to be modified dynamically. However, the XML files define the portable representation of the SCA artifacts.
The basic artifact is the composite, which is the unit of deployment for SCA and which holds services that can be accessed remotely. A composite contains one or more components, which contain the business function provided by the module. Components offer their function as services, which can either be used by other components within the same module or which can be made available for use outside the module through Entry Points. Components may also depend on services provided by other components — these dependencies are called references. References can either be linked to services provided by other components in the same module, or references can be linked to services provided outside the module, which can be provided by other modules. References to services provided outside the module, including services provided by other modules, are defined by External Services in the module. Also contained in the module are the linkages between references and services, represented by wires.
A component consists of a configured implementation, where an implementation is the piece of program code implementing business functions. The component configures the implementation with specific values for settable properties declared by the implementation. The component can also configure the implementation with wiring of references declared by the implementation to specific target services.
Composites are deployed within an SCA System. An SCA System represents a set of services providing an area of business functionality that is controlled by a single organization. As an example, for the accounts department in a business, the SCA System might cover all financial-related functions, and it might contain a series of modules dealing with specific areas of accounting, with one for customer accounts and another dealing with accounts payable. To help build and configure the SCA System, Composites can be used as component implementations, in the same way as Java classes or BPEL processes. In other words, SCA allows a hierarchy of composites that is arbitrarily deep – such a nested model is termed recursive.
The capture and expression of non-functional requirements, such as security, is an important aspect of service definition, and affects SCA throughout the life-cycle of components and compositions. SCA provides the Policy Framework to support specification of constraints, capabilities and Quality of Service (QoS) expectations, from component design through to concrete deployment.
Transition to a standards body
After several years of incubation under an informal industry collaboration, early (V1.0) implementations of the specification are now coming to market. The collaboration partners indicated that formal industry standardization would be the appropriate next step and announced their intentions in March 2007. The chosen Standards Development Organization is the OASIS organization, and a new OASIS Open CSA Member Section has been established. Charters for six new Technical Committees (TCs) have been submitted to OASIS and a Call for Participation for Technical Committee members has been issued within the OASIS organization. The Technical Committees planned to start their work in September 2007. Participation in these OASIS SCA TCs remains open to all companies, non-profit groups, governments, academic institutions, and individuals. Archives of the work will be accessible to both members and non-members, and OASIS will offer a mechanism for public comment.
- Apache ServiceMix
- Business Process Model and Notation (BPMN)
- Docker (software)
- Enterprise application integration (EAI)
- Mule (software)
- Open ESB
- Reactive programming
- Semantic service-oriented architecture (SSOA)
- Service-oriented modeling
- Windows Communication Foundation (WCF)
- Edwards, Mike. "Service Component Architecture". OASIS. Retrieved 7 April 2011.
- Daniel Sholler, David Mitchell Smith (December 5, 2005). "New SOA Specification Will Fill Niche Among Java Users" (PDF). Gartner Group. Retrieved April 29, 2017.
- Technology srinivas vendors extend collaboration on SOA technologies http://www.hoise.com/primeur/06/articles/monthly/AE-PR-08-06-92.html
- OSOA Technology Supporters http://www.osoa.org/display/Main/Current+OSOA+Supporters+Community
- "Service Component Architecture Specifications". Open SOA Collaboration web site. Archived from the original on October 12, 2007. Retrieved April 29, 2017.
-  SCA & SDO, the next Corba?
-  The rise and fall of CORBA
- "community.user: Comparing SCA, Java EE and JBI | SCN". Sdn.sap.com. 2005-12-12. Retrieved 2013-06-16.
- Bell, Michael (2008). "Service-Oriented Conceptualization". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. p. 3. ISBN 978-0-470-14111-3.
- "OASIS Open CSA Member Section for SCA".
- "Six Technical Committees Proposed for the OASIS Open CSA Member Section".
- "Six OASIS Committees Form to Standardize Service Component Architecture (SCA) for SOA".
- Understanding SCA from experts Jim Marino and Michael Rowley 
- SOA for the Business Developer: Concepts, BPEL, and SCA—ISBN 978-158347-065-7
- Apache Tuscany in Action, ISBN 978-1-933988-89-4
- Open Source SOA, ISBN 1-933988-54-1
Open-source communities tools
There are some independent open source communities implementing SCA:
- Apache Tuscany – Apache Tuscany – The Tuscany reference implementation
- Fabric3 – A Tuscany fork implementation
- CASA SOA with Netbeans plugin and OpenEsb
- Service Conduit
- Anypoint Studio from MuleSoft SCA Free/GPL tool with Visual data mapping
- [http://www.jboss.org/switchyard SwitchYard' – Paid and from JBoss
- Trentino A C++-based SCA runtime designed for embedded systems.
- Current trend about Service Component Architecture on world
- Mail of 2013-02-19 with Death of OASIS SCA Assembly technical committee, on that mail the amazing SCA was died
- Mail of 2015-02-20 with the leader Jim Marino telling about Oracle killing SCA
- NetBeans SOA Composite Application Project Home
- Running Apache Camel in OpenESB
- Introduction to programming for SCA Dr. Dobb's
- [dead link]Current SCA Specifications from the Industry Collaboration
- [dead link]Open Service Oriented Architecture – official site for information about the SCA & SDO technology
- Fabric3 open source SCA runtime
- Apache Tuscany – Open Source implementation of the SCA specification
- SALT - Enterprise ready SCA runtime for C++, Python, Ruby, and PHP
- PocoCapsule for WS and SCA An open source C++ SCA container based on inversion-of-control (IoC) and domain-specific-modeling (DSM)
- Newton open source distributed SCA & OSGi runtime
- A French public research project, which includes a SCA runtime called FraSCati
- SCA Home Page at OASIS web site
- Current SCA Resources & Collateral
- Latest SCA & SDO News
- Introducing SCA – A tutorial by David Chappell, Chappell & Associates
- [dead link]Relationship of SCA and JBI
- Eclipse STP/SCA sub project An Open Source Eclipse project that provides a set of tools for SCA
- Microservice architecture patterns and best practices
- martinfowler microservice architecture site
- Smart endpoints and dumb pipes – martinfowler