General Principles

This section will be used to provide general guidelines for the operation and construction of components for this project.


Identity

It seems to me that there is an interesting question that runs through several of these threads which has to do with identity. For some things, we often think of the identity of the person as established by a user name and password or some biometric or other means. But, it seems to me that there are other functions which depend on physical identity. E.g., for an AppServer agent starting up, if we are going to have it determine its configuration based on some service, then how do we know which agent it is? This could also apply to security polices such as Joe is entitled to download general ledger details when he is sitting at his desk, but not when he is dialed in from a remote location. I would be interested in people's ideas about both what kind of identities are needed and how it is that they might get assigned.


Standard Questions

There are a number of questions we want to ask about each candidate service. These include:

1. What kind of service is it? I.e., is it one service for a network? One per application? One for a system? One per session? Can it be replicated without change of function?

2. What inputs does it need?

3. What outputs will it return?

4. Who uses it and how frequently?

5. What does it depend on and how often?

6. How is it managed?

I will also note that while we have been using the currently popular term "service", there are places where we might want instead to use the term factory or the term manager. Service seems particularly appropriate when the component is centralized and broadly used, but also seems to fit some per session uses. Not key, but something to think about whether there is any convention we might want to adopt.