Hail A Web Service! Date:   Thursday , March 04, 2010 DO A GOOGLE SEARCH ON THE TERM “WEB Services” and you’ll come up with nearly three million hits—and literally thousands of individual references and resources—on the topic. Clearly, interest in Web Services is at an all-time high. Yet, despite this abundance of information, the concept of Web Services remains unclear to many business professionals. So, to help provide some clarity, consider the following “off line” analogy of a universal service known to all of us: the taxi. In any major city, step on to the curb, put your hand up in the air and everyone knows that you are trying to get a taxi. When a taxi stops to pick you up, you and the taxi driver will then engage in a simple, well-understood transaction. The business rules and interactions involved in finding, using and paying for taxicab services are very well defined (in most places, at least). There is generally no need to explain the mechanics of the activity of moving people from the pickup point to the destination, nor the associated financial transaction. The world of taxi services is comparable to the world of Web Services in several important ways: discovery, protocols, entry points, authentication, payment and service availability. Discovery The existence of taxi services in any city is given. Taxis are usually labeled “TAXI” and marked in a distinctive yellow. They are typically listed in the local phone directory, similar to the Universal Description Discovery and Integration (UDDI) registry in the Web Services world so that interested outside parties can find a particular service. UDDI enables a business to •describe its business and its services, •discover other businesses that offer desired services, and •integrate its services and products with the services of those other businesses. Protocols In the taxi example, the business rules for the service are already understood. A passenger requires transport from point A to point B. The city’s previously defined addresses simplify the process of finding the beginning and ending destinations. In the Web Services world, the person using the taxi is the “Service Requester” and the taxi driver is the “Service Provider.” The actual service provided will vary. Entry Points There are multiple ways to access a taxi service. For example, one can hail a cab on the street, at designated taxi stops (hotels, public transport stops, etc.), or via a telephone call to the dispatcher. Looking up a limousine service in a phone book is similar to looking up a service provider in the UDDI. Knowing the network address where service is available is equivalent to just going to the corner of the street where the cabs are lined up. Taxi cabs are usually summoned in a loosely coupled manner (via radio, cell phone, cab company routing system) and are spread across the network of roads and highways. Similarly, Web Services can be spread across many actual machines operating on various internal and external networks. Authentication The taxi/car service also offers a similar analogy for validation and authentication. Validation or identification is not required in all cases; street-side pickup is anonymous. But a car service may require customers to call in requests. In those cases, a name is provided for identifying the requesting individual. An additional level might be some form of recognition for accessing a private car/limousine service where one has an existing account and requires personal recognition for a small service or some other standard form of ID for larger car services. Similarly, though Web Services do not require validation, they may incorporate validation and authentication in private applications. This could be as simple as a user name and password, or a client certificate. Payment Taxi fares are metered and/or predefined but can also be negotiated for very long trips. Payments are usually made in cash, but may involve the use of credit/debit cards or company accounts. Web Services can similarly be billed on a per-transaction, flat-fee or other basis. Payments can be arranged electronically (as a credit-card transaction) or at an account level. Service Availability or Threading After the cab delivers the passenger, it is once again available for service. Generally, cab companies maintain a fleet of several taxies for servicing multiple customers simultaneously. Similarly, it's possible to make multiple Web Services requests, unless the services have been deliberately designed as single threaded. Generally, however, Web Services are multi-threaded so many customers and requests can be served simultaneously. Web Services Definitions and Component Descriptions Web Services as defined by the World Wide Consortium (W3C): “There are a number of varied and often inconsistent uses of the term “Web Services.” At its core, a Web Service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web Service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols.” The following illustration highlights the off line taxi example as it relates to the typical Web Services architecture components. The following standards are central to Web Services: XML (eXtensible Markup Language) - A markup language for documents containing structured information. 3 XML is equivalent to English or, in the case of the taxi example, whatever language is spoken by the driver and passenger. SOAP (Simple Object Access Protocol) defines an XML messaging protocol for basic service interoperability. SOAP is equivalent to general etiquette for requesting a service, such as in CB radio lingo (i.e. 10-4 for ending transmission) or “cultr” for “see you later” in Instant Messaging speak. WSDL (Web Services Description Language) defines a grammar for describing and requesting a service. WSDL is equivalent to having a tourist guidebook that tells a person how to request a cab service. An extract from Building Web Services with Java provides an excellent technical definition/view on Web Services: “..there is broad agreement on what a Web service might be, but no single agreed-upon definition. Many developers will claim they cannot define what a Web service is, but they know one when they see one. “A Web service is a platform and implementation independent software component that can be: • Described using service description language • Published to a registry of services • Discovered through a standard mechanism (at runtime or design time) • Invoked through a declared API, usually over a network • Composed with other services “One important point is that a Web service need not necessarily exist on the World Wide Web. A Web service can live anywhere on the network, Inter- or intranet; . . . Web services have little to do with the browser-centric, HTML-focused World Wide Web. Sometimes, the names we choose in the IT industry don't make a lot of sense; they simply take on a life of their own.” Getting Comfortable with Web Services The cab service analogy highlights a universally recognized service. The key differentiator between taxis and Web Services is our training and familiarity with the required elements for service delivery. Taxis allow us not to worry about Data Type Definitions (DTDs) and Application Programming Interfaces (APIs); instead we simply use common concepts like addresses, money, and roadways. In the simplest form, the cabbie understands the language we speak; a Web Service understands the XML the requestor “speaks.” Remember that using a Web Service is conceptually as straightforward as hailing a cab. The more difficult challenge of creating and/or consuming a new service (Web or otherwise) comes from the unfamiliarity with the rules of engagement. But as Web Services standards and its use evolves, the more refined and reliable they become, and the more business customers should become comfortable calling on them without worrying about the technical aspects of how they inter-operate. Just as anyone who needs fast transportation in a city has to learn how to call a cab without worrying about the workings of the dispatch system, so too must business users learn to confidently “hail” Web Services without having to understand all of the standards and protocols at work “under the hood.” Otherwise, they risk being left stranded at the corner. Velan Thillairajah is the founder and CEO of EAI Technologies (www.eaiti.com). He has worked with or for PriceWaterhouseCoopers, Hewlett-Packard, Network Solutions, AOL, Verizon, BMC, VeriSign, KPMG and Agilent. He studied at Cornell University, followed by an MBA at the University of Rochester's Simon School of Business, where he was featured in Forbes 'Best and Brightest.'