Difference between revisions of "AWG Domain rationale discussion"
(try to scope domain down to use in explaining the architecture) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
In normal usage, within computer architecture, a domain is a span of authority or trust, or in the case of DNS, a subtree of name space. Linden has proposed splitting the current flat system into an agent domain, and a region domain, and then, multiple agent and region domains. (in the 2008 picture, we see SecondLife Agents, XYZ Employees, XYZ land, and LindenMainland, as examples of domains, as well as a third domain, marked as central utilities. This strongly implies that domains which are both functional as well as trust/authority based. | In normal usage, within computer architecture, a domain is a span of authority or trust, or in the case of DNS, a subtree of name space. Linden has proposed splitting the current flat system into an agent domain, and a region domain, and then, multiple agent and region domains. (in the 2008 picture, we see SecondLife Agents, XYZ Employees, XYZ land, and LindenMainland, as examples of domains, as well as a third domain, marked as central utilities. This strongly implies that domains which are both functional as well as trust/authority based. | ||
Pragmatically, domains are only useful, if they give us some leverage in building the system. In other words, when we separate a set of components into a domain, we should expect to gain some technical leverage from the distinction. Grouping services by trust, for example permits us to use lower cost mechanisms to establish trust between services in the domain. Grouping services by function, seems less obvious, unless there is a very specific load balancing benefit from the grouping. (There may be perfectly good reasons for a company hosting a service to group servers by function for administrative purposes, but | Pragmatically, domains are only useful, if they give us some leverage in building the system. In other words, when we separate a set of components into a domain, we should expect to gain some technical leverage from the distinction. Grouping services by trust, for example permits us to use lower cost mechanisms to establish trust between services in the domain. Grouping services by function, seems less obvious, unless there is a very specific load balancing benefit from the grouping. (There may be perfectly good reasons for a company hosting a service to group servers by function for administrative purposes, or for example to provide a 3rd party acceleration service for one or more functions, but that is not being considered at this time.) | ||
So... abstractly, a domain is a grouping of resources which have some properties in common, such that we can use those properties when structuring the system, on an architectural level. | So... abstractly, a domain is a grouping of resources which have some properties in common, such that we can use those properties when structuring the system, on an architectural level. | ||
| Line 26: | Line 26: | ||
[[Category: | [[Category: AW Groupies]] | ||
Latest revision as of 17:53, 7 November 2007
This is intended to explain, in some detail, the basis for the definition offered in the glossary. Please feel free to add to it, ask questions, and generally help articulate this more clearly
In normal usage, within computer architecture, a domain is a span of authority or trust, or in the case of DNS, a subtree of name space. Linden has proposed splitting the current flat system into an agent domain, and a region domain, and then, multiple agent and region domains. (in the 2008 picture, we see SecondLife Agents, XYZ Employees, XYZ land, and LindenMainland, as examples of domains, as well as a third domain, marked as central utilities. This strongly implies that domains which are both functional as well as trust/authority based.
Pragmatically, domains are only useful, if they give us some leverage in building the system. In other words, when we separate a set of components into a domain, we should expect to gain some technical leverage from the distinction. Grouping services by trust, for example permits us to use lower cost mechanisms to establish trust between services in the domain. Grouping services by function, seems less obvious, unless there is a very specific load balancing benefit from the grouping. (There may be perfectly good reasons for a company hosting a service to group servers by function for administrative purposes, or for example to provide a 3rd party acceleration service for one or more functions, but that is not being considered at this time.)
So... abstractly, a domain is a grouping of resources which have some properties in common, such that we can use those properties when structuring the system, on an architectural level.
In software terms we could imagine having an web service which permits us to determine the membership and the properties of a domain. (This would require having useful markup for these properties) Note that both explicit and implicit domains exist in the current world. (any machine that is resolvable as .ibm.com is in the .ibm.com domain in DNS space, even tho we cannot fully enumerate them, and they share no other properties. All the machines in a lan server domain may be enumerable, and share a single administrative password.
There are other useful meanings of the word domain, and we might discuss domain experts, and the "scalability domain" in our discussion, but they aren't used in understanding the architecture we are trying to explain, and as such, can be left to common usage.
AWG Components =
These components are a part of the AWG Domain:
- Identity
- Scalability
- Decentralization
- Virtualization
- Geometry
- Physics