Module 4: User Services

Contents
Overview 1
Introduction to User Services 2
Technologies 7
Design and Implementation Considerations 20
Market Purchasing 24
Best Practices 27
Lab 4: User Services 28
Review 35

Module 4: User
Services

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, 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 4: User Services iii


Instructor Notes
This module provides students with knowledge about creating the logical and
physical designs of user services.
After completing this module, students will be able to:
!
Describe the logical and physical designs of user services.
!
Describe the differences between thin client and rich client physical designs
and the technologies that are involved in each.
!
Create a physical design for a thin client solution.
!
Create a physical design for a rich client solution.
!
Describe the logical and physical designs for the Market Purchasing user
services.

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_04.ppt
!
Module 4: User Services
!
Lab 4: User Services

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the lab.

Presentation:
60 Minutes

Lab:
60 Minutes
iv Module 4: User Services


Module Strategy
Use the following strategy to present this module:
!
Introduction to User Services
The purpose of this section is to introduce students to the logical and

physical designs of user services.
The focus of the logical design is on the creation of a metaphor for the
user/system interaction.
The focus of the physical design is on the selection criteria for the
technologies that will be used to implement the metaphor. One of the
selection criteria will involve whether to choose a thin client or a rich client.
In the topic “The Business Problem,” emphasize that the selection of an
appropriate metaphor is an art rather than a science.
!
Technologies
The purpose of this section is to introduce students to the technologies that
can be used in the physical design of user services. The technologies are
separated into five categories: protocol, content presentation, data exchange,
parsing and rendering, and components.
In each technology category topic, review the important technology items.
This section also includes a demonstration of an Extensible Markup
Language (XML)/extensible style language (XSL) viewer.
For more information about Simple Object Access Protocol (SOAP), go the
Web site located at
and read the article “Web Services and the SOAP Toolkit for Visual Studio
6.0.”
!
Design and Implementation Considerations
The purpose of this section is to present the design and implementation
considerations for choosing a thin client vs. a rich client.
In the topic “Implementation Considerations,” review the table of features
and the justifications for the choices between thin client and rich client
designs. This is an opportunity to solicit student participation in the
discussion about the justifications.
!

Market Purchasing
The purpose of this section is to review the logical and physical designs of
Market Purchasing and to explain the justification for the choices made. The
logical design metaphor is a frame-based structure with multi-level menu
selections. This model was chosen because it provides simplicity of
interaction. The physical design uses a thin client when possible for speed
and a rich client for interactions with the user that would be difficult to
implement with a thin client.
!
Best Practices
In this section, emphasize that discovering a “real world” metaphor that is
easy to use and implement is crucial to good user services logical design.
This might not be achievable, however. The alternative solution is to create
a generic menu-based interface, as in the case of Market Purchasing.

Module 4: User Services v


Lab Strategy
!
Lab 4: User Services
The purpose of Lab 4 is for students to learn to design user services.
Students probably will not derive answers that correspond exactly to the
design of Market Purchasing. 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 4.


Module 4: User Services 1

#
##
#

Overview
!
Introduction to User Services
!
Technologies
!
Design and Implementation Considerations
!
Market Purchasing
!
Best Practices


This module provides students with knowledge about how to create the logical
and physical designs of user services.
After completing this module, you will be able to:
!
Describe the logical and physical designs of user services.
!
Describe the differences between thin client and rich client physical designs
and the technologies that are involved in each.
!
Create a physical design for a thin client solution.
!
Create a physical design for a rich client solution.

!
Describe the Market Purchasing user services logical and physical designs.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about user services and
how to create a logical
design and a physical
design for user services.
2 Module 4: User Services


#
##
#

Introduction to User Services
!
The Business Problem
!
Business Requirements


The focus of this presentation is on the implementation of user services as Web
clients. User services can be developed by using Microsoft
®

development tools
such as Microsoft Visual Basic
®
, Microsoft Visual C++
®
, and Microsoft Office
to create a rich user experience that uses the full capabilities of the user
computing environment (often referred to as rich clients). Technologies such as
dynamic HTML (DHTML) and ActiveX
®
controls can provide varying degrees
of richness of functionality. Alternatively, lighter-weight HTML front ends
(often referred to as thin clients) can be developed by using Microsoft
FrontPage
®
or Microsoft Visual InterDev
®
and hosted on Internet Information
Services (IIS). These HTML-based applications allow greater reach to clients in
intranet and Internet solutions with technologies such as Active Server Pages
(ASP).
In this section, User services will be placed in the proper context of the business
problem. A discussion about the business requirements of user services will
follow.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn

about the business problem
facing designers that must
implement user services.
Module 4: User Services 3


The Business Problem
Facade Layer
Web Services Facade Business Facade
User Services
Food Menu


User services represents a translation of the use cases of a conceptual design to
a metaphor. A metaphor is an underlying model for representing the interaction
between a user and the information system that is supporting the user in the
particular system. An example of a user services metaphor is a shopping basket
used on an e-commerce site or an airplane seating chart in an airline reservation
system. The metaphor governs the way data is represented and input is
gathered. In particular, the metaphor should facilitate the following activities:
!
Data presentation
Data presentation is the format in which data is presented to a user. Data can
be presented in text or as part of a metaphor. For example, in Market
Purchasing, the items purchased can be represented either as lines on a
requisition form or as items in a shopping basket. The requisition form and
the shopping basket represent metaphors for the Market Purchasing user
interface. The data must be presented as an integral part of the metaphor.
!
Sending user input to business services

A secondary role of user services is to send data to the business services.
Access to business services is controlled by a facade. The discussion of
facades will be presented in Module 5, “The Facade Layer.”
!
Receiving results from business services
The complement of sending data to business services is receiving results
from business services.
!
Data capture
User services, as represented by the metaphor, should facilitate the capture
of data from a user as part of the interaction between the user and the
system. For example, the Enter New Requisition use case must capture the
user’s selections for country, requisition class, vendor, and part class.
Topic Objective
To provide background
about the business problem.
Lead-in
In this topic, you will learn
about the business problem
facing designers that must
implement user services.
4 Module 4: User Services


!
Data validation
User services plays a critical role in data validation by presenting to the user
only the valid choices. In the logical design of user services, we have
progressed a long way from the text-based data entry, in which data was not
validated until it was submitted to business services. Today, data validation

occurs at the source.
!
Providing task guidance for the user
A successful user services metaphor is one that is intuitive and easy to use.
The successful user services metaphor guides the user (imperceptibly)
through the activities like an invisible hand.
!
Displaying errors to the user
Users can always make mistakes. Accepting responsibility for mistakes and
correcting them is a stressful human endeavor. Successful user services
provide a friendly and nonstressful mechanism for notifying users of errors
and allowing them to correct them. An even better approach is to try to
design the user interface to help users avoid errors altogether, by using
elements such as drop-down list boxes or spin boxes.

The logical design of user services includes a specification of the metaphor.
Metaphors enable a business application to imitate the actual business process
by implementing the representation of the artifacts used by the business.
One of the most obvious metaphors in information technology (IT) applications
is the menu. A menu in a restaurant provides a customer with a list of available
choices. When you try to select a choice that is not currently available, the
waiter notifies you of the situation and recommends that you make another
selection. A computer menu provides similar functionality. The computer
menu, however, can list only the available choices from which you can select.
Using metaphors that represent the artifacts of a business or organization
enables the IT representation to present a reality with which the user is familiar.
Following are some examples of metaphors used in business environments:
!
Cash registers representing sales in a retail environment
!

Pushpins representing a note
!
A form representing a requisition

A more detailed discussion of the logical design issues of user services and
using business metaphors is presented in Module 11, “Designing the
Presentation Layer,” of the MSDN Training Course 1608A: Designing Business
Solutions.
It should be noted that business rules are never implemented or enforced in user
services.
Module 4: User Services 5


Business Requirements
!
Hardware
!
Software
!
Network
!
Security
!
Deployment
!
Support
!
Cost of Ownership

The decision of whether the physical design of user services should include the
use of a thin or a rich client depends on the following considerations:
!
The application requirement specification (which describes the application
logic flow and is represented in the use cases).
!
The physical requirements (which describe physical constraints such as UI
color choices and performance requirements).
!
Hardware restrictions (such as the type of workstation that the application
must be run on).

This topic presents criteria that must be taken into consideration when deciding
on the appropriate design for a particular use case. The criteria will help you
decide what to select as the basis for the physical design. For example, the
Market Purchasing application includes an Approve/Deny a Requisition use
case. Should the physical design of user services for this use case be based on a
thin client or a rich client?
The following are the seven criteria for deciding whether to use a thin or rich
client for a particular use case:
!
Hardware
Can the physical design of the use case run on the hardware platform
available to the user of this use case? For example, is the user going to have
local hard disk storage?
!
Software
Can the physical design of the use case run on the software platform
available to the user of this use case? For example, is the user going to have
Microsoft Internet Explorer installed?

Topic Objective
To summarize the
considerations for deciding
between thin and rich
clients.
Lead-in
In this topic, you will learn
about the process of
deciding between thin and
rich clients for a use case.
6 Module 4: User Services


!
Network
Can the physical design of the use case accommodate the existing network
bandwidth available to the user of this use case? For example, is the user
connected by means of the Internet or by means of a local area network
(LAN)?
!
Security
Can the physical design of the use case meet the security requirements of
the user of this use case? For example, is the user going to be authenticated
by membership services or by Microsoft Windows NT
®
LAN Manager
(NTLM)?
!
Deployment
Can the physical design of the use case accommodate the deployment

infrastructure that is available to the user of this use case? For example, is
the user a Microsoft Systems Management Server client?
!
Support
Can the physical design of the use case accommodate the existing support
infrastructure available to the users of this use case? For example, is this
application going to be supported by a Help Desk?
!
Cost of ownership
In general, what costs will be incurred for the selected physical design, and
are these costs acceptable to the enterprise?

The purpose of the seven criteria is to ascertain whether a thin client or a rich
client physical design is in the best interest of a use case user.
Module 4: User Services 7


#
##
#

Technologies
!
Protocol
!
Content Presentation
!
Parsing and Rendering
!
Data Exchange

!
Components


Ultimately, a good user services physical design is one that users believe is
good. There are, however, technology choices that need to be made in the
translation of the logical design to a physical design that would enhance the
user experience. In this section, the technologies that are available for the
physical design will be presented in detail. In particular, the following
categories will be presented:
!
Protocol
The protocol selection defines the type of interaction between user services
and business services, which ultimately influences the physical design of
user services. The choice of protocol can be influenced by two other factors:
the physical location of the clients and the type of workstation that is going
to be used. The two possible selections are Hypertext Transfer Protocol
(HTTP) and Simple Object Access Protocol (SOAP). SOAP facilitates
interoperability among a wide range of programs and platforms, making
existing applications accessible to a broader range of users. SOAP combines
the proven Web technology of HTTP with the flexibility and extensibility of
Extensible Markup Language (XML).
!
Content presentation
In the content presentation category, a selection can be made from a wide
variety of technology choices: HTML, dynamic DHTML, Extensible
Markup Language, Cascading Style Sheets (CSS), ASP, client-side scripting
(using Visual Basic Scripting Edition), ActiveX controls, and Component
Object Model (COM) components.
!

Parsing and rendering
The parsing and rendering category represents the treatment of information
that should eventually be presented on a desktop. These operations can
either be performed in business services or on the client side. Using CSS
and XML parsers on the client facilitate a richer client environment.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
about the technologies that
can be used to create a
physical design for user
services.
8 Module 4: User Services


!
Data exchange
In the data transfer category, there are two options. The data can be
transferred as part of the HTML body that is being sent back to the client, or
it can be transferred as a client-side cursor engine that allows a rich client to
cache and manipulate the data locally.
!
Components
The components category represents the nodes on which the physical
components can reside. The components can be physically instantiated on
the client side or in the business services by using an Abstract Data Factory.

Module 4: User Services 9


Protocol
!
Hypertext Transfer Protocol
!
Simple Object Access Protocol


Hypertext Transfer Protocol
The HTTP protocol layers request and respond to communications between a
client and a Web server over Transmission Control Protocol/Internet Protocol
(TCP/IP). An HTTP client connects to an HTTP server by using TCP. The
standard port number used in HTTP is port 80, but any port can be used. After
establishing the TCP connection, the client can send an HTTP request message
to the server. The server then sends an HTTP response message back to the
client after processing the request. Both the request and response messages can
contain arbitrary payload information, typically tagged with the content-length
and content-type HTTP headers.
HTTP headers are plain text. As a result, it is easy to diagnose HTTP problems
by using a packet sniffer or text-based Internet tools like telnet. The text-based
nature of HTTP also makes it easily adaptable to low-tech programming
environments popular in Web development. The first line of an HTTP request
contains three components: the HTTP method, the Request-URI (Uniform
Resource Identifier), and the protocol version. The Internet Engineering Task
Force (IETF) has defined standard HTTP methods. GET is the HTTP method
used to retrieve content from Web servers. POST is the most commonly used
HTTP method for building applications. Unlike GET, POST allows data to be
sent from the client to the server.

Topic Objective
To provide a presentation of
protocols.
Lead-in
In this topic, you will learn
about HTTP and SOAP.
10 Module 4: User Services



Simple Object Access Protocol
SOAP enables rich communication between applications over the Web. Today,
the majority of Web traffic consists of browsers connecting to servers to
retrieve HTML pages. SOAP enables applications to communicate with other
applications, and it provides a framework for connecting Web sites and
applications to create Web services. SOAP uses the proven Web technology of
HTTP with the flexibility and extensibility of XML.
SOAP uses XML as an encoding scheme for request and response parameters
used in the HTTP protocol. There are a few important SOAP concepts:
!
Methods
A SOAP method consists of an HTTP request and response that is compiled
with the SOAP encoding rules.
!
Endpoints
A SOAP endpoint is an HTTP-based URL that identifies a target for method
invocation. SOAP does not require that a specific object be tied to a given
endpoint. Rather, the implementer decides how to map the object endpoint
identifier to a server-side object.
!

Requests
A SOAP request is an HTTP POST request. SOAP requests must use the
text/XML content type. Additionally, they must contain a Request-URI as
defined in the HTTP specification. How the server interprets this Request-
URI is implementation specific, but many implementations are likely to use
it to map to either a class or an object. A SOAP request must also indicate
the method to be invoked by using the SOAPMethodName HTTP header.
The SOAPMethodName header is simply the application-specific method
name scoped by a URI by using a # character as a delimiter, as shown in the
following syntax:
SOAPMethodName: urn:strings-com:IString#reverse

The preceding slide shows how a logical component can be mapped onto a
SOAP protocol.
The physical design of user services can either use HTTP as a protocol for the
distribution of content or use SOAP as a mechanism for remote method
invocation.