Tài liệu Module 7: Integrating with External Systems pdf

Module 7: Integrating
with External Systems
Contents
Overview

1

Selecting a Transport

2

Time-Bound Operations

13

Security and Authentication

26

Lab 7: Creating and Using Web Services

44

Review

52


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.
 2001 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, ActiveX, BizTalk Server, FoxPro, FrontPage, Hotmail, Jscript,
Outlook, PowerPoint, Visio, Visual Basic, Visual C#, Visual C++, Visual Studio, 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.


Module 7: Integrating with External Systems

Instructor Notes
Presentation:
60 Minutes
Lab:
60 Minutes

This module discusses the mechanisms that are available for an e-commerce
site developer to enable electronic communication with trading partners in
business-to-business (B2B) solutions. It covers the available transport options,
such as using the Internet, implementing Value Added Networks (VAN), and
using Point-to-Point Protocol (PPP).

The module then describes various transport protocols, such as Hypertext
Transfer Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer
Protocol (SMTP), Distributed Component Object Model (DCOM) and
Microsoft Message Queue Server (MSMQ). Extensible Markup Language
Protocol (XMLP), which is the new name for Simple Object Access Protocol
(SOAP), is discussed as a mechanism for making object calls over the Internet.
Web Services are also described in this context of B2B communication.
The module continues by discussing synchronous and asynchronous
communication, including details on using MSMQ, COM+ events, and queued
components in asynchronous B2B solutions.
The module concludes with an architectural overview of security for B2B
solutions.
After completing this module, students will be able to:
Describe the transport options available to B2B solutions.
Decide whether to perform an operation synchronously or asynchronously
in B2B solutions.
Explain the security and authentication issues in B2B solutions and the
technologies that address these issues.
Create and use Web Services in an e-business application.

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 2260a_07.ppt
Module 7, “Integrating with External Systems”
Lab 7, “Creating and Using Web Services”

Preparation Tasks
To prepare for this module, you should:
Read all of the materials for this module.
Complete the lab.
Review the information in the following Web sites:
and
/>
iii


iv

Module 7: Integrating with External Systems

Module Strategy
Use the following strategy to present this module:
Selecting a Transport
In the first section, discuss VANs, the PPP protocol, and the Internet as
mechanisms and infrastructure that can be used for carrying out e-business.
It is important to stress that VANs are expensive to implement and therefore
cannot be afforded by small companies, whereas the Internet-based and
PPP-based solutions are less expensive and within the reach of all
organizations.
The topics on DCOM and XMLP must be taught such that the emphasis is
on the benefits of XMLP. You must not be recommending that students
implement DCOM for all their solutions because of the problems outlined in
the topic. The description of DCOM is included for the sake of
completeness and must be used as a suitable comparison against which the
advantages of XMLP must be explained.
Time-Bound Operations

It is very important that you cover the requirements for synchronous and
asynchronous operations thoroughly. Students must be able to identify
which types of operations must be implemented in a synchronous manner
and which types of operations can be implemented by using an
asynchronous solution. After you are sure that they understand the
distinction between the two types of solutions, you can then discuss the
queuing details in greater depth.
You must fully discuss the interaction between MSMQ, queued
components, and COM+. Where relevant, stress that queued components
offer rapid application development (RAD) advantages over MSMQ
solutions.
Security and Authentication
Because B2B solutions are expected to integrate with external
organizations, emphasize that this integration feature raises some extra
security issues for applications that are for internal use and B2C solutions.
Your discussion of the topics in this section must be focused on B2B
solutions, rather than going into any depth about specific technologies.
Next, discuss virtual private networks (VPNs) and the protocols used to
implement them. Ensure that the students understand that VPNs can use the
basic backbone infrastructure of the Internet to provide what is effectively a
private network similar to a local area network (LAN).
Conclude this module with a discussion on how Microsoft Internet Security
and Acceleration (ISA) Server 2000 enables you to implement firewalls and
VPNs.
Lab 7: Creating and Using Web Services
In the lab, students will create and use Web Services. They will create a
Web Service (an .asmx file) and then test its functionality. They will then
create a Microsoft Visual Basic® proxy file that will enable them to use the
service. Finally, students will incorporate the service into a B2B application.

Module 7: Integrating with External Systems

1

Overview
Topic Objective

To provide an overview of
the module topics and
objectives.

Lead-in

In this module, you will learn
about selecting a transport
mechanism, implementing
time-bound operations, and
the security issues and
solutions that are available
for B2B e-commerce
applications.

Selecting a Transport
Time-Bound Operations
Security and Authentication

*****************************ILLEGAL FOR NON-TRAINER USE*****************************
Business-to-business (B2B) e-commerce solutions involve electronic
communication between trading partners. In this module, you will learn about

some of the options relating to transport mechanisms and data formats, such as
Extensible Markup Language (XML) and Extensible Markup Language
Protocol (XMLP). XMLP is the new name for Simple Object Access Protocol
(SOAP).
When interacting with external systems, it is often useful to queue or batch
requests because real-time or synchronous operations may not always be
possible or suitable. You will learn how asynchronous operations can be used
for queuing request. You will also learn about the security requirements for
cross-organization data exchange.
After completing this module, you will be able to:
Describe the transport options available for B2B solutions.
Decide whether to perform an operation synchronously or asynchronously
in B2B solutions.
Explain the security and authentication issues in B2B solutions and the
technologies that address these issues.
Create and use Web Services in an e-business application.


2

Module 7: Integrating with External Systems

Selecting a Transport
Topic Objective

To introduce the topics in
this section.

Lead-in

There are a number of
transport options available
to allow communication
between companies
participating in B2B
solutions.

Transport Options
Transport Protocols
Distributed Object Calls
Calling Web Services

*****************************ILLEGAL FOR NON-TRAINER USE*****************************
There are a number of transport options available to allow communication
between companies participating in B2B e-commerce. One of the decisions that
you will have to make is which transport protocols are to be used in your
application. Other decisions that you will have to make include how distributed
object calls are made by your application.
This section examines some of the transports options and discusses the features,
advantages, and limitations of each option.


Module 7: Integrating with External Systems

3

Transport Options
Topic Objective

To explain the transport

options available for B2B
solutions.

Lead-in

There are several transport
options available for B2B
solutions.

Value Added Networks
The Internet
Point-to-Point Protocol

*****************************ILLEGAL FOR NON-TRAINER USE*****************************
Before electronically exchanging business data between trading organizations,
the basic infrastructure to be used for the transport of the data must be agreed
upon by those organizations. There are several transport options available for
B2B solutions:
Value Added Networks (VANs)
The Internet
Point-to-Point Protocol (PPP)

Value Added Networks
Thousands of businesses exchange business documents, such as orders and
invoices, with their trading partners through a widely used standard
communication and content protocol named Electronic Data Interchange (EDI).
Most EDI implementations use leased lines or VANs that require significant
integration for each trading partner. Network design, installation, and
administration can be costly in terms of hardware, software, and staff. In fact,
these costs are the main reason why EDI is most widely deployed in only larger

companies.

The Internet
All companies can take advantage of value-chain integration through the low
cost of the Internet. Open standards for electronic document exchange allows
all companies to become Internet trading partners and function as suppliers,
consumers, or both. This integrated trading tightens relationships between
businesses while offering them greater choices in supplier selection.


4

Module 7: Integrating with External Systems

Point-to-Point Protocol
PPP is a set of industry-standard protocols that negotiate configuration
parameters for multiple layers of the Open Systems Interconnection (OSI)
model. Microsoft® Windows NT® and Microsoft Windows® 2000 support PPP.
Computers running Windows can dial into remote networks through any server
that complies with the PPP standard. PPP compliance also enables both
Windows NT–based servers and Windows 2000–based servers to receive calls
from, and provide network access to, other vendors' remote access software.
PPP has made substantial progress in becoming a standard for Integrated
Services Digital Network (ISDN) communications. ISDN is a system of digital
phone connections, which has been available for more than a decade. The
growth of the Internet and the development of new PPP-related technologies
have enhanced the usage of PPP. For example, the Point-to-Point Tunneling
Protocol (PPTP) uses a PPP link to the Internet to provide a secure link to a
remote local area network (LAN). Dialing into a local Internet Service Provider
(ISP) will now establish connections that once required an on-site remote

access server. Because of advances in encryption technology, the link will
remain private and remote clients can access the LAN from their home office
through an Internet connection.


Module 7: Integrating with External Systems

5

Transport Protocols
Topic Objective

To explain the different
transport protocols for B2B
solutions.

Hypertext Transfer Protocol

Lead-in

Used in Internet and intranet communications

There are a variety of
transport protocols that can
be used in B2B solutions.

File Transfer Protocol
Used for transferring files between computers
Simple Mail Transfer Protocol
Distributed Component Object Model

Microsoft Message Queue Server

*****************************ILLEGAL FOR NON-TRAINER USE*****************************
There are a variety of transport protocols that can be used in B2B solutions:
Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
Simple Mail Transfer Protocol (SMTP)
Distributed Component Object Model (DCOM)
Microsoft Message Queue Server (MSMQ)

HTTP
HTTP is the standard protocol that is used in Internet and intranet
communications. It is a lightweight application-level protocol. HTTP is based
on Transmission Control Protocol (TCP). TCP is a part of Transmission Control
Protocol/Internet Protocol (TCP/IP), which deals with connection-based
communication. Because HTTP uses a single request and single response
mechanism, it might seem better suited to a connectionless protocol such as
User Datagram Protocol (UDP). The reason TCP, rather than UDP, is used is
that the response to an HTTP request often carries a large amount of data, and
TCP has the capacity to transfer large amounts of data reliably without
complicating HTTP.
Secure Sockets Layer (SSL) can be used to encrypt data between the transport
and the socket layer of the TCP/IP protocol stack. All Hypertext Markup
Language (HTML) and Active Server Pages (ASPs) on the Web server that
receive, display, or process sensitive information must be secured by SSL.
During the SSL authentication process, a unique encrypted session key is
generated by the browser for bulk encryption of information and then
transferred to the Web server by using a public key operation so that
information can be transferred securely.

6

Module 7: Integrating with External Systems

FTP
FTP defines a protocol for transferring files between computers. FTP has a role
to play in e-business because it provides an effective option for delivering large
amounts of data to trading partners and consumers in an efficient manner. For
example, a supplier can send product catalogs to interested parties by using
FTP. Alternatively, an organization can send detailed sales figures and
customer profile information to other businesses or regulatory bodies that need
this information.

SMTP
SMTP allows information to be sent as an e-mail message by using an SMTPbased server. A process at the receiver end that operates in conjunction with a
SMTP server (an e-mail server such as Microsoft Exchange Server) must wait
for and process messages as they arrive.
SMTP is an appropriate transport for one-way business transactions, such as
purchase orders, order status updates, shipping notifications, and payment
reminders.

DCOM
DCOM is an integral part of Microsoft's strategy for distributed objects. With
DCOM, a client program can invoke the methods of a remote object located on
the server. DCOM is an appropriate protocol for synchronous communications
between tightly coupled applications in which the client knows the location and
methods of the remote object.
For more information about DCOM, see Distributed Object Calls in this
module.

MSMQ
In conventional application design, applications usually communicate to other
applications directly. With message queuing, applications communicate directly
with a message queue server, which queues the messages/requests and transmits
them to another message queue server for processing.
MSMQ is a Windows NT and Windows 2000 service that provides guaranteed
transactional asynchronous communication of messages between distributed
programs. MSMQ reduces the coding and administration effort needed to
implement asynchronous applications and can shorten the time needed to
develop e-business systems that include the need for asynchronous
communication.


Module 7: Integrating with External Systems

7

Distributed Object Calls
Topic Objective

To explain distributed object
calls.

DCOM

Lead-in

Being able to make object
calls between different parts

of your B2B solution is
fundamental to the success
of your e-business
application.

Binary communication
Variety of TCP/IP ports
Firewall issues
XMLP
XML-based communication
TCP/IP port 80 (HTTP)

*****************************ILLEGAL FOR NON-TRAINER USE*****************************
Being able to make object calls between different parts of your B2B solution is
fundamental to the success of your e-business application. The challenge is
making these calls between components that are not necessarily on the same
computer or even on the same LAN.

DCOM
DCOM is a protocol that allows components to communicate with each other
across a network. A Component Object Model (COM) component is a unit of
software that implements certain interfaces. Interfaces are defined by using a
language-neutral definition language, the Microsoft Interface Definition
Language (MIDL), which allows the developer to specify the following
information for each interface:
Name of the interface
Methods in the interface
Attributes in the interface
After an interface has been defined, it must be implemented by a program at the
server by using an appropriate language such as Microsoft Visual C++® and

Microsoft Visual Basic®. To implement an interface, you must provide an
implementation for each of the methods and attributes defined in that interface.
After these methods have been implemented in the server program, the server
program polls a port (or a group of ports) on the server host computer and waits
for client requests for its methods. Server host systems maintain a list of these
ports, known as object endpoints, in the registry.


8

Module 7: Integrating with External Systems

For a client application to invoke one of the methods, the following events must
take place:
The client has to establish a connection with the server object on a given
remote system. The remote system can be specified programmatically, or it
can be configured in the registry.
After the object on the remote server has been located, the client can invoke
the appropriate method on that object. DCOM uses Remote Procedure Calls
(RPC) for this process. The client connects to the TCP/IP port that the
server is polling on and then invokes the appropriate method on the server
object.
Parameters are passed from the client to the server, almost as if for a simple
in-memory procedure call. The server's method does its work and returns a
suitable response back to the client.
The use of RPC and TCP/IP ports to establish a connection between the client
and the server presents difficulties when trying to access server objects behind a
firewall (a gateway between one network and another). Firewalls usually permit
access on only the HTTP port (port 80 by default). However, COM objects tend
to poll on a variety of ports because they are not restricted to polling on port 80,

and a firewall is unlikely to allow a client to connect to the server on any port
other than port 80.

XMLP
XMLP overcomes the problems in using firewalls and traditional RPCs. XMLP
delivers RPC-type calls as XML messages over HTTP. HTTP is the standard
Internet protocol and, therefore, presents no problems to the firewall.
By using XMLP, an RPC is delivered as an HTTP request and response. The
method call is represented as an XML message and contains invocation
information about the target server and the target method. Method calls usually
include parameters. These parameters are also included as part of the XML
message. The XML message can pass easily through any firewalls that might
exist, thereby allowing the client application to invoke operations on the server
computer.
An XMLP request is an HTTP POST request. XMLP uses an HTTP-based
Uniform Resource Locator (URL) to identify an object endpoint at the server.
The server implementer can decide how to configure this endpoint such that it
points to an actual server-side object. An XMLP request also indicates which
method to invoke. This is defined in the SOAPMethodName HTTP header as
follows:
Syntax

SOAPMethodName: namespaceURI#methodName

The namespaceURI is equivalent to an interface identifier (ID) in DCOM. The
name of the method is delimited by a # character, as shown in the preceding
syntax.


Module 7: Integrating with External Systems

The method parameters are contained as an XML document in the body of the
HTTP request. The following example shows the HTTP header (which
identifies the method to call) and the HTTP body (which defines the input and
input/output parameters for the method):
POST server HTTP/1.1
Host: 123.456.789.0
Content-Type: text/xml
Content-Length: 123
SOAPMethodName: namespaceURI#methodName
<soap:Envelope xmlns:soap="urn:schemas-xmlsoap-org:soap.v1">
<soap:Body>
<m:methodName xmlns:m="namespaceURI">
<theParameter>This is my parameter value</theParameter>
</m:methodName>
</soap:Body>
</soap:Envelope>

The HTTP body is enclosed in XML elements named <soap:Envelope> and
<soap:Body>. The soap: namespace prefix represents the SOAP Uniform
Resource Identifier (URI) and identifies XML tags prefixed with soap: as
SOAP-specific. The URI specifies the location of the SOAP schema.
Note that the first element in the body must have the same name as the method
name in the HTTP header.
The HTTP response contains a SOAP XML body in a similar format. It
identifies the return values and the output or input/output parameters of the
method.
For more details on XMLP or SOAP, see
/>
9

10

Module 7: Integrating with External Systems

Calling Web Services
Topic Objective

To describe how to use Web
Services in e-business
solutions.

Lead-in

As the Internet becomes
more integrated with
mainstream businesses, the
need to have Web Services
interwoven with mainstream
business computing
increases.

An application delivered as a service that can be
integrated with other applications using Internet standards
Examples: Passport, Hotmail, and calendar service
Web Services communicate through XML and XMLP
Requirements of Web Services:
Web Services must be easily exposable
It must be possible and easy to use Web Services and to

program against them in a straightforward manner
Applications must be able to use Web Services with
minimal configuration overhead
SOAP Toolkit for Visual Studio 6.0 addresses these
requirements

*****************************ILLEGAL FOR NON-TRAINER USE*****************************
A Web Service is an application delivered as a service that can be integrated
with other applications by using Internet standards. In other words, it is a URLaddressable resource that returns information to clients who want to use it. An
example of a Web Service is Microsoft Passport. It contains the functionality
that you can use to verify a user’s identification and the permissions to access
his or her information in your Web applications.

Web Services
Web Services form a part of Microsoft's .NET strategy to provide an integrated
platform for Web applications. Web Services seek to integrate functionality
such as e-mail, news, advertisements, and financial updates.
Web Services are building blocks that can be used by developers to construct
and integrate services and applications, from local and remote resources, for
different clients. Web Services can be purchased from Microsoft and
independent vendors or can be created specifically to meet your own
requirements. The following are some typical Web Services:
Passport
Microsoft Hotmail®
WebStore
E-mail and calendar services
Instant messaging
Notification
Host integration

Module 7: Integrating with External Systems

11

Web Services Communication
Web Services use asynchronous messaging for robustness and scalability, and
they rely on XML because of its simplicity, openness, and extensibility.
XMLP can be used as a common wire format for the XML messages sent
between Web Services. XMLP is a good choice because it is designed to
perform method invocations and it is not restricted to a particular operating
system, object model, or programming language. Furthermore, XMLP works
over the existing Internet infrastructures.
There is a need for Web Services to describe their functionality to client
applications. In other words, Web Services need to make available their names,
attributes, and methods. Because they are based on XML, this is easily achieved
by creating XML schemas that describe the content of the Web Service. XML
schemas are used to describe the contents of an XML document, usually in
terms of the business data that it contains. In the case of Web Services, schemas
do the same, but their goal is to describe the functionality of the service, rather
than the contents of a business document.

Using Web Services
To be able to use Web Services, they must conform to the following
requirements:
Web Services must be easily exposable.
It must be possible and easy to use Web Services and to program against
them in a straightforward manner.
Applications must be able to use Web Services with minimal configuration
overhead.

The SOAP Toolkit 2.0 for Microsoft Visual Studio® 6.0 addresses the
preceding requirements as follows:
If the service you wish to expose is a COM component, the SOAP Toolkit
includes a tool that can be applied to the COM component's type library to
generate an XML description of the COM component. If the service is not a
COM component, you can write the XML description by hand.
To use a Web Service, you can use the SOAP Toolkit’s automatic Remote
Object Proxy Engine (ROPE). ROPE takes the XML service description
(mentioned in the preceding bullet point) and automatically creates a Visual
Basic proxy object to represent the service. The Visual Basic programmer
can use this proxy object as though it were a local COM object. The proxy
object encapsulates the underlying task of connecting to the actual Web
Service object.
When the client application starts, the proxy uses SOAP to make calls
across the network to the Toolkit’s listener application on the Web server.
This listener application is either an ASP page or an Internet Server
Application Programming Interface (ISAPI) application. The listener
application takes care of starting up the service application and handles all
subsequent interaction with that application.


12

Module 7: Integrating with External Systems

The SOAP Toolkit for Visual Studio 6.0 can be downloaded from the following
link: />Note For more information about Web Services, see
/>

Module 7: Integrating with External Systems

13

Time-Bound Operations
Topic Objective

To introduce the topics in
this section.

Lead-in

This section compares the
use of synchronous and
asynchronous
communications between
applications in B2B
solutions.

Synchronous vs. Asynchronous Operations
Asynchronous Operations: Requirements and Caveats
Queuing
COM+ Events
COM+ Queued Components
Using COM+ Queued Components

*****************************ILLEGAL FOR NON-TRAINER USE*****************************
This section discusses the use of synchronous and asynchronous
communications between applications in B2B solutions. The section begins by
comparing the benefits and drawbacks of each approach and then describes how
asynchronous messaging can be achieved with MSMQ and COM+ queued

components.
You will learn how applications can generate events by using the COM+ Event
Service so that subscribing applications are notified when important business
events occur.


14

Module 7: Integrating with External Systems

Synchronous vs. Asynchronous Operations
Topic Objective

To compare synchronous
and asynchronous
operations.

Lead-in

Some tasks associated with
e-business have to be
completed in real time,
whereas others can be
performed asynchronously.

Synchronous Operations
Sending and receiving applications
must have overlapping running times

Server scalability and

reliability can be an issue

Response times are determinable
Asynchronous Operations
Applications can have different running times
Disconnected mobile users can communicate effectively
Server downtime can be handled more effectively
Suitable for workflow applications, log maintenance, and updates
of slowly changing data
Rudimentary load balancing

*****************************ILLEGAL FOR NON-TRAINER USE*****************************
Some operations associated with e-business have to be completed immediately,
in real-time. Other operations can be performed asynchronously, such as
overnight stock checks. E-business operations can therefore be classified as
synchronous or asynchronous.
It is important to understand the types of operations that must be undertaken in
a synchronous manner and the types of operations that can be implemented by
using an asynchronous solution.

Synchronous Operations
The following are some of the features of synchronous operations:
Sending and receiving applications must have overlapping running times.
When the sending application invokes a synchronous operation, the
receiving application must be running at the same time to service the
request.
Response times are determinable.
In a synchronous communication, the client is assured of a response almost
in real time.
Server scalability can be an issue.

If the server has to respond to a heavy demand of synchronous operations
requests, response times might suffer as the server attempts to service all of
the requests.
Server reliability can be an issue.
Synchronous operations rely on the availability of the server at all stages of
the communication and are not robust enough to deal with factors such as
server failures. Availability of your solutions can be improved with fail-over
clustering so that even if a server crashes, a secondary node can take over
the processing load; however, your solution is still dependent on servers
being available when needed.


Module 7: Integrating with External Systems

15

Asynchronous Operations
Asynchronous distributed applications can be easier to develop than their
synchronous counterparts, because there is no need for all of the participants to
be running at the same time.
Some of the features of asynchronous operations are as follows:
Applications can have different running times.
In an asynchronous architecture, the request can be queued up and delivered
to the receiving application when it is available online.
Disconnected mobile users can communicate effectively.
Asynchronous messaging allows data residing on portable and hand-held
devices to be queued locally while these devices are disconnected and then
dispatched when they connect to a server.
Server downtime can be handled more effectively
The server that performs a certain task may be available at only certain

times. Alternatively, the network connection to the server or the server itself
may be unreliable. In these cases, requests can be queued or batched for
later delivery when the service is available. This is a useful mechanism that
can be used to add robustness to a distributed application.
Suitable for workflow applications
Asynchronous systems work well for workflow applications in which
approval by a human is one of the tasks. In this case, an e-mail message can
be sent requesting such approval while the application continues to serve
other clients.
Suitable for log maintenance
Although logging of transactions is important for audit, it does not
necessarily have to be done in real time, as long as it is done at a later time.
Such logging can be performed by using asynchronous messaging.
Suitable for updates of slowly changing data
If one organization contains a copy of a portion of a catalog from one of its
suppliers, the real-time accuracy of that catalog is not necessarily vital.
Updates to prices or specifications could be sent by using asynchronous
messages to be applied when the application has spare capacity to handle
the updates.
Rudimentary load balancing
Asynchronous queuing systems can provide simple load balancing by
placing requests on a common work queue. Multiple servers can then
remove requests from the queue as and when they have the capacity to
handle them.


16

Module 7: Integrating with External Systems

Asynchronous Operations: Requirements and Caveats
Topic Objective

To explain the requirements
and caveats involved in
asynchronous
communication.

Lead-in

Although using
asynchronous
communication provides
certain benefits, it comes
with a set of requirements
and caveats.

Requirements and Caveats
The need for a queuing system
Timing requirements
No definitive answer
Transactional limitations
Need for Flexible Systems

*****************************ILLEGAL FOR NON-TRAINER USE*****************************
Although using asynchronous communication provides certain benefits, it
comes with a set of requirements and caveats, including:
The need for a queuing system
Whether it is the installation and configuration of MSMQ or the installation
of an e-mail server, some support will be required for the queuing service.

You will need someone who can install and configure MSMQ and can plan
the required capacity of the message store.
Timing requirements
Asynchronous operations may not be suitable when an operation must be
performed in a certain amount of time.
No definitive answer
If an application requires some form of response to the request it has made,
using asynchronous mechanisms adds a layer of complexity to the
application. An extra protocol is required at the application level to tie up
requests and responses.
Transactional limitations
COM+ provides transactional services to ensure that the execution of related
tasks can be grouped together into a transactional unit. If any one of the
tasks in a transactional unit fails, COM+ Transaction Services can rollback
the other tasks and, therefore, ensure consistency for your applications.
MSMQ provides transactional queues that can be used as part of a COM+
transaction. It is important to understand the meaning of this transaction
support. A transactional queue uses transactions to guarantee that a message
will be delivered. However, it does not guarantee that any operation
resulting from the message will succeed. If such an operation fails, it will
have no impact in the transaction used by the application that queued the
message.


Module 7: Integrating with External Systems

17

For example, one of your employees creates a purchase order request. In
response to this business action, you have two tasks to be completed. One of

the tasks is to update a database with details of the purchase order request.
The other task is to use MSMQ to call an object that creates an actual
purchase order. Assume that the purchase order is an XML-based business
document that must be validated with your company’s schema for purchase
orders. If the creation of the purchase order fails because of a schema
validation rule, creating a transactional unit for the database operation and
the message queue will not roll back the changes to the database. The
delivery of the message will still be considered successful in this scenario.
The update would be rolled back only if the actual call to MSMQ failed or if
it failed to deliver the message to the component that creates purchase
orders.
Used appropriately, asynchronous operations can deliver many benefits in terms
of scalability, flexibility, and robustness.

Need for Flexible Systems
Many of the distributed systems built over the past decade have relied on the
definition of some form of contract or interface between the client and server.
For example, a COM+ application will define interfaces between its constituent
components. These interfaces define the methods that can be called on the
server by the client and what data passes between them. Such use of interfaces
can be very helpful because they impose a certain amount of discipline on the
application developer. By constraining the methods and data types used, many
bugs and errors can be avoided.
The same discipline that benefits interface-based distributed systems can be a
hindrance when developing some of the flexible systems required for
e-business. For these systems, the data passed between client and server may
change rapidly over time. New features and functionality may be added on a
weekly basis. This calls for a more flexible representation of both the data
passed and the services requested.
XML can provide a solution for such systems. By using XML to represent the

data, it can be updated quickly and easily without having to re-compile the
application or re-distribute COM type-libraries. Similarly, by using XMLP as
the protocol for communication between applications, new functionality can be
added with much less overhead than in traditional distributed systems.


18

Module 7: Integrating with External Systems

Queuing
Topic Objective

To describe how MSMQ
queues and processes
messages.

Lead-in

In conventional application
design, applications
communicate with other
applications directly. With
message queuing,
applications communicate
directly with another
Message Queue server.

An MSMQ message can be set to expire when it does not
reach or read from a receiver’s queue in a time interval

For an MSMQ message, you can request a receipt when it
has been received or when it expires

*****************************ILLEGAL FOR NON-TRAINER USE*****************************
In conventional application design, applications communicate with other
applications directly. With message queuing, applications communicate directly
with another message queue server, which queues the messages/requests and
transmits them to another Message Queue server for processing.
MSMQ is an integral part of Windows 2000. It is a set of run-time services that
enable applications to send and receive asynchronous messages to other
applications on different computers.

Working of MSMQ
For an application to receive messages, the application must create a message
queue. For another application to send a message to this application, it has to
locate the queue by using system services or it must have prior knowledge
about the receiving application. The sending application then uses MSMQ
services to send a message to the receiving application.
The receiving application detects the incoming message either by polling or by
using callback notification. If the computer hosting the receiver's queue is not
running when the message is sent, the message is buffered by the sending
computer (or by some intervening computers on the network) until the
receiving computer starts running.


Module 7: Integrating with External Systems

19

MSMQ Messages

MSMQ contains a variety of features to support the delivery of messages. For
example:
The sender of a message can indicate that a message should expire and be
deleted if it does not reach the receiver's queue in a specified interval of
time.
The sender of a message can indicate that a message should expire if it is
not read from the receiver's queue in a particular time interval.
The sender of a message can request a receipt when the message is received.
The sender of a message can request a receipt if the message expires before
it has been read.


20

Module 7: Integrating with External Systems

COM+ Events
Topic Objective

To explain the role of COM+
events.

Lead-in

COM+ event service allows applications to publish
notifications that might be of interest to a number of
subscribing applications

Windows 2000 supports
COM+ events.

Any COM+ component can become a publisher or
subscriber of COM+ events
COM+ events can be used in B2B solutions
*****************************ILLEGAL FOR NON-TRAINER USE*****************************
Windows 2000 supports COM+ events. COM+ events allow applications to
publish notifications that might be of interest to a number of subscribing
applications. The publish/subscribe model is widely used in distributed
programming because it offers a simple way for publishing applications to
notify subscribing applications of important business events.
Windows 2000 implements the publish/subscribe model through the COM+
event service.

The COM+ Event Service
An event is represented by a call to a method on a COM interface. The
publisher calls the method, and the event service delivers the event to all
registered subscribers. The event service has to keep track of which subscribers
want to be notified about which events. A publisher is any program that makes
COM calls to initiate events. A subscriber is a COM+ component that receives
the COM calls representing events from a publisher.
The event class is a COM+ component generated by the event service. The
event class consists of interfaces and methods (known as event interfaces and
event methods) that the publisher can call to generate an event. Subscribers
have to implement these event interfaces and event methods to receive events.
Delivery Tip

Use the diagram on the
preceding slide to explain
the steps that are outlined in
the student notes.

The following steps describe the decoupled interaction between a publishing
application and a subscribing application by using the COM+ event service:
1. The publisher registers an event class with the COM+ catalog.
This involves providing a type library and informing the COM+ catalog
about which event interfaces and event methods the event class must
contain.
2. The subscriber registers an interest in specific events with the event service.
A subscription is a data structure that specifies an event class and indicates
which event interface and event method the subscriber is interested in.
Subscriptions are placed in the COM+ catalog.


Module 7: Integrating with External Systems

21

3. The publisher creates an object of the required event class by using
conventional object creation functions, such as CreateObject or
CoCreateInstance.
This is known as the event object, and it contains the event service’s
implementation of the specified interface.
4. The publisher calls the event method that it wants to generate for
subscribers when the event occurs.
5. The event service’s implementation of the interface examines the COM+
catalog to find the list of subscribers that have registered an interest in this
interface and method.
6. The event service connects to each subscriber and calls the specified
method.

Creating COM+ Publishers and Subscribers
Any COM+ component can become a publisher or subscriber of COM+ events.
Neither the publisher nor the subscriber needs to know how the event service
delivers events from the publisher to the subscriber(s).
However, there are some restrictions that need to be considered:
Typically, many subscribers register an interest in the same event.
Therefore, an event method cannot use output parameters or input/output
parameters because there is no way of specifying which of the many
subscribers should set the value for such a parameter. For the same reason,
event methods must return only success or failure results.
The current implementation of the event service does not support a
distributed subscription mechanism.
Publishing applications must therefore create event objects on a centralized
computer, which is available for all subscribing applications. Clearly, this
approach introduces a possible single point of failure. Microsoft Clustering
Services can be employed to overcome this potential hazard.
The delivery of events currently uses point-to-point communication
mechanisms, such as DCOM or queued components.
This presents a problem if there is a large number of subscribers because the
time taken to deliver an event increases linearly with the number of
subscribers.
Broadcasting the events would be the obvious solution to problems that can
arise when there is an increase in the number of subscribers, but broadcast
datagrams are not currently supported by the event service. Instead, the best
approach at the moment is to create a single DCOM subscriber that re-sends
event notifications to any applications that are interested.