A Dynamic e-Business Application Using Web Services
The World Wide Web has brought about a revolutionary change in the way businesses are conducted on the Web. Although the initial focus was primarily on B2C interactions, it is now evident that for businesses to grow and succeed, organizations and companies not only need to participate in trading partnerships but those beyond need to work in close cooperation. B2B integration is about coordinating activities by transparently sharing information between organizations to streamline and automate business processes. Companies from across a variety of industries are embracing B2Bi, realizing the enormous competitive advantage it provides through faster time to market, reduced cycle times, increased customer service—in short, better quality of service.
What Is a Web Service?
Today, with virtually every computer and potentially every application connected to a single network, there are increased opportunities for establishing business relationships dynamically. To achieve this, business transactions must happen in real time and also use open Internet standards to integrate these disparate islands of applications. Major IT players, vendors, service providers, and consumers of IT services have now come together to agree on a common standard—Web Services. Web services based on open standards acts as a facade to provide a uniform and widely accessible dynamic interface to expose business operations. Figure 1 illustrates how a typical Web service works.
Figure 1: Workings of a typical Web Service
XML and HTTP form the core of Web service standards. Web service technology stacks, composed of SOAP, WSDL, and UDDI are the basic building blocks that provide a solid infrastructure, enabling systems to interoperate with relative ease and reduced cost of integration. Refer to the References section for more information on these technologies.
Web services, based on a service-oriented architecture (SOA), typically involve three entities: the service provider, the service broker, and the service requestor. Figure 2 shows the interaction of components that make up the SOA.
Figure 2: The Service-oriented architecture
In a typical Web services scenario, a service provider publishes its services in a standard format on a global business registry (the service broker) that is accessible over the Web. A service requestor can be an application on a company's intranet, a partner application on the Internet, or an application on an end-user device. It searches the business registry to discover the service and its associated endpoints. It then binds with the service provider and invokes a method on the Web service using the SOAP protocol. The method invocation is sent as an XML document embedded in an HTTP request. The service provider's Web server receives the HTTP request and passes it to the Web service engine, which in turn invokes an appropriate method on the backend system. The result of the method invocation (formatted as an XML document) is embedded within an HTTP response and returned to the service requestor. The actual object implementing business logics on the backend system may be a Java class, an EJB, a .NET component, or any legacy application.
Role of Web Services in Enterprise Architecture
Most enterprise application architectures are based on component technologies such as COM/DCOM, J2EE, and CORBA. Traditional middleware platforms based on these technologies have matured and have been well proven to implement key enterprise requirements such as distributed transaction integrity, workflow automation, security, scalability, and so forth.
However there are some downsides to it. One major drawback of these middleware architectures is their inability to interoperate with each other. This is primarily due to the binary incompatibility between the object models and proprietary protocols used for information exchange. For instance, a COM object running on a Microsoft platform cannot quite easily interact with a Java component or a CORBA object. Even if it does, the connected components are highly dependent on each other, resulting in tight coupling between them. Yet another problem associated with component technologies is firewall penetration. Object protocols such as DCOM, RMI, and IIOP operate using an arbitrary set of ports on the server, thereby opening up potential security holes. Web administrators are wary of opening ports other than 80 for security reasons.
Web services offers a perfect solution by providing a uniform interface to access business functions using protocols such as SOAP and XML-RPC. These protocols that work with XMLs as the payload over the ubiquitous HTTP, circumvent both the problems mentioned above.
Although the W3C SOAP standard specifies the bare minimum, several organizations have come up with recommendations such as WS-security, Business Transaction Protocol for WS-transactions, WSFL for workflow, and so on to meet other important enterprise requirements. So, as of now, Web services cannot be considered a replacement for component technologies, but rather complement them.
Benefits of Web Services
The key benefit of Web services is that they allow previously incompatible applications to interoperate on the Web regardless of language, platform, and operating systems, thereby creating new e-business opportunities. This makes it easy for companies to adapt to changing business relationships and develop new e-partnerships. Unlike integration using EDI, it now will be possible to unilaterally create a Web service without prior agreement from business partners.
Take the case of the travel industry—airlines, hotel chains, tour operators, insurance, and car-rental companies are gradually packaging their services to create turnkey products. For example, when a travel agent sells a ticket, he can dynamically choose among different airlines, locate a suitable travel insurance, book the client to a hotel, and arrange for a car rental service, all in a single operation. This dynamic assembly of products and services gives the client real added value and provides enterprises with marketing advantagesÿlower costs for acquiring clients, customer satisfaction, customer retention, and so forth.
Similarly, in a manufacturing company, activities such as customer/product enquiry, order processing, obtaining part/quotes information from suppliers, and the like had been traditionally done using telephone, faxes, e-mails, or Web pages. These activities can now be performed dynamically with little or no human intervention by exposing functions using Web services, thereby automating the entire work flow process. One can cite numerous such instances where Web services can be used.
Web services architecture is independent of the connected application components in an enterprise or the underlying technology used. Consequently, it allows users to focus more on the functional aspects and evolving strategies to maximize profits and minimize risks. It has earned widespread acceptance due to the fact that it does not effect existing business components and does not require users to re-write their applications, thereby protecting customer investments—a clear winner from an ROI perspective.
Web servicess represents the next generation of e-business applications. Its architecture offers a loosely coupled model for interaction between systems and removes the stumbling blocks associated with traditional e-business. The next section describes a practical example of using Web services.