And just what is the nature of the M$ code? Sun's Lee said while SOAP supports XML and HTTP, the protocol, as it stands, does have some proprietary software code because it was developed mostly by Microsoft.
SOAP doesn't rely on any proprietary technology. The SOAP/Perl bits run on Linux/Apache with no black magic from M$. The Java bits also don't require any M$ software. Sun's Lee is obviously misinformed.
I'm not entirely happy with SOAP either.. but for different reasons. It seems just a smidgen more complex then XML-RPC but I don't see any significant advantage over the latter. XML-RPC works just fine for me and it's just as cross-platform.
I see two major technical advantages to SOAP.
It spec's a set of HTTP headers to make it more firewall friendly.
It easily supports multi-reference data/cyclic data.
The latter is important for supporting serialized Java object graphs (I leverage the hell out of it right now).
I'm not happy with SOAP. - It's too much RPC and not enough distributed objects. They support the concept of session/transaction IDs, (although these seem nicely spoofable). But the persistence model is too weak and object refs are not explicit.
I'm sorry you are not happy with SOAP. Your comments are interesting. Here's my take on what you stated.
SOAP deliberately doesn't mandate object semantics. It also doesn't prohibit it. SOAP also doesn't explicitly support session or tx IDs. I am not sure you are reading the same spec I worked on (we used a tx id as an example application for protocol extensions but by no means mandated or even spec'ed them).
As for objrefs being explicit, I'm not sure what you mean. URLs are pretty explicit in the HTTP protocol and they are in essence our objref format. As for server-side persistence, SOAP isn't trying to mandate a CORBA-esque (or COM-esque) programming model, just a wire protocol. It would be trivial to layer a POA on the back end (RogueWave/Neuveau are doing just that I believe).
As for tunnelling IIOP or DCOM over HTTP, these are PROPRIETARY solutions and I don't know if any orb vendor has implemented the OMG spec for dealing with firewalls in a shipping product.
Slashdot Mirror
Iona joins RW/Neuveau and is supporting SOAP.
Here's the link: http://www.iona-iportal.com/news/prsui te.htm
DB
Sun's Lee said while SOAP supports XML and HTTP, the protocol, as it stands, does have some proprietary software code because it was developed mostly by Microsoft.
SOAP doesn't rely on any proprietary technology. The SOAP/Perl bits run on Linux/Apache with no black magic from M$. The Java bits also don't require any M$ software. Sun's Lee is obviously misinformed.
DB
I see two major technical advantages to SOAP.
- It spec's a set of HTTP headers to make it more firewall friendly.
- It easily supports multi-reference data/cyclic data.
The latter is important for supporting serialized Java object graphs (I leverage the hell out of it right now).DB
http://www.develop.com/soap/soapfaq.xml
- It's too much RPC and not enough distributed objects. They support the concept of session/transaction IDs, (although these seem nicely spoofable). But the persistence model is too weak and object refs are not explicit.
I'm sorry you are not happy with SOAP. Your comments are interesting. Here's my take on what you stated.
SOAP deliberately doesn't mandate object semantics. It also doesn't prohibit it. SOAP also doesn't explicitly support session or tx IDs. I am not sure you are reading the same spec I worked on (we used a tx id as an example application for protocol extensions but by no means mandated or even spec'ed them).
As for objrefs being explicit, I'm not sure what you mean. URLs are pretty explicit in the HTTP protocol and they are in essence our objref format. As for server-side persistence, SOAP isn't trying to mandate a CORBA-esque (or COM-esque) programming model, just a wire protocol. It would be trivial to layer a POA on the back end (RogueWave/Neuveau are doing just that I believe).
As for tunnelling IIOP or DCOM over HTTP, these are PROPRIETARY solutions and I don't know if any orb vendor has implemented the OMG spec for dealing with firewalls in a shipping product.
DB
http://www.develop.com/soap/soapfaq.xml