OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsrf] Groups - wsrf-ws_resource-1.2-spec-wd-08.doc uploaded (fwd)

Mark et al,

Another posting from Mark. I will answer in line at the same time as  

First wrt your earlier mail, a lot of the issues surrounding the notion  
of what a resource is have been addressed in the recent drafts. What a  
resource actually can be is much the same as the W3C model. However,  
all the semantic around WSRF focus on the WS-Resource and the  
associated MEPs. Have a look during our final Public review (starting  
this afternoon hopefully).

On 15 Sep 2005, at 20:51, Mark McKeown wrote:

> Hi Dave,
> Afraid I bounced again - I have got e-mails saying
> I am part of the TC!
> If my input starts to be a hindrence rather than a help
> let me know and I will stop - I cannot tell from the
> postings on the list if the TC wants to move on...
> cheers
> Mark
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mark Mc Keown                            RSS
> Mark.McKeown@man.ac.uk 	                 Manchester Computing
> +44 161 275 0601     		         University of Manchester
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ---------- Forwarded message ----------
> Date: Thu, 15 Sep 2005 20:45:22 +0100 (BST)
> From: Mark McKeown <zzalsmm3@nessie.mcc.ac.uk>
> To: "Wilson, Kirk D" <Kirk.Wilson@ca.com>
> Cc: ian_robinson@uk.ibm.com, wsrf@lists.oasis-open.org
> Subject: RE: [wsrf] Groups - wsrf-ws_resource-1.2-spec-wd-08.doc  
> uploaded
> +1 to the comments by Kirk, they were things that confused me
> on reading wd 08.
> I have some futher comments to add regarding the use of the
> EPR in the example included in wsrf-ws_resource-1.2-spec-wd-08.doc:
> <wsa:EndpointReference>
>     <wsa:Address>
>         http://www.example.com/service
>     </wsa:Address>
>     <wsa:ReferenceParameters>
>         <tns:SomeDisambiguatorElement>R1</tns:SomeDisambiguatorElement>
>     </wsa:ReferenceParameters> ?
>     .
> </wsa:EndpointReference>
> Given this EPR the client does not know weither the
> SomeDisambiguatorElement element is being used to
> identify him, ie the client, or being used to map
> messages to state by the service provider.
> (ReferenceParameters are supposed to be opaque - so
> he shouldn't be looking anyway)

The example is just for guidance. The EPR is opaque. We even discussed  
something like:

>     <wsa:ReferenceParameters>
>         <tns:ghfhrd>ggdtsr53674534</tns:ghfhrd>
>     </wsa:ReferenceParameters> ?

But it didn't seem to make things any clearer.

> From my understanding of ReferenceParameters they
> are similar to HTTP cookies ie. they are used to
> support stateful interactions.
> So a client who is given a EPR that contains
> ReferenceParameters should not share the EPR as
> the ReferenceParameters may be client specific,
> ie they might be used by the service provider
> to identify which client sent the message.
> So EPRs with ReferenceParameters should not be put
> into public or shared ServiceGroups/registries, just
> as bad things can happen if you share your cookies.

I don't see a problem here. If as a client I have put an RP in the EPR,  
this one is not opaque and I can remove it before storing it in a  
registry. RP's have many functions, some opaque and not.

> I think this is why the W3C think that cookies
> should not be used to identify resources as it reduces
> the visibility of the system.

This is one of the advances that WS-Addressing adds. At present many  
URI/HTTP based systems use cookies to identify the resource at the end  
of an http request, i.e. bunches of identification data not in the URI  
- so much for the pure URI model. The WS-A EPR actually helps this  
problem by providing a standard wrapper for all this stuff.

> Am I mistaken. Should the WSRF TC recommend that WS-Resource
> implementors not use ReferenceParameters to map messages
> to particular state?

I think this is an implementation choice. I know of several  
implementations that don't use the RPs - others that do.

> (I believe this is an issue that Hugo Haas raised in
> the WS-Addressing WG -
> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0051)
> Is the use of EPRs as references to WS-Resources mandatory -
> ie. should the word MUST be used. (Currently only a SOAP binding
> has been defined for WS-Addressing - ie HTTP and Plain Old XML
> cannot be used to implement WSRF using EPRs)

This is an interoperability issue. Eventually there will be other WS-A  

> cheers
> Mark
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mark Mc Keown                            RSS
> Mark.McKeown@man.ac.uk 	                 Manchester Computing
> +44 161 275 0601     		         University of Manchester
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> On Thu, 15 Sep 2005, Wilson, Kirk D wrote:
>> As someone said earlier, this is a "black hole".  I apologize, the
>> conversation on this doc went a little too fast and was not all that
>> audible for me to jomp in on the telephone.  I was thinking about the
>> text and you had moved onto the BaseFaults discussion.
>> Two things:
>> 1.  The third bullet says:  "If access to the lifecycle of the  
>> resource
>> is exposed through the WS-Resource, ..."  I thought there was a
>> clarification given earlier in the day that the lifecycle of the
>> resource is NOT that which is exposed through WS-RL--just the  
>> lifecycle
>> (Destroy) of the WS-Resource.  We really can't infer anything about  
>> the
>> lifecycle of the resource.  This statement should be rephrased to be
>> consistent with the clarification.
>> 2.  I find the diagram in 2.2.1 confusing because it is incomplete.   
>> It
>> shows a single Web service and two resources.  However, it doesn't  
>> have
>> any representation of the "WS-Resource" associated with the Web  
>> service
>> and the resource identified by R1.  Is the Ws-Resource in 1:1
>> association with the Web Service and 1:m with the resources?  Or is  
>> the
>> Web service in 1:m association with WS-Resources, each of which has a
>> 1:1 association with the resources?  (I believe the answer is the  
>> later,
>> but neither the diagram nor the text makes these associations clear.
>> Note, as well, that the text says "The Web service provides access to
>> two resources..."  That's the role of the WS-Resource, which, IMHO,
>> further confuses the discussion.
>> Sorry for the delay in getting you these comments.
>> Kirk Wilson
>> Architect, Development
>> Office of the CTO
>> 802 765-4337
>> -----Original Message-----
>> From: ian_robinson@uk.ibm.com [mailto:ian_robinson@uk.ibm.com]
>> Sent: Thursday, September 15, 2005 11:39 AM
>> To: wsrf@lists.oasis-open.org
>> Subject: [wsrf] Groups - wsrf-ws_resource-1.2-spec-wd-08.doc uploaded
>> The document named wsrf-ws_resource-1.2-spec-wd-08.doc has been
>> submitted
>> by Dr Ian Robinson to the OASIS Web Services Resource Framework (WSRF)
>> TC
>> document repository.
>> Document Description:
>> WS-Resource spec - wd-08
>> View Document Details:
>> http://www.oasis-open.org/apps/org/workgroup/wsrf/document.php? 
>> document_
>> id=14466
>> Download Document:
>> http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/14466/ 
>> wsr
>> f-ws_resource-1.2-spec-wd-08.doc
>> PLEASE NOTE:  If the above links do not work for you, your email
>> application
>> may be breaking the link into two pieces.  You may be able to copy and
>> paste
>> the entire link address into the address field of your web browser.
>> -OASIS Open Administration

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE

     +44-208-606-4649 (Office)
     +44-208-606-4539 (Fax)
     +44-7768-807526  (Mobile)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]