In the B2C world, e-commerce vendors used online ad banners, television, newspapers and other means to articulate their presence. The goal was to get the individual consumers to visit the site at least once. During that one visit, the user was presented with information about the site, the products and service offerings. Most of that information was in standard written text. Sites that were able to present a clear mission of what they do and back that up with robust performance and ease of use, were likely to succeed in attracting that customer for repeat business. In the B2B world, the same problem still exists. When a web service is offered, somehow it has to lets others know about its existence. The main difference is that the others are not made up of individual consumers, but of various systems owned by partners, suppliers and other vendors.
Standards like SOAP do a good job addressing the messaging needs of two entities. When you open a new physical office, you need to furnish it. It is well understood that you load up a truck with the furniture, drive on the road until you get to the location designated as the office’s address and unload the furniture there. This is what SOAP does in the Web services world. What we sometimes take for granted is the process by which we find the furniture store. WSDL (Web Services Description Language) and UDDI are the technologies that describe what a particular service does and how to locate it. Going back to the office scenario, somehow you have to know that there is a furniture store in a certain location, what types of furniture they sell, how they receive payment, how they deliver, etc. While this information can be captured and put on a web page for easy access, in a true B2B situation, we record and present these details in a standard manner. The needed information include items like communication protocol, location/address of service, formatting of data (both sent and received to/from the service), and miscellaneous aspects of the service such as error handling.
WSDL achieves its goals by carefully separating implementation details from the abstract notion of the service. The abstract concepts that are captured by WSDL are the port type, operation and message. It is common to expect a single port type to support multiple operations (the furniture store sells furniture, accepts new products, employs people, etc.). Furthermore, it is possible to have a single operation performed via different messages. For example, you can order furniture in person, by phone or via a catalog. The abstraction allows WSDL to be applicable to a variety of services. Using a discovery mechanism like UDDI, a system can find a service, learn about its workings by parsing the WSDL file associated with it, and then apply a late binding to specific implementations. There is plenty of room for WSDL to evolve. For one thing, issues like quality of service or even the business rules surrounding a particular service are valuable information that can be exposed through WSDL. Find out more about WSDL from