Support for Service Component Architecture (SCA) offers a way to construct applications based on Service-Oriented Architecture (SOA). The support uses the Apache Tuscany open-source technology to provide an implementation of the published SCA specifications.
SCA is defined in a set of open specifications produced by IBM® and other industry leaders through the Open SOA Collaboration (OSOA) and OASIS.
You can use SCA to assemble and compose existing services in your enterprise. The key principle of SOA demonstrated by SCA support is the ability to use your existing services to create new ones.
Another key objective of SCA is to highlight the ease-of-use characteristics of SCA service development in Java. This is accomplished by demonstrating annotated Plain-Old Java-Object (POJO) components deployed using simple JAR packaging schemes, an easy to use assembly model, and wiring abstractions that enable service definition over different transports and protocols.
To learn about SCA in WebSphere® Application Server products, see the following general information:
SCA enables your organization to move quickly into the world of SOA, as follows:
SCA in WebSphere Application Server follows the definition of the technology as documented by OSOA. Defining a set of compliance test suites was not part of the OSOA charter, so the implementation provided in this product uses the following specifications as guiding principles. However, IBM provides an implementation that adheres strictly to our interpretation of the specifications.
See the "Unsupported SCA specifications sections" topic for restrictions and limitations that are unsupported.
The product provides partial support for the following SCA OASIS specifications:
The product supports EJB binding, POJO, JAXB, and SDO as data types.
See the "Unsupported SCA specifications sections" topic for restrictions and limitations that are unsupported.
The OASIS SCA specifications were developed from the OSOA SCA specifications but there are some subtle differences. The following tables list differences between OSOA and OASIS specifications:
Type | OSOA | OASIS |
---|---|---|
Namespace | http://www.oasis-opencsa.org/sca-assembly | http://docs.oasis-open.org/ns/opencsa/sca/200912 |
XSD | Extensibility removes the occasional UPA issue. The sca:extensions element appears in various places. |
|
composite.xml | Reference targets component/service Put unconfigured bindings on the reference. |
Reference targets component/service/binding Do not put unconfigured bindings on the reference. The target string identifies them and the configuration is pulled from the service. |
Asynchronous invocation | Not supported | Asynchronous invocation is supported. Activate it by including the asyncInvocation intent on an interface (or service or reference). |
Conversations | Supported | Not supported |
Operation configuration | Supported in services or references | Not supported in services or references |
Interface | Cannot be marked remotable from within the composite | Can be marked as remotable from within the composite |
Wire format | Bindings can have a wireFormat child element | |
Operation selector | Bindings can have an operationSelector child element | |
Wires | New replace semantics | |
Domain level | References and services are ignored | |
definitions.xml | Has binding element | Does not have binding element |
Type | OSOA | OASIS |
---|---|---|
API | SCA Client API | |
API | Has CallableReferences | Does not have CallableReferences. Has ServiceReference. |
API | New exceptions: InvalidServiceException, NoSuchDomainException, NoSuchServiceException | |
API | Has conversion APIs | Does not have conversion APIs |
Annotations | Has AsyncInvocation. Does not have conversations. |
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" ...>
...
</composite>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" ...>
...
</composite>
For OSOA, an sca-contribution.xml file is not required if there is only one default.composite file in the Java archive (JAR). An sca-contribution.xml file can reside in the META-INF/ directory or in a subdirectory.
For OASIS, an sca-contribution.xml file is required and must reside in the META-INF/ directory, and not in a subdirectory.
As already noted, multiple specifications are defined at OSOA and OASIS, as well as Tuscany extensions provided in open source that go beyond the basic mission of WebSphere Application Server. Each vendor can decide which aspects of SCA apply to their product. For WebSphere Application Server, the focus is on enabling compositions as services, Java components, and integration of key qualities of service-like transactions and security.
SCA can enable mediations, business rules, and business process execution language to be treated as any other service, and while WebSphere Application Server provides the mechanisms to wire services that are implemented in those languages and environments, the product does not provide native support to host those kinds of service implementations.