Web Services Performance (WS-Performance)

Draft April 1, 2004

Authors:

Aleksander Slominski, IU Extreme! Lab (Editor)
Kenneth Chiu, IU Extreme! Lab
Sriram Krishnan, IU Extreme! Lab

Copyright Notice

Copyright 2004 by Indiana University Extreme! Lab  All rights reserved.

Indiana University Extreme! Lab (collectively, the "Authors") hereby grant you permission to copy and display the WS-Performance Specification, in any medium without fee or royalty, provided that you include the following on ALL copies of the WS-Performance Specification, or portions thereof, that you make:

1. A link or URL to the Specification at this location

2. The copyright notice as shown in the WS-Performance Specification.

EXCEPT FOR THE COPYRIGHT LICENSE GRANTED ABOVE, THE AUTHORS DO NOT GRANT, EITHER EXPRESSLY OR IMPLIEDLY, A LICENSE TO ANY INTELLECTUAL PROPERTY, INCLUDING PATENTS, THEY OWN OR CONTROL.

THE WS-GOODNESS SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE WS-GOODNESS SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE WS-GOODNESS SPECIFICATION.

The WS-Performance Specification may change before final release and you are cautioned against relying on the content of this specification.

The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the WS-Performance Specification will at all times remain with the Authors.

No other rights are granted by implication, estoppel or otherwise.

Abstract

This document defines a new kind of policy assertions [WS-Policy] which apply to both Web Services and other Web Services specifications.

WS-Performance is provided as-is and for review and evaluation only. IU Extreme! Lab hopes to solicit your contributions and suggestions in the near future. IU Extreme! Lab makes no warrantees or representations regarding the specifications in any manner whatsoever.

Composable Architecture

By using XML, SOAP and related standards it is possible not only to leverage WS* specifications but to compose them together. However there is important missing information not available to WS architects: what are performance implications of various specifications and their parameters. WS-Performance allows to attach such metadata to description of specifications and Web Services.

 

Status

This WS-Performance Specification is an initial public draft release and is provided for review and evaluation only. IU Extreme! Lab hopes to solicit your contributions and suggestions in the near future. IU Extreme! Lab makes no warrantees or representations regarding the specification in any manner whatsover.

Table of Contents

1. Introduction

   1.1. Notational Conventions

   1.2. Namespaces

   1.3. Terminology

2. Policy Assertions for Performance

   2.3. PerformanceToken Assertion

3. Security Considerations

4. Acknowledgements

5. References

1. Introduction

WS-Performance provides a neutral and Web Services friendly mechanism to indicate performance characteristics of Web Services specifications.

We have noticed that one of the most important concern when composing Web Services is impact on performance of each specification. Therefore if there could be a synthetic indicator of performance impact of each specification it could help to automate estimation of composed Web Services.

Initially we considered calling this compositional effect of Web Serviced a 'slowness' factor (or simply 'WS-Slowness') but as we firmly believe Web Services performance will improve due to Moore's Law we have chosen to concentrate on positive performance outlook for Web Services.

1.1. Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].

When describing abstract data models, this specification uses the notational convention used by the XML Infoset [XmlInfoset].

1.2. Namespaces

This specification uses a number of namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant.

Prefix Namespace
S http://www.w3.org/2002/12/soap-envelope
pi http://www.extreme.indiana.edu/xgws/schemas/2004/04/performance
wsp http://schemas.xmlsoap.org/ws/2002/12/policy
xs http://www.w3.org/2001/XMLSchema

Table 1 Prefixes and Namespaces used in this specification

WS-Performance is defined in terms of the XML Information Set [XmlInfoset]. WS-Performance is designed to work with general Web Services framework including WSDL service descriptions and be conformant to the SOAP 1.2 processing model; SOAP 1.2 is not a requirement for using the constructs defined in this specification. The examples in this specification use an XML 1.0  representation but this is not a requirement.

All information items defined by WS-Performance are identified by the XML namespace URI [XML-ns] "http://www.extreme.indiana.edu/xgws/schemas/2004/04/performance". A normative XML Schema document MAY be obtained by dereferencing the XML namespace URI.

1.3. Terminology

We introduce following terms we use throughout this document:

Policy
A policy is a set of domain-specific policy statements
Policy Statement
A policy statement is a group of policy assertions
Policy Assertions
A policy assertion represents an individual preference, requirement, capability or other.

2. Policy Assertions for Performance

The [WS-Policy] specification defines a framework to indicate a service's requirements and policies. We extend this framework to allow making statements not only about services but also about WS* service specifications.

To indicate support for this specification the following policy assertion SHOULD be used:

  <wsp:SpecVersion wsp:Usage="wsp:Required"
           URI="http://www.extreme.indiana.edu/xgws/schemas/2004/04/performance" />

2.1. PerformanceToken Assertion

The <pi:PerformanceToken> element is used to describe what are performance indicators provided by Web Service or WS specification.

<PerformanceToken wsp:Preference="..." wsp:Usage="..." >
  <TokenType>...</TokenType>
  <TokenIssuer>...</TokenIssuer>
  <Claims>...Token type-specific claims...</Claims>
  ...   (TokenType-specific details)
</PerformanceToken>
		

The following describes the attributes and tags listed in the schema outlined above:

/PerformanceToken
This identifies a security token assertion.
/PerformanceToken/@wsp:Preference
This optional attribute specifies the preference of this particular alternative. The preference is expressed as an xsd:int. The higher the value of the preference, the greater the weighting of the expressed preference. If no preference is specified, a value of zero is assumed.
/PerformanceToken/@wsp:Usage
This mandatory attribute indicates the usage of this assertion (e.g., required, optional, etc.) per WS-Policy.
/PerformanceToken/TokenType
This mandatory element expresses the type of the performance token for this assertion specified by a QName. This is extensible, but the following types are predefined:

 

QName Description
pi:PeakMessagesPerSecond Maximum number of messages that service can process per second
NOTE: not applicable to WS specifications
pi:AverageTimeToProcessMessageInMs Average time to process input message in milliseconds
pi:SlowDownFactor How many times slower (expressed in xsd:double) is using particular feature when compared to some baseline
NOTE: this is further defined by additional specification, for example we expect to have WS-Security specific set of claims to describe impact of message encryption and signing
QName Additional token types can easily be added
 

/PerformanceToken/TokenIssuer
This optional element's contents are interpreted as the name of a trusted issuer (or names of trusted issuers).
/PerformanceToken/Claims
This optional element contains data that is interpreted as describing type-specific claims that are expressed in the performance token. TokenType-specific descriptions, such as required extensions environment characteristics to meet performance requirements, MUST be specified using this mechanism.
/PerformanceToken/{any}
This is a general extensibility mechanism to allow additional elements to be specified.
/PerformanceToken/@{any}
This is an extensibility mechanism to allow additional attributes to be specified.

 

3. Security Considerations

It is strongly RECOMMENDED that policies and assertions about WS specifications will be signed by all specifications authors

It is strongly RECOMMENDED that policies and assertions about Web Services endpoints be signed by service designers and implementators.

4. Acknowledgements

This work was done under influence of Global XML Web Services Specification Architecture.

5. References

[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997

[WS-Policy] "Web Services Policy Framework", BEA, IBM, Microsoft, SAP, December 2002 (see http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-policy.asp )

[XmlInfoset] W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001 (see http://www.w3.org/TR/2001/REC-xml-infoset-20011024/ )

[XML-ns] W3C Recommendation "Namespaces in XML", Tim Bray  et al., 14 January 1999 (see http://www.w3.org/TR/1999/REC-xml-names-19990114/  )