Abbie,
Can you point me to specific specs describing "binary"
(opaque, really) data transfer capability of SOAP (or XML)?
Also, you mentioned previously that we should consider SOAP
because web services use SOAP. I would like to make that statement
more precise so that we can evaluate this advantage. If OCP is built
on top of SOAP, do you expect any existing web services to be able to
act as callout servers "as is", without _any_ modifications? Or do you
expect modification of existing services to support OCP-over-SOAP to
be "easier" than similar modification to support OCP-over-notSOAP?
Thank you for the other two clarifications. It looks like BEEP
provides similar features with respect to the transport protocol
selection and even better (more direct) features for connection state
management.
Alex.
On Mon, 21 Apr 2003, Abbie Barbir wrote:
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Thursday, April 17, 2003 4:58 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: SOAP and OCP
Abbie Barbir argued that OPES processors should support SOAP
as a foundation of OCP. Abbie, I think it is time to resume
that discussion in the OCP transport light/scope. I have
three basic questions:
1. SOAP is not a transport protocol. Would you
require a specific transport protocol to
be used if OCP is implemented using SOAP?
For example, would you require that BEEP/TCP and
only BEEP/TCP is used under SOAP?
Yes, but there are bindings defined for SOAP (like HTTP, BEEP ?). No
we will not require specific bindings. We have agreed that this OCP
draft basically define metadata/state machine for OCP and that
bindings will be defined later. IF we use SOAP, then SOAP can have
its own bindings. This way we define SOAP/OCP and then SOAP over ...
can be defined by anyone else.
2. My understanding is that using SOAP pretty
much requires XML message format/encoding for
OCP messages. How do you suggest we implement
OCP data pipeline with SOAP? More specifically,
what is the best way to transfer, say, a 900KB
"binary" stream from OPES processor to callout server?
Single large SOAP message? Multiple small messages?
How to encode binary data?
SOAP can have various ways of encoding binary data and in general it
is not efficient. However, SOAP 1.2 support attachements. Mesasges
can be frammed/fragemented etc.. by the SOAP over xxx protocol.
XML must be used, but we can have a core XML set that can be parsed
quickly. Yes there will be overhead and Yes we can try to minimize
it.
3. Does SOAP allow for SOAP "connections" that are
mapped to transport connections of some kind?
If we do not have access to transport connections,
how do we keep state and avoid constant
renegotiations? How do we guarantee that two
messages to the same callout server IP address
end up at the same server (as opposed to being
NATed or load-balanced to different servers)? Do
we care about IP not being sufficient to identify
a real server?
SOAP will run over another protocol. So the answere here is a
function of the underlying protocol. IF we ignore SOAP for now, you
still need to answere the same questions if you are using HTTP over
HTTP (something like ICAP). So basically, there is no reason for not
be able to do with over SOAP/....
I think SOAP can be a very good match, since, we can define SOAP
over any of the transport (I am using it here in general terms like
HTTP, BEEP, SIP, SMTP, FTP, etc..).
Using SOAP can really make our job much easier, since the underlying
protocol can be defined by anyone.
Abbie