What Web Services Are NOT (3/4) - exploring XML
What Web Services Are NOT
Web services are NOT solely externally focused. A significant number of Web service applications will be focused on enabling applications within the enterprise to communicate with each other. In fact, Web services are ideally suited for this task. They provide a mechanism for intercommunication between systems in a platform, applications and network protocol in a neutral manner. Since Web services are typically implemented over HTTP (the standard Internet Web protocol) it doesn't matter what systems are used by the transmitter and the receiver.
Before Web services, communication between two applications involved using a closely coupled mechanism where one program called the other through an API (often a client stub of a RPC - remote procedure call - implemented using CORBA or DCOM). When using Web services for application integration, as long as the data elements and document definitions don't change, old and new applications can work together without changing anything in the communication layer. Communicating at the API level, on the other hand, would mean having to upgrade an application and re-deploy it (along with new versions of all its clients). In a distributed network with many nodes, trying to make all these changes simultaneously is impractical. Hence using Web services for application integration is analogous to the Web itself where the browser and server are not tightly coupled.
Existing (legacy) business logic can be accessed (and incorporated) into new applications by wrapping them with Web service interfaces. For example, consider implementing the business logic for a "user login" step in a new application. The logic may have to consult a central authentication database in LDAP. This can be done by wrapping the LDAP database with a Web service interface and accessing this interface as part of the login processing.
There is NOT yet a universally accepted format for XML documents exchanged during a Web service invocation. Web services give you the foundation for transmission of information between applications. They do not define how the information is structured or what the information means. This is much like what a relational database does for storing information. The database gives you a foundation for storing data but does not define the table structure for a particular application. This is both a strength and a weakness. The flexibility has led to a proliferation of standards. It is daunting to go to an XML Website and see how many markup languages and initiatives there are (for example, the Web site www.xml.org lists eight standards just in the e-commerce field). The growth of standards is not expected to slow down anytime soon. The leading initiative in this area is ebXML (which is the XML based successor to EDI) - expected to culminate in a specification about 18 months from now.
It is important to note that it is not necessary to have a standard to start using Web services. Smart vendors are waiting and watching and in the meantime allowing you to specify your own vocabulary for inter-company interaction. As long as the interacting group of companies (e.g., the auto parts company and its suppliers in the previous example) understand the data definition, Web services can be made to work.
Last, but not least, let's look at directories and robust applications.
Produced by Michael Claßen
Created: Feb 16, 2002
Revised: Feb 16, 2002