Hi Etienne, all,
On Thu, Sep 15, 2011 at 7:27 PM, Etienne URBAH
On Thu, 15/09/2011 13:00, Bernd Schuller wrote:
In many cases it was not clear to me whether you talk about the BES interface specification, or about the way a BES instance should be deployed and operated. It would be good to remove the operational and deployment concerns, so that only the specification parts remain.
2.4 Collaboration with other services
While this is important for interoperability, it is unimportant for the specification of a BES. The BES spec should NOT try to specify all the interaction with the rest of the world. This is the task of a "grid architecture specification" like OGSA.
My document is NOT targeted only to the specification of the BES Client interface, but to the clear and consistent description of BES context and functional + operational requirements which are really necessary for interoperability.
I would like to put forward a motion: "The discussion about BES interface specification should be separated from the discussion about interoperation of BES services." Motivation: Both discussions are important and necessary to have. Discussing both topics at once, however, will convolute the BES interface specification, and will delay overall progress. I do not mean that interoperation can only be discussed after the BES interface spec is finished, not at all - but each argument should clearly marked as belonging to *either* discussion, not both. Some more comments inlined...
Specifically, the interactions with security, monitoring, accounting and logging framework are OPERATIONAL concerns that MUST NOT be a mandatory part of a BES specification.
FAILURE of practical operations is often caused by LACK of early care about operational concerns during specification phase. As GIN-GC has proven and documented, this is even more true for interoperability on the field (as opposed to theoretical interoperability at the WSDL level).
I confirm that care about operational concerns is REQUIRED for real operations and for practical interoperability on the field. Although operational concerns are NOT part of the BES Client interface, they are REQUIRED for the overall specifications of BES in its context.
"REQUIRED for the overall specifications of BES" - I assume that this does *not* mean the BES Service Interface specification (which I think you refer to as 'BES client interface', as it is consumed by a non-service / client)?
In the text, I have stressed that the document DOES take into account operational concerns.
'the document' - I assume you mean the present requirement document? If so, I agree - it is useful to capture operational requirements. I also agree with Bernd though, that those should not directly influence the BES service interface specification, but rather are a separate concern. You cannot foresee the requirements of all implementations, nor the boundary conditions of all deployments - adding operational features to the BES Service interface specification *will* limit its applicability. Thus, those issues must IMHO be addressed in a separate document. And no, I don't expect EGI to use my service implementation ;-) My $0.02, Andre. -- Nothing is ever easy...