After you develop an Service Component Architecture (SCA) component, you can use bindings
to specify how SCA services and references enable the component to communicate with other
applications.
Deprecated feature: 
The Service Component Architecture (SCA)
programming model and samples are deprecated, and will be removed in a future release. You cannot
deploy new SCA business-level applications.
Update your applications to use different programming
models. The programming models that you use vary depending on how you previously incorporated SCA in
your application.
If you used SCA for binding, consolidate the ways in which your application
is exposed to a few standards, such as Java API for RESTful Web Services (JAX-RS) or Java Message
Service (JMS). For example, use JAX-RS for application bindings. To minimize the duplication of
binding level implementation, structure your application to use shared code.
If you want to
continue to use SCA as part of your long-term strategy, consider hosting your applications on IBM Business Process Manager.
About this task
Services and references enable a component to communicate with other applications. By design,
however, the SCA services and references say nothing about how this communication occurs. Bindings
are used to determine how a component communicates with the world outside its domain. SCA services
use bindings to describe the access mechanism that clients must use to call the service. SCA
references use bindings to describe the access mechanism that is used to call a service. Depending
on what the SCA component is communicating with, a component might or might not have explicitly
specified bindings.
The product supports the following binding types:
- SCA binding
The SCA binding is also referred to as the default binding. It is the binding that
is used when no other binding is specified for configuration of a component reference or service. It
is the natural binding to use when your SCA client invokes an SCA service in the same
domain.
SCA default bindings are not compatible across implementations by architecture;
however, some interoperability scenarios are enabled between Open SCA and Classic SCA as implemented
in the BPM Suite of products like WebSphere Process Server.
Components communicating within
the same domain only need to explicitly configure a default binding on a service or reference when
there is at least one non-default binding, such as the SCA web services binding or the SCA EJB
binding, that is also configured.
- Web service binding
The SCA web services binding applies to the services and references of
components. The web service binding is designed for SOAP-based Web Services-Interoperability (WS-I)
compliant web services. This binding defines the manner in which a service is made available as a
web service, and in which a reference can invoke or access a web service. The web service binding
enables SCA applications to expose SCA services as web services to external clients that might or
might not be implemented as an SCA component. This binding is a Web Services Description Language
(WSDL)-based binding which means that the web service binding either references an existing WSDL
binding or enables you to specify enough information to generate a WSDL file. When an existing WSDL
binding is not referenced, you can generate a WSDL binding. You can further customize an SCA web
services binding using SCA policy sets.
Web services technology plays an important role in
most SOA solutions relevant today, including SCA. The SCA web service binding type enables SCA
applications to expose services as web services to external clients as well as enabling SCA
components access to external web services. External clients that access SCA services exposed as web
services may or may not be implemented as an SCA component. You can use the web service binding
element <binding.ws> within either a component service or a component
reference definition. When the web service binding is used with a component service, this binding
type enables clients to access a service offered by a particular component as a web service. When
the web service binding is used with a component reference, components in an SCA component can
consume an external web service and access as if it was any other SCA component. Only WSDL Version
1.1 is supported.
- EJB binding
EJB session beans are a common technology used to implement business services. The
ability to integrate SCA with services based on session beans is useful because it preserves the
investment incurred during the creation of those business services, while enabling the enterprise to
embrace the newer SCA technology in incremental steps. The simplest form of integration is to simply
enable SCA components to invoke session beans as SCA services. There is also a need to expose
services such that they are consumable by programmers skilled in the EJB programming model. This
enables existing session bean assets to be enhanced to exploit newly deployed SCA services without
the EJB programmers having to learn a new programming model.
The SCA EJB binding enables SCA
to integrate with existing Java EE applications. It exposes SCA services as stateless session beans
to external clients. The binding element <binding.ejb> is used within a
component service or component reference definition. Support is provided for the EJB binding when
using both 2.x and 3.0 EJB styles for both the SCA service and reference.
- JMS binding
Use the SCA Java™ Message Service (JMS)
binding to compose and assemble SCA services from new and existing services that are available using
the JMS programming interface. By taking advantage of the ability to integrate SCA with existing
services based on JMS, you can preserve your investment in enterprise messaging technology, while
enabling the enterprise to embrace the new SCA technology in incremental steps.
The SCA JMS
binding enables an open, implementation neutral, service-oriented description of the SCA service
assembly and composition. Use the binding element <binding.jms> within a
component service or component reference definition. SCA services using the JMS binding are exposed
using the Java EE Connector Architecture (JCA)-based messaging
provider in WebSphere® Application Server.
The
product supports the default messaging provider or WebSphere MQ as the messaging engine.
- Atom binding
Use the Atom binding to work with services that provide or consume entries
described in the Atom Syndication Format and Atom Publishing Protocol. An SCA component can
reference existing external web feeds defined using the Atom protocol and work with them inside a
Java implementation. Also, you can use the Atom binding to compose new services and expose them as
an Atom feed.
The product supports the Atom binding for OSOA, but not
for OASIS.
- HTTP binding
Use the HTTP binding to expose SCA services for consumption by remote
JavaScript-enabled web browser clients. Using this binding, clients can invoke Remote Procedure
Calls (RPC) to server-side SCA components.
The product supports the HTTP
binding for OSOA, but not for OASIS.
Procedure
- Select a binding type to use for an SCA component.
- Use the SCA default binding when you want to invoke an SCA service from an SCA client.
- Use the SCA web services binding to specify that an SCA service is made available as a web
service or an SCA reference can invoke a web service.
- Use the SCA EJB binding to integrate SCA with services based on session beans.
- Use the SCA JMS binding to compose and assemble SCA services from new and existing
services.
- Use the Atom binding to expose collections of data as an Atom feed or to reference existing
external Atom feeds.
- Use the HTTP binding with a wire format of JSON-RPC to expose services to remote web browser
clients.
- Configure the selected binding and use it in an SCA component or
application.
Results
SCA components can use the configured bindings to communicate with other SCA services and
references.
What to do next
Deploy the SCA component or application.
![[AIX Solaris HP-UX Linux Windows]](../images/ngdist.svg)
![[z/OS]](../images/ngzos.svg)