WS-I Usage Scenarios

Document Status: Final Specific= ation

Version: 1.01

Date: <= st1:date ls=3D"trans" Month=3D"12" Day=3D"9" Year=3D"2003" w:st=3D"on">December 9,= 2003

Editors: Scott Werden, WRQ

&nbs= p; Colleen Evans, Sonic Software

&nbs= p; Marc Goodner, SAP

&nb= sp;

Notice

The material contained herein is not a license, either expressly or impliedly, to any intellectual property owned or controlled by= any of the authors or developers of this material or WS-I. The material contain= ed herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors and developers of this material and WS-I hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpos= e, of accuracy or completeness of responses, of results, of workmanlike effort= , of lack of viruses, and of lack of negligence. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THIS MATERIAL.

IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATER= IAL OR WS-I BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOOD= S OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

Status of this Document

This is a final specification. Readers should refer to the WS-I.org web site for errata and updates.=

Table of Cont= ents

1&= nbsp; Introduction. 5<= o:p>

1.1&= nbsp; How to use this document 5<= o:p>

2&= nbsp; Usage Scenario Taxonomy. 5<= o:p>

2.1&= nbsp; Web Service Stack 5<= o:p>

2.2&= nbsp; Activities = 6<= o:p>

2.2.1&= nbsp; Data Layer Activities 7<= o:p>

2.2.2&= nbsp; SOAP Message Layer Activities 7<= o:p>

2.2.3&= nbsp; Transport Layer Activities 8<= o:p>

2.2.4&= nbsp; Web Service Actors 8<= o:p>

2.3&= nbsp; Security. 8<= o:p>

3&= nbsp; Usage Scenarios 8<= o:p>

3.1&= nbsp; One-way. 8<= o:p>

3.1.1&= nbsp; Description. 8<= o:p>

3.1.2&= nbsp; Flow. 9<= o:p>

3.1.3&= nbsp; Flow Constraints 11<= o:p>

3.1.4&= nbsp; Description Constraints 12<= o:p>

3.1.5&= nbsp; UDDI = 13<= o:p>

3.1.6&= nbsp; Security. 14<= o:p>

3.2&= nbsp; Synchronous Request/Response. 14<= o:p>

3.2.1&= nbsp; Description. 14<= o:p>

3.2.2&= nbsp; Flow. 14<= o:p>

3.2.3&= nbsp; Flow Constraints 18<= o:p>

3.2.4&= nbsp; Description Constraints: WSDL 19<= o:p>

3.2.5&= nbsp; UDDI = 20<= o:p>

3.2.6&= nbsp; Security. 20<= o:p>

3.3&= nbsp; Basic Callback 20<= o:p>

3.3.1&= nbsp; Description. 21<= o:p>

3.3.2&= nbsp; Details = 22<= o:p>

3.3.3&= nbsp; Flow. 22<= o:p>

3.3.4&= nbsp; Flow Constraints 30<= o:p>

3.3.5&= nbsp; Description Constraints 30<= o:p>

3.3.6&= nbsp; UDDI = 33<= o:p>

3.3.7&= nbsp; Security. 33<= o:p>

4&= nbsp; Appendix 1 – Security. 34<= o:p>

4.1&= nbsp; Authentication. 34<= o:p>

4.1.1&= nbsp; Request Authentication. 34<= o:p>

4.1.2&= nbsp; Response Authentication. 34<= o:p>

4.2&= nbsp; Authorization. 35<= o:p>

4.2.1&= nbsp; Request Authorization. 35<= o:p>

4.3&= nbsp; Confidentiality. 35<= o:p>

4.4&= nbsp; Data Integrity. <= /span>36<= o:p>

4.5&= nbsp; Replay. 36<= o:p>

4.6&= nbsp; Logging and Auditing. 36<= o:p>

4.7&= nbsp; Other Risks 36<= o:p>

5&= nbsp; Appendix 2 – Constraints 36<= o:p>

5.1&= nbsp; Write XML 37<= o:p>

5.2&= nbsp; Process XML 37<= o:p>

5.3&= nbsp; Write SOAP Envelope. 37<= o:p>

5.4&= nbsp; Process SOAP Envelope. 37<= o:p>

5.5&= nbsp; Write SOAP Body. <= /span>37<= o:p>

5.6&= nbsp; Process SOAP Body. <= /span>37<= o:p>

5.7&= nbsp; Write SOAP Header 37<= o:p>

5.8&= nbsp; Process SOAP Header 37<= o:p>

5.9&= nbsp; Send HTTP. <= /span>37<= o:p>

5.10&= nbsp; Receive HTTP. <= /span>38<= o:p>

5.11&= nbsp; General WSDL Constraints 38<= o:p>

5.12&= nbsp; Constraints on WSDL types 38<= o:p>

5.13&= nbsp; Constraints on WSDL messages 38<= o:p>

5.14&= nbsp; Constraints on WSDL portTypes 38<= o:p>

5.15&= nbsp; Constraints on WSDL Bindings 38<= o:p>

5.16&= nbsp; Constraints on WSDL Port 39<= o:p>

5.17&= nbsp; General UDDI constraints 39<= o:p>

6&= nbsp; References = 39<= o:p>

Table of Figu= res

Figure 2‑1 Web services stack 6<= o:p>

Figure 3‑1 One-way Sequence. 9<= o:p>

Figure 3‑2 One-way Request 10<= o:p>

Figure 3‑3 One-way Acknowledgement 11<= o:p>

Figure 3‑4 Synchronous Request/Response Sequence. 14<= o:p>

Figure 3‑5 Synchronous Request 15<= o:p>

Figure 3‑6 Synchronous Response. 17<= o:p>

Figure 3‑7 Basic Callback Sequence. 21<= o:p>

Figure 3‑8 Basic Callback Consumer Request 23<= o:p>

Figure 3‑9 Basic Callback Provider Acknowledgement 25<= o:p>

Figure 3‑10 Basic Callback Provider Response. 27<= o:p>

Figure 3‑11 Basic Callback Consumer Acknowledgement 29<= o:p>

Revision Hist= ory

Version 1.0 = ; Original version

Version 1.01 &nbs= p; Revisions to Board Approval Draft to reflect late changes to the Basic Profile 1.0

1 = Introduction

WS-I Usage Scenarios define the use of Web services in structured interactions, identifying basic interoperability requirements for such interactions and mapping the f= low of a scenario to the requirements of the WS-I Basic Profile 1.0 (hereafter, Basic Profile) [1]. Scenarios = are independent of any application domain. WS-I Use Cases employ Scenarios to m= odel high-level definitions of specific applications.

The scenarios presented here can be composed or extended. That is, t= hey describe fundamental Web service design patterns that can be combined and b= uilt upon like building blocks. For example, the Synchronous Request/Response scenario describes a basic exchange and can be expanded by adding SOAP head= ers. The only requirement is that the extensions must also conform to the Basic Profile.

1.1 How to use this document

This docume= nt describes the WS-I Usage Scenarios to be used with the Basic Profile. The B= asic Profile constraints and requirements are referenced directly and the reader= is expected to use the Basic Profile in conjunction with this document to interpret the referenced information.

The three scenarios presented in this document are int= ended to provide sufficient information so that a user of this document can create WS-I compliant Web service applications using one of more of the scenarios.= All applicable guidelines and restrictions for the messages and service descrip= tion instances for each scenario are provided.

2 = Usage Scenario Taxonomy

The Usage Scenario taxonomy defines a structure for ap= plying the Basic Profile constraints. The taxonomy consists of a Web services stack and a set of activities, grouped by the layers of the stack, that a Web ser= vice instance executes as part of the Web service Usage Scenario. The constraint= s of the Basic Profile are applied to each activity as well as to the optional components of the scenario, e.g., the WSDL for the description of the Web service instance. There are two types of constraints on scenarios:

Flow Constraints applying to each activity that takes part in the flow of t= he Web service. These include: expressing the Web service data model in X= ML, creating and consuming messages using SOAP, transporting messages using HTTP

de= scription of the Scenario. Operationally, the description of a Web service insta= nce occurs in WSDL and possibly UDDI, therefore, these constraints are app= lied to the WSDL and UDDI describing the Scenario.

The following are attributes of WS-I Usage Scenarios:<= /p>

2.1 Web Service Stack

The Usage Scenario taxonomy is based on a Web services stack. Each layer of the stack represents one of the fundamental functional areas of a Web service instance. Not all possible functional areas are represented (e.g., security or coordination), only the most basic. These la= yers are depicted in the following diagram.

= ;

Figure 2‑1 Web services stack

A Web service application may include several logical = layers incorporating functions such as the Web service instance and application business logic. The Bas= ic Profile and Usage Scenarios do not address application business logic except where the functionality of any part of the Web services stack is implemented within the business logic.

The details of each layer of the Web service stack are= :

Data Layer

The data layer translates the application specific dat= a into the model chosen for the specific Web service. The data layer includes the functions necessary to support flexible data typing. This layer maps to the= wsdl:types and wsdl:message definitions within a WSDL document.

SOAP Message Layer

The SOAP message layer is the infrastructure that proc= esses SOAP messages, dispatches them, and may optionally fulfill Quality of Servi= ce requirements. On the sending side the message layer writes SOAP messages, b= ased on the data model defined in portTypes and bindings. On the receiving side = the message layer processes the SOAP messages and dispatches requests to the correct application or method.

Transport Layer

The transport layer sends and receives messages. For t= he Basic Profile, this includes only HTTP client and server platforms. This layer maps to the wsdl:binding and wsdl:p= ort definitions with the WSDL document.

2.2 Activities

A set of activities is defined for each layer of the W= eb service stack. Activities are the fundamental operations that comprise a Web service. A single activity has several constraints applied to it from the B= asic Profile. For example, one act= ivity might be “Send HTTP” and the specifications and guidelines for = how to fulfill that activity come from the SOAP 1.1 and HTTP sections of the Ba= sic Profile.

The following table summarizes these activities.

Layer=	Activity
Data Layer	Write XML Process XML
SOAP Message Layer	Write SOAP envelope Process SOAP envelope Write SOAP body Process SOAP body Write SOAP header Process SOAP header
Transport Layer	Send HTTP Receive HTTP

Table 1 - Activities grouped by Web services stack layer

2.2.1= Data Layer Activities

The following activities are part of the Data layer:

Write XML

Application-level messages that are to be exchanged du= ring a Web services interaction must be written to a serialized form that can be transported with the underlying transport protocol. These messages use the = data types and formats declared in the data model documentation (i.e., WSDL or Schema). Writing the message = data is the responsibility of the application component sending a message to a recipient.

Process XML

Application-level messages that are exchanged in a Web services interaction are passed to application components responsible for receiving, interpreting and acting upon the received messages. Application components process mes= sage data according to the types and formats declared in the data model documentation.

2.2.2= SOAP Message Layer Activities

The following activities are executed with the SOAP Me= ssage Layer.

SOAP envelope<= /span>

The SOAP envelope is the container for all the ot= her SOAP message parts, including the payload.

Write SOAP envelope
Process SOAP envelope

SOAP body

The SOAP body is used for transporting application-spe= cific information included in the application message data. The activities in this layer are different from the data payload writing and processing activities described in the Data Layer activities section.

Write SOAP body=
Process SOAP body

SOAP header

The SOAP header provides a modular mechanism for exten= ding a SOAP message.

Write SOAP header
Process SOAP header

2.2.3= Transport Layer Activities

SOAP messages may be sent using the HTTP or HTTPS tran= sport protocols.

Send HTTP
Receive HTTP

2.2.4= Web Service Actors

In WS-I Web services scenarios there are two high level actors. These are not related to SOAP Actors as defined in SOAP 1.1.

Consumer

A Consumer is responsible for making requests of a ser= vice implemented by a Provider.

Provider

A Provider is responsible for listening for and proces= sing Consumer service requests.

2.3 Security

Usage scenarios do not explicitly address authenticati= on, authorization, identification, or privacy. However, some of those concerns = can be addressed with existing technologies that are compatible with the Basic Profile. For example, the HTTPS binding can be used rather than the un-encrypted HTTP binding. Application level security can always be added within the message layer and this would be entirely transparent to the Basic Profile.

Countermeasures are best applied through a risk assess= ment of your Web service application. To assist in this process please see the Security Appendix below for more detailed information on common threats and Basic Profile compliant mitigation strategies. Each Usage Scenario includes= a section detailing additional concerns as well as the identified common thre= ats most relevant to the given scenario.

3&nb= sp; Usage Scenarios

This section defines the three Usage Scenarios develop= ed to complement the Basic Profile:

One-way
Synchronous request/response
Basic callback

3.1 One-way

3.1.1= Description

A Consumer sends a request message to a Provider. The Provider receives the me= ssage and processes it.

The exchange is one way; no SOAP response message from= the Provider is generated or expected. The underlying transport is not required to guarantee delivery of the message to the Provider. Rega= rdless of the protocol implemented by the transport layer, the Consumer receives no acknowledgement above the transport layer that the message was successfully sent, delivered to the intended destination, or received by the Provider.

This Scenario applies to situations where information = loss is inconsequential (for example, in a status monitoring scenario where peri= odic status update events are provided such that if one update event is lost, a subsequent update event will convey correct status).

Figure 3‑1 One-way Sequence

High-level flow:

Consumer invokes the service by s= ending a SOAP message bound to an HTTP request to the Provider
Provider executes the service.

Assumptions:

This scenario describes a runtime sequence of events; it does not describe = the design or deployment activities.
The data model, the application semantics, and the transport bindings are all agreed upon and implemented a priori to this scenario.
All parts of this scenario are defined in conformance with the guidelines = and recommendations of the Basic Profile.
This scenario is “composable”, that is, it may be used as a foundation for creating more complex scenarios.

3.1.2 Flow

The detailed flow for this scenario, using the activit= ies defined in Section

Figure 3‑2 One-way Request

The Consumer initiates a SOAP request:

Data Layer

Write XML. The payload is cre= ated according to the data model.

SOAP Message Layer

Write SOAP envelope
Write SOAP body

Transport Layer

Send HTTP

The Provider receives the SOAP request:

Transport Layer

Receive HTTP

SOAP Message Layer

Process SOAP envelope
Process SOAP body

Data Layer

Process XML. The data payload is processed according to the data model and dispatched to the application

Figure 3‑3 One-way Acknowledgement

The Provider sends the acknowledgement:

Transport Layer

Send HTTP. Note that the HTTP response can be sent at any time relative to= the processing of the SOAP message. There is no SOAP envelope sent with t= he HTTP response.

The Consumer receives the acknowledgement:

Transport Layer

Receive HTTP (status code). This is ignored by the higher layers of the Web services stack.

3.1.3 Flow Constraints

The following are the flow constraints upon this Usage Scenario.

Write XML, as defined in Section 5.1
Write SOAP envelope, as define in Section 5.3
Write SOAP body, as define in Section 5.5
Send HTTP, as defined in Section 5.9. Further constraint specific to this scenario is R2714.
Receive HTTP, as defined in Section 5.10. Further constraints specific to this scenario are R2727 and R2= 750.
Process SOAP envelope, as defined in Section 5.4
Process SOAP body, as defined in Section 5.6
Process XML, as defined in Section 5.2

3.1.3= .1 Error conditions and SOAP Fault

A SOAP Fault cannot be generated in this scenario since there is no SOAP response message. If any error occurs in the Provider, the Provider and Consumer must respectively abide by R2714.

3.1.3.2 SOAP Headers

Use of a SOAP header is optional for this scenari= o. If it is used, it must follow the constraints for the Write SOAP Header and Process SOAP Header activities, as defined in Section 5.7 and 5.8, respectively.

3.1.4= Description Constraints

The WSDL should have at least the following content wi= thin its definitions for the One-way Scenario. Not all sections are required, bu= t if present in the WSDL, each should follow the guidelines as presented below. General constraints on the WSDL are described in Section 5.11. Other constraints imposed upon the WSDL by the B= asic Profile are listed below.

3.1.4.1 types

This section is not required and if present, will be dependent upon the specifics of the data model.

Constraints on WSDL types are listed in Section <= /span>5.12.

3.1.4.2 messages

Message format will be dependent upon the data model (doc/literal or rpc/literal). Only one message is defined: one input.

3.1.4.2.1 Docu= ment messages

Document messages parts are composed from Schema eleme= nt definitions (see R2204)

<wsdl:message …>

&nb= sp; = <wsdl:part name=3D”Input” element=3D”..”>=

</wsdl:message>

3.1.4.2.2 RPC messages

RPC messages parts are composed from Schema type declarations (see R2203)

<wsdl:message …>

&nb= sp; = <wsdl:part name=3D”Input“ type=3D”..” /><= /p>

</wsdl:message>

Other constraints are listed in Section 5.13.

3.1.4.3 portTypes

The one-way transmission primitive must be used. Gramm= ar is:

<wsdl:portType ..>=

<wsdl= :operation …>

&nb= sp; = &nb= sp; <wsdl:input …/>

&nb= sp; = </wsdl:operation>

</wsdl:portType>

Other constraints are listed in Section 5.14.

3.1.4.4 binding

The wsdl:bin= ding section must use the SOAP binding extension with HTTP transport. The same operation type defined in wsdl:po= rtType must be used in the binding section.

<wsdl:binding …>

&= nbsp; <soap:binding style=3D”rpc|document” transport=3Dhttp://schemas.xmlsoap.org/so= ap/http>

&nb= sp; <wsdl:input …>

&nb= sp; </wsdl:input&= gt;

&nb= sp; </soap:binding>

</wsdl:binding>

Other constraints are listed in Section 5.15.

3.1.4= .5 port

The soap:add= ress element must be specified along with the URL for the endpoint:

<wsdl:port>

&nb= sp; <soap:address location=3D”uri” />

</wsdl:port>

Other constraints are listed in Section 5.16.

3.1.5= UDDI

Advertisement of Web services patterned after this sce= nario adheres to the “Using WSDL in a UDDI Registry, Version 1.07” Best Practice document. A uddi:tModel representing the Web service type references the file containing the wsdl:binding for the message operation. The uddi:bindingTemplate captures the service endpoint and references the http://www.uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf<= /a>). These include the browse pattern, = the drill-down pattern and the invocation pattern.

General UDDI Constraints are listed in Section 5.17.

3.1.6= Security

This section identifies the threats most relevant to t= his Usage Scenario as described in Appendix 1 where additional information on B= asic Profile compliant countermeasures may also be found.

Additional constraints may apply if HTTPS is used to implement security. These are Profile requirements: R5000, R5001, R5010, .<= span style=3D'mso-spacerun:yes'> Appendix 1 has additional guidelin= es on Security.

As of this writing no specific threat has been identif= ied as being singularly relevant to this Usage Scenario.

3.2 Synchronous Request/Response

3.2.1= Description

A Consumer sends a request message to a Provider. The Provider receives the message, processes it, and sends back a response.

The following diagram shows the high-level interactions between a Consumer and a Provider in the Synchronous Request/Response Usage Scenario.

Figure= 3‑4 Synchronous Request/Response Sequ= ence

High-level flow= :

1. Consumer invokes the service by sendin= g a SOAP message bound to an HTTP request to the Provider

2. Provider executes the service and send= s a SOAP message bound to an HTTP response to the Consumer

Assumptions:

3.2.2= Flow
The detailed flow for this scenario, using the activit= ies defined in Section

Figure = 3‑5 Synchronous Request

The Consumer initiates a SOAP request:
- Data Layer
- SOAP Message Layer
- Transport Layer
The Provider receives the SOAP request:
- Transport Layer
- SOAP Message Layer
- Data Layer
Figure 3‑6 Synchronous Response

The Provider generates a SOAP response:
- Data Layer
- SOAP Message Layer
- Transport Layer
The Consumer receives the SOAP response:
- Transport Layer
- SOAP Message Layer
- Data Layer
3.2.3 Flow Constraints

The following activities have the referenced constrain= ts in this Usage Scenario.
- Write XML, as defined in Section 5.1
- Write SOAP envelope, as defined in section 5.3
- Write SOAP body, as define in Section 5.5
- Send HTTP, as defined in Section 5.9
- Receive HTTP, as defined in Section 5.10
- Process SOAP envelope, as defined in Section 5.4
- Process SOAP body, as defined in Section 5.6
- Process XML, as defined in Section 5.2
3.2.3= .1 Errors and SOAP Faults

Errors that occur during SOAP processing are communica= ted with a SOAP Fault message, as per the SOAP 1.1 specification. This scenario supports SOAP Faults through composition, that is, all the constraints described in sections 3.2.3 and 3.3.4.1 apply, plus the additional constraints imposed up= on the following Activities.

The Web service Provider must abide by the following restrictions and guidelines from the Basic Profile:
- Behavior for fault generation: R2= 724, R2725
- Writing the soap:fault: R1000, R1001, R1004, R1031, R2742, R2743
- HTTP SOAPAction: R1119
- HTTP status codes: R1126
- Requirements for WSDL description: R2728, R2742, R2743, R2754
The Web service Consumer must follow the following restrictions and guidelines from the Basic Profile:
- Processing the soap:fault: R1002, R1003, R1016
3.2.3.2      SOAP Headers

Use of a SOAP header is optional for this scenari= o. If it is used, it must follow the constraints for the Write SOAP Header and Process SOAP Header activities, as defined in Sections 5.7 and 5.8, respectively.

3.2.4=       Description Constraints: WSDL

The WSDL should have at least the following content wi= thin its definitions for the Synchronous Request/Response Scenario. Not all sect= ions are required, but if present in the WSDL, each should follow the guidelines= as presented below. General constraints on the WSDL are described in Section <= span style=3D'mso-field-code:" REF _Ref24415586 \\r \\h "'>5.11. Other constraints imposed upon the WSDL by the B= asic Profile are listed below.

3.2.4.1    types

This WSDL section is not required, and if present, wil= l be dependent upon the specifics of the data model.

Constraints on types are listed in Section 5.12.

3.2.4.2    messages

Message format will be dependent upon the data model (doc/literal or rpc/literal). At least two messages must be defined: one in= put and one output. Optionally, a fault message may also be defined.

3.2.4.2.1 Docu= ment messages

Document message parts are composed from Schema element definitions (see R2204)

<wsdl:message …>

&nb= sp;            =    <wsdl:part name=3D”..” element=3D”..”>

&nb= sp;            =    <wsdl:part name=3D”..” element=3D”..”/>
</wsdl:message>

3.2.4.2.2 RPC messages

RPC message parts are composed from Schema type declar= ations (see R2203)

<wsdl:message …>

&nb= sp;            =    <wsdl:part name=3D” “ type=3D”..” />

&nb= sp;            =    <wsdl:part name=3D” “ type=3D”..”/>

</wsdl:message>

Constraints on messages are listed in Section 5.13.

3.2.4.3    portTypes

The request/response transmission primitive must be us= ed. Grammar is:

<wsdl:portType ..>=

<wsdl= :operation …>

&nb= sp;            =             &nb= sp;      <wsdl:input …/>

&nb= sp;            =             &nb= sp;      <wsdl:output …/>

&nb= sp;            =    </wsdl:operation>

</wsdl:portType>

Constraints on portTypes are listed in Section 5.14.

3.2.4.4    binding

The wsdl:bin= ding section must use the SOAP binding extension with HTTP transport. The same operation defined in wsdl:portTyp= e must be used in the binding section.

<wsdl:binding …>

        &= nbsp;       <soap:binding style=3D”rpc|document” transport=3Dhttp://schemas.xmlsoap.org/so= ap/http>

    &nb= sp;         <wsdl:input …>

    &nb= sp;         </wsdl:input&= gt;

    &nb= sp;         <wsdl:output …>

    &nb= sp;         </wsdl:output= >

    &nb= sp; </soap:binding>

</wsdl:binding>

Constraints on bindings are listed in Section 5.15.

3.2.4.5    port

The soap:add= ress element must be specified along with the URL for the endpoint:

<wsdl:port>

    &nb= sp; <soap:address location=3D”uri” />

</wsdl:port>

Constraints on port definitions are listed in Sec= tion 5.16.

3.2.5=       UDDI

Advertisement of Web services patterned after this sce= nario adheres to the “Using WSDL in a UDDI Registry, Version 1.07” Best Practice document. A uddi:tModel representing the Web service type references the file containing the wsdl:binding for the synchronous message operation(s). The uddi:bindingTemplate captures the service endpoint and references the uddi:tModel(s) for the Web service type.

Advertising Web services in this way e= nables discovery using the inquiry patterns supported by the UDDI Inquiry API set = (see http://www.uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf). These include the browse pattern, = the drill-down pattern and the invocation pattern.

General UDDI Constraints are listed in Section 5.17.

3.2.6      Security

This section identifies the threats most relevant to t= his Usage Scenario as described in Appendix 1 where additional information on B= asic Profile compliant countermeasures may also be found.

Additional constraints may apply if HTTPS is used to implement security. These are Basic Profile requirements: R5000, R5001, R5010. Appendix 1 has additio= nal guidelines on Security.

As of this writing no specific threat has been identif= ied as being singularly relevant to this Usage Scenario.

3.3     Basic Callback

3.3.1=       Description

The Basic Callback scenario facilitates a form of asynchronous message exchange for Web services. This is accomplished through the composition of two synchronous request/response pairs. The messages are related via correlation information that is provided by the Consumer. The Consumer also provides the endpoint information for the callback service location to the Provider. The definition of the callback service is defined by the Provider in the publis= hed Web service description and implemented by the Consumer.

At runtime a Consumer sends the initial SOAP request i= n a request/response sequence to the Provider, which in turn sends back an immediate acknowledgement of receipt. At a later point in time the Provider will initiate the final request/response sequence to the Consumer containing the response data for the initial request sent by the Consumer. The following diagram shows the high-level interactions between a Consumer and a Provider in the Basic Call= back Usage Scenario.

Figure 3‑7 Basic Callback Sequence

High-level flow:
1. Consumer initiates the service by sending a SOAP message bound to an HTTP request to the Provider (the “initial request”)
2. Provider acknowledges receipt via= a SOAP message bound to an HTTP response to the Consumer (the “ini= tial response”)
3. Provider completes the exchange by sending a SOAP message bound to an HTTP request to the Consumer with t= he results of the initial request (the “final request” or “callback”)
4. Consumer acknowledges receipt of = the callback message with a SOAP message bound to an HTTP response (the “final response”)
Assumptions:
- This scenario is a runtime sequence of events; it does not involve any desi= gn or deployment activities.
- The data model, the application semantics, the callback correlation mechan= ism, and the transport bindings are all agreed upon and implemented a prior= i to this scenario.
- All parts of this scenario are defined in conformance with the guidelines = and recommendations of the Basic Profile.
- This scenario is “composable”, that is, it may be used as a foundation for creating more complex scenarios.
3.3.2 Details

The Basic Callback scenario is built upon two correlat= ed synchronous request/response interactions. Since a Consumer and a Provider = may have many outstanding requests, there needs to be a mechanism for each part= y to unambiguously identify which callback goes with which initial request. This= can be achieved using some business data in the SOAP payload, such as a purchase order number, that can be used to correlate the callback with the request, = or through using some form of message id.

In order to invoke the callback service, the Consumer = must communicate the callback endpoint to the Provider. This can be conveyed at runtime in= the initial SOAP message sent by the Consumer to the Provider, during deploymen= t, or using a discovery mechanism agreed to by both parties.

The Web service description for both the initial and f= inal request/response pairs (i.e., portTypes) may be defined in a single WSDL document. Although it is not a requirement to do so, placing them in the sa= me document will communicate the contract and the expectations on the client m= ore effectively. In loosely coupled situations where two businesses may not wan= t to maintain a single document, the initial and final request/response pairs sh= ould be described in separate WSDL documents.&n= bsp; In either case, portTypes for both the Provider and Consumer Web services shall be defined. The description MAY contain ports for the Provid= er Web services, and DOES NOT contain defined ports for the Consumer Web servi= ces. Since the final service address is not known beforehand, a WSDL port cannot= be defined for the final request/response portType. It is, instead communicate= d by the Consumer as described above.

3.3.3= Flow

The detailed flow for this scenario, using the activit= ies defined in Section

Figure 3‑8 Basic Callback Consumer Request=

The Consumer initiates a SOAP request:
- Data Layer
- SOAP Message Layer
- Transport Layer
The Provider receives the initial SOAP request:
- Transport Layer
- SOAP Message Layer
- Data Layer
Figure 3‑9 Basic Callback Provider Acknowledgemen= t

The Provider generates the acknowledgement (response) message:
- Data Layer
- SOAP Message Layer
- Transport Layer
The Consumer receives the acknowledgement (response) message:
- Transport Layer
- SOAP Message Layer
- Data Layer
Figure 3‑10 Basic Callback Provider Response

The Provider initiates a SOAP request:
- Data Layer
- SOAP Message Layer
- Transport Layer
The Consumer receives the SOAP request:
- Transport Layer
- SOAP Message Layer
- Data Layer
Figure 3‑11 Basic Callback Consumer Acknowledgemen= t

The Consumer then generates the acknowledgement (respo= nse) message:
- Data Layer
- SOAP Message Layer
- Transport Layer
The Provider receives the SOAP acknowledgement (respon= se) message:
- Transport Layer
- SOAP Message Layer
- Data Layer
3.3.4= Flow Constraints

The following activities have the referenced constrain= ts in this Usage Scenario.
- Write XML, as defined in Section 5.1
- Write SOAP envelope, as defined in Section 5.3
- [Write SOAP header (when correlation information is conveyed in a SOAP header)], as defined in Section 5.7
- Write SOAP body, as define in Section 5.5
- Send HTTP, as defined in Section 5.9
- Receive HTTP, as defined in Section 5.10
- Process SOAP envelope, as defined in Section 5.4
- [Process SOAP header (when correlation information is conveyed i= n a SOAP header)], as defined in Section 5.8
- Process SOAP body, as defined in Section 5.6
- Process XML, as defined in Section 5.2
3.3.4= .1    Errors and SOAP Faults

Constraints = for Fault generation and behavior as described in the Synchronous Request / Response Scenario 3.2.3.= 1 also apply to this scenario.

3.3.5      Description Constraints

For the Basic Callback scenario, the WSDL must have at= least the following content within its definitions. Not all sections are required, but if present in the WSDL, each should follow the guidelines as presented below. The WSDL defined below is contained within a single document, and describes both the Initial and the Final request/response sequences of the Basic Callback. Constraints imposed upon the WSDL by the Basic Profile are = also listed.

General constraints on the WSDL are described in Secti= on 5.11. Other constraints imposed upon the WSDL by the B= asic Profile are listed below.

3.3.5.1    types

Application Data

This section will be dependent upon the specifics of t= he data model and often contains correlation information in addition to application data types.

3.3.5.2    messages

Message format will be dependent upon the data model (= doc/literal or rpc/literal). The following messages and parts are typically defined for this Usage Scenario:
- Initial request message
- Initial response message
- 3.3.5.2.1 Docu= ment and RPC style
  Below are some general issues concerning differences b= etween Document and RPC style messages. For simplicity all required messages for t= his scenario have been defined as Document style, but this is not a requirement= .
  
  Document messages
  
  Document message parts are composed from Schema element definitions (see R2204)
  
  <wsdl:message …>
  
      &nb= sp; <wsdl:part name=3D”InitialRequest” element=3D”..”>
  
  </wsdl:message>
  
  RPC messages
  
  RPC message parts are composed from Schema type declar= ations (see R2203)
  
  However, parts to be used in SOAP headers or faults MU= ST be defined as elements
  
  <wsdl:message …>
  
      &nb= sp; <wsdl:part name=3D”InitialRequest“ type=3D”..” />
  
  </wsdl:message>
  
  Constraints on messages are listed in Section = 5.13.
  
  3.3.5.3    portTypes
  
  The request/response transmission primitive must be us= ed for both the Initial and Final sequences.
  
  3.3.5.3.1 Prov= ider
  
  <wsdl:portType name=3D"ProviderPortType">
      &nb= sp; <wsdl:operation name=3D"…">
  
      &nb= sp;         <wsdl:input&#= 8230;
  
      &nb= sp;         </wsdl:input&= gt;
  
      &nb= sp;         <wsdl:output&= #8230;
  
      &nb= sp;         </wsdl:output= >
  
      &nb= sp; </wsdl:operation>
  
  </wsdl:portType>
  
  3.3.5.3.2 Cons= umer
  
  <wsdl:portType name=3D"ConsumerPortType">
      &nb= sp; <wsdl:operation name=3D"…">
  
      &nb= sp;         <wsdl:input&#= 8230;
  
      &nb= sp;         </wsdl:input&= gt;
  
      &nb= sp;         <wsdl:output&= #8230;
  
      &nb= sp;         </wsdl:input&= gt;
  
      &nb= sp; </wsdl:operation>
  
  </wsdl:portType>
  
  Constraints on portTypes are listed in Section 5.14.
  
  3.3.5.4    binding
  
  The wsdl:bin= ding section must use the SOAP binding extension with HTTP transport. The same operation defined in wsdl:portTyp= e must be used in the binding section. Two bindings will be defined, one for = the Initial sequence, one for the Final.
  
  3.3.5.4.1 Prov= ider
  
  <wsdl:binding name=3D"ProviderSoapBinding" type=3D"tns:ProviderPortType">
  
  <soap:binding style=3D"document|rpc" transport=3D"http://schemas.xmlsoap.org/soap/http"/>
  
  <wsdl:operation name=3D"…">
  
      &nb= sp; <soap:operation/>
  
      &nb= sp; <wsdl:input…
  
      &nb= sp; </wsdl:input>
  
      &nb= sp; <wsdl:output…
  
      &nb= sp; </wsdl:output>
  
  </wsdl:operation>
  
  </wsdl:binding>
  
  3.3.5.4.2 Cons= umer
  
  <wsdl:binding name=3D"ConsumerSoapBinding" type=3D"tns:ConsumerPortType">
  
  <soap:binding style=3D"document|rpc" transport=3D"http://schemas.xmlsoap.org/soap/http"/>
  
  <wsdl:operation name=3D"submitFinalReq">
  
      &nb= sp; <soap:operation/>
  
      &nb= sp; <wsdl:input…
  
      &nb= sp; </wsdl:input>
  
      &nb= sp; <wsdl:output…
  
      &nb= sp; </wsdl:output>
  
  </wsdl:operation>
  
  </wsdl:binding>
  
  Constraints on bindings are listed in Section 5.15.
  
  3.3.5.5    port
  
  Only one port will be defined: that for the Initial Request/Response. The Final sequence has an unspecified port-binding. The <= span style=3D'font-family:"Courier New"'>soap:address element must be spe= cified along with the URL for the endpoint:
  
  <wsdl:port>
  
      &nb= sp; <soap:address location=3D”uri” />
  
  </wsdl:port>
  
  Constraints on port definitions are listed in Sec= tion 5.16.
  
  3.3.6=       UDDI
  
  There are two Web service implementations involved in = this Usage Scenario, but only the Initial Web service is advertised in UDDI. The Final Web service is not discoverable because the callback endpoint must be known to and accessible = by the initiator of the Initial request. Communicating the callback endpoint in the initial request accomplis= hes this.
  
  Advertisement of Web services patterned after the Init= ial sequence in this scenario adheres to the “Using WSDL in a UDDI Registry, Version 1.07” Best Practice document. A uddi:tModel representing the Web service type references the containing document for th= e wsdl:binding of the Initial operation. The wsdl:binding corresponding to th= is portion of the Web service type is referenced using an xpointer based fragm= ent identifier appended to the WSDL file URL.&= nbsp; The uddi:bindingTemplate for the Initial sequence captu= res the service endpoint and references the uddi:tModel(s) for the Web service type.
  
  Because the Final sequence in this scenario occurs bet= ween the two parties that participate in the Initial sequence, no advertisement = or discovery of this sequence is desired or necessary.
  
  Advertising Basic Callback Web service= s in this way enables discovery using the inquiry patterns supported by the UDDI Inquiry API set (see http://www.uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf). These include the browse pattern, = the drill-down pattern and the invocation pattern.
  
  General UDDI Constraints are listed in Section 5.17.
  
  3.3.7=       Security
  
  This section identifies the threats most relevant to t= his Usage Scenario as described in Appendix 1 where additional information on B= asic Profile compliant countermeasures may also be found.
  
  Additional constraints may apply if HTTPS is used to implement security. These are Basic Profile requirements: R5000, R5001, R50= 10. Appendix 1 has additional guidelines on Security.
  
  As of this writing no specific threat has been identif= ied as being singularly relevant to this Usage Scenario, though Replay is being investigated as a potential candidate.
  
  4      = Appendix 1 – Security
  
  This section details common Web service threats and su= ggests possible countermeasures that are compliant with the Basic Profile. The countermeasures detailed here are best applied through a risk assessment of your Web service application.
  
  This information presented here is not intended to be = an exhaustive or encyclopedic treatment of the security issues confronting Web services developers. Rather, it is designed to provide an intermediate assessment of security issues that briefly explores the intersection between traditional security issues and their manifestation in the Web services architecture.
  
  4.1     Authentication
  
  = Authentication is a mechanism or a protocol that demonstrates proof of an asserted = identity. Using an authentication mechanism, a Web service can draw conclusions about the send= er of a request or response message, and then act on the message. Many types of authentication mechanisms and protocols have been developed, including pass= word schemes, Secure Sockets Layer (SSL), Kerberos, and public key infrastructur= e. Each mechanism has advantages and limitations. With respect to interoperability, each mechanism introduces a variety of challenges. Web services can usually rely on the software platform to provide interoperable transport authentication. Additionally, Web services may wish to share authentication information across domains to provide single sign-on within a community of cooperating business entities.
  
  Authentication requirements are usually asymmetrical b= etween service requestors and service providers. Therefore, authentication for Web services can be further subdivided as below.
  
  4.1.1=       Request Authentication
  
  Threat
  
  The threats to a Web service= that does not authenticate users include access to data or resources by unauthor= ized entities, and ‘man-in-the-middle attacks’. In man-in-the-middle attacks, an unauthorized entity intercepts messages between requestor and responder, enabling eavesdropping and data manipulation. In very sophisticated Web services environments, a Web service provider may not be able to authentica= te all parties involved in a transaction, and may therefore be required to delegate trust to other Web services.
  
  Since Web services may rely on directory services to f= ind providers of services (such as UDDI), authentication must be ensured in cer= tain processes such as consulting UDDI registries or downloading WSDL files. If authentication is not required by a directory, a relatively easy attack wou= ld be to falsify a WSDL file, causing reliant Web services to bind to improper ports.
  
  Countermeasure
  
  A Web service SHOULD authenticate the sender of a request. Some specific situations in which Web services should authenticate requests incl= ude those in which underlying state is changed, in which there is a charge for using the service, or where the information returned by the service is privileged.
  
  Authentication of the service requester is the appropriate countermeasure. Client authentication can be performed using agreed upon digital certificates in the client authenticati= on piece of an SSL/TLS exchange. The digital certificates exchanged during the= SSL handshake must chain to a certificate authority agreed upon by both client = and server.
  
  4.1.2=       Response Authentication
  
  Threat
  
  An attack on a service reque= ster is one that interposes a false or ‘spoofed” service that supplies responses resembling those provided by the expected service. For example, a “man-in-the-middle” might substitute a false response message f= or a genuine response, leading to request/response mismatches.
  
  Countermeasure
  
  Authentication of the servic= e is the appropriate countermeasure. An SSL/TLS connection can provide server authentication and is typically sufficient protection from Web service prov= ider spoofing for point-to-point transactions.
  
  4.2     Authorization
  
  Authorization is the process of determining the capabi= lities granted to an entity by a service provider or another trusted entity. While authentication determines wh= ich entities can access a Web service, authorization determines which features = of that Web service can be accessed by the authenticated entity. In some cases even authenticated entities must be restricted to a subset of functions pro= vided by a Web service.
  
  4.2.1=       Request Authorization
  
  Threat
  
  Unauthorized access to computational resources or protected data.
  
  Countermeasure
  
  Apply authorization mechanisms. Web services requests are fulfilled based on the authorization assigned to a particular requestor by = the service provider. A Web service m= ay need to communicate its authorization requirements through a policy.
  
  A simple Web service may hav= e one authorization level: i.e., I will execute process X for any user authentica= ted using a recognized token. However, more sophisticated mechanisms may be required for Web services designed to service a range of consumers.
  
  4.3     Confidentiality
  
  Threat
  
  A compromise of privileged information through unauthorized access. In a messaging environment (as opp= osed to a session environment) it is important to evaluate the message protection characteristics of a Web service, because a Web service may not know the ultimate destination or the full route of the data being sent. Intermediari= es may be traversed and if the data is unprotected, might read the confidential contents of a message, or they might be able to deduce confidential informa= tion by the mere fact that a particular message (or a message of a certain type,= or messages in a certain frequency) was sent.
  
  Countermeasure
  
  Encryption is the primary de= fense against a breach of confidentiality. How encryption is applied can vary wid= ely. The SSL/TLS protocol encrypts messages for the duration of the session. . However, at each end-point, the message will be fully decrypted. An excepti= on to this situation is SSL Proxy tunneling. In which a client proxy opens a connection to a secure server, copying data in both directions without intervening in the secure transaction.
  
  There are ways to address the problem of end-to-end co= nfidentiality while remaining compliant, though out of scope, of the Basic Profile. As an example, XML Encryption can be used to selectively encrypt elements or the entire message. There are many configurations, but one is to have the SOAP implementation encrypt the message payload, while leaving other information "in the clear" in the SOAP header.
  
  4.4     Data Integrity
  
  Threat
  
  Loss of data integrity is the unauthorized modification of a request or response. The threat to Web servi= ces is the malicious alteration or the accidental corruption of data.
  
  Countermeasure=
  
  Messages sent using SSL/TLS have guaranteed data integ= rity for the duration of the exchange.
  
  Another technique compliant, yet out of scope, with the Basic Profile is the use of digital signatures and message digests to provi= de proof of data integrity using XML Digital Signature. These can be applied to complete XML messages, or to portions of XML documents according to the XML Digital Signature specification.
  
  4.5     Replay
  
  Threat
  
  A basic attack on a Web serv= ice is an attempt to re-use a once valid message. Certain elements of a Web services message, such as a security token, can also be reused as part of a different message to give the impression of a valid request or response.
  
  Countermeasure
  
  Replay attacks can be addres= sed by using message timestamps and caching, and through the use of universally un= ique identifiers on all messages.
  
  4.6     Logging and Auditing
  
  One of the best countermeasu= res for any of the above security issues is a robust auditing/logging mechanism. In= combination with authentication mechanisms, auditing and logging mechanisms can provide chains of evidence that permit runtime infractions of trust policies to be remedied by the offline trust infrastructure of business agreements and contractual law.
  
  4.7     Other Risks
  
  Like any networked application, Web services are expos= ed to standard network security vulnerabilities such as:
  - Unauthorized users gaining direct access to network resources
  - Virus or Trojan horse programs being transmitted within otherwise valid XML messages
  - Misconfiguration or improper coordination of internal resources by a Web services provi= der.
  - Exploitation of known weaknesses
  - Denial of Service attacks
  5 = Appendix 2 – Constraints
  
  This section provides a mapping of constraints listed = in the Basic Profile to each of the flow activities identified in Section 2 and wi= thin each scenario. In carrying out each activity, the listed constraints should= be consulted in the Basic Profile to check for compliance with the details of = the constraint.
  
  5.1 Write XML
  - XML Representation of SOAP Messages: R4001, R1008, R1009, R1010, R1012, R1= 013
  5.2 Process XML
  - XML Representation of SOAP Messages: R4001, R1008, R1009, R1010, R1012, R1= 013, R1015, R1017
  5.3 Write SOAP Envelope
  - Envelope structure: R1011, R2714
  5.4&= nbsp; Process SOAP Envelope
  - Envelope requirements: R1011, R1015, R1028, R2714
  5.5 Write SOAP Body
  - XML Representation of SOAP Messages: R1005, R1006, R1007, R1011, R1014, R2= 735, R2737
  - The SOAP Processing Model: R1025, R1029, R1030
  - RPC messages: R2729
  5.6 Process SOAP Body
  - XML Representation of SOAP Messages: R1005, R1006, R1007, R1014, R1017, R1= 028, R1029, R1030
  5.7 Write SOAP Header =
  - XML Representation of SOAP Messages: R4001, R1005, R1008, R1009, R1010, R1= 012, R1013,
  - The SOAP Processing Model: R1027
  - Using SOAP in HTTP: R1109
  - Header blocks: R2738, R2739, R2751, R2752, R2753
  5.8 Process SOAP Header
  - XML Representation of SOAP Messages: R1012, R1005, R1008, R1009, R1010, R1= 012, R1013, R1015, R1017,
  - The SOAP Processing Model: R1025, R1026, R1027, R1028, R1029, R1030,
  5.9 Send HTTP
  
  The following constraints apply to both HTTP and HTTPS= .
  - General: R1108, R1140, R1141, R1132
  - Status code: R1106, R1107, R1111, R1112, R1113, R1114, R1115, R1116, R1124, R1125, R1126, R1130
  - SOAPAction Header: R1109, R2713, R2744, R2745
  - Cookies: R1120, R1121, R1122, R1123
  5.10 Receive HTTP
  
  The following constraints apply to both HTTP and HTTPS= .
  - General: R1110, R1140, R2746
  - Status code: R1107, R1111, R1112, R1113, R1114, R1115, R1116, R1124, R1125, R1126, R1130, R1131
  - SOAPAction Header: R1119
  - Cookies: R1120, R1121, R1122, R1123
  5.11 General WSDL Constraints<= /span>
  - Description of an Instance: R0001
  - Importing documents into WSDL: R2001, R2002, R2003, R2004, R2005, R2007, R2008, R2009, R2010, R2011
  - Constraints on the overall structure of WSDL: R2020, R2021, R2022, R2023, R2024, R2025, R2026, R2027, R2028, R4002, R4003, R4004
  - WSDL Extensions: R2747, R2748
  5.12= Constraints on WSDL types
  - Constraint on use of QNames: R2101, R2102
  - Constraint on declaration of array types: R2110, R2111, R2112, R2113
  - Usage of XML Schema: R2105, R2114, R2800, R2801
  5.13= Constraints on WSDL messages
  - Constraints relating to bindings and parts: R2201, R2202, R2203, R2204, R2206, R22= 07, R2208, R2210
  - Constraints on portType: R2209
  5.14= Constraints on WSDL portTypes<= /span>
  - Wire representation of the message: R2301, R2302, R2305, R2306, R2710, R271= 2
  - Constraints on operations: R2303, R2304
  5.15= Constraints on WSDL Bindings
  - Structure: R2029
  - Allowed bindings: R2401, R2700
  - Transport constraints: R2701, R2702
  - Constraints on soap:style: R2705
  - Constraints on soap:use: R2706, R2707
  - Relationship to portTypes: R2709, R2718
  - Using SOAPAction: R2713
  - Using soap:namespace attribute: R2716, R2717, R2726
  - Faults and header constraints: = R2719, R2720, R2721, R2722, R2723, R2740, R2741, R2749
  5.16= Constraints on WSDL Port
  - Allowed bindings: R2711
  5.17= General UDDI constraints
  - Description of an Instance: R0001
  - Constraints on binding templates: R3= 100
  - Constraints on tModels: R3002, R3003, R3005, R3010, R3011
  6&nb= sp; References
  
  [1] WS-I Basic Profile vers= ion 1.0 from www.ws-i.org.

2.3 Security

3&nb= sp; Usage Scenarios

3.1.2 Flow

3.1.3 Flow Constraints

3.1.3.2 SOAP Headers

3.1.4.1 types

3.1.4.2 messages

3.1.4.2.1 Docu= ment messages

3.1.4.2.2 RPC messages

3.1.4.3 portTypes

3.1.4.4 binding

3.1.4= .5 port

3.2 Synchronous Request/Response

3.2.3 Flow Constraints

3.2.3.2 SOAP Headers

3.2.4.1 types

3.2.4.2 messages

3.2.4.2.1 Docu= ment messages

3.2.4.2.2 RPC messages

3.2.4.3 portTypes

3.2.4.4 binding

3.2.4.5 port

3.2.6 Security

3.3 Basic Callback

3.3.2 Details

3.3.5.1 types

3.3.5.2 messages

3.3.5.3 portTypes

3.3.5.3.1 Prov= ider

3.3.5.3.2 Cons= umer

3.3.5.4 binding

3.3.5.4.1 Prov= ider

3.3.5.4.2 Cons= umer

3.3.5.5 port

4.6 Logging and Auditing

5 = Appendix 2 – Constraints

5.7 Write SOAP Header =

5.8 Process SOAP Header

5.11 General WSDL Constraints<= /span>

5.16= Constraints on WSDL Port Allowed bindings: R2711

6&nb= sp; References

5.16= Constraints on WSDL Port

Allowed bindings: R2711