Contents
Overview 1
Introduction to Disconnected Business
Logic 2
Technologies 7
Demonstration: Queued Components 11
Demonstration: COM+ Events 15
Logical Design of Disconnected Business
Logic 19
Physical Design of Disconnected Business
Logic 26
Market Purchasing 42
Best Practices 45
Lab 7: Business Logic for Disconnected
Components 46
Review 54

Module 7: Business
Logic for Disconnected
Components

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

Build Coordinator: Eric Wagoner
Graphic Artist: Scott Serna
Test Lead: Eric Myers
Manufacturing Manager: John Williams
Group Product Manager: Juan Fernando Rivera
Lead Product Manager, System Services and Infrastructure: Edward Dudenhoefer
Manufacturing Manager: Rick Terek
Operations Coordinator: John Williams
Manufacturing Support: Laura King; Kathy Hershey
Lead Product Manager, Release Management: Bo Galford
Group Manager, Courseware Infrastructure: David Bramble
General Manager: Robert Stewart

Module 7: Business Logic for Disconnected Components iii Instructor Notes
In the preceding module, “Business Logic for Connected Components,” you
introduced students to cooperative processing among synchronous business
objects in an enterprise solution. This module provides students with an
introduction to cooperative processing among business components that are
disconnected in time and space.
After completing this module, students will be able to:
!
Describe the design and implementation of disconnected business logic and
how to apply design patterns to the design of business logic.
!
Describe the technologies used in implementing disconnected business
logic: COM+ queued components and loosely coupled events (LCE).
!

Lab:
60 Minutes
iv Module 7: Business Logic for Disconnected Components Demonstration
This section provides demonstration procedures that will not fit in the margin
notes or are not appropriate for the student notes.
Queued Components
To prepare for the demonstration
• Review the instructions in the student notes.

COM+ Events
!
To prepare for the demonstration
• Review the instructions in the student notes.

Module 7: Business Logic for Disconnected Components v Module Strategy
Use the following strategy to present this module:
!
Introduction to Disconnected Business Logic
The purpose of this section is to introduce students to the disconnected
business logic layer. The business needs of an application require its
interaction with other business applications. Frequently, these interactions
can be separated in time and space. Two business scenarios can summarize
the business requirements for loosely coupled mechanisms:
• Response is never required

In the topic “Queued Components and Transactions,” explain the concept of
a transaction in a disconnected logic environment and the need for a
compensating transaction. You can use the example of VA and BA to
explain that if BA returns a denial of a reservation you would need to add to
the application a compensating transaction. The compensating transaction
would reverse the confirmation of a VA flight since it is no longer
applicable if the connection from London to Tel Aviv cannot be made.
vi Module 7: Business Logic for Disconnected Components !
Physical Design of Disconnected Business LogicThe purpose of this section
is to introduce students to the physical design considerations of COM+
events and queued components.
!
Market Purchasing
The purpose of this section is to present the logical and physical designs of
the disconnected business logic of Market Purchasing and to explain the
justification for the choices made.
By using the Computer Management application, you can present the
mpVendors queue that is implemented by Market Purchasing. You can also
use Component Services to present the Market Purchasing Business Logic
COM+ application. By running the Monitor, Vendor, and Accounting
applications, you can demonstrate how the disconnected logic works in
Market Purchasing. You can present the Extensible Markup Language
(XML) files that are created when the accounting application is used. Or
you can show how the mpVendors queue receives messages when a vendor
sends notifications.
!
Best Practices

Market Purchasing
!
Best PracticesIn Module 6, “Business Logic for Connected Components,” you were
introduced to cooperative processing among synchronous business objects in an
enterprise solution. In this module, the focus shifts to cooperative processing
among business components that are disconnected in time and space.
After completing this module, you will be able to:
!
Describe the design and implementation of disconnected business logic and
how to use design patterns.
!
Describe the technologies used in implementing disconnected business
logic: COM+ queued components and loosely coupled events (LCE).
!
Create a physical design for a queued component.
!
Create a physical design for event notification.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about the disconnected
business logic layer and
how to create a logical

what makes up a business
logic layer and, in particular,
a disconnected business
logic layer.
Module 7: Business Logic for Disconnected Components 3 The Business Problem
Data Access Layer
Connected Business
Logic Layer
Disconnected Business
Logic Layer
Facade Layer
Web Services Facade Business Facade
Transactional DAL
Nontransactional DAL
User Services
External
ObjectsThere are many parts of a system that can be disconnected, or asynchronous.
Asynchronous requirements must be identified early, and the design must take
them into account.
Asynchronous Behaviors
Many aspects of a distributed system do not need to be synchronous. For
example, consider an order being placed by a customer. When the customer
clicks a button to enter the order, the business logic needs to save the order to a
database to record the purchase. The business logic also must send the order to

communication in the Market Purchasing sample application. Requisitions are
sent to vendors, but the Market Purchasing application cannot assume that
vendor systems are always connected and running. As a result, some sort of
disconnected business logic is necessary to communicate with systems in other
businesses.
Disconnected Business Logic Layer
The solution to dealing with asynchronous behavior is to create a disconnected
business logic layer. The disconnected business logic layer is parallel with the
connected business logic layer. In other words, the facades call both layers, and
each layer uses the data access layer (DAL).
The disconnected business logic layer receives requests from the business or
Web services facade layer, processes the requests, and passes additional
processing to external objects. The disconnected business logic components
must also implement techniques for retrieving the results from the external
objects and pass the results of the processing back to the facade layer.
Module 7: Business Logic for Disconnected Components 5 Business Requirements
!
Asynchronous Communication and Notification
!
Messaging and EventsIn an enterprise solution, communication or notification between business
objects that reside on different nodes that use synchronous protocols might not
always be the best solution:
!
The lifetimes of client and server cannot always be guaranteed to overlap.

disconnected business logic
layer.
6 Module 7: Business Logic for Disconnected Components Two business scenarios can summarize the business requirements for loosely
coupled mechanisms:
!
Response is never required
The client’s job is complete when the call has been made and the message
or notification is sent. This model works well for applications whose only
task is input.
!
Immediate response not required
In this scenario, the application does not require an immediate response, but
it expects some form of acknowledgement in the future. The application
might only require negative acknowledgements indicating that some error
has occurred, or it might require both positive and negative
acknowledgements. In either case, a separate asynchronous communication
can occur from the server to the client. The primary benefit of using
asynchronous communication or notification in this scenario is that end
users do not need to wait for a response if it is not required. (The response
might take time given potential network latency or server unavailability.)

Module 7: Business Logic for Disconnected Components 7 #
##
#

used to implement
disconnected business
logic.
8 Module 7: Business Logic for Disconnected Components Message Queuing
!
Supports Creating and Managing Queues
!
Supports Sending and Receiving Messages to Queues
!
Can Program Through API or COM ObjectsMessage Queuing is a rich set of run-time services that allow applications on
different computers to send and receive asynchronous messages. An object
creates a message and sends it to a queue. Another object can read the message
from the queue. The queue is a persistent storage area. As soon as the message
has been posted to the queue, the sending object can continue with other work
without waiting for the message to be read.
You use Message Queuing through an application programming interface
(API). By using the API, you can programmatically create queues, send
messages, receive messages, wrap messages in transactions, and secure
messages. You can also use a set of Component Object Model (COM) objects
called the MSMQ COM Components, which wrap the API. The MSMQ COM
Components simplify the API and allow you to send messages by using almost
any programming language. For more information about building applications
that use Message Queuing, see Course 1901A: Building MSMQ Applications
with Visual C++ 6.

Messaging Services:
!
Higher level of abstraction
!
Conventional component behavior
!
Choice of communication method

The COM+ queued component architecture is represented by three objects: a
Recorder, a Listener, and a Player.
The Recorder Object
The Recorder object is provided by the COM+ Queued Component service and
is conceptually similar to a standard COM proxy. The Recorder object
provides an implementation for all of the methods in the object’s interface.
However, the actual implementation is quite different. The Recorder object’s
implementation for each method accepts the input parameters and, rather than
firing them directly at the actual COM objects, records them into a message.
This process is repeated for each method call made by the client. When the
client deactivates the object, the COM+ Queued Component service uses
Messaging Services to send the message containing the recorded calls to the
server on which the actual COM object resides.
Topic Objective
To provide a review of
queued components.
Lead-in
In this topic, you will learn
about the physical design
issues for queued
components.
10 Module 7: Business Logic for Disconnected Components

3. Right-click COM+ Applications, point to New, and click Application.
4. In the Welcome to the COM Application Install Wizard dialog box, click
Next.
5. Click the Create an empty application button.
6. In the text box next to the label Enter a name for the new application,
enter the name Orders, and then click Next.
7. In the Set Application Identity dialog box, click Next.
8. Click Finish.
9. Select the Orders COM+ application.
10. Right-click Orders and click Properties.
11. Click the Queuing tab.
12. Select the Queued and Listen check boxes and click OK.

Topic Objective
To provide a demonstration
of queued components.
Lead-in
In this demonstration, you
will see how to use queued
components in an
application.
12 Module 7: Business Logic for Disconnected Components !
Install a Queued Component
1. In the left pane, expand Orders and Components.
2. Right-click Components, point to New, and click Component.
3. In the Welcome to the COM Component Install Wizard dialog box, click
Next.

Process Queued Component Messages
1. Return to the Component Services snap-in.
2. Select the Orders COM+ application.
3. Right-click Orders and click Start. A message box should appear with the
details of the order. Dismiss the message box by clicking OK.
4. Return to the Computer Management application.
5. Right-click the orders queue and click Refresh. The right pane should
indicate that there are no messages waiting. The message was delivered to
the queued component.

Module 7: Business Logic for Disconnected Components 13 COM+ Events Events in COM+ are based on an LCE model. The loose coupling is achieved
by introducing an intermediary between publisher and subscriber—namely, the
COM+ event service. The COM+ event service matches event subscribers with
event publishers. The event service maintains a database that lists subscribers
for a particular class of event. A subscriber wanting to subscribe to a particular
class of event contacts the event service, which adds a subscription record to the
database. When a publisher wants to fire an event, the publisher talks to the
event service. The event service searches the subscription database, contacts
each of the subscribers in turn, and forwards the event.
The publisher and subscriber architecture adopted by the COM+ Event Service
uses two components. First, an event class is used to represent the connection
between a publisher and a subscriber. Second, the COM+ Event Store within
the COM+ Catalog is used as a database for subscriptions.
The Event Class

subscriptions are maintained in the Event Store, but they do not survive
system restarts.
!
Per User
Per User subscriptions can only deliver events when the subscriber is logged
into the event system’s computer. When the subscriber logs off, the
subscriptions are disabled.

When an event fires, the event store is accessed, and each subscriber in the list
is contacted. COM+ forwards the event from the publisher to each subscriber.
Subscribers do not have to be running when an event is fired. The COM+ Event
Service will create instances of each subscriber component.
Filtering Events
Filtering events allows subscribers to be more selective with regard to the
events they receive. It also allows publishers to control exactly which
subscribers should receive events and the order in which the subscribers should
receive the events.
Module 7: Business Logic for Disconnected Components 15 Demonstration: COM+ Events The demonstration of COM+ events includes two Visual Basic COM
components. The first is eTicker, which has two functions, Up and Down, that
have no implementations, and the second is subTicker, which provides the
implementations for both Up and Down. The demonstration also includes a test
application, eTickerDemo.
These components demonstrate a scenario in which a stock price monitor
(eTickerDemo) can generate events when stock prices move up or down. The


12. Click Install new event class.
13. In the Select files to install dialog box, select the file eTicker.dll from the
directory install folder\Democode\Mod07\eTicker and click Open.
14. Click Next, and then click Finish.

!
Create a COM+ Application with a Subscriber Component
1. Right-click COM+ Applications, point to New, and click Application.
2. In the Welcome to the COM Application Install Wizard dialog box, click
Next.
3. Select Create an empty application.
4. In the Create Empty Application dialog box, enter subTicker as the new
application name, and then click Next.
5. In the Set Application Identity dialog box, click Next.
6. Click Finish.
7. In the left pane, expand subTicker and Components.
8. Right-click Components, point to New, and click Component.
9. In the Welcome to the COM Component Install Wizard dialog box, click
Next.
10. Click Install new component.
11. In the Select files to install dialog box, select the file subTicker.dll from the
directory install folder\Democode\Mod07\subTicker and click Open.
12. Click Next, and then click Finish.

!
Setup Subscriptions
1. In the left pane, expand subTicker.SubDemo and Subscriptions.
2. Right-click Subscriptions, point to New, and click Subscription.
3. In the Welcome to the COM New Subscription Wizard dialog box, click

1. On the Start menu, point to Programs, then point to Microsoft Visual
Studio 6.0, and then click Microsoft Visual Basic 6.0.
2. In the folder install folder\Democode\Mod07\eTickerDemo, open the Visual
Basic project eTickerDemo.vbp.
3. Run the application eTickerDemo.
4. Enter a ticker symbol MSFT and click Down.
You should see two message boxes displaying the message “MSFT has
moved down.” There is one message for each subscription.

The message boxes might appear behind other windows. If this
happens, a task will appear on the taskbar called subTicker. You can select
the subTicker task to display the message box.

5. Enter a ticker symbol INTC and click Up.
You should not get any message box. The INTC ticker symbol is filtered in
All Events.

Note
18 Module 7: Business Logic for Disconnected Components Combining Queued Components and Events You can combine the COM+ Event service with the Queued Component
service to make the publisher and subscriber achieve temporal independence.
You can publish events asynchronously (queuing between publisher and event)
or you can deliver events asynchronously (queuing between event and
subscriber).
To publish events asynchronously, you must introduce a queuing mechanism


In this section, the following design patterns that apply to the logical design of a
disconnected business logic layer will be presented: Observer and Queue.
In addition to the two design patterns covered in Module 6, “Business Logic for
Connected Components” (Iterator and State), the disconnected business logic
layer can use two behavioral design patterns: Observer and Queue.
An Observer behavioral design pattern defines a one-to-many dependency
among objects such that when one object changes state all of its dependents are
notified. Depending on whether notification happens automatically, an
Observer design pattern can be mapped either to events or to Extensible
Markup Language (XML) data structures, as you will see in detail in the
following topics. Observer objects are typically used in an enterprise solution
when there is a publisher with one or more subscribers waiting for a particular
event to occur.
A Queue behavioral design pattern defines a many-to-many dependency
between objects so that one or more objects post messages to a message queue
and all of their dependents can retrieve the messages from the same message
queue. Queue objects are used in enterprise solutions that require decoupling of
requests for a business service from multiple service providers that can handle a
request independent of the source for the request. For example, requesting fund
allocation for a requisition can be handled by a number of accounting services
providers.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
about the logical design for
disconnected business