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 13:29:58 -0500
If the WS-RAP has such a conformance
statement, it would be good for the embodiment to note the issue for WSDL
1.1 users. Even at a conformance testing level, it would be quite straight
forward to require that only one portType containing wsrf-rp or wsrf-rl
operations be exposed. If people feel a specific conformance statement
is required, it should be at this level rather than at the composition
model level.
Rich
"Sedukhin, Igor S"
<Igor.Sedukhin@ca.com>
11/22/2004 01:08 PM
|
To
| Rich Thompson/Watson/IBM@IBMUS,
<wsrf@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrf] an attemt to simplify,
clarify and combine into one WSDL binding |
|
Great! I had the same concern,
however this restriction was imposed in order to comply with the WS-RAP
constrainments of a representation of a reference referring to only one
WS-Resource.
If we remove this constrainment
then one instance of a WSDL document may in principle refer to many WS-Resources.
And I would have no problem with that.
I also believe that WSRF is the
wrong place to impose this.
-- Igor
Sedukhin ..
(igor.sedukhin@ca.com)
-- (631)
342-4325 ..
1 CA Plaza, Islandia, NY
11749
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Monday, November 22, 2004 9:14 AM
To: wsrf@lists.oasis-open.org
Subject: Re: [wsrf] an attemt to simplify, clarify and combine into
one WSDL binding
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]