Subject: RE: SOAP and OCP

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 21 Apr 2003 09:35:26 -0400

Hi,
sorry for the dealy
see inline

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Thursday, April 17, 2003 4:58 PM
> To: [email-masked]
> 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

---

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

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.

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

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 22 Apr 2003 11:52:19 -0400

> SOAP/OCP and then SOAP over ... can be defined by anyone else.

I'm not convinced that this would be an attractive option, since it 
opens up again the issue of interoperability. I bet we'll see vendors 
implementing "OCP over SOAP over A" and other vendors implementing 
"OCP over SOAP over B", thus not being able to interoperate.

We already see this happening in the SIP area, where some vendors only 
implement SIP over TCP, and others only SIP over SCTP - whether this 
is "allowed" by the standards or not...

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 22 Apr 2003 10:15:29 -0600 (MDT)

On Tue, 22 Apr 2003, Markus Hofmann wrote:

> opens up again the issue of interoperability. I bet we'll see
> vendors implementing "OCP over SOAP over A" and other vendors
> implementing "OCP over SOAP over B", thus not being able to
> interoperate.
>
> We already see this happening in the SIP area, where some vendors
> only implement SIP over TCP, and others only SIP over SCTP - whether
> this is "allowed" by the standards or not...

Whether the above is truly an interoperability problem depends on
whether a "TCP vendor" actually wants to interoperate with the "SCTP
vendor". I do not know whether OCP really needs multiple transport
protocols, but I can imagine a situation where a certain callout
server supports only one transport (out of several available) and
causes no interoperability problems because it supports the only
transport that makes sense for its kind of services.

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 22 Apr 2003 13:38:01 -0400

> transport that makes sense for its kind of services.

I agree in theory, but fact is that this complicates interworking in 
real life. Some services won't clearly dicted a specific transport, 
i.e. some services can potentially be run on top of different 
transports. If you now have vendors with different preferences, only 
supporting their prefered transport (for whatever reason), these 
vendors simply won't be able to interwork with each other - that's an 
interoprtability problem.

I agree - I also don't yet know whether OCP needs multiple transport 
protocols. But this should *not* make us conlcude that there 
definitely will be multiple such bindings and design the 
system/protocol accordingly. Maybe on transport binding is sufficient, 
and we would end up with a clearer picture?

-Markus