ietf-openproxy
[Top] [All Lists]

RE: SOAP and OCP

2003-04-21 10:44:53


On Mon, 21 Apr 2003, Abbie Barbir wrote:

Try w3c (SOAP 1.2)
http://www.xml.org
http://www.xml.com/pub/a/2003/02/26/binaryxml.html
http://www.w3.org/TR/soap12-af/

OK. So it looks like we have at least two choices when it comes to
transmitting opaque data over SOAP. First, we can base64-encode it.
The "binaryxml.html" document argues that encoding is the right way to
go because it lets us stay within XML boundaries. On the other hand,
encoding is expensive (CPU and bandwidth wise). The second option is
to use MIME-like "attachments".

The worst part is that there is no "standard" way to transmit opaque
data over SOAP yet. Implementations use different approaches and may
not be compatible. Please correct me if I am wrong.

OCP is about exchanging opaque data and metadata. XML does not support
opaque data well. That is why SOAP does not support opaque data well.
From this point of view, SOAP is the wrong protocol to base OCP on --
the primary OCP function is not well supported.  Other factors may be
more important though.

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?


Yes, web services uses SOAP and this will allow OPES to be plugged
into that area (as opposed to be a competitor). The short answere to
your question about modifications is Yes. By definition a web
services once discovered and its description is obatianed is
immediatly interoperable. On the otherhand, a schema of OCP can be
written that could be used by the web services server that he will
use to become an OPES Callout server.

I am not sure I understand the answer. What does it mean to be
"immediatly interoperable by definition"? My understanding is that any
existing web service can already participate in an OPES system "as is"
as long as the OPES processor using the service supports SOAP.
However, such participation is outside of OCP scope because OCP is not
SOAP; OCP is a stand-alone protocol that has features not described in
SOAP specs. To support OCP, a web service must be modified.

In other words, SOAP may be used as an OPES callout protocol (from
architectural point of view). However, the protocol we are working on
(OCP), is not identical to SOAP (but can be implemented on top of
SOAP). Modifications would be required for existing web services to
support OCP.

Is my understanding correct? If it is, we may have a good compromise
available: treat both OCP and SOAP as possible callout protocols and
make sure that OPES framework is not OCP- or SOAP-specific.  OPES
implementations will use the most appropriate protocol for their
needs.

Comments?

Alex.

<Prev in Thread] Current Thread [Next in Thread>