OSOA Home

The SCA specifications were initially published at a "0.9" level in November 2005. These specifications were updated and a set of new specifications were added in July 2006, labelled as the "0.95" level. In March 2007, the OSOA collaboration released the SCA specifications at the "1.0" level.

This page describes the changes from the 0.95 release to the 1.0 release as of March 16 2007.

For the changes in the specification from the 0.9 to the 0.95 level, see this page:

Changes in the SCA Assembly specification since the 0.9 release

Changes to the SCA Specifications since version 0.95

The following SCA specifications that were published at the 0.95 level:

• Assembly
• Client and Implementation for Java
• Client and Implementation for C++
• 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

The specifications published at the 1.0 level are:

• Assembly
• Java Common Annotations & APIs
• Java Component Implementation
• C++ Client and Implementation
• BPEL Client and Implementation
• Spring Component Implementation
• Policy Framework
• Web Services Binding
• JMS Binding
• EJB Session Bean Binding

The 0.95 Client and Implementation for Java document is split into two for the 1.0 release:

1. Java Common Annotations & APIs
2. Java Component Implementation 

The 1.0 Policy Framework document contains the material from the 0.95 Security Policy specification.

The JCA Binding Specification will be published at the 1.0 level on a later date. In addition, the SCA team are working on a Java EE Specification and a JAX-WS specification which will be published at the 1.0 level at a later date.

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

Assembly

A number of changes and extensions to the Assembly specification have been made in the 1.0 version:

• A completely new section on deployment and packaging
• Changed the handling of property declarations and property value setting
• Ordering of SCA elements in composite documents is relaxed
• New definition of the way in which referenced artifacts are resolved from composite documents
• Changed the handling of composite services and composite references so that they promote service / reference of a contained component, reducing the amount of information that must be repeated at each level
• Autowire capability added which reduces the amount of wiring information required in a composite
• componentType expanded to contain values as well as definitions
• Additional information for callback interfaces for bidirectional interfaces
• Additional language neutral methods for marking interfaces with SCA metadata, including WSDL extensions
• New <definitions.../> element added
• Multiple default targets can be specified for references with multiplicity >1
• constrainingType added to assist top-down design process
• added dynamic wiring through "wiredByImpl" attribute on references

Java

The Java specifications from the 0.95 level are split into two in the 1.0 release:

1. Java Common Annotations & APIs
2. Java Component Implementation

The Common Annotations and APIs document contains the annotations and the APIs that are intended to be used by other Java-related specifications, including the Spring specification and the (future) JAX-WS and (future) Java EE specifications.

The Java Component Implementation is a specification that defines how to create SCA components based on Java POJO classes. It makes heavy use of the APIs and Annotations defined in the Java Common Annotations & APIs specification.

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.  In addition, a C++ to WSDL mapping is defined, while WSDL to C++ mapping is handled via the definition created by OMG.

BPEL

The BPEL Client and Implementation specification describes 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 provides a Spring Component Implementation specification.  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 namespace handlers) to declare the services, properties and references of the SCA composite defined by that Spring application.

With this specification, there is a happy marriage of using Spring to implement fine-grained and closely coupled Java components and using SCA to handle the exposure and connection of coarse grained services. 

Policy Framework

The Policy Framework specification provides mechanisms for specifying policy intents, which are simple types that allow business-level application developers and assemblers to select framework-provided capabilities by choosing among a small number of high level option.  An example is choosing the type of authentication to use for a service from the choices of (none, basic, cert). The framework then specifies how these intents, 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.  Concrete policies are provided either directly by a particular Binding, or they may be supplied by one or more PolicySets which are intended to be used in conjunction with particular bindings.

Intents and policies are of two kinds:

Interaction policies apply to services and references and the wires which connect them together.  They affect how communication takes place between the service client and the service provider. 

Implementation policies apply to components themselves and are a contract between the component and the runtime container in which the component runs. 

The Policy Framework defines a series of intents and policies for Security.  Security policies include both interaction policies such as the encryption of messages flowing between a reference and a service and also implementation policies such as roles allowed for a component.

The Security Policy specification also specifies annotations that may be used with programming languages including Java and C++ to specifying various security features.

The Policy Framework also defines a series of policies relating to Reliable Messaging. 

Web Services Binding

The Web services binding defines how SCA services and references communicate using Web services protocols.  Principally, this means that the services and references are described by WSDL.  The Web services binding does not presuppose a particular protocol such as SOAP / HTTP, but can support a wide range of protocols that includes SOAP / HTTP, but could include others such as SOAP / JMS, for example.

The Web service binding allows for two broad forms of usage.  One is based on the principle that all the required information is contained in an existing WSDL document, so that all that is required is a reference to the appropriate WSDL document.  The second form is based on the idea that the interface for the reference or service is defined (either by a Java interface, WSDL interface, or some other interface definition language) and that it is rendered into a WSDL document containing binding and port type definitions, based on simple sets of parameters applied to the Web service binding element in SCA, including the use of intents and policySets to specify infrastructure capabilities.

JMS Binding

The JMS binding defines how SCA services and references communicate using the JMS messaging API.  This allows the use of messaging infrastructure that supports the JMS API.

The JMS Binding provides the capability to specify JMS parameters in detail, which is most useful when an SCA service or reference is dealing with messages that flow to or from messaging applications that are not within the SCA domain. This includes the capability to map messages to specific service operations and to map the message formats into specific data formats used by those operations.

EJB Session Bean Binding

The EJB Session Bean binding provides the means to access Java EE Session EJBs from SCA components and also the means to expose an SCA service as if it were an EJB Session Bean.

The principal use of this binding is in environments where Java EE applications are in use and where it is necessary to access their function from new contexts, or where the function of the Java EE applications needs to be extended by having those applications call new components written using some different technology.