On 21:37 12/03/03, Oskar Batuner said:
And they send these messages ONLY through the OPES processor. My point
is that as OPES processor is the principal point of contact between
OPES flow ends and the OPES application it should be the only
point exposed to the end user/server. In your previous example
about preferences end user does not know the OPES application
composition (what functions are performed at what point), and
preferences relate to the OPES application as a whole.
SOS! I am lost (low IQ, old brain). I am not sure I fully grasp
some of the word, and most of all their different shades.
- OPES processor.
- OPES application.
- OPES flow ends.
- OPES box
- a callout processor.
- one or several servers proposing OPES (services)
- OPES components
Sorry for the questions. I don't need examples to understand
but I need logic and exact words which leads to simplicity,
even to robust rusticity.
At this time I understand
- there is a data flow between a user and a content provider.
- the user and the provider may switch roles,
- they usually want to talk HTTP
- between the user and the provider there is a converter
made of
- a filter (dispatcher)
- transformers (OPES servers).
- there is a protocol from the dispatcher towards the servers,
however it is not clear to me if the protocol is between
dispatchers acting as front end for servers or between
dispatchers and servers.
At some stage I understood that a property of OPES
was that the user did not know they exist and that he
could not relate with them. Now it appears that the HTTP
flow should be transport (how?) an indication of the
OPES presence, that the OPES could be opposed at
the user decision? That the dispatcher could relate with
the user, but not the OPES (service).
Am I reading this correctly in simple layman words?
If this is the case we are not anymore in the OPES field
as it is not an "edge service" but a "both ends" service.
IMHO the very nature of the OPES is to add a service to
one end. The other end may be interoperated as part
of the service, but should not decide of the service itself.
If the other end co-decides, it becomes a cooperator
of the OPES, and many other ends in a relation many
to many may also be cooperating: we enter another
model I call ONES.
Distribution of OPES application functions between components may
even change dynamically as adaptation to the load conditions. Let's say
until your OPES box is underloaded application functions are performed
there, if load is too high - callout processor is invoked, if load is
too high for callout processor a new one is added - either by the OPES
processor or by callout processor. Certain things may break - I've
already notified OPES server and one callout processor that I don't
want adult contents, but now load balancer switched me to the new
callout processor that does not know my preferences!
All these things are only operation management not architecture?
If you have a single user contact point this may scale pretty well,
otherwise the user has to be involved in the process in which he/she
is not interested at all - function distribution between OPES components.
As soon as the user is aware of OPES existence and knows the contact
point (this information MUST be provided in-band)
How?
further communications
may be ether in-band or out-of-band, depending on the particular protocol
and application.
True. But is that still OPES?
jfc
PS. Please relax: I am out for 3 days :-)