1. Introduction
The use of Web Services on the World Wide Web is expanding rapidly as the need for application-to-application communication and interoperability grows. These Web services provide a standard means of communication among different software applications, running on a variety of platforms and/or frameworks. The architecture presented in this document is intended to promote interoperability and extensibility among these various applications, platforms and frameworks in a manner that remains consistent with the architecture of the Web [2].
This document describes the Web services reference architecture, including the identification of candidate technologies that meet the functionality defined within the architecture. For example, the reference architecture includes transport services, and references SOAP as a candidate technology that meets the defined functionality.
The Web services reference architecture identifies the functional components comprising the Web services stack of technology, and defines the relationships among the components in the stack. The architecture also illustrates the execution environment for Web services technologies.
| Editorial note | |
| MC: I've added a lot of stuff here ... | |
"Web Services" does not currently describe a coherent set of technologies, architectures, or even visions. The community of web services developers represents a merging of at least three major sources of inspiration, with various ideas taken from other sources as well. Several streams of thought and practice have merged to produce what we think of as web services, including:
"Distributed Objects" or "Application Integration" -- exchange of programming objects or invocation of software functions over a network.
EDI / B2B - the exchange of electronic business documents over a network.
The World Wide Web itself - accessing human readable documents and posting requests for information, products, or services via the HTTP protocol.
The excitement about web services in the last two years or so is based largely on the potential for a combination of XML, the Web, the SOAP and WSDL specifications, and to-be-defined protocol stacks to address many of the problems these technologies have encountered. For example, distributed object systems such as Microsoft's COM family and the OMG CORBA standard did not interoperate, each presented numerous security and administration challenges when deployed over the internet, and neither quite meet the scalability expectations created by the Web. Various XML-based B2B systems have showed much potential, but created incompatible protocols on top of the internet standards which lead to interoperability problems. The Web has proven enormously popular, scalable, and interoperable, but it too presents many challenges -- reliability, security, database-level transactions, details of how to map platform-neutral data, URIs and HTTP operations to back-end application systems, and many others -- that must be handled by Web applications rather than some standardized infrastructure.
The popular Web services standards; SOAP and WSDL, were originally developed outside the W3C but are now being refined and standardized within the Web Services Activity of the W3C. These de-facto standards have helped by creating and extensible messaging framework within which some of these problems can be addressed, and an interface definition language and data encoding conventions that facilitate mapping to back end systems.
| Editorial note | |
| CBF: relocated this discussion temporarily. Probably belongs somewhere under features since MEPs are specialized features as defined by SOAP1.2. | |
| Editorial note | |
| MC: Put it back in the Introduction at Dave's request. I guess the editors need to talk about this ...The discussion of MEP probably belongs somewhere else, but the simple diagrams belong early in the document. | |
| Editorial note | |
| CF: Not sure that I agree that we necessarily want diagrams here. Early on, yes, but this is too premature. | |
| Editorial note | |
| CF: begin Eric's contribution. | |
The Web services architecture describes a system of related technologies that exchange messages between senders and receivers. The architecture extends the message exchange into "patterns" such as one-way, request/response, and pub/sub. Message exchange patterns are further extended with functionality to ensure privacy, coordinate transactions, orchestrate multiple message exchange patterns, among other things. Web services architecture components are defined using XML applications, and use XML for message data typing and structuring.
Figure 1 illustrates the basic concept of the Web services architecture. A message is sent from a sender and received by a receiver. The level of abstraction at which Web services operates encompasses such interaction styles as RPC emulation, asynchronous messaging, one-way fire and forget style messaging, broadcast, and publish and subscribe. All message interaction styles, or patterns, are composed of one or more one-way asynchronous messages.
Figure 2 illustrates a second fundamental concept of Web services architecture: a receiver can publish a service description that the sender can use to construct the message and send it to the receiver. The service description provides the message definition and the receiver's endpoint address.
Figure 3 illustrates that a Web services receiver can also be a sender, constructing a request/response message interaction pattern.
Figure 4 illustrates the concept that Web services message patterns can include intermediaries, which are by definition both senders and receivers.
Figure 5 illustrates the concept that web services messages can carry semantic information for higher level functions such as security, transaction coordination, reliability, and orchestration.
At a high level, a Web service is two, or more, software agents exchanging
information using a variety of Message Exchange Patterns (MEP). A very common
Message Exchange Pattern for Web services is the Request Response MEP. This is
illustrated below. A sender sends a request to a receiver, and the receiver
responds. The data that is exchanged in the request or the response is usually
XML carried over an underlying transport or transfer protocol, such as HTTP.
The XML can be XML Element/attribute syntax or it can be defined as an XML
Infoset, or it can be information solely in the underlying protocol. An example
of this is an HTTP GET request that does not contain an XML message, but the
response may carry an XML message.
SOAP provides an extensible framework for the XML data that is
interchanged. The format that SOAP defines has restrictions and places of
extensibility. Web Services Description Language provides a format for defining
the allowable formats for messages to and from agents. These include SOAP, XML,
MIME, and simple HTTP requests. The relationship between Web Services, SOAP and
WSDL is shown below.
Many "real" products and projects are successfully using SOAP and WSDL, and it is clear that a critical mass of knowledge and technology are forming around them, and they will remain at the center of the web services architecture. Nevertheless, there are numerous architectural questions that remain unsolved, or at least whose solution is not widely agreed upon. These include:
Integration with the Web - SOAP 1.1 web services use the HTTP infrastructure to move messages around, and allow standardization of the format of the payload of a POST command, but conventional Web applications are not able to directly access most web services. In particular, it is not possible to hyperlink to SOAP 1.1 web service via HTML links, XSLT document() functions, etc. As many critics have noted, hyperlinks are the very essence of the World Wide Web, and this limitation is quite severe. SOAP 1.2 addresses this issue at a technical level, but there is little architectural guidance available as to when and how to use the various HTTP-friendly and protocol-neutral aspects of the SOAP protocol.
Extension mechanism - SOAP 1.2 provides an extension mechanism via headers, but the implications, --such as when to use XML markup in the body of a message, when to use headers -- are not spelled out. Likewise, it is not clear how SOAP-based protocol extensibility would interoperate with or complement traditional Web applications.
Overall understanding of modules and layering - SOAP 1.2 provides a framework within which additional features can be added via headers, but there is little agreement on the specific categories of functionality that these headers will specify nor on specific format standards.
Detailed objectives are laid out in the accompanying Requirements document [WSAREQ], but at a high level the W3C Web Services Architecture is intended to:
Integrate different conceptions of web services under a common "reference architecture". There isn't a simple one to one correspondence between the architecture of the web and the architecture of existing SOAP-based web-services, but there is a substantial overlap, and the Web Services Architecture needs to identify what they have in common and how they differ.
Describe the "best practice" for the set of rules that existing Web service agents typically follow, and to rationalize the best practices from the different communities. The objective is not to say "this practice is good" or "that practice is bad", but rather to say "this specific approach is brittle in the following ways." or "That common practice works better if X occurs as well as Y."
Prescribe a framework for the future evolution of web services standards that will promote a healthy mix of interoperability and innovation. That framework must accommodate the edge cases of pure SOAP-RPC at one side and HTTP manipulation of business document resources at the other side, but focus on the area in the middle where the different architectural styles are both taken into consideration.
It is a non-objective to resolve all of the profound disagreements that web services theorists and practitioners continue have over the concepts and technology we the shared area. The W3C WSA will accomodate divergent opinions on whether various services should be implemented at the application or infrastructure level, whether it is appropriate to "tunnel" remote procedure calls over HTTP, etc. Similarly, it is unrealistic to expect the W3C Web Services Architecture to define a set of "Lego blocks" that can be snapped together to build real applications. That is a reasonable vision for the web services industry, but it will require considerable research, experimentation, and standards-building to achieve. This reference architecture is intended to help clear the way for these activities by forming a consensus on what the basic types of components might be, the ways in which they relate to one another, and what to name them.
1.1 Notational Conventions
The key words "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.
1.2 What is a Web service?
[Definition: A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols.]
| Editorial note | |
| CF: I've included the revised, gramatically improved, definition of Web service here. 08/13/02. The WG may wish to consider this when it comes back from its summer hiatus. | |
A Web service is a software agent that acts upon messages from other agents according to some set of principles that must be agreed upon among all agents involved in delivering and consuming a web service.
| Editorial note | |
| MC: "according to the principles defined in this document" makes it sound more authoritative than it really is, and could put some people off. I changed it to something I felt to be more realistic. Also let's refer to this as the W3C WSA so as to distinguish it from several member companies' very similar concepts, e.g. Microsoft's GXA. | |
1.3 Web services Architecture
The Web services architecture consists of:
A single specification of the way in which artifacts of the system are identified: the Uniform Resource Identifier (URI) [1] (see section 2. Identifiers.).
A non-exclusive set of data formats designed for interchange between agents in the system (see section 3. Formats.).
A small and non-exclusive set of protocols for interchanging information between agents (see section 4. Protocols.).
A small and non-exclusive set of ... (see section 5. Processing Model).
Each of these is discussed in detail in the following sections.
2. Identifiers
The Web services architecture builds directly upon the Web Architecture [2]. As such, the Web services architecture directly leverages the definition of, and architectural constraints placed on, identifiers from the Architecture Principles of the Web[2].
What about QNames as identifiers as used by WSDL? TAG Finding.
What about UUIDs as identifiers as used by UDDI? Don't believe that there is a formally registered URI scheme for UUIDs.
Constraint: URIs as identifiers
URIs MUST be used to identify all conceptual elements of the system (see Web Services Architecture Requirements: AR009.3).
3. Formats
As with identifiers (see section 2. Identifiers), the Web services architecture builds upon the definition of, and architectural constraints placed on, formats from Architecture Principles of the Web[2].
...
3.1 XML Infoset
Specifications for data formats used in the context of Web services SHOULD be based on XML Infoset [3]. XML Infoset is not a data format per se, but a formal set of information items and their associated properties that comprise an abstract description of an XML document [4]. The XML Infoset specification provides for a consistent and rigorous set of definitions for use in other specifications that need to refer to the information in a well-formed XML document.
Serialization of the XML Infoset definitions of information MAY be expressed using XML1.0 [4]. However, this is not a requirement. The flexibility in choice of serialization format(s) allows for broader interoperability between agents in the system.
3.2 XML Schema
say something nice about XML Schema [5]. Probably want to say something about preference for use of XML Schema Datatypes [6] if nothing else.
3.3 SOAP
One of the key specifications used in the context of Web services is SOAP [7]. The format of a SOAP message is formally defined in the SOAP1.2 Part 1: Messaging Framework specification. However, SOAP is much more than simply a message format.
| Editorial note | |
| refer to (and develop!) other sections describing extensibility, binding framework, and process model. | |
3.3.1 SOAP Extensibility
SOAP provides a simple messaging framework whose core functionality is concerned with providing extensibility. Extensions to the base messaging framework defined by SOAP are modeled and specified as abstract features. Example features include "reliability", "security", "correlation", and "routing". The Web services architecture describes a number of these features (see section 8. Web Services Features), their inter-relationships with one another, and their purpose within the overall architecture.
A SOAP feature MUST clearly and completely specify the content and semantics of the properties used to implement the desired behavior, including any modifications to the SOAP Processing Model (see section 3.3.3 Process Model).
Constraint: URIs as identifiers
All SOAP Features MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 3.4 WSDL).
Expression of a SOAP Feature is accomplished through one of the two mechanisms provided for by SOAP:
the SOAP Binding Framework, or
as a SOAP Module
One special type of SOAP Feature is the Message Exchange Pattern (MEP). A MEP is a template that establishes a pattern for the exchange of messages between SOAP nodes. Examples of MEPs include: request/response, oneway, peer-to-peer conversation, etc. A MEP MAY be supported by one or more underlying protocol binding instances either directly, or indirectly with support from software that implements the required processing to support the SOAP Feature as expressed as a SOAP Module.
Constraint: URIs as identifiers
All MEPs MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 3.4 WSDL).
3.3.1.1 SOAP Module
A SOAP Module is a formally specified expression of a SOAP Feature as one or more SOAP header blocks. Refer to the SOAP specification for the detailed requirements of a SOAP Module. A SOAP Module is typically used to express a feature that is not provided for either directly or indirectly through mechanisms of the bound transport, or transfer, protocol. They are also used for the expression of end-to-end SOAP Features that might span multiple, disparate transport, or transfer, protocols as the message is conveyed from original sender to ultimate receiver.
3.3.2 SOAP Protocol Binding Framework
SOAP provides for the exchange of messages between software agents known as SOAP nodes using a variety of underlying transport, or transfer, protocols. The formal set of rules for exchanging a SOAP message via an underlying protocol is called a binding. The SOAP Protocol Binding Framework provides general rules for the specification of bindings to an underlying protocol. The framework also describes the formal relationship between bindings and the SOAP nodes that implement those bindings.
Constraint: URIs as identifiers
All SOAP Protocol Bindings MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 3.4 WSDL).
3.4 WSDL
say something nice about WSDL. e.g. it is the preferred format for describing Web services.
| Editorial note | |
| CF: Eric's thoughts on WSDL process model | |
Both the sender and receiver of a Web services message must have access to the same service description. The sender needs the service description to know how to format the message correctly and the receiver needs the service description to understand how to receive the message correctly.
As long as both the sender and receiver have the same service description, (e.g. WSDL file), the implementations behind the Web services can be anything. Web services typically are implemented using programming languages designed for interaction with the web, such as Java Servlets or Application Server Pages (ASPs) that call a back-end program or object. These Web service implementations are also typically represented using a Web services description language.
The Web services description language contains the message data type and structure definition, the message exchange pattern definition, and the endpoint address the receiver listens on. When a sender wishes to send a message to a receiver, the sender obtains the service description and generates a message corresponding to the data type and structure information contained within the service description, and sends the message to the endpoint address identified in the service description. The receiver listens at the defined address for messages. When the receiver receives a message, the receiver validates the message using the data type and structure information in the service description, and uses information in the service description and associated with the service description to transform or map the message contents onto an executable program. Similarly, the sender's executable program generates the message using information in the service description and information associated with the service description.
Web service definitions can be mapped to any language, object model, or messaging system. Simple extensions to existing Internet infrastructure can implement web services for interaction via browsers or directly within an application. The application could be implemented using COM, JMS, CORBA, COBOL, or any number of proprietary integration solutions.
4. Protocols
Now provide description of Web service protocols
SOAP protocol binding framework
-------------------------------
http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#transpbindframew
The SOAP Protocol Binding Framework provides general rules for the
specification of protocol bindings; the framework also describes the
relationship between bindings and SOAP nodes that implement those
bindings.
http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#bindfw
The creation, transmission, and processing of a SOAP message,
possibly through one or more intermediaries, is specified in terms
of a distributed state machine.
... each SOAP message is modeled as an XML Infoset ...
... the XML Infoset of a SOAP message MUST NOT include a DTD ...
Bindings MAY provide for streaming when processing messages.
Bindings MAY depend on state that is modeled as being outside
of the SOAP XML Infoset.
| Editorial note | |
| talk about modules and layering ... interoperability is possible without all "web services" using the same set of features and modules, but there has to be a conceptual agreement on what the features are, how they are packaged, and how they are layered ... | |
4.1 HTTP
something about HTTP, possibly as normative binding described for SOAP.
HTTP has a special status in the W3C Web Services Architecture for a number of both practical and theoretical reasons. For one, early versions of SOAP (and XML-RPC, which is still widely used in existing web services) were explicitly tied to HTTP. SOAP 1.1 implied a certain amount of protocol-independence, and SOAP 1.2 makes this explicit, but HTTP is still the dominant means of communicating between web services agents. Also, HTTP is
4.2 Other Protocols
Many believe that HTTP is the "native" protocol of the Web because it was designed to work with the URIs that identify Web resources. While HTTP has become almost ubiquitous, and many of the issues surrounding its earlier incarnations have been resolved in subsequent versions of the standard and by "industrial strength" implementations, it is not the only protocol upon which Web Services can be built. For example
TCP
UDP
BEEP
JMS
proprietary messaging systems
5. Processing Model
Now provide description of SOAP and WSDL Processing models
Processing model ---------------- http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#msgexchngmdl SOAP provides a distributed processing model that assumes a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soapnodes A SOAP node can be the initial SOAP sender, an ultimate SOAP receiver, or a SOAP intermediary. A SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing model. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soaproles In processing a SOAP message, a SOAP node is said to act in one or more SOAP roles, each of which is identified by a URI known as the SOAP role name. This specification defines the following SOAP roles: http://www.w3.org/2002/06/soap-envelope/role/next http://www.w3.org/2002/06/soap-envelope/role/none http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#targettingblocks A SOAP header block MAY carry a role attribute information item that is used to target the header block at SOAP nodes operating in the specified role. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#muprocessing A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that header block. ... for every mandatory SOAP header block targeted to a node, that node MUST either process the header block or not process the SOAP message at all, and instead generate a fault http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#structinterpbodies An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#procsoapmsgs Rules for SOAP processing and the kinds of faults that must be generated. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#envvermodel A SOAP Version 1.2 message has a child element information item of the document information item with a local name of Envelope and a namespace name of "http://www.w3.org/2002/06/soap-envelope". If a SOAP node receives a message whose version is not supported it MUST generate a fault with a Value of Code set to "env:VersionMismatch". Any other malformation of the message construct MUST result in the generation of a fault with a Value of Code set to "env:Sender".
7. System Architecture
This diagram shows a System compliant with the web services architecture, and the data flow between various parties.
8. Web Services Features
Note:
It is not the intent of this specification to provide a normative specification of the features described below. That work is intended to be the product of an other W3C Working Group, an external SDO, or of a proprietary nature such as an internal IT organization or vendor-specific specification. The descriptions of Web service features described in this specification are intended as a generalized description, combined with a set of constraints that would serve as input to the formal development of a specification for such a feature.
Note:
ImageMap to link to the sections on each...
| Editorial note | |
| CBF: really? can this be done in xmlspec? | |
| Editorial note | |
| CF: added Eric's stack diagram here. | |
This shows 3 stacks of Web Services Features, that are closely related. A transport stack is for standards that are exchanged on the wire. Description is for describing an individual or collection of services. Discovery is the finding of services. The salmon coloured section shows specifications that are related to a particular stack. The light orange shows which specifications would be embedded in or expressed in the specification listed at the bottom. An example is security headers expressed in a soap message, or message exchange patterns described in WSDL. The orange boxes indicate individual specifications.
We expect that a base standard for the transport is SOAP. This can contain the following headers:
Asynchrony - dynamic specification of ports for callback messages
Routing - forward and reverse message paths
Security - Digital signatures, Encryption, Credentials, and authentications
Caching
Reliability - typical reliability semantics of best effort, once and only once, at least once, etc.
Conversations - long running stateful conversations between services
Transactions - Compensating, two-phase, atomic, other transaction styles.
Management - These are messages, or system services, related to web services. Examples are Ping, Status, Control messages. the line in the light orange box indicates the separation between messages and headers.
Packaging - containers for SOAP messages, like MIME or DIME
Description is based upon WSDL. In general, there will be WSDL definitions of each of the elements in the transport layer. It can contain:
XML Schema definitions of types
Choreography - aka orchestration/workflow, the ordering of messages between 2 or more parties.
Service characteristics - the static information about a service, such as reliability, availability, privacy policies. This information is typically not expressed in a transport message.
Discovery, typically invoked with SOAP messages, contains a large variety of information, typically descriptions of services and businesses. It has aspects of:
Inspection, the retrieval of information about a service or an organization from that service or organization. Very limited query capabilities.
Registry based, queries are often to 3rd party registries. Examples are UDDI, ebXML Registry.
There are other aspects that are either architectural or orthogonal. Security and Manageability are aspects that are architectural in nature. Workflow Languages - these are the programmatic specification of choreography. These are not exchanged at run-time, but typically between two authoring tools.
12. System Aspects
These are aspects that broadly affect the architecture. The specific protocol, description or discovery aspects are covered in those sections.
13. References
13.1 Normative References
- [1]
- IETF RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, August 1998 (See http://ietf.org/rfc/rfc2396.txt.)
- [2]
- DRAFT: Architecture Principles of the World-Wide Web (See http://www.w3.org/2001/tag/2002/0813-archdoc.)
- [3]
- XML Information Set, W3C Recommendation, eds. J. Cowan, R. Tobin, 24 October 2001 (See http://www.w3.org/TR/xml-infoset/.)
- [4]
- Extensible Markup Language (XML) 1.0 (Second Edition), W3C, eds. T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler. 6 October 2000 (See http://www.w3.org/tr/rec-xml/.)
- [5]
- W3C Recommendation "XML Schema Part 1: Structures", eds. H. Thompson, D. Beech, M. Maloney, N. Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/xmlschema-1/.)
- [6]
- W3C Recommendation "XML Schema Part 2: Datatypes", eds. P. Biron, A. Malhotra, 2 May 2001. (See http://www.w3.org/TR/xmlschema-2/.)
- [7]
- W3C Working Draft "SOAP Version 1.2 Part 1: Messaging Framework", eds. M. Gudgin, M. Hadley, J. Moreau, H. Nielsen, 26 June 2002 (See http://www.w3.org/TR/soap12-part1/.)
- [8]
- W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", eds. M. Gudgin, M. Hadley, J. Moreau, H. Nielsen, 26 June 2002 (See http://www.w3.org/TR/soap12-part2/.)
- [9]
- Web Services Description Language (WSDL) Version 1.2, eds. R. Chinnici, M. Gudgin, J. Moreau, S. Weerawarana (See http://www.w3.org/TR/wsdl12/.)
13.2 Informative References
- [ebMS]
- Message Service Specification, ebXML TRP Version 1.0 (See http://www.ebxml.org/specs/ebMS.pdf.)
- [SOAPAttach]
- SOAP Messages with Attachments (See http://www.w3.org/TR/SOAP-attachments.)
- [SOAPPRIMER]
- SOAP 1.2 Part 0 (See http://www.w3.org/TR/2002/WD-soap12-part0-20020626/.)
- [SOAPREQS]
- XML Protocol (SOAP) Requirements (See http://www.w3.org/TR/2001/WD-SOAP-reqs-20010319/#N2082.)
- [USAGE]
- XML Protocol Usage Scenarios (See http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/.)
- [CHARTER]
- Web Services Architecture Charter (See http://www.w3.org/2002/01/ws-arch-charter.)
- [WSAREQ]
- Web Services Architecture Requirements (See http://www.w3.org/tr/wsa-reqs.)
- [WSRP]
- Web Services Routing Protocol (WS-Routing) (See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsrvspev/html/ws-routing.asp.)