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] Modelling sessions



Hi Jim,

> > In your scenario, I think it is ok to model both the session 
> > and the database as WS-Resources. They are both stateful 
> > resources and can get their own reference.
> 
> I think your answer raises some worrying points about the implied
> resource pattern. Things which are clearly not resources 
> (like sessions)
> have to be reduced to resources to fit in. This is not a natural thing
> to do - there are far better ways of modelling sessions than 
> perverting
> the resource model.

I have no problem with this at all. I wrote that it is ok to use a
WS-Resource to model the session if you want to. My point was that
whether you use a WS-Resource to manage the session or not is irrelevant
to how you send messages to the database WS-Resource. As Greg pointed
out, if you are using WS-Context there already is a service interface
defined to manage the session, so you would probably want to use that
instead of creating a WS-Resource for this purpose. In the rest of my
email I was assuming the session was modeled as a WS-Resource because
this is the use case that Savas submitted and I wanted to explain how to
address messages in this seemingly confusing case.

> I would like to propose that the TC considers the prospect that the
> resource-oriented model is insufficient or inelegant for some cases
> (like sessions), and properly plan for the interplay between stateful
> resources (however much I may object to their explicit 
> naming) and other
> architectural entities.

I agree that WSRF is not the appropriate tool to use in all situations.
But you requirement ("plan for the interplay between stateful resources
(...) and other architectural entities") is a little vague at this
point...

> To simply reduce everying to a resource is unrealistic.

No contest here.

Regards,

William


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