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

[Marvin Theimer]

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. 

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

Marvin.


-----Original Message-----
From: Karl Czajkowski [mailto:karlcz at univa.com] 
Sent: Friday, April 28, 2006 11:09 PM
To: Marvin Theimer
Cc: ogsa-wg at ggf.org
Subject: Re: [ogsa-wg] Thoughts on extensions mechanisms for the HPC
profile work

Marvin and all:

One additional comment I would add for consideration with extensible
content (operations, resource models, etc.) is that there is a
practical need for two complementary mechanisms that is often
overlooked:

   1. Runtime meta-language for marking criticality of extended content,
      e.g. marking an extension field as "OK to ignore" or "MUST be
      understood" so that a service in a heterogeneous environment can
      decide whether to proceed when it encounters some newfangled
      extension that is not implemeneted in the service.

      I would argue that there is no default policy that is appropriate
      for a majority of environments. Making the wrong choices on an
      extension-by-extension basis can cause faulty behavior and/or
      waste.

      I think there is a tendancy to use undisciplined "xsd:any" syntax
      in GGF documents lately, and I think it is a mistake.  Please
      see the createAgreement operation extensibility of recent
      WS-Agreement drafts for my take on what is needed at minimum.  We
      define an "OK to ignore" wrapper so that the service can
      disambiguate required versus optional extension fields in the
      input message.  Unwrapped extensions are assumed to be
      mandatory/critical.

   2. Discovery mechanisms for extensions supported by services. This
      obviously should complement what other discovery mechanisms are
      under discussion for job management.  This is what will enable
      efficient brokering/routing of requests in a heterogeneous
      environment.

The runtime disambiguation in (1) is more important if we have a
general "aspect oriented" extension mechanism where, as you mentioned,
there is a power-set of possible job descriptions.  With a more
limited profile/dialect approach, there would be a much smaller set of
defined combinations.  The art is probably finding the right hybrid of
some "major" dialects with "minor" aspects so that major contradictory
dialects cannot be mixed by accident, but simple minor extensions are
not forced into this extend-by-replacement methodology.


karl

-- 
Karl Czajkowski
karlcz at univa.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20060501/939a16b4/attachment.html