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
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:
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. |