Leaving SOAP as an option

Discussions

XML & Web services: Leaving SOAP as an option

  1. Leaving SOAP as an option (2 messages)

    Hi All,

    We've concluded that while SOAP looks _very_ promising for some of what we want to do with our EJB application, it's too steep a learning curve for us to adopt just yet. So what I want to do is make sure that my J2EE design leaves the option of adopting SOAP open for the future.

    Here's how I've got it: we already have one Session Bean that provides an XML interface to any other method in any of the other session beans (through a custom-built XML marshaller/serializer, kind of like Castor). Our web layer communicates with this bean and uses XSL to format data in both directions. It works well, though I suppose that optimizing is going to be a lot of fun later on. As I see it, when we need SOAP, I can just build a SOAP interface that attaches to this Session Bean.

    But is there anything I should look out for in the architecture design that will make it easier to adopt SOAP later on?

    Many thanks,
    James

    Threaded Messages (2)

  2. Leaving SOAP as an option[ Go to top ]

    One thing to keep in mind that SOAP comes in two styles of processing: SOAP-RPC and SOAP-Messaging.

    The messaging style is typically asynchronous in nature and lends itself more closely to MDBs.


    francis!
  3. Leaving SOAP as an option[ Go to top ]

    The easiest way to make sure of being SOAP compliant, as far as I see it, is to expose your functionality in one facade bean.
    If/when integrating your app. with SOAP all you need to do is to map the methods in this facade to the SOAP Servlet and you have built a SOAP compliant app.server.
    Just my 2c
    /Henrik