- Key Insights
- Specific Web Services Technologies
- The Roles of UDDI, WSDL, and SOAP
- Building a Web Services Architecture Using Some or None of the Formal Standards
- An Example: Using an Alternative Approach to UDDI for Finding Cooperative Applications
- Chapter Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Building a Web Services Architecture Using Some or None of the Formal Standards
In theory, the way that Web services are really supposed to work is that:
-
A source application makes a request to a directory service (UDDI) for a particular kind of application service. This directory steers the source application to one or many secondary Web services applications.
-
The source application and the Web service application then need to agree on how they will communicate and exchange data. Now that the source and secondary applications know about each other, they need to have a “discussion” about how to communicate. WSDL protocols help establish the parameters for the two applications to successfully exchange data and information.
-
Once agreement has been reached, the two applications cement the relationship (by binding communications together) and begin communicating (using SOAP protocols).
-
Data/information is transmitted over the Internet (using a “transport” protocol called HTTP).
I use the words “supposed to work” because of many of today's Web services applications use only a few of the protocols and registry services listed above.
-
At this juncture, few public or private directories contain Web-enabled applications. The work-around for this situation is to write code that tells an application where to go to find a particular service (called “hard-coding”). In lieu of access to a very large and inclusive public UDDI directory, most Web services source applications are written in a manner that tells the source (requester) application where to find a particular service. Application programmers frequently “hard-code” application locations between two cooperative applications such that requester applications know where to go to obtain Web services.
-
Many Web service applications written today make minimal use of WSDL and/or SOAP protocols. Instead, they use other APIs or other program-to-program models [such as Microsoft's Distributed Common Object Model (DCOM), or the OMG's CORBA interfaces]. The reason is usually that the enterprises writing the Web services applications already have code written in COM or DCOM or some other program model, and they find it expedient in the short term to use existing code in lieu of Web services protocols.
In other words, many of today's Web services applications are being written using hard-coding techniques to tell requester applications exactly where to find the services they need, and using application program interfaces other than Web services' SOAP and WSDL. At this juncture in time, using alternative approaches makes sense, because some of the alternative approaches are more robust than today's Web services protocols.
In many cases reusing applications that make use of non-Web services APIs is more expedient than rewriting existing code to be Web services compliant. Hence you will see in later chapters several examples of enterprises that have implemented Web services without using UDDI or WSDL or SOAP (but every one of them uses XML and HTTP).
In the longer term, in order to truly enable programs written in different programming languages to interoperate with other programs on disparate platforms, the common set of Web services APIs will have to be used. Until other aspects of Web services are enhanced (such as security and reliability), however, expect in many cases to see various first- and second-generation programmatic interfaces and architectures (such as COM or CORBA) being used to facilitate XML program-to-program communications.