Defining the Problem

A. Datum Corporation is a computer vendor with a difference. It specializes in complex setups for server-based computers. A. Datum deals primarily with orders from local software companies in the area. (A. Datum's office is located in the heart of Silicon Valley.)

A. Datum has been using an informal model in which orders are placed by phone. Upon receiving an order, the sales staff informs the production staff immediately by phone and sends an internal e-mail with full details. Wherever possible, orders are processed in a matter of hours and sent by courier the very same day. The sales staff also logs order records to an internal database hosted by Microsoft SQL Server, but there is no process in place to ensure that this step is taken. The production staff doesn't interact with the SQL Server database at all; instead, they receive the order information through internal e-mail.

Now A. Datum is growing, primarily because it has a reputation for meeting orders with record speed. Management is well aware that the current infrastructure can't handle their growing needs. They don't have enough employees to create a dedicated call center to handle incoming orders, and they need to enforce a more consistent, standardized approach. However, A. Datum is unwilling to surrender its reputation for the fastest possible response times. Their challenge is to implement a system that enables them to have this instantaneous notification without sacrificing scalability and to have the ability to grow the organization if it meets with continued success.

Fortunately, A. Datum also has a considerable amount of in-house development expertise. Therefore, it can handle a more complex system than a less tech-savvy company might. In fact, A. Datum developers have already begun to develop a test version of a Windows ordering client to distribute to interested parties. A. Datum hopes that this application will become the standard order-submission tool used by its clients. The company could use ASP.NET to allow clients to submit orders, but it has avoided this option because it limits the functionality the application can provide. In the future, A. Datum would like to add tools such as wizards and network diagramming to help clients specify the configuration for the extremely technical systems they order. A. Datum also wants to enable clients to draw up orders without an Internet connection. Both of these considerations have steered the company toward Windows Forms.

Key Analysis

A. Datum isn't seeking a traditional solution. It has specific needs and wants to gain a competitive edge with a slightly unusual approach.

The traditional approach to this type of application would be to create a simple ASP.NET Web site for order submission and an internal Windows client for order fulfillment. The Windows client would probably not receive individual order notification. Instead, it would query the database for outstanding orders at the user's request. Figure 17-1 shows this model.

Figure 17-1. A centralized system with an XML Web service

graphics/f17dp01.jpg

However, A. Datum isn't interested in this approach. It wants the internal client to be alerted immediately if an order exists. This alert will enable the production staff to begin working immediately. Currently, this notification is performed by a phone call, which raises numerous potential problems, including the possibility that the order the company fulfills won't exactly match the order entered in the database, which can lead to future inventory, invoicing, and accounting headaches. To avoid these problems, A. Datum needs to centralize their workflow around the database.

The easiest part of the design to implement is the client application for submitting orders. A. Datum already has a clear idea about how it wants this application to function. The client application will periodically download a price-information file and then use this information file to tailor its user interface. The client configures an order using the downloaded price information, and then submits the order through an XML Web service hosted by A. Datum.

The key question is determining the ideal method for notifying the internal client about new orders. Some possibilities include:

  • Poll the database at a regular interval. This is one of the least scalable approaches. It can impose a significant burden on the database if the polling is performed frequently and by several clients. (In this case, the database usage is analogous to a denial-of-service attack.)

  • Add a database trigger that creates a file when a record is inserted. This is really a "code-around" tactic rather than a real solution. It can't distinguish between records added for different reasons (for example, order records that have already been fulfilled), and it requires the client to poll a directory on the server.

  • Use an order XML Web service that sends a message via Message Queuing. This approach has a low overhead and doesn't require excessive coding.

  • Use an order XML Web service that sends a message via .NET Remoting. This approach is fairly easy to implement, but it requires more code to deal with potential connection and serialization errors.

The last two options represent the most reasonable choices for A. Datum. They offer similar performance, but the Message Queuing option is the least complicated to implement and therefore has the least possibility for error. Message Queuing is also supported by their internal network environment, and will work over a company firewall that could thwart a TCP Remoting channel.



Microsoft. NET Distributed Applications(c) Integrating XML Web Services and. NET Remoting
MicrosoftВ® .NET Distributed Applications: Integrating XML Web Services and .NET Remoting (Pro-Developer)
ISBN: 0735619336
EAN: 2147483647
Year: 2005
Pages: 174

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net