Tài liệu Module 7: Business Logic for Disconnected Components ppt

Module 7: Business
Logic for Disconnected
Components
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


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
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual

property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.
 2000 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, ActiveX, BackOffice, BizTalk, FrontPage, Microsoft Press, MSDN,
MS-DOS, PowerPoint, Visio, Visual Basic, Visual C++, Visual InterDev, Visual J++, Visual
Studio, Win32, Windows, and Windows NT are either registered trademarks or trademarks of
Microsoft Corporation in the U.S.A. and/or other countries.
Other product and company names mentioned herein may be the trademarks of their respective
owners.
Program Managers: Rhy Mednick, Susie Parrent
Instructional Designer: Susie Parrent
Subject Matter Experts: David Chesnut, Sam Gill (TechnoWiz), Michel Pahud
Media Management: David Mahlmann
Editing Manager: Lynette Skinner
Editor: Mick Alberts, Jennifer Linn
Production Manager: Miracle Davis
Print Coordinators: Linda Lu Cannon (Write Stuff), Marlene Lambert (Online Training
Solutions, Inc.)
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
Presentation:
90 Minutes
Lab:
60 Minutes

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).

!

Create a physical design for a queued component.

!

Create a physical design for event notification.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.

Required Materials
To teach this module, you need the following materials:
!

Microsoft® PowerPoint® file 1910A_07.ppt

!

Module 7: Business Logic for Disconnected Components

!

Lab 7: Business Logic for Disconnected Components

Preparation Tasks
To prepare for this module, you should:
!

Read all of the materials for this module.

!

Complete the lab.


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 ComponentsTo 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
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 expects some form of acknowledgement at some time in the future.
In the topic “The Business Problem,” illustrate disconnected business logic
by using SneakerNet as an example. Point out that when using SneakerNet
you can pass files but you don’t guarantee delivery. Contrast this with using
Message Queuing, where delivery is guaranteed.
In the topic “Business Requirements,” illustrate the interaction with the
following example. If you are planning a trip from San Francisco to Tel
Aviv, you can book your flight with Vigor Airlines (VA) and Blue Sky
Airlines (BA). VA would be your carrier from San Francisco to London,
and BA would be your carrier from London to Tel Aviv. VA acts as your
primary agent and can confirm your reservation on its flights but cannot
confirm your reservations on BA. VA can send a message to BA to ask for
confirmation. The BA system will subsequently confirm or deny your
reservation and notify VA accordingly.

!

TechnologiesThe purpose of this section is to introduce students to Message

Queuing, queued components, and COM+ events. Spend time
demonstrating queued components and COM+ events and answering
student questions about these two demonstrations.
In the topic “Message Queuing,” continue using the VA/BA example to
explain the operation of message queuing.

!

Logical Design of Disconnected Business LogicThe purpose of this section
is to introduce students to the two design patterns that can be used in the
logical design of disconnected business logic: Observer and Queue.
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
The main message presented in this section is to use the power of queues for
disconnected business logic. While events are important, the fact that you
can only use them on-node makes them too restrictive.

Lab Strategy
!

Lab 7: Business Logic for Disconnected Components
The purpose of Lab 7 is for students to learn to design disconnected
business logic. Students probably will not derive answers that correspond
exactly to the Market Purchasing design. This is acceptable as long as the
student answers are justified and reflect the principles discussed in the

module. Discuss with students their answers to Lab 7.


Module 7: Business Logic for Disconnected Components

1

# Overview
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
design and a physical
design for it.

!

Introduction to Disconnected Business Logic

!

Technologies

!

Logical Design of Disconnected Business Logic

!

Physical Design of Disconnected Business Logic

!

Market Purchasing

!

Best Practices

In 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.


2

Module 7: Business Logic for Disconnected Components

# Introduction to Disconnected Business Logic
Topic Objective

To provide an overview of
the section topics and
objectives.

Lead-in

!

The Business Problem

!

Business Requirements

In this section, you will learn
what makes up a business
logic layer and, in particular,
a disconnected business
logic layer.

Disconnected business logic allows logical business objects and physical
business components to cooperate even though they are separated by time and
perhaps space. The temporal separation is called asynchronous behavior. This
behavior manifests itself in business logic that makes calls on other business
logic objects and does not wait for the results.
In this section, the disconnected business logic layer will be placed in the
proper context of the business problem. A discussion of the business
requirements for disconnected business logic will follow.


Module 7: Business Logic for Disconnected Components

3

The Business Problem
Topic Objective

User Services

To provide background
about the business problem.

Lead-in

In this topic, you will learn
about the business problem
facing designers that need
to implement a business
logic layer.

Facade Layer
Web Services Facade

External
Objects

Business Facade

Disconnected Business
Logic Layer

Connected Business
Logic Layer

Data Access Layer
Transactional DAL

Nontransactional DAL

There 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
the shipping department to ship the goods on the order to the customer.
However, the customer is not expecting that the order be shipped immediately,
nor does the customer need to be aware of how the order is handled internally
by the system. The only synchronous response expected by the customer is that
the order be placed successfully. Consequently, the order does not need to be
sent to the shipping department immediately. It could be placed in a queue until
the shipping department gets a chance to process the order.
Sometimes a system requires asynchronous behavior. For example, when a
requisition is entered into the Market Purchasing sample application, the
requisition is saved. If the requisition is greater than a certain amount, it
requires manager approval. Because no manager can be expected to monitor the
system 24 hours a day, the approval must wait until the manager logs on to the
Market Purchasing application. This behavior is by nature asynchronous and
requires disconnected business logic to be implemented.


4

Module 7: Business Logic for Disconnected Components

Physical Barriers
The separation between systems might be so great that synchronous responses
might not be feasible. Such is the case with business-to-business
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
Topic Objective

To provide background
about business
requirements.

Lead-in

!

Asynchronous Communication and Notification

!

Messaging and Events

In this topic, you will learn
about the business
requirements for a
disconnected business logic
layer.

In 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.

!

The network connection that links client to server cannot always be
guaranteed to be working.

!

The network latency associated with the wide-area connection cannot be
predicted.

As an alternative to synchronous communication or notification, consider the
approach of using asynchronous communications based on messages or
notification based on events. With either approach, business objects on different
nodes communicate with one another by passing messages or events through a
third party messaging service or a notification service. The interaction between
business objects is mitigated through a third party that ensures delivery.
In this enterprise solution scenario, message-based communication 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 then continues with other processing.
The message is stored in a holding area or queue until the receiver is ready to
process it. Similarly, event-based notification eliminates the need for the
listener to be active when the event occurs.
Asynchronous mechanisms are sometimes referred to as loosely coupled
because various pieces of the process are independent of one another.
Additionally, the client and server might have independent lifetimes.


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

# Technologies
Topic Objective

To provide an overview of
the section topics and
objectives.

Lead-in

In this section, you will learn
about the Microsoft

technologies that can be
used to implement
disconnected business
logic.

!

Message Queuing

!

Queued Components

!

COM+ Events

!

Combining Queued Components and Events

In this section, you will learn about the Microsoft® technologies that can be
used to implement disconnected business logic. First, you will learn about
Microsoft Message Queuing, which allows you to create queues to send and
receive messages. Second, you will learn about queued components, which
allow you to call components while disconnected from them. Third, you will
learn about COM+ events for sending notifications and events. Finally, you will
learn how to combine queued components and events for sending notifications
in a disconnected manner.

8

Module 7: Business Logic for Disconnected Components

Message Queuing
Topic Objective

To provide an overview of
queued components.

Lead-in

In this topic, you will learn
about the features of
Message Queuing.

Delivery Tip

You might want to remind
students that Message
Queuing was formerly
referred to as Microsoft
Message Queue Server
(MSMQ).

!

Supports Creating and Managing Queues

!

Supports Sending and Receiving Messages to Queues

!

Can Program Through API or COM Objects

Message 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.


Module 7: Business Logic for Disconnected Components

9

Queued Components

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.

The COM+ Queued Components service builds upon the Messaging Services
infrastructure. A client application creates a queued component in the same way
that it would any other component. The queued component exposes a COM
interface that looks similar to any other COM interface. The client is free to call
methods on this interface in the same way as it would for a regular COM
interface. The main difference arises from the underlying communications
mechanism used to deliver the method parameters. With queued components,
the communication between the client-side proxy and the server-side stub is
handled by Messaging Services.
Using COM+ Queued Components offers three advantages over directly using
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.


10

Module 7: Business Logic for Disconnected Components

The Listener and Player Objects
When the message arrives at the server, the recipient application uses a
Listener object provided by the system to detect the inbound message.
Messaging Services are then used to read the message, and a Player object is
activated. The Player object creates the actual COM object and plays the

recorded calls into it. If the server application is not active when the message
arrives, the message will be stored in the application’s queue. When the
application is subsequently started, it can retrieve and process any awaiting
messages.


Module 7: Business Logic for Disconnected Components

11

Demonstration: Queued Components
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.

This demonstration includes a Microsoft Visual Basic® client, OrderClient,
that places an order consisting of first name, last name, address, and product ID
to a queued component. The queued component, called qcOrder, will display a
message box indicating that it received the order after it is started.
To run this demonstration, execute the following steps:

! Create a Queued COM+ Application

1. On the Start menu, point to Programs, then point to Administrative
Tools, and then click Component Services.
2. In the left pane, expand Component Services, Computers, My Computer,
and COM+ Applications.
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.


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.
4. Click Install new component.
5. In the Select files to install dialog box, select the file qcOrder.dll from the
directory install folder\Democode\Mod07\qcOrder and click Open.

6. Click Next in the Install New Components dialog box.
7. Click Finish.
8. Expand the folders Orders, Components, qcOrder.Order, and Interfaces.
9. Select the _Order interface.
10. Right-click the _Order interface and click Properties.
11. Click the Queuing tab.
12. Select the Queued check box and click OK.

! Call a Queued Component
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\OrderClient, open the Visual
Basic project OrderClient.vbp.
3. Run the OrderClient application.
4. Enter a First Name, Last Name, Address, and Product ID. Then click the
Place Order button.
5. On the Start menu, point to Programs, then point to Administrative
Tools, and then click Computer Management.
6. In the Computer Management application, expand Services and
Applications, Message Queuing, Public Queues, and orders.
7. Right-click the Queue messages folder and click Refresh. The right pane
should indicate that there is one message waiting in the orders queue. This
message was created by the recorder for the OrderClient application placing
an order.

! 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
Topic Objective

To provide a review of
loosely coupled events in
COM+.

Lead-in

In this topic, you will learn
about the physical design
issues for loosely coupled
events of a COM+ object.

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
The event class is a COM+ component that contains the interfaces and methods
used by a publisher to fire events. The event class is abstract in nature. Its
purpose is to define one or more COM interfaces that define a set of events that
can be fired.


14

Module 7: Business Logic for Disconnected Components

The COM+ Event Store
The COM+ Event Store maintains a subscription list. Subscribers place entries
in the event store either by using the Component Services administration tool or
programmatically by using the COM+ administration interfaces. A subscription
record provides the event service with information about the recipient of an
event. There are three types of subscription supported by the COM+ Event
Service:
!

Persistent
Persistent subscriptions reside in the COM+ Event Store and survive system

restarts.

!

Transient
Transient subscriptions are tied to a particular object instance. Transient
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.