On Thu, 5 Jun 2003, Martin Stecher wrote:
regarding services: The usage examples do not convince me that
changing of services will be needed
I agree that my examples were not very convincing. Let me try to come
up with a few better/different ones:
An OPES processor is serving a large group of users,
with diverse filtering needs. Perhaps this is a
hosting environment with OPES-powered translation
of hosted pages and other customer-specific services.
Or maybe this is a CDN-like environment. The OPES
processor is configured to use a callout server that
can perform any service required. When the processor
opens the connection to the server, no single set
of services would describe its future needs. The
processor leaves per-connection services empty as
the default. For each transaction, the processor
specifies the exact services that apply to that
transaction, overwriting the default empty set.
Opening a new transport connection for each
transaction is not efficient enough in this case.
An OPES processor performs a well-known list of
services for all transactions, except there is
a small group of VIP users that need a different set.
The processor can allocate a new transport connection
whenever a request comes from a VIP user, but it would prefer
to use the existing transport connection since
a VIP connection is not used often enough to
keep it persistent.
A busy callout server shared among many OPES
processors (they subscribe to and pay for the
service) does not allow more than one transport
connection from a single OPES processor (or per
single subscription so that you can pay for extra
connections).
To summarize my current understanding, which, I think, reached another
level thanks to your comments:
0a.Allocation of new services can be expensive so
it is good to have some facility to load/unload
a set of services for a group of transactions,
instead of doing it for every transaction.
0b.Allocation of transport connections can be
both very expensive and, in some cases, technically
or administratively impossible. OCP should not require
allocation of multiple transport connections for
semantic reasons. Everything should work over a single
transport connection. This is an important design
constraint!
1. There are cases where transactions
share the same list of services.
2. There are cases where transactions
do not share the same list of services.
3. Several common lists of services may co-exist.
For example, common services for images and
common services for executables.
The above observations lead me to the following solution:
A "list of services" needs direct OCP Core support.
We need messages that create and destroy service
lists. We need a mechanism to refer to an existing
service list from a transaction-start message.
Something along these lines:
service-list-create sid=123 (s1, s2, s3);
transaction-start xid=56 ... sid=123 ...;
transaction-start xid=57 ... sid=123 ...;
transaction-start xid=58 ... sid=123 ...;
...
service-list-create sid=45 (s4, s5);
transaction-start xid=60 ... sid=45 ...;
transaction-start xid=59 ... sid=123 ...;
...
service-list-destroy sid=123
...
transaction-start xid=61 ... sid=45 ...;
...
service-list-destroy sid=45;
Note that service-list-create and service-list-destroy messages have
no "scope" other than OCP connection. They are, essentially, a
connection-global variables or objects. This gives us enough
flexibility to cover all cases. Yet, it is a relatively simple and
very efficient scheme.
What do you think? Does this address your concerns? Do you think a
services-for-images and services-for-executables example is
valid/common enough? Do you think that OCP MUST work over a single
transport connection?
Thank you,
Alex.