Discussions

J2EE patterns: JAXB/XML Value Object Design Pattern

  1. JAXB/XML Value Object Design Pattern (22 messages)

    One very disturbing trend that I have found with JDO and EJB 2.0 is simply the lack of XML support...

    Without getting into major .NET vs. Java arguments, Microsoft has implemented a very common sense design pattern that I am anxious to see present itself in the Java community.

    It revolves around ADO.Net, (Microsoft's first real solution to database persistence in my opinion). What basically happens is that the developer defines business objects using XML Schemas. The schemas are then compiled into binary objects called DataSets, (Kinda like JDO). However, there is a really handy dandy feature that allows you to marshall and unmarshall XML content from that object...

    In the Java World I would really like to see an even better implementation...

    - Developer defines XML Data Object with XML Schema, (This is already present in the JAXB specification minus the schema support. Only DTDs were supported last time I checked).
    - A JDO or Entity Bean then Extends or has an interface to this JAXB object.
    - All Persistence functions are managed by JDO or the Entity Bean...
    - The JDO or Entity Bean would then contain the XML Marshalling and UnMarshalling features found in JAXB..
    - A Value Object could be retrieved in binary or XML form from the JDO/Entity Bean Object.
    - A JSP could easily extract the XML Schema and XML Data from the Value Object and perform operations on it such as XSL transformations.

    I think that anyone reading this will say, "But you can already do that in Java..." This is true, Value Objects have been being used for quite some time and also XML patterns similar to this.

    My argument is essentially that a standardization of this pattern would be nice. For example, as far as I know, JDO and Entity Beans have no standard way for interfacing to JAXB objects... (Nor were XML Schemas supported in JAXB the last time I checked.)

    I have been implementing this design pattern for quite some time and it makes development a whole lot faster, (After you write the BMP Entity Bean...) It would be really nice if JAXB support was built into CMP Entity Beans and JDO.

    Am I completely missing something here? Is this pattern already supported in IDEs and I have been coding this stuff by hand for no reason? Please let me know...

    Thanks.

    Threaded Messages (22)

  2. JAXB/XML Value Object Design Pattern[ Go to top ]

    Not sure if this should be called a design pattern in the strict sense.
    Nevertheless, I think it would be interesting if you posted some more details about your pattern/implementation, since it could be quite handy for some use cases.

    Regards,
    Stefan
  3. JAXB/XML Value Object Design Pattern[ Go to top ]

    Thats woul be kick b***. If I understand you correctly.... It would be easier as a client to know how an XML/ValueObject will parse as an autonomous Java object vs. loading 7Mb of Java XML parsing libraries and stepping through a DOM or SAX API.

    I know nothing of M$oft but that sounds like a good feature.

    The only API I know is the SOAP message API, it is small and lets one manipulate just SOAP headers, methods, etc.(if I am understanding correctly...)

  4. JAXB/XML Value Object Design Pattern[ Go to top ]

    I am not exactly sure how I could further define this without using UML diagrams.... In short this is essentially how we have implemented

    this pattern in the past...

    To try and make this a little clearer, I will try to describe the non database version of the pattern...


    However, first I will state the summary so that the description may be easier to follow.

    /*****************************************************/
    Summary:

    The ease of use of this pattern is obvious...

    // Business Layer:


    // JavaMug is a proprietary class that we use instead of JDO or JAXB since they don't support this pattern.

    public class AccountData extends JavaMug {}



    // WebService is a proprietary interface that defines WebService contracts, etc...

    public class AccountService extends AccountData implements WebService {}



    // Presentation Layer:

    AccountService myAccountService = new AccountService();
    AccountData myData = new AccountData(myAccountService.GetAccountInfo());

    TranslationControl myTranslationControl = new TransLationControl("../XSL/AccountStyleSheet.xsl", myData);

    httpContent.append(myData.translate();





    /***************************************************/
    This is is the pattern without a business tier involved. (basically an XML/XSL Control pattern... Most people implement a caching mechanism

    of some sort....)

     
    - A JSP invokes a JavaBean passing in two arguments; an XML data file, and an XSLT source.
    - The JavaBean performs the translation using standard APIs and returns the new XHTML, (We use XHTML exclusively now), markup to the calling

    JSP...
    - The JSP then appends the content to the page...

    (As you can tell, all of the APIs to do this are already present within Java, (JAXP in particular, etc).






    /***************************************************/
    XML/XSL Control with Database Support

    A JSP or Servlet invokes a WebService which returns XML records from a database. (For sake of the argument this WebService is called

    AccountService and a WebMethod called getAccountInfo() returns all of the user's information in XML form...)

    Well, this is Microsoft's version... This is the exact C#.Net syntax.....




    /************************************************/

    // This is the control that performs the translation... I recommend a JavaBean...
    System.Web.UI.WebControls.Xml Xml2;


    // AccountService.AccountService is essentially a class that wraps the Soap Invocation of the AccountService WebService.... It contains all

    of the URL information, etc...

    AccountService.AccountService accountService = new AccountService.AccountService();


    // This class represents a Soap Header that eventually gets sent to the AccountService WebService....

    AuthenticationHeader accountHeader = new AuthenticationHeader();

    // This sets the properties in the Soap Header....

    accountHeader.userName = User.Identity.Name;
    accountHeader.ticket = Request.Cookies.Get(".ASPXAUTH").Value;


    // This sets the Soap Header in the AccountService Wrapper so that when the WebService is actually invoked the Soap Header information gets

    sent too....

    accountService.AuthenticationHeaderValue = accountHeader;


    // This is the cool part. This is ADO.Net. The GetAccountInfo() Web Method is invoked on the WebService and returns an XML representation

    of the data. AccountDataSet is an ADO DataSet that I created from an XML Schema... The .Net framework automagically casts the XML response

    into the AccountDataSet object.

    AccountDataSet accountDataSet = accountService.GetAccountInfo();

    // Now the following part is very convoluted because the .Net Framework does so much under the covers that noone really knows whats going

    on... What essentially happens is that the XML gets extracted from AccountDataSet and gets sent sent to the XSL transform Control.... The

    product is then automatically placed in the response object (I am not going to explain this here...)

    XmlDataDocument doc = new XmlDataDocument(accountDataSet);
    XslTransform trans = new XslTransform();
    trans.Load(Server.MapPath("../XSL/Account.xsl"));

    Xml2.Document = doc;
    Xml2.Transform = trans;


    /***************************************************/
    The point...

    It would be really cool to do something like this in Java...

    myJAXBObject = accountService.GetAccountInfo();

    ---------- or ----------

    myJDOObject = accountService.GetAccountInfo();



    /***************************************************/
    Unfortunately, as far as I know, none of the specification teams are trying to provide this support. (I sincerely hope I am wrong).
    what I have had to do instead is this....


    // I am using a proprietary DataObject which is essentially a mix of JDO and JAXB here... :(

    myProprietaryDataObject.setXML(accountService.GetAccountInfo());

    myTranslator.XSLSource = "../../XSL/AccountDisplay.XSL";

    // This is really crazy pointer operation is covered up to avoid copying XML Data Again...

    myTranslator.setXMLData(myProprietaryDataObject);


    // htmlContent is a StringBuffer object....

    htmlContent.append(myTranslator.translate());



    /***************************************************/
    This pattern is repeated again in the business layer...

    This is going to look really crazy because this is not a standard.
    As a matter of fact this is really EJB and JDO all rolled up into one... (Into what I believe they should be).

    We compile an XML Schema document into a regular Java class... This class has configuration data which is intialized on instantiation
    from an XML file that contains Database connection strings, Primary Key, Foreign Key, and constraint information for relationships...

    This object inherits a class called JavaMug... (Essentially a JDO like class on XML Steroids with database and transaction support.)



    // This class that gets created is:
    public class AccountData extends JavaMug {}



    We then can create two types of objects... One is a WebService EJB and the other is just a regular Entity Bean that does not comply with any

    specification. However, we do provide the interfaces that can be accessed by Servlets just like regular Entity Beans. We wanted some kind

    of portability).

    // We rarely use the EJB interface to the Business Object, (JavaMug), since the SOAP interfaces are much faster than CORBA and the lack of

    current EJB spefication support...


    public class AccountEJB extends AccountData implements CustomEJB {}
    public class AccountService extends AccountData implements WebService {}


    Obviously the implementations are not provided in this example.
    However, what happens is:

    - Our compiler tool takes a UML diagram or database table that shows instance fields and relationships and creates an XML Schema from it.
    - The schema gets compiled into our custom JavaMug object which provides the JDBC, JTS and XML support.
    - Creates the basic implementation for the WebService or Entity Bean providing the appropriate get/set methods...
    - One of the Methods provided is: getJavaMugVO(); which returns the parent object as a value object, (Binary and serializeable).
    - Another Method that is provided is: getXMLVO(); which returns the XML data as a value object, (StringBuffer).
    - In the case of a WebService all of the XML data is sent with the appropriate SOAP Headers and what-not...
    - Another nice feature is that you can instantiate these JavaMug objects from an XML document: AccountData myAccountData = new

    AccountData(XMLDocument); This also provides validation support based on the Schema that it was compiled with...




    /*****************************************************/
    Summary:

    The ease of use of this pattern is obvious...

    // Business Layer:


    // JavaMug is a proprietary class that we use instead of JDO or JAXB since they don't support this pattern.

    public class AccountData extends JavaMug {}



    // WebService is a proprietary interface that defines WebService contracts, etc...

    public class AccountService extends AccountData implements WebService {}



    // Presentation Layer:

    AccountService myAccountService = new AccountService();
    AccountData myData = new AccountData(myAccountService.GetAccountInfo());

    TranslationControl myTranslationControl = new TransLationControl("../XSL/AccountStyleSheet.xsl", myData);

    httpContent.append(myData.translate();

    I hope this clears things up a bit....






    /***************************/
    P.S PLEASE BECOME ACTIVE IN THE JAVA COMMUNITY PROCESS. www.jcp.org
    If anyone hasn't noticed, new standards are taking forever to be completed...

  5. JAXB/XML Value Object Design Pattern[ Go to top ]

    We use Castor to do the same except that we don't have to transform XML using XSL.
    We are waiting for XML Schema support in JAXB. I agree with you that use of XML as VO must be standardized one way or other.

    Ganesh
  6. JAXB/XML Value Object Design Pattern[ Go to top ]

    Where do you get Castor?
  7. Castor can be found at www.castor.org. It supports generating objects from an XML Schema and mapping these objects to the database using JDO. Castor is a more mature version of JAXB.
  8. JAXB/XML Value Object Design Pattern[ Go to top ]

    Oracle have something they call "Business Objects for Java"
    (BC4J) that comes as part of their JDeveloper (9i) product.

    I don't have first hand experience using this product, but
    from what I know of it, it uses XML files to facilitate
    object-relational mappings between database tables and CMP
    entity beans.

    If you're interested, you can find out more from Oracle's
    "Technet" site at:

    http://technet.oracle.com

    Cheers,
    Avi.
  9. Infact its pretty easy using JDEVELOPER 9 since it uses
    XML and SCHEMA objects to represent DATABASE data or snapshots as called in programmers perpestive.
    Its good tool where u can easily bind ur datalayer with
    XML and uses different patterns inbuilt to give diff
    customizable views.
    It also facilitates easy creation and management of EJBS
    also OCBJ and BC4J are the mirror of todays Patterns
    and Services.
    But one think is that the code generated at the back
    is fairly Oracle specific so if u want to merge the
    tool with different applications u should have to
    customize a bit.
    TO know more about it just visit technet.oracle.com
    a great sight for Oracle lovers.
    Regards
    Swapnil S
  10. JAXB/XML Value Object Design Pattern[ Go to top ]

    I completely agree with you on the use of XML Schema as the basis of code generation to produce Java (or C#, or C++, or other) Value Objects that marshal XML-based data.

    However...

    It seems to me that the intent of Value Objects is to provide a way to provide data in a Java-specific and serializable way, primarily to remote clients. The focus of these objects is only data, not behavior; one can think of them as pseudointelligent structures.

    I can't speak much to entity beans, as I have avoided using them since EJB 1.0, but I can speak to JDO persistence capable objects. These objects are intended to represent both data and behavior in your business domain. They represent the fundamental concepts in your domain, and they are fairly independent of process, fine-grained in nature, and only meant to be accessed locally. I would recommend using session bean facades and message-driven beans that manipulate JDO persistence capables according to a request-response paradigm, where the request and response objects themselves are manifested by code generated from XML Schema.

    The request and response schemas are driven almost exclusively by the use cases of your system, whereas the object model of the JDO persistence capables are driven by the analysis of your problem domain. While it is appealing to attempt to represent the state of all of your fine-grained objects, often that state would amount to the full closure of your graph of persistent objects; the decision of where you stop becomes arbitrary, and inevitably will not always be appropriate for some use case. Instead, let the use cases themselves serve as requirements and as drivers of the request and response schemas. When I first saw SOAP, with its request and response schemas, I noticed how cleanly this model works with it.

    If you do use XML Schemas to generate code, it is helpful to do a few things (in no particular order):

    1. Ensure that your XML Schema fits well into an object model. Don't use nested complex types (<xsl:element name="CreateOrderRequest"><xsl:complexType>...). Use complex types (<xsl:complexType name="CreateOrderRequest">...) to define types, and use elements that declare themselves to be of a given type (<xsl:element name="createOrderRequest" type="CreateOrderRequest">...).

    2. Consciously decide whether or not to use reflection during marshalling. If performance is of the utmost concern, you might consider having your code generator generate code that does its own marshalling. If code reuse is more important, consider having the code generator generate code to delegate the parsing to a reflection-based marshaller.

    3. Implement Serializable. This ensures that your Value Objects can cross the wire.

    4. Make the schemas self-contained to a reasonable degree. This is a consequence of implementing Serializable, and is important when working in an asynchronous, message-driven environment.

    5. Include object IDs. This allows clients to find objects referenced in the response schema for later display or manipulation.

    --Matthew
  11. JAXB/XML Value Object Design Pattern[ Go to top ]

    Have you looked at Castor? It has its own JDO and Java/XML implementations (which includes a XML to Java source generator) and it supports XML Schema.

    http://castor.exolab.org/

  12. JAXB/XML Value Object Design Pattern[ Go to top ]

    I just looked at the Castor site... This is very similar to what we have also done....

    Perhaps we could start another "Java Community" at Apache or somewhere to produce a real set of Open APIs... This way the community could manage the new technologies instead of letting the JCP sit on it forever.
  13. JAXB/XML Value Object Design Pattern[ Go to top ]

    We're trying something similar with Breeze (similar to castor) and Oracle's XSU. Haven't gone very far in to it though .
  14. JAXB/XML Value Object Design Pattern[ Go to top ]

    Enhydra's Zeus is yet another program that does things similar to Castor and Jaxb (http://zeus.enhydra.org/index.html). Zeus 3.1beta supports XML Schema (and DTD of course). And we have used both Zeus and Jaxb in our projects.

    I think the original message in this thread has a very good point. It really makes sense that these XML data binding frameworks lead to a standard way of marshaling and unmarchaling XML files to/from Java objects. Jaxb has the potential to be included into J2EE 1.4. But its progress is very very slow. Making persistent Java objects from XML documents seem a long way from standardization. I certainly want to hear more about it...
       
  15. JAXB/XML Value Object Design Pattern[ Go to top ]

    Excellent posting, its the kind of .NET and ONE comparisons I would like to learn about.

    Forgive my ignorance, but I thought that JAXB wasn't really available yet. How did you go about getting a reference implementation of JAXB?

    Thanks,
  16. JAXB/XML Value Object Design Pattern[ Go to top ]

    You can get JAXB here....

    http://java.sun.com/xml/jaxb/

    The WebServices stuff can be found here...
    http://java.sun.com/webservices/webservicespack.html
  17. JAXB/XML Value Object Design Pattern[ Go to top ]

    You might want to look at what was discussed in the XML aware value object thread:
    http://www.theserverside.com/patterns/thread.jsp?thread_id=10431
    Although it solves a somewhat different problem - there is much common ground.
    also see JDOM at:
    http://www.jdom.org/
    for an alternative XML API.
  18. THis pattern is exactly the same than I posted a few months ago. See the link:
    http://www.theserverside.com/patterns/thread.jsp?thread_id=8675

    I have followed the SUN pattern format, so it should be easier for blueprints aware engineers.

    I have not used JAXB since it does not support schema. Castor is once again an excellent framework. I am currently using it using their JDO implementation which is excellent !!

    Defining delegates and DAO Factories would allow to use any persistent backend engines (EJB vs JDO).

    JDO is much easier to learn than EJBs. Wrapping JDO objects into a Session Bean should achieve the same thing than writing Entities.
  19. Its interesting, your basic point is:
    You want a STANDARD WAY to get XML from xxx.

    Nothing wrong with that. Hope it happens.

    BUT, several things I noted:
    // We rarely use the EJB interface to the Business Object, (JavaMug), since the SOAP interfaces are much faster than CORBA and the lack of current EJB spefication support...

    REALLY? SOAP are faster than corba? i.e. using an ascii xml stream with dom/sax marshalling and schema checking is faster than corba. I'm amazed. Not sure I believe, but if you have done the comparison I guess I must.

    AND.
    >// Presentation Layer:
    >TranslationControl myTranslationControl = new >TransLationControl("../XSL/AccountStyleSheet.xsl", myData);
    >
    >httpContent.append(myData.translate();

    Surely the only point at which you need XML is at the point of translation. So all you actually need are value objects than can render themselves as xml. This means you can buy into EJB's and app servers, no need of bespoke introspection factories or whatever. All you need is the 'marshallToXml' call on the value object.

    This means value objects are still in use which use less bandwidth, can be reused and contain validation, can be serialised and use more efficient marshalling/unmarshalling.

    So, all your code gen has to do is produce value objects with the XML marshalling code in. Which is your original point I guess, you want the call to have a 'standard' name.

    Jonathan
    =================================================
    The LowRoad EJB code generator does all this and more...
    http://www.tallsoftware.com/


  20. Can I uses EJB to get some data from a XML file? My intention is that the Session bean would do some business logic and pick the correct stored procedure, and its parameters information from a XML file, ready to be parsed for db calling.
  21. I would suggest using Apache Xindice to get XML data into an EJB... But then again, this is what this whole threade is about. MS SQL Server 2000 and Oracle 9i do emit XML but again, there is no standard way of doing this.
  22. Yes,

    The SOAP interfaces that we use are much faster than our EJB/CORBA implemenations for several reasons.

    -We don't have to worry about an Object Broker.
    -Our SOAP messages are running over TCP and not HTTP at this point.
    -We are using the PULL technique for XML parsing instead of regular DOM/SAX methods.
    -EJBs are just slow. (Or hasn't anyone noticed?). The whole notion of the Application container being separate from the Web Container is ludicrous. Why? Certainly deploy them on several machines to improve scaleability but why implement the stupid EJB interfaces such as Passivate etc... There are much much better methods for going about doing this. If needed we could start a completely new thread about different techniques for persisting server side state.

    We usually use one of three interfaces.
    - SOAP/HTTP for Interoperability
    - SOAP/TCP for B2B type implementations
    - Binary/TCP for performance critical functionality.
  23. JAXB/XML Value Object Design Pattern[ Go to top ]

    Hello,

    JAXB ie Java XML Binding API provides interface and explains the reasons for this API. It is the responsibility of vendor to give JAXB engine that will take care of XML to Binary and vis-a-vis.