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 possiblethat is, your service or another service can be described in exactly the same terms and therefore processed by exactly the same tools.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.
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.