Johannesburg, 29 Nov 2007
We`ve all heard the hype around Web services:
* "You will never have to maintain an application ever again";
* "Allow your application to work, even if some parts of it are offline";
* "Speak to any other computer system";
* "Keep all your data secure"; and
* "Cure dandruff".
OK, I am kidding about the last one, but Web services have been sold as the cure to every development problem.
Unfortunately, there is no silver bullet solution. So let`s try to understand what a Web service is and how it can help your systems communicate more effectively. I will try to describe what Web services are, followed by some situations where I have used Web services in architectural efforts.
What is a Web service? It is a block of application logic (think of getting a stock price quote or performing a forex trade) that is accessible through the Internet in a standard way.
Web services are accessible at some level to almost all programming languages and environments. Just as some Web sites are secured by a certificate, Web services can also be secured in the same way. (Note: Not all Web services are secured like this; some send their information as clear text over the Internet. Providers of Web services have to take specific precautions to prevent unauthorised access to data.)
What is a Web service not? A Web service is not a plug-and-play out-of-the-box solution. Someone still has to design it, write the code for it and test it; both in isolation and as part of one or more larger solutions. The use of Web services as a central part of your application architecture does add some overhead to development, and demands extra skills from your technical staff.
Where would you use Web services? Some examples: I currently work on a transaction capture system for a large financial institution. This system also communicates to other third-party systems that retrieve data from credit bureaus, perform analysis on deals, and more. These interfaces to other companies` systems happen primarily through Web services. This is because it is useful to have the interface as clearly defined as with a Web service.
When you communicate between systems, you need a common vocabulary, and that is supplied through the use of XML schemas. Our typical approach for a Web service that performs a large chunk of processing is a service with few interfaces, and the message rather encoded in the XML input and output. Our Web services typically have hundreds or even thousands of data items being passed around; the interface for a stock quote might look quite different.
Our system can also accept some input from a Web site. Rather than tie the Web site to our system, we published a Web service that the Web site could send a block of XML to, that contained the initial information for a transaction. In this example, however, we ran into a common difficulty: skills shortage. The maintainers of the Web site did not have knowledge of XML or Web services, and we then had to write a component for them that they could use to invoke the Web service, and finally we had to take over maintenance of that portion of the Web site.
From these two examples you can see the benefits of Web services:
* They are reliable;
* They are well defined blocks of application logic;
* They are ideal for sharing among different systems; and
* They are effective for communicating across companies, where you do not control both sides of the transaction or lack access to the resource from the other company.
Some drawbacks include the lack of skills, and while you can define the interface explicitly, there are inevitably teething problems with any new cross-business Web service deployment. As an architectural consideration, always ensure you audit trail the transactions in detail. Where you invoke a Web service, store a clean, unadulterated copy of the input and output data separate from the processed versions of the data. Do this specifically for debugging and traceability after the fact.
That little nugget has saved me hours of debugging, and hopefully will do the same for you or your technical staff.
By Joon du Randt, technical team leader at DVT
Share