Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
XML Schemas to the Rescue
Of course, significant problems result from the great flexibility of XML. Because XML allows you to define your own elements, it's very difficult to ensure that everyone uses the same elements in the same way to mean the same thing. That's where the need for mutually agreed-upon, consistent content models comes in, which actually describes a lot of the effort by consortia such as RosettaNet, ebXML, OAG, and OASIS.
Two parties exchanging XML data can understand and interpret elements in the same way only if they share the same definitions of what they are. If both parties that share an XML document also share the same Schema, they can be sure to understand the meaning of the same element tags in the same way. This is exactly how Web services work.
Unlike established distributed computing systems, Web services content is loosely coupled from the underlying executable implementation of the service. That's why it's so important to emphasize the fact that Web services are not executable in and of themselves, although some definitions would include the executable part, of course. But I think it's clearer to understand the distinction between the two worlds because it's possible for the same XML message to be interpreted in different ways, depending on the associated Schema, or semantic information.
As a practical matter, you don't see this very often in Web services products on the market today. Many of them focus on WSDL, and tend to associate a service with its WSDL definition and in the singular sense in which a given Web service is associated with one and only one WSDL. But it's still important to remember that a program that understands how to process documents and map the documents—or a subset of them—onto other software programs is what consumes Web services, and therefore makes them interoperable with almost anything.
The fundamental reason for the popularity of Web services derives from the power and flexibility of XML to represent any kind of data using extensible tags, and to also include within the associated Schema information about how to interpret the data.
Web services applications, therefore, are built up out of traditional markup language processing programs, with additional programs layered on top of them to interpret the associated content model. Just as you would reformat a user manual or sales report by changing the associated style sheet, you can change the mapping information associated with a Web service. It's possible to map the same Web services message to different underlying programs (that is, a message can be generated from a CORBA system and consumed by a J2EE system or a .NET system).
Similarly, Web services are intended to be mapped to multiple transports so that the same message might travel over HTTP, JMS, IIOP, or a proprietary transport; depending on the instructions contained in the associated WSDL file or other schema. This type of flexibility and level of abstraction means that interactions between programs using Web services tend to be loosely coupled and large-grained.