[ogsa-bes-wg] Attempted distillation of "Questions and potential changes to BES, as seen from HPC Profile point-of-view"

[Marvin Theimer]

Hi;

 

I still don't understand what you're getting at here. I don't see this
as the two interfaces are mutually exclusive. I just don't see any point
of having identical operations for both the BES/activity factory service
and the activity service. If the factory and activity service were the
same, then fine. If they are two distinct services then tailor the
interfaces. You mentioned "keeping them in sync". I still don't
understand your concern here. What is it that frightens you about the
BES group being able to keep the two (which are intimately related) in
sync?

 

I'm just trying to advocate good software engineering principles here: I
would prefer to avoid having to keep two interfaces in sync with each
other across two different specifications.  It's not a big deal and I'm
religious about it.  I believe that in a later email you suggest that
both interfaces be kept in the same spec.  That seems like a good idea
unless another compelling reason should pop up that argues for keeping
them separate.

 

 

I would rather see a generic property getter method instead that takes
an array of EPRs. This would model better w.r.t. WSRF's
getResourceProperty, etc... methods and avoid the precedent of providing
individual operations for each property.

 

 The challenge here is the schism between the WSRF and the WS-Transfer
camps.  Although that schism is now slated to be healed by the new
reconciliation effort that IBM, Microsoft, et al. announced recently,
that reconciliation won't be finalized for another year or two.  Recall
also that, although I'm proposing that the base case BES interface just
deal with individual activities, one of the extensions that I expect
will get added very quickly is an array interface for dealing with
multiple activities in a single interaction.  For the latter interface,
it does not make sense to query the factory service's resource
properties (in the WSRF-oriented world) or its EPR (in the
WS-Transfer-oriented world) since the query is about the state of a
bunch of activities, not the factory.  Since I'd like to have the
interface for dealing with arrays of activities and for dealing with
individual activities look as similar as possible - and given that the
reconciliation of WSRF and WS-Transfer has not yet been completed - I've
introduced named operations for the type of state I wish to see
returned.

 

Now, you could argue that what I've done is expose a single "property" -
the activityState property - and a means of retrieving all "properties"
in something akin to WS-Transfer style.  Based on that, you could argue
that we should expose query operations for "all" the individual
"properties" of an activity.  Since that set is not completely defined
and since we will also (at least eventually) want to support extended
sets of "properties" and since there is not a reconciliation-approved
way of exporting which "properties" an activity exports, I advocate that
the base case of BES should aim to export a "minimal" query interface.
To me, that's a way to get everything (including any extensions) and a
way of getting the one common state element that we know everyone always
wants to query - namely the activityState element.  Please note that I
have no problem with adding in additional query operations in
extensions, but I would argue that the BES base case should be kept as
simple as possible.  (Along those lines, one might argue that we should
jettison the GetActivity operation that returns just the activity's
state diagram state.  However, retrieving all the state that describes
an activity just to get the activityState seems excessive to me,
especially when thinking about how that would behave when dealing with
large arrays of activities.)

 

 

It worries me that this is a non-WSRF-only operation. We should try very
hard to avoid branching the spec for two different resource models. If
we can't avoid it then there needs to be two separate specs IMHO. What
do the WSRF services do with this?

 

We may have to have two separate specs, if people feel they need a
WSRF-based version of the spec.  Personally, I'd prefer a single spec
that uses neither WSRF nor WS-Transfer and thereby circumvented the
problem - but that's my personal opinion.  The interface I've proposed
essentially tries to circumvent the issue by employing named query and
modification operations.

 

 

I don't really understand what you're trying to accomplish here. You say
it's a non-WSRF operation and yet this description says it's an
aggregation of the WSRF RPs. Then you add that it might return other
stuff as well. This seems like a "give me the serialized resource
object" operation. My feeling is that if the necessary information were
exposed correctly you wouldn't need this operation.

 

This again comes down to the WSRF/WS-Transfer schism.  I come from the
WS-Transfer side of the world and so think of returning state as a
single infoset.  I'm trying to couch my descriptions in a manner that
allows bridging to how a WSRF-oriented person would think about things.

 

 

Marvin.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060614/e75f032d/attachment.html