A service-oriented architecture (SOA) must enable integration of both new and existing services, and this integration requires connectivity to a range of different systems. This section covers the concept of connectivity in an SOA, and how an enterprise service bus (ESB) enables this concept.
An ESB links together many types of data, applications, protocols and platforms, allowing you to adapt quickly to changes in your business environment and information technology (IT) systems. Having the ability to connect to many types of system promotes reuse: your data and business logic become reusable, and applications are easier to service-enable.
You must provide interfaces to the services you want to use. Generally, service interfaces for the ESB are defined using WSDL portTypes. Having a formal (WSDL) description enables message exchanges to be viewed as service calls. The service requester (consumer) sends a service request to the ESB, and the service provider receives a service request from the ESB. Both the export and the import need an interface definition that describes the structure of the data that is exchanged.
You can use WebSphere Integration Developer to create interfaces, and generate WSDL. For example, to service-enable an application you might use the business object editor to describe the content of the message you want to send, and then use the business object when you create an interface. You could then specify the interface on the export and import, and select the precise binding. The binding specifies both the protocol and the physical format used to send and receive service messages.
After a binding has been configured, protocol transformation is handled by the run time.
If two services have the same interface (as defined by their WSDL) and no mediations are required, you can use WebSphere Integration Developer to wire exports directly to imports. If two services have different interfaces, or you need to mediate the message, a mediation flow component is needed to do the transformations. For more information, see: Protocol conversion
The following is a summary of the types of service requesters and service providers that you can connect to, through the ESB. Some systems naturally enable asynchronous communication, while others fit better with synchronous communications.
You can connect to Web services using a Web service binding.
WebSphere Integration Developer provides two kinds of bindings that are suitable for Web services: Web service bindings and HTTP bindings.
The Web service binding (which can be either SOAP/HTTP or SOAP/JMS) is simpler and follows established standards for remote execution. It is described in a WSDL file, so it works naturally with the WSDL interfaces that are used with most components and exports.
If you want to share
Web service bindings between modules deployed in the same cluster,
you need to share the port. For more information
on creating Web service bindings, see:
At run time, you
can specify a new endpoint from the administrative console by modifying
the binding. For more information see:
You can connect to external messaging systems using a JMS binding. JMS can exploit various transport types, including TCP/IP and HTTP or HTTPS.
If you invoke a mediation module by sending a JMS message to an export with a JMS binding, you can use any part of the message inside the mediation flow component to make mediation decisions, such as routing or transformation.
You can connect to native WebSphere MQ applications using WebSphere MQ bindings.
You can connect to a WebSphere MQ service provider using communications that are one-way or two-way (request-response). For two-way communications, A WebSphere MQ request-reponse application can use various techniques to correlate response messages with requests. For more information, see: Key features of a WebSphere MQ binding
For more information on WebSphere MQ bindings, see: WebSphere MQ bindings
Before you can run an application containing WebSphere MQ bindings, you must ensure that the MQ_INSTALL_ROOT environment variable is set to a supported version of WebSphere MQ.
At run time, you can use the administrative console to tune, or set, special features of the resources. For more information, see: Configuring WebSphere MQ bindings
IBM adapters allow you to create integrated processes that include EIS systems.
Adapters service-enable external applications and data storage facilities by connecting them to the ESB, which powers your SOA. Adapters are sometimes referred to as resource adapters, and provide a standard interface to proprietary systems. Using standard interfaces avoids the maintenance issues associated with non-standard solutions.
For more information on developing
services, using adapters, see:
When you are designing a system, or developing modules, you might want to link SCA modules together. You can do this if you are using the default (SCA) bindings. Mediation modules are types of SCA modules.
If
you want to link two SCA modules, the first module has an import with
an SCA binding, and the second module has an export with an SCA binding.
At run time, you can change which SCA modules are called by changing
the SCA import binding. For more information
on changing SCA import bindings, see: