 | |||
|
Wednesday November 21 2001 Web Services Intermediaries Adding Value to Web Services We are now at the stage where we are seeing a growing number of Web Services implementations across several industries. These initial implementations have served to not only reinforce the fact that Web Services provide tremendous value but at the same time, they serve to identify pieces in the Web Services puzzle that need to be present in order to effectively implement these solutions. In this article, we shall take a look at an entity called the Web Service Intermediary. These Intermediaries are increasingly getting recognized as the means to provide value-added services like Authentication, Quality of Service, etc. We shall also take a look at the general architecture of an Intermediary and practical issues that Web Services publishers and subscribers will have to grapple with when dealing with an Intermediary. Finally we will take a look at existing support for Intermediaries in Web Services standards. What is a Web Service Intermediary? An Intermediary is a component that lies between the Service Client (subscriber) and the Service Provider (publisher). It basically intercepts the request from the Service Client, provides the service (functionality) and forwards the request to the Service Provider. Similarly, it intercepts the response from the Service Provider and forwards it to the Service Client. To understand what a Web Service Intermediary is, it is useful to first take a look at the standard way that a Web Service is invoked (SOAP Messages over HTTP) as shown below:
A Web Service Intermediary therefore lies between the Web Service Client and the Web Service Provider as shown below:
Note that it is not necessary that there is only one Intermediary between the client and the Service Provider. As shown in the diagram below, it is possible to combine Intermediaries in several ways. As we see, a chain of Intermediaries (A and B) intercepts the HTTP Request from the Web Service client. Another Intermediary, C, further intercepts the HTTP Response from the Web Service.
What this means is that it is possible to place Intermediaries in a variety of configurations. A fact to note is that the Web Service Provider (as a part of Web Service implementation) might utilize other Intermediaries at the backend. It should now be clear that an Intermediary can be authorized to intercept the calls from the service client to the provider. A Web Service Intermediary can in fact be a Web Service itself that provides a certain piece of functionality. Let us now move on to what services these Intermediaries can provide to us. Intermediary Services Web Services Intermediaries can provide us with extremely important services as shown below: Authentication Services An Intermediary can provide an authentication service that helps to validate the Web Service client. A well-known example of an Authentication Intermediary is Microsoft, which is providing an Authentication Service called Passport (see the Passport site for more details). In a sample Authentication scenario, a Web Service client will first authenticate itself with the Authentication Intermediary and receive a token that identifies itself. It can then use this token and pass it along in its invocation to the Web Service Provider. The Web Service Provider will use that token and validate it with the Authentication Intermediary again as shown below:
Auditing Services As Web Services are used between enterprises to perform business operations, it is extremely important that a proper log of messages is kept. An Auditing Service will generally include auditing the activity of the service, its reliability, downtime, etc. An Auditing Service would therefore keep a log that contains information to track the above characteristics of the service. It would also serve to track who is using the service and be useful in tracking down any security breaches. In an Auditing Service scenario, the service interposes itself between the Service Client and Service Provider as shown below:
Management Services A Management Service Intermediary is used to collect together a number of useful reports about the Web Service. Some of these reports include the number of Web Service hits, Web Service client usage (services used, total time usage, monthly/yearly reports, etc.). This would definitely help in identifying if the Web Service were meeting the Quality of Service (QoS) specified in the contract between the two organizations. This Intermediary could also track the health of a Web Service and trigger an alert if the Web Service goes down. It functions in a similar manner to the Auditing Service explained above. Performance Improvement Services An interesting use of Intermediaries is in the area of Performance Improvement. A "Cache" Intermediary could be used to store data frequently requested by Web Service clients, for example News Items that change every hour. When a client requests this data it can provide the information from its local cache instead of making an expensive network call to the Web Service. This results in reducing some of the load on the Web Service too. By placing several such "Cache" servers across the network, the response time to the clients will also be improved. Note that we will need a mechanism for the "Cache" servers to regularly update their caches with the latest information. A "Store and Forward" Intermediary is used in situations where we don't want to overload the Web Service with too many requests. This is similar to the concept of a Batch, where a number of instructions are collected together and sent across at one time. So, what a "Store and Forward" Intermediary can do is to collect these requests from different Web Services clients and then shoot them off to the Web Service Provider. This would make the Web Service more asynchronous, which is fine if the client doesn't want or need an immediate response. Aggregation Services An "Aggregation" Intermediary is a powerful Intermediary and it can be used to provide a number of value added services that it combines and provides as a uniform service to the client. An Aggregation Intermediary could be used to combine several Web Services into one composite Web Service. Examples of Aggregated Services could include transaction management, combining different sources of information into a single unified interface, etc. In addition to the above services, Intermediaries can provide a host of other services like Reliable Messaging, Transformation of Data (XML/XSL), Registry Services, Utility Services like Contacts, Calendar (Microsoft.NET My Services, formerly HailStorm), etc. Now that we have looked at different kinds of Intermediary Services, let us look at the general architecture of a Web Service Intermediary. High-Level Web Service Intermediary Architecture Shown below is a very basic set of components that would make up a Web Service Intermediary. This is by no means a complete set of components but it is just to provide you with a glimpse of what it could contain from a conceptual level.
A Web Service Intermediary would have the basic "Web Services Stack" which will allow it to seamlessly plug-in to the Web Services invocation route. The "Core Functionality" component is the main functionality of the Web Service. This could itself be a J2EE Application, a CORBA based application, or .NET component. Similar to Web Services, it should not matter what the platform is or what programming language was used to create this functionality. The "Rules" component can serve to define the behavior of the Intermediary; how it interacts with different clients, its interaction with other Intermediaries, etc. The "Log" database holds all the information on the messages passing to and from the Intermediary. Finally the "Repository" can be used not only for its core functionality but also as a source of information about other Intermediaries that it needs to interact with. Web Service Intermediary Issues As usual, the world of Intermediaries comes with its own set of issues that we need to be aware of. We have seen that Intermediaries intercept the calls from the Service Client to the Service Provider. We have also seen that Intermediaries could be chained together. What this means is that Security is of prime importance whenever Intermediaries are involved. For example, if I am a Service client, I would like to know which Intermediaries my request is going to go through. Can I trust those Intermediaries? Do I need to enforce Security via encryption, signatures, etc., to guarantee not only the source of my data but also the validity of my data? Of equal importance are Transactions and Service Context. Since there could be a chain of Intermediaries that are present in a single service invocation, care should be taken that the Service Context is propagated correctly. Also the Transaction context needs to be propagated to ensure correct execution of the request. Other interesting issues are those of Inspection and Routing. A Web Service Provider should have a mechanism for describing the Intermediaries that are supported by its Web Service. This way, there is a standard mechanism for the Web Service client to inspect the Intermediaries. Similarly, it would be great to have a mechanism whereby the SOAP Request can be precisely routed between a specified set of Intermediaries only. As these issues get addressed, there is definitely an opportunity here for a new kind of Intermediary called the "Trusted Intermediary". In the digital security world, we have entities called Certificate Authorities that facilitate in authenticating organizations. In a similar manner, we could see the rise of the "Trusted Intermediary" that could provide us with a complete range of secure Intermediary services. Using such a trusted Intermediary might be more practical that a number of uncoordinated Intermediaries. Such trusted Intermediaries could very well turn out to be software companies like Microsoft, financial institutions like Visa, portals like Yahoo, or probably a complete new breed of companies. Standards & Web Services Networks It is important that each of the above issues be addressed appropriately in any standards that come forth for Web Service Intermediaries. At the moment, there are no standards for Web Services Intermediaries. As SOAP is being extended to incorporate features like transactions, security, context, etc., it would be advisable to shape these in a manner that the Intermediaries can implement too. The XML Protocol Group at W3C is addressing a number of issues relating to Intermediaries. Microsoft has also submitted a Web Services Routing Protocol that is used to route a SOAP message through a predefined set of Intermediaries. The next generation of Apache SOAP called AXIS is going to provide support for Intermediaries. While the standards are being developed, we are seeing the development of Web Services Networks that function as Intermediaries for you and provide a set of services like hosting, security, context, maintaining relationships, etc. Web Services network providers include Grand Central and Flamenco Networks. Conclusion In this article, we have looked at what a Web Service Intermediary is and the kind of services that they provide. Web Services Intermediaries are here to stay, and with appropriate development of standards for them we should see tremendous activity on the part of component developers and organizations to write Intermediaries that seamlessly plug-in to Web Services networks, thereby providing value-added services. This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com Related articles: Hailstorm, by Johann Dumser Keep up to date with all the new articles and features on
Web Services Architect: |
