Discussions

EJB design: XML-based architecture for multi-tiered applications

  1. Hi,

    What do you think about using XML to pass data between the server and the client?
    This architecture is used on my current project and it works pretty well. Data is extracted from the db using its XML query functionality (supported by MS, Oracle and possibly others). There are no entity beans, only the session ones. All the methods of the session beans take as the parameter and return XML.

    Scenario:
    1. Client app requests data (eg person details). It calls Person.getPerson (ID)
    2. Client app receives XML string containing all the relevant details about that person and populates its fields accordingly.
    3. Client app updates the person details. It creates an XML string from the data in its fields and calls Person.updatePerson (xmlString) method.

    Advantages:
    - No entity beans and the performance problems associated with them
    - Easy maintanability: If you want to add one more field to the form then you'll have to change the stored procedure that retreives the information and the client. No need to recompile the beans or the 'Data Objects'.
    - Easy to represent complex tree-like structures with XML (eg master-detail).
    - No need to write BMP Entitiy beans or initialise data objects from resultsets.


    Disadvantages:
    - Need to parse XML on the client which adds a little to the complexity of the client code
    - The stored procedures' syntax is a bit convoluted in order for them to produce XML
    - Business logic could be spread between the stored procs and the session beans, with most of it residing in the stored procs.
    - Strong DB vendor tie-in
    - Higher network bandwidth consumption


    Further Improvements:
    - Use of JAXB to automatically bind XML to java objects.
    If done on the client side, then the XML received is parsed automatically. Potentially, could be used in the business objects tier instead.



    Please let me know what's YOUR opinion on this approach.

    Regards,

    Alex

    PS This is a copy of the message posted earlier to the XML forum
  2. IMHO, this architecture negates the whole idea of business objects. Instead of putting the business logic where it should sit - in the middle tier - you are sticking it into the database!
  3. We have used roughly similar techniques on a project but did map between XML and business objects within the app server. We started work before JAXB was about, so developed our own utility for mapping.

    Luckily we already had a utility that had been used for C applications to generate database access code and that was modified to generate both mappings between business objects and DAO objects (we have mostly used Session EJBs that directly interact with the DAO - and business - objects) and between business objects and XML.

    Generally this approach has been successful and performant. It also offers the possibility of easy integration with SOAP/WSDL/UDDI etc. at a later date.