XML Interface vs. RMI/EJB/Corba Interface


XML & Web services: XML Interface vs. RMI/EJB/Corba Interface

  1. XML Interface vs. RMI/EJB/Corba Interface (6 messages)

    Hi All,

    with the current XML and webservices trend people are thinking of designing component interfaces with XML schemas or WSDL rather than with Java interfaces or IDL. But even without SOAP an XML interface is possible:
    String myService(String pXML);

    I am not sure about which way to go, IDL or XML.

    By gut feeling I would design component interfaces in IDL or Java and use value objects to transfer data, but this might just be too conservative.

    The advantages of IDL/RMI:

    o no need to generate and parse XML at runtime
    o XML is alien to a programming language
    o efficient binary formats to exchange data
    o UML to design interfaces

    advantages of XML
    o readable wire data (but who wants to read that?)
    o XML schema has higher expression power than IDL (?), so
      you could do semantic checks on the parser level (but is this a good idea?)
    o decoupling of both ends, i.e. no need to keep stubs and skeletons in step

    Anyway, going from programming language to XML entails using a totally different paradigma, so I want to understand the consequences.

    Thank you for your input,
  2. Hi Juergen.

    You raised a very interesting point. I agree with most the points you made. I'd like to add a little about the last XML "advantage" which seems to be a very "popular" argument for XML interfaces:
    "decoupling of both ends, i.e. no need to keep stubs and skeletons in step"
    I don't think this is correct at all. It's nothing more than an illusion. Both sides need to be able to read/write consistent XML formats. They also need to be able to access XML data written in that format. This means that, bar extraordinarily complex "meta-programming", both sides are hard-wired for one specific format. They are just as coupled as the RMI parties, only the coupling hides behind the way you parse XML. You still have "stub-like" classes that are specific to your server, only you generate them yourself (or using an XML binder) rather than have them generated for you. I also want to note that RMI can do remote loading of stub classes.

    About the expressive power of an XML schema, I think it is important for some types of information, but that's usually not the kind of information you would need. It's important for relatively free-form data like HTML or other document formats. For describing object models, the additional expressive power is not that important, IMHO. The boundary checks that an XML schema can do are also important, but do you really need it when you have two communicating RMI parties? You usually have two instances on both sides that are guaranteed to be valid (given you program your classes that way).

    To conclude, I think SOAP is good allmost exclusively for communicaing between two different, "alien" systems. If both systems are in the same company and both use Java, I would go ahead with RMI without a lot of doubts.

  3. Thanks Gal for your interesting opinion.

    Thinking more about the subject, I found other arguments:

    Using XML as value objects, like in String myService(String pXML);
    it should be faster to transport a single big string over the wire than to marsal and unmarshal an object net. But on the other hand there is the time spent in the XML parser.

    Concerning XML schemas' expressive power, I doubt if XML/schemas are the place to express business rules. I have no practical experience with schemas, but what happens if there is a violation of a constraint in a schema? I'd expect the parser to throw an exception which could not be caught in a reasonable way until up in the application layer. This means there also has to be a sophisticated error handling layer in the application which is redundant to the constraints in the schema.

  4. Juergen,

    I find the idea of passing XML around as Strings to be pretty senseless. You didn't save yourself any time if the server is going to be using this String: it would have to parse it anyway. You would probably get better performance passing a parsed DOM tree. You can even pass a SAXSource or DOMSource and then use the two polymorphically. Note that if you don't have the strings parsed on the client you don't have to parse it: you can make a sax source that references the unparsed string.

  5. I've done some testing a few month ago:
    With 2 weblogic server, I implement some simple test:
    the first one: communication between ejb and web application with rmi
    the second one: communication between 2 web application, one use a business container (servlet were used to send and receive xml) and the second one as a real web app.

    My test was to transfer simple JavaBean Object or collection of object.

    And the best was with rmi. I've done some benchmark, and the longest is to read xml to recreate the object. (write xml was quite fast and transfer the xml file was really fast).

    hope it will help you
  6. Hi,
       I think that the XML/Webservices is just a wave, a way to create demand for new(?) products/services.
       Some many people are using SOAP 'cause it is 'more readable' but the systems don't need "human readable
    data format" , only us , humans.
       I think that IDL , or ILU or another meta-language a great way to define objects
    'cause you're not tied in one language but if you plan to use only java , RMI goes fine for the
    most cases.
  7. We ran into the same question with a remotely called application I recently architected.

    What we found, and maybe your experience is different, is that we're in the business of trading off between performance and deployment headaches. If we went XML/web services we got worse performance, but fewer coordination problems between apps when we deployed new code. If we stuck with Bean-2-bean calls (which use RMI), we got better performance, but several other applications have to recycle when we redeploy.

    Our experience is that the difference, for what we are doing, is 300-500ms. In the future, I'm only going RMI when I can't afford the extra fraction of a second (which is rarely).

    I hope this helps.

    Derek C. Ashmore
    (Architect for ThreadWorks)