Using Web services with Service Component Architecture for interoperability Patrick Flanders interviews Matt Oberlin | 11 Nov 2005 WebSphere Technical Podcast series on developerWorks http://www.ibm.com/developerworks/podcast/websphere/ Patrick: Hi, and welcome to the WebSphere Technical Podcast series on developerWorks. This is the fourth in our series of podcasts. These are interviews with technical experts within IBM. Our goal is to help you better understand how to solve important software development issues. I'm your host, Patrick Flanders, and I'm an editor with developerWorks. I hope you've had a chance to follow our series thus far. Our last installment, which was about integrating JMS MQ applications with WebSphere Process Server, is especially relevant and that's because today we're going to dive deeper into that topic and discuss some of the details of implementing SOA with WebSphere Process Server, particularly the use of Web services import and export binding. To guide us through this complex topic, we're joined by Matt Oberlin who I hope you remember from our first podcast. In case you missed him, Matt is a consultant on the IBM Software Services for WebSphere team and he specializes in SOA / J2EE application development and Web services. Hi Matt. It's great to have you with us again. Matt: Hi Pat. It's my pleasure to be here. Patrick: Great. Well, let's start with a rather broad question and I think this will be particularly helpful to listeners who are just joining the series. What role does WebSphere Process Server play in Web services and SOA implementation. Who should care about this and why should they care? Matt: Well, so I'll start with the easy part first. Everybody should care. I can probably narrow that down a little bit and say, really, organizations that are worried about interoperability need to worry about how to achieve that interoperability. And Web services, and let me just clarify by saying, for the purposes of our conversation today, I'll say Web services is SOAP over HTTP. So Web services are the latest, greatest, best hope for interoperability. No guarantees, but that's a good way to achieve interoperability. So SOA certainly is all about interoperability. To talk about an architecture that's service oriented without it being interoperable and without it being based on standards really is not quite as useful. And so I think it sort of falls down on several of the criteria we have for SOA. Now, of course, WebSphere Process Server, as we've talked about in other parts of this series and as I know you've talked with some of my colleagues about, WebSphere Process Server works well within the SOA space, both as part of the architecture and more specifically works well with Web services. And we can certainly talk more about that in detail if you'd like. Patrick: Well, Matt, why don't we talk about the technologies that are supported in Process Server version 6 and maybe you can tell us what's new an exciting about it. Matt: Sure. The thing that's great about Process Server version 6 is it is both a continuation of some excellent things that have been done. It has a fantastic BPEL engine for process choreography for managing tasks, we've got the addition of human tasks, but it also is a wonderful business-integration environment and gives us capabilities not only that we at IBM haven't had before in our products but no other company to my knowledge has been able to put together in the way we have. One of the things that's in Process Server that I'm particularly interested in is the integration framework. It's a services integration framework. So it's a way that we can take different applications -- different pieces and components -- and integrate them quickly and easily. And of course we have tooling that helps us achieve that. So, it's really well put together. Patrick: Tell us about the significant components that are a part of Process Server version 6. Matt: Sure. There's several things, one of which Patrick you and I talked about once before, which is the SCA runtime -- the Service Component Architecture -- and it really is an invocation framework for this type of integration. One of the things that to me is really exciting about Process Server is, it's really is just a start for SCA. It's the first IBM product that we're seeing SCA in. But, without giving anything that, you know, making any product promises, which obviously I'm not supposed to do. Let's just stay "stay tuned." You're going to see more from SCA and it's really only a start. So if you think of SCA as the invocation framework and as we're using it now, within the integration environment then the second piece that goes right along with that are business objects and the ability to have one common format for all of the data we're passing in and out of our environment. The other great thing about Process Server is it's given us good ways to deal with, what we like to say, "data at the edges." So for example, for our topic today, I want to get data into my integration environment, work with EIS systems and various other parts of my application. Well, one thing that certainly is going to live on the edge are Web services. This is where we'll be interoperable. Patrick: Now let's get on to some of the gnarly stuff. Are you ready for this Matt? Matt: Absolutely. Patrick: Tell us about Web services import and export binding and how they fit into this discussion. Matt: Sure. The only drawback with the podcast is, of course, I can't draw on the whiteboard, or bring up my slides from my presentation but if you think about integration, you know, we have this wonderful environment in Process Server, but the fun is always at the edges. How do we get things into and out of this environment? So, for us in Process Server, there are several different ways to achieve that and I'll let you continue this discussion with some of the other fine people in our group to talk about many of those, but for my interest area SOAP over HTTP as a way into Process Server or a way out of Process Server -- and what I mean by "out of" is a way to expose my business activities to partners, other parts of the organization, whoever it may be. Web services is a perfect vehicle to do that. Patrick: Let's focus on Web services export. What's accomplished with it and are there any specific points that the developer needs to know? Matt: Sure. A couple things we talk about when we talk about Web services export. I've mentioned SOAP over HTTP which will be my transport and my binding layer. First and foremost, stay interoperable. Well, of course that's why we're talking about Web services. One of the best suggestions for that is stay within the recommendations of the Web Services Interoperability organization -- the WS-I. The have a set of profiles, our tooling and our runtime, supports and enhances or I don't want to say enforces, it can if you want to enforce the WS-I profiles. But we adhere very closely to WS-I recommendations. Now, again there's no guarantee, but that gives you the highest possible capability for interoperability. You have to take a good hard look at the WSDL, the Web Services Description Language. This is really the contract that we use in Web services. Now the good news is there's nothing that's new and extraordinary for somebody who's in the Process Server environment because WSDL is how we describe, at least one of the ways, we describe our interfaces of our other components. So now with Web services export in Process Server we're really just saying, "Look, here is an interface, here is a WSDL file, take this, you can now access my process, my whatever it is, business logic, as a service. That's a wonderful way to achieve interoperability. Patrick: Same question about Web services import. Matt: Sure. So, we take the question and just turn it around. But without giving you a sort of, you know, ditto answer the real details are now we're taking a WSDL file -- we're taking someone else's service -- we're consuming it within Process Server. Now the really interesting part about this within Process Server is, just like the other components in Process Server that are making use of SCA for the invocation, I now have a WSDL interface that represents, in this case, not another component, but an outside partner, vendor, whatever it is -- whoever I'm talking to. And the great thing is, within Process Server, it looks the same. My SCA invocation is the same. The fact that I'm now not talking to one of the components in my own process, but talking out over the worldwide Web, SOAP over HTTP, is transparent to me as the developer within Process Server. And, that's a powerful framework to work within. Patrick: One more detail here, Matt. What do Web services import and export accomplish that cannot be done with JMS? Matt: That's really an excellent question. I think the biggest contrast is that Web services as I'm describing it -- SOAP over HTTP - - and, and I want to be clear about this, because, I'll be honest. IBM has a rather expansive view of Web services and I think that is a tremendous visionary look-ahead. The issue with that though is describing SOAP over JMS, which by the way we can do in Process Server and our other products as well, describing SOAP over JMS is not as interoperable. Not everyone has bought into that so when we talk about pure interoperability and adhering to standards, SOAP over HTTP, Web services are really our best bet to achieve that interoperability. The other big thing about Web services and SOAP over HTTP is the fact that we can make our calls synchronously. JMS, based on queuing, is an asynchronous -- a fire and forget -- so oftentimes those patterns play into our choice of why we would not pick SOAP over HTTP versus JMS and a queuing model. Patrick: Good job with a lot of detailed information there. Can you provide a few words of summary since we need to sort of wrap up here. And then, you know, what are the most important takeaways for the listener from this discussion? Matt: A key theme has been interoperability, SOAP over HTTP, the use of good, interoperable WSDL, how this can play very powerfully within the Process Server environment. The one thing I'm going to do is temper my own enthusiasm and just sort of give people a caution and say, you know, there are occasions where you can get too much of a good thing. So just like you don't want to take two helpings of dessert, you don't want to try to do everything as Web services, and everything as SOAP over HTTP. This is really something that exists on the edges of our application to expose services or consume other services and to give us maximum interoperability. So, use Web services where they make sense, use them judiciously, and they really help with interoperability. Patrick: Well, Matt, that really was a great overview -- and included some great detail on how to implement Web services/SOA apps with WebSphere Process Server 6.0. And I really appreciate your time and your thoroughness with this. Matt: My pleasure Pat. It was, it was fun doing this. Patrick: Good. Well I hope we have a chance to talk again soon. And thanks to all of you for listening in from your home, office, car, or wherever you happen to be. If you're interested in learning more, I invite you to visit developerWorks. Just point your browser to www.ibm.com/developerworks, again that's ibm.com/developerworks. This is IBM's developer Web site that 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 and you can get there at ibm.com/developerworks/websphere/community, again that's ibm.com/developerworks/websphere/community. I should also mention that all of these resources as well as many others are highlighted on the podcast summary pages which are accessible from the developerWorks home page. We'll get back to WebSphere Process Server version 6 in our next podcast, which will cover best practices in assuring flexibility in your software through what we call versioning and dynamicity. Please join us. For now, this is Patrick Flanders for the WebSphere Technical Podcast series on developerWorks, and remember, we're more technical than music. Thanks for listening.