 | |||
|
Wednesday February 20 2002 UDDI Based Electronic Marketplaces Easier Integration with UDDI and WSDL Printer-friendly
HTML version eMarketplaces are designed to bring together businesses on the Web. Both buyers and sellers should be able to interact with each other inside an architecture that is easy to use and maintain. eMarketplace owners can implement several types of processes depending upon their target audience, operations, and finance models. The greatest benefits lie with cost reduction for all players and the ability to reach otherwise untapped business prospects. This article discusses how UDDI (Universal Description, Discovery and Integration) and WSDL (Web Services Description Language) work together to form the core architecture of the next generation e-commerce model. There are certain entities that are common to most e-commerce models of today, for example Buyers, Sellers, and Marketplaces. Buyers are the customers who want to make use of the products and services that sellers offer. Throughout this article, we will refer to buyers as eBuyers. Sellers have the role of supplying products and services; we will refer to them as eSuppliers. The marketplace is the virtual place that resides somewhere on the Internet, where eBuyers and eSuppliers can meet; we will call it an eMarketplace. There are various ways of bringing together buyers and sellers, which we will discuss shortly, but some common requirements of possible models have been identified. Let us see these common requirements first. Some common requirements of all e-commerce models 1. Content Management Whatever model you choose, an eMarketplace will be required to provide eBuyers with access to eSuppliers' data. For example eBuyers will need pricing and product information. In present day e-commerce, this is done through one of the following two methods:
2. Interoperability in E-Commerce No business (eSupplier) can serve the entire needs of its customers (eBuyers) alone. It has to coordinate with other eSuppliers. This is the famous Business-to-Business (B2B) concept. An eMarketplace owner will be interested in allowing one eSupplier to invoke the services of other eSuppliers. For example many eSuppliers will use the services of forwarding or shipping companies. They will therefore invoke the freight related services of shipping companies. In present day e-commerce, this is very costly to achieve through an eMarketplace. The simple reason for that is that every business has its own workflow and resource planning systems, and the cost of integrating them in most of the cases is not worth the benefit. On the other hand, the concept of Web Services reduces the cost of interoperability to such an extent that hardly any business will remain out of the eMarketplace domain. What is a UDDI based eMarketplace? A UDDI based eMarketplace provides the same level of information and the same breadth of services to its customers that a conventional eMarketplace would have offered. It defines, however, flexible standards for interoperability in order to manage growing complexity and dynamism in relationships (which means an eSupplier's internal workflow and content management systems will remain independent of the eMarketplace). It also provides a significant cost reduction for the implementation of eMarketplaces. This cost reduction is two fold: due to the existence of a standard UDDI specification, best of breed implementations will be available off-the-shelf (cost reduction for eMarketplace owners), and B2B Integration for eSuppliers will also become cheaper due to interoperable standards for Web Services (cost reduction for eSuppliers). Think of UDDI as a standard process in which you can search for required services, and once found ask them to serve you. As discussed above, an eSupplier may need to invoke other services in order to fulfill requirements from eBuyers. At our eMarketplace, one eSupplier may become a customer (essentially an eBuyer) for other eSuppliers. If we are able to define industry wide standards for doing this (searching for and invoking services), the entire process will appear seamless to its users even though it is distributed all over the Internet. UDDI (for searching) and WSDL (for describing how services are to be invoked) are the standards for this purpose. How Customers and Businesses participate in a UDDI eMarketplace According to the UDDI specification, two actions can be performed on a UDDI registry: publishing and inquiry. There are APIs (Application Programming Interfaces) provided to accommodate these actions. They are in the form of messages going to or coming from a UDDI registry, messages that are human readable text (a concept called SOAP messaging). As human readable text is supported in all platforms and in all programming languages, there is no problem in supporting the UDDI APIs on any platform. The Publishing API is for the use of service providers. Using this API, a business (an eSupplier) can expose (publish or advertise) its services to our eMarketplace where their prospective customers (eBuyers) can search for and make use of their service. The Inquiry API will be used by eBuyers, to search for products or services of interest at a UDDI based eMarketplace. This API specifies several methods to perform general to detailed (drilled down) searches. A Real life Example of UDDI based eMarketplace Take for example the tourism industry in which there are a number of entities that interact with each other. At an eMarketplace dedicated to tourism, tour operators (eSuppliers) will offer vacation tours, and eBuyers will buy vacation tours. The tour operators will need to interact with hotels and car rental services in order to fulfill tour requirements. All these entities (tour operators, hotels, and car rentals services) are eSuppliers. How can we start a UDDI based eMarketplace? A UDDI registry will sit at the heart of our eMarketplace. UDDI is actually a normal database with a special interface for read and write operations. We can think of the Inquiry API as UDDI's way of reading or searching through records. On the other hand, the Publishing API is intended for writing records to the UDDI registry. These records will constitute the database that contains information about eSuppliers and their products or services. In order to make things easier for potential partners (eSuppliers or eBuyers) for our UDDI based eMarketplace, we could create a graphical user interface (GUI) for the each API. How will we enable eBuyers to use our eMarketplace? The search/inquiry GUI will invoke the Inquiry API of our UDDI registry. It may be normal ASP/JSP, or any other form of Web page. They contain search and indexing options similar to any typical or conventional existing eMarketplace. The main difference lies with what happens when an eBuyer has found the service they are interested in. Unlike most conventional eMarketplaces, it will not redirect eBuyers to the eSupplier's site blindly. It will rather display the eSupplier's interface details to the customer and allow them to invoke services. It will also bring the resulting message back to the eBuyer after invocation. This means that our eMarketplace will be linked to eSuppliers, so that eBuyers will dynamically access their content management system when they invoke a service. How will we enable eSuppliers to serve eBuyers at our eMarketplace? This is the place where the UDDI Publishing API is used. Our eMarketplace should provide a GUI to cater to publishing requests. Using this GUI, eSuppliers will publish the details of their businesses and services they offer. They also have the option of editing their profiles later. Using the structures in the Publishing API, first of all an eSupplier gets registered. Then it will publish its services (a single business entity may contain one or more services). The next step would be to publish WSDL interfaces at the UDDI registry. This is done through Binding Templates and Technical Models. A Binding Template binds a service to a WSDL interface. UDDI refers to that WSDL Interface as a Technical Model. In simple English, the services of any service provider are exposed in terms of one or more interfaces. This interface is described by a grammar called Web Services Description Language or WSDL for short. In UDDI terminology, all interfaces are called Technical Models. What is the role of UDDI in our eMarketplace? The eSupplier that wants to register itself to a particular conventional eMarketplace has to write its interface according to the architecture of that eMarketplace. For each eMarketplace, it will have to rebuild the interfacing requirements separately. With UDDI based eMarketplaces, participating eSuppliers only have to write their WSDL interfaces once, and they can get themselves registered with any other UDDI based eMarketplace without further effort and cost. As far as the role of UDDI in an eMarketplace is concerned, the UDDI acts like a central repository where eSuppliers can register themselves, expose their services and market their products. The UDDI based eMarketplace makes B2B integration less costly. What is the role of Web Services Definition Language (WSDL) in an eMarketplace? WSDL is the grammar in which a business can describe its services. For our UDDI based eMarketplace, it provides an interface between the UDDI registry and the business logic of the eSuppliers. The WSDL file provides not only details about the services of an eSupplier but also contains information about how to invoke these services, what methods you can call, what parameters you have to pass to these methods, and what formats will be returned by different methods. When a UDDI based eMarketplace takes an eBuyer to the doorstep of an eSupplier, the attendant at the business gate is SOAP, with whom the eBuyer will talk using WSDL. The eMarketplace actually links the customer with the business services interface (the WSDL interface). Conclusion We have briefly seen here how replacing a proprietary integration system with UDDI and WSDL can make the lives of everyone involved in an eMarketplace much easier. Rather than having to write a new interface for each of three eMarketplaces your company may wish to join, you can write one standards based interface and happily integrate with each of the others. Using UDDI and WSDL will make the trend of integrating eMarketplaces with others serving similar industries an easier task as well, for example dynamically linking chemical and mining industry eMarketplaces. This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com Or purchase the extended PDF version of this article from:
Adobe Acrobat format (PDF) - 76K Keep up to date with all the new articles and features on
Web Services Architect: |
