Network Deployment (Distributed operating systems), v8.0 > Develop and deploying applications > Develop SCA composites

Specify bindings in an SCA environment

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.

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 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 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 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. We 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. We 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 v1.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 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 WAS.

  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.

• 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.

Procedure

1. Select a binding type to use for an SCA component.

   • Use the SCA default binding when 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.

2. 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.

Related

Configure the SCA default binding
Use the SCA default binding to find and locate SCA services
Configure the SCA web services binding
Configure EJB bindings in SCA applications
Use EJB bindings in SCA applications in a cluster environment
Configure the SCA JMS binding
Use Atom bindings in SCA applications
Use HTTP bindings in SCA applications
Develop SCA services from existing WSDL files
Develop SCA services with existing Java code
Develop SCA service clients
Deploy and administering business-level applications
Manage policy sets

Related

Service Component Architecture specifications and APIs

+

Search Tips   |   Advanced Search