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


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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

Subject: RE: [ogsi-wg] RE: [ws-caf] WS-Resource Framework

Hey Jeff.

Aren't both ways of doing message correlation? What the service does
with regards to the message correlation is up to the service. If the
message decides that the correlated messages will refer to a particular
resource, that's up to the message. That begs the question why come up
with yet another way of doing message correlation, especially when the
WS-Context approach is scalable to multiple participants.

Savas Parastatidis
http://savas.parastatidis.name (now blogging)

> -----Original Message-----
> From: owner-ogsi-wg@gridforum.org [mailto:owner-ogsi-wg@gridforum.org]
> Behalf Of Jeffrey Frey
> Sent: Friday, January 23, 2004 6:11 PM
> To: Ian Foster
> Cc: Newcomer, Eric; ogsi-wg@gridforum.org;
> Savas Parastatidis; ws-caf@lists.oasis-open.org
> Subject: Re: [ogsi-wg] RE: [ws-caf] WS-Resource Framework
> I agree with Ian. There is a subtle but important distinction.
Context, as
> referred to in WS-Context, is explicitly declared and meant to
> an interoperable understanding between the client and the service. For
> example, a transactional unit of work is something that can be
> by the client and sent to the service in a well known context that
> accompanies the message to the web service. The same is true for
> that represent security function, etc. This is not the same as what we
> have
> introduced with the WS-Resource. There is no need to declare the
> WS-Resource context for interoperability reasons. The WS-Resource
> "context"
> is not produced by the client. It is produced and consumed by the
> It is carried in the EPR as an opaque construct to the client. There
is no
> need for the client to interpret or inspect the contents of the
> properties. In fact, there is no additional "context" handler required
> all on the client side of the interaction other than what is already
> generically specified in the WS-Addressing specification. So, while I
> understand that this appears to be the same at an abstract level of
> understanding, we did not intend the identity of the resource as it is
> treated in the EPR to be interpreted as "context" in the same way
> usage context is produced and consumed across the web service
> with the client.
> In addition, while we know some have an aversion to the treatment of
> stateful resource as a "first class" addressable entity or as the
> target of the interaction from the client., some do not. And if your
> is that the resource is the "target" of the message interchange from
> client the service, our view is that it should be treated as distinct
> other execution contexts which exist not for the purpose of
> the
> target of the message exchange, but to provide additional control over
> the target of the message exchange is to be treated. WS-Context should
> used to facilitate the contextual usage of the target of the message,
> the target of the message itself.
> Jeffrey Frey

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