Web services is a term that seems to be getting used quite a lot lately, but is it just more hype in an IT industry that has been battered by it's own inability to live up to it's own hype, or does web services actually have some real substance
New technologies come and go on the Internet, each promising to do new things, in new and more exciting ways. Many do not deliver on these heightened expectations. Web services promises to be different, as it's advocates promise an evolution of existing technologies rather than a complete overhaul of them.
In essence, web services hopes to integrate many different Internet applications that have been written over several different software platforms, into a new kind of Internet that is software-driven, rather than the current text-driven Internet. This promises to be an Internet more focused on data rather than simple HTML text pages, and how this data is processed and used by businesses and individuals alike.
The glue that holds this new vision together is XML (eXtensible Mark-up Language), which has the ability to become the standard technology that allows data to be transported, understood and modified by all of these different technologies, such as Microsoft's .NET, J2EE (Java 2 Enterprise Edition), CORBA (Common Object Request Broker Architecture) and many other server-side database management systems.
In a typical web service application, a web service interface receives a standard piece of XML data and transforms this data into a format understood by the particular server-side software environment, and if required, returns a reply message. Web services control not only the data itself but also how that data is processed and mapped into and out off the various software applications.
The real beauty of the web services concept is that it is all based on open standard technologies. All web services should be self-contained and self-describing and be capable of being packaged up and utilized over existing standard technologies.
This modular approach allows the client to pick and choose the particular web service that is required, and to only purchase what is specifically necessary. In theory, cost is reduced with such a tailored approach being implemented.
For web application developers, this allows even the smallest set-up to compete with larger developers, so long as they have developed a particular tool that people want to use, they will be able to package this as a web service and sell it on. This may even be a component part of a larger application, but so long as it has enough value for clients, developers can make some money from it's use.
The central standard behind web services is XML, the development of which is under the control of the W3C (the World Wide Web Consortium). On top of this, there are many XML based technologies, in fact so many that the sudden bombardment of technical jargon may make you feel dizzy! Here is a necessarily brief description of the main technologies involved:
For the moment, it is important that you understand that web services are concerned with program-to-program communications, rather than people-to-program. A good way of thinking of it is as a toolbox of technologies that allows this communication to take place as fluently as possible.
As XML is the central technology behind all of the potential promise of web services, it is worth singling it out for more attention. XML was developed by the W3C to overcome the limitations of HTML (Hyper Text Mark-up Language), with a special emphases on providing the ability to enable dynamic content generation, i.e. content that can change, unlike HTML content which is static and never changes.
XML is a mark-up language that is used for creating mark-up languages. Confused Think of it this way: XML is, in may ways, the trunk of the mark-up language tree; HTML is simply one of many possible branches. XML allows the user to defined their own, tailored branch of 'tags', the elements that are used in HTML and all other mark-up languages:
<tag>This is the data that the tag defines</tag>
With XML, more meaningful tags can be introduced, for example, an online store may have tags defining their products such as:
<boot> <colour>Brown</colour> <amount>100</amount> <price>â‚¬25.00</price> </boot>
Here these tags make more sense, but with the possibility of so many different combinations being developed, you would be forgiven for thinking that compatibility issues will arise. After all, what if I want my XML to be compatible with that of the web service that I am using, and vice-versa
This is were XML schemas come in to constrain this flexibility. An XML schema is an XML document that defines the content, elements and structure that is allowed in an XML document. If two parties share the same schema, they can be sure that they understand the same element tags in the same way. It is this precise feature of XML that allows web services to operate effectively.
The next generation of the Internet is likely to be more concerned about data, rather than text. XML is to data what HTML is to text. It is envisioned that the next generation will address current weaknesses in the Internet, such as the inability to search for exact matches of text strings over the Internet.
It is impossible, however, to ignore the success and popularity of the World Wide Web as it stands today. Completely replacing existing technology is impractical, maybe even unfeasible. Therefore, the next generation of the Internet will be an evolution of existing technologies, which will be used in a new way in order to promote software-to-software communications.
Although there is a lot of hype currently surrounding web services, in reality it may be several years before they are fully implemented. In the meantime, many businesses are testing web services at an internal level behind the safety of their firewalls. When the time comes to deploy their web services beyond their firewalls, it should not be a difficult task to turn them around to be externally facing.
For the moment, concentrating on evaluating web services potential, while also studying the various technologies behind them should be a sufficient undertaking. In this way, if web services do live up to the hype, you will be well placed to take full advantage of the situation.