This (somewhat repetitive) discussion makes me think that we still do not have a precise enough nomenclature for the various aspects of jobs that matter in describing the architecture. I think we (the HPC and Grid Job management community) spend an inordinate amount of time talking in circles to reestablish common ground because of this... The terms are important not only to have unambiguous debates, but also to make the semantics in specifications clear, concise, and relevant. At a high level, this thread has revisited (and these are my best efforts at describing them for discussion, and not an assertion of what to call things in specifications): 1. Service management interfaces a. Possible generic control (start, stop, deploy, undeploy, etc.) b. Existing BES-specific controls (accept activities, etc.) [Has strong overlap with WSDM, CIM, et. al] 2. Generic Activity management interfaces (the main point of BES) a. Activity creation and destruction b. BES service "resource capabilities" (what can be run) c. Single and Array activity monitoring and control [Has overlap with provisioning and resource management] 3. Extended Activity management interfaces a. HPC Suspend/resume b. POSIX or Windows-specific controls c. Job File I/O d. ... (huge range of domain-specific stuff in future) [Has overlap with existing "legacy" grid services] 4. Extensibility Discovery/Negotiation mechanisms And I will add: 5. Applications/Services By this last one, I mean that BES is envisioned to support management of complex services through extensions. I think there is a distinction to be made between the "business" end of such a service (5) and its management interface as a special kind of activity (3). I often get an uncomfortable feeling that some people are expecting the "activity EPR" to expose the business interface, while I and some others expect it to only expose the extended management interface. This extended interface might well include some discovery/bootstrapping capabilities to help find the business endpoint(s) of the activity. I will also point out that, in some sense, BES as a generic activity manager (2) ought to be capable enough to recursively act as the manager of another BES service (1a). As an analogy, a well-known BES service might allow creation of VO's and VO services. Some of these VO services might be new BES instances. It seems to me that the BES-service management interfaces (1b) of the second-tier BES should be part of the extended activity interface (3) of those BES-types activities when they exist within the first tier's environment. On the other hand, the ability to create activities in the second tier is part of the "business" interface of those BES services. In my opinion, it does not belong in the activity management view of the service within the first tier BES service! [Note, I mention this to try to cut deeply into the distinctions between interfaces. I realize recursive use of BES is not on the top of everyone's must-have scenario list.] Also, as Marvin and Donal are pointing out, we need to consider various roles and scenarios. On the other hand, Donal's comments lead towards that slippery slope of assuming too much about implementation, e.g. that authorization is scoped at endpoints. Do we wish to assume this? I know it is easy in Globus land, but we can also handle per-operation authorization. We are, as implementers, a little hog-tied as far as providing finer authorization scoping, e.g. access controls on specific message contents. It is a tricky area, fraught with usability problems and non-interoperability. karl -- Karl Czajkowski karlcz@univa.com