System Design

Based on the requirements, SOAP is an obvious choice as base technology for the exposed API. Figure 15.1 shows the high-level structure of the application in relation to potential external clients.

SOAP Considerations

SOAP is an XML-based Remote Procedure Call protocol that was originally intended to be served via HTTP requests. Each SOAP request is logically mapped to a method invocation on a server object. The object processes the arguments that were passed in by the SOAP client, then sends a result that the client reads as an HTTP response.

Like HTTP, SOAP calls are inherently stateless. Each SOAP request is intended to stand on its own, with any transactional support being built into the object on the server.

Because SOAP messages are conveyed as HTTP requests, all the IIS security features (IP restriction, SSL, and so on) may be employed to protect the integrity of system transactions.

Microsoft's implementation of SOAP is distributed as the Microsoft SOAP Toolkit, currently at version 2.0. The toolkit uses the Web Services Description Language (WSDL) and Web Services Meta Language (WSML) to expose and link SOAP requests to the methods of COM objects.

COM Development

In a real-world scenario there would most likely be existing COM interfaces into the order processing system. Although simply publishing these existing COM interfaces might seem to be a viable and efficient way to rapidly implement the system, there are several reasons to create a brand-new SOAP-specific object:

• The existing interfaces will most likely not support the connectionless requests presented by SOAP requests.

• The internal interfaces will expose more functionality (for example, modifying customer records) than it is desirable to offer to outside clients.

• Proprietary internal systems tend to change and evolve over time. Even if the internal API is already adequate for SOAP requests, having external vendors write to an inter mediate interface allows flexibility when redesigning internal systems.

After the decision has been made to use the Microsoft SOAP Toolkit as the SOAP server platform and to develop a new SOAP-specific COM object to implement order processing, a COM development platform must be selected. A few common languages used to develop COM objects are Visual Basic, C++, and Borland's Delphi. Each of these languages has its own strengths and weaknesses.

Windows Scripting Components

However, one of the lesser-known (but very useful) COM development tools is the Microsoft Windows Scripting Component (WSC) platform. A WSC is an XML document that describes the registration information, properties, and methods of a COM object using XML. The code for the object is written in one of the scripting languages supported on your platform (such as VBScript, JScript, or even ActiveState's Perl scripting language). The WSC document may then be registered using regsvr32.exe like a regular COM object.

Support for WSCs is built into the latest Windows Scripting Host package, which can be downloaded from the Microsoft Web site. No special development environment (beyond a text editor) is needed. The OrderHandler component will be developed as a WSC component, written in VBScript.

Component Design

When designing a COM interface that will be called via SOAP, a few factors need to be taken into consideration.

Because each SOAP request is stateless, either the entire transaction must take place in one method call or the object must implement its own transactional support.

SOAP supports marshalling arguments of most basic types, but some consideration needs to be given to how much of a burden the marshalling will place on the SOAP client.

To keep the overall application and interface simple, the OrderHandler object will expose a single method, ProcessOrder(). ProcessOrder() will accept all the information for an order (per the “Requirements” section) and return a unique order ID if the transaction is successful.

Final Order Disposition

In a real-world application, the SOAP object would submit orders to the actual corporate order-processing system. For this example, the orders will be written to a Microsoft Access database using ActiveX Database Objects (ADO).