[ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work
Karl Czajkowski
karlcz at univa.com
Sat Apr 29 01:09:21 CDT 2006
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
More information about the ogsa-wg
mailing list