WebSphere

Connectivity

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.

Introduction

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.

How to enable connectivity for WebSphere ESB and WebSphere Process Server

To enable ESB connectivity you need to perform the following tasks:
  1. Identify, or create, your services.
  2. Create a module that makes use of your services. Use WebSphere® Integration Developer to create a mediation module.
  3. Define resources for the deployment environment. You can use the runtime administrative console (or scripts) to define, or configure, many of your resources.
  4. Deploy your mediation module to the deployment environment. You can export your mediation module from WebSphere Integration Developer as an EAR file, and install the EAR file on the runtime system.

How to enable connectivity at integration development

To enable ESB connectivity, use WebSphere Integration Developer to specify:
  • The services you want to interact with (exports and imports).
  • The format of the data to be exchanged (interfaces).
  • The protocol of the service you want to interact with (bindings).

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.

Protocol transformation

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

How to enable connectivity at run time

There are aspects of connectivity that you have to define outside of the integration environment. At run time, your mediation modules might need access to databases, registries, messaging systems, and enterprise information systems (EIS). You can use the runtime administrative console, or scripts, to define or configure the following resources to the run time.
  • Messaging systems. To configure messaging systems, refer to the links given later in this topic.
  • EIS systems. IBM® adapters allow you to connect to EIS systems. To change EIS configurations at run time, see: SCA EIS bindings.
  • Registries. To define registries to the run time use the administrative console. Click Service integration > WSRR definitions > New. For more information, see: Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere ESB for z/OS. Click this link to go to the topic for WebSphere Process Server. Click this link to go to the topic for WebSphere Process Server for z/OS.
  • Databases. You can connect to databases in various ways. For example, you can connect to a database:
    • As the service endpoint. IBM adapters allow you to connect to EIS systems, including databases.
    • From inside a mediation module. Some mediation primitives are designed to make use of databases. For example:
      • The Database Lookup mediation primitive can change messages using information from a user-supplied database.
      • The Message Logger mediation primitive uses a database for logging, and this mediation primitive can make use of the Common database that is created when you install the runtime product.

Types of service requesters and providers you can connect to

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.

Asynchronous communications, using messaging queues, can have the following SOA advantages:
  • A solution design based on asynchronous messaging can allow communicating partners to be decoupled, helping towards the flexibility goal of SOA.
  • Asynchronous messaging and queueing allow you to set levels of reliability, which can help you move towards the robustness goal of SOA.
You might choose to use a Java™ Message Service (JMS) provider, or IBM WebSphere MQ, depending on what systems you currently have and what systems you might connect to in the future.

Web services

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: Click this link to go to the topic for WebSphere Integration Developer.

At run time, you can specify a new endpoint from the administrative console by modifying the binding. For more information see: Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere ESB for z/OS. Click this link to go to the topic for WebSphere Process Server. Click this link to go to the topic for WebSphere Process Server for z/OS.

Messaging systems

You can connect to external messaging systems using a JMS binding. JMS can exploit various transport types, including TCP/IP and HTTP or HTTPS.

The following JMS bindings are supported:
  • Generic JMS 1.1 compliant providers (third-party JMS providers), using generic JMS bindings. Generic JMS bindings support JMS providers that support the Application Server Facility of the JMS 1.1 specification, but do not support JCA 1.5. Generic JMS 1.1 compliant providers are provided by: Oracle AQ, TIBCO, SonicMQ, WebMethods, BEA WebLogic, and WebSphere MQ.
    • Due to its generic nature, there are no provider-specific connectivity options, and the generic JMS binding has limited capability to generate resources at deployment and installation.
    • You must set up connectivity to and from a third-party JMS provider in order to use the generic JMS binding. For more information, see: Setting up connectivity for the generic JMS binding
  • WebSphere Application Server default messaging provider, compliant with JMS JCA 1.5. If you want to use the WebSphere Application Server default messaging provider you specify JMS bindings.
    • When you generate JMS bindings using WebSphere Integration Developer, you have the option of creating the provider resources when the mediation module is deployed. Alternatively, you can specify the Java Naming and Directory Interface (JNDI) name of the runtime resources your JMS imports and exports must use. Runtime configuration of the JMS binding depends on which option you select at development time.
    • At run time, you can configure JMS import and export bindings to apply special features of the resource, using the administrative console. For more information, see: Configuring JMS bindings
  • WebSphere MQ JMS provider. If you want to connect to WebSphere MQ using its JMS provider you specify WebSphere MQ JMS bindings. The WebSphere MQ JMS binding is designed to interoperate with JMS applications deployed to WebSphere MQ, and to expose messages according to the JMS message model.

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.

WebSphere MQ

You can connect to native WebSphere MQ applications using WebSphere MQ bindings.

When you generate WebSphere MQ bindings using WebSphere Integration Developer, you have the option of creating the provider resources when the mediation module is deployed. Alternatively, you can specify the Java Naming and Directory Interface (JNDI) name of the runtime resources your WebSphere MQ imports and exports must use. Runtime configuration of the WebSphere MQ binding depends on which option you select at development time.
Note: the resources created do not include the queue or the queue manager, which the WebSphere MQ administrator must create if they do not already exist.

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

EIS systems

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.

There are two types of IBM adapters:
  • WebSphere Adapters, also referred to as JCA adapters.
    • WebSphere Adapters are based on Java 2 Platform, Enterprise Edition (J2EE) Connector architecture (JCA), and are the recommended adapters to use with your ESB.
    • If an application is developed with a WebSphere Adapter embedded, the adapter is deployed with the application.
  • WebSphere Business Integration Adapters.
    • WebSphere Business Integration Adapters reside outside of the ESB. The run time communicates with this type of adapter through a Java Message Service (JMS) transport layer.
Both types of adapter can be split into two classes:
  • Technology Adapters
  • Application Adapters

For more information on developing services, using adapters, see: Click this link to go to the topic for WebSphere Integration Developer.

Service Component Architecture (SCA) modules

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: Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere ESB for z/OS. Click this link to go to the topic for WebSphere Process Server. Click this link to go to the topic for WebSphere Process Server for z/OS.


concept Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 20 June 2010 00:38:39 BST (DRAFT)


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wbpm.scenarios.esb1.620.doc/concepts/cwesb_connectivity.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).
iDoc on