Subject: RE: SOAP and OCP

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 21 Apr 2003 12:33:08 -0400

Alex,

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/

see inline
Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Monday, April 21, 2003 10:54 AM
> To: [email-masked]
> Subject: RE: SOAP and OCP
> 
> 
> 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?
> 

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.

> 	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.
 SNIP

Abbie

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 21 Apr 2003 11:44:53 -0600 (MDT)

> 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
> 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.