OSOA Home

One of the fundamental SCA design principles is that it accommodates diversity, since IT environments are typically composed of a variety of technologies that must work in unison. Another SCA principle is that it is service-based: applications are architected as services that are wired together.

In SCA, components contain application logic that offers one or more services to clients. Components may in turn be clients of services offered by other components. SCA provides mechanisms for wiring components together and assembling them into applications.

SCA supports a diverse range of programming languages and frameworks for implementing components and assembling them into applications, including Java, C++, BPEL, Spring, and PHP. There are also plans to define specifications for EJBs and JAX-WS. To enable this, SCA has created a series of language specifications that define the APIs and metadata used in developing components using particular languages or particular frameworks.

Despite the diversity of supported languages and programming models, SCA applies a set of consistent principles to component development that transcend language differences. These are summarized as follows:

Evolutionary, not revolutionary

It should be possible for businesses to use existing programming models to create components. For example, components can be authored using technologies such as Spring, EJB, and BPEL. In addition, SCA is designed to integrate well with popular presentation- and data-tier technologies. In Java, this includes various web application frameworks such as Struts as well as persistence technologies such as JPA.

Designed for SOA

The SCA language specifications define metadata and APIs for enabling SOA-specific use cases. For example, the language specifications define mechanisms for performing non-blocking service invocations, conversational service interactions, and callbacks.

Reduce complexity

A key goal of the SCA language specifications is simplicity. Using SCA features does not require an understanding of complex APIs and wire protocols. This is done through separation of concerns. Where possible, techniques such as injection are used to provide capabilities to the implementation code without the use of APIs. The injected elements are derived from metadata held in SCA composites.

In addition, Policy and wire protocol definitions, called bindings, are defined using external metadata as opposed to placing this burden within application code. This allows the task of application development to be partitioned across various roles. For example, policies and bindings can be configured by specialists and reused by different applications. This frees application developers from the tedious task of dealing with low-level middleware infrastructure and also greatly reduces the complexity of application code.

Use existing language idioms

Another SCA principle is that it should be "natural" for application developers to use. That is, using SCA features should adhere to the design principles and idioms of whatever language a developer chooses to use, be it C++, PHP, Java, etc. SCA does not provide a language independent programming model. Rather, it provides a language independent model for assembling applications from components written in a variety of languages. Those components may access SCA capabilities, but they do so using APIs and metadata specific to their implementation language.