Changes to the SCA Specifications since version 0.9

All of the specifications that were published as a 0.9 version (which includes the Assembly Specification, the Client and Implementation Specification for Java and the Client and Implementation Specification for C++ ) have all had significant improvements made to them.  The improvements have increased the generality of the SCA development model, simplified the model, and clarified the semantics.  The collaboration has also developed new specifications that describe the general model for bindings and policies; provide details of specific bindings; and describe out additional implementation technologies can be incorporated into an SCA-based service network.  The new specifications are:

• Client and Implementation Model for BPEL
• Client and Implementation Model for Spring
• Bindings and Policy Framework
• Security Policy Specification
• JMS Binding Specification
• JCA Binding Specification

Brief descriptions of the changes made to the existing specifications and a short summary of each new specification follows.

Assembly

The primary change to the assembly model is the introduction of the idea that modules (as they were called in 0.9) can be used as component implementations, no different from a Java class or a BPEL processes.  With this change, the model became recursive, allowing a hierarchy of modules that is arbitrarily deep.

With this change, a number of other concepts, which had been treated differently depending on whether they were at the "subsystem-level" or the "module-level" could then be collapsed into single concepts.  For example, entry points become services and external services become references.  With this change, the name module no longer seemed to be an accurate name for the assembly of artifacts that it represents, so its name was changed to composite.

In 0.9, modules provided the basic mechanism in three different areas: deployment (what gets deployed together); locality (what is running in the same process); and visibility (which components can be seen by others).  All of these characteristics are now only optional characteristics of a composite:

Deployment.  Because some composites are included in other composites, every composite is not necessarily a deployable unit.  Only "top-level" composites are packaged for deployment.

Locality.  Whether all the components within a composite must be within the same processes is now determined by a new local attribute.  If that attribute is true, the composite may contain components whose interfaces are not remotable.  Also, the services and references of composites may be defined with interfaces that are not remotable (dropping a restriction that existed for module entry points and external services).

Visibility.  When used as the implementation of a component in a higher level composite, composites describe a boundary of visibility between the components within the composite and those that are outside of it.  However, the 0.9 specification had the concepts of module fragments and subsystems, which both allowed components and services to be defined without a visibility boundary, with the intent that they are combined with other fragments into a cohesive whole.  In the updated Assembly specification, both of those concepts have been dropped in favor of the concept of using any composite via inclusion into another composite.

WSDL has become somewhat more important in the SCA model now.  The 0.9 model allowed for services to be described by interfaces written in any interface language, without restrictions.  In the current version, interface languages that are used to represent remotable interfaces must now be translatable into WSDL, even if in most cases, the generation of the WSDL never occurs.

The Assembly model now also includes a definition for conversational interfaces.  This was a capability that was present in the 0.9 specifications, but was buried within the session scope defined by the Java Client and Implementation specification.  Because it is valuable to be able to declare services that maintain a long running conversation between the client and the service provider, whatever the implementation type, the definition of conversational interfaces was moved to the assembly specification.

Java

The changes to the Java Client and Implementation specification have been relatively minor. Most of the changes have been to align the programming model with the introduction of recursive composition (composites) to the assembly specification.  As noted above, the description of session-scoped services was generalized and moved to the assembly specification as conversational services.

C++

The C++ Client and Implementation model added a number of features in support of asynchronous programming, including support for non-blocking calls, callbacks and conversational services.  It also added the use of annotations to declare SCA aspects of a class, similar to the annotations used in the Java model.  Since C++ doesn't have language support, the annotations are inside C++ single line comments (e.g. //@Remotable).  With the annotations the component type side files that are required by the 0.9 spec are no longer required.

BPEL

The BPEL Client and Implementation specification is new.  The main goal of the specification is to describe how any valid BPEL process can be used as the implementation of a component within SCA.  The most important aspect is the description of how to map  BPEL's partner links to SCA services and references.  The specification also defines some optional BPEL extensions that can be used to access SCA concepts that have no equivalent standard BPEL construct, such as deployment-time properties and multi-valued references.

Spring

While the SCA specifications include a specification for Java, that specification is not intended to limit the Java-based technologies that can be used to implement SCA components. SCA now has a draft of a Client and Implementation Specification for Spring.  This specification describes how you can use a Spring application context to define an SCA composite, which can be used as the implementation of coarse-grained components within an SCA system.  In the approach described by the specification, Spring configuration files are used to define the wiring within the composite and SCA-specific elements are added to the Spring configuration file (using Spring's new namespace handlers) to declare the services, properties and references of the SCA composite defined by that Spring application.

Binding and Policy Framework

The new Binding and Policy Framework specification provides mechanisms for specifying policy intents, which are simple enumerated types that allow business-level application developers and assemblers to choose framework-provided capabilities by choosing among a small number of choices, such as choosing the type of authentication to use from choices of (none, basic, cert). The framework then specifies how these intens, combined with the binding that is used for a service or reference, may be used to ultimately find a set of concrete policies that gives the precise definition of that policy for the service.

Security Policy

The first use of the binding and policy framework is the SCA Security Policy specification.  While the policy framework is intended to be a general purpose framework that supports any kind of policy statements, SCA does provide some specific defined policies as part of the proposed standard.  The security policy specification defines a set of default intents to use for message-level security policies, such as integrity, confidentiality, authentication.  These are considered to be interaction policies since they need to be understood by both the client and the service provider. 

Implementation policies only need to be understood by the runtime container of the component to which they are attached.  The security policy specification describes how service components may specify various authorization constraints, such as the roles allowed and the roles referenced by the component.

The Security Policy specification also specifies annotations that may be used with either the Java or C++ programming model for specifying authorization and message protection policies.

Specific Bindings

New specifications have been written that provide a detailed description of bindings for Web Services, for JCA and for JMS, including the XML syntax that should be used to use those bindings.