• Service components exposing functionality from existing enterprise applications
• Connectors and adapters that make connections possible between disparate systems
• Document handlers and transformers that enable conversion among different document formats (XML or non-XML, industry vertical open standards-based or otherwise, structured or semi-structured, etc.)
• Business process templates, sub-process templates, workflows
• Data and message schemas specifying a common information model (CIM) for enterprise entities, schemas for component/service to component/service interaction messaging
• Business rules, business policies, SLA definitions, UI assets, business event metadata and executables, workflow roles

So a comprehensive gamut of ready-made and configurable items can go into making a composite application. These individual constituents may have been tried and tested individually during development as well as in different business use cases. However, whenever a new composite application is built from these existing components, it has to undergo rigorous testing and validation iterations.

SCA & Composite Applications
Service Component Architecture (SCA) 1.0 is a new standard specification that has been created to address these concerns of building composite applications. It enables a standardized way of specifying, configuring, customizing, and composing the constituents through interconnections. The process of composition is recursive. SCA is an umbrella of specifications, the two fundamental specs being:

• SCA Assembly Model v1 – It defines the building blocks and the composition mechanism. It covers concepts such as domain component, implementation, interface, composite, reference, wire, service, component type, binding, recursive composition, and extensibility aspects of the SCA model, packaging, and deployment. The SCA components and composites are specified in Service Component Definition Language (SCDL) files (XML-based). Components are implementations that have been configured using properties and adhere to a service interface definition that is the only portion of the component exposed to the external world. The service is exposed using different bindings accessed over compatible wires or protocols by service consumers. The components could be composed into composites that could in turn be treated as components hiding internal composition details. The components could be consumers of services from other components through references over compatible wires. These components, composites, and their interconnections are enacted inside an SCA domain that uniquely recognizes these entities and their configurations inside that domain.

• SCA Policy Framework v1 – It defines the building blocks for specifying the non-functional aspects of the components and composites. It covers concepts such as policy, policy sets, intents, mechanisms of attaching the policies and intents to SCA components and composites, roles and responsibilities involved in building composites. In its current version this specification covers two important non-functional aspects – policy specifications of security and reliability aspects. There are two types of policies – implementation (e.g., authorization required when accessing the service implementation) and interaction (e.g., the security and reliability of message delivery during the interaction). Usually these policies are framed as WS-Policy assertions. Intents are abstract policy intentions such as “atLeastOnce,” “authentication,” “integrity,” “confidentiality,” “confidentiality. Message,” “confidentiality. Transport.” Corresponding policies are concrete implementations of intent such as the particular authentication technology like the X.509 certificates that JMS provided at least once delivering the message. The policies can be grouped into policy sets and intents into profile intents.

The components and composites might embody implementations in diverse platforms and yet would still need to be connected to each other to accomplish a complex cross-functional business process in an interoperable manner. Since SCA aims to provide a standard for composition platforms, it has specifications for standardizing component descriptions and connectivity from various implementation platforms. SCA currently covers the component and composite specification for the following platforms:

• Java
• C
• C++
• BPEL
• COBOL

The specifications for the above cover both service consumer- and provider-side implementations (called Client and Implementation). SCA also covers component implementation aspects in detail on Java and the Spring Framework.

To provide interoperable connectivity among components and composites, SCA v1 currently targets some widely adopted bindings (and hence natively supports the corresponding “Binding Types”) such as:

• Web Services
• JMS
• EJB Session Bean
• JCA

The SCA specification at the moment also allows specification of service component interfaces (and hence the corresponding “Interface Types”) in two languages:

• WSDL PortType
• Java interfaces

The concept of component type is fundamental in SCA. SCA can introspect a component implementation and discern its component type (service interface, reference, and other configurable properties) provided the SCA runtime natively supports the corresponding implementation type. In case SCA can’t verify the implementation through introspection, it can use an accompanying component-type file (that has to be provided by the implementation supplier) to discern the “intentions” of the component – services, interfaces, dependencies, and properties.