I am sorry, but I find this terminology confusing and limiting the analysis.
We are talking about services. Theses services are called by dispatchers
according to rules. If there is a service there is a user the service is
delivered to and a host the services is delivered on behalf of. My
understanding from IAB and first draft is that OPES correspond to the
following sheme under HTTP:
Service User ----> dispatcher -----> Service Organizer
^
| callout protocol
v
service
provider
As Oskar says, the traffic can be bidrectional. So I do not really know who
the data consumer and the data producer are:
Service User <----> dispatcher <----> Service Organizer
^
| callout protocol
v
service
provider
Others want to support SMTP etc. Others want the system to be able to fork.
Service User <----> dispatcher <----> Service Organizer
/ ^ \
Other user / | \ Other Host
v
service
provider
My own reading is that this dialog system conducted by the dispatcher
should become a polylogal system, hence "open" in my "open extended network
system" naming. This is also why I call them "network" services while IAB
specifies clearly "edge". And why I call them "extended" (in comparison
with "basic" and "enhanced", because they relate users with as well as what
you call data producers and with other data users)
Because - as Oskar points it in saying it is bidireactional - I know who are:
- the user and the producer in an access connection
- the caller and the calleed party in a communication
- but I do not know who are the user/producer nor the caller and callee in
a relation - all the more in a distributed networked relations among a
community/market. I can at most differentiate different classes of users
(of of their agents) and groups of virtual services (organizers). In this
what counts is not what is installed or proposed, but what I am allowed to
use at a given time. And the very organizing host (supervisor) may be
itself subject to in the flow changes (example: the proposed service
promotes me on-the-fly to an "admin" status).
To follow the same presentation as above:
Supervisor or
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
At 21:08 22/02/03, Oskar Batuner wrote:
Hi Alex,
Here are some comments:
> 0. Introduction
>
> draft-ietf-opes-protocol-reqs-03.txt defines the following
> information flow:
>
> data provider --(original application message)-->
> -- [ OPES magic ] -->
> --(produced application messages)--> data consumers
>
I think both protocol requirements and architecture support OPES
processing in bi-directional message flow, both for data consumer
requests and data producer responses. This means that this diagram
and subsequent association of incoming message with the data producer
and outgoing message with the data consumer should be changed to
reflect the bi-directional nature of the OPES flow.
True. But this only permits a dialog: ask the user to accept
a redirection. It should support polylog (example: conditional
access to be accepted. Ex. the redirection costs more and
depending on the caller, an external authority (bank) is to
permit it which may want to call the caller for extra warranties.
> OPES processor and callout server exchange messages. The
> exchange is bi-directional. There is no clear client or
> server role. There is no clear request/response message
> category either.
>
I do not agree with that. Per OPES architecture processing is initiating
by rules that are triggered by some event in the OPES flow (arrival of
request or response). As a result of some rule evaluation OPES processor
can make a request to OPES application (either in the same box or a callout
server). This creates a clear client-server roles: OPES processor makes a
request and callout server produces response.
There is a link between the dispatcher and the service. But none is
the boss. There may be negotiations (both ends) or flow control
(the service adding a rule in the dispatcher to block requests until
it is ready again), etc.. A service may be linked to serveral
dispatchers and a dispatcher to several identical/similar services.
OPES callout protocol should reflect these roles. Each transaction is
initiated by the client (OPES processor) and executed by the server
(callout server). There are certain message types that are produced by the
client and other (different) types produced by the server. Protocol state
transitions also should clearly reflect these roles. For example each
transaction starts from <xaction-start> message from the transaction client
and is terminated by <xaction-end> from the transaction server. BTW, my
initial confusion was due to the absence of transaction roles. In
bi-directional
exchange without defined roles each side has to specify transaction
boundaries, but
with predefined client-server roles it is enough to have one open and one
close message, as in your example.
There is a client/server role within an accepted on-going
cession/transaction. But if the link is broken what are the
recovery decisions? The service may be to contact the
user and rebuild the link through another dispatcher?
Note that protocol requires definite roles only per transaction. Roles are set
by the opening message and may be different for different transactions.
True.
For the OPES architecture when processing is initiated by incoming OPES
processor
messages (from producer or from consumer) OPES processor is always a client.
These
roles may be different only for metadata requests (e.g. callout server
requests
about consumer or provider preferences). But again each transaction has client
and server.
If I read you correctly you talk about two different client/server systems.
One is producer/consumer, the other one is processor/server.
And you say that depending on transactions the roles may be changed?
The question is: do we allow such requests in-band?
May I suggest a question in response? How do we zap
and abort the transactions? Should not the response be
the same?
jfc