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

[Marvin Theimer]

Hi;

 

The "neither" option is what frustrates me reading this. We want to

expose public state, and yet apparently we have to keep implementors in

mind that have no standard way to expose that public state.

 

...

 

I reluctantly agree. I was operating under the assumption that at very

least either WSRF or WS-Transfer would be an acceptable requirement. Not

having any public state model requirement at all makes this a slightly

different problem in my opinion.

 

I believe that today's reality is that you can't assume universal WSRF
or WS-Transfer support anytime soon.  

 

 

I think I'm with you now for the most part. I just have a problem with

singling out one property over another in terms of which ones are "good

enough" to have their own accessor operation. Especially if we allow for

notifications, the activity status might be the least used and yet you

are proposing that we make it the only property that gets it's own

accessor operation. Perhaps it would be acceptable to create a hybrid

operation that either takes an array of property QNames and returns

those properties (ala WSRF's "GetMultipleResourceProperties"), or if the

array is empty/not specified returns the entire public state document

(ala WS-Transfer's "Get"). If we need a multiple-activity operation for

the BES services, then just add another argument that is an array of

activity EPRs and name the operation to distinguish it from the singular

operation.

 

I didn't mean to advocate that there be an explicit accessor function
for only the activity status property.  Rather I was advocating that
there be accessor functions for each of the properties and that the
interop standard mandate that there be at least the accessor function
for returning an activity's status (in addition to the accessor function
for returning all the state information for an activity).  All other
accessor functions would be part of extensions.  

 

In my response further down I explain why I prefer explicity accessor
functions over a WSRF-style GetMultipleResourceProperties approach.

 

 

This is essentially what I was pushing with my ambiguous public state

model concept. What I wasn't considering was this new (at least to me)

requirement for no public state model at all. If we can't assume a

public state model, then we have to basically agree on some minimal

reconciliation between WSRF and WS-Transfer since the BES spec implies

some sort of public state model as a result of it's definition of

statefull service properties. The two candidates seem to be the

following:

 

1) Have named accessor operations for each property and one operation

for obtaining the entire public state document, or

 

2) Have a single, generic operation that fetches either an array of

properties or the entire set of public state properties.

 

I would advocate taking approach 1 for the following reasons, derived
from an explanation of a colleague of mine recently provided me:

 

The advantage of the explicit accessor function approach, given the
current tooling and suite of technologies that most of the world has, is
that you can describe it completely using metadata (i.e. WSDL). The
latter approach cannot be described in WSDL, hence the need to introduce
the additional message exchange (GetListOfProperties). The disadvantage
of the explicit accessor function approach is that you can't request
more than one property at a time.

 

You might ask why being able to describe the interface completely in
WSDL/XSD matters.  The reply to a 'GetState' request will have to be a
message with open content...

 

<properties>

  <xsd:any>

</properties>

 

Of course you can define in your specification that if property A is
included in there, then the structure would look like

 

<properties>

  <A>

     <foo />

    <bar />

  </A>

</properties>

 

However, now this description is in a human language specification and
not in a machine-processable vocabulary.  You have to manually make sure
that you implement support for the various infosets before you can deal
with the results.  If you make an error in your implementation then the
tooling won't help you - nor can the tooling help you with any kind of
static analysis of your interface for correctness or security purposes.

 

If you define explicit messages, then you can describe the structure
using WSDL and XSD and you can point your favorite WSDL->Java or
WSDL->C# tool at the WSDL document and everything will be generated for
you. There would be no surprises because the two sides have agreed on a
contract.  Note also that such tools make the creation of client code
for using a multitude of explicit accessor functions fairly painless.

 

 

Marvin.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060628/01e0ee0a/attachment.htm