Monday, May 4, 2009

Messaging: JMS vs SCA

Ivan Smirnov, Senior Consultant

In SCA, bindings are the means of transporting data (messages) to and from modules. One specific application I’d like to discuss is messages between SCA modules: that is, when one SCA module calls another SCA module. There are several types of bindings that can be used in that scenario. The easiest is, I kid you not, the SCA binding. At runtime, it becomes an EJB call. SCA binding was designed specifically for inter-module calls and it is so good at this, it makes you wonder: why use any other binding type at all? Well, if you need more flexibility, JMS binding may be handy.

SCA binding is best suited for simple synchronous calls between modules. It is possible to use SCA binding for an asynchronous invocation, but it will be implemented on auto-generated JMS queues on a SCA SYSTEM bus. With little control over queues, this option does not provide all the benefits of JMS binding.

Advantages of SCA bindings over JMS bindings:
  • They do not require any external configuration and thus are maintenance-free.
  • Interfaces are early bound. Interface types are checked when binding is established, and the Export interface must match the Import interface. This eliminates a possibility of errors not discovered until runtime.

Advantages of JMS bindings compared to SCA:
  • More flexibility: target module can be relocated (even to a different cell).
  • You don’t have to use the same interface on both sides of binding. Even method names may be different on caller (module Import) and target (module Export), so long as payload type is correct.
  • There is an easily accessible checkpoint between modules(a JMS destination) where messages may be inspected for troubleshooting/debugging purposes.

In addition to this theoretical analysis, let me share my experience. I experimented with inserting JMS binding between modules where SCA was a natural fit, just for error handling purposes. My idea was that it would be much easier to control message flow and retry logic if there was a JMS queue between modules that I could configure to my liking. As intriguing as it sounds, there was too little real benefit in that specific ESB solution. So my conclusion was that error handling is not sufficient justification for using JMS binding where SCA binding is a more natural fit.

Ivan Smirnov is a Senior Consultant at Prolifics with extensive hands-on experience with the WebSphere family of products (including WebSphere Application Server and Process Server, WebSphere Studio/Rational and WebSphere MQ), Tivoli security offerings (including Tivoli Identity Manager and Tivoli Access Manager for e-business), DB2, XML and Web Services. With strong technical skills both in development and administration, as well as deep troubleshooting skills, Ivan handles aspects of implementation installation, configuration, securing and tuning/troubleshooting to development and architecture within a J2EE environment. He also possesses key Application Server migration skills and has helped several customers’ transition to the WebSphere platform from other J2EE platforms.