SOAP just gives us a way to agree on how to get a message from point A to point B, with the semantics of invoking a procedure. What goes on at the receiving end, that is the place where the service is, may be implemented with J2EE or COM+ or other menas to actually do some work. So they are not necessarily competing.
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
Soap is now a little bit clearer for me.
Originally posted by Kyle Brown:
SOAP isn't a competitor -- it's a complement to J2EE. SOAP doesn't specify how the objects on each end are implemented -- J2EE provides that. SOAP specifies a vendor and language-transparent protocol for messaging -- J2EE needs that for interoperation with anything else (including interoperation between different J2EE vendor's containers) I don't think one will replace the other.