Module 4: User Services

Describe the logical and physical designs for the Market Purchasing user services.. Best Practices In this section, emphasize that discovering a “real world” metaphor that is easy to use

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

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

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 http://msdn.microsoft.com/xml/general/toolkit_intro.asp 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

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

In this module, you will learn

about user services and

how to create a logical

design and a physical

design for user services

# Introduction to User Services

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

In this section, you will learn

about the business problem

facing designers that must

implement user services

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

! 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

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

! 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?

! 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

In this section, you will learn

about the technologies that

can be used to create a

physical design for user

services

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

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:

! 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

Content Presentation

<Invoice>

<From> Judy Lew </From>

<To> Sean Chai </To>

<Date year = '1999' month = '11' day = '22'/>

<Amount unit = 'Dollars'> 100 </Amount>

<TaxRate> 21 </TaxRate>

<Total currency = "Dollars"> 121 </Total>

</Invoice>

Hypertext Markup Language

For years, HTML has been the markup language of choice for Web pages Over time, the following limitations of HTML as a markup language have surfaced:

! HTML describes only visual presentation

! HTML describes only static presentations

! HTML is a poor store of information

! HTML does not understand the content and structure

! HTML has a limited structure; it is a fixed set that is not extensible

! HTML provides only limited reuse and data interchange

! HTML is not strict enough for data representation (data is mixed with presentation)

Web authors today face significant challenges when making their Web pages interactive The static nature of HTML pages limits their creative choices, and interactive components can be difficult to build and reuse In addition, using proprietary extensions means authoring browser-specific Web pages

Dynamic HTML technology helps to remove these barriers for content providers and offers users more engaging and interactive Web pages Dynamic HTML provides authors with enhanced creative control so that they can manipulate any page element at any time Dynamic HTML is also the easiest way to make Web pages interactive, using open, standards-based technologies Microsoft is working with the World Wide Web Consortium (W3C) to help ensure interoperability and support for users on multiple systems with different browsers

Making simple updates, such as changing the color of text after a Web page loads, traditionally has meant reloading the page These limitations have slowed the user experience and have impeded interactivity on the Web

Dynamic Hypertext Markup Language

Microsoft's dynamic HTML takes interactivity to the next level Pages authored with dynamic HTML come alive, with every element in the page being truly dynamic After the page has loaded, content providers can change any element

of the page, text, or graphics without reloading the page from the server This increased control and flexibility results in more compelling sites For users, the Web experience becomes more responsive and rich

Active Server Pages

ASP pages are Web-based pages that prepare HTML content that is returned to the client browser

Extensible Markup Language

XML is a descendant of the Standard Generalized Markup Language (SGML) XML is an industry standard for data exchange from the World Wide Web Consortium (W3C) XML is not just a markup language It is a meta-language that allows you to design your own markup language It gives you the freedom

to capture useful information about what your data is and how it is structured XML is extensible and platform independent

Presenting data as an XML document provides four benefits: the data is self describing, the data can be manipulated with standard tools, the data can be viewed with standard tools, and different views of the same data are easy to create with style sheets There are two possible ways to create views of XML documents: a CSS and an Extensible Style Language (XSL) A CSS associates particular formatting with each element of an XML document An XSL contains two sections: transformation and formatting Transformation allows you to replace one tag with another, while formatting enables you to specify the appearance and layout of a page

Associated with an XML document is a Document Type Definition (DTD) A DTD provides a list of the elements, attributes, notations, and entities contained

in an XML document

The physical design of user services must determine the appropriate technology for presenting content: HTML, DHTML, ASP, or XML

Demonstration: XML/XSL Viewer

This demonstration provides a good example of using XSL to offer different views on XML Many times, the Web designer will want to display different data to different consumers Through XSL, this aim can be accomplished without altering the original XML document or the HTML page used to load that document This demonstration of the XML/XSL viewer allows the user to surf through different XML documents and apply different XSL style sheets to those documents

To run this demonstration, execute the following steps:

1 Launch the Internet Explorer browser

2 Click File, and then click Open

3 Browse to

install folder\Democode\Mod04\multiple_views\multiple_vbs.htm

4 Click Ok

1 In the left pane, choose an XML document and an XSL style sheet to display the view

2 Repeat Step 1 with different documents and style sheets

Parsing and Rendering

Cascading Style Sheets

Cascading Style Sheets are design templates that provide augmented control over the presentation and layout of HTML elements They allow you to separate the way you design information from the HTML content

Using style sheets, you can create Web pages with minimal graphics, and therefore much smaller downloads Style sheets also provide you with a higher level of typographic control, and they enable you to make changes to an entire site by using linked style sheets

When you understand CSS basics, all you need to know is a few lines of script and you can enable any HTML tag to change dynamically by applying CSS attributes to it For example, inline script events allow you to dynamically change the style attributes of any HTML element when you touch it with the

mouse (onmouseover event) or move the mouse off of it (onmouseout event)

Topic Objective

To provide a discussion of

parsing and rendering

Lead-in

In this topic, you will learn

about CSS and DOM

Document Object Model

Using the XML DOM in the physical design of user services allows the loading and parsing of XML files, the gathering of information about those files, and the navigation and manipulation of those files The four main objects exposed

by the XML DOM are XMLDOMDocument, XMLDOMNode,

XMLDOMNodeList, and XMLDOMNamedNodeMap Each of these objects

exposes methods and properties that enable you to gather information about the instance of the object, manipulate the value and structure of the object, and navigate to other objects within the tree

The DOM exposes the XML document as a tree structure that is composed of nodes; the DOM programming interfaces enable applications to traverse the tree and manipulate its nodes Each node is defined as a specific node type

according to the DOMNodeType enumeration, which also defines valid parent

and child nodes for each node type For most XML documents, the most common node types are element, attribute, and text Attributes occupy a special place in the model because they are not considered child nodes of a parent A distinct programming interface, the named node map, is provided for attributes