Queued Components allow you to create components that can execute immediately if the client and server are connected. They provide an easy way to invoke and execute components asynchronously. If the client and server are not connected, the component can hold execution until a connection is made. By using method calls similar to those calls used in component development, withdrawing the need for a comprehensive knowledge of marshaling Queued Components supports the developer. You can use Queued Components to build COM+ applications that are not time-related. Using messaging and queuing helps your applications handle the disconnected client case; it can also increase reliability and scalability.
Queued components have enormous implications for enterprise application development, particularly for disconnected client applications and those running on personal digital assistants. If a server component is not available, Windows will queue execution on the client computer. It's a whole new way of implementing components, in which you can no longer count on a component being available in memory at the time of the call, either on the local or a remote computer. There are some remarkable possibilities with this feature, but they require completely rethinking application design. Queued Components, a key feature of COM+ and based on Microsoft Message Queuing Services (MSMQ), provides an easy way to invoke and execute components asynchronously. Processing can occur without taking into account the availability or accessibility of either the sender or receiver. A small shopping network is a model of the type of application that might advantage from asynchronous processing. In this asynchronous, disconnected scenario where viewers’ phone in to several operators, orders are taken en masse and are then queued for later retrieval and processing by the server.
When designing new applications, developers must consider the implication of coding components for real-time (or synchronous) processing against queued (or asynchronous) processing. Eventually, the choice depends on the requirements of the specific application and determining which method better serves the underlying business logic of the application. Using queued processing offers advantages for certain applications, while writing an application using real-time, synchronous processing could be the best choice for another application. As an instruction, ‘queued processing’ offers the subsequent advantages over real-time processing:
- Component Availability
- Component Lifetime
- Disconnected Application
- Message Reliability
- Server Scheduling
Better Queuing Foundation
Before XP and COM + 1.5 under COM+ 1.0 Queued, components needed the existence of a domain controller to give authentication for the queued request. This means, if you do not have a domain controller, you have to shut down COM+ 1.0 application authentication. COM+ 1.5 gives an authority to improved configurable security verify for queued request through sorting them out from normal synchronous calls. The application Queuing tab now lets you configure authentication for queued calls explicitly.
Improved queuing support helps you to manage the maximum number of simultaneous player components the application can have. As every player component is created on a separate thread, there is unsurpassed operating cost linked with generating and maintaining a player component. In deep situations, your application may grind to a stop the progress if the number of matched player components is too large. The Queuing tab also lets you to manipulate Microsoft Message Queuing (MSMQ) domain controller authentication once the application is configured to use authentication for synchronous calls. Never authenticate queued calls into this application. Choosing this option lets you to openly use queued components without a domain controller. Continuously, authenticate incoming queued calls, not considering of the application authentication setting.
When you put a limit to the number of player components and that limit is reached, the listener does not generate new player components. Preferably, queued calls remain in the application queue, allowing calls in progress to execute and complete. The limit is also good for load balancing purposes, and can be used in concurrence with application pooling.
Comments