[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: RE: OPES protocol, pre-draft 01
A A typo of mine created some confusion. Sorry. Instead of this
Service
User <-----> dispatcher <----> Service Organizer
/ ^ ^
\
Other user /
| | \ Other
users
v v
service <--> server <----> service
controler /provider
dispatcher provider
external user
/
^
/^
etc..
etc..
| / |
v / v
etc. /
alarms,logs
/ etc
/
other ONES domains
Please read that.
Supervisor or
Service User <-----> dispatcher <----> Service
Organizer
/ ^ ^
\
Other user /
| | \ Other users
v v
service <--> dispatcher <----> service
controler
/provider /
^
provider
external user
/
/
|
/
^
etc..
etc..
/
v
/ |
/ service /
v
dispatcher etc. /
alarms,logs
/ etc
/
other ONES domains
The difference is about the wrong typing
"server<br>dispatcher" confusing with "server
dispatcher".
I tried to keep it denser and using "server dispatcher" was a
wrong wording (server's dispatcher was intended but I thought
"'s" was only for persons?). Anyway using "server" as
a separate machine was wrong. Using "secondary dispatcher"
(like in the DNS) would also be wrong.
This only wants to show that there are thres building blccks:
- dispatchers
- services
- ends
That services are actually made of a service adminstrator triggering the
services. and that the ends may be of tree different natures :
- user : they call and get the service
- organiser : they organize their access/responses to use the ONES (used
on the flow)
- supervisor : they organize their responses as a permanent cooperative
strategy.
This only shows that there is a simple (three building blocks, with
limited number of building block types) but wich a lot more of
interaction types than in the OPES draft model.
My only interest right now is that we understand clearly this way what is
in the OPES area (in the charter of this group) and how it may benefit
from ONES analysis (up to the WG to discuss issues over OPES charter). If
we do not do that we risk to confuse?
jfc