Dynamic Value Objects Using CMP2 and XML Article Posted on TSS


News: Dynamic Value Objects Using CMP2 and XML Article Posted on TSS

  1. A new featured article 'Dynamic Value Objects Using CMP2 and XML' by Meeraj Kunnumpurath has been posted on TheServerSide. This article proposes an alternative to the standard Value Object/Data Transfer Object approach patterns, by illustrating using EJB 2.0 in conjunction with bean introspection and JAXP to create dynamic XML based data structures.

    In the article, a framework is developed that can dynamically traverse the container managed persistent and related fields of a given local EJB and create an XML document that can be transferred between the various tiers in the application.

    Read Dynamic Value Objects using CMP2 and XML.

    Threaded Messages (26)

  2. The author says that the operation took 0.5 seconds for a record set of a thousand with complex relationships. It would have been very useful if he had compared it with the value-object approach. :)

  3. Joda project[ Go to top ]

    This is one of the ideas I had when I started the Joda project. www.joda.org is setting out to provide domain solutions. Central to this is an enhancement to the basic JavaBean model.

    Joda allows a bean to dynamically add and remove properties. This is useful for the dynamic behaviour described in the article.

    Joda also allows a bean and a property to have attributes (like XML). An example use is to attach an error code as an attribute of the property that caused the error.

    Finally, Joda allows querying of the structure via interfaces with normal get and set methods. Thus, the extensibility of DOM is maintained, but with the ability to write small interfaces to make the program easier to use.

    Joda already supports bean to and from SAX, type conversion, XPath integration and a Swing integration example. Why not take a look at www.joda.org.

  4. Interesting and useful.

    Curious for examples to complete the traversal.
    Examples provided illustrate bean->dom

    What would the code look like to find, update the bean based on dom?

  5. Castor XML provides a similar type of functionality. It has been available for the year-and-a-half that I've used Castor. Also, Castor XML's functionality is not bound to an EJB environment.

    See the Castor web site.
  6. I think this article touches a veru usefull technique that is fast becoming a major competitor to JSP, namely using XSLT for front-end formatting. However, I think the main focus of the article should be shifted. I don't think creating values objects is a big problem with modern development environment, and I don't see any reason to move data from the server to the client as DOM. DOM is much less efficient than normal Java objects in many areas, and is especially inefficient when it comes to primitives (all primitives are converted to strings, meaning they take up much more space and require more time to process). DOM is so inefficient, virtually all XSLT processors completely replace it with a table-like model, even though that means they have to convert the entire DOM to their own model every time they do processing. It still saves them prcoessing time.

    I don't think this approach promotes loose coupling of tiers. It only creates the illusion of loose coupling by dropping all type information. The tiers are still coupled by the data structure, only this structure is not formally defined in an interface, which is a negative effect IMHO. It also effectively rules out the abillity to use the value objects for changing the bean state: if you change the DOM directly you get absolutely no type safety, not even against creating nodes that don't match to anything, etc. It also becomes impossible to implement "smart" value objects, such as objects that maintain a list of changed fields, etc.

    I think the main focus should be on treating Java object graphs as DOM trees. This allows using normal OO methods for the programmatic access to your data, and using your objects within XSLT templates as well. I propose to do this by implementing an adapter module that dynamically maps objects to DOM. This also avoids the inefficient storage mechanisms used by normal DOM trees, as it uses the objects as the storage mechanism, and merely maps these objects to DOM.
    Note that this approach is atleast as powerful as the article's approach, because you can allways do the DOM mapping at the server side and pass the generated DOM to the client. However, I argue that the approach I outlined above has many advantages over this one.

    Some projects have been set up to do just this, notably the Domify project. I have also started a project of my own called JND, which is about to go open source under an Apache-like license soon. If anybody is interested in details you can mail me at nerlin at inter dot net dot il

  7. I fully agree that I don't see the benefit of moving data around within a pure-Java system using DOM. It is actually going backwards.
    In my opinion it is useful at the integration points and probably at the presentation layer (even there I don't agree that it is always more cost-efficient or faster to have XSLT-based front-ends). Internally, the proper and sound mechanisms provided by the language and the frameworks are more appropriate and have better performance.
  8. I agree using XML as data transfer objects is not the ideal solution and I have mentioned the shortcomings associated with this approach towards the end of the article.

    However, the article focuses on using CMP2 relations and local references to create dynamic data structures. Regarding, type safety, if the application is architected properly, most of the business processing will be performed in the enterprise tier. Here we don't use XML at all, rather we use entity EJBs with local references that model as domain objects.

    XML is only used for presentation. The data that need to be presented to the client devices are dynamically created as XML from the CMP beans. IMHO the presentation tier shouldn't be concerned with anything other than presenting the data and XML provides a very flexible mode of multi channel rendering.

    Regarding sending data back to the enterprise tier, you can always use business delegates encapsulating session facades and the methods on these delegates may take any number of arguments. You don't need to pass the data back as a single bean or encapsulated in a DOM.
  9. My argument was that you could equivalently pass a graph of normal objects to the client, just as you do with your DOM. This provides for more efficient data transfer. It also allow for more flexible client interaction modes, for instance when you want optimistic concurrency mgmt: you have to give your client some version identifer - just session facades won't do. In fact that's a common design pattern that is decribed in TSS's patterns section.

    I also argue that passing object graphs does not create a stronger coupling: even if we consider the DOM to be an indirection point, you can create the DOM version on the client side using Java reflection just as you can on the server side. But I don't agree that the DOM is a point of indirection at all. It represents exactly the same structure. The only thing it does is remove compile-time checking. You still have exactly the same field types, names, hierarchy, etc. You only get an illusion of weak coupling. Results that would be found at compile time will now be found at run-time. I consider this to be a negative effect.

    I think designing your beans to only suite a presentation tier is misdesign. EJBs should represent data and logic, independent of how it is used in the system. By only returning a DOM tree, you rule out all programmatic access to the data (well, you can access the data in DOM's typeless mode, but in a programmatic environment that's a very bad choice, IMHO). What if you have an adminitration client application that displays the data in a Swing application, without HTML integration? Just plain old Swing components... shouldn't be that hard, should it?

    I still think this approach is very usefull for the presentation tier, and hope it will become common. However, I just don't see any reason to tie the EJB tier to what's usefull for the presentation tier. If the presentation tier could use a DOM tree, the presentation tier can make one. Thats the way I see it.

  10. Gal,

    I do agree with some of your comments.

    For example it would be nice to use Java objects for Swing based applications. Again you can write XML driven table models, tree models etc for your frontend widgets.

    I think things like optimistic locking and version number etc should be handled by some sort of business tier controller. Again the presentation tier will have to pass the value of the version number column to the methods exposed by session facades/Business delegates.

    IMHO the presentation tier should be as thin as possible, doing basic data rendering tasks and very high level validations.


  11. I believe your entire article to be a spoiler. Fundamentally flawed from multiple aspects.

    1.XML is about adding meaning to data. i.e. transforming data into information. Not only that, but transforming data into information that can be both machine and human readable.

    2.Interfaces are about providing the black box that adds value to projects. Both in terms of decoupling and code reuse. These are realised through strong communication and project management. But ultimately through interface specification - ie not dynamic, layed down in stone.

    3.Dynamic discovery is cool, much like function pointers passed in memory blocks. BUT it makes for useless project maintenance. All you are doing is upping the anti on your coders skill set.

    4.There is a myth that decoupling of web and middle and backend tiers will result in an increase in productivity. To the extend that the addition of a column to a table will not cascade through every feed, and application that uses the data. This is total rubbish, try adding a second email address to a contact record with an optional switch to preferred delivery address. It effects every part of every app that accesses the fundamental data.

    My point is that XML is not part of J2EE tier seperation. It is totally part of data feeds, and definatly will become the defacto data storage and mining format (say 8 years away), with XSLT and assoc technologies replacing vast swathes of current 'architectures' (mentioning no names).

    Your entire perspective is flawed in terms of performance, reuse and usefullness. I will agree it is 'cool'.

  12. I dont agree and dont see its implementation on a B2C systems.I think we would not even consider replacing Value Object with XML.We have been working in building up a highly performance and scalable J2EE system for a year now(trust me as big as yahoo.com) and never used these kind of framework which involves all this XML parsing at run time.

  13. Jonathan

    Interfaces should be laid down in stone. I agree. However, that doesn't mean interfaces should always have object incarnations. For example, WSDL defines an interface that is not tied down to an implementation technology.

    Peformance is important. I agree. But after an acceptable level, it doesn't bother me much. And it depends very much on the context in which it is meassured. On normal B2C systems, there is no big difference in performance in the order of micro seconds and milli seconds.

    Your web tier need not be always J2EE. You may be exposing your enterprise tier as a set of web services that are consumed by applications implemented using other technologies. Here XML provides seamless integration. You don't need to delve into the encoding intricacies for your Java object bindings.


  14. In my opinion the biggest flaw, is the cmp2 centric view that is taken, treating XML as just a way of transfering objects as text that can be read by humans.

    The strength of XML is that it is a human readable and human writable format

    Within an organisation where key data is shared between many applications, systems and individuals, XML schemas and DTDs and the documents produced with them should be driven by business need primarily and not secondary functions to their use in applications.
  15. First of all let me say that I for one don't consider this article to bew a "spoiler". The main result of of the design you propose is to have the presentation tier written (mostly) in XML-aware engines such as XPath and XSLT. I think this is definately a good direction, to the extent that I started my own project to make that possible. Even if all this article did is stir debate on this topic, it is of value to the community.

    Our disagreement is on the exact scope that this XML-isation should have. I don't consider this XML form to be of generic usefullness. Many programmatic tasks would have been hard to accomplish, had this been the only way to get data from beans. It may be usefull if you use the EJB like a web service, and make it possible to decode the XML back into Java objects. But that defeats your argument about not having to write these objects in the first place. Besides, I'm not to quick to start using all my EJBs as web services. I am very skeptic about the range of use web services will have.

    About the optimistic locking comment, you could pass the version by hand. But keep in mind different objects have different version (you can't maintain a global version, it's impractical and useless). So the client will need a way to obtain the version for each particular part of the model, and then pass it to the delegate. That's a little too much reposnsibility on the client IMHO, I don't think it makes good encapsulation.

    I agree with your last paragraph. I do consider creating the DOM for an object model to match this category.

  16. Well, may I twist the discussion a bit?

    What value objects are good for afterall?! Let's break it to two usage scenarios: web-based and remote client.

    - For web/jsp/servlet-based clients of ejbs in ejb2 we have local interfaces and in fact the topology of putting web and ejb tiers in different machines is deprecated. So no need for value objects here.

    - For remote clients we have to transfer the objects, right? But in this scenario we should also break it into two usages: one dealing with outer systems (which are pobably better handled by xml in/out and soap) and fat clients (a swing client maybe). The truth is that we can't rely on bare data holder value objects for this scenario either! Because we need to share some logic too in these tiers. For example, we need a base Customer interface/class which defines the common properties and logics, and CustomerClient (the class remote client uses) and CustomerServer (the class server uses). CustomerClasses might have some special properties not shared by client (password field for example) or some server side logic. Unfortunately with ejb we can't easily make this kind of stuff happen (are you going to derive CustomerClient from CustomerBean ejb class? Maybe the remote intf but what about logic?). It's because ejb's object model is a very exposed and non-transparent object model, you simply don't have properties and method there. And then comes the issue or passing object graphs around and synching them back. Apple's webobjects has a neat solution for this kind of distribution/synching stuff, but in ejb this scenario is not supported and you have to role your own solution.

    So what value objects are good for? I'm curious to learn.

    PS: Btw, the latest XDoclet (v1.1.2) offers a sophisticated solution for generating value objects. It doesn't stop in level one classes but traverses the whole object graph and creates value objects for the whole object grath. I do prefer this approach over the one described in the article, because: you're still dealing with java objects (type safety/etc, intuitive, etc) and it should be way faster because it doesn't rely on xml and it uses code generation instead of runtime reflection.


  17. Value objects are essential for distributed systems. I am not sure I understand or agree with your points.

    >> - For web/jsp/servlet-based clients of ejbs in ejb2 we have
    >> local interfaces and in fact the topology of putting web
    >> and ejb tiers in different machines is deprecated. So no
    >> need for value objects here

    For security reasons you should separate your presentation and business logic tiers with a 2nd firewall. (Some, perhaps most, banks have 3 firewalls in fact - the 3rd between the business logic tier and the data tier.)
    Moreover, from the point of view of scalabilty of some applications, it is entirely necessary too, to physically separate tiers.
    Seperation is hardly deprecated.

    >> - For remote clients ...<snip>

    I dont understand your point.

    Value objects are there for efficiency of network transfer of data (or if the nature of the data used on the client is in fact a complex graph of objects).
    They tend to be somewhat oriented to the way the data is used rather than the way it is stored - this is where the insulation from your persistent data model is achieved.

  18. I completely agree with Nick. I don't see how local interfaces can possibly affect the deployment topology. You can't make a local call from the web server to the EJBs. Local calls can only be made *within* the container.
    The way I see it, all the major considerations towards splitting the web server from the app server are still there: better scallability, improved security, lower costs (3 Apaches and 1 WebLogic is that much cheaper than 3 WebLogics), etc. I don't see how local interfaces play a factor.

    I really didn't get your second comment, about remote clients. Value objects is a very commonly used design pattern in distributed system design. It has been used a great number of times with proven success. Why do you think it suddenly became so useless?

    "because ejb's object model is a very exposed and non-transparent object model"
    How so? EJBs can *only* be accessed through their remote interfaces, and all access is mediated by the container. It also has a higher-level security model based on the user principal. As a component model, EJB has a very strong version of a "client contract". I really don't understand what you mean by saying the object model is exposed and transparent.

    You say that value objects cannot be used because logic has to be shared by different types of clients, and not only data. But the value object is not ment to hold logic. Logic should be placed in remote components, where it is easily accessible and maintainable. Value objects only serve as a way to "batch" data access from and to the remote logic. Again, I can't see your point.

  19. My biggest complaint about the value object pattern is all the mapping that has to be coded every time the schema changes. Personally, I'm looking for opportunities to code faster, and IMO, if I don't have to spend time writing blocks that either build immutable value objects with lengthy constructor signatures or manually do "bucket-brigade" gets and sets (e.g. valueObject.setFoo( ejb.getFoo( ) ); valueObject.setFoo2( ejb.getFoo2( ) ); etc...), assuming your value object provides a manner to get the data in, I'm much more content.

    I figure if I'm sending the object out simply so someone can use it to mark up a display, send it as an XML doc, cache it even, maybe cache it in the tier closest to display even.

    On the project I'm currently managing, we actually did away with the use of "set" methods altogether. The user builds up a chain of actions (i.e. functions), feeds those in to the biz logic tier in a Frame, which actually invokes that set action and sets the values in the appropriate tier via reflection. That way, if needed (which we do), we can track the exact time of every "set" call and the order in which they happened. You just can't acomplish that in any reasonable time without introducing these very "fuctional" (i.e. Scheme) models into the mix.

  20. <Nick Minutello>
    For security reasons you should separate your presentation and business logic tiers with a 2nd firewall. (Some, perhaps most, banks have 3 firewalls in fact - the 3rd between the business logic tier and the data tier.)
    Moreover, from the point of view of scalabilty of some applications, it is entirely necessary too, to physically separate tiers.
    Seperation is hardly deprecated.
    </Nick Minutello>

    The way I see it ejb2 spec encourages you to separate http server and application server, but not web and ejb servers. You can place a firewall between the http server and the application server. If you take a look at the latest petstore app you see unlike previous versions no value objects are used, local interfaces and a wrapping transaction are used. These two paragraphs from Websphere redbooks are also interesting:

    <WAS redbookd>
    In terms of performance this topology allows one to replicate different numbers of application servers (for example, two Web containers and five EJB servers or vice versa), which may provide better performance. In general, however, elimination of the local JVM optimizations that occur when both the servlet (client) and the EJB (server) are resident in the same application server (JVM) as well as the network latency introduced with the topology will tend to negate any possible performance improvement brought about by the additional processing power afforded by a separate physical server.

    While providing more redundancy for application server processes, this topology also introduces more possible points of failure. In addition to more application server processes, this means that you’ll have more to manage as well.
    </WAS redbookd>

    <Gal Binyamini>
    I really didn't get your second comment, about remote clients. Value objects is a very commonly used design pattern in distributed system design. It has been used a great number of times with proven success. Why do you think it suddenly became so useless?
    </Gal Binyamini>

    Well, what I was complaining about is that value object pattern is a workaround. I can't pass ejbs around, to server, to client. I have to create value objects out of the ejbs. Sure you can't pass ejbs around, they are bound to run in a container with all those jndi/blabla stuff. So you should partition it yourself to -common logic (runnable on both server and client, like simple valudations for example), -server side stuff and -client side only stuff. Take a look at apple's webobjects to understand what I mean.

  21. <Ara>
    The way I see it ejb2 spec encourages you to separate http server and application server, but not web and ejb servers.

    I dont think that is the intention of the spec. Local interfaces were introduced primarily to provide a standard differentiation between remote and local beans - to improve security and performance of fine grained EJBs (e.g. CMR).

    You can place a firewall between the http server and the application server.

    Typically, to achieve a gain in security you must also have a protocol break between firewall layers. Http thru FW1 to Web/Servlet tier - JRMP/T3/IIOP to business logic tier - JDBC?/? to data/legacy tier.

    If you take a look at the latest petstore app you see unlike previous versions no value objects are used, local interfaces and a wrapping transaction are used.

    You might be right - I havent looked at the J2EE1.3 Petstore.

    In the end, its not an invalid design to use local interfaces between web and ejb tiers. However, this is only valid if you are only doing web clients (there are many non-web applications). Also, you do this in the full knowledge that you are limiting your options.

    As I stated earlier, your DTO's will be naturally different from your persistent data model. This is good - it hides your persistent data model from your clients. Your cients get only the data they need (or cache data they are likely to need).
    Using local, fine grained interfaces between your client and business tiers will encourage tighter coupling between persistant data model and client tiers. Not desirable IMO.

    In terms of common logic, I still dont understant your point (sorry). Partitioning of responsibility is exactly what EJB/DTO's encourage.

  22. How strange, the debate has changed.

    Initially the author was saying use XML and reflection for all RPC.

    Now a different set of folks are saying value objects are slow and shouldn't be used when using local EJB's.

    Haaa haa haa haaaaaa haaa ha.


    OK, schema changes cascade to every level of your project no matter what you use for RPC. I agree automation is called for - either introspection, code generation or XML auto marshalling code. Whatever.

    BUT, there is a big risk. And its versioning, especially in enterprise system with loads of feeds going on. The nice thing about value objects and BMP (yes I still cling to it) is that you can code for minor version upgrades and often ensure major upgrades are backwards compatible. Also coders can see all the code involved and not get lost in 15 layers of software indirection.

    So, I still say use Value Objects. Don't use introspection. And use code generation rather than dynamic discovery. And use RPC and serialisation rather than XML.

    BTW, a new release of the LowRoad is out with audit table populate and all the examples are upgraded.
  23. I think I shouldn't ask this kind of question here but I hope you help me on this.

    For web baseed application, is optimistic concurrency mgmt is the feasible solution? Because we can't force the client to refresh their data.

    Also, how can I implement the optimistic concurrency mgmt if the DB table hasn't got the last modified day? Or, is that built in to all tables?

    If so, do you know how to get it in MS SQL DB? Thank you!

  24. XchainJ does something like this[ Go to top ]

    A product called XchainJ that was released in January 2002 does something similar but not specifically within EJB.

    A GUI enables XML/Java/database mappings and Java bindings to be declared (no code to write, just GUI-based stuff). Exported mappings and bindings are used by a runtime processor to transform between XML, Java, database.

    The upshot is XML/Java/database interoperability without writing SAX, DOM, JDOM, JDBC, etc. All we need to do as developers is invoke the processor and apply business logic to data in the Java objects, if desired.

    The disparity between hierarchical XML and database tables (that are essentially flat) is handled really well.

    This product winds up eliminating a whole bunch of development time. I believe the vendor provides an evaluation version at www.XchainJ.com

  25. I like the concept. For business applications, I often feel that having to constantly construct and refactor business objects is a tremendous pain. When possible, I'm omitting objects because I end up constructing adapters upon adapters that translate from RDBMS to Objects to XML. And, the objects seem to get in the way of the business "functions" that need to occur. Then, I end up writing reflection code (a significant amount lateley) to handle things like attribute copying (so I don't have to have oodles of lines like foo.setA( foo2.getA )), transformation into XML.

    And, look at the amount of reflection code that has to be written. After writing a ton of reflection code, I said "screw this" and wrote all of my code in Jython, because I could get first class objects, easily construct lists, do invocations via apply( ) and eval( ), and I cut the number of lines down tremendously.

    But, I think more structured data and fewer objects is where we're all heading, because we eventually end up having to transform and display this data to some client, be it a web page or client app.

    Certainly is nicer to build in Jython, though.

  26. Can someone post the proper link to the article?
  27. I tested the code provided in the article on an existing CMP2 structure. It works well except for one case:
    If there is one-to-one relation which currently has no associated EJB the invoke() method returns null. This is not handled in populateElement(). However this can be easily achieved by the following modification:

    Object prop = propReadMethod.invoke(local, null);
    if(prop != null) {
       if(RESERVED.indexOf(propName) >= 0) {
           catch(ClassCastException ex2) {
               parent.setAttribute(propName, prop.toString());

    This works well but I want to see (and will produce) some performance figures before I put the pattern into use.