<<How important is the SOA Reference Model that OASIS now offers as a standard definition of the service-oriented approach? James Bryce Clark: One of our milestones for 2006 was that the SOA Reference Model committee did issue a standard. It's proving to be a very useful and appreciated piece of work. But let me tell you what it is not. It is not an architecture. It is also not a list of standards. There's a tremendous temptation to say SOA is the following six tools or the following four standards used together. You can sell a lot of software by saying that. The problem is it's not true.
So what is it? Clark: Service orientation is a methodology. It's a way of organizing information. An enterprise service orientation most commonly expresses itself as bullet points in an RFP (request for proposal). What you're really doing when you decide to go down the path of service orientation is you are making a decision about the requirements and constraints that you will impose on all the information that you want to expose to interoperate with other people. There are a lot of ways to do it. There are a lot of different methodologies. There are a lot of different modes of expression. There are many different software choices. It is not a bunch of standards or a vendor's product. It's a decision that you want everything you're doing to run a certain way. Then it constrains your choice of methods and vendors and apps and sometimes trading partners. Is it a case where SOA is not always what people think it is? Clark: One of the interesting challenges for our world has been to help people understand what tasks they face and what pieces are likely to be on the playing board in moving toward service orientation and Web services. It's not about XML. We've kind of moved from EDI to XML in our world now but some day we'll be doing something other than XML. But service orientation reaches across all that and is not dependent on any of them. The idea is that you're going to take your product computation functions and express a node or end point for them that is available to the world, described in a certain way and takes calls and other functions so it can be reused, even by people who don't know you. That's a fundamental architectural concept and a lot of constraint and opportunities follow from it. How did the reference model project get started at OASIS? Clark: The most interesting thing about the SOA Reference Model is that it got started because a bunch of people who had been working in XML, Web services and other SOA methods were frustrated with the attempt to define service orientation. It actually started as a project to name a set of standards. They thought maybe we can explain it to people in terms of layers. You have to have a registry layer, a messaging layer, a content layer. There was some effort to go down that road. What they learned quickly was that in order to say any of those things validly you had to grasp more fundamental concepts like what is a service? What is a phenomenon properly understood as a service, not an attribute or a feature of a service? What does it mean to have a description of a service abstractly? What can we conclude from a definition of a service, what do you have to do to have a definition? There were some basic concepts that really needed some fleshing out before you could create any architecture. So the SOA Reference Model was an attempt to come up with a working consensus definition of those basic building blocks on an abstract level, which then could be taken to architectures, to more than one architecture. Take a look at the model. It's great work. A lot of people who are out there building these things seem very happy with the concepts. It seems to be helpful in organizing their own architectural plans. Is there a next step in building on the reference model? Clark: Yes. Now the SOA-RM technical committee is going on to a second phase. The SOA-RA subcommittee is continuing to develop a SOA reference architecture (SOA-RA) based on the SOA-RM specification. What will the reference architecture encompass? Clark: The reference model, which is the one that has been issued, was attempting to answer the question what is an SOA. What are the pieces? How would you know one when you see it in the wild? It helps people think about whether they want one or not. Once you've got past that question, you've got a second question. What do you do with one and how should you build it once you've decided you do want one. How do you build it? How do you use it? How do you own it? That's a different set of questions. The reference architecture technical committee members are taking that same set of elements. There is a service. There is a description. There are contracts and policies. They will take each of those basic shapes of the "tinker toy" and describe in more detail what can populate each of those pieces. What are the requirements? If you're going to have a service description, what do you need? Undoubtedly, there will be a listing of some possibilities as examples. But they are still not trying to create a normative command that you must use this, that or the other thing. So will this then be more in the form of guidelines rather than rules? Clark: Yes, because take for example service description. There are lots of services out there and a lot of them are described by WSDL, which is designed for that purpose. The functional question is, if you're going to have a service description what are the things that it must do? Then you can use WSDL to interrogate it against those requirements. Will the OASIS SOA Adoption Blueprints play any role in the development of the reference architecture? Clark: As you may know, SOA Blueprints is an ongoing technical committee working to describe models of business processes that can be instances of SOA. For example, I want to run an auction site. I want to automate my CRM. The SOA Blueprints project is creating examples of instances that are open and do not embed a lot of competitive intelligence. One of the problems is many of the automations of business processes embed an awful lot of competitive advantage. For example, Boeing and Lockheed, both of which are very into e-commerce, do not want to share their methods with each other because it has all their business rules baked into it and they're not keen to give that to each other. So the SOA Blueprints technical committee is helping to make things generic, so they define in an open space some basic processes. Their output is not in the form of XML specs. They are instances of how you might accomplish a particular goal. I would expect the reference architecture will eventually be a set of criteria that would inform collections of examples, like SOA Blueprints. For the matter, any enterprise or government that wanted to show you what it did with Web services might well say, "Now that we've got some things that we've bootlegged together, we're going to take the RA model and hold it up and see if things are working the way we think they are." Then those might become additional instances, or good examples. But SOA Blueprints and the RA are related at an abstract level. They don't feed directly into each other. How will RA differ from the WS-I basic profile? Clark: The WS-I people set out to solve the following problem: assuming you want to use WSDL, UDDI and SOAP, how do you set all the settings on those things so all of the vendors will make sure they support those standards? They're paving a clear path for us, saying we're all going to agree on this, so as to remove the practical problem for some poor guy who just bought middleware and is trying to figure out how to set the switches. That's what the profile is. So the WS-I basic profile will be an example of a set standards that you can hold up to the functional requirements of the reference model and the reference architecture. They don't rely on each other. The WS-I model will tell you if you are buying turnkey products from one of the major middleware providers, then you know there are one set of settings that will work for everybody. The reference architecture will tell you what things we need to make sure are done in our architecture and in our software. How do we make sure each of our vendors are fulfilling our needs and whether we are missing any pieces? When are we likely to see a first draft of the reference architecture? Clark: They expect to be done within 2007. We've talked about defining SOA and moving on to a reference architecture, can you sum up where things stand now at OASIS? Clark: We benefit tremendously from the fact that our members are willing to take extra time to share their models and contribute their information and collectively advise the world on the best ways to do these things, and what they've learned so far. Standardization is an area where folks who are in competition come together to make something that's better for everybody. The thing that's more important to understand about SOA in the standards world is that the privileged information of standardization is reality. We can come up with models until our eyes are crossed. But what is really important is what people are doing out there. Where have implementers encountered problems? When vendors try to build something and they can't make it the way our idealistic model describes because there is a practical problem, that's important information. It happens sometimes when an implementer who is creating their own enterprise architecture installs all the stuff their consultant or provider told them to install and it doesn't meet their need because their business needs weren't really contemplated by the vendor's plan. That's really important information. So these aren't static issues and dead conversations. They are models that are continually refreshed by more feedback from the implementation world. Our best work comes when we send out pretty good descriptions that are then critiqued and made better when people come and tell us how the world really works. We'll hear from the folks at some of the large retailers and some of the large e-commerce companies and manufacturers with big supply chains. They will come back to us and say: "This is really helpful and I learned a couple things, but you have this part wrong as we found out when we were orchestrating the supply chain of 24,000 suppliers of car parts." So this is not an issue we resolve and then we're done. It's a collective body of knowledge that grows over time. In standardization, we're seeing more and more releases, more and more uses of wikis and discussion lists for ongoing conversations. It's living information. We are at the early stage of the experience of enterprises with service orientation, which means we'll know a lot more in a year than we know now.>> You can read this at: <http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1237413,00.html?track=NL-110&ad=575808&asrc=EM_NLN_880902&uid=5532089> Gervas
