December 24, 2002

Web Services - A Definition

Earlier this month I ran across a forum titled, Web Services: Definition Wanted !! The answer is simple, "A service on the Web." The question of what Web Services are is vague and can be defined in different ways without any answer being wrong. Here is my definition of XML Web Services and the components necessary to make them a success.

The concept of Web Services has always been around, with good examples being websites or email. The success of the website was due to the browser/server relationship and their ability to speak HTML and HTTP. But when people throw out the term "Web Services" today, they are implying "XML Web Services". It is not a problem of definition, but rather one of terminology.

XML Web Services are not about integration, compatibility, or any specific field in that matter. XML Web Services (I'll just call them XML-WS from now on) are about anything you want them to be about. The reason XML was chosen as the foundation of XML-WS was no mistake, but rather to take advantage of its extensibility. Essentially, you could write a Web Service using whatever technologies you want and not care about XML, but the whole point of writing XML-WS is that someone else is going to use your service. Keeping this in mind, you have to understand the complications of different companies using different technologies and requiring you to learn different APIs, etc. These complications and more are the reasons why people love XML-WS.

So XML-WS must use XML and that's it?
Yes, kinda, not really. You see, because XML is so extensible, you have to define some basic rules to make sure everyone is on the same page. Otherwise, with everyone speaking different XML, you end up with a bigger mess then the one you tried to solve. So the XML in XML-WS just turned into X*ML. The asterisk could either be a wildcard or a "read the fine print" pointer. Anyways, these basic rules are compromised of standards and recommendations that attempt to create a roadmap of what technologies to use, when to use them, where to use them, how to use them, and so on. You can pick and choose as you please. SOAP, WSDL, UDDI are there to help you if you need them. No one said you HAVE to use them, but you have to ask yourself, "What do the consumers of my web service want?" This is the most important question that XML-WS creators should ask themselves before they waste their time trying to create a Web Service that supports every conceivable buzzword in the market. This can be done by directly asking consumers or just starting the project by positioning yourself as the consumer before writing a line of code for your XML-WS.

I'm confused, what technologies should I use?
Don't worry. Although there are infinite possibilities, two architectures have emerged as the best choices to deploy XML-WS—REST-based and SOAP-based. REST is a description of the current model of the Web and when used within the context of XML-WS it means using XML, HTTP, and URIs as its foundation (I'll call this REST-WS and the SOAP-based architecture SOAP-WS to save some typing). REST-WS advocates argue that we don't need any new standards or recommendations, but rather that the current model of the Web is fully capable of supporting XML-WS with the use of HTTP methods (GET, POST, PUT, DELETE, etc) and URIs (such as So your XML-WS is accessed just like CGI scripts but instead of speaking HTML your XML-WS speaks in XML. REST-WS is very simple, the support is already there, and you could go on for days on why REST-WS is a good choice. But REST-WS is doing something very dangerous—it is using an architecture for XML-WS that wasn't meant for XML-WS. REST-WS advocates downplay this fact. The reality is that REST was excellent for the Web when it came to instant transactions such as browsing a website but when the Web became complex REST broke. It was patched up but it was never really fixed. But look at the Web, look at REST, look at how successful it is you say! Yeah look at all the millions of dollars businesses have lost because of Web security, look at where it has been successful, and more importantly look at where is has failed. REST = Simple. Simple = Insecure. It's true that there are technologies that help REST overcome its issues such as SSL, callbacks, cookies etc, but do you really want to keep pushing REST, keep throwing in new technologies to handle problems, keep...? You can use a wrench to pound on a nail, but I'd rather use a hammer.

You have probably realized by now that I am pro-SOAP. The reasons are numerous, but mainly due to the fact that SOAP has the potential to bind to any application protocol. The REST-WS use of HTTP assumes everyone is happy with HTTP. Don't get me wrong, I love REST and HTTP for certain client/server tasks, but not XML-WS. I think the fact that standards bodies are looking to layout new ground for XML-WS is because they analyzed the Web, learned from it, and felt it wasn't the best choice for the future of XML-WS. We can't predict the future, but we can prepare for it. We all know XML will be there but how long will HTTP last? It might be kind of silly to think that HTTP will be wiped off the face of the Earth, but REST-WS advocates need to consider it a possibility. With SOAP's ability to bind to various underlying protocols, it can go protocol hopping or make use of future protocols. When you consider free XML-WS that are deployed to the developer community, a lot of times you feel REST would be much easier and it is. But when you sit down and actually think about where XML-WS will most likely be used, you will change your mind. Think about the complex architecture required for business XML-WS for a moment. Data Privacy and Data Integrity come to mind. Authentication, Authorization, Non-repudiation, Digital Signature, Time Stamping, Encryption and that long list of subjects starts coming into play. That's when technologies such as SAML and WS-Security used in conjunction with SOAP starts to make sense. When you think of a Service-Oriented Architecture (SOA), then you start thinking of a highly distributable XML-WS environment. This will require support for synchronous and asynchronous operations that SOAP is very capable of handling. The scenario of peer-to-peer, client-server, server-to-server, and other systems seem very likely for XML-WS. Do you still want to use HTTP? Okay, so you changed your mind and say REST-WS is better for RPC. That's a great idea, let's use REST-WS for RPC and use SOAP for Messaging. No, SOAP can handle both and SOAP-WS is much more powerful.

So now we have XML and SOAP as part of our definition for XML-WS, is there anything else?
Yes, there must be a way to describe how consumers connect to your XML-WS. WSDL looks like a good choice. There are a lot of tools by major vendors that support it to do such things as automatically generate it from your XML-WS or grab an existing WSDL file from another XML-WS and generate code. There has been some criticism about WSDL and SOAP that can be found around the Web in mailing lists, blogs, and articles. Guys, calm down. The standards are still being developed. Your criticism is pointless if you don't send it to the W3C. It's funny how the release of new technology always prompts some kind of technology war. Developers start taking sides, start forming new technologies, and the flame wars begin. Usually within days of the beta or draft, some developers just fork their own solutions. Standards take time so developers need to be patient. Although I must say, it is hard to resist rolling your own solution when you find that first flaw in a new technology. Instant fame, a loyal group of followers, and then you get slashdotted. Anyways, where was I? Ah yes, the definition of XML-WS. Now we have, XML, SOAP, and WSDL. That's enough for me. UDDI doesn't strike me as a necessity but can be useful in some scenarios such as when the number of XML-WS you created is getting out of hand. It might then be wise to publish your services in a UDDI registry and have some kind of interface that gives you the details of your services. Another use for UDDI that I am looking into is for backup purposes. For example, you have a critical service that must always be up so you host it on different servers. If you try to use the service and the connection fails (the server responded with a SOAP Fault or some kind of error), then your client automatically queries your UDDI Registry for backup services and automatically connects. This is a nice feature to be able to have and is very easily done through UDDI and Dynamic Invocation APIs. As for clients that query registries, negotiate a contract, and dynamically invoke third parties that you have no prior agreement with, I don't think so. Maybe for free services, but if I get a bill in the mail that is another story. Expect UDDI to be used privately or with business partners after contracts have been negotiated. Google and recommendations will still be my main source for finding services.

In conclusion, a Web Service is any service on the Web. An XML Web Service is a service that utilizes XML and other standards to define an efficient way to describe the Web Service and talk to the Web Service. From this definition, I concluded that XML, SOAP, and WSDL are the only requirements to make this work efficiently. The underlying protocol that SOAP is sent across can be chosen based on the needs of the Service Provider and Consumer. Depending on the complexity of your XML-WS environment, UDDI and other Web Services technologies can be used as necessary.

A final word of advice, be patient with XML-WS. Get comfortable with XML and look into standards supported by well-known standards bodies. The complexity of WSDL and SOAP is usually hidden by APIs and development tools. This is nice, but it doesn't mean you should ignore the technical details. Learn their intricacies so you can use them to their full potential, especially SOAP. Last but not least, move with the crowd. SOAP-WS is what all major vendors are basing their XML-WS initiatives on.

Posted by Nasseam Elkarra at December 24, 2002 10:44 PM