Imports define interactions between Service Component Architecture (SCA)
modules and
service providers. SCA modules use
imports to permit components to access external services (services
that are outside the SCA module) using
a local representation. Import bindings define the specific way that
an external service is accessed.
If SCA modules do
not need to access external services they are not required to have
imports. Mediation modules usually have one or more imports that are
used to pass messages or requests on to their intended targets.
Interfaces and bindings
An
SCA module import
needs at least one interface, and an
SCA module import
has a single binding.
- Import interfaces are abstract definitions that define a set of
operations using Web Services Description Language (WSDL), an XML
language for describing Web services. An SCA module can have
many import interfaces.
- Import bindings are concrete definitions that specify the physical
mechanism that SCA modules use
to access an external service.
Supported import bindings
WebSphere® ESB supports
the following import bindings:
- Web Service bindings permit components to invoke
Web services. The supported protocols are SOAP/HTTP and SOAP/JMS.
A Web services binding that uses SOAP/JMS, supports JMS using the
default WebSphere Application Server default messaging provider in
a point-to-point configuration. The SOAP/JMS binding does not support:
generic JMS, MQ JMS, or the JMS broadcast mode.
- SCA Bindings connect SCA modules to other SCA modules. SCA
bindings are also referred to as default bindings.
- Java™ Message Service (JMS) 1.1 Bindings permit
interoperability with the WebSphere Application Server
default messaging provider. JMS can exploit various transport types,
including TCP/IP and HTTP or HTTPS. The JMS Message class and its
five subtypes (Text, Bytes, Object, Stream, and Map) are automatically
supported.
- WebSphere MQ JMS bindings permit interoperability
with WebSphere MQ based JMS providers. The JMS
Message class and its five subtypes (Text, Bytes, Object, Stream,
and Map) are automatically supported. If you want to use WebSphere MQ as a JMS provider you might
have WebSphere MQ JMS bindings.
- WebSphere MQ Bindings permit interoperability
with WebSphere MQ. You can use WebSphere MQ
bindings only with remote queue managers via a WebSphere MQ
client connection; you cannot use them with local queue managers.
You might have WebSphere MQ bindings if you want to communicate
with native WebSphere MQ applications.
- Generic JMS bindings permit interoperability with third-party
JMS providers that integrate with the WebSphere Application Server
using the JMS Application Server Facility (ASF).
- WebSphere Adapters bindings permit interaction
with Enterprise Information Systems (EIS).
- HTTP bindings permit you to access applications using the HTTP
protocol.
Dynamic invocation of services
Services
can be invoked through any supported import binding. A service is
normally found at an endpoint specified in the import. This endpoint
is called a static endpoint. It is possible to invoke a different
service by overriding the static endpoint. Dynamic override of static
endpoints lets you invoke a service at another endpoint, through any
supported import binding. Dynamic invocation of services also permits
you to invoke a service, where the supported import binding does not
have a static endpoint.
A specific configuration is used to
control how dynamic invocation of services works. The configuration
can be defined using a model import binding, or at invocation time.
The
invocation target type is identified from the endpoint URL. An sca URL
indicates an SCA module.
An http or a jms URL indicates a
web service. Using http in the URL does not mean
that the endpoint is an HTTP service. Similarly, using jms in
the URL does not mean that the endpoint is a JMS service.