use case? [Re: WS-Addressing patch (ref props support in headers)]

[Aleksander Slominski <as...@cs.indiana.edu>]

SJ wrote:

> specifications
> To give you something more concrete, take a look at the WS-RF suite of
> http://devresource.hp.com/drc/specifications/wsrf/WSRF_overview-1-0.pdf
> I can think of a scenario where a webservice needs to opaquely handle
> the reference properties it receives about state and pass it around, to,
> say another webservice or so. In such cases, all it needs to do is to
> retrieve the ReferencePropertiesType object from the AddressingHeaders 
> that
> the AddressingHandler saves for it in the message context, and add this
> into the AddressingHeaders instance intended for the other webservice.

but those reference properties identifies and are specific only to this 
service (instance) so why would you want to send them to other service? 
instead i would use EPR (that contains set of reference properties) to 
identify other service.

> It
> would work all along with POJOs and the axis handlers that kick in 
> take care
> of automatically serializing and deserializing these ref props into
> SOAP header.

if i understand it correctly WSRF uses EndpointReference similarly to 
remote reference in RMI?

service will have EPRs from  ReplyTo and FaultTo headers so that they 
can be used to send reply/fault. if service needs to contact other 
service then it will have and use EPR for other service to put endpoint 
references as headers into outgoing message?

therefore it looks to me like there never a need to echo reference 
properties?! what are cases when it is needed - why would service send a 
message back to *itself*?

thanks,

alek

-- 
The best way to predict the future is to invent it - Alan Kay

Re: use case? [Re: WS-Addressing patch (ref props support in headers)]

[SJ <os...@yahoo.com>]

My replies interspersed ...

Aleksander Slominski <as...@cs.indiana.edu> wrote:

>but those reference properties identifies and are specific only to this service 

> (instance) so why would you want to send them to other service? instead i 

> would use EPR (that contains set of reference properties) to identify other 

> service.

The handler will be installed in front of the service (typically in its requestFlow path. Need not be a global handler (common to all services). This is not a question about EPRs - it is about parsing reference properties - rather who parses this - the service code itself or the handler. Actually I could rephrase your question as - if webservices need to support ws-addressing headers, why would you have to code the SOAP header manipulations in every webservice - why not code it in a handler (like the AddressingHandler), and any webservice that wants to parse these props could just install the handler in front of it (and achieve some reuse).

.

> service will have EPRs from  ReplyTo and FaultTo headers so that they can 

> be used to send reply/fault. if service needs to contact other service then it 

> will have and use EPR for other service to put endpoint references as headers 

> into outgoing message?

 

Yes, it will need to create a new EPR. The point is how will it throw in these EPRs - without this support, the webservice will have to parse SOAP headers, extract ref props from it, put them (or different ones) into another EPR and so on. With the support for reference prop manipulations in the handler, the webservice can achieve most of this using plain old java objects instead of having to deal with low level SOAP header manipulations. 

> therefore it looks to me like there never a need to echo reference properties?! 

> what are cases when it is needed - why would service send a message back 

> to itself? 

I think you did not get the point of my example. I was not talking about echoing reference properties. I was talking more about passing them around. The reason I used WS-RF as an example was because these specifications use the notion of passing around reference properties. In WS-RF, the EPR contains the address of a webservice and some refprops describing the state that it interacts with. Now if you can take the ref props out of this EPR and pass them around, you are in effect passing around a reference to the state.Maybe you got this confused with echoing back reference properties. There are many reasons why you might want to pass around reference props. For example you could use it like a cookie. For example - a webservice could expect a client to pass its state references encoded as ref props along with every request. Now the client itself might get this state through headers of some message that was directed at it. This client might need to treat these ref props opaquely (i.e
 just pass them around without interpreting it). All I am trying to say is that in such cases, a higher level abstraction (using plain old java objects) might be more convienient than having to handle SOAP headers directly.


Regards,

Shiva




---------------------------------
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today