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

[Meadhbh Hamrick <[e-mail]>]

so i said services contain "protocol endpoints" rather than
"capabilities" as it's possible for services to have well defined,
public endpoints that are NOT capabilities.
how 'bout...

the terms "asset domain" and "region domain" are used to identify the
domain of certain types of transactions in the protocol. their use
underscores the potential separation of the roles each domain plays.

so we would say, "the agent domain initiates the process of placing an
agent in a region domain's simulator" rather than "the first service
initiates the process of placing an agent in a region."

so the terms "agent domain" and "region domain" are "positional" and
describe the function in a protocol transaction, NOT a requirement
that a group of machines implement a particular cluster of services.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Mon, Mar 29, 2010 at 1:44 PM, David W Levine <[e-mail]> wrote:
>
> [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
>
>
>
>
>
>
>
>
>
>