Contents
Overview 1
Introduction to Queued Components 2
Working with Queued Components 16
Lab 5.1 Creating and Using Queued
Components 35
Handling Events 39
Publisher and Subscriber Architecture 45
Working with Events 53
Lab 5.2: Creating and Using Event Classes 71
Combining Queued Components and
Events 77
Lab 5.3: (Optional) Combining Queued
Components and Events 83
Best Practices 90
Review 93

Module 5: Queued
Components and
Events

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may

applications that publish information with subscribers. For advanced students,
material is also provided to learn how to combine queued components and
events.
After completing this module, students will be able to:
!
Describe the purpose and benefits of queued components.
!
Create a queued component.
!
Instantiate and communicate with a queued component.
!
Describe the COM+ Events service provided with Microsoft Windows
2000.
!
Create and use an event class to match publishers with subscribers.
!
Combine queues with events to make the processing of publisher and
subscriber events time independent.

In the practice, students will learn to enable an application for queuing and view
application queues by using the computer management tool. ,Instructor-led
demonstrations are provided to illustrate how to create and register an event
class, create a subscriber component and add a subscription entry to COM+,
publish events, and finally filter events. A demonstration is also provided to
illustrate how queued components can be combined with events to publish and
deliver events asynchronously.
In the first lab, students will use COM+ queued components to place orders
asynchronously. In the second lab, they will use the COM+ events to create and
register an event class. In the optional lab, students will learn how to combine
queued components and events to make publisher and subscriber events time

!
Complete the practice, demonstrations, and labs.
!
Read the instructor notes and the margin notes for the module.

Module Strategy
Use the following strategy to present this module:
!
Introduction to Queued Components
Discuss the inherent problems associated with synchronous communications
in a distributed environment and highlight how a message-based form of
asynchronous communications, such as COM+ queued components, can
overcome many of these problems. The primary challenge is to provide a
reliable way for the various parts of an application to communicate.
Other issues that you should consider include unreliable or slow network
connections, remote disconnected users, and heterogeneous application
architectures. Discuss how queued components relate to the underlying
Microsoft Message Queue Server (MSMQ) technology. Present the
architecture of queued components and discuss the three system-provided
components: the recorder, the listener, and the player. Point out the
restrictions on interface design required by queued components.

!
Working with Queued Components
Discuss how to use queued components to manage the communication that
occurs between the various parts of an enterprise application. Explain how
to view, instantiate, and create queued components. Discuss how to
communicate with and receive output from queued components. Finally,
describe how to use the COM+ queued component service to handle
transactions and security.

Explain that the COM+ Event service is used to advertise and deliver
information to one or more interested parties without a prior knowledge of
their identity. The COM+ Event service acts as an intermediary between
information publishers and subscribers. As an intermediary, the COM+
Event service addresses some of the weaknesses associated with other
methods for handling COM events, such as the tight coupling approach used
in Visual Basic. Explain the critical role of the event class and that
subscribers must implement the interfaces exposed by the event class. Also
explain that the system provides an implementation of the event class,
which searches the event store and forwards event notifications to each
subscriber in turn.

!
Working with Events
Explain how to create and register event classes, subscribe to events, and
publish events. Events can also be filtered so that subscribers can be
selective about what events they should receive. Discuss the two primary
methods of filtering: subscriber filtering and publisher filtering. Explain the
advantages of declarative publisher filtering over run-time publisher
filtering (that is, the ability to use the solution with queued components and
the fact that the publisher code does not need to be modified).
vi Module 5: Queued Components and Events !
Combining Queued Components and Events
Discuss how the COM+ Event service can be combined with the Queued
Component service to make the publisher and subscriber time independent.
Events can be published asynchronously (by queuing between publisher and
event object) or events can be delivered asynchronously (by queuing

onto each subscriber registered in the COM+ Event Store. It also highlights that
each subscriber must provide an implementation of the event interface to
“handle” each event.
!
To prepare for the multimedia presentation
!
To show this animation, double-click the file 1907A_05a010.avi.

Module 5: Queued Components and Events vii Demonstrations
This section provides demonstration procedures that will not fit in the margin
notes or are not appropriate for the student notes.

These instructions assume that the demonstrations will be performed in
sequence.

Queued Components
The purpose of this demonstration is to show how to enable an application and
a component for queuing and to show how the Queue moniker is used to
instantiate a queued component.
!
To perform the demonstration
1. Open the project QCServer.vbp located in <install
folder>\Democode\Mod05\Queued Components\Server. Describe to the
students how the Server class module contains one method that simply
displays the supplied message via a message box.
2. Select Make QCServer.dll from the File menu to generate the QCServer
component.

15. Nothing visible will happen at this point because the QCServer application
is not currently running. However, point out that a message will have been
delivered to the QCServer application’s queue.
16. Press the Send Message button again to generate a second message.
17. Using the Computer Management tool, view the contents of the QCServer’s
application queue. Two messages will currently be in the queue.
18. Using the Component Services tool start the QCServer application.
19. Two message boxes will be displayed that contain the text parameter passed
from the test harness: “Hi There!” Explain that the listener component
within the QC Server application detected the messages in the queue,
dequeued them, forwarded them to the player (which then instantiated the
QCServer object), and called the method.
20. Click OK to dismiss both message boxes.

Creating and Registering an Event Class
The purpose of this demonstration is to show how to create an event class by
using an ActiveX DLL project and an abstract class module. The purpose of the
class module is to simply define each function in the event class interface.
Having created the event class DLL, this demonstration shows how to install
the event class component into a COM+ application.
This demonstration uses a simplified version of an event class that might be
used by an Electronic Point of Sale (EPOS) stock management system. As such,
the event interface provides two methods: LastItemSold and
NewOrderPlaced.
!
To perform the demonstration
1. Open the stock event class project StockEventClass.vbp located in <install
folder>\Democode\Mod05\Events\EventClass.
2. Describe to the students that the IStockEvents class module is an abstract
class module in that it contains public functions definitions but no

project with class modules that use the Implements keyword to provide a
concrete implementation of the event class interface. The demonstration
proceeds to show how subscription records are entered into the COM+ Event
Store. Two subscribers are provided.
!
To perform the demonstration
1. Open the first event subscriber project EventSubscriber.vbp located in
<install folder>\Democode\Mod05\Events\Subscriber.
2. View the StockEventSubscriber class module and illustrate the use of the
Implements keyword. Point out that the class module must provide
concrete implementations for all of the methods defined in the interface
being implemented. Also highlight the fact that a project reference has been
set to the StockEventClass type library.
3. Select Make EventSubscriber.dll from the File menu to build the subscriber
component.
4. Repeat the previous three steps for the EventSubscriber2.vbp project. This
process will create a second subscriber component. (When these subscribers
are called, the resulting message boxes displayed by their implementation
code will reflect the identity of each subscriber by displaying the
appropriate subscriber number in the message box title bar).
5. By using the Component Services tool, create a new COM+ application
called EPOS Subscriber. Select the default options when creating this
application.
6. Add the two subscriber components to the application by using the regular
Install new component(s) button of the Component Install Wizard.
7. Expand both components within the Component Services tree view to
display the two Subscriptions folders.
8. You will now create a new subscription record in the COM+ Event Store.
Select the Subscriptions folder of the first subscriber, right-click, point to
New, and then point to Subscription.

1. Open the stock event publisher project StockEventPublisher.vbp located in
<install folder>\Democode\Mod05\Events\Publisher.
2. Show the application’s main form and explain that the Item Sold button
fires a LastItemSold event while the Product Ordered button fires a
NewOrderPlaced event.
3. Explain that the Publish Asynchronously check box is used in a future
demonstration when events are intended for asynchronous publication using
queued components. (For the current demonstration, you should leave this
check box unselected).
4. Examine and explain the code behind each button. Explain that to publish an
event, you must create an instance of the event class and then call methods
on the event class’s interface to fire events. The event class is created in the
CreateEventObject private function because this approach allows control
over whether the object is created in the standard fashion (by using the New
keyword) or created via a Queue moniker for asynchronous method
publication. (This determination is made by setting the Publish
Asynchronously check box).
5. Select an item from the Products list and click the Item Sold button.
6. A message box will be displayed with the title box indicating which
subscriber has been invoked. (Beware that the message box may not come
to the foreground and may appear on the task bar).
7. Click OK to remove the message box.
8. A second message box from the other subscriber will appear. Click OK to
remove this message box. Stress that the order of delivery is determined by
the system, and if the order of delivery is important, you will have to write a
publisher filter component.
Module 5: Queued Components and Events xi 9. Return to the Component Services tool and select the Fire in parallel

of events relating to product ID number 1. Point out that the lngProductID
symbol is used in the event class’s type library and that any symbol in this
type library, together with relational and logical operators and parentheses,
can be used in this expression. Explain that the subscriber will only receive
event notifications when the supplied expression evaluates to True.
7. Return to the Stock Event publishing application, select the first item in the
list, and press the Item Sold button.
8. Two message boxes should appear because the first item in the list has a
product ID of 1.
9. Press OK to dismiss both message boxes.
10. Select the second item in the list and press the Item Sold button.
11. A single message box from Subscriber 1 will be displayed. Subscriber 2 has
not received the notification due to the filter. The second item in the list has
a product ID of 2.
12. You have now demonstrated subscriber filtering.

xii Module 5: Queued Components and Events Combining Queued Components with Events
The purpose of this demonstration is to show how queued components can be
combined with events to make the publisher and subscriber time independent.
This demonstration illustrates how queuing can be used between publisher and
event classes to enable asynchronous event publication. It also shows how it
can be used between the event class and subscriber to enable asynchronous
event delivery.
!
To perform the demonstration
1. Using the Component Services tool, select and then right-click the EPOS
Stock Events application and select Properties.

asynchronously, you will now mark the subscription as queued and queue-
enable the subscriber’s application and interfaces.
18. By using the Component Services tool, expand the EPOS Subscriber
application and then expand the Components folder.
Module 5: Queued Components and Events xiii 19. Expand the first subscriber component
(EventSubscriber.StockEventSubscriber) and expand its Subscriptions
folder to show the First EPOS Event Subscription.
20. Select and then right-click the First EPOS Event Subscription, and select
Properties.
21. On the Options tab, place a check mark in the Queued check box. Explain
that this check mark sets the SubscriberMoniker property on the
subscription record within the event store and updates it with the Queue
moniker. The Queued option causes the system-generated event class
implementation code to instantiate the subscriber component by using the
Queue moniker.
22. Press OK to dismiss the Properties dialog box.
23. Repeat steps 19 to 22 to mark the subscription record for the second
subscriber as queued.
24. You must now mark the _IStockEvents interface on each subscriber
component as queued.
25. Expand the Interfaces folder beneath the first subscriber component
(EventSubscriber.StockEventSubscriber).
26. Select and then right-click the _IStockEvents interface and select
Properties.
27. On the Queuing tab, place a check mark in the Queued check box.
28. Press OK to dismiss the Properties dialog box.
29. Repeat steps 25 to 28 to mark the second subscribers _IStockEvents

#

Overview
!
Introduction to Queued Components
!
Working with Queued Components
!
Lab 5.1: Creating and Using Queued Components
!
Handling Events
!
Publisher and Subscriber Architecture
!
Working with Events
!
Lab 5.2: Creating and Using Event Classes
!
Combining Queued Components and Events
!
Lab 5.3: (Optional) Combining Queued Components and Events
!
Best Practices and ReviewIn this module, you will learn how to use COM+ queued components to provide
message-based asynchronous communication between the various parts of your
application. A communication system based on messages will help you
overcome some of the key problems encountered when building enterprise
solutions.

provide message-based
asynchronous
communication.
2 Module 5: Queued Components and Events #
##
# Introduction to Queued Components
!
Asynchronous Communication
!
Microsoft Message Queue Server vs. Queued
Components
!
Architecture of Queued Components
!
Animation: COM+ Queued Components In this section, you will learn how you can use COM+ queued components to
solve some of the fundamental problems associated with developing enterprise
solutions. The primary challenge is to provide a reliable way for the various
parts of an application to communicate. Other issues that you should consider
include unreliable or slow network connections, remote disconnected users, and
heterogeneous application architectures.
This section includes the following topics:
!
Asynchronous Communication
!

unavailable when a client wants to communicate with it. For example, the
server computer may be offline for planned (or unplanned) maintenance.
!
The network connection linking client to server may not always be working.
If the network connection linking client to server is unavailable, a
synchronous call will fail. There can be no guarantees that network links
will be 100 percent reliable, particularly in a distributed systems
environment.
!
The network latency associated with the wide area connection cannot be
predicted.
A client using a synchronous protocol will block communications while
waiting for a response from the server. As a result, increased network
latency, perhaps due to excessive traffic loads or inadequate bandwidth, can
have a severe impact on the responsiveness of the client application. The
client cannot predict how long the server will take to receive, process, and
return the call.

Messaging and Asynchronous Communication
As an alternative to synchronous communication, consider the approach of
using asynchronous communications based on messages. With a messaging
approach, applications on different computers communicate with one another
by passing messages.
4 Module 5: Queued Components and Events
Message-based communication, such as that provided by Microsoft Message
Queue Server (MSMQ), eliminates the need for the client to wait for the
server’s response. The client simply calls the server by sending it a message and

Advantages of Asynchronous Communication
Asynchronous communications offer a number of advantages when building
distributed applications.
Advantage Description

Facilitates
development
It is easier to write most distributed applications if you do not
need all the participants to be running simultaneously. An
asynchronous approach based on messages allows one
application to send a message to another regardless of whether
the destination application is running. If the destination
application is not available, the message is queued and held in
a storage area. It will be processed by the destination
application when it subsequently starts.
Improves
performance
A synchronous communications approach forces a client
application to wait for a response from a server, whether or not
a response is actually required. On slow networks, this wait can
result in significant delays. An asynchronous approach allows
the client application to communicate with the server and then
carry on processing immediately.
Enhances reliability A distributed application built by using asynchronous
messaging is more resilient to failure. For example, an
application using messaging queuing can continue to function
despite network failures and offline servers. The messages
destined for a server application are queued and subsequently
forwarded to the application when the network connection
resumes or the server comes back online.

with another. You can determine the appropriate communication model,
asynchronous or synchronous, by the particular scenario used in your
application.
!
Immediate response always required
An application that requires an immediate response for every call is not
suited to asynchronous communications. In this scenario, do not force an
asynchronous solution; instead, use regular COM communications.
!
Response is never required
This application scenario is ideal for one-way asynchronous
communications. The client’s job is complete when the call has been made
and the message sent. This model works well for applications whose only
task is input. For example, a clerk working in a goods inward department
and carrying a handheld PC performs input recording only. After
notification has been dispatched informing the clerk that the particular
goods have arrived, the clerk requires no further confirmation.
!
Immediate response not required
In this scenario, the application requires responses to a communication at
some point in the future. This hybrid scenario is also suited to asynchronous
communications, specifically to a form referred to as two-way asynchronous
communication. In this scenario, the application does not require an
immediate response, but expects some form of acknowledgement at some
time in the future. The application may only require negative
acknowledgements indicating that some error has occurred, or it may
require both positive and negative acknowledgements. In either case, a
separate asynchronous communication can occur from the original server to
client.
One important point regarding this scenario is that the server must have

Message Queuing infrastructure, it is important to understand the differences
between the two technologies. Using queued components offers a number of
advantages over directly using Message Queuing.
Microsoft Message Queue
Message Queuing is a rich set of run-time services that allows applications on
different computers to send and receive asynchronous messages back and forth.
An application wanting to receive messages creates a queue, the location and
identity of which is known to the operating system. The queue is simply a
persistent storage area conceptually similar to a mailbox.
An application wanting to send a message to another application locates the
queue either through system services or by application-based foreknowledge
and uses Message Queuing to send the message. The message may pass through
one or more intermediate nodes before reaching its destination. A system
administrator configures the network topology.
Message Queuing supports the following features.
Feature Description

Guaranteed “exactly
once” delivery
This feature ensures that only one copy of the message will
arrive at the destination. Intermediate queues between client
and server may be used to ensure that messages do not get lost
if network errors occur. It also means that either the client or
the server (or possibly both) may be offline while a message is
in transit and it is still guaranteed to arrive.
Module 5: Queued Components and Events 9 Feature Description


back either in the component that sends the message or the
component that receives the message. For example, if an
application updates a database and sends a message to another
application within a transaction, any abort condition causes the
database updates to roll back. Message Queuing also rolls back
the send operation. For more information about this feature, see
Queued Components and Transactions in this module.
Programmable
Object Model
Message Queuing provides an Automation object model that
enables you to program both the sending and receiving
application.
Two queue types Message Queuing supports recoverable and express queues.
Messages sent by using recoverable queues are committed to
disk for reliability while in transit. Express queues use RAM
for speed.

Queued Components
The COM+ Queued Components service builds on the Message Queuing
infrastructure. However, when you work with queued components, the
underlying detail of Message Queuing is hidden.
A client application creates a queued component in much the same way it
would any other component. The queued component exposes a COM interface
that looks similar to other COM interfaces. The client is free to call methods on
this interface in the same way that it is for a regular COM interface. The main
difference arises from the underlying communications mechanism used to
deliver the method parameters. Traditionally, distributed COM uses
synchronous remote procedure calls (RPC) to send the bytes from one computer
to another, as shown in the following illustration.
10 Module 5: Queued Components and Events

Sub SendOrderAndGetOrderNum( ByVal ProductID As Long,
ByVal Quantity As Integer,
OrderNum As Long )
versus
Sub SendOrder( ByVal ProductID As Long,
ByVal Quantity As Long )Interface Design Issues
When you use queued components in your application, the component interface
design is subject to a few restrictions.
!
Parameters must be passed by value, not by reference.
Microsoft Visual Basic passes parameters by reference unless explicitly
instructed to do otherwise. Passing parameters by reference means that any
variable passed to a method can be changed by the method, and the calling
routine will see the change when the method call returns. In a distributed
scenario (in which client and server are in separate processes or on separate
computers), the value of the parameters must be transmitted from client to
server and back again. This parameter transmission process is referred to as
marshaling.
With queued components or with any asynchronous communication
scenario, there is no guarantee that the client will still be running when the
server processes the method call. As a result, it is not possible to send
parameter values back from the server to the client. All interfaces must be
unidirectional.