Wouldn't it be nice if my application could talk to your application across any of our communication links or devices. This is the goal of web services.

Wouldn't it be nice if my application would understand your application without any intervention. We could exchange messages without knowing about the content with our applications or agents making decisions based on our rules of engagement. The next time we look in our diaries we would have an evening meal arranged, at a convenient appropriate restaurant, at a mutually acceptable time.

This might read utopic but it is possible. It will need methods that correctly interpret the messages, it will need technologies that can reliably transport the messages and a database of personal preferences. This is how web service should work.

So what is this - web service?

It sounds like science fiction. If an American cannot talk to an Englishman without some difficulties (trunk, boot, lets table this agenda item, fanny, A4, Letter, etc., etc.) how can we expect applications to understand what is required?

Enter the computer scientist and the alphabet spaghetti.

We have XML and WSDL and SOAP and Java and COM and C++ and BPEL and .Net and WS-Coordination and UDDI and WS-Reliable Messaging and WS-Security -- to list just a few.

It really does look like science fiction but if these services can be weaved together, we could get the seamless interoperability that is promised.

So what do all of these things do and how will it help me?

Feature Story

XML Web Services Unplugged

Firstly we have Extensible Mark-up Language (XML). In its basic form XML is used as a self-defining data structure syntax. Using the language you can define each word (field), its content, its structure, etc. This can be used to create a plain-text message or a complex application interface. Even though XML is self defining it is still important that all parties interpret the XML data in the same way. This is done through agreed schemas.

To support the packaging and transfer of the XML-encoded messages, Simple Object Access Protocol (SOAP) was created and to describe the service, the Web Service Description Language (WSDL) was defined. So now we have the message, we have made it into an object and we can describe what service we need. At this point we have the Universal Description Discovery and Integration (UDDI) that specifies the web services directories so we can advertise the service on the web and find ones that we can use. This sorts out the basic plumbing.

We need to use languages like C, Java or Visual Basic to write the applications. When object-orientation is implemented then Java, C++ and COM are employed.

An area of development is business process orchestration that glues enterprise applications together allowing orders to be created by one company and automatically sent to another company which responds with an acknowledgement and logistics information which are used by the ordering company to adjust its inventory information. This is supported by Business Process Execution Language (BPEL), Web Services Coordination (WS-Coordination) and Web Services Reliable Messaging (WS-Reliable Messaging) to assure message transportation.

Most importantly the Web Services Security (WS-Security) must be implemented. If it is not done a message can be used in a malicious manner.

There is still much to do.

SOAP is very verbose and is text-based so is not performant, It is also incomplete and requires standards for security, transactions, guaranteed delivery and more. Many of the standards are just emerging so it will take some time before web services delivers become reality.