Difference between revisions of "Second Life Grid Glossary"

From Second Life Wiki
Jump to navigation Jump to search
Line 7: Line 7:




IEEE-1471 looks slightly heavyweight at first glance, but it isn't in practice because it isn't a straightjacket.  Its main benefit is in helping designers of system architecture to embrace the idea that interested parties ('''stakeholders''') each have their own concerns ('''viewpoints''') which need to be described in appropriate architectural '''views'''. An architecture itself is just an abstraction, and it is through the multiple views that this abstraction reveals how it solves the numerous (and frequently orthogonal) requirements.  One view definitely doesn't fit all.  (See [[Talk:Components_and_Roles|Talk]] for more.)
IEEE-1471 looks slightly heavyweight at first glance, but it isn't in practice because it isn't a straightjacket.  Its main benefit is in helping designers of system architecture to embrace the idea that interested parties ('''stakeholders''') each have their own concerns ('''viewpoints''') which need to be described in appropriate architectural '''views'''.
 
An architecture itself is just an abstraction, and it is through the multiple views that this abstraction reveals how it solves the numerous (and frequently orthogonal) requirements.  One view definitely doesn't fit all.  (See [[Talk:Components_and_Roles|Talk]] for more.)


== Terms of discourse ==
== Terms of discourse ==

Revision as of 02:59, 12 October 2007

References

Common understanding is achieved by discussing common mental models using a common language. In systems architecture, IEEE-1471 helps us approach that goal:


IEEE-1471 looks slightly heavyweight at first glance, but it isn't in practice because it isn't a straightjacket. Its main benefit is in helping designers of system architecture to embrace the idea that interested parties (stakeholders) each have their own concerns (viewpoints) which need to be described in appropriate architectural views.

An architecture itself is just an abstraction, and it is through the multiple views that this abstraction reveals how it solves the numerous (and frequently orthogonal) requirements. One view definitely doesn't fit all. (See Talk for more.)

Terms of discourse

Words with specific meanings within the project, defined so that discussions can be concise and misunderstandings fewer.

Agent
A entity (can be a real person or a bot) interacting with other agents eventually with a region.
Architecture
An abstraction that is central to system design, and which is revealed through descriptions and multiple views.
Asset
some entity which can be transferred from agent to agent or from agent to region or from region to agent. It can be something like an object, texture, sound, link, landmark
It's basically just a piece of data with a type
Avatar
The representation of an agent in a region (or somewhere else, like on the web)
Region
Some space. It can have any form. It can be grouped together with other regions.
Resource
Any finite architectural component or property or behaviour that is subject to exhaustion or which can become a bottleneck to system performance. Resources are the primary focus in designing for scalability. Examples: client-server bandwidth, agent pool depth, database access mechanism, locks, transaction times, utilities, services.
Scalability
The ability of a system to grow effectively in a given dimension in proportion to the amount of resource or capacity provided. The given dimension is often associated with a related dimension. A specific system may attempt to be scaled by adding resources, but this is effective only if the system is scalable. Example: scalability in the number of avatars at an event, viewed against the size of the user population, in proportion to the hardware allocated.
Service
A Web Services invocable resource which performs some task on behalf of a region
Stakeholder
Anyone who has a technical viewpoint that impacts on AWG work on system architecture.
Non-technical viewpoints exist and have validity, but do not fall within the current scope.
Utility
A Service, or collection of services which provides a utility which does not manifest as a region, agent or avatar within the virtual world. Examples: Currency, Identity, Asset Storage, Messaging, Presence, Topology Management.
Viewer
A program which (possibly) controls an agent (eventually inside a region)
Viewpoint
A set of related concerns about the architecture, and the representations or views used to describe the architecture to address those concerns. Examples: Client viewpoint, Functional viewpoint, REST Services viewpoint, Scalability viewpoint, Network viewpoint, Manpower viewpoint.