Hi,
sorry for the dealy
see inline
Abbie
-----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