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@univa.com