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