Re: [ogpx] verbiage : domain, agent domain, region domain, trust domain, service, etc.

[David W Levine <[e-mail]>]

[e-mail] wrote on 03/29/2010 01:16:18 PM:

> [image removed] 
> 
> [ogpx] verbiage : domain, agent domain, region domain, trust domain,
> service, etc.
> 
> Meadhbh Hamrick 
> 
> to:
> 
> ogpx
> 
> 03/29/2010 01:17 PM
> 
> Sent by:
> 
> [e-mail]
> 
> so... there's been some grumbling about the use of terminology on the
> list and in drafts. at the f2f we reiterated the need to agree on some
> basic terms. as i'm sure we all have one or two things to say about
> this subject, let's get the ball rolling...
> 
> as many people on this list know, the terms "agent domain" and "region
> domain" come from the previous OGP work. the term "domain" was
> originally thought to mean "a collection of machines administered by
> the same authority." an "agent domain" was a domain that managed
> user-oriented data: profile info, avatar presence, IM services,
> inventory, etc. a "region domain" was a domain that managed
> place-oriented data and processes: object presence, simulation, etc.
> 
> as the model was developed and we gained more deployment expertise, a
> couple things became clear:
> 
> 1. there's a high quality implementation of an asset service out there
> (cable beach) which _could_ be deployed independently of an OpenSim or
> LL instance. does this mean we should have an "asset domain"?
> 
> 2. linden deployment patterns (which formed the basis of early drafts)
> may not be used by all participants. specifically, an agent domain may
> "contract out" fulfillment of certain services to a third party. think
> of the way that linden currently deploys maptiles by way of amazon S3.
> for the purposes of managing maptiles, is S3 considered part of the
> linden agent domain? functionally it is, but even though it is trusted
> by linden,machines that serve the maptile requests will always be
> identified as belonging to amazon. (more info at
> http://aws.amazon.com/solutions/case-studies/linden-lab/ )
> 
> in response to point 1, several of us started to think that we
> probably would want to think about what makes a domain a region or
> agent domain, and if it's possible to have an "asset domain." this led
> to some verbiage in an earlier intro and goals draft that described
> "agent domains" as domains that contain an authentication service and
> "region domains" as domains that expose an object presence service.
> other groups of systems administered by the same entity were simply
> "domains"
> 
> fortunately, no one noticed we didn't define the term "service"
> especially rigorously. but i think there was general consensus that a
> "service" was a collection of "protocol endpoints" that performed a
> function on behalf of a client. an "endpoint" was an entity with an
> address that represented a RESTful resource that could be accessed to
> change or query the state of a service. for the most part, we talked
> of endpoints as being HTTP(S) urls, as most of us had experience with
> doing "OGP over HTTP."
> 
> while some of us debated the merits of various terms, others of us
> were wrestling with issue 2 above: what constitutes a domain? are all
> machines in a domain trusted by each other? what about when you add
> services from multiple domains, does that make a new domain? should we
> call it something else to highlight the fact that some of the machines
> in the domain may not trust other machines in the domain explicitly?
> if so, then why the heck do we have the term domain?
> 
> one suggestion was to redefine the term "domain" to mean "a collection
> of machines." then the term "trust domain" is used to define a
> collection of machines that share a trust relationship. a "composite
> domain" may be used to describe machines from two distinct trust
> domains that cooperate to deliver a service. "services," in turn are
> contained entirely in a domain. (so if a service is delivered by
> machines in two different trust domains, i.e. it's a composite domain,
> then that service is said to be contained by the composite domain, not
> the two trust domains that cooperate to deliver the service.)
> 
> so. ugh. what do we say about this:
> 
> domain - a collection of machines
> 
> trust domain - a domain whose members share trust characteristics.
> 
> trust characteristic - an abstract description of which entities are
> allowed to access which services on which members of a domain.
> 
> composite domain - a domain whose members are composed of two or more
> distinct trust domains. note that a composite domain may form a new
> trust domain.
> 
> service - a collection of protocol endpoints that implement a function
> (like authentication, inventory, IM, search, etc.)
> 
> (protocol) endpoint - the address of a RESTful resource a client may
> use to query or change the state of a service.
> 
> agent domain - a domain that exposes an authentication service.
> 
> region domain - a domain that exposes an object presence services.
> 
> comments? questions? death threats?
> 
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]

First, +1 (if not more) on getting the terminology coherent. The time has 
come to speak of things... We need names for the things, and we need those 
names in the base drafts, with nice crisp definitions. 

Names only help when they add real value. If we can't crisply say "This is 
a Blongezorf, and this isn't." we're merely muddying the waters. For 
domain, this is especially tricky as there are several very good and 
normal uses of Domain, both in Distributed Computing, and to and extent 
the casual discussion centering around the specs today. 

>From my perspective, there's a nice progression of things which we can 
define.

We have a set of "messages" which are defined in LLIDL, which laminate 
together into interaction patterns
(Post message X, Get response set Y1-Y7, post message Q) Mark that as a 
"service" , marked off by one or more capabilities.  Those services 
combine into a a cluster of services which form a capital "s" Service, 
such as a "Asset Server" or an "Inventory Service" 

I tend to think about the core "capital S" services as what we're busy 
defining. I'm not at all sure that, given the diversity of deployment 
patterns, defining "Domains" which tie to these into clusters beyond what 
people deploy actually adds any depth to the explanatory framework. I can 
see that there may well be some clusters of "Big S" services which often 
cluster, which may be worth looking at, if there is useful power in naming 
those clusters. Unless those clusters form of necessity, not habitual 
deployment, I'm thinking they would be a non-normative term used elucidate 
rather than define. 

- David
~ Zha