IBM WebSphere SIB & Cloud Computing: Leveraging the Power

Special Report:

IBM WebSphere SIB & Cloud Computing: Leveraging the Power

By Gaurav Tripathi

TheServerSide.com

Power of Messaging by WebSphere SIB & Cloud Computing

High performance, availability and scalability with messaging solutions, and the key to the mix is the WebSphere Application Server (WAS) along with a handy Service Integration Bus (SIB). Here we're going to deliver some hints and best practices, as we show you how to configure for high availability. 

Introduction

Any asynchronous message that reaches the WebSphere Application Server will typically be processed by a Message Driven Beans (MDB). The message bean listens to a particular queue(s) for incoming messages and starts the processing of the messages by invoking the appropriate application component.

Java Messaging (JMS)

Messaging is a medium to connect between applications or application components. It helps in providing a common reliable way to create, send, receive and read messages in any Enterprise distributed environment. It also ensures reliable asynchronous communication, guaranteed message delivery, message security, and delivery notification and transaction control.

Enterprise Java Beans (EJBs), application clients, and web components can send or synchronously receive JMS messages. Also, application clients can receive JMS messages asynchronously. Message-driven bean (MDB) supports the asynchronous consumption of messages.  Messaging systems are classified into two different models that determine which client receives a message:

Publish-Subscribe Messaging:

In this model, multiple applications receive the same messages. The publish-subscribe model supports messages publishing to a particular “Topic”. Multiple Publishers can send messages to a Topic, and all Subscribers to that Topic receive all the messages sent to that Topic. As shown in below figure, this model is useful when multiple applications want to notify each other of a particular occurrence/event.

 

Point-To-Point Messaging:

In this model, one client sends a message directly to another client through the receiver's queue. Only one consumer gets the message in this model.  Below is the figure shows point-to-point messaging system:

WebSphere Application Server and Messaging (SIB)

WAS supports several messaging providers for messaging applications, including its own default messaging provider which SIB and WebSphere MQ. The SIB components which provide the mechanisms associated with the transport of messages. This article will only cover the default messaging provider. The messaging components that are involved when applications use the default messaging provider include, but are not limited to, the following components:

  • Bus member
  • MDB   
  • Messaging engine
  • Message store
  • Destinations

SIB, default messaging provider, can be used as an ESB for the following key reasons:

  • It has a capability to replace dynamically service destination with newly generated endpoints.
  • It has JAX-RPC handlers and can be used for enabling direct application control over both SOAP and non-SOAP messaging.
  • It has a capability to transform protocol between messages. Also WebSphere Application Server supports more than one target service for a single gateway service endpoint.
  • It provides a specific construct for grouping of the resources like mediators, inbound & outbound services, gateway & proxy services.

 

 Below figure shows WebSphere Application Server components including message engine and its integration:

 

  • Each deployed applications are bound to JNDI objects that represent the JMS provider
  • Actual objects of message engine gets bounded with JMS JNDI objects
  • Destinations for point-to-point messaging are message queues
  • Message engine can have its own data source for persistence based messages
  • Message Queues can be individually configured on individual bus members

Architecture & Design Consideration

This section will discuss on cloud computing enabler messaging architecture and design for achieving high performance/availability and scalability of an application. SIB can be easily be used in a non-cluster environment but if you are using in a cluster environment then few things needs to take care like SIB Cluster configuration, type of message i.e. persistence or non-persistence, application scalability etc. Following are the architectural and design consideration, while using SIB, with respect to QoS (Quality-of-Service):

  • Messages Patterns:  Message patterns can be selected based on the requirement of the application like Point-To-Point or Publish-Subscribe Messaging.
  • Message Reliability: The reliability of JMS is summed up in four words - Atomicity, Consistency, Isolation, and Durability (ACID).
    • Atomicity: This refers to the ability of message to guarantee that all tasks within a transaction are performed or none at all. For MDB to be reliable the following tasks need to be performed:
      • Receive message from the queue
      • Print the payload in message
      • Acknowledge that message was received and that all processing was done
    • Consistency: This refers to the property of message being in a legal state when the transaction begins and when it ends. There are two options we can do to revert to a previous consistent state:
      • Re-throw the exception to let the transaction manager
      • Do not acknowledge the message
    • Isolation:  This refers to the ability of the process to make operations in a transaction appear isolated from all other operations. An EJB container allows many instances of a message-driven bean class to be executing concurrently, thus allowing for the concurrent processing of a stream of messages.
    • Durability: This refers to the guarantee that a successful transaction will persist and can not be undone. JMS supports two modes of message delivery:
      • Non-Persistence Mode
      • Persistence Mode
  • Scalability & Availability: Availability and scalability can be achieved by configuring WebSphere Application Server in a cluster environment.  Clustering of WAS can be achieved through WAS ND (Network Deployer).  In WebSphere Application Server ND, clusters can be bus members, in which case message engines can be highly available. So if using SIB in a cloud then configure bus to cluster level instead of server and node level.
  • Security:  Security of messages will be handled in the following manner:
    • Message Queue Security:
      • Restricting unauthorized queue managers sending messages to the main queue manager
      • Preventing queue managers joining a cluster
      • Secure Channel & Cluster

Cloud Enablement:

WAS SIB can easily be scalable depending upon the load of the system especially message load and if any of the application’s MDB takes or consume more resources then it can be deployed in a separate instance or box. Also a separate instance of SIB can be used/deployed in a separate box to cater high message load.

In a Cloud environment like Amazon EC2, which has many of the proven IBM platform technologies including IBM WebSphere Application Server, IBM DB2, IBM Informix, and IBM WebSphere Portal Server etc ., where WAS SIB can efficiently be used in a high performance web sites and cater large message load.  

 

Conclusion

Messaging is a key component to any of the enterprise application. With this in mind, this article showed how the Service Integration Bus can be used as a backbone for enterprise messaging, how WebSphere Application Server supports message bus, how SIB can be scalable to Cloud Environment and messaging architecture and design consideration.

 

Resources

 

About the Author

I'm working with HCL Technologies Ltd as a Solution Architect. My primary consulting focus is architecture of large-scale/complex enterprise applications and assessment of existing enterprise applications. Also involved in architecture governance, mentoring junior architects, instructional materials, technical training. 

Blog: http://visitgaurav.blogspot.com/

Linkedin: http://in.linkedin.com/in/gauravtripathi

 

 

31 Aug 2010