The recent smash hit, Web Services, has played from coast to coast on the business “Hypo-Tronic Gizmo” for several years now. One might even suggest that if DJ-Bob had a weekly Top 10 countdown featuring the most prolific debuts in business-hype history, Web Services would be at or near the top (clouds are also floating fairly high these days). This Hypo-Tronic Gizmo (or HG device) is extremely unique because it plays only what the listener wishes to hear. For top-level executives the device delivers a simple, “Cha-Ching”. For mid-level managers it renders a more subtle, “Here we go again”, reprise. But, for those in the trenches – the technical implementers and end users – it screams, “Fire in the hole!” Yet, surprisingly, to those who have lived through the budget-blowing and non-committing trends of the past, Web Services has actually delivered a Certified Platinum hit that many advocates had hoped it would achieve.
The term “Web Services” is used to describe a standardized method for taking applications that have been developed for the web and integrating them using the components that make up the “Service”. These components are, namely, XML (metadata or “tags” identifying the data), SOAP (transmission protocol), WSDL (describes the service), and UDDI (listing of available services). Web Services generally hunker-down inside business logic – they are executed individually as one process that is part of a larger workflow. Where applications are generally equipped with a graphical user interface (GUI), Web Services often do not have (or require) such a GUI…they just simply execute. A service is therefore justified by having a need that is repetitive.
Take this as an example: On a whim, I purchased the board game “Mystery Date” for my two daughters for Valentine’s Day. As a kid, I remember the TV commercials where giggly girls would sit around a table and laugh hysterically as they would open the door to “their” mystery date. Well, a word that rhymes with “game” is “lame” and that’s exactly the reaction I received from my daughters…but that’s not my point. The point is, when I went to Amazon.com to make that now-dreaded purchase, I was asked to provide specific information. One necessary piece of data was my local zip code. This was not only important for ensuring an on-time delivery, but also to calculate the actual shipping costs. I will gladly bet that game, that Amazon has a Web Service running behind the scenes, to: (1) import my zip code, (2) send it to the parcel carrier via the carrier’s Web Service, and (3) receive-back the shipping total for my verification and acceptance. Rather than Amazon writing a program to determine the shipping costs (one that would certainly require ongoing maintenance to ensure accuracy), the most efficient solution is to employ a Web Service made available by the carrier but “subscribed-to” by Amazon.
The application for Web Services is limitless. Through a service, any web application can be easily integrated with any other web application. To do this, an organization will initiate the procedure by producing a service that is designed to simplify a repetitive integration process. Those wishing to interface with that service need only to simply subscribe. What started as an application for the web has now expanded to non-web integrations. For example, Web Services can be implemented inside an organization where data must be integrated between two internal but disparate applications. Also, two companies exchanging data outside a web application could use a Web Service to integrate data between their applications. The purpose might still be a need to verify shipping costs through a Web Service with a carrier, but instead of being driven by user input (GUI) it may be driven by a non-user source (EDI). Thus, Web Services provide opportunities that are reaching all applications and are independent of platform and database.
Oh…and did I mention my daughter’s “mystery date”? Yes…none other than the inventor of the Hypo-Tronic Gizmo. “Cha-Ching!”