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

[Peter G Lane]

On Wed, 2006-06-14 at 13:25 -0700, Marvin Theimer wrote:
> 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.

Ok, I'll consider this reconciled, then. ;-)

> 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.

I have to admit that I had to read up on WS-Transfer. It makes more
sense where you're coming from now. It's a very different philosophy of
how resource state should be managed. Considering this I think we should
still make this activity description a resource state property/element
and leave it ambiguous as to how it is accessed. Unfortunately if we
don't define the Activity interface we can't define the state item.

> 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.)

And here is where I have the biggest problem with WS-Transfer. I think
an activity's progress state should be a property that is modeled as
desired (i.e. either WS-Transfer or WSRF) as long as there are multiple,
popular ways to do so; but as you say, getting the entire state for one
item is excessive. That's my personal opinion in general after reading
about WS-Transfer. I don't think we should be sacrificing good design
just because some implementation detail (I consider this implementation
because it's left ambiguous in the spec) doesn't play nice. If you don't
like it, don't use WS-Transfer in your implementation.

Now then, there is a potentially serious problem here in that if the
public state model is not standardized in the spec then how do you know
what WS interface to use to manipulate it? In that case I would say we
need an operation that specifically targets interop data (kind of like
the FTP "FEAT" command). This is yet another reason in support of
defining the activity interface. Each activity ought to be exposing via
such a method what kind of public state model it uses.

> 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.

To summarize what is essentially a counter proposal, I think we need
to...

1) Expose public state as it was intended to be exposed (i.e. in state
properties/elements within the state document)
2) Leave the public state model ambiguous
3) Define the Activity interface
4) Include an interop data fetch operation, say "GetInteropData", on
both the BES interface and the Activity interface. The returned data
should be well defined but extensible, and include what type of public
state model is being used.

> 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.

And again I think that if it's burdensome to fetch the entire infoset
just for one datum then you shouldn't be using WS-Transfer. It's not the
BES-WG's fault that WS-Transfer isn't flexible enough. We shouldn't be
making concessions to broken implementations. I apologize if that's a
bit biased/harsh, but I'm not sure how else to put it. I want to make it
clear that this is essentially a workaround to avoid a limitation of a
particular implementation choice. Occasionally that's unavoidable, but I
don't think that is the case here.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3720 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060614/9280a199/attachment.bin