All, On the call today we had: Steven Newhouse Michel Drescher Karl Czajkowski Fred Maciel Steve McGough Andrew Grimshaw Issues identified in the document that need to be discussed on the next call or on the list: Review: Section 3.2: Replacement of a general all encompassing fault with 'NotKnown' status that can be used within the ActivityStatus document to identify activities that are not known. Discussion: Section 3.2: Use of the CIM state enumerations. Discussion: Sections 3.5, 3.5 & 3.6. Having 3 management operations in the BES specification until generic OGSA management structure defined? Discussion: Section 3.7: When returning the JSDLDocuments do we place the WS-Name in the JSDLDocument or encapsulate it with the WS-Name in a new element? Review: Section 4: Text for exposing container acitivty. Review: Section 5: Text for security considerations. -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
I wanted to ask when will the BES team take on the task of defining a WSRF rendering? I would think that generating this concrete WSDL would be revealing in terms of the BES design. Ian. At 09:11 PM 7/21/2005 +0100, Steven Newhouse wrote:
All,
On the call today we had: Steven Newhouse Michel Drescher Karl Czajkowski Fred Maciel Steve McGough Andrew Grimshaw
Issues identified in the document that need to be discussed on the next call or on the list:
Review: Section 3.2: Replacement of a general all encompassing fault with 'NotKnown' status that can be used within the ActivityStatus document to identify activities that are not known.
Discussion: Section 3.2: Use of the CIM state enumerations.
Discussion: Sections 3.5, 3.5 & 3.6. Having 3 management operations in the BES specification until generic OGSA management structure defined?
Discussion: Section 3.7: When returning the JSDLDocuments do we place the WS-Name in the JSDLDocument or encapsulate it with the WS-Name in a new element?
Review: Section 4: Text for exposing container acitivty.
Review: Section 5: Text for security considerations.
-- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
_______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org
I wanted to ask when will the BES team take on the task of defining a WSRF rendering?
I see another few weeks of resolving the issues in the current psuedo interface before moving on to concrete rendering. I'd hope that would be the main topic at the OGSA F2F. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
great, thanks. At 08:05 AM 7/22/2005 +0100, Steven Newhouse wrote:
I wanted to ask when will the BES team take on the task of defining a WSRF rendering?
I see another few weeks of resolving the issues in the current psuedo interface before moving on to concrete rendering. I'd hope that would be the main topic at the OGSA F2F.
Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
_______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org
Discussion: Sections 3.4, 3.5 & 3.6. Having 3 management operations in the BES specification until generic OGSA management structure defined?
The operations in 3.4 & 3.5 (Start & Stop AcceptingNewActivities) I see as being a service specific management function (i.e. they effectively alter the behavior of one specific operation within the service). The 'ShutdownContainer' operation is a concern. Firstly from a naming perspective as it applies to the BES not to the web service hosting environment. And even if the name was changed to imply that the service itself was to be shutdown... 1. This would be a 'generic' management action which should fall under the general OGSA management remit. 2. Also, this seems to be an operation on the hosting environment not the service. 1 & 2 are I suppose effectively the same but I suppose I'm not sure this operation fits here. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
On Jul 23, Steven Newhouse modulated:
Discussion: Sections 3.4, 3.5 & 3.6. Having 3 management operations in the BES specification until generic OGSA management structure defined?
The operations in 3.4 & 3.5 (Start & Stop AcceptingNewActivities) I see as being a service specific management function (i.e. they effectively alter the behavior of one specific operation within the service).
While its semantics references a BES operation, it seems to me that it is a more general management pattern for any service that has a stateful, factory-like interface: stop accepting/creating new work items but continue processing the existing ones (whatever they are). The BES-specific meaning could just as easily be specified by calling out this work acceptance model so that it can be related to an external management mechanism. I think it is wrong to burden BES implementations with these kinds of management functions that are specific to a hosting environment. I think the right path here is to engage in management standards for web services and create profiles to compose these with a basic execution service if you require both. I cannot see these functions as being more important interop points than any of the other security and policy management functions which everyone seems to agree are out of scope. If you must use localized mechanisms to do practical management of a BES installation, I am not sure what these functions buy you. karl -- Karl Czajkowski karlcz@univa.com
+1 Karl Frey’s Law: “Every 5 years the number of architecture components double and the ability to comprehend them halves” Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601 Karl Czajkowski <karlcz@univa.com > To Sent by: Steven Newhouse owner-ogsa-bes-wg <s.newhouse@omii.ac.uk> @ggf.org cc ogsa-bes-wg@ggf.org Subject 07/24/2005 01:13 Re: [ogsa-bes-wg] Management AM Functions in BES On Jul 23, Steven Newhouse modulated:
Discussion: Sections 3.4, 3.5 & 3.6. Having 3 management operations in the BES specification until generic OGSA management structure defined?
The operations in 3.4 & 3.5 (Start & Stop AcceptingNewActivities) I see as being a service specific management function (i.e. they effectively alter the behavior of one specific operation within the service).
While its semantics references a BES operation, it seems to me that it is a more general management pattern for any service that has a stateful, factory-like interface: stop accepting/creating new work items but continue processing the existing ones (whatever they are). The BES-specific meaning could just as easily be specified by calling out this work acceptance model so that it can be related to an external management mechanism. I think it is wrong to burden BES implementations with these kinds of management functions that are specific to a hosting environment. I think the right path here is to engage in management standards for web services and create profiles to compose these with a basic execution service if you require both. I cannot see these functions as being more important interop points than any of the other security and policy management functions which everyone seems to agree are out of scope. If you must use localized mechanisms to do practical management of a BES installation, I am not sure what these functions buy you. karl -- Karl Czajkowski karlcz@univa.com
The operations in 3.4 & 3.5 (Start & Stop AcceptingNewActivities) I see as being a service specific management function (i.e. they effectively alter the behavior of one specific operation within the service).
While its semantics references a BES operation, it seems to me that it is a more general management pattern for any service that has a stateful, factory-like interface: stop accepting/creating new work items but continue processing the existing ones (whatever they are). The BES-specific meaning could just as easily be specified by calling out this work acceptance model so that it can be related to an external management mechanism.
I don't disagree with your statement. 1. Do these exist at the moment for use within the BES specification? 2. Would I want to adopt a whole new set of specifications (assuming the answer to 1 is yes) to turn this off in a 'generic' way?
I think it is wrong to burden BES implementations with these kinds of management functions that are specific to a hosting environment.
Altering the behaviour of one operation within the service has nothing to do with the hosting environment in my view. The 3rd operation (to stop the service) - would be hosting environment specific - and perhaps does belong elsewhere. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
On Jul 25, Steven Newhouse modulated: ...
I don't disagree with your statement.
1. Do these exist at the moment for use within the BES specification?
I don't know. Does the unix "nologin" pattern count (which administrators requested as an interface to stop job submission on GRAM)? My point is not that there would be _one_ standard but that there are different localized administrative mechanisms which already exist and are even preferable to yet another service-specific control. I used the word "profile" because I personally do not expect to find convergence on one administrative model among the BES constituency...
2. Would I want to adopt a whole new set of specifications (assuming the answer to 1 is yes) to turn this off in a 'generic' way?
You tell me. :-) I would want to adopt one, or rather, I would want my BES implementation to compose w/ the other standards I already must worry about instead of introducing yet another mechanism.
I think it is wrong to burden BES implementations with these kinds of management functions that are specific to a hosting environment.
Altering the behaviour of one operation within the service has nothing to do with the hosting environment in my view.
I see this as fundamentally an authorization mechanism, just like the nologin thing. Quite likely, the site may want to exempt certain users and/or classes of jobs from the "do not accept jobs" mode. In our Globus Toolkit web service container, authorization is conveniently handled on a per-operation basis and is often handled by more generic mechanisms at the message-handling layer rather than by service-specific code. (All sorts of variants are possible.) Also, historically, I think management models like CIM and now WSDM have tried very hard to identify general lifecycle patterns such as this "stop accepting work but keep processing" and they are trying to standardize the administrative models for such things. They may want to automate the control of such things using workload managers or other adaptive throttling behaviors. I think a different question is, can I continue to make do without this extra BES function until such standards are ready? karl -- Karl Czajkowski karlcz@univa.com
participants (4)
-
Ian Foster -
Karl Czajkowski -
Steven Newhouse -
Tom Maguire