COM & .NET Component Services

Receiving Output from a Queued Component

Banishing all output options for a queued component would be too draconian and impractical. Sometimes expecting output from a queued component is appropriate. Consider the online shoe store. After the Shipment object ships the order, you would like it to notify another object about it. The Store object would like to pass in the Notification object as a parameter to the ShipOrder( ) method.

From a design perspective, it is a good idea to decouple the notification actions from the Shipment process itself. You should decouple the action to ensure that the Shipment object knows only about a generic notification interface and that it calls a method on it once the order is shipped. It is up to the Store object to decide which notification object to pass in as a parameter. You could have multiple implementations of the Notification interface—for example, one Notification object sends an email to the customer to say that the shoes are on the way and another also sends promotional material.

You have already seen that COM+ allows you to pass in interface pointers for objects that support the IPersistStream interface. COM+ also lets you pass in as a method parameter an interface pointer to another queued component. This technique is called Response Object because it allows the client to receive a response from the queued component and be notified about the results of the queued call. The response object does not need to support the IPersistStream ...