Defining the Solution

A. Datum is a growing company, and it understands the importance of avoiding poor design practices that can hamper growth. Database polling is a particularly good example of what not to do because it imposes a serious burden and prevents scalability beyond a small set of users.

With earlier programming technologies, instant notification would be unrealistic or prohibitively difficult and time-consuming to code. However, with .NET you can create a robust, high-performance solution with only a few ingredients: a central database, a client-servicing XML Web service, two independent Windows Forms applications, and a simple Message Queuing notification system. Figure 17-2 diagrams the proposed system, which is named Transact.NET.

Figure 17-2. The Transact.NET system with notification

graphics/f17dp02.jpg

Note that Message Queuing acts in addition to the basic infrastructure and isn't a key part of it. It notifies the client that a new order is available and indicates the order number. However, it doesn't try to send the full package of order information. This has several important consequences:

  • If the Message Queuing service fails, the application still works as designed. The only missing functionality is the instant notification.

  • Message Queuing is optional. If the order-filling client doesn't have an available message queue, it doesn't need to use this service.

  • Programming is vastly simplified, and scalability is ensured. If you try to use Message Queuing exclusively to route order information to the order-filling client, you face a number of dangers, including losing the order on the wrong computer, difficulty tracking in-progress orders, and the inability to move the order-filling client to another computer while it has outstanding orders.

  • The Message Queuing service can be easily replaced with a different notification method (such as events over .NET Remoting) without redesigning the entire solution.

On startup, the order-filling client registers its notification queue with the XML Web service. The XML Web service automatically sends a notification message when it receives an order, provided there is a registered queue. This loosely coupled design is conceptually similar to a callback, but as you've learned in this book, a callback isn't as easy or reliable when it needs to cross machine boundaries. Messaging, however, is a lightweight form of communication that quickly frees the ASP.NET worker thread so that it can handle new requests.

The order-filling client uses a background thread to monitor for new messages and maintains a list of available orders. The client can "check out" any orders that it intends to fill and then either return them to the pool or complete them and create a shipment record.

The external client doesn't require the same threading or messaging capabilities, but it does present an interesting way to use the DataSet. Pricing and product information is stored locally in an XML file that contains the serialized content of a DataSet. When the application starts, it checks this XML file (which has a server-assigned expiry date) and decides whether to download a new version from the XML Web service. The application then dynamically creates and fills Windows controls to represent the product options in the pricing file. This case study uses a simple version of the client that lacks basic capabilities such as saving and loading order files. However, it provides a good example of how you can distribute dynamically updated product and pricing information.



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