This is the hour in which your humble authors get to play futurist. Predicting the future in any technology is always a risky venture. Although it is true that predictions are very often wrong, there doesn’t seem to be any lasting punishment for the erroneous predictor. With this in mind, we will cover what appears to be the direction of Web services for the near future.
When reading about these topics, it is important to remember that there is no centralized leadership in the world of computing. Every individual writer, thinker, company, standards body, and governmental organization that gets involved possesses some degree of self-interest. Many good ideas die on the vine because they conflicted with a few people’s or companies’ interests. Other weak trends get more attention than they deserve because of powerful backers.
In some ways, we are fortunate that the decision making process is so fragmented. In spite of the financial clout of several software and hardware companies in the recent past, they have been spectacularly unsuccessful at dictating terms to the rest of us. Their only successes have come by working to achieve consensus among the sometimes cantankerous factions that compose our world. This is the fundamental reason that all the predictions in this hour should be taken with the proverbial “grain of salt.” All of them might indeed come to pass, but it is more likely that some of them will not.
We will start by talking about other uses of the Web services standards that are already beginning to appear. Following that, we will talk about new versions of the existing standards, followed by a discussion of the new standards that are likely to be adopted.
In this hour you will learn about
Non-Web services uses of UDDI, SOAP, and WSDL
New versions of the existing standards
Wireless Web services
W3C’s Web services architecture
WS-Coordination and WS-Transaction
As stated throughout this book, Web services are built using a suite of standards. These standards have their own set of followers and are governed, in near independence, by their own standards bodies. Although these bodies monitor the directions that the other groups are taking and take care to avoid incompatibilities, each charts its own course. This will become increasingly true as more standards are added to the Web services suite.
Nearly every invention finds uses that are far outside the vision of its inventors. Could the ancient inventors of gunpowder have foreseen the machine gun, or could the creators of networked computers have foreseen e-commerce?
The standards created for Web services have already begun to be used for other purposes. We predict that every one of the current standards associated with Web services will find a strong following in at least one area not normally thought of as related to Web services at all.
If you look at the features of UDDI apart from its role in Web services, you will see that it possesses a number of interesting characteristics:
Language independence—. The only language that UDDI is required to conform to is XML.
Human readable—. The information in the UDDI is in ASCII-character format, which can be read using a simple text editor such as Notepad or any one of a number of more sophisticated approaches.
Hardware independence—. A UDDI registry can be created on any platform using any programming language or tool.
Universal—. UDDI is capable of describing any piece of software regardless of its platform, origin, language, and so on.
Comprehensive—. A UDDI registry can contain a wide variety of information about a piece of software. This includes information about its purpose, its owners, the standards that it is built on, its locations, and its cost per access, if any. In addition, the UDDI registry normally contains the Internet addresses of other resources that describe the service, such as its WSDL description and the phone numbers of support personnel.
Standards based—. Standards take some of the politics out of decision making. The UDDI registry specification has brought some measure of peace to the software industry, so it might find acceptance within your organization also.
These characteristics make it a great candidate for maintaining an inventory of all the software systems in a large organization, company, or university. Having a central registry like this is essential to any software reuse strategy. All these organizations have systems that run on a variety of hardware and software platforms and that are written in a variety of computer languages.
In order to reuse a piece of software, you have to know where it is, who owns it, what language it is written in, its purpose, and so on. In short, you must have the kind of information that is normally stored in a UDDI description.
In addition, you also must have a contact person to provide support and advice. Look for organizations to purchase or create UDDI-compliant software to serve as a repository for their software inventory and reuse catalog. Figure 24.1 shows a UDDI-based reuse catalog.
The communication, up to and including the inquiry of the UDDI registry, is identical to the way it would be done to find a Web service. From that point forward, it would be a traditional phone call followed up by email communication.
If you look at the features of WSDL apart from its role in Web services, you will also see that it possesses a number of useful characteristics:
Language independence—. The only language that WSDL is required to conform to is XML.
Human readable—. The information in the WSDL is in ASCII-character format, which can be read using a simple text editor such as Notepad, or any one of a number of more sophisticated approaches.
Machine readable—. Enough information in the WSDL exists that can be used to generate code.
Hardware independence—. A WSDL can be created on any platform using any tool.
Universal—. WSDL is capable of describing any piece of software regardless of its platform, origin, language, and so on.
Comprehensive—. A WSDL document contains a wide variety of information about a piece of software. This includes both a logical view of the services that it provides as well as one or more descriptions of how you would bind to it.
Standards based—. Documents written to the WSDL standard can be understood by any person or software system that understands the standard. This makes it possible to share code across organizational boundaries.
These features combine to make WSDL a universal Application Programming Interface (API). The WSDL can be used as the design view of a service or system, regardless of how the actual code that implements it is created. This is true whether or not SOAP is used to provide the message protocol.
This idea is far reaching because a COBOL programmer who knows how to describe his systems in WSDL format can now communicate with a Java programmer in a meaningful way—without either of them having to understand too much about the other’s world. In addition, a framework programmer could use the WSDL to generate the code needed to connect the Java front end to the COBOL back end.
In the future, expect to see the WSDL move outside of its current Web services role and find uses in the Enterprise Application Integration world—in many cases, without SOAP.
One of the weaknesses of XML is that it is a noun-oriented language. An XML tag represents an entity such as a paycheck or a machine. It can also contain adjectives (attributes), but where do you place verbs? One solution that we and others have used was to use message queues to transfer XML documents. If a document arrived on one queue, it was treated as an order; if a document arrived on a different queue, it was treated as a request to return defective merchandise. Responses were sent using yet a third queue. Figure 24.2 shows this approach graphically.
This approach provided the verbs or method calls implicitly by the choice of queues. This approach was serviceable within a single company or between companies that communicated using messaging, but beyond that it was very limiting.
A better approach is to define verbs (method calls) in XML itself. This provides the advantage of having explicit calls instead of implied calls in the messaging software. In addition, this approach would allow you to remove the requirement that expensive messaging software be used. The only thing lacking is the syntax of the XML to be used. SOAP provides that syntax in a standardized fashion. SOAP has the following qualities:
XML based—. SOAP is a dialect of XML, and it can be parsed by any XML parser.
Standard—. The W3C regulates the contents of a SOAP message, which means that any SOAP engine can be used on any SOAP message. It also means that every programmer trained to use SOAP can understand the format being used by every other SOAP programmer.
Easy—. SOAP messages are not complicated, and they can be written by hand using a text editor.
Generated—. Your code can generate SOAP messages on-the-fly, just as it can create any other XML document.
These features allow us to redraw Figure 24.2 using this new approach. Figure 24.3 shows this approach.
Notice the simplicity of this approach. In addition, note that there is no middleware to buy with SOAP (though a vendor’s product might perform better). Each computer can communicate with another directly. This approach is practical any time you want to implement a system in which one computer needs to make method calls on another. This is true regardless of whether you have a WSDL defined for the server or whether you are using a Web services platform such as Apache Axis. It is a useful approach even if all you are doing is opening a socket between one program and another. In addition, if you hire a new programmer who knows SOAP, he might be able to understand your code better.
In the future, expect to see SOAP move outside of its current Web services role and find uses all over your company as a dialect of XML to send and receive method calls. However, SOAP and Web services are getting a reputation for being “slow.” They will have to overcome this to move past their current role of “outside the firewall integration” and into the realm of general purpose RPC.
When standards are in their formative years, they are constantly undergoing changes. The reason for this is that they have been accepted in general, but deficiencies have been identified that must be remedied before they can be declared truly useful.
One of the three current Web services standards, UDDI, is still in its formative years. As a result, you can expect new versions of it from time to time. The other ones, SOAP and WSDL, have stabilized, and newer versions of them tend to contain only maintenance-type changes.
In July 2002, a new version of the UDDI was released. It builds on the previous releases and adds the following features:
Support for multiregistry environments—. Before version 3, UDDI registries had no way of expressing relationships to one another. Version 3 introduces the concepts of a root and affiliate registries. The root acts as the authority for the registry. It can delegate key partitions so that other registries can interact with the root without having to get unique keys for their entries from it.
Subscription—. Before version 3, you had to make an inquiry to learn if the registry contents had changed. As of version 3, your registry can subscribe to be notified whenever an entry that it has an interest in has been modified.
Separation of policy from implementation—. Version 3 addresses the issues of permissions and policy by using policy abstractions, rules, decisions, decision points, and enforcement points. All these entities describe who is allowed to do what to the registry.
Security features—. The ability to determine the truthfulness of the data in the registry has been lacking until version 3. This version adds the ability to digitally sign all the core data in the registry. It does this by supporting the new XML-Signature standard. As the name implies, XML Signature is a set of XML tags. These tags are designed to contain sufficient information to allow a client to be verified using the public/private key pair that he must possess to participate in a signed transaction. Hour 22, “Web Service Security,” covers digital signatures in more detail.
Enhanced inquiry—. Version 3 provides significant improvements to the Inquiry API. New qualifiers allow you to perform both case sensitive and not case sensitive matches, sorts, as well as sorts using accents (non-English alphabets). In addition, it now supports approximate matching, binary sorting, and exact matching. Finally, it allows you to search only where a signature is present.
Chunked retrieval—. You may now inquire about services and receive the data back in chunks of an appropriate size. This is similar to cursoring through a database, except that each chunk can be retrieved at a slightly different time, allowing some updates in the mean time.
Of the three standards, UDDI is the one that lags behind in adoption by the user community. Its fans hope that this new version will provide solutions to issues that have held it back in the past. It is interesting to note that UDDI has now pulled WS Signature into the Web services standards, albeit in a second-hand way.
One of the curious things about Web services is that it hasn’t been formally defined. It is generally considered to consist of UDDI, WSDL, and SOAP—all of which are governed by one standards body or another. Until late 2002, however, the formal definition of the architecture was missing.
In November 2002, the W3C published the first working draft of a document called “Web Services Architecture.” According to this document, which can be found at www.w3.org/TR/ws-arch,
“The Web services reference architecture identifies the functional components, defines the relationships among these components, and establishes a set of constraints upon each to effect the desired properties of the overall architecture.”
Before you get too excited though, this version of the document contains a disclaimer that the document doesn’t reflect the consensus of the W3C Web Services Architecture WG that created it. It was published to stimulate discussion of the topics in which there is still no widespread agreement.
Hopeful signs exist in the document that some of the problems that have held Web services back, such as security and choreography, are going to get some attention.
This document is divided into two parts: basic and extended architecture. The basic architecture describes a Web services stack, or completely functional implementation. The extended architecture describes how messages are combined into higher-level interactions. It provides details on support for security, transactions, orchestration, privacy, and business-level transactions.
The document defines messages and intermediaries, as well as operations. It makes a draft attempt at defining many terms, including the following:
Asynchronous messaging
Attachment
Caching
Correlation
Long running transaction
Management messages
Message authentication
Message confidentiality
Message exchange pattern
Message integrity
Message routing
Reliable message
Session
Finally, this document defines a Wire stack that is composed of three layers as shown in Figure 24.4.
The transport is the actual protocol, such as HTTP, or SMTP. In addition, it can be a vendor protocol such as MQSeries. The packaging layer represents the technology that packages information for exchange. XML and SOAP fit into this layer.
Extensions represents the frontier of Web services. It defines the information such as context, routing, policy, authentication, and other technologies that are likely to be implemented in the SOAP header.
One of the oft-mentioned deficiencies of Web services is the lack of a transaction model. A logical transaction is a set of activities that compose one complete operation from the user’s point of view. For example, a deduction of $20 from your savings without a corresponding deposit of $20 to your checking account would invalidate a transfer. Even worse, it would leave you $20 poorer. Logically, the transaction begins before the deduction and ends after a successful deposit into checking.
Database management systems (DBMSs) often provide a way of beginning and ending (committing) a transaction. In the world of Web services, a similar need exists. However, a single DBMS vendor cannot supply this functionality because all the parts of the transactions don’t take place in his software. A single transaction might take place over several days and involve a dozen or more computers.
Recognizing this deficiency, BEA, Microsoft, and IBM have begun work on a standard way of handling Web services transactions called WS-Transaction.
At the time of this writing, this paper has not yet been submitted to any standards body. It is still in its formative stage in which ideas are incorporated on a regular basis. You can find a copy of the WS-Transaction document at www-106.ibm.com/developerworks/library/ws-transpec/.
The document defines two very different types of transactions:
The Atomic Transaction—. This is the class type of transaction similar to the bank account example explained previously. The transaction is an all-or-nothing proposition. If it fails at any time, all parts of the transaction are to be rolled back as if this transaction never started.
The Business Activity—. This is a different type of transaction based on the fact that long transactions exist in the real world. Many business activities take weeks to complete and involve dozens of people and computer systems. An example of this would be an order for a jet airplane. If you begin the transaction just after signing the contract, you would commit the transaction after you fly the jet off. In this scenario, you couldn’t roll back to the beginning. Parts have been fabricated, money advanced, people hired, and so on. When this type of transaction fails, and it does sometimes, you have to be very sophisticated in your approach to cleaning up. Everyone involved must be “made whole” to the best of your ability.
This specification is designed to fit into the WS-Coordination proposed standard. Both of these specifications must be accepted by the W3C for inclusion into the SOAP header file standards before you can assume that every SOAP engine supports it. That doesn’t stop you from using these features today, however, if the other party in the transaction is aware of them and knows how to handle the extra tags that he will find in the SOAP header.
Another area in which specifications are needed is in the area of choreography. Modern business transactions are very complex. If you consider the number of different computer systems used when you are purchasing a house, you will get a feel for this complexity.
If a sufficiently powerful business-process language existed, the level of automation possible would increase, thereby decreasing costs. Imagine being given the task to automate the house-closing process. You would have to create a Web service on every computer that needs to know about the purchase. This includes at least two mortgage banks, insurance companies, title search firms, and a host of governmental agencies, including federal, state, and local. In effect, you would need to create a Web service for every piece of paper that you normally sign at a closing.
That is daunting enough, but after you had completed programming all these Web services, you would need to create a SOAP message that provides instructions on what to do at each stage. You would have a chain of intermediaries that would stretch on for pages. In addition, you would need exception handling for cases in which one of the services doesn’t behave the way that you were hoping. The definition of this path is the subject of business-process execution.
Fortunately, IBM, BEA, and Microsoft have joined together and produced a specification to start the process of defining exactly what is needed. Although this effort is far from mature, it does serve to get the ball rolling. They call this proposed standard the Business Process Execution Language for Web Services (BPELWS).
When you consider the complexity of designing the process needed to automate a complex business transaction, you are reminded of a third-generation programming language such as Java. You will need if...then...else processing, do...while, catch exception, and just about every other conditional operation that you need in a programming language.
BPELWS provides this type of processing in an XML format. A few of the tags that it uses are
<assign><invoke><source><switch><terminate><while>
There are so many more that it would be difficult to list them all in the space that we have here. If BPELWS’s tags aren’t sufficient, you can extend these with the <extension> tag that has a namespace attribute.
It is hard to say what will come of this effort. At the time of this writing, the BPEL4WS specification was in its initial draft release. If you study it, however, your time will not be wasted because the need surely exists for some specification to fill this niche. In all likelihood, some part of this specification, small or large, will find its way into the Web service that you will be working on 10 years from now. The URL for this proposal is http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/.
In this hour, we covered some of the developments that are coming up on the Web services horizon. We first covered the use of UDDI, WSDL, and SOAP for other purposes. Next, we discussed the new features of UDDI 3.0. Following that, you learned about the new Web Services Architecture draft specification that has been circulated for review.
Next, we looked at a number of specifications that are well thought of at the present time. Finally, we looked at WS-Transaction and BPELWS as two specifications that fill import needs in the future development of Web services.
The Workshop is designed to help you review what you’ve learned and begin learning how to put your knowledge into practice.