XML Web Services and the MSDN Pencil Company

Matt Powell
Microsoft Corporation

March 18, 2002

Introduction

In the three previous At Your Service columns, Scott and I have demonstrated how an industry could create a common XML Web service interface for purchasing the standard products for the industry. Our approach was quite simplistic in order to demonstrate with minimal overhead the technical aspects of:

• Defining a common interface.
• Creating an XML Web service that implements the common interface.
• Registering that service with UDDI.
• Creating a client application that searches the UDDI registry for companies that implement the interface and then access their particular services based on the data in the UDDI registry.

In the coming months, we will build on this barebones application scenario to demonstrate a number of other XML Web service technologies, ideas, and best practices. In the process, our simplistic application will become more and more realistic. In this article, I'll lay out some of our plans, so you can see the sort of topics we will be covering to show how you can use XML Web services in new and powerful ways.

Evolving the Infrastructure for the MSDN Pencil Company

One of the main ideas behind the Microsoft Solutions Framework is the time-proven practice of performing incremental updates to a solution in order to achieve key requirements in shorter intervals, so that value is realized faster for the customer without losing sight of an application's development vision. We have created an initial architecture for the MSDN Pencil Company based on the XML Web service we created in the Building XML Web Services Using Industry Standard WSDLs column. We will be building upon that initial infrastructure to create an architecture that supports authentication through digital message signing, payment processing, asynchronous message handling, and approaches to message forwarding. Updates to the application will be made incrementally to illustrate the various technical messages of the column, and to add key capabilities for our application.

Current Infrastructure

As mentioned earlier, the current application infrastructure is quite simplistic. It is illustrated in Figure 1.

Figure 1. The current MSDN Pencil Company application architecture

The current application exposes two XML Web services: the Pencil Discovery service and the Pencil Order service. Both of these services perform simple interactions with a SQL Database in order to implement their logic. The XML Web services are exposed for anyone to use in order to purchase pencils from the MSDN Pencil Company. We show a couple of applications submitting their discovery and order request messages to the two services, and the services returning response messages.

The problem with this model is that it is pretty unrealistic. The client is not authenticated in any way, there is no support for any sort of monetary transaction, and the backend infrastructure is non-existent. So we are going to look at what options we have for molding this baseline infrastructure into something that is more realistic, and will demonstrate just how we might use XML Web services to enable our application to take that next step.

The Backend

Our main concern with our previous architecture was simply creating an XML Web service that exposed the particular interfaces defined by the Industry Standard WSDLs. Therefore, reading and writing to a simple database interface was all we really required for our backend. In a more realistic scenario, the Pencil Order service would have to communicate to the company's warehouse to inform them of the request. In fact, the customer may have three warehouses scattered across the country in order to minimize shipping costs. The MSDN Pencil Company could take advantage of the ease of development and the inherent interoperability of XML Web services and implement a simple order shipping service that it could host locally at the three different warehouses in order to receive shipping requests. The distributed warehouse architecture is shown in Figure 2.

Figure 2. Adding shipping services for the three warehouses

You might have noticed that messages are only being sent to the warehouse services and return messages are not indicated. This is because an XML Web service that might be running over the HTTP protocol cannot wait for the warehouse to gather the materials, package them, and ship them before they send the HTTP response. The shipping requests must be queued while the manual labor to package the material is accomplished at its own rate. But this definitely raises the question of how the shipping entities are going to report their status. The Pencil Order service supports the ability for a customer to check the status of their order, so we need some mechanism that allows the shipping entities to report back to some central authority their status in fulfilling the order. The answer, of course, is to use an XML Web service. Figure 3 shows an additional status notification service in our MSDN Pencil Company backend.

Figure 3. Adding an Order Status service

Notice that our Order Status service is not just receiving SOAP status notifications from our shipping entities, there will also be status changes coming from our Pencil Order service. The Pencil Order service will tell the Order Status service when a new order has been received, so it plays a key role in initializing a new order for the Order Status service.

Handling Payments

So we have a more realistic asynchronous messaging scheme for a couple different parts of our application architecture. You might already be thinking about how having a central status location service might work for other business processes. One such process would be the handling of financial transactions. If someone is going to order pencils from us, they must certainly pay for those pencils. One straightforward approach: we could modify the pencil order schema in such a way as to include a bank account number, and the amount of the monetary transfer. However if we define a couple of extra fields for our current Pencil Ordering interface, we run the risk of the person's bank account number being found out by others. The bank would not know for certain whether it was the owner of the account that approved the financial transaction, nor could the bank be certain whether the amount of the transfer had been changed since it was properly authorized. Therefore we need to make some key changes in the way that our XML Web services handle orders to insure proper payment validation. Figure 4 illustrates our additional architecture for including payment processing.

Figure 4. Adding payment processing

Changing the Pencil Order interface to include encrypted and digitally signed payment information is indicated in Figure 4 by the envelope with the lock on it. The encrypted payment portion of the message will be forwarded to an external partner, First MSDN Bank, through an XML Web service. Of course the bank will not be able to immediately transfer the funds, so the request will be queued. When the transfer does complete, we use our asynchronous callback mechanism with the Order Status service to receive notification from the bank that the funds have been transferred. This requires that the Order Status service has an external interface accessible to third parties. The external interface might be defined differently than the internal interface, in order to allow for authentication and schema differences that might be defined for financial transactions.

Now if we consider adding an auditing service, several reporting services, services for interacting with a third party shipping company, and a system monitoring service, we might get something that looks like Figure 5.

Figure 5. Options for adding new services internally and externally

My goal was not to inundate you with grey arrows and to show off my pixilated artistic capabilities. What I hoped to illustrate is the flexibility and agility that building applications on XML Web services provides you. Obviously the grey boxes with funnels on their sides illustrate that XML Web services are everywhere in this vision. More importantly, however, they map directly with the business functions of the departments and third-party companies that the MSDN Pencil Company interacts with when handling pencil orders. And crucial to the success of the XML Web services vision for the MSDN Pencil Company is the ability of XML Web services to provide secure, private, irrefutable communications, so that things like financial transactions can take place with confidence by all the parties involved. We may not ultimately implement all the grey arrows shown in Figure 5, but we do plan on covering the topics involved that would allow a system like this, based on XML Web services, to be successfully implemented.

Future At Your Service Topics

The process of incrementally developing XML Web services in a manner consistent with the Microsoft® Solutions Framework raises a number of common issues. These are the issues that we plan on delving into for future At Your Service columns. Issues such as how to evolve an XML Web service interface, caching strategies for XML Web service content and applications, merging the XML that might be returned from a number of XML Web services, message routing strategies, digitally signing SOAP messages, encrypting portions of a SOAP message, options for asynchronous XML Web service communications, and how to implement centralized services such as auditing. These are some of the topics we will hit on over the coming months. Some of these involve delving into new technologies, while others are simply common development challenges that inevitably arise when creating an application architecture using XML Web services.

Conclusion

The advances in XML Web service technology, and the ease of development made possible by great tools like Microsoft® Visual Studio® .NET, makes creating entire business solutions based on XML Web services an efficient reality. As we continue to look at the issues involved in making interconnected business solutions with XML Web services, we encourage you to give us your feedback. Click on the "Read User Comments" link at the top of the page, and you can add your own ideas on topics for discussion, or give your opinions on the vision we have created for the MSDN Pencil Company. In the next issue, Scott will be taking the first step into the world of MSDN Pencil, and will be talking about evolving XML Web service interfaces.

At Your Service

Matt Powell is a member of the MSDN Architectural Samples team, where he helped develop the groundbreaking SOAP Toolkit 1.0. Matt's other achievements include co-authoring Running Microsoft Internet Information Server from Microsoft Press, writing numerous magazine articles, and having a beautiful family to come home to every day.