Hi;
This topic got discussed at today’s BES conference call and the
reasoning for having a GetAttributesDocument operation in the core BES
interface was re-derived from the previous time(s) that the topic was
discussed. The argument goes like this:
·
Clients will want to retrieve some
or all of the attributes that a BES exposes. If GetAttributesDocument is in
a separate “rendering” port type that composes with the BES-Factory
and BES-Management port types then clients will need to determine which
rendering port type is actually available from any given BES.
·
In order to determine which
renderings a BES implements you have to query it. That requires that
there be some operation in the core client BES interface (i.e. BES-Factory) that
will retrieve the attribute that describes which renderings are available by
some means or another. (I can’t actually find an attribute in the
spec that exports that information, by-the-way.)
·
If that operation just returns the
attribute that describes which renderings are available then the normal case
behavior for a client querying multiple BESes in order to see what state they
are in (e.g. to decide which is most lightly loaded) will involve two message
round trips: one to retrieve the rendering information and one to then retrieve
the desired attributes. That seems like a bad design from a software and systems
engineering point-of-view. One might argue that clients will be written
to amortize the cost of the rendering query over multiple attribute retrievals,
but that presumes a fairly heavy-weight client model that may not be
appropriate in all cases. Note also that BES service implementers will be
implementing a retrieval operation of some sort that is rendering-independent
in any case. So from an implementation complexity point-of-view, they
have to pay the development cost of implementing some sort of retrieval
operation in the BES-Factory port type in any case.
·
The only way to make this common
case into a single message exchange is to have a single rendering that is
universally implemented. Tom Maguire has pointed out that WS-ResourceTransfer
has now been published and could be considered a candidate for such a universal
rendering interface. But using this rendering interface implies that BES implementers
must implement ALL of that interface in order to be able to employ its Get
operation. Furthermore, they must do so in a manner that complies with
the standard and its compliance requirements and tests (have those been
published yet?). So, in order to get a simple Get operation, a BES
implementer must also implement Put and Create operations, whose semantics are
potentially controversial (I haven’t read the new spec to see how they
deal with atomicity questions of creating/updating multiple properties) and, in
general, a spec that is 30 pages long – 46 pages if you count the
appendices. That’s arguably substantially more work than simply
implementing a single GetAttributesDocument operation that is unencumbered by
any other spec’s requirements.
·
So, in order to enable BES clients
to efficiently (i.e. using only a single message exchange) retrieve all the
attributes of a BES without having to require BES service implementers to
implement a non-trivially sized second spec, most of which is not necessary for
BES, it was decided to include a GetAttributesDocument operation in the
BES-Factory port type.
·
Inclusion of this operation makes
the BES specification inherently resource model-free, but it does not preclude
a BES from redundantly exporting its attribute information by means of other
(composed) rendering port types, such as WSRF, WS-Transfer, or
WS-ResourceTransfer as well. This would allow clients that wish to
exploit the reuse possibilities of such renderings to do so while imposing only
a very minor additional service implementation burden for BES implementers –
namely to implement the GetAttributesDocument operation instead of a
GetRenderingAttribute operation.
Marvin.
-----Original Message-----
From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On
Behalf Of Peter G. Lane
Sent: Wednesday, September 06, 2006 10:51 AM
To: Mail list for ogsa-bes-wg working group
Cc: ogsa-bes-wg@ggf.org
Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Christopher Smith wrote:
> Characterizing this issue as WS-RF vs WS-Transfer is misleading. I
can't
> recall any discussions within this group where anybody advocated
doing a
> WS-Transfer rendering for the BES interface. Well ... other than
the WS-RF
> proponents who wrongly assumed that because some (like myself)
were against
> the use of WS-RF, that must mean we were in favour of WS-Transfer.
I also
> don't recall anybody advocating operations for modification, etc
such as
> defined within WS-Transfer. To me this is a discussion of a
resource
> modelling approach (built on WS-RF) vs a non resource modelling
approach.
Just for the record, I wasn't trying to make this into a fairness issue
between WSRF and WS-Transfer
just because WSRF isn't being equally represented and I'm from the WSRF
camp. If some WSRF-like
operation was included I would have asked the same question. I also did
bring this up before the
tracker existed, but nobody seemed interested in discussing it then.
That said, whether a discussion
was had or not, having this operation makes WS-Transfer partly
redundant. That's my main point in
all of this. It seemed silly to have two operations doing the exact
same thing when minimal interop
IMHO doesn't warrant it. In other words, it was a cosmetic gripe.
>
> My main reason for not wanting to make use of one of the resource
modelling
> approaches has to do with the burden of implementation. If
Platform buys
> into one of these resource models, we no longer have to implement
one simple
> spec and test compliance of that specification, but we need to
implement and
> test compliance on a suite of specifications, for (in my opinion)
no extra
> benefit. You might say that once you've implemented a resource
modelling
> suite of specifications, you can use it over and over and thus
amortize the
> cost of this implementation. But even at a small cost, it's not
one that I'm
> willing to take, as the implementation of standards specifications
is one
> feature in a sea of features that we implement from product
release to
> product release.
Fair enough. Out of curiosity, though, if WSRF and WS-Transfer get
reconciled, does this mean
Platform will still opt not to implement a second spec? If on the other
hand they would be willing
to implement such a spec, would they be ok with deprecating the GetAttributesDocument
operation at
that time?
Peter
>
> -- Chris
>
>
>
> On 06/9/06 07:56, "
>
>> If it's about fear of reopening the dialog, then I'd
appreciate if someone
>> could at least add
>> comments to the two trackers addressing the issues raised.
>>
>> Ian can push for reopening this particular issue if he wants;
but I just want
>> to know why we're
>> advocating WS-Transfer in spirit if not in name, and why
aggregation of
>> resource attributes is not a
>> concern to anyone else. As long as someone has a reason for
these issues that
>> I raised in the
>> tracker, I'm fine. I don't expect to get everything to go my
way, and I'm open
>> to being convinced of
>> alternate points of view. I just don't like being ignorant,
especially when
>> I'll have to implement
>> the spec someday.
>>
>> On the other hand, if nobody has a good answer for the issues,
I think Ian is
>> perfectly valid in
>> asking for it to be reopened as apparently the issues weren't
actually
>> addressed as they should have
>> been.
>>
>> Peter
>>
>> Mark Morgan wrote:
>>> Well, I guess the thing that confuses me is whether or not
it is SOP to
>>> re-open an issue that was discussed previously because a
new person has
>>> re-raised that issue. I'll bow to whatever the
majority thinks is best of
>>> course, but it seems to me that you can't reopen an issue
everytime a new
>>> person re-raises it or you risk the possibility of
continuously cycling on
>>> it. New information should always be considered, but
if an issue gets
>>> re-raised that has already been discussed fully and voted
on, then it
>>> doesn't make sense to re-discuss it. Just my 2 cents
worth...
>>>
>>> -Mark
>>>
>>>> -----Original Message-----
>>>> From: ogsa-bes-wg-bounces@ogf.org
>>>> [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian
Foster
>>>> Sent: Tuesday, September 05, 2006 9:39 PM
>>>> To: Mail list for ogsa-bes-wg working group; 'Mail
list for
>>>> ogsa-bes-wg working group'; ogsa-bes-wg@ggf.org
>>>> Subject: Re: [OGSA-BES-WG] Tracker Resolution
Descriptions
>>>>
>>>> Mark:
>>>>
>>>> I guess that I am asking that we re-open the issue,
then.
>>>>
>>>> Ian.
>>>>
>>>> At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
>>>>
>>>>
>>>> I'm not sure what level of "addressing" is
meant here, but my
>>>> recollection/belief was that it was addressed in the
>>>> group in so much as the
>>>> topic was discussed at the last face-to-face and that
>>>> the appearance of the
>>>> GetAttributesDocument was the result of that
>>>> discussion. We haven't as a
>>>> group discussed the email that Peter sent out yet but
>>>> it is my belief that
>>>> doing so is essentially a rehash of discussions
previously had.
>>>>
>>>> -Mark
>>>>
>>>>> -----Original Message-----
>>>>> From: ogsa-bes-wg-bounces@ogf.org
>>>>> [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of
Ian Foster
>>>>> Sent: Tuesday, September 05, 2006 1:42 PM
>>>>> To: Mail list for ogsa-bes-wg working group;
>>>> ogsa-bes-wg@ggf.org
>>>>> Subject: Re: [OGSA-BES-WG] Tracker Resolution
Descriptions
>>>>>
>>>>> Has Peter's comment been discussed?
>>>>>
>>>>> He advocates (I believe) that we should not
include the
>>>>> GetAttributesDocument operation. Instead, any
particular BES
>>>>> should choose (if they wish) to provide access to
attributes
>>>>> via an appropriate resource model-specific
operations.
>>>>>
>>>>> * A WS-Transfer-based BES would use GET
>>>>> * A WSRF-based BES would use WS-ResourceProperties
>>>>> * A resource-model-free BES might define a
>>>>> GetAttributesDocument operation
>>>>> * etc.
>>>>>
>>>>> This seems a good proposal to me.
>>>>>
>>>>> Ian.
>>>>>
>>>>> At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
>>>>>
>>>>>
>>>>> 2) Why are we
still essentially advocating
>>>>> WS-Transfer's attribute model by having the
>>>>> GetAttributesDocument operation? In my opinion it
is not
>>>>> necessary for minimal interop, and makes
WS-Transfer's Get
>>>>> operation redundant. Is part of the problem that
we haven't
>>>>> defined any interop standards yet?
>>>>>
>>>>>
>>>>
_______________________________________________________________
>>>>> Ian Foster -- Weblog: http://ianfoster.typepad.com
>>>> <http://ianfoster.typepad.com/>
>>>>> <http://ianfoster.typepad.com/> Computation
Institute:
>>>>> www.ci.uchicago.edu
<http://www.ci.uchicago.edu/>
>>>> <http://www.ci.uchicago.edu/> &
>>>>> www.ci.anl.gov <http://www.ci.anl.gov/>
>>>> <http://www.ci.anl.gov/>
>>>>>
>>>>>
>>>>> Tel: +1 630 252 4619 --- Globus
>>>> www.globus.org <http://www.globus.org/>
>>>>> <http://www.globus.org/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> ogsa-bes-wg mailing list
>>>> ogsa-bes-wg@ogf.org
>>>> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
>>>>
>>>>
_______________________________________________________________
>>>> Ian Foster -- Weblog: http://ianfoster.typepad.com
>>>> <http://ianfoster.typepad.com/> Computation
Institute:
>>>> www.ci.uchicago.edu
<http://www.ci.uchicago.edu/> &
>>>> www.ci.anl.gov <http://www.ci.anl.gov/>
>>>>
>>>>
>>>> Tel: +1 630 252 4619 --- Globus Alliance:
www.globus.org
>>>> <http://www.globus.org/>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> ogsa-bes-wg mailing list
>>> ogsa-bes-wg@ogf.org
>>>
http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
>>>
>> --
>> ogsa-bes-wg mailing list
>> ogsa-bes-wg@ogf.org
>> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
>
> --
> ogsa-bes-wg mailing list
> ogsa-bes-wg@ogf.org
> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
>