eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Bob Sutor, IBMs director of WebSphere infrastructure software, will be keynoting at this weeks Edge 2004 conference on software development in Boston. Sutor, who will be speaking on the concept of service-oriented architecture, took time last week to explain IBMs SOA strategy to eWEEK Senior Writer Darryl K. Taft.
What will you be talking about at the Edge 2004 conference? What will be the gist of your message, service-oriented architecture?
The title of the talk is going to be “How and What to Think About SOA.” So the idea is to try to describe the characteristics of what were talking about in service-oriented architecture and how that relates to all this business stuff were talking about with on demand. And essentially the story there is to say we can talk about on demand completely in business terms. The top of it is to say that what our customers are after is flexibility, efficiency, being able to respond quickly to their market opportunities and the demands that their customers place upon them. That will allow them to become more competitive and so on.
So on demand is very much a business story, and it talks about how can I run my business much more efficiently to serve my customers? Then its very logical to say how do you actually do it? So the gist of what Ive been talking a lot about is to say at the top level the “how you do it” answer is service-oriented architecture because its the best way we know about right now to build what is essentially distributed computing.
So there are all sorts of new IT challenges included in this brave new world that has been brought upon us by the Internet that we need to solve. And SOA is not a new thing. By most accounts were actually in the third decade of thinking about SOA.
The story continues from the architectural picture of the capabilities of what were looking for in terms of SOA to say, Well how do you do that? And the technologies that let you do service-oriented architecture and let you do distributed computing are things like Web services, are things like grid. But again those are technologies. But if you focus down to like the fourth level and say, How do you deliver those technologies, how do they become concrete? Then the IBM story is thats WebSphere and our other products.
So what particular points will you be making?
In many ways, I think there are two important things to pull out of this. One is that were being forced into service-oriented architecture whether we want to or not. Its a good idea. Its good that it solves a number of our problems. And, frankly, from an architectural perspective its rather elegant. But the way business has been changing over the last few years and the expectations of the Internet really mean that these notions of service-oriented architectures and being able to work across heterogeneous environments … theres no question that we have to do it. The logical questions are around when and how as opposed to if.
Then the second point I would say is for many different ways of looking at this, service-oriented architecture is really why we did WebSphere. To ultimately not just serve up Web pages, but to truly allow enterprises to connect to each other and to truly build powerful enough applications that could tie together the concerns of the people you need to interact with externally, with all the different sources and different applications you might have internally as well. So the evolution of a WebSphere with its Java programming model is really key to providing the service-oriented architecture and its key features. Thats why we announced, coming up on four years ago, early support for SOAP [Simple Object Access Protocol], as weve been very aggressively helping to define the standards and implement them around Web services and around Java. This is why we very much think that WebSphere is moving, in the IBM universe, as the center of the SOA universe.
SOA is very clearly instantiated through WebSphere and has been guiding the creation of the WebSphere application server over the last few years. And it will absolutely continue to contribute to the way we do things like data management and systems management and straight-out software development.
Definition of SOA
Can you pull back a bit and give me a basic definition of what is an SOA?
Essentially, in brief, an SOA is distributed computing where you identify the different units of work or units of activity as services. So a service is some piece of software that you can issue queries to, issue commands to in some way, basically tell it to do something, and it responds back to you. Its critical that there is a large degree of standardization in how you actually define these services. That is, we cant have one language for talking about this service and another language for talking about that service. The key is to try to make what is essentially an extremely heterogeneous implementation to look as homogeneous as possible—that is, your service or another service can be described in exactly the same terms and therefore processed by exactly the same tools.
Given this notion that I can describe services, I can get those descriptions, I then need to connect to them. And I have certain requirements about that connectivity. So I have requirements about reliability, that is I know if I invoke a service Id like to know that something actually happened. That it got the message and responded back to me.
So it basically boils down to distributed computing with standards that tell us how to invoke different applications as services in a secure and reliable way and then how we can link the different services together using choreography to create business processes. And then finally so that we can manage these services so that ultimately we can manage and monitor our business performance.
Why all of a sudden has it become a buzzword?
I think its become a buzzword in large part because Web services is taking off. Web services is really the best pure way we know of doing service-oriented architecture right now. Web services is taking off because its finally sinking into people that the value that we saw in the Internet around Web pages in the last decade is going to translate to the ability for businesses to really connect with each other and do transactions across the Internet. So once you get to a point where you realize something is inevitable, you then go down a little bit deeper into it. When you talk about new technologies like Web services you have to say but how does the rest of my world play? The last thing people want to say is you have to rip out everything.
So therefore once there are new technologies that get a sufficient following, people start thinking about the bigger picture. And they start thinking about how they can evolve their existing implementations to take advantage of these things. And they start thinking about roadmaps. And in the IT world when you talk about bigger pictures youre talking about architecture.
So the reason is Web services was enabled because of the success of the use of XML on the Internet. Once people started to get enough success around Web services for projects, and enough understanding on what the point was, they wanted to know what was the larger picture and how did it relate to the infrastructure they already put in place. That means a move to architecture. The architecture that Web services is a part of is a service-oriented architecture and therefore that now brings in the much larger consideration of what youre doing with IT.
There is really tremendous acceptance about what weve been talking about with on demand. On demand is an IBM phrase, but the things I said before about becoming more flexible and responding to business opportunities, thats very straightforward. When people say, “How do I do that?” fundamentally theyre saying, “How do I build my business processes to get the business value and to do the appropriate connections with my customers, my suppliers and my partners to make this work?” It turns out that SOA maps very, very closely to this notion of business processes and to business requirements. So therefore you come up from below from a technological perspective of looking at the bigger IT picture, and SOA makes sense. When you come down from the business-level discussion of what youre trying to accomplish and what the actual business processes are that you need to run your business, theres a very close mapping between the notion of services and the components of business processes that gives an extra little kick as well.
Do you think the term is overused?
No, I dont. I think its actually nice to settle in. And in fact if you go back 15 years when people were looking at object-oriented systems, well before Java, the notion of things that are in Java would have been considered absolutely radical 15 to 20 years ago. And its just obvious now. But at that time there was a major move away from building applications in a structured manner to building them in an object-oriented way. It came out of academics. And people really started examining how you structured applications, how you structured data and how you could start to share these things. And a lot of the seeds of SOA were in that.
I was in IBM Research for 15 years, and there were things that we did in the late 1980s that were more sophisticated and are not yet in the object-oriented systems that were doing now. We were dealing with mathematics in the sense of modeling things. So a lot of the seeds of what was eventually SOA came out of the object-oriented view of the world.
So its a long time in coming. And its not a term thats hyped because its brand new and its the latest fad. Its something people have been thinking about for a very long time.
Next page: Customer reaction to the SOA message.
Customer Reaction
What has customer reaction been to this SOA message?
Its very interesting. Thereve been two experiences. Weve been doing this Web services stuff for almost four years. So it used to be that when we went in we would have to explain Web services. Wed tell them about the specs and what we were doing. Thered be a very heavy education aspect to that.
When we talk to customers now and we describe service-oriented architecture they say, “Yeah, were already doing that.” And so its a very different world. And I cant conclude that its because they now understand Web services completely. I think its more that were being driven to this as an inevitable way of building these systems and these customers have concluded that all by themselves. That does not mean they have in place all the software they need to do this. It means they have begun to think about their systems in an SOA manner. Asking how do you bridge these different sorts of systems. “Heterogeneous” is a big word for saying “different.”
Have you noticed whether its translated to increased sales?
Well, I dont know that I can say that anybody has come in and bought an IBM system strictly because of SOA. I dont know that anybodys said, “Thank you, Ill buy five copies of WebSphere because I like IBM SOA.” When we talk to customers, its far more concrete than that. Its more, What problem are you trying to solve? How do our products work together? How can we work with you to provide services to do what you want to do?
Its more reflected through saying IBM understands Web services and IBM understands SOA, we can provide this value to you.
So in that sense I think what is clear to customers is we get it. IBM gets it in the products and in the services. So I cant pull out the SOA revenue from things like that. But I would say from the general picture, if you look at WebSpheres position in the marketplace relative to BEA, the type of mindshare and leadership weve built over the last few years around these concepts has translated because of things like Web services and because of SOA to some degree. I cant measure exactly what that is, but Im confident it has translated to superior market share for WebSphere in comparison to its competitors.
Have you noticed that SOA is beginning to appear in RFPs [requests for proposals] and stuff like that?
Some of them, yeah. Certainly Web services are. And SOA is one of those things that if Web services shows up then SOA does as well. So those types of things show up all the time—support for SOAP, support for WSDL [Web Services Description Language] and things like that. I think were in a transition point where were going to see it show up in new and different ways. Were going to see it show up when people talk more and more about systems management in general. I think were going to see it show up more and more when we talk about the various collaborative features we have, because a lot of the back-end stuff we have like WebSphere Portal actually uses Web services under the covers.
So I think SOA shows up pretty regularly in terms of what we call process integration by virtue of direct Web services support, but also the way we implement SOA with WebSphere MQ and the WebSphere MQ brokers and things like that. They all play as well. The types of things weve been doing on the messaging side of the house, all those things are critical parts of IBMs SOA story.
I asked because I saw a recent policy statement from the state of Massachusetts that specified an SOA as the target for future acquisitions.
Yeah, that makes sense. And thats an architectural view of the world, which means that all these things we talked about have to be there. I want to also emphasize that the SOA story is not just Web services, there are other components. So the standardization of the connector architecture within Java means that youre going to be able to work in a far more standard way with the different pieces of enterprise software you need to interact with. Thats one component of what were trying to do. The general notions around messaging that people have been doing all play into this.
At this point I also want to mention a lot of people like to come up with litmus tests if you will. So I can describe SOA in terms of distributed computing, hence requirements on how the different pieces talk together and how you manage them and security and things like that. When we talked three years ago about Web services I was fairly liberal in terms of saying, well, if youre doing this type of thing youre playing in the Web services world. Right now, though, I think were far more precise in talking about what it means to do Web services. It typically means somewhere down in the bowels of what youre doing youre using SOAP or WSDL. And then we can expand that. And every year that goes by, the definition and the litmus test becomes more and more precise. The Web Services Interoperability Organization [WS-I] is critical to that sort of thing.
So with Web services were advancing to the point where you can be far more specific. Youre doing real Web services or youre not.
With SOA right now, I think the big picture here is pretty clear about the notions of interfaces, the notion of true distributed computing, the notions of being able to say if Im interacting with you and youre doing .Net and Im doing a service-oriented architecture. If I have to know youre doing .Net, you lose—because youre not playing in the game right here. Youre still somehow pushing what is proprietary technology out to the forefront. So to use your example of the state of Massachusetts, part of what theyre saying is while we will obviously buy particular technology from vendors, when were talking about the way our systems interact among the systems we have in-house and the other systems we need to touch, that proprietary stuff must remain in the background.
Distributed computing has got to be there. The notion of being standards driven has to be there. Sure, theyre going to look and say, “Does IBM provide a better implantation?”, but its the question of these interface points that are what people are looking at for SOA.
Next page: Legacy technologys role in SOA.
Role of Legacy Technology
What role does legacy technology play in SOAs?
It plays a lot. I mean its not going away. In the sense that whats legacy now will be legacy three to five years from now. It seems to be a characteristic of enterprise systems that when you install something you are looking for five to 15 years at least worth of work there. So that means that if youre going to start talking about new technologies, as we did seven years ago with Java and more recently with XML, you must absolutely answer the question of how it plays. It is possible using things like Java and Java Connector Architecture to essentially just leave those systems in place. And to provide more modern interfaces for interacting with them. But what youre providing is this standardized view of how you talk to it and how it talks to you. What that means is to the degree that you have processes that are running legacy systems that are using legacy communications and they need to keep running, they keep running. But you need to extend or augment the use of those through new channels. And such a new channel could be via Web service, it could be via Java Connector Architecture or by other things.
As with everything there is design associated with these things. If you had installed an SAP ERP system, odds are youre not going to expose absolutely every capability it has in there. Youre interested in doing certain things. You may be interested in getting customer data out of it or inventory data out of it. So therefore what you will do is let the system keep running, but you will define services that allow you to interact with that bigger older system in very well-described ways. So SOA gives you a lot of reuse of the legacy systems themselves. But you must think of how those systems play in the bigger picture and how you model the interactions with them.
You do not take the legacy system and every possible thing it does and simply make into a service. What you can do is, as youre thinking in SOA terms, say, “What do I really want to do with that thing and what information do I want from it?”
With a lot of the more recent specs IBM has been involved in, some folks are saying it looks like youre trying to reinvent CORBA [Common Object Request Broker Architecture]. Is that true?
They said that when we put out SOAP.
Well, you kind of touched on it in the beginning when you said were doing stuff now that we did in the 80s.
Were refactoring what were doing. I think the difference is that Web services is a componentized architecture. Use what you want. If you dont need that big piece, dont use it. So we will have failed with Web services if I want to do a very simple invocation of a service with no security and no reliability if I have to bring in a lot of other pieces of machinery.
Fundamentally what we do know from IT is that there are certain types of requirements that come out. Just because we evolve technology does not mean certain things go away. When SOAP came out we didnt have anything about security in that. There were hooks in it to do security, but there was not security there on Day One. And people yelled at us about that. And we said, yeah we know. Security will come. But the IT requirement for security was still out there. And to this day we are building the standards to implement security. In the larger picture we are building the standards for message reliability, because knowing whether a message gets there or not is just critical.
So all these things are standard parts of computer science. Theyre basic requirements in the abstract of how you build enterprise systems that communicate with each other.