wsrf message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrf] an attemt to simplify, clarify and combine into one WSDL binding
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrf@lists.oasis-open.org
- Date: Mon, 22 Nov 2004 09:13:50 -0500
While I have not dug through this post
in detail, I question the basis that is laid out in the first paragraph.
This contains two significant restrictions on the use of WSDL 1.1 for which
I fail to see WSRF-specific reasons:
1. Restrict the WSDL to containing a
single service element. While the vast majority of WSDLs I have seen only
use a single service element, why does WSRF need to restrict those deploying
services in this manner?
2. Restrict the ports of a service element
to all resolve to the same portType. While this is a common pattern for
WSDL1.1 services and is the pattern chosen by WSDL 2.0, another common
pattern is to use the service element to group the portTypes implemented
by the component being exposed as a service. Is there a reason services
using this latter pattern should be excluded from leveraging WSRF?
In summary, while both of these could be useful restrictions, I think WSRF
is the wrong place to be imposing them unless there are strong WSRF-specific
reasons for the restrictions.
Rich
"Sedukhin, Igor S"
<Igor.Sedukhin@ca.com>
11/17/2004 04:17 PM
|
To
| <wsrf@lists.oasis-open.org>
|
cc
|
|
Subject
| [wsrf] an attemt to simplify,
clarify and combine into one WSDL binding |
|
3.3 WSDL
1.1 Embodiment
This embodiment is one in which WSDL 1.1
is used [WSDL11]. The form of a WS-Resource reference is a WSDL definitions
element which contains exactly one WSDL service child element which, in
turn, contains one or more WSDL port child elements each bound to the same
portType element.
Rules of WSDL 1.1 [WSDL11] and any extensions
thereof which appear in the reference MUST be followed in order to properly
form messages containing resource identifiers and target them at the WS-Resource.
For example, policy attached to the WSDL
definitions may indicate that X.509 certificate must appear in the WS-Security
header. The certificate must be obtained by the requestor from the execution
context or otherwise. Terefore, messages targeted at the WS-Resource will
contain headers with required certificates which may be used as the resource
identifiers by an implementation to distingish the resource targeted by
the message.
Note that a form of a reference to a WS-Resource
in this embodiment of WS-RAP does not necessarily contain a value of the
resource identifier, however it 1) identifies what the resource identifier
is (e.g. the fact that it is an X.509 certificate in the requestor’s context),
and 2) specifies where in the message the value of the resource identifier
has to appear (e.g. a <soap:header> WSDL SOAP binding extension element).
The actual value of the resource identifier depends on the application
specifics and the context in which the requestor runs. Therefore, it is
possible to have one WS-Resource reference which when interpreted in each
requestor/caller context will result in messages targeted to different
resources. This is an application-context dependant form of a reference.
See example in $3.3.1.
A simpler case of this embodiment which does
specify the value of the resource identifier is the one where the resource
identifier value is encoded in the contents of a WSDL port element of the
WS-Resource reference. In case of SOAP binding, within the soap:address
element. In this case, the address encoded within the WSDL port element
contains both the address of the Web service endpoint and the resource
identifier. See example in $3.3.2.
3.3.1 Header element example
The following is an example of a valid reference
to a WS-Resource in this embodiment:
<wsdl:definitions … xmlns:tns=”…”
xmlns:my=”…”>
<wsdl:message name=”custom”>
<wsdl:part name=”hdr”
element=”my:ResourceIdentifier”/>
</wsdl:message>
<wsdl:binding name=”SOAP”
… >
<wsdl:operation
… >
<wsdl:input>
<soap:header
message=”tns:custom” part=”hdr” use=”literal”/>
<soap:body
… > … </soap:body>
</wsdl:input>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name=”svc”>
<wsdl:port name=”SOAPHTTP”
binding=”tns:SOAP”>
<soap:address=”http://my.server.org/soap/http/listener”/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
In this example, the requestor would need
to understand how to form the contents of the my:ResourceIdentifier
element before sending a SOAP message to the http://my.server.org/soap/http/listener
address. The QName of this header element identifies the application semantics
of the element. For example, semantics could be that the elemeent must
contin a value of a primary key into a specific database table. Precisely
how to form the contents of the header element is dictated by its application
semantics, and it has to be known and implemented by the requestor. This
specification does not make any assumptions as to what such application
semantics could be. However, applications that understand the semantics
of my:ResourceIdentifier element will be able to use this reference sucessfully.
3.3.2 Address example
The following is an example of a valid reference
to a WS-Resource in this embodiment:
<wsdl:definitions … >
<wsdl:service name=”svc”>
<wsdl:port … >
<soap:address=”http://www.example.com/R1”/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
In this example, messages sent to http://www.example.com/R1
are, actually, sent to the endpoint of the Web service which provides
access to the resource in this example identified by the string “R1”.
Note that even though resource identifier does not appear within the SOAP
envelope contained in messages sent when using this reference, it MUST
appear in as part of the HTTP message (in the form of the URL).
-- Igor
Sedukhin ..
(igor.sedukhin@ca.com)
-- (631)
342-4325 ..
1 CA Plaza, Islandia, NY
11749
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]