Future Directions

The current solution meets all the requirements of the problem analysis. It allows disconnected clients to create orders and coordinates the workflow so that orders can be filled mere moments after they've been received. However, a number of additional features can be added to this basic infrastructure.

Adding Security

You might want to add increased security or a ticket-based authentication system, such as the one presented in the next chapter. This authentication code might make use of the customer GUID, which is present in the Customers database but isn't used.

Currently, the XML Web service takes one important precaution: it applies the current pricing to all submitted orders to prevent malicious clients from purchasing items at incorrect prices. However, there is no way to prevent nonregistered users from using the service and submitting invalid orders or just wasting server resources.

Adding Confirmation GUIDs

Another useful change would be to create a unique GUID value to identify orders. This GUID could be inserted into the order record and returned to the client as a confirmation value.

If you choose to implement this approach, make sure you identify orders with GUIDs, not just sequential numbers. You should never use the unique identity field as a confirmation number because it allows clients to make false order claims easily. For example, a client that receives confirmation number 200 might claim to have submitted order 201. However, a client that receives a GUID confirmation code such as 382c74c3-721d-4f34-80e5-57657b6cbc27 will have no idea what other confirmation codes are used by the system and won't be able to guess another valid value.

Supporting Multiple Order-Filling Clients

One of the most obvious changes you might make is to modify the OrderService so that it can support multiple order-filling clients. This change is quite easy; you just have to replace the notify queue string with a collection that contains multiple queue paths. The RegisterNotifyQueue method then adds or removes entries from this collection, using a SyncLock statement to prevent errors.

 <WebMethod()> _ Public Function RegisterNotifyQueue(ByVal queuePath As String, _   ByVal remove As Boolean)     Dim NotifyList As ArrayList = Application("NotifyQueueCollection")     SyncLock NotifyList         If Not remove Then             NotifyList.Add(queuePath)         Else             NotifyList.Remove(queuePath)         End If     End SyncLock End Function 

When an order is submitted, the OrderService would then step through the full list and attempt to send a message to each queue:

 Dim NotifyList As ArrayList = Application("NotifyQueueCollection") Dim QueuePath As String SyncLock NotifyList     For Each QueuePath in NotifyList         Try             Dim NotifyQueue As New MessageQueue(QueuePath)             NotifyQueue.Send(ID)         Catch Err As Exception             ' (Depending on the error, you might want to remove the             ' queue from the list here.)           End Try     Next End SyncLock 

You'll also need to make some minor modifications to the order-filling clients. For example, they need to prevent users from processing an order that is already being filled by another client. To support this feature, the logic in the SetOrderInProgress stored procedure needs to be tightened so that in-progress orders can't be requested, as shown here:

 CREATE Procedure SetOrderInProgress  (     @ID int  )  AS UPDATE Orders     SET Status = 1     WHERE ID = @ID AND Status = 0 

If no matching record is found, the stored procedure should refrain from returning any rows to the client. You can accomplish this by checking that the global SQL Server variable @@ROWCOUNT is 0. This variable always returns the number of rows affected by the most recent operation.

 IF @@ROWCOUNT = 1   BEGIN     SELECT * FROM Orders WHERE ID = @ID     SELECT * FROM OrderStations WHERE OrderID = @ID     SELECT * FROM OrderItems       INNER JOIN Products ON Products.ID = OrderItems.ProductID       INNER JOIN OrderStations          ON OrderStations.ID = OrderItems.StationID       WHERE OrderID = @ID   END 

The OrderDB.SetOrderInProgress method must then check how many records were updated by the command. If the command succeeds, it will return one affected row. If it returns zero affected rows, the database component should throw an error to notify the client. The client can interpret this error as indicating that the row is currently in progress, notify the user accordingly, and remove the item from the list.