On Tue, 8 Apr 2003, jfcm wrote:
At 21:53 07/04/03, Alex Rousskov wrote:
On Mon, 7 Apr 2003, jfcm wrote:
Would these sessions represent the whole message transiting through
OCP towards as many services as required ? If yes I would accept the
concepts. Interaction otherwise? A session would be all the OCP
interactions that a message may perform from the dispatcher to
services until sent to the user. So you could talk of the OPES
session. Makes sense in French, but I do not know if it is the same
in English.
If "many services" are on different callout servers,
I did not say "many services" but "as many services as required".
- if there is one or there are ten this makes no difference
- there must be no asumption of where a service process is located.
then your definition of "session" makes sense, but seems to be out of OCP
scope since OCP is concerned with single processor - single server
communication.
Please reread what I wrote. I am simply saying that if multiple
servers may be involved, then your definition of a session becomes out
of OCP scope. It is no longer an OCP session but something else. There
is nothing wrong with that, but it needs to be stated explicitly so
that we would know that OCP has nothing to do with it (this is an OCP
draft discussion thread!).
Tracing should keep track of previous OPES applied to the message.
To prevent loops. This builds the concept of a session (exit the
session in case of loop).
That's fine. You are, essentially, talking about tracing mechanisms.
Tracing discussion has its own thread.
If the services are on the same callout server, then
your "session" would be in OCP scope. It would be something that may
cross OCP connections even. I am not sure why we would need it though.
To be able to abort easier?
The question was about using the word session to another end.
The question was about naming communication between OCP agents. We
are talking about logical connections "to another _OCP_ end". Your
session is not about OCP, but OPES in general, I guess.
I explained what "session" meant to me, and I think it makes sense
and can be used. Abort is one reason I quoted, yes. There may be
others like to understand the order of the previously applied
services, etc.
Sure, that is what tracing is for. For example, HTTP Via headers are
used by proxies to detect loops. It looks to me that your session is
nothing else but a collection of all trace records added to the
application message so far. Is it not?
You sure you want to use OPES Processor the way you do?
For me it is opposed to every standard thinking I know.
Not sure what you mean. OPES processor is just an application proxy
that outsources processing of some messages. Sounds pretty "standard"
to me. Is it not?
Documented that already. To me a a processor is where an process occurs. An
OPES is a service. So to me OPES Processor is where the service process
occus, ie on what you call the call-out server. On what you currently call
the OPES Processor only happen the dispatch of the call-outs.
OPES processor can do adaptation internally. It can also do adaptation
externally but without the use of callout servers and OCP. I think
that is why it was called Processor, with a Dispatcher element. I
agree that the name/concept is unfortunate because it focuses on
physical placement (same box versus external server) rather than
logical role.
I tried to use OPES dispatcher as an OCP client, but folks objected,
citing the architecture draft. I do not have the energy to fight this
well-established terminology. Perhaps you can drive the change? Does
anybody else care about "OPES processor" terminology imperfections?
Alex.