[OGSA-BES-WG] BES Last Call

[Karl Czajkowski]

On Feb 08, Christopher Smith modulated:
...
> The reason for the MAY is in the phrase "If the consuming system does not
> provide the requested operating system....". Some systems may choose to
> accept the JSDL as is, and might just have an activity whose resource
> requirements can never be satisfied (unless an operating system of that type
> is configured in the system and made available to the BES). This would be
> the case for my BES implementation on top of LSF, which allows one to
> specify resources that may never be satisfied.
> 

Chris, I think you are trying to get at some awfully subtle
distinctions here. Where do you draw the line between:

  1. XML unparseable (malformed)
  2. XML unvalidatable (extension schema not known)
  3. semantically inconsistent (schema allows meaningless expressions)
  4. not supported by implementation
  5. resources "never" available (not configured in cluster, etc.)
  6. resources "temporarily" unavailable (due to load, etc.)
  7. resources unavailable for given user role (due to policy, etc.)
  ...

It would seem to me that you want to be careful in making sure faults
are also interoperable if you are going to model them.  Can a
programmatic client behavior take a meaningfully different fault
response action based on the fault type here?  Or does this boil down
to the fault indicating "the service did not like it" and there being
some hints that a human might find useful during fault determination?

This leads me to wonder if there is any real information captured in
these very similar fault messages.  If a system MAY report something
as invalid when it might really be extensible value content not
understood by the system, and if a system MAY accept something that is
contradictory, what exactly is being communicated?

It would seem to me that you need a fault "lattice" where the most
generic fault at the bottom can be generated and understood by any
sensible implementation, while the more precise faults should have
more stringent requirements on when they can be signalled.  I don't
think you want to model subtle faults and then allow implementations
to be liberal in what they generate here, as that would fail to encode
real information for further processing decisions.


karl

-- 
Karl Czajkowski
karlcz at univa.com