I don't see how SOAP has anything to do with component technology. It's just a simpler RPC wire protocol than the fiercely competing alternatives (IIOP, DCOM, RMI, etc.)
I noticed that MS felt the need to implement a new HTTP method called M-POST
M-POST isn't just an MS thing. Check out the spec at the W3C. H. Frystyk Nielsen (W3C) is the lead author. Both he and Paul Leach (of MS) were on the HTTP 1.1 spec as well.
It might actually make sense to use SOAP as a new transport mechanism with CORBA. Coders would get to keep their language bindings and their existing code base, and CORBA would get a more or less standard way to travel over HTTP (which is the whole point of the SOAP excercise. HTTP means that every firewall will understand it)
Agreed. SOAP is intentionally simple and as nonobtrusive as possible. I'd like to be able to make SOAP calls to objects whose runtime is CORBA, Java, COM, Perl, etc., from any CORBA, Java, COM, Perl, etc. runtime. SOAP is so much simpler than DCOM, IIOP, JRMI, etc., and it really just codifies the existing practice of transmitting XML over HTTP, which lots of folks are already doing. If folks are going to ignore it just because some MS guys are on the spec, then I think that's rather sad.
As for M-POST, if you check out the spec I linked to above, you'll see that it provides a sane way for firewalls to filter based on HTTP headers. SOAP uses M-POST to be firewall friendly (it's easy to block all SOAP requests, or just certain ones depending on its endpoints or the logical type of the request; i.e., the interface or method name).
I was one of the first implementors of SOAP. My implementation is pure Perl and runs on Linux/Apache as well as any other platform that supports Perl - see http://www.develop.com/soap.
I don't know what Lee is talking about when he says "[SOAP] does have some proprietary software code". SOAP is just a simple protocol that uses HTTP to transmit XML in a traditional RPC-like request/response pattern.
Lee's statement about folks grudginly using CORBA because it's tricky - I've heard exactly the opposite from friends using it. I wish folks would stop adding fuel to the object war fires.
Slashdot Mirror
I don't see how SOAP has anything to do with component technology. It's just a simpler RPC wire protocol than the fiercely competing alternatives (IIOP, DCOM, RMI, etc.)
M-POST isn't just an MS thing. Check out the spec at the W3C. H. Frystyk Nielsen (W3C) is the lead author. Both he and Paul Leach (of MS) were on the HTTP 1.1 spec as well.
It might actually make sense to use SOAP as a new transport mechanism with CORBA. Coders would get to keep their language bindings and their existing code base, and CORBA would get a more or less standard way to travel over HTTP (which is the whole point of the SOAP excercise. HTTP means that every firewall will understand it)
Agreed. SOAP is intentionally simple and as nonobtrusive as possible. I'd like to be able to make SOAP calls to objects whose runtime is CORBA, Java, COM, Perl, etc., from any CORBA, Java, COM, Perl, etc. runtime. SOAP is so much simpler than DCOM, IIOP, JRMI, etc., and it really just codifies the existing practice of transmitting XML over HTTP, which lots of folks are already doing. If folks are going to ignore it just because some MS guys are on the spec, then I think that's rather sad.
As for M-POST, if you check out the spec I linked to above, you'll see that it provides a sane way for firewalls to filter based on HTTP headers. SOAP uses M-POST to be firewall friendly (it's easy to block all SOAP requests, or just certain ones depending on its endpoints or the logical type of the request; i.e., the interface or method name).
I don't know what Lee is talking about when he says "[SOAP] does have some proprietary software code". SOAP is just a simple protocol that uses HTTP to transmit XML in a traditional RPC-like request/response pattern.
Lee's statement about folks grudginly using CORBA because it's tricky - I've heard exactly the opposite from friends using it. I wish folks would stop adding fuel to the object war fires.