WAS v8.5 > WebSphere applications > SCA composites
SCA in WAS: Overview
Support for 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.
We 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.
This topic provides general information about SCA in WebSphere Application Server products:
- Benefits of SCA
- OSOA support
- OASIS support
- Differences between OSOA and OASIS specifications
- Differences between OSOA and OASIS in SCA applications
- WebSphere support for SCA
Benefits of SCA
SCA enables your organization to move quickly into the world of SOA, as follows:
- Improve flexibility in application deployment
-
- Adapt applications quickly to reflect changes in the business environment
- Reuse the components you create in other business processes and composite applications
- Easily compose services into more complex composite applications
- Adjust solutions to accommodate varying technology offerings (that is, protocols or deployment targets) without the need to rebuild business applications
- Increase programmer productivity
-
- Stay focused on solving business problems, rather than getting
bogged down in the individual complexities of the technologies that connect service consumers and service providers
- Use the same fundamental principles to uniformly represent existing assets and newly engineered components
- Organize service components into logical modules to hasten composite application development
- Leverage the loosely coupled service model with clear service definitions to enable developers to work independently and in parallel, for fast delivery of solutions
- Stay focused on solving business problems, rather than getting
bogged down in the individual complexities of the technologies that connect service consumers and service providers
OSOA support
SCA in WAS 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.
- SCA Assembly Model
- SCA EJB Session Bean Binding
- SCA Java Component Implementation
- SCA Java Common Annotations and APIs
- SCA Java EE Integration
- SCA JMS Binding
- SCA Policy Framework
- SCA Spring Implementation
- SCA Transaction Policy
- SCA Web Service Binding
See the "Unsupported SCA specifications sections" topic for restrictions and limitations that are unsupported at this time.
OASIS support
New feature:
v8.5 adds support for the SCA OASIS programming model implementation.
WAS v8.5 provides partial support for the following SCA OASIS specifications:
- OASIS Service Component Architecture / Assembly (SCA-Assembly) 1.1
- OASIS Service Component Architecture / Policy Framework (SCA-Policy)
1.1
WAS v8.5 supports OASIS policy attachment, but does not support OASIS policy set definitions.
- OASIS Service Component Architecture / Bindings (SCA-Bindings)
1.1
WAS v8.5 supports OASIS SCA JMS Binding 1.1 and OASIS SCA Web Service Binding 1.1, but does not support OASIS SCA JCA Binding 1.1.
- OASIS Service Component Architecture / J (SCA-J) 1.1
WAS v8.5 supports EJB binding, POJO, JAXB, and SDO as data types.
See the "Unsupported SCA specifications sections" topic for restrictions and limitations that are unsupported at this time.
Differences between OSOA and OASIS specifications
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.osoa.org/xmlns/sca/1.0 | 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. |
Differences between OSOA and OASIS in SCA applications
- We can distinguish between OSOA and OASIS composites by looking
at the SCA artifact XML namespaces.
In an OSOA composite description, the namespace resembles:
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" ...> ... </composite>
In an OASIS composite description, the namespace resembles:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" ...> ... </composite>
- We cannot mix OSOA and OASIS SCA artifacts, such as .composite files or sca-contribution.xml files, within the same asset. However we can wire OSOA and OASIS SCA components together
when both SCA composites are running in a single cell.
For OSOA, an sca-contribution.xml file is not required if there is only one default.composite file in the 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.
WebSphere support for SCA
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 WAS. Each vendor can decide which aspects of SCA apply to their product. For WAS, 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 WAS provides the mechanisms to wire services implemented in those languages and environments, the product does not provide native support to host those kinds of service implementations.
SCA support includes the following:
- POJO (Plain Old Java Object) service-component implementations, including support for annotations
- Asynchronous capability
- Recursive composition model support
- Support for SCA specifications
- Support for SCA services developed from existing WSDL files or Java code
- Deployment of SCA composites in business-level applications
- SCA authorization and security identity policies
- PassByReference optimization for SCA applications
- Several binding types, including web services binding, SCA default binding, EJB, JMS, Atom, and HTTP bindings
- Support for Java Architecture for XML Binding (JAXB) data bindings in SCA applications
- SCA annotations for Java EE web modules, session beans, and message-driven beans
- Preview of native SCA deployment
- Spring 2.5.5 containers in SCA applications
- OSGi applications as SCA implementations
- Service Data Objects 2.1.1
- Sample SCA composites compiled specifically for use with the product
Related concepts:
Unsupported SCA specification sections
SCA components
SCA composites
SCA contributions
SCA domain
Related
Develop SCA services from existing WSDL files
Develop SCA services with existing Java code
Develop SCA service clients
Specify bindings in an SCA environment
Use JAXB for XML data binding
Use existing Java EE modules and components as SCA implementations
Use Spring 2.5.5 containers in SCA applications
Use SCA authorization and security identity policies
Use PassByReference optimization in SCA applications
Deploy business-level applications
Reference:
API documentation
Related information:
Samples, v8.5 information center