Opinion: Why Use SOAP?

Discussions

News: Opinion: Why Use SOAP?

  1. Opinion: Why Use SOAP? (55 messages)

    Artima.com has published an article by Frank Sommers comparing SOAP and application-specific XML for web services interaction, which suggests that for many web services, SOAP is overkill.

    Read: Why Use SOAP?

    Here's an excerpt:

    For many Web services, you need only a combination of XML, HTTP, and an application-specific message protocol. To be sure, SOAP has its uses. But, in my opinion, SOAP's role is overstated in the early stages of a Web service's development. Using SOAP for the wrong tasks can easily hijack a Web service development project, because SOAP introduces a large set of problems that are orthogonal to the challenges of building a Web service. SOAP-related issues tend to consume the majority of the development effort.

    Question: Are many of you using web services in an informal way (HTTP + XML) ?

    Threaded Messages (55)

  2. REST[ Go to top ]

    REST is part of this anti-SOAP thinking thats out there.
  3. ;-)
  4. REST[ Go to top ]

    REST is part of this anti-SOAP thinking thats out there.


    Thanks for the link, Chad. I was not aware of REST, though I remembered reading the xml.com article once I re-read it.
  5. REST[ Go to top ]

    REST is part of this anti-SOAP thinking thats out there.


    I have worked with both the REST and SOAP-based Amazon Web services interfaces when building the JavaShelf.com Java bookstore. Here are my feelings based on that experience:

    REST:
    + Easy to test your queries by typing the URL in your favourite Web browser.
    - Name/value pairs may be too crude to handle complex queries.
    - People forget that URLs need to be encoded too!
    - You are handling the low-level HTTP communication stuff yourself.
    - You are handling the XML message parsing yourself.
    + You have more control on "what happens" and how.

    SOAP:
    - More heavy to test. You need a "sniffer" to have a look at the XML messages.
    + When you have access to a WSDL file, tools are available to generate proxies that handle all the low level stuff in collaboration with the SOAP runtime: connecting to the server, sending the XML messages, handling XML to Java and Java to XML deserialization and serialization, etc.
    - You have less control on "what happens" and how (black-box effect).

    All in all, I have found the SOAP approach more easy and quick in term of development time (I have to confess that I am using SOAP for several years). However, I lost time with SOAP at deployment time because of a dependency on a DOM level 2 feature that was not available to our Tomcat instance (still a 3.2.3 release).

    What I don't like with REST are the falacious arguments their promoters use and their general "the others are stupid" attitude (with terms like "anti-SOAP", for example, if you see what I mean). Let me cite a few points that come in mind:

    a) REST guys contribute to the (mis)perception that SOAP is an RPC-style system only. This is wrong: SOAP supports both RPC-style and document-style approaches. UDDI is a very good example of document-style SOAP system.

    b) REST guys say that SOAP is reinventing the wheel and that some tasks may be implemented "simply" using the PUT and DELETE HTTP methods. They forget to say that these methods are most of the time disabled from Web servers for security reasons.

    c) REST guys say that the SOAP envelope is just overhead. They never talk about things like XML signatures. Maybe are they going to put them in HTTP headers as well? (just kidding).

    I would say that if you don't know SOAP, REST will be faster to get started with. Just imagine that you are generating XML pages instead on HTML pages and you are started. If your queries are too sophisticated to be expressed using name/value pairs, go the SOAP route directly.

    In what concerns XML over HTTP vs. SOAP, most I have said about REST still holds. Think about it: why would you drop the advantages provided by a SOAP runtime and tools that handle Java code generation from WSDL files to roll your own communication and parsing mechanisms? The title of that article should rather be "Why XML over HTTP?". Of course, these are just personal opinions...

    Bertrand Fontaine
    INSPIRE IT - www.inspireit.biz
    JavaShelf.com: Your Java bookstore on the Web!
  6. REST[ Go to top ]

    Bertrand, that was an excellent summary. Regarding sniffer tools, there are some really good tools out there, e.g. SoapScope. I actually like testing better using SOAP, since it allows easy automated testing with your proxy logging all incoming/outgoing SOAP traffic.
  7. web services based on REST[ Go to top ]

    Hi, I am a newbie. Please tell me the step by step procedure for how to create web services using REST. I have to use Technology JAVA. can any one ple provide an example so that i can understand. my email id is eeswari_k at yahoo dot com. Thanks in advance.
  8. SOAP is the standard - not IIOP[ Go to top ]

    It very much depend on the development platform you are using as to how complicated it is to implement and maintain SOAP based WEB services.

    We use SOAP based WEB services extensively (both client SOAP surrogates and servers) and are generally very happy with the approach (and so are our customers - which cover a large body of Britains exam boards)

    Cheers,
    - Madsen -
  9. Opinion: Why Use SOAP?[ Go to top ]

    Question: Are many of you using web services in an informal way

    >(HTTP + XML) ?

    nope, I havent. We used SOAP (JAX-RPC) to integrate J2EE app. with a desktop app. written in Delphi. IMHO It would be quite hard to agree about common XML structure without SOAP.

    Maris
  10. Why use XML?[ Go to top ]

    Use Soap because you are already using XML. i.e. you have already tied yourself to a slow, bulky standard BECAUSE it is a standard. Lets face it, there are many faster, smaller socket comms and RPC mechanisms that work - base 64 encoding is still the main asynch encoding (emails anyone).

    So the reason to use SOAP is that you like standards.

    It's a sliding scale of performance against 'modern' standards. There are older standards that work just as well - RMI etc. There are even tools to deserialise java objects - so cross platform is not even an argument. The argument is more about an instream human readable data format (cos there are loads of folks watching the wire...). Or perhaps an end to end data format with simple transform - and soap is part and parcel of that message.

    Jonathan
  11. Different uses[ Go to top ]

    This is an interesting topic which I think gets really short shrift. Looking at Axis, I see that so much emphasis is being placed on JAX-RPC - using XML and SOAP for fine-grained RPC operations. I agree that SOAP is total overkill for this type of thing.

    But where I think XML does offer some value is when you're dealing with coarse-grained operations where you're passing large chunks of XML that encapsulate what might normally be several individual RPC calls. In the Axis model, this would be the document-style, messaging use, which of course gets all of about 3 lines of explanation in the User's Guide.

    The SOAP standard is not clearly defined at all IMHO, and can be applied in many overlapping ways. I think the WS-I: Basic Profile is a good step in the right direction as it assigns delineated responsibilities for SOAP and for the schema you define for the actual business data being passed.
  12. Why use XML?[ Go to top ]

    <quote>
     The argument is more about an instream human readable data format (cos there
    are loads of folks watching the wire...).


    thats why we need to encrypt it and compress it to a binary format ;-)
  13. Why use XML?[ Go to top ]

    |
    |Use Soap because you are already using XML. i.e. you have already tied yourself
    |to a slow, bulky standard BECAUSE it is a standard
    |

    No. Not at all.

    You use SOAP and, more importantly, WSDL if you want a language independant interface (Many existing client apps are still C++/MFC or VB - and they need to make calls to a java-based server).

    Why not use IIOP? I guess that once you actually try and do this, it will become crystal clear.
    Using CORBA on the client-side is substantially less complex than on the server-side. However, its still quite complex and very error-prone.

    As most people have probably not tried using CORBA for C++ client integration, I will list some of the problems as I have seen them:

    1) You have to generate the IDL in the first place. Now, some tools do this quite nicely - others dont. Some you have to manually list all the interfaces and classes, which is tedious and error-prone.

    2) However, not even the best tools work 100% of the time - e.g. if you are using some kind of inheritance in your Value Objects (and your interface only declares the base-class) then you have to remember to MANUALLY generate IDL for each subtype - very error prone.

    3) Same problem again when it comes to exceptions. A Java Exception is mapped to a CORBA OBV type as well as a CORBA exception. Again, if your interface throws an exception baseclass, you will need to remember to MANUALLY generate the IDL for each exception subtype - even more error prone than DTO's.

    4) In your client C++, you have to register an OBV factory for each Value Object that you pass back (remember exceptions too) - very error prone.

    5) In end, if you have some problem (say, a Marshall exception) then not only is it difficult to work out where the problem is, due to lovely C++, but you cant really see what is on the wire that is causing it to blow up either. (THATS why people are interested in whats on the wire - when it goes wrong)

    6) No support for simple things such as Dates.

    Having said that, the SOAP picture on the C++ side is not rosy either. There are essentially 3 implementations to choose from: WASP, if you want to write C++ that looks nothing like C++ (zero usage of STL, and OVER-usaage of macros), RogueWave Persian, or open-source gSoap (which is more of a c-binding than C++)

    So, is the answer to use some custom socket library? Definitely not. In my experience, they are generally unmaintainable and usually the pet project of 1 developer (truck number?). If at some later stage you require a new language binding, you have to start from scratch at the lowest level.

    I personally think that WSDL, and the host of tools that support, it is the real key. It can be used to describe 1-way messaging or RPC interactions, its language undependant, and in the end it doesnt specify the actual protocol or the transport. So, SOAP messaging over MQSeries is quite a common and reasonable thing to do.

    So, sure, you can not use SOAP/WSDL because you think its too "standard".... or, if you want a language independant wire format and interface definition, you can use SOAP.

    -Nick
  14. Why use XML?[ Go to top ]

    "4) In your client C++, you have to register an OBV factory for each Value Object that you pass back (remember exceptions too) - very error prone. "

    I wrote a templatized factory that could do this for any type. It worked great.
    Very few lines of code.

    On the other points, though, you're right on. If an interface changes you have to go through the painful idl editing, idl2cpp, etc. Very painful.

    And it's oh-so-easy to create gobs of memory leaks.
  15. Why use XML?[ Go to top ]

    |
    |I wrote a templatized factory that could do this for any type. It worked great.
    |Very few lines of code
    |

    The point I was making was that if you forget to register a factory then your client will blow up at runtime (especially dangerous for Exception OBV's because you wont know until that exception is thrown)

    Does your factory address this? How did you manage to do it?

    -Nick
  16. Why use XML?[ Go to top ]

    Oh. You need to register it. The template I wrote, though, made it easy to do the registration.
  17. Why use XML?[ Go to top ]

    Having said all that (re CORBA clients stink), all of the problems could be solved if the vendors provided the tools to do it.

    The OBV factory problems are no different than those faced by SOAP client libraries - just that the SOAP libraries generate code to register the serializers/deserializers (OBV factories).

    The question is whether any of the C++ ORB vendors see it as a worthwhile investment of time/ resources to provide these features that are outside the CORBA and J2EE specs.

    -Nick
  18. Using CORBA/IIOP[ Go to top ]

    Nick,

    CORBA/IIOP isn't really "as bad" as you're noting, when used as prescribed. With CORBA, though, it's really pretty much mandatory that you *start* with the IDL and then implement the clients and servers. If you start with Java, and then use the Java to IDL mapping, you are in for a world of hurt. I really can't fathom why the Java to IDL mapping is so horribly bad -- it's obvious that a committee tried to jam a square peg in a round hole because it is chock full of details that really fly in the face of language transparency (valuetypes are really frowned upon by the CORBA community at large and they make up about 90% of the Java to IDL mapping).

    Where cross language Java and IDL are concerned, I recently came across a product from a company called ZeroC (http://www.zeroc.com) called "Ice" which does cross language C++ and Java and can use SSL for security, can integrate with firewalls, and supports persistence. If you're using Java but not EJBs it could be an interesting replacement (one of the many big knocks on CORBA was that it can't get past the firewall) for servlets/XML/HTTP/... It's quite a bit faster and can be point to point (it's also a binary protocol, fwiw).

    I've only been tinkering with it for a couple weeks but it's pretty neat so far -- most of the functionality I've needed without the complexity of CORBA *or* J2EE (the whole suite of which is overkill because I've mostly just used Java and servlets -- not EJBs).
  19. Using CORBA/IIOP[ Go to top ]

    |
    |CORBA/IIOP isn't really "as bad" as you're noting, when used as prescribed. With
    |CORBA, though, it's really pretty much mandatory that you *start* with the IDL and
    |then implement the clients and servers.
    |

    But that then means that you have to write your own server (either RMI or CORBA). Thats frowned upon generally.


    |
    |I really can't fathom why the Java to IDL mapping is so horribly bad -- it's
    |obvious that a committee tried to jam a square peg in a round hole because it is
    | chock full of details that really fly in the face of language transparency
    |(valuetypes are really frowned upon by the CORBA community at large and they
    |make up about 90% of the Java to IDL mapping).
    |

    Well, firstly, I dont go for the thinking that the spec writers were stupid. They wouldnt have created a bad spec on purpose and they wouldnt have done it by accident either. Its not pleasant stuff to work with because the problem isnt pleasant.

    The spec, in fact, is written in such a way that it is actually very simple to implement. That is pretty important if you want vendors to support it in a consistant (and portable) manner.

    I do believe that an improvement could be made by providing for a DTO mapping to CORBA structs rather than OBV's. That would have simplified it a little bit (what do you do with exceptions still...).

    In the end, my experience brings me to the conclusion that SOAP provides the best tools for this kind of integration. On the serverside you can use just servlets or session beans depending on your problem (neither of which requires writing your own server).
    The CORBA vendors could provide better code generation tools - ie self-registering OBV factories, providing C++ CORBA implementations of such things as java.util/java.sql Dates as well as Collections.... but I dont see a big market for it.

    -Nick
  20. Using CORBA/IIOP[ Go to top ]

    |

    > |CORBA/IIOP isn't really "as bad" as you're noting, when used as prescribed. With
    > |CORBA, though, it's really pretty much mandatory that you *start* with the IDL and
    > |then implement the clients and servers.
    > |
    >
    > But that then means that you have to write your own server (either RMI or CORBA). Thats frowned upon generally.

    As opposed to what? Writing the Java classes first, and then "CORBA-izing" them? That's basically going backwards of the principles of CORBA -- which is "provide an interface which is language and OS independent." Somebody implements the server, and provides the IDL to clients who use it. The problem is the approach IMO -- when you say "Here are some Java classes let's use CORBA to make them accessible to a client in a different language" you have already painted yourself in a corner, and you often see people asking questions which are "wrong" by the principles of CORBA -- things like "How do I represent java.lang.Vector in IDL?" which by its nature is NOT cross language.

    >
    > |
    > |I really can't fathom why the Java to IDL mapping is so horribly bad -- it's
    > |obvious that a committee tried to jam a square peg in a round hole because it is
    > | chock full of details that really fly in the face of language transparency
    > |(valuetypes are really frowned upon by the CORBA community at large and they
    > |make up about 90% of the Java to IDL mapping).
    > |
    >
    > Well, firstly, I dont go for the thinking that the spec writers were stupid. They wouldnt have created a bad spec on purpose and they wouldnt have done it by accident either. Its not pleasant stuff to work with because the problem isnt pleasant.

    I'm not necessarily sure they're stupid -- I do believe there were political wranglings about what "was" and "was not" the intent of CORBA and the spec was basically designed by committee and ended up being something which wasn't really implementable in broad scale for complex applications.


    > The spec, in fact, is written in such a way that it is actually very simple to implement. That is pretty important if you want vendors to support it in a consistant (and portable) manner.
    >
    > I do believe that an improvement could be made by providing for a DTO mapping to CORBA structs rather than OBV's. That would have simplified it a little bit (what do you do with exceptions still...).

    That might improve things a bit -- OBV is really something that about 90% of the "Purist" CORBA community thinks shouldn't even exist in the specification -- the fact that the Java to IDL mapping makes complete use of it definitely says something, doesn't it?

    > In the end, my experience brings me to the conclusion that SOAP provides the best tools for this kind of integration. On the serverside you can use just servlets or session beans depending on your problem (neither of which requires writing your own server).

    True -- My point is that using CORBA/IIOP *could* be a good/strong way of doing this *if* the mapping weren't so bad. As is, though, servlets/XML and SOAP are probably better solutions.

    > The CORBA vendors could provide better code generation tools - ie self-registering OBV factories, providing C++ CORBA implementations of such things as java.util/java.sql Dates as well as Collections.... but I dont see a big market for it.

    I don't either.
  21. Using CORBA/IIOP[ Go to top ]

    |
    |As opposed to what? Writing the Java classes first, and then "CORBA-izing"
    |them?
    |

    What I meant was that by starting with IDL, you have to write a CORBA server (and all the crap that goes with writing a server) rather than make use of a container - as EJB does.

    I understand what you are saying - but also, its not really reasonable to impose such a restriction that you have to start with the IDL - because evidently thats not where people start.

    |
    |the spec was basically designed by committee and ended up being something which
    |wasn't really implementable in broad scale for complex applications
    |

    So, how do you think it could be different?

    -Nick
  22. Using CORBA/IIOP[ Go to top ]

    |
    |because evidently thats not where people start
    |

    I meant to add:

    ... as is the case with WSDL. Not too many people start with WSDL - or want to.

    -Nick
  23. Why I Use SOAP[ Go to top ]

    I use SOAP because it allows interoperability between the Windows world and the Java world. I don't worry that it's XML under the covers - a good toolkit should hide that (although I have taken to hand-crafting my WSDL). I don't worry that it is verbose - my messages are small. And it's also "free" - no need to justify to management or customers the cost of an ORB.

    I'm not sure I'll be using a REST approach soon. I like REST as a philosophy but most software today is written in an imperative way rather than a declarative one - web services, for better or worse, seems to fit in with that. Even Tim Bray seems to think manipulating XML using modern programming languages is a pain:

    XML Is Too Hard For Programmers

    All the hype around web services is just that - hype. Interoperability is the key justification for SOAP. Everything else (business directories, workflow, etc.) is relatively unimportant to me at the moment.

    Ian.
  24. encoding and faults[ Go to top ]

    IMHO, there are two main reasons to use SOAP over XML/HTTP - SOAP encoding and SOAP faults. If you are just using XML, you still have to have agreement on the data encoding - XML Schemas will do most of this for you, but SOAP gives you additional encoding functions for arrays etc. SOAP faults are a way to handle exception handling back to the caller.

    You could use XML-RPC (the precursor to SOAP, also written by David Winer(sp?))
    which handles the encoding for you, but not the exception handling.
  25. Opinion: Why Use SOAP?[ Go to top ]

    In two small but important projects we had to use non standard Web services protocol. but used our proprietary XML messages over http: that because we had to integrate two legacy applications (one was a desktop application and the other a Mainframe legacy app); SOAP was not supported by the tecnology the desktop app was written in (Power Builder); so we choose dto adopt a simple XML format for our messages. This solution worked very well, but if possible, I'd still prefer to write standard SOAP-based web servicess.. tools like Glue make it very easy..
  26. Opinion: Why Use SOAP?[ Go to top ]

    PowerBuilder can use COM, MS soap toolkit has it.
  27. Opinion: Why Use SOAP?[ Go to top ]

    PowerBuilder can use COM, MS soap toolkit has it.


    Yunfeng, this is a very well kept secret :-)

    Unless you are forced to really integrate apps from diferent environments, you fail to realize the power of COM And SOAP rpc. And if you are not forced, you have the liberty to say things like overkill, poor performance, etc...
  28. In Other News...[ Go to top ]

    Frank Sommers also concluded that for the majority of Java applications, the virtual machine introduces completely unneccessary levels of overhead, and added complexity to applications.

    Frank recommends coding your applications in Assembly, and only porting them to Java later if the need arises to introduce a complex virtual machine.

    Trust Frank on this one. In 20 years we will be laughing about these so-called 'virtual machines' the same way we laught about agents and virtual reality.
  29. ...virtual machine[ Go to top ]

    I think you need to go back the definition of "virtual machine". Virtual machines
     are not a concept unique to Java, I remember my computer architecture professor
    explaining them to me long before Java existed. Providing an abstraction layer reduces complexity for the many and reduces software faults.

    Don't forget your assembly code relies on someone elses microcode...
  30. If every company used there own network protocol, there woulod be no open networks. I mean this guy is silly. he creates a simple XML document and compares it to a SOAP one, but I can make my own XML doc pretty complex if you give me time. If you need to send just data, then SOAP non RPC style is simple enough to use. Using SOAP for Web Services is like eusing IIOP for EJBs. If you don't like it use t3 like WebLogic. Using common protocols enables tool providers to have a common format.

    Also, he is missing the big picture about tool providers being able to integrate for RAPID deveopment.
  31. Message oriented SOAP[ Go to top ]

    There are two ways to do soap
    * Message oriented SOAP
    * RPC Oriented SOAP
    The latter is more polular, But still there are Inter-operability issues with that. The first one gives more flexibility, and it can be used for Request/Response kind of web-service without worrying about encoding. SOAP already takes care of what the auther has descibed in a native XML+HTTP model. It is better to use Message oriented SOAP than re-invent the infrastruture.
  32. I agree. Also, what happens once the plethora of WS standards that utilize the soap header gain more traction? To utilize any of these features with vanilla XML over HTTP or xml-rpc, you end up having to reinvent the wheel and push the data or context into the space of the xml docs you are sending, adding elements that may define things like security, routing, transactions, etc., then I would imagine one would start wondering whether any of this information really had anything to do with the original structure of the vanilla xml, and you start re-inventing the wheel again.
  33. SOAP Justification[ Go to top ]

    I completely agree that using SOAP for the RPC way is very seldomly justifiable. If you have control over both client and server, you can just as easily use IIOP (with or without using EJBs, simple RMI clients/servers and CORBA). But to replace SOAP with a hand-crafted XML over HTTP protocol is, in my opinion, just like replacing IIOP with your own, hand-written socket-based protocol - stupid.

    Using SOAP gives you so much more support during development that the performance overhead - remember, compared to a proprietary XML/HTTP solution - is simply not worth the trouble.

    Apart from that, I believe that REST has a lot of very good parts; but I believe that the REST philosophy is going to influence SOAP and other WS standards - there is simply too much industry support (read: "Hype" and "Marketing Dollars") behind SOAP for it to become replaced by something else.

    Stefan
  34. IIOP on port 80.[ Go to top ]

    "If you have control over both client and server, you can just as easily use IIOP..." -- Stefan

    Is there an open source ORB that can operate solely over port 80?
  35. RPC vs Message oriented[ Go to top ]

    I am somewhat dismayed at the preoccupation with RPC oriented SOAP and the consequent lack of tools for message oriented calls.

    As an example, the JAXM/SAAJ apis, although appearing remarkably similar to DOM, don't implement any of the DOM interfaces and therefore can't be used by most if not all tools that are currently available for XML processing.

    If I want to do something more sophisticated than simply call a method on a session bean it's back to roll-your-own web services as far as I can tell.

    But in the end, the decision to standardise on something, anything, in the XML messaging space comes down to the desire for interoperability plus a dose of hype for good measure.
  36. I don't know why people often step away from a SOAP solution and do some "proprietary" HTTP/XML solution instead. It is not only about how to transport your data through a firewall, SOAP is more about tools that exist, so you don't even have to care about http and xml. Glue is a great example.
  37. Another great tool is WASP from Systinet.
  38. Why I use SOAP[ Go to top ]

    I use SOAP daily. My co-workers make me..
  39. I don't know why people often step away from a SOAP solution and do some "proprietary" HTTP/XML solution instead.

    What is so proprietary about HTTP and XML? Those non-SOAP solutions don't use anything else but those two standards. If custom XML schema is in your opinion proprietary, then one can't do anything "open" with XML at all (remember, XML is all about defining your own document schemas).

    > It is not only about how to transport your data through a firewall, SOAP is more about tools that exist, so you don't even have to care about http and xml. Glue is a great example.
    HTTP/XML also has quite some tools: java.net.* (adequate), jakarta-commons HttpClient (better), Servlets and a myriad of XML processing tools.

    Are they easy to use? If you exchange messages/documents, then they are the simplest thing that works. If you want do do RPC, definitely not. But remember, this industry has been trying to do RPC right for the last 20 years, but without any real success. Reasons for that (in an old, but rarely understood lesson, and it's coming from Sun): http://research.sun.com/techrep/1994/abstract-29.html
  40. The easiest thing for me to use are SOAP webservices, it takes about one line of code to consume one with either Glue/Java or webreferences/.Net.

    Why? Because I do not have to parse XML. I do not have to use a myriad of XML processing tools. All I need is the client stub, which got generated from my SOAP tool. Under the hood this might use HttpClient or whatever TransportClient. In most cases I don't care, because I should not care.
  41. many applications can be very well managed with least resources and least complications, easy maintainance without using EJBs. But i have seen people go for EJB more for fashion and looking "COOL" than anything else & then end up in maintaining it rest of their life. Simple Servlet-Beans-Http(session object) is more than enough for a lot of applications. And throw in some command pattern / Struts, you have a simple efficient scalable application ready.
       XML over http in a simple Form post format can also be used in many cases. There is no need to go for SOAP. At the same time, I agree that SOAP has its own advantages.
  42. HTTP + XML[ Go to top ]

    Question: Are many of you using web services in an informal way (HTTP + XML) ?


    Yes, we use it almost daily, mainly to integrate old applications, writen in environments which sometimes are hard to soap-enable.

    It´s important to note that not everybody has time or resources to learn all the details of the newer environments that make soap use productive. It´s worst when you have a big team, or a lot of legacy systems. But XML with http or even sockets is a very simple thing to grasp. And doing that could be a step to use/understand SOAP, that, after all, is just XML over http, with a standard protocol.

    Please, I'm not saying soap is dificult. However, to use it in the wrong situation, or without the proper tools can be a source of endless headaches, not always needed.
  43. JMS[ Go to top ]

    Why not use JMS to send XML messages.
    It guarantees delivery. I know it is a costlier solution, but very reliable.

    The biggest problem i have with SOAP is that , i do not know after sending my message, whether it was reached destination for sure.
  44. SOAP and JMS[ Go to top ]

    Please do let me know if you disagree, but I think there's a bit of a misconception out there that SOAP must be delivered over HTTP. I think that it's simply a common *binding* to use HTTP, but there is absolutely nothing stopping you from delivering SOAP payloads via JMS. In fact, JAXM provides an interface to do so.

    I believe that the original Apache SOAP implementation also provided an example of binding SOAP to SMTP.
  45. SOAP and JMS[ Go to top ]

    You are correct, and there is at least one proposal for a ws reliability that would utilize mom's/jms.
  46. Opinion: Why Use SOAP?[ Go to top ]

    Question: Are many of you using web services in an informal way (HTTP + XML) ?


    I am but one, but, I do.

    Much before B2B, B2C or web services, we used HTTP+XML and IIOP+XML to integrate vast systems in quite a few CALS projects and we have not abandoned the practice. We are an exclusively objects shop and SOAP with its RPC roots doesn't cut the mustard in quite a lot of our scenarios.

    Still, the real catastrophe is the UDDI (and WSDL). Locating a web service with a URI/URL is the best reason for continuing an informal approach.
  47. SOAP seems to heavy for J2ME[ Go to top ]

    Question: Are many of you using web services in an informal way (HTTP + XML) ?


    I am. I started using HTTP + XML before SOAP. Now I work in J2ME and SOAP seems too heavy for that environment. I like to use XML because of its expresiveness and because of the good tools on the server side.
    I think it is more likely that I will switch to a simpler text based format for messages rather than SOAP. I haven't taken the time yet to really get in to SOAP. Once I do I might give it a reconsideration.
  48. Don't expect phones and the other typical J2ME devices to be good at string processing. Nor SOAP, nor XML over HTTP are good choices, here. Rather, use application-specific protocols that keep string processing on the J2ME device minimum.

    Just my 2 (euro-)cents,

    Bertrand Fontaine
    INSPIRE IT - www.inspireit.biz
  49. Moore's law is working for J2ME devices too :)

    Right now you are definetly right. In production especially it makes little sense to use any xml messaging mostly because clients may end up paying for the extra verbosity.
    Things change quickly though - Motorola announced recently a device with 256 total memory, 3G is promising speeds better than Wi-Fi, operators already offer fixed rate data packages...

    There is actually a project for putting SOAP on phones and PDAs:
    http://ksoap.enhydra.org/project/aboutProject/index.html
    May be there are others too, I haven't checked carefully.

    It is more a question of whether SOAP will catch hold on the server side in business to business messaging. If it does we will use it in J2ME devices too.
  50. FYI, there is a J2ME Web services specification (JSR 172) on the way. Here it is:

    http://jcp.org/aboutJava/communityprocess/review/jsr172/index.html

    Bertrand
  51. Informal webservices versus SOAP[ Go to top ]

    Hi,

    I have seen both informal webservices, and SOAP based webservices used in a project. In the first case, a lot of time was spent on designing XML structures and designing and testing the protocol.

    In the second case, WSAD 4.03 webservices tooling was used and this was a total non issue. We got a WSDL file from the company whose expert system we were linking with, and 5 minutes later we had integrated with it ("it" being a WebLogic server).

    So to me it is clear: things like SOAP and WSDL are de facto standards, meaning there is tooling, meaning you would be foolish to "roll your own". At least I do not care to spend customer time on such an infrastructure issue.

    Cheers, Luc.
  52. Re: Opinion: Why Use SOAP?[ Go to top ]

    Question: Are many of you using web services in an informal way (HTTP + XML) ?


    Yes. ( See http://xml.coverpages.org/epp.html )
  53. XML Over HTTP is NOT SOAP[ Go to top ]

    Question: Are many of you using web services in an informal way (HTTP + XML) ?


    Yes we are using XML+HTTP. And I have used it in 2-3 projects. And after using them, I prefer to go with SOAP.

    In the environment where you do know your clients, XML + HTTP is very simple and easy to understand. REST works there. But in environment where you do NOT know your clients, it is safe to implement standards. Standards give very clear guidelines as how it should be implement. They are easily communicated to multiple parties. Also if you go with standards, you inherit its design. IT IS A MAJOR HELP. If you do not believe this, try analyzing the error messages from XML + HTTP WS. See their naming conventions of XML tags. See their grouping of tags. Sooner or later you will feel that if these WS implement a standard, they might be better.

    SOAP protocol is a very good starting point and WS should keep working towards standardizing.

    Parag
  54. Opinion: Why Use SOAP?[ Go to top ]

    I just want to make two points: first there are many soap tools out there, so encoding and decoding of SOAP message are not very complicated; second, for most of integrations, the processing of SOAP message is not the bottle neck.

    --Yajun
  55. Why use SOAP ???[ Go to top ]

    To keep the dirt away of course...

                    Yann
  56. Not so hard after all...[ Go to top ]

    ...even without the large number of tools available SOAP is not so bad after all. At least it sets some standards that would be very hard to agree on otherwise. My personal view is that while it's inherently very complex and flexible - like binding to different message delivery mechanisms - it lacks other things or creates even more complexity. For example there is no support for user sessions or user login at all, still automatic creation of SOAP stubs from WSDL is only available on a limited basis. In my opionion, it might have been more wise to keep simple things as simple as possible - currently I have the feeling it gets even more complex than CORBA but does still over a rather limited subset of its functionality.