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: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
- To: "Rich Thompson" <richt2@us.ibm.com>,<wsrf@lists.oasis-open.org>
- Date: Mon, 22 Nov 2004 14:05:27 -0500
I have no problem indicating what you are asking for in
this embodiment. This is a fairly minor fix. I'd wait for more comments on my
proposal to see where this is going.
-- Igor
Sedukhin
..
(igor.sedukhin@ca.com)
-- (631)
342-4325
..
1 CA Plaza, Islandia, NY 11749
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]