The Future of Web Services

Introducing .NET My Services

Consider the personal information you have stored electronically: multiple usernames and passwords to access an array of Web sites; bookmarks stored on your home PC, which you cannot access from the office; calendars that you must synchronize on PCs in different locations and on your PDA; and separate contact lists held by your cell phone, PDA, and home and office PCs. And this is merely a fraction of the information the average user must manage. Users will soon have a solution to this problem with .NET My Services, a set of XML Web services that gives a user control over his personal data.

.NET My Services allows a user to store personal information remotely in a secure “digital deposit box.” The user can then permit individuals or organizations to access parts of this information on the user's terms. For example, a user might allow an airline access to her schedule for a single operation so that the airline can enter flight departure and arrival times. Not only can the user control her information, but she can also access that information at any time from any device. For example, a user might access her information using PCs at various locations, a cell phone such as the Stinger smart phone, or even an Xbox. This is possible because .NET My Services is like any other Web service—it communicates over existing transport protocols using XML and it returns XML to a client, which must then interpret and render the information in an appropriate fashion.

The beta release of .NET My Services will consist of a set of core services. Later, Microsoft and approved third parties will develop and release additional .NET My Services services. The initial core services are as follows:

  • .NET My Services service Records the services to which a user subscribes.

  • .NET Alerts Allows a user to manage subscriptions to alerts or notifications and allows Web sites and Web services to send a user alerts. For example, a Web service might send an alert to a user if a particular stock drops in price.

  • .NET ApplicationSettings Stores a user's application settings. For example, an application that accesses the service can adjust itself to the stored settings for toolbars in order to match the user's preferences.

  • .NET Calendar Stores a user's calendar information, such as time and task management information.

  • .NET Categories A list of categories that allows a user to group data documents together. For example, a user can group contacts (from .NET Contacts) together to form a contact list.

  • .NET Contacts Stores a user's contact information, such as colleagues' e-mail addresses and phone numbers. For example, a user can store a colleague's contact details while at the office and then look up these details using his cellular phone while out of the office.

  • .NET Devices Stores information about the devices a user plans to use to access .NET My Services. For example, a user can store the display attributes of her PDA. Incidentally, you can deliver information from services to mobile devices using the Mobile Internet Toolkit, which allows you to write ASP.NET pages that the runtime formats to match the display attributes and markup language that the client's device supports.

  • .NET Documents Stores a user's documents both securely and remotely.

  • .NET FavoriteWebsites Stores a list of the user's favorite Web sites.

  • .NET Inbox A centralized access point for users to access their e-mail. For example, a user can access her Hotmail account from a PDA while away from a PC.

  • .NET Lists Stores user-defined free-format lists. For example, a user can store a list of all the countries he wants to visit on an around-the-world tour.

  • .NET Locations Stores the location of the actual user at a given time. For example, a user might set her location to The Office or At Home.

  • .NET Presence Stores information about a user's availability for receiving alerts. For example, a user can set his presence status to indicate that he is currently off line and thus cannot receive an alert.

  • .NET Profile Stores a user's personal information. For example, a user can store her name, family birthdays, and personal photographs.

  • .NET Wallet Stores information the user needs to make payments, as well as items such as receipts and coupons that relate to payments. For example, the user can securely store his credit card details so that he does not have to enter card information each time he wants to make an online payment.

.NET My Services will offer exciting opportunities not only to users but also to businesses and developers. Businesses will be able to offer levels of service that the Web simply cannot deliver today. For example, with the aid of .NET My Services, an e-commerce business will be able to interact with a new customer as if she were an existing customer. All the user has to do is log in using .NET Passport, and the business will be able to access her personal details, delivery information, and payment information. The business can even send alerts to her cell phone when a new product arrives in stock or update her schedule so that she knows when the product will be delivered.

From a developer's perspective, .NET My Services eliminates many of the problems of securing data, providing encrypted transport channels, and reconciling disparate data sources. And all of this is achievable using XML Web services, so businesses are spared the drastic learning curve associated with new technologies and the need to make any radical changes to their development and production environments.

The following graphic shows a simplified view of the .NET My Services architecture. It shows that a client can consume a .NET My Services service in the same way that it consumes a regular Web service (at least at a high level), with the exception of the authentication service that .NET Passport provides. A client can make requests to .NET My Services services using XML using a protocol such as HTTP or Direct Internet Message Encapsulation (DIME) as a transport mechanism. Authentication is necessary in this architecture to ensure that only individuals or organizations that a user wants to grant access to can access that user's information.

Securing .NET My Services

.NET Passport is at the heart of the .NET My Services security architecture and provides authentication services through the use of Kerberos. The .NET Passport service authenticates users and provides access to a .NET My Services service through the issuing of tickets, which are in effect temporary encryption keys. The following graphic shows the process of authenticating a user and allowing that user access to a .NET My Services service.

note

Kerberos is an industry-standard protocol created at the Massachusetts Institute of Technology (MIT) that provides strong authentication over a network. Several operating systems implement this protocol, including Microsoft Windows 2000 and Windows XP.

As you can see, once the user clicks on a .NET Passport link, he is redirected to the .NET Passport server. When this redirection occurs, the referring site passes an ID unique to that site and a return URL. .NET Passport uses these to verify that the referring site is indeed the site it claims to be. If verification is successful, .NET Passport presents the user with a log-in screen, where the user enters a username and password. If .NET Passport can authenticate the user's credentials, it extracts a Passport Unique Identifier (PUID) and a Passport Profile from a database. .NET Passport then uses these to create three encrypted .NET Passport cookies (a ticket, a profile, and a visited-sites cookie), which it returns to the user's browser. .NET Passport then redirects the user to the referring Web site, where the site extracts the ticket and profile information and sends them to a Passport Manager object. This object decrypts the information and authenticates the user.

Under the .NET My Services model, the user no longer stores her own personal information but instead allows Microsoft or a trusted third party to store that information on her behalf. This paradigm shift requires the user to establish a trust relationship with the holder of her information—the user must be confident that her information will be made available only to appropriate parties. Authentication partially addresses this issue, but the issues of the security of the data store and the availability of information to third parties still remain.

In terms of data-store security, Microsoft ensures that database servers are not accessible over the Internet and that only Microsoft-certified personnel can access these databases. In addition, Microsoft can rotate encryption algorithms to further enhance the integrity of the data stores. Privacy of information is a different matter because it relies on the integrity or philosophy of an organization rather than on a physical means of protection.

Microsoft states that it will not allow secondary use of data and supports this with the following two measures:

  • Microsoft will be audited by Safe Harbor, a controlling body of the European Union (EU).

  • Microsoft states that it will adhere to its own Fair Information Practices.

Working with .NET My Services

When you work with .NET My Services, you can think of it as an XML database—a database of user information that, for example, you can execute queries against and that will return the results of those queries as XML fragments. It is then up to you to interpret that data and render it appropriately for your client. In reality, .NET My Services stores all data as XML service documents, and you access this data using XML messages rather than using a query language such as SQL.

HSDL, the .NET My Services data manipulation language, defines the following six XML messages, which are common to all .NET My Services services:

  • queryRequest Allows you to issue a query against a document, which will return an XML node set.

  • deleteRequest Deletes a specified node set from a specified document.

  • updateRequest Allows you to define a composite message, which can consist of a series of insert, delete, and replace requests.

  • replaceRequest Replaces a specified node set with another node set.

  • insertRequest Inserts XML in a document at a specified location.

  • subscriptionResponse Requests a subscription to specified data; when data changes, you receive a notification.

As you can see, each of these messages allows you to either insert data into or extract data from a service document. You can also see that most of the messages manipulate node sets rather than individual elements within an XML document. These node sets are demarcated by specially designated elements that allow HSDL messages to use XPath-style node selection. At the highest level within a document is a root element whose name matches that of the corresponding service. This element is known as the root, and HSDL labels this as a blue element. HSDL also labels the children of this element (that is, top-level elements) as blue elements.

The following example shows sample XML with the blue elements shown in bold:

<myAddress changeNumber="..." instance>   <address changeNumber="..." >     <cat ref="..."></cat>     <officialAddressLine xml:lang="..."></officialAddressLine>     <internalAddressLine xml:lang="..."></internalAddressLine>     <primaryCity xml:lang="..."></primaryCity>     <secondaryCity xml:lang="..."></secondaryCity>     <subdivision xml:lang="..."></subdivision>     <postalCode></postalCode>     <countryOrRegion xml:lang="..."></countryOrRegion>     ...     <!-- Further Elements -->     ...   </address>   <webSite changeNumber="..." >     <cat ref="..." ></cat>     <url></url>     ...     <!-- Further Elements -->     ...   </webSite>   ...   <!-- Further Blue Elements -->   ... </myAddress>

The listing shows that the following elements are blue:

  • <myAddress/>

  • <address/>

  • <webSite/>

These elements demarcate the node sets, which you can manipulate using the previously described HSDL messages. Each blue element contains one or more red elements or attributes, which the previous example shows as underlined. You can use the red elements to assist in the selection of a blue element when you use HSDL messages. The remaining elements—those that are neither red nor blue—you cannot address directly, but you can include them within a reference to a red item.

You can use both red and blue items in XPath predicates within HDSL messages, but be careful that you understand how the following commands work:

  • insertRequest Inserts a blue item into a document or a red item into a selected blue item

  • deleteRequest Deletes a blue item from a document or a red item from within a blue item

  • replaceRequest Replaces a blue item or a red item

  • queryRequest Returns a blue item (or items) or a set of instructions that tell you whether cached information is valid

A Sample .NET My Services Request

As a developer, you are probably eager to see how HSDL works in practice. Although you cannot write real code against .NET My Services today, we can still walk through a short example of using HSDL against a .NET My Services service. This example creates a SOAP message that inserts an entry containing a user's name and e-mail address into the .NET Profile service document.

Here is the complete example, with the HSDL operation shown in bold:

<?xml version='1.0'?> <s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/envelope/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Header>   <x:path xmlns:x="http://schemas.xmlsoap.org/rp/">     <x:action>     http://schemas.microsoft.com/hs/2001/10/core#request     </x:action>     <x:rev><x:via /></x:rev>     <x:to>http://species8472</x:to>     <x:id>35b4474a-a7d9-11d5-bf0e-00b0d0ccc121</x:id>   </x:path>   <ss:licenses   xmlns:ss="http://schemas.xmlsoap.org/soap/security/2000-12">     <h:identity mustUnderstand="1">       <h:kerberos>1</h:kerberos>     </h:identity>   </ss:licenses>   <h:request    xmlns:h="http://schemas.microsoft.com/hs/2001/10/core"   service="myProfile"   document="content"   method="insert"   genResponse="always">     <h:key instance="0" cluster="0" pu />   </h:request> </s:Header> <s:Body>   <hs:insertRequest    xmlns:hs="http://schemas.microsoft.com/hs/2001/10/core"    xmlns:m="http://schemas.microsoft.com/hs/2001/10/myProfile"    hs:select="/m:myProfile">     <m:name      xmlns:m="http://schemas.microsoft.com/hs/2001/10/myProfile">       <m:givenName xml:lang="en-us">John</m:givenName>       <m:surName xml:lang="en-us">Chen</m:surName>     </m:name>     <m:emailAddress      xmlns:m="http://schemas.microsoft.com/hs/2001/10/myProfile">       <m:e-mail>john@fabrikam.com</m:e-mail>       <m:name xml:lang="en-us">John Chen</m:name>     </m:e-mailAddress>   </hs:insertRequest> </s:Body> </s:Envelope>

As you can see, most of the XML isn't the HSDL command, but the remainder of the SOAP envelope. When Microsoft makes .NET My Services publicly available, you can use the .NET My Services SDK to generate the SOAP message for you, so I will not provide a detailed explanation of the entire SOAP envelope here. However, you should note a few points.

  • The path element contains information about the forward path of the SOAP message; it can optionally contain additional information that specifies the return path. (I discuss the future of Web services routing later, in the section titled “WS-Routing.”)

  • The child elements of the licenses element are shown without any content in the previous example, but in the future you will be able to define information pertaining to authentication using Kerberos and .NET Passport. (I discuss this later, in the section titled “WS-Security and WS-License.”)

  • The request element does contain information that relates to the HSDL command the SOAP message issues. The service attribute defines the target service, which in this instance is myProfile. The document attribute can have two possible values: content if the request is for data-related purposes, and admin if the request is for administrative purposes. Finally, the method attribute defines the type of request the client wants to have performed on his behalf, which in this case is an insert.

As shown in the preceding listing, the SOAP body element contains the actual HSDL message. As you can see, the message itself is quite simple. The name and emailAddress elements are blue elements, which (as I mentioned previously) means you can insert, modify, or delete the node sets that these elements demarcate. In the preceding example, you insert data into the name node set and the emailAddress node set. You can do this because these node sets are blue elements, but what you cannot do is directly address one of their children. To insert only a user's e-mail address, you must insert an emailAddress node set that contains an e-mail element rather than insert just an e-mail element.



Building XML Web Services for the Microsoft  .NET Platform
Building XML Web Services for the Microsoft .NET Platform
ISBN: 0735614067
EAN: 2147483647
Year: 2002
Pages: 94
Authors: Scott Short

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net