[ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work

[Karl Czajkowski]

On May 01, Marvin Theimer modulated:
> Hi;
> 
> You're absolutely right that we require some sort of discovery
> mechanism for determining which extensions are supported by a given
> service.  I would argue that this is a general problem where we should
> be following the lead of the broader web services community.  That
> said, I don't think that that community has settled on anything yet --
> people please correct me if I'm wrong on this -- and that we may well
> need to define our own mechanism in the interim.  We should make sure
> that we design things so that we can easily migrate to whatever the
> industry standardizes on whenever that becomes available.
> 

Right, I haven't seen anything adequate from the WS community either.
It is funny that simple things like critical/non-critical protocol
extensions, which existed even in LDAP are not carried forward here...


> Regarding your suggestion for having a runtime meta-language for
> marking content as "ok to ignore" or must be understood", I have
> several questions/requests:
> 
>   • When you say "meta-language" are you implying something richer than
>     these two choices?  I can imagine at least two answers to this
>     question:
>       □ "Simple" (and hence also efficient) resource matchmaking
>         typically involves (mostly) exact matches.  Adding a simple
>         binary notion of an optional resource requirement adds a
>         powerful descriptive capability without substantially
>         complicating the matchmaking system.

I wanted to raise the general issue in case others have
requirements/opinions.  I think a binary model is a good one for a
basic interface.


>       □ You want a much more expressive resource description/
>         matchmaking language that lets you specify all kinds of
>         complicated concepts, such as prioritization of optional
>         alternatives.

WS-Agreement has a much more elaborate meta-language which can capture
prioritization and even cost/optimization models for whole
combinations of domain-specific constraints (in some sense, every
service description is an "extension" in WS-Agreement).

I completely agree that this is a hard problem and by the time you
want to support this, you are probably better of going to a protocol
like WS-Agreement that has defined it in from the start.  It is not
only the runtime meta-language, but also the discovery model used to
expose these options, which become more complex.


>   • It would be great if you could provide a variety of example use
>     cases.  I personally agree with your view that having a small set
>     of major dialects with minor aspect extensions seems like the most
>     likely approach to be successful.  Having a concrete set of
>     examples will make the design conversations much more focused.

I think it will be easier to do this after a few of the high-priority
(or low-hanging) problem domains have been identified.  I don't want
to go off into a never-ending modeling exercise... I would like to
help define job-description models which can serve equally well in a
"basic HPC job protocol" as well as in WS-Agreement descriptions of
the same job.  In otherwords, a product of this effort needs to be the
standardized job ontology that is the basis for these
protocols. (There, I said it. ;-)


>   • Without wanting to comment on the specifics of GGF documents, I
>     think of the use of xsd:any as being as markers for extensibility
>     in specific protocols.  Profiles then define and constrain how
>     those xsd:any fields may be turned into more concrete (extension)
>     specifications.
> 

Right, the problem is that without the runtime distinction of
critical/non-critical nor an appropriate discovery system, this
approach leads to extremely fragile systems.  Basically, there is no
good way to find out who understands your dialect and everyone has to
be paranoid and reject any dialect or jargon they do not
understand. The two mechanisms are complementary in getting "good
enough" processing to occur in a heterogeneous and evolving
environment.


> 
> Marvin.
> 


karl

-- 
Karl Czajkowski
karlcz at univa.com