These SCA specifications support the construction of composite services using many different technologies, including BPEL, XML, Java, C/C++, PHP, as well as offering extensions for platform-specific technologies. The glue that holds all of this together is the SCA Assembly specification. The SCA Assembly model acts as a kind of "global deployment descriptor" that describes all of the artifacts that are used to build a composite service and how they relate to each other.

The key components of the assembly model are:

1.  Composite
A composite is the encapsulating abstraction for the description of a composite service and is described in XML. The rest of the SCA assembly artifacts that we describe are contained in a composite.

2.  Service
The service defines the "entry point" for a composite service. The service consists of an interface that is generally defined as the PortType of a WSDL document. It also includes a binding element that describes the protocols that are used to contact the service. For example, SOAP 1.1 is a common binding used to make composite services network-accessible. Bindings can also contain policies that are enforceable rules that further refine the requirements and capabilities of a service.

3.  Component
A component is a piece of encapsulated business logic that provides some or all of the functionality offered by the service. A component is an abstract, technology-independent description of some concrete functionality that is hosted in the service platform runtime. Components are configured to point to implementations of business logic, which can be implemented with different languages or technologies. For example, a component may be used to configure and load a BPEL process into the service platform. Components implement an interface that can be matched up to a service element to make the component accessible. Typically, a component has one or more references that are connected to other components or external services.

4.  Implementation
The implementation is the actual business logic or declarative XML processing rule that is executed by the platform when a message is dispatched to the component. An example of an implementation is a BPEL process definition or a Java class file.

5.  Reference
A reference refers to services that are outside of a composite. Like a service, it supports a particular interface, protocol binding, and policies.

6.  Wire
Everything described so far is connected together in the SCA Assembly model by wires. A wire is a connection that links together services, components, and references. Wires don't have special semantics: they are used to tell the service platform how to route messages between the network layer and the pieces of business logic that are used to implement the composite service.

The employee provisioning service (discussed above) can be modeled as a composite in SCA. Figure 2 shows a logical representation of the composite. In this case, the composite's service is wired to a component representing the core BPEL process. The partner links in the BPEL process are resolved by wires to human tasks, business rules, and external services. Instead of a combination of different middleware platforms, this example shows a single composite that combines together many building block technologies to build one service.

Finally, while other standards such as WSDL help to define the description of services, SCA also defines how these services interoperate through bindings and policies. In our example, the composite service and reference elements would include bindings that describe the protocols used by the service when it's made available on the network. SOAP is an ideal default binding type to use with SCA, as it maximizes system interoperability and can also easily be optimized under the cover (for instance for intra-JVM communications). Ultimately, this SCA model, coupled with SOAP and WSDL, results in more uniform and interoperable applications.

SOA Runtime Platforms
A composite service designed with SCA needs to be deployed to a SOA platform. It may be helpful to take a look at a platform architecture that can be used to host composite services. Figure 3 shows a representative SOA platform architecture.
Using containers, the platform architecture supports many do main-specific languages for implementing business logic. These languages include process and orchestration capabilities, ESB functions such as service virtualization and message routing, human task management, and business rules. The SCA model provides a standard way to combine these capabilities together and deploy them to the platform. The containers manage the implementation artifacts and execution for each implementation type.

Similarly, SOA platforms will support many protocols for connecting to back-end services and integrating with pre-existing systems. The bindings defined in SCA composites seed the protocol-binding layer to enable interoperability across the data center. The main function of the platform itself is to manage the interactions between all the building blocks that are used to host services. This includes deployment and lifecycle functions, system management, routing of messages between the building blocks based on the wiring in the composite, governance, and metadata management. We expect many platforms that leverage SCA for building composite services to emerge on the market over the next year or so. These platforms will focus on declarative processing of XML messages and domain-specific languages for functions like process orchestration.

Summing It Up
The next generation of SOA applications will combine domain-specific languages and XML processing capabilities, from Java to BPEL, leveraging the wide array of tools and standards available for developing services. The enabling technology for assembling these distinct technologies into composite services is the Service Component Architecture. As Service Oriented Architectures become more ubiquitous in modern data centers, SCA-based SOA platforms will be the de facto standard for building and hosting services. These trends will shape the future of application development, much like J2EE standards helped define enterprise Web development in the 1990s