Difference between revisions of "Second Life Grid Glossary"
| Line 5: | Line 5: | ||
:* [http://en.wikipedia.org/wiki/IEEE_1471 Wikipedia:IEEE-1471] | :* [http://en.wikipedia.org/wiki/IEEE_1471 Wikipedia:IEEE-1471] | ||
:* [http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf IEEE-1471 presentation slides] | :* [http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf IEEE-1471 presentation slides] | ||
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. | 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. | ||
Revision as of 11:42, 9 October 2007
Helping system designers speak a common language
Common understanding is predicated on discussing common mental models using a common language. IEEE-1471 helps considerably:
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.
What are the components of a grid?
In here components of a grid should be defined without looking at a possible implementation.
- Agent
- A entity (can be a real person or a bot) interacting with other agents eventually with a region.
- Region
- Some space. It can have any form. It can be grouped together with other regions.
- 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)
- Viewer
- A program which (possibly) controls an agent (eventually inside a region)
- Service
- A Web Services invocable resource which performs some task on behalf of a region
- 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.
- Currency, Identity, Asset Storage, Messaging, Presence, and a topology management are examples of Utilities