Introduction to the SOA programming model Patrick Flanders interviews Matt Oberlin | 14 Oct 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 first in a series of podcasts. These are interviews with IBM technical experts on today's vital software development issues. I'm your host, Patrick Flanders. I'm an editor with developerWorks, and our first podcast is an introduction to a service-oriented architecture or SOA programming model -- what it is, what you can do with it, and how you can develop SOA applications. I'm fortunate to have with me today Matt Oberlin. Matt is a consultant on the IBM Software Services for WebSphere team who specializes in SOA / J2EE application development and Web services. Matt it's great to have you with us. How are you?. Matt: Thanks Patrick. It's great to be here. I'm doing well on a rainy day. Patrick: Oh good. So it's rainy out there in Raleigh, is it? Matt: It is ... yup ... but we need the rain so that's good. Patrick: Good. So, well, we have a number of questions I'd like to ask you, so I'm just gonna jump right into it. Maybe in 25 words or less -- I know that might be difficult -- uh, why is SOA better than other component architectures? Matt: I think that's a great question, Patrick. Umm, the 25 words could be tough but as those who know me know, 25 words or less can be difficult for me. First of all, you've got to be very careful when you compare SOA -- a service-oriented architecture -- with other component architectures, because one of the things we want to be very clear about is it doesn't supersede other architectures. This is really part of an evolutionary process, so, when we say it's better we have to be careful that we're not implying throw out all you've been doing. In many cases, people have been doing SOA, though not necessarily formally, not necessarily according to standards which give you the most interoperability, but organizations have been doing SOA and not realizing it, or moving in a direction of creating service-oriented architecture. I think the other thing that is new in this evolutionary process and really provides value, so in that sense it definitely is better, is the fact that we have a much clearer sense of what we mean by services. We're now starting to define services from a business level and not from -- you know -- as an IT practitioner, the level I think of services at. Now it is all well and good to define those services from a business level, but the real flexibility comes in being able to implement those as business services down at the IT level. And that's the exciting part about this. We're getting to a point, and we're at the point we're starting to use it where we can actually create architectures where we can do that. We can describe services from the business level and give us maximum flexibility in how we implement those in IT. Patrick: That's great. I'm sure that's going to be music to the ears of our listeners, especially the architects and developers who are going to be doing some of this implementation. Matt, getting to the programming model, I want to talk specifically about that for a moment. I want to find out , first, what are its core principles and what do they mean for a development team? Matt: Well, it's kind of interesting you say that. At one level I have to admit that an SOA programming model grates on a me a little bit. It's a little bit like fingers on a chalkboard, only because sometimes I think the implication there is that as a programming model it helps us, or it automatically gives us a service-oriented architecture. And the analogy I like to tell people is, you know, saying that a programming model gives us SOA isn't any more true than saying building a wall makes a castle. It's a good start. You know, you need the bricks and mortar to build a large structure, but it's really about the blueprint of how you create that. So it is more in the architecture rather than what it is you use to implement it. Now, having said all of that, what I will say is, the key behind SOA from an implementation standpoint is how do you do the sort of things we've been wanting to do? You represent things in a standard way. You represent things with an interface. And of course, these things I'm talking about are services. That's what gives us the ability to make our services composable, replaceable components. That's really the key. When you have an infrastructure -- in this case we're talking about a programming model -- when you have something that gives you that ability, then you have the power, you have the ability to create and architecture, in this case a service-oriented architecture. But, you know, just having those tools doesn't guarantee you have the architecture. You still have to have a plan and do it right. Patrick: So I'm curious about this. What does an SCA -- a service component architecture component look like, and how does that actually help me build the SOA system? Matt: Well, that's the great question, right? And that's the interesting part. To a developer, to the person who is actually putting this together, or the integration specialist, SCA looks like a component. Now, of course at one level it sounds like I'm double-talking, right, because component is in the phrase. But what I really mean by that is it's a thing that has an interface, and the great thing about SCA is that interface can either be Java or the Web services description language -- WSDL. And the great thing is WSDL is a known interface. It's a way to describe services. Typically we think of that -- we with a capital "W" in the global sense -- we think of a Web service as being SOAP over HTTP, but the Web Services Description Language actually gives us capabilities to describe much more than SOAP over HTTP, and the great thing about using WSDL as an interface is it's well understood, it's standards based, and it's very interoperable. At its heart of hearts it's just XML. So what I'm really talking about now is an XML interface that you can use, you as a developer can use to get to my component. And the great thing is, SCA gives me a very simple programming model around invoking things with that interface. What's behind that interface? As a developer I like to say that I'm ignorant and apathetic. I don't know, I don't care what the implementation is. To me, that's a real service orientation. I now have a component that is a service and I don't need to worry about the details of how that's represented. Patrick: OK. So now, let's say I'm a practitioner. What technologies do I need to know, what do I need to master in order to build SCA components, and are there truly specialized skills and a core set of knowledge that I'm going to need? Matt: Well, today a little bit of Java would be helpful since SCA is implemented today on Java. That may not always be the case, so keep looking in this space to see what happens in the future. But the point is, beyond just Java, SCA is built today on top of J2EE, so one of the nice things is SCA hides a lot of the more difficult J2EE implementation. You, as a developer, don't have to worry about those. The focus is on using the new tooling called WebSphere Integration Developer, or WID we sometimes like to call it, and using that tool and a GUI to drag together components and literally create lines that are physical connections. Now within all of that, there are artifacts that are generated, there are XML files and J2EE artifacts that come out of that. So understanding J2EE and knowing a little something about the WebSphere App Server is certainly helpful, and you're built upon that rock solid technology. But it's not necessary for, say, the integration developer to know all of the details of J2EE. They're abstracted from that. They're really working with SCA and a GUI and these things called business objects which are the way data are represented within process server. Patrick: Matt, this might be a good time to briefly mention some of the tools and technologies, and even some of the training that IBM offers to help developers use the SOA programming model and build SCA components. Can you enlighten us a bit on some of those resources? Matt: Sure, absolutely. For a general overview of SOA, IBM as you have probably seen has been doing a lot of work in getting the message out about what SOA is, and in a lot of cases what SOA isn't. If you go to the main IBM site -- www.ibm.com -- and then go slash SOA, you'll find a wealth of resources including "getting started." There's even a really excellent talk by Robert LeBlanc on SOA. For more detail down to the nitty gritty, as I like to say, getting the bits and bites underneath your fingernails, you can go to the developerWorks site -- again, www.ibm.com/developerworks/soa -- and there's a wealth of information there about getting started today with the details and the technologies of SOA. You should probably look into the latest products coming out from IBM. The WebSphere Process Server has been announced and actually exists as a product today. The WebSphere Integration Developer, as I mentioned a moment ago, also exists. Those two are companions. And then at the heart of the WebSphere Process Server is a new product that will be coming out later in 2005, toward the end of the year here, called the WebSphere Enterprise Service Bus, and that will be a new technology that will help enable service-oriented architectures from an enterprise service bus pattern. Patrick: That's great, and I will going into some other resources a little later in our chat, but that's a great overview, Matt. And I think that listeners should also just keep in mind that, if you stay with developerWorks, if you check out the various areas on developerWorks including things that would be relevant -- there's the Java area, XML, Web services, WebSphere -- we always track the developments in these areas, so listeners should always try to come back to developerWorks and you'll see what we're working on in IBM and how we can help you too. That's just my little plug in there , Matt. So let's get back here really quickly with these SCA components. So these components clearly help me get to a complete SOA deployment, but what do I do if I've already built a lot of functionality using non-SCA components? Matt: You know, that's a great question and that actually in some ways brings us full circle to a very good instance of where I said, ya know, IBM's take on SOA as an architecture is not revolutionary, it's evolutionary. And the point is here, you don't want to throw out all the things that already exist. You know, there's been some points in the IT world and we've seen these even in the beginning of SOA where it was, well, let's tear everything out and turn everything into services. And what we talk about now is not throwing things out or tearing them out, but reusing what already exists. You know, sometimes we call them legacy systems. I don't like that word because they're often the things that are at the heart of our business today, so what we'd like to do is take things like access to the mainframe or that critical business process that's sitting on a server running in C, and maybe it's even CORBA-based depending on the technology -- it could be most anything -- we want to take those and service-enable them, right? So we want to make those available as services and fit them into this pattern of an enterprise service bus and the larger service-oriented architecture. That's really how we gain this. When we talk about business having the flexibility to change, it's because we can define services from the business perspective. But more importantly, we can actually represent those in our IT structure. That's big and that really is a giant leap forward. So the great thing is, we can reuse what we already have, but we service-enable them, so for example, we can use SCA as a wrapper around existing architectures, components, and IT systems. Patrick: OK, good. Now Matt, we're almost out of time unfortunately, but by way of a wrap-up, for people who want to get right to work on SOA and SCA, what would you suggest that their first steps be? Matt: Well, I would say they should make a connection with us at IBM, and there' a number of different vehicles to do that. I gave some of the URLs. There's a lot of information that's available for free on our Web sites that they can dig right in, they can do an SOA self-assessment, they can hear, not just myself, but some of the real big thinkers at IBM talking about SOA and where it's headed. And then they can engage IBM directly. They can go to their sales force, they can interact with services, and start to get information on how they can apply SOA in their organization today and even moving into the future. One of the things to remember about SOA is, you don't have to start with the entire organization. You can start with smaller pieces. There's a number of different entry points into this sort of architecture. Again, part of the evolutionary, not revolutionary. We're not going to do it all at once. We're not going to do it overnight. But if we don't have a road map, if we don't have a path to getting there, we certainly aren't going to get there. Patrick: Those are really important things to keep in mind, definitely. Matt, thanks so much for your time here. I really appreciate your time and I'm sure that our listeners are very glad to gotten your advice and opinions on these things. Matt: My pleasure. I was happy to be here. Patrick: We look forward to talking to you again. At this point, that wraps up our coverage of the SOA programming model. If you'd like to learn more, I recommend that you check out developerWorks as Matt mentioned. Just point your browser to www.ibm.com/developerworks/soa, again that's www.ibm.com/developerworks/soa. developerWorks contains literally 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 www.ibm.com/developerworks/websphere/community, again that's ibm.com/developerworks/websphere/community. Join us next time to talk about another important SOA topic -- applying integration patterns to speed your SOA development. This is Patrick Flanders for the WebSphere Technical Podcast series on developerWorks, and remember, we're more technical than music. Thanks for listening.