ave you heard the term Web Services and wondered what all the fuzz is all about? The marketing machine at Microsoft announced .NET as the next new "new thing," and Sun's initiative, called Sun ONE aims at the same market space. Logically, I asked myself if the marketing hype contains any meat to the bone?

My curiosity is two fold: as a Developer and as a technical consumer. On top of the research I have done, I attended a full day technical Web Services Briefing seminar sponsored by IBM. The presenters, Arthur Ryman and Doug Tidwell, gave a high level architectural overview of what Web Services are. As the day progressed, they moved into more technical details and implementation examples of Web Services, at the same time showcasing IBM tools to build those services.

This writing won't go into the implementation details and I have tried to stay away from too much technical jargon, as it won't be beneficial unless you are a developer. But if you are a developer, you should already know most of it or you can find about it all over the place, of course if you like to discuss further, email me.

What do I get if I read this article?
At the end of the read, you should have a high level overview (executive summary as some call it) of what Web Services are, why they exist and if talking about it in your organization makes sense. Also, you will gain some knowledge about Web Services and you will a more pragmatic individual who will be able to understand what the fuzz is really all about.

The real thing
Web Services are the real thing, but, if we get carried away with the all the marketing hoopla we may get lost and we may not end up understanding what it all means.

Note that Web Services are not about any operating system (like Microsoft's XP) nor has anything to do with proprietary technology (like Sun's Java). Web Services intend to cover an existing gap, which prevents 2 (or more) completely different platforms to interact with each other (Interaction here, is meant in the computing sense). In a nutshell Web Services:

• promise to make applications interact with other applications without human aid.
  
• Web Services allow for interoperability between companies.
  
• allows for 2, or more, different types of computing environments to exchange information.
  
• are all about XML.
  

What is a Web Service?
A Web Service is all about XML and is a process of 2 different computers to exchange information regardless of geographical location or computing platform. But, read on, there is a bit more about it than meets the eye.

There is much information to be digested about Web Services and like any other new technology it's full of new acronyms: XML, UDDI, SOAP, WSDL UDDI4J, et all. These acronyms define different protocols or implementation technologies and due to limited space, or attention spans, I'm only going to discuss the following 3: XML, SOAP, UDDI.

1. XML
XML stands for eXtensible Mark-up Language and is a descendant generation of SGML. XML is somewhat similar to HTML (Another descendant of SGML). Tags rule both, XML and HTML. In HTML we have predefined standardized tags that are used to format text and any HTML client must adhere to these standards tags in order to correctly render the desired effect.

For example, in HTML, the tag <b> together with </b> makes any text enclosed between them to be displayed bold.

I mentioned that tags, similar to HTML, rule XML. Though, the power of XML comes from the flexibility to make up the tags as you go. Hence, I can define a brand new set of tags to enclose some data, and be a totally valid XML file. For example <name>Jose Sandoval</name> is a valid XML tag. So there is no standard definition of XML tags, I can create them, as I need them.

Why is XML the heart of web services?
We need to go back to one of the early definitions I gave: Web Services allows different types computing environments to exchange information.

The exchange of information is the key to web services and this is accomplished through XML and XML only. XML files are defined with tags enclosing the data to be transferred between two different applications. Think of it as the request being the Input of an action to be taken, and the response, another XML file, returned as the Output. The XML files that are passed around follow rules that are pre-defined between the services. I mean, that each service expecting an XML file needs to know what the file is used for.

So the heart of Web Services is XML. Again, XML is used to exchange information from one system to another in a standard way using predefined protocols, like SOAP which is discussed in the next section.

I said that XML has no predefined tags, as in HTML. But, there is some sort of structure to follow between the requestor and respondent. Here is where www.w3.org comes in. The W3 Consortium works together with companies to put standards in place so that all the different companies involved in the particular industry follow the same protocols to make the whole architecture work. Verbatim from W3's web site: The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential as a forum for information, commerce, communication, and collective understanding.

2. SOAP.
SOAP stands for Simple Object Access Protocol and it is a lightweight protocol used to interchange XML files between applications. The protocol defines the metaphor of an envelope: a wrapper XML structure which encloses the XML (data) file definition together with the action to be taken towards this data (more or less a Data Structure); there is a request envelope and response envelope.

SOAP defines the way envelopes are sent back and forth between services. The request envelope is the input of the process and the response envelope is the result of the service's action taken for the request message (This is grossly simplified here).

For example, a message or XML file sent from service A to service B is composed of tags and data that each service (A and B) knows what to do with. If B doesn't know about A's XML format and a request is made, sure, the data is exchanged between the services, but nothing happens. Each service has to agree at some point that this exchange will take place so that service A and service B know what the XML definition means and what needs to happen when the request is received.

Imagine sending your credit card number to 3 different merchants who accept credit cards as a form of payment when you buy something they offer. The companies will receive your number, but if it is not accompanied by a "buy" action and a specific "item" to buy, then nothing happens (At least we hope nothing is charged to the card). So, in a similar manner web services need to know about each other and certain details need to be known so they can interact. There needs to be an understanding that an exchange of data will take place between them.

I must point out the coupling of the 2 services I have used above; A and B need to know about each other's existence and hence they need to know the format of the XML file. This is not a limitation at all if you are thinking that this scenario is too restrictive in terms of its use (Only Service A and Service B can use each other). In this case, the builder of both services is in control of both computing environments, at least in terms of development of the software to be used, so it's fine that the coupling is present, we can deal with it. This coupling was a detail of Web Services I didn't like too much, before I understood the Registry component of the architecture and here is where UDDI comes into play. I mean, how exiting is it to connect two computers in the same office?

3. UDDI
We know that web services can be implemented between 2 companies (or departments inside a company). What about the more complex scenario where 2 or more web services know nothing about each other, yet they need to interact to solve a problem?

UDDI stand for Universal Description, Discovery and Integration and it allows for Web Services to be discovered dynamically at run time. In this scenario any number of services available do not need to know any details about each other, unless you request more information about them.

The question is: how do you know where to find these services? And the answer comes from big software companies like IBM and Microsoft, who are telling us that we (developers or Web Service providers) can register services with them and users will go to these registries and use the solution for a fee (Kind of like if you build it, they will come, which is yet to be seen).

This is what a "Web Service Registry" will be: a central location, a service market, if you will, of Web Services. Note that these registries will not host the service. So it is not the current ASP (Application Service Provider) architecture of many web sites out there. They will only be a pointer to where the real service is located. Think of these registries as the yellow pages for companies looking for specific Services to solve complex problems.

So then, service A can dynamically find out about any number of services advertised in the registries at run time using, of course, UDDI.

My personal comment here: I like the idea of a registry where services are found. I don't think is a good idea to have a monopoly of registries doing the service (I.e. two of the biggest software companies). I hardly think is beneficial to have only 2 mayor software vendors being the authority on web services. Anyway, there are issues with a multitude of registries floating all around as well and all questions are not answered (We haven't even asked the questions yet), but, so far we have no problem with millions of web sites scattered all over the place, this being sometimes, a good thing and a bad thing.

UDDI is part of the implementation details and allows applications to find out dynamically about what a web service is and is not (At run time). We can query the registry for information about the service and use it if it is what we are looking for, if it's not, then we keep looking for the appropriate service in the same registry server or we can go try our luck at another existing registry provider. Once a service is found, SOAP takes over and we get a problem solved remotely, regardless of what computing system is being used.

There is much more that can be said about UDDI, but I would have to get into the coding details of it all. Suffice to say that UDDI can also be used to find about specific requirements the service must meet in order to be used all across. For example, if company A belongs to professional group that requires certain certifications to use a service (or contractor) then, this information can be obtained dynamically through UDDI. I.e. I can dynamically find out if any company providing the service I'm looking for has the required certification to provide the service.

Smart agents, not again? The following may sound as wishful thinking, but since I'm the writer, here it comes. You can think of Web Services as smart agents that are distributed all across the planet (and outside) in machines that are connected to the Internet. Remember "smart agents?" The term was made famous around the time when the Internet was popularized. The promise of computers automating boring informational tasks and we could leave a smart agent doing our bidding for us while we slept at night. We are not quite there yet, but Web Services allowing for applications exchanging information without human interaction, are as close as we're going to get, at least for now.

The benefits
By implementing Web Services, we now have a way to communicate between two platforms, two different machines, or two different programs that could never do so before, all thanks to XML and all the other standards that are being put in place.

XML is platform independent and SOAP is used as the main protocol to exchange these XML files. The service does not care if the request came from a UNIX server or that the processor of the request is a Mainframe computer. It makes no difference. A Web Service host understands what to do, as long the XML file is transferred using SOAP and a protocol both machines/services implement.

The most commonly used transfer protocol is HTTP (Hyper Text Transfer Protocla and is preferred for it's simplicity), so that the request from service A to service B is transferred as a web page request and the response from B to A, is an also HTTP response.

Issues of security come to mind, but do not despair. All of these transactions (including parts or the whole XML file) can be encrypted and can make use of standard encryption practices: PKE and HTTPS.

Better than sliced bread?
Are web services better than sliced bread? The answer depends of what kind of bread and how big of a slice you need.
On one side of the coin, if your company's incompatible platforms require the exchange of information for regular operations or for new defined challenges, then yes, Web Services can be a very effective tool. On the other side, Web Services can be misused, and will be misused making for bloated solutions that will come at a great price in 7manpower and dollar cost of unnecessary technology.

The key to a successful deployment of Web Services is to understand what the problem to solve is. Computers, since their invention, without a well-defined problem to solve, are nothing more than glorified screen savers or really fast calculators and perhaps when using Web Services in the wrong way they will become even more powerful calculators, but this time scattered all across the net land.

Imagine a web service to add a + b, a very effective way to add two numbers, but way over killed (In this example a, b belong to N, and a, b < 5 and N is the natural numbers).

Where is the industry in terms of Web Services?
Web Services are in its infancy. There are companies solving real problems with the aid of Web Services, but they are not many out there yet. These companies are early adopters and are mostly solving internal problems in Intranet settings.

The short and long term strategy for corporations
The next step for Corporation is to take advantage of the symbiotic relationships they have established with other companies to bring more compelling information products to consumers. Corporations need to also come up with new ways of operations to take advantage of all the data/information available.

One of the issues to make all this collaboration possible has always been that different companies usually have different computing environments and it is really expensive to make application work together. It has been done in the past and it's being currently done, but it is really, really expensive. Try to find a Java developer with professional Cobol experience. They are out there but the number is limited, and hence very well paid (Personally, I have not even seen one line of Cobol before, so I am not one of those consultants, in case you were wondering).

As Web Services start to mature and start to come out of the proof of concept state, they will become part of daily operations and they will go out in the Internet world solving really interesting problems.

The future
I'll give you two views of the future: a bright future and a not so bright future.

Bright future
Re-usable software is here to stay. Web Service integrators can re-use many Services to come up with gigantic Web Services that touch on many industries and solve unsolvable problems of the past, present and future. All that is needed is the integration of a set of Services to create new ones.

This is the vision of future computing. Web Services are P2P (Peer to Peer) in a massive scale. They won't be used to move MP3s from computer to computer; Web Services will move bits of information and new information products from enterprise to enterprise.

Companies have seen the light and are pushing towards this utopian view of massive servers connected to solve computing problems without human interaction. A powerful set of smart agents will be borne. The next generation of the Web will begin. The Web will finally become profitable.

Web services will be smart enough, that they will search on the registries and build themselves up without human interaction. AI (Artificial Intelligence) will actually become more popular as these massive software agents will gather around the registries exchanging knowledge, much like we do at chat rooms and IRCs. Computer science will advance in leaps and bounds as we learn to analyze and begin to understand how to actually take advantage of the problems these Web Service Agents will be solving autonomously.

The idea of exchanging data between two different computing platforms is not new, but it is until now that we have proper infrastructures and computing power to make such architectures actually work.

It will become clear, that companies that don't implement or at least explore the idea of web services will be left behind. How will they stay competitive if the cost of development of one single application surpasses the cost of using a well-defined, thoroughly tested massive smart Web Service?

Not so bright future
Web services are offered as the silver bullet solution and many companies will use them where they should not have. Millions of dollars will be lost in implementation cost and due to these failures the industry will not mature and we will have a Web Services bust. The industry will not mature and corporations that should use Web Services will be too skeptical of the benefits after seeing so many others who have tried to implement them and failed.

Web Services will be nothing more than marketing promises of vapourware by big software and hardware vendors who are pushing proprietary technologies or operating systems, and the realization of the next Web generation will not happen.

Web Services will raise too many privacy issues once unscrupulous service integrator span information bits across many industries and will become part of government regulations that will leave the utopian view of information exchange crumbling to pieces.

Some really smart kid, somewhere out there, will come up with an application or a new way of doing things where the rules are re-invented an leaves CTOs and VPs, who are paid to come up with these visions, turning heads wondering what happened and why their R&D groups didn't come up with it in the first place. Think of the recording industry here, where their tools and means have become the hiring high price lawyers and government lobbing to intimidate whoever is trying to make a profit out of their industries - I mean, someone should make a profit, they dropped the ball, and don't know how to pick it up.

Ok, no more predictions
Ok, I'll stop with the predictions. I think I made my point. I only meant to demonstrate that even though, Web Services are here to stay and are the real thing, they can be misused and if they are misused the whole revolution that everyone is talking about may not happen.

I, for one, am optimistic of the outlook of Web Services. It is not hard to imagine the scenario I described, self-building Web Services who find each other, since it is possible that in the next 5 to 10 years such technologies could exist.

And if Arthur and Doug are right when they said we (About 120 of us who attended the seminar) were all pioneers because we even knew about these technologies, then I guess I am at the right place and time. Of course I've heard this pioneer business before (maybe I'm getting better at pioneering things and nobody told me about it).

This far
If you made it this far, I hope that some questions were answered about Web Services and that reading this article was worth your time. Let me know if any of these happened.