I am quite disturbed by the lack of modelization of all this. I do not
really understand what an OPES means to be as I understand it starts as a
very general process (modification of the data flow) but limited to a
peripheral architecture (edge) and to a very limited set of protocols.
My personal reading of this is that OPES belong to what I call for years
"open network extended services" (ONES) that I specified, operated and/or
sold some for nearly 20 years over various environments (pubic net, X.25,
Minitel, fax..).
The notion of callout protocol is exciting because it permits to
standardize things I ran on a per application basis and to interoperate
with third party services.
But I am afraid that lack of modelization (where does all that fit in the
OSI or an extended OSI model) leads to some confusion between different layers.
I suppose everyone will accept I suppose there are at least two global
layers involved;
- a layer concerned by the object transportation aspects (I suggest
Hardware + layers 1-7 OSI)
- a layer concerned by the interapplication levels and above (operators,
decisions, etc) (I suggest above OSI)
To respond to your suggestion I would suggest:
1. we take advantage from the different propositions (XML, SOAP, ...) to
understand what the web service (and others) layer provides making a
difference between what is common to all of them ...
2. and we take advantage from the features each of them to decide if
- it is something we would expert from the other too (so it should be
added to the socket)
- of if this is something something belonging to the callout protocol
level.
3. from then on we can list all what they contributed to what is specific
to a callout protocol and what is missing both in a strict OPES environment
- and in the more global ONES environment (what should help us not to miss
possible extensions).
This should result in a fairly good description of
- which "transport" protocols are possible to use
- how to plug them in
- what some protocol should support to become OPES compatible.
- the specification for any compact or more specific inter-ONES
transportation protocol
- the description of the callout specific functions.
Let take the two maximum cases Hilarie and you consider:
- two CPU interacting together under QNX in the same rack
- two web services by different operators on different continents through
the internet
SOAP may not be the best solution in the first case but mandatory in the
second one. Yet the metadata to be exchanged to perform the service will be
the same (except that dialog/signaling will demand probably a
synchronization adapted to each). Telematic synchronization/decoupling of
the applications will probably be a very important issue in all this.
To come back on performance related points, I suppose it may be more
complex than just hardware considerations - two examples:
1. we will need to "receive" information that have not been sent. Very
simple example: every page of a site has a gif logo which may have to be
changed in jpeg. The protocol should be able to say "I do not transmit a
data you will read where I told you to store it" and to handle the error
case and verifications..
2. we should be able to zap data. Example: a security control center
becomes overloaded by the data pouring in from a blown-up plant. An OPES
extracts and format data for the remote controller of a door. Delayed infos
tell that the door flaps. The system reacts adding to the traffic, while
there may not be any door anymore. All that junk information should have
been zapped.
jfc
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03