Page Operations
Browse Space
The SCA Assembly Model
Service Component Architecture (SCA) provides a programming model for building applications and systems based on a Service Oriented Architecture. It is based on the idea that business function is provided as a series of services, which are assembled together to create solutions that serve a particular business need. These composite applications can contain both new services created specifically for the application and also business function from existing systems and applications, reused as part of the composition. SCA provides a model both for the composition of services and also for the creation of service components, including the reuse of existing application function within SCA compositions.
SCA is a model that aims to encompass a wide range of technologies for service components and for the communication mechanisms which are used to connect them. For components, this includes not only different programming languages, but also frameworks and environments commonly used with those languages. Examples include C++, PHP, BPEL and Java for languages and the Spring, Java EE and JAX-WS technologies with the Java language. For access methods, SCA compositions allow for the use of various communication and service access technologies that are in common use, including, for example, Web services, Messaging systems and Remote Procedure Call (RPC).
The SCA Assembly Model defines the configuration of an SCA system in terms of service components which implement and/or use services and composites which describe the assembly of components into packages of function, including the connections between components and describing how services and references are exposed for use.
Figure 1: An SCA Composite, showing Components, Services, References, Wires and Properties.
What's New?: The Assembly Model
The primary change to the assembly model compared with the 0.9 level of the specification is the introduction of the idea that composites (called modules in 0.9) can be used as component implementations, in the same way as a Java classes or a BPEL processes. With this change, the model allows a hierarchy of composites that is arbitrarily deep - such a nested model is termed recursive.
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" are now collapsed into single concepts. For example, entry points become services and external services became references. With this change, the name module no longer seemed to be an accurate name for the assembly of artifacts that it represents, so the name was changed to composite.
In V0.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 another component). All of these characteristics are now optional characteristics of a composite:
- Deployment. Because some composites are included in other composites, not every composite is necessarily a deployable unit. Only top-level composites are packaged for deployment.
- Locality. Whether all the components within a composite must run 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 offered by a composite may be defined with interfaces that are not remotable (dropping a restriction that existed for module entry points).
- Visibility. When used as a component implementation a composite describes a boundary of visibility between the components within the composite and those that are outside it. However, composites may also be used by being included into another composite, broadly equivalent to the capability offered in the 0.9 specification by module fragments and subsystems. When a composite is included into a higher level composite, there is no visibility boundary, with the intent that the contents of the composite are combined with other elements of the higher level composite into a cohesive whole.
WSDL is somewhat more important in the SCA 1.0 model. 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 be translatable into WSDL, even if, in many cases, the generation of the WSDL never occurs.
The 1.0 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, the definition of conversational interfaces has been moved to the assembly specification.
The 1.0 Assembly model contains a deployment and packaging section that is substantially changed from the in the 0.9 and 0.95 specifications. There is a packaging format based on the ZIP file format, with particular locations defined for SCA metadata. The logical space into which SCA elements are deployed is now termed the Domain and deployment is defined in terms of its effects on the domain. Allowance is made for the deployment of very diverse types of artifact, as is likely in the kind of heterogeneous, distributed environment that SCA describes.
SCA Assembly 1.0 provides a number of facilities that reduce the need to respecify information during composition. Promotion of services and references of components to the composite level and Autowiring of references to services both reduce the amount of metadata to a minimum. There is also the capability for composites to describe wires that are made dynamically at runtime by the component implementations (through the implementation code obtaining an endpoint address for the service it needs to use and giving this to the SCA runtime environment).
Resources
Changes in the SCA specifications since the 0.95 release
Changes in the SCA Assembly specification since the 0.9 release
