Solving integration issues when building a service-oriented architecture Patrick Flanders interviews Shahryar Sedghi | 28 Oct 2005 WebSphere Technical Podcast series on developerWorks http://www.ibm.com/developerworks/podcast/websphere/ Pat: Hi, and welcome to the WebSphere Technical Podcast series on developerWorks. This is the third in our series of interviews with IBM technical experts, who we hope can help you solve important software development issues. I'm your host, Patrick Flanders. I'm an editor with developerWorks, and today we're going to discuss how to solve integration issues when building a service-oriented architecture. If you've built software in MQ Series and/or are using Java Messaging Service, we'll look at how you integrate them with the IBM WebSphere Process Server 6.0. To dive into this, we're fortunate to have with us Shahryar Sedghi who is a business integration architect on the IBM Software Group Application and Integration Middleware team that develops WebSphere Process Server, in addition to other technologies. Together, we'll look at integrating JMS MQ-based applications with WebSphere Process Server 6.0 using JMS import and export. Shahryar, thanks for joining us. How are you today? Shahryar: Thanks for asking. Good, and thank you for the time for the interview. Pat: Absolutely. Well it's good to have you here. And first off, let's get a little bit of context. Can you briefly describe the role that WebSphere Process Server plays in implementing an SOA, and also maybe say a few words about what's new with version 6? Shahryar: WebSphere Process Server is a component-based service-oriented architecture integration platform. It means that, in WebSphere Process Server, we can create components and expose them as a service. We can also take some other components out of WebSphere Process Server and expose them as a WebSphere Process Server component. We also can create a process that does a choreography between all of these components and expose them as a service. WebSphere Process Server version 6 comes with a robust process engine based on BPEL version 2. It comes also with a rules engine that addresses 80% of the requirements of anybody who wants to have a rules engine, without buying an external rules engine. It also has a human task manager for human decisions that normally we do during a process. It also has some interface and data mapping features that provide some of the functionality that the WebSphere Interchange Server, in the past, would provide. Pat: Are there other technologies and terminology that we should define before getting into the meat of the discussion? Shahryar: WebSphere Process Server is built on two components. One is SCA, that's service component architecture. And the other one is SDO, that's service data objects. Service component architecture is a programming model that simplifies the process of developing composite business applications. What I talked about -- components -- it's provided to us using SCA. SCA simplifies the J2EE programming model and provides some level of component abstraction. Service data objects is the technology that WebSphere Process Server business object is built on. So with service data objects, we can create business objects in a uniform way, and we can send this business object between various components. Service data objects are leveraging XML and XML Schema to define the business object. Pat: Shahryar, another general question: Why focus on JMS MQ applications in WebSphere Process Server? Shahryar: MQ is becoming the de facto standard of the passport between heterogeneous applications during the 90's and 2000. JMS is an API on top of MQ and also, recently we have some other JMS providers that are interacting with MQ. They are not using the MQ engine, but they have a way of interacting with MQ. With supporting JMS, we open WebSphere Process Server to many different applications and components that are utilizing JMS. I can give you an example on this one. One of them is WebSphere Partner Gateway, that is our B2B engine. The other one is WebSphere Message Broker that opens WebSphere Process Server to many enterprise applications with various data formats. Almost all of our third party and competitors are using JMS and MQ to talk to any components inside IBM and to the applications. So if we support JMS inside WebSphere Process Server, we can interact with almost every software in the world. Pat: Let's get into some details. Tell me more about JMS import and export, how they work, and what they help the developer accomplish. Shahryar: JMS import and export are a specialization of EIS import and export. EIS import and export are components that actually sit between WebSphere Process Server and the outside world. The way they work, they make components inside WebSphere Process Server as an entity similar to what the enterprise service talks to normally, and also they make enterprise services like SCA components that we can interact with. JMS import and export are providing this service for JMS- and MQ-enabled services. So if we have an MQ-enabled service, we can have a JMS import and put JMS imports between an SCA component and a JMS service the way that service looks like an SCA component to us. On the other hand, we can put JMS export and make an SCA component like a normal JMS application that a JMS application typically deals with. Pat: What JMS import and export patterns are available to the developer? Shahryar: For JMS, export patterns are simple. JMS export makes an SCA component inside WebSphere Process Server like another JMS application. So we send a message to it -- this is a one-way -- and we might not expect a reply, or we send a message to it and we expect a reply back in another queue. JMS import is more complex than this one is, because JMS import makes the enterprise services the same way as if they are another SCA component. In order to understand how JMS import works, we need to understand how SCA invocation patterns are. SCA invocation patterns are either synchronous or asynchronous. In the synchronous one, we send a message and we wait for the response, and the caller is blocked until the response comes back. In the asynchronous pattern, we send a message and we're not blocked. We either don't need any response back, so it's a one-way pattern, or we want a response back in a later time. We call it "deferred response." In this deferred response model, we send a message, we get a ticket back, and later on we use the ticket to retrieve the response. There is another pattern that's called "request with callback." We send a message, we register a callback, and when the reply comes back, SCA invokes that callback and passes the ticket that we got when we sent the message originally. JMS import supports all of these patterns by providing three queues. We have a sentqueue, we have a receive queue, and we have a callback queue. Typically, if we send a message to a sent queue, then we might get a reply back in the receive queue. This is normal ... similar to the deferred response or asynchronous. Then we have a request with callback. When we send a message, if the message comes back into the callback queue, then it invokes a callback inside of the module that actually invoked that JMS import. Pat: Shahryar, can you tell us about the various kinds of binding that need to take place as part of integrating JMS MQ applications with Process Server? Shahryar: When we start talking about binding, we want to bind an SCA component or WebSphere Process Server to the outside world. This binding happens in three levels. The first one is interface binding. That actually we map the logical interface to physical resources of the enterprise service. For JMS, it's matching the logical interface to all the physical resources that JMS supports like queues, topics, queue connection factories, and so on. The more difficult portion of this binding is method binding. Method binding is, when an event is coming in, it has an identifier. This identifier tells us how to map between this event and an operation inside this interface. In method binding, we provide a mechanism to map between the incoming event and the operation on the interface. We also have a data binding, that ... because the data that is coming from the enterprise services is not necessarily matching the business objects inside process server, so we need somehow to convert this incoming data to the data that's understandable by the Process Server. So data binding is where we are serializing or de-serializing the data that's coming from enterprise services to business objects. Pat: OK. Now, Shahryar, we obviously covered quite a bit of material. Perhaps you could take a minute to sum up some of the key points and leave our listeners with a few ideas for next steps that they should take to learn more and get started. Shahryar: In order to implement JMS import and export bindings, we need to deal with all of these three levels of binding that I mentioned. The first level is more administrative. It's how to define queues and topics and all of the resources to bind a JMS application, either from incoming messages or for outgoing messages. We also need some level of abstraction in the method binding that's provided to us by Java routines called "function selectors." WebSphere Process Server comes with some default function selectors that expect some specific attributes on the incoming message to map an event to an operation. We are also able to implement function selectors. So the function selector becomes very important when we are dealing with some non-standard applications that are sending messages to us. If we send a JMS message to WebSphere Process Server, typically JMS messages have some properties in JMS headers that provide the event name for us. But if we are receiving applications from some legacy MQ applications that cannot search the JMS header, then we need to deal with function selector and we need to know about function selector as well. We are also dealing with data binding. Messages that are coming into WebSphere Process Server, for example they are XML messages. We need to know how to map an XML message to a business object, and this is what data binding does for us. It's important to know how to define a business object for a particular XML message that we are dealing with. So we need to focus on all these three levels of binding to be able to make JMS import and export binding work. Pat: Thanks so much for your time, Shahryar. You really did a great job of covering some very technical material. Shahryar: Thank you and thanks for the time you gave me for this interview. Pat: Absolutely. We look forward to talking to you again. That's our whirlwind tour through some complex technology. A note to our listeners: This subject deserves a lot more time, so in our next podcast, we'll take a deeper dive looking more at what you need to know about WebSphere Process Server 6.0, and specifically at Web services import and export binding. Also, let me recommend a recently published book by IBM Press. The title is "Enterprise Messaging using JMS and IBM WebSphere", and it's by IBM product manager, Kareem Yusuf. In addition, you'll enjoy reading Kareem's enlightening blog, which is at www.websphere.org/blog. If you're interested in these and other software development issues, I invite you to visit developerWorks, which is at ibm.com/developerworks. Again, that's ibm.com/developerworks. This site contains thousands of original articles and tutorials, as well as discussion forums, blogs, and other interactive tools about open standards technologies and IBM development products and tools. You might also benefit from being part of the WebSphere community by going to ibm.com/developerworks/websphere/community. Join us next time for our more detailed discussion of Web services import and export. We'll cover application integration with process integration. This is Patrick Flanders for the WebSphere Technical Podcast series on developerWorks, and remember, we're more technical than music. Thanks for listening.