Useful Design Practices for Application Development in IIB

One of the key challenges faced by a growing organization looking to leverage their existing systems is to implement a common interface that provides a means of communication for the systems. This gives rise to Enterprise Service Bus layer to connect large number of diverse applications or services, each using different messaging formats and communication protocols.

Almost every organization following SOA (Service Oriented Architecture) design, where services are decoupled and interact with each other irrespective of the service type, needs ESB (Enterprise Service Bus) layer which forms the backbone of any SOA architecture. While there are numerous products offering ESB capabilities, IBM Integration Bus (formerly WebSphere Message Broker) stands out, offering key features such as advanced graphical data mapping, global cache and multiple development languages.

InfoTrellis recently involved in a MDM upgrade project which used IIB to house all ESB related operations such as message transformation and routing between source and MDM applications and vice versa. This article highlights some of the best practices to be followed in IIB consumption for better maintenance and scalability.

Using Shared Libraries:

The concept of static libraries was introduced in WMB V8 to isolate common components that can be shared across multiple applications. However, this had a key limitation, as the library is maintained as a local copy by the referred applications and hence any change in the library requires redeploying all the referred applications. The latest version of IIB v10 has given an enhancement to the libraries where it can be deployed as a standalone on a server.

Shared libraries are useful for the following scenarios:

• Most commonly used services such as Add, Update, Lookup are packaged as separate applications, but they use the same Schema and WSDL definitions, which can be created as a Shared library and referenced by the individual applications.
• Functionalities such as auditing, logging and error handling are common across applications. The resources used for implementing such functionalities such as ESQLs, Java classes and Sub flows can be packaged into a shared library.
• External JAR files such as JDBC/ODBC drivers needed for DB integration.

There are two ways of deploying a Shared Library:

An interesting point to note is that a shared library can in turn refer other shared libraries but a cyclic dependency is not possible

Configuring node properties

The simplest way to specify node properties is within the application/library it is contained in. But in some scenarios the properties might vary for different environments, in which case a separate BAR has to be created for each environment.

There are two approaches to create an environment specific BAR:

1. The Manage tab of the BAR in the Integration Development perspective provides an easy way to locate resources and provide property values for different nodes. The BAR need not built again and only requires to be saved and deployed
2. Alternatively, to facilitate configuring properties without a development environment, an override property file can be created for each environment. In this case, the original BAR file with the source code needs to be rebuilt or overridden to a new BAR file with the help of ANT scripts.

The following are some scenarios where the above two approaches would be helpful:

1. Specifying queue name and queue manager for MQ Input/Output/Reply nodes
2. Specifying file directory for logging/caching in File Input/Output/Read nodes
3. Binding Policy Set and Security profiles for SOAP Request nodes

Setting runtime properties

Applications under a broker could be dependent on external services. In such cases, instead of defining on nodes in a message flow, we might need to define properties on the broker level that could be changed at runtime so that all the applications under the broker can access the properties without the need of a redeploy. One way to define such properties is by creating a user defined configurable service, such as following:

1. Web service URL and authentication parameters can be defined using mqsicreateconfigurableservice command, instead of setting directly on SOAPRequest node. The configurable service values can be retrieved in compute node and set
2. For DB integrations from a compute node, connection URL format and attributes can be set using mqsicreateconfigurableservice command. Authentication parameters can be set using mqsisetdbparms command