Discussions

J2EE patterns: Dynamic Value Object

  1. Dynamic Value Object (102 messages)

    This pattern applies to those projects that use the Value Object pattern. If you choose to use Value Object (i.e. a cache on the client side of the Entity Bean state) you will also have to provide a politic to detect dirty read collision and a politic to initialize outer reference to other Entity Bean. As we have seen on this site these issue can be addressed respectively by the Long Lived Pessimistic Pseudo-Transaction (Version Numbering) pattern and the Lazy Initialization pattern.

    Every Value Object class of the system, in cooperation with his Entity Bean, will have to implement those patterns. Noticing that in a single project it is most likely that the same politic will be chosen to address the previous problems for all the Value Objects of the system, what we get is a replication of the code for each group of class (Entity Bean and Value Object) that handle those problems.
    The objective of this pattern is to use just one class to implement all the Value Objects of the sistem. This class (dynamic proxy object) masquerades itself as the remote interface of the bean it is going to represent. Get/set method are treated locally using a local cache (hash table) while other "normal" business method are called on the Entity Bean.

    To masquerade a class with an interface at runtime is possible thank to a new, nice feature of jdk1.3: dynamic proxy. This allows client to use the dynamic proxy object as the remote interface thus not changing existing code (except for the creation of the dynamic value object).

    I will now describe the pattern in more depth, providing some code examples.

    This pattern supposes that you also use the Business Interface pattern that is a simple pattern but always good.

    public interface BusinessInterface {
        public void doBusiness() throws java.rmi.RemoteException;
        public String getString() throws java.rmi.RemoteException;
        public void setString(String string) throws java.rmi.RemoteException;
    }

    The business interface is implemented by a business object the contains only the business logic. Business Interface and Business Object could belong to a separate package that is totally unbound from technological issues and contains only the business logic. This simplifies the portability of the project among different technological domains (for example from CORBA to EJB or vice versa).

    public class BusinessObject implements BusinessInterface {
    ...
    }

    This patter defines an interface called Proxiable that is used by the dynamic proxy to synchronize the local cache of the state of the Entity Bean with the bean itself.

    public interface Proxiable {
        public void bulkSetAttribute(java.util.Map attributeMap) throws java.rmi.RemoteException;
        public java.util.Map bulkGetAttribute(java.util.Set attributeSet) throws java.rmi.RemoteException;
        public java.util.Map getAllAttributes() throws java.rmi.RemoteException;
    }

    the set of attribute that represente the exportable state of a entity Bean is contained in a map: pairs name of attribute, value. The method getAllAttribute is used to initialize the cache at the creation of the dynamic value object

    The remote interface of the Entity Bean extends both the Business Interface and the Proxiable interface, and of corse the EJBObject interface as from EJB Specification

    public interface BusinessRemote extends BusinessInterface, javax.ejb.EJBObject,Proxiable {
    }

    This pattern introduce an interface called Versionable to help the Entity Bean to detect dirty read collision through the Version Numbering pattern

    public interface Versionable {
      public Integer getVersionID();
      public void setVersionID(Integer versionID);
    }

    The EntitBean extends the BusinessObject and implements the Proxiable, the Versionable and the EntityBean interface.

    public class BusinessBean extends BusinessObject implements javax.ejb.EntityBean,Proxiable,Versionable {
    ...
    }

    The implementation of the Proxiable interface is the same for every Entity Bean: for every attribute that must be set or got the right set/get must be called on the Entity Bean. So, not to replicate the code a ProxyDelegate class is provided. The Entity Bean must simply delegate invoactions on methods of the Proxiable interface to the proxy delegate. Note that the proxy delegate also use the Versionable interface exposed by the Entity Bean to detect ditry read collision.

    public class ProxyDelegate implements Proxiable {
    ...
    }

    Since the business methods are implemented in the business object and the Prixable methods are implemented in the ProxyDelegate the only methods that must be implemented in the entity beans are the container oriented ones, those that handle the Bean lifecycle and are inherited from the EntityBean interface.

    On the client side we have a ProxyFactory interface that is used to create dynamic value object:

    public interface ProxyFactory {
      public Object getProxy(javax.ejb.EJBObject o,Class c) throws ClassCastException,java.rmi.RemoteException;
    }

    The method getProxy receive two parameter the remote interface that must be wrapped and the interface class that the dynamic proxy will have to expose.
    A default implementation of this is interface could be the following

    public class DefaultProxyFactory implements ProxyFactory{

      public DefaultProxyFactory() {
      }

      public Object getProxy(javax.ejb.EJBObject o,Class c) throws ClassCastException,java.rmi.RemoteException {
        Proxiable PI=(Proxiable)o;
        java.util.Map attributeMap=PI.getAllAttributes();
        java.lang.reflect.InvocationHandler EJBPI=new DefaultEJBProxyInvocationHandler(c,o.getHandle(),attributeMap);
        Class[] interfaces={c,Updatable.class};
        return java.lang.reflect.Proxy.newProxyInstance(o.getClass().getClassLoader(),interfaces,EJBPI);
      }
    }

    Notice that in this implementation the initial state of the local cache is obtained calling the getAllAttribute method. Then the dynamic proxy object is built. To build a dynamic proxy object you must provide an array of interfaces that the newly created object will implements and the invocation handler that will handle invocations.

    Notice that the dynamic value object exposes two interface: the Entity Bean remote interface and the Updatabale interface.

    The Updatable interface is called by the client to synchronize the local chache with the entity bean state.
    My default invocation handler uses the local cache when set or get method are called on the dynamic value object, while when other methods are called it forwards the invocation on the Entity Bean.

    To assure that the value object is serializable the reference to the EntityBean is stored as an handle.
    The rest of the pattern is described in the first reply to this pattern...

    Threaded Messages (102)

  2. Dynamic Value Object[ Go to top ]

    My default invocation handler looks like this:

    public class DefaultEJBProxyInvocationHandler extends java.lang.Object implements java.lang.reflect.InvocationHandler, java.io.Serializable {
        javax.ejb.Handle remoteHandle;
        java.util.Map attributeMap;
        Class businessInterface;

        /** Creates new EJBProxyInvicationHandler */
        public DefaultEJBProxyInvocationHandler(Class businessInterface,javax.ejb.Handle remoteHandle,java.util.Map initialAttributeValues) throws java.rmi.RemoteException{
            this.remoteHandle=remoteHandle;
            this.attributeMap=initialAttributeValues;
            this.businessInterface=businessInterface;
        }

        public java.lang.Object invoke(final java.lang.Object obj,java.lang.reflect.Method method,java.lang.Object[] args) throws java.lang.Throwable {
            if (method.getName().equals("update") && (args==null || args.length==0)){
                Proxiable PI=(Proxiable)obj;
                PI.bulkSetAttribute(attributeMap);
                attributeMap.put("versionID",new Integer(((Integer)attributeMap.get("versionID")).intValue()+1));
                return null;
            }
            if (method.getName().startsWith("get") && (args==null || args.length==0)){
                String attribute=method.getName().substring(3);
                attribute=attribute.substring(0,1).toLowerCase()+attribute.substring(1);
                return getMethod(attribute,method,args);
            }
            if (method.getName().startsWith("set") && (args!=null || args.length==1)){
                String attribute=method.getName().substring(3);
                attribute=attribute.substring(0,1).toLowerCase()+attribute.substring(1);
                setMethod(attribute,method,args);
                return null;
            }
            return commonMethod(method,args);
        }




        protected Object commonMethod(java.lang.reflect.Method method,java.lang.Object[] args) throws java.rmi.RemoteException {
            try {
                javax.ejb.EJBObject remoteBean=getEJBObject();
                return method.invoke(remoteBean,args);
            }
            catch (java.lang.reflect.InvocationTargetException e){
                //this should never happen
                java.io.StringWriter SW=new java.io.StringWriter();
                e.printStackTrace(System.out);
                throw new java.rmi.RemoteException(e.getMessage());
            }
            catch (IllegalAccessException e){
                //this should never happen
                throw new java.rmi.RemoteException(e.getMessage());
            }

        }

        protected Object getMethod(String name,java.lang.reflect.Method method,Object[] args) throws java.rmi.RemoteException {
            Object res=attributeMap.get(name);
            try {
                if (res==null){
                    javax.ejb.EJBObject remoteObject=getEJBObject();
                    res=method.invoke(remoteObject,args);
                    attributeMap.put(name,res);
                }
            }
            catch (java.lang.reflect.InvocationTargetException e){
                //this should never happen
                throw new java.rmi.RemoteException(e.getMessage());
            }
            catch (IllegalAccessException e){
                //this should never happen
                throw new java.rmi.RemoteException(e.getMessage());
            }
            return res;
        }

        protected void setMethod(String name,java.lang.reflect.Method method,Object[] args){
            attributeMap.put(name,args[0]);
        }


        protected javax.ejb.EJBObject getEJBObject() throws java.rmi.RemoteException {
            return (javax.ejb.EJBObject)javax.rmi.PortableRemoteObject.narrow(remoteHandle.getEJBObject(),businessInterface);
       }
    }

    Notice that this dynamic proxy does not synchronize with the bean before calling a normal method. This is an implementation choice and among others is up to you to decide which politics to use in this or other similar cases. The important thing to notice is that thank to the proxy factory interface you can switch easily from a politic to another.
  3. Dynamic Value Object[ Go to top ]

    And give up all compiler type checking ? No thanks.
  4. Dynamic Value Object[ Go to top ]

    Tarek Hammound,
    if you read the pattern carefully you will see that you don't have to give up any compiler type checking.
  5. Dynamic Value Object[ Go to top ]

    This is all too complicated!!!

    If the technology (J2EE) makes us jump through hoops like this, why do we use it?!?!?!
  6. jumping through hoops[ Go to top ]

    James, it isn't that J2EE is superior, it's just that the alternatives are much worse (with apologies to Winston Churchill).

    Take a look at COM+, and try not to retch at the hoops required there.

    Take a look at a production system written in Perl and maintained over 2 years, and try not to retch at the hoops required there.

    Then look at J2EE and judge its complexity.
  7. Dynamic Value Object[ Go to top ]

    I guess my interpretation of compiler type checking differs from yours. You are doing method lookup by name. Any type mismatch will only be caught at runtime!! No compiler type checking. This is throwing out the baby with the bath water.

    Tarek
  8. Dynamic Value Object[ Go to top ]

    I'm new to this Dynamic proxies but as I understand it there will be limited type checking (and safety):
    - The client uses a specific typed interface. The compiler will make sure all methods are invoked in accordance with their types.
    - Type errors can still occur if the attributes stored in the Map do not conform to the type the client interface expects. My guess would be that this will only occur if the server objects' definitions are changed and the client interfaces are not. Or the Proxiable methods (to get the Map) are implemented incorrectly by the server objects.

    I connsider the first item to be the most important. The two limitations at the second item seem like manageable risks, that will always occur in distributed system development: server interface changes may require changes to its clients, and server methods need to be implemented correctly for clients to work.

    This leads me to conclude that type safety isn't a huge problem in this approach. Which issues did I overlook?

    Fried.
  9. Tarek, how do you think the JavaBeans API works? It uses reflection, and matching on strings. This is just the reality that one has to deal with if they're making a dynamic framework -- type checking is a crutch that at times does not provide enough value to justify it.

    Java's type checking system is useful (mainly because of interfaces) but very often gets in the way of writing clean code productively. I suppose coming from a C++ background this may sound appauling, but I think high productivity coupled with unit tests tend to make for a better quality solution.
  10. The java beans api (using setters and getters) is invoked dynamically by IDE's. It was never the intention of sun to dynamically invoke bean methods by using reflection for application developers. The introspection mechanism is meant to be used by IDE's and NOT by mortal programmers.

    Invocation during the normal programming course involves calling the setters and getters directly in case full IDE wiring is not possible.

    There is a big difference between static and dynamic type checking. It is always better if the compiler can catch potential problems at compile time rather than having the VM do so at runtime. Each has its use but the suggested pattern is a very weak one for the problem at hand.

    All the best.
  11. JavaBeans[ Go to top ]

    Tarek -- while it is *normally* the case you would not want to dynamically invoke getters and setters in general course of business, it is *very often* the case that you would do this when designing a business objects framework.

    This "dynamic value object" pattern is very important to me because it is around 80% identical to a pattern+framework I came up with last year during a project when teaching 30 junior programmers how to build a medium-complexity EJB system. This pattern significantly helped their productivity and understanding of the spec. We also encapsulated most of this pattern into our own object/relational mapper.

    I also discussed this pattern at length with Floyd Marinescu, and I believe he was also intrigued by it... It's a very addicting pattern to be able to bulk-set your attributes without type checking. The industry trend towards XML seems to also be along these lines -- runtime type checking vs. compile time. The tradeoff is productivity vs. safety.

    In this case, I'm not really talking about "mortal programmers", I'm talking about systems programmers that are trying to make EJB work better, because by default EJB does not provide a lot of the facilities one might desire in a complex system. We're not yet at the ideal where EJB can be leveraged well by "mortal programmers" without significant support from more experienced programmers.

    In a complex system, one of the major goals is to simplify most of the code. One of the ways of doing this is to provide a mechanism to read or write attributes dynamically (known as a Key/Keyable pattern). Several servers already do this, including WebObjects and IBM SanFransisco. Performing true Model/View/Controller separation also requires a layer similar to VisualWorks Smalltalk's ValueModel/AspectAdaptor framework, which also leverages dynamic method invocation.

    Wiring business components to GUIs *without code* is an extremely important area -- something Sun's blueprints do not aim towards.
  12. Dynamic Value Object[ Go to top ]

    Thanks for this interesting pattern. I do have some questions. I hope you could comment on them.

    - Currently you never seem to update the state of the EJB on the server. Did I see that correctly? You do mention that you don't do it before every business method, which is a choice (I wouldn't make it but...). Is the client expected to explicitly call bulkSetAttributes and then refresh its Map (for the new version ID)?
    - Would it be a good idea to keep a seperate Map of the updated attributes, thereby allowing only the changed ones to be transmitted when the server state has to be updated? An update-cancellation can then be processed without new server interaction.
    - Also I consider it to be likely that multiple EJB can be updated in a single transaction. And that a EJBs business method behavior depends on the state of other EJBs. This means these other ones also have to be updated before the method is executed. Would a global Map for all updates (on multiple EJBs) in a transaction be an idea? Do you see possibilities for such a Map (with proper commit/rollback semantics of course ;-))?
    - A final issue I was thinking of is the tuning of the caching strategy. Different (groups of) EJBs might benefit from different caching strategies. Some might be best served by retrieving all (as the pattern currently does), others could benefit from a smaller set of attributes, and yet other would be best served by retrieving (some of) the attributes of multiple EJBs in one call. Any thoughts?

    All this is complicated stuff, as far as I'm concerned, but interesting.
    This is the kind of stuff a J2EE server provider could provide as extra value. This could make all this stuff more transparent. All this caching stuff is a need felt by most development groups. Why does everyone have to invent their own wheel. Caching is needed almost always, with sufficient customization features. Maybe an idea for an addition to the EJB spec?
    Anyone selling a EJB cacher as a product (as add-on to a server)? This would allow projects to focus on their business problems...

    Fried.
  13. Dynamic Value Object[ Go to top ]

    With this message I'll try to answer to the questions you rise in both your previous messages.

    --

    About the first:

    While I agree with the second point I don't fully understand the first. You say there is a limited type checking because the client uses a specific typed interface.
    I try to summarize this point: thanks to dynamic proxy it is possible to create at runtime a class that wears one or more interfaces. Anyway to use this class one must first cast it to one of this interfaces. From the cast on all type checking is assured by the compiler at compile time.
    So the code is secure since compile time (except for invocation handler wrong implementation but this is another issue). Furthermore I propose to use the RemoteBean Interface as an interface dynamically implemented by the dynamic value object, this way should ensure sinchronization between the enterprise java bean and the dinamic value object

    --

    About the second:

    >>"- Currently you never seem to update the state of the EJB on the server. Did I see that correctly?"

    Yes you see it correctly. It is a fault in the explanation I provide a sinchronyzation inteface through an interface called Updatable (you saw it mentioned in the DefaultProxyFactory code. Sorry I forgot to explain it. The interface looks like this:
    public interface Updatable {
      public void update() throws java.rmi.RemoteException;
    }
    You can see an indirect implementation of this interface in the DefaultProxyInvocationHandler.
    The idea is that the dyinamic proxy class has all the methods of the remote bean interface plus this update method that must be used to explicitly update the EJB.

    >>"Would it be a good idea to keep a seperate Map of the updated attributes".

    When I posted this pattern I just wanted to give an idea of how to resolve the problem of the value object classes proliferation. I gave an implementation of this pattern to make an example. The implementation is really weak about optimization but it works (I could give you the code if you are interested in). The architecture of this pattern leaves two point in the code in wich the developer can insert his optimization/policy code.

    The first point is the caching mechanism of the invocation handler (as you noted). To answer you question yes what you say can be an otpimization but there can be others that fit better in some cases. Toerically there should be an invocation handler implementation for each caching mechanism you want to use. The you can choose the caching mechanism through the ProxyFactory.

    The second point (as you noted in your last comment) is in the ProxyDelegate code. This code serves mainly for the cration of new attribute map with which dinamic proxy staus is initilized. A developer, in theory, could create a particular map for every EJB.

    About the third question you rise I'm not sure to unserstand but I'd leave all synchronization issues to the container.

    If you are interested in a sample code that uses dinamic value objects please post a message with your e-mail address.

    Raffaele.
  14. Dynamic Value Object[ Go to top ]

    I think this is interesting material. I'd be very happy with a peek at the example source. Could you mail it to me at DVO at hsac dot nl ?
    If you can, I would also like to know a bit more about the environment you use(d) this in...

    Fried.
  15. Dynamic Value Object[ Go to top ]

    I would like to check the code email me at jseshkumar at hotmail dot com
    thanks
    seshu
  16. Dynamic Value Object[ Go to top ]

    Could someone send me a sample code of dynamic value objects at himanshug at idapta dot com

    Thanks,
    Himanshu Gupta
  17. Dynamic Value Object[ Go to top ]

    Could someone send me a sample code of dynamic value objects at scotes at excite dot com

    Thanks;

    Steve Cotes
  18. Dynamic Value Object[ Go to top ]

    I would also like a look at the code. Probably, it will shed some light on how to cut the number of value objects I have currently. Please email to sshark at tm dot net dot my

    /lim/
  19. Dynamic Value Object[ Go to top ]

    Hi
    I am interested in the code for this pattern. Raffaele could someone please post this to me on the following e-mail
    yasmin dot akbar-husain at iname dot com
    Thanks
  20. Dynamic Value Object[ Go to top ]

    Please, send it to stepanosov@hotmail.com
  21. Dynamic Value Object[ Go to top ]

    Hi,
      Could u please send me the sample code too at rakeshr at indya dot com .

    Thx,
    Rakesh
  22. Dynamic Value Object[ Go to top ]

    Raffaele, could I get a copy of the your ref. implementation of this pattern. Thanks, Brian
    bsbodden@integrallis.com
  23. Dynamic Value Object[ Go to top ]

    this was fascinating material. i am very much interested in the sample code that utilizes this pattern. please send such a code at yufaung at hotmail dot com. thankyou very much.
  24. Dynamic Value Object[ Go to top ]

    Hi Rafaelle,

    Would you mind please to send me your sample code at yan at fr dot uu dot net
    Thanks in advance,

    Yan
  25. Dynamic Value Object[ Go to top ]

    raffaele, ottimo lavoro.

    vorrei dare un'occhiata al codice. puoi inviarmene
    una versione a g_pirola at yahoo dot it.

    grazie in anticipo, giovanni
  26. Dynamic Value Object[ Go to top ]

    Great strategy.
    I will definetely try it.
    Can you Please, send the code to neeraj_nargund at yahoo dot com
    Thanks,
    Neeraj...
  27. Dynamic Value Object[ Go to top ]

    hi,

    I am new to dynamic value object pattern i would also like to have a source code too. please send to my address snarula at zapapp dot com

    thx
    sonika
  28. Dynamic Value Object[ Go to top ]

    Please email the sample code that uses dinamic value objects.
    Thanks,
    Paul
    pknepper@cardionow.com
  29. Dynamic Value Object[ Go to top ]

    Hi,

    The Sample code helps me to undersatnd the pattern better..
    Please send me the Sample code..
    Thanks a Lot

    Saran

    saran_v@yahoo.com
  30. Dynamic Value Object[ Go to top ]

    Could I have the source code to try it myself? Please send it to asit at homemail dot com.
    Thanks.
  31. Dynamic Value Object[ Go to top ]

    Being the nth person to ask this: can anybody please send me (mang at informatik dot hu-berlin.de) the sources, too? I'm working on my master thesis which is related to EJBs and design patterns. Thanks.
    Manuel Mang
  32. Dynamic Value Object[ Go to top ]

    How can i get source codes ?
  33. Dynamic Value Object[ Go to top ]

    My mail is bgonul@veripark.com
  34. Dynamic Value Object[ Go to top ]

    Can I get a copy of the code sent to mrm60 at cvip dot net ?

    thanks
  35. Dynamic Value Object[ Go to top ]

    Hi

    Can i have a copy of the source ? (jcunha at mail dot telepac dot pt)

    Thanks

    Joao
  36. Dynamic Value Object[ Go to top ]

    Could you please send examples and source code of the pattern to: sbrkic at excite dot com

    Thanks,
    Slav Brkic
  37. Dynamic Value Object[ Go to top ]

    Hello,
    is this thread still active ? if it is, could I get the sample code:
    m dot kaleem at tuhh dot de

    thanks,
  38. Dynamic Value Object[ Go to top ]

    I would be very interested in the sample code. Please send to:
    cmasuda at ipnetsolutions dot com

    Thank you.
  39. Dynamic Value Object[ Go to top ]

    I am intrigue by the pattern as we are working on something like that but without using Dynamic Proxies. I was wondering whether you can sent your reference implementation to me. I will like to take a look and will definitely provide feedback.

    Please email it to jee dot meng dot ang at ebizal dot com

    Thanks.

    JM.
  40. Dynamic Value Object[ Go to top ]

    I would be very interested in the sample code. Please send to: andreas dot reitsam at sigel dot de

    Thank you
  41. Dynamic Value Object[ Go to top ]

    Can you send me the source code?........
    My Email : dayirala at yahoo dot com

    Thanks in advance,
  42. Dynamic Value Object[ Go to top ]

    Please Rafaelle, i need the code implmenting the Dynamic Value Object.

    Thanks
    Giovani Salvador
  43. Dynamic Data Object[ Go to top ]

    Hi, I like your pattern and I think it is usefull. May you send me the source code to my email kalhelo at yahoo dot com regards, kal
  44. Dynamic Value Object[ Go to top ]

    Hi,

    very interesting stuff! Could please send me the sample code to Robert.Lentz@Dresdner-Bank.com.
    Thx
    Robert
  45. Dynamic Value Object[ Go to top ]

    Would you please mind sending me the sample code. ywlee73 at hotmail dot com...

    Thank you much!
  46. Dynamic Value Object[ Go to top ]

    Hi,
    If its not too much trouble I'd love to have a look at the source code as well.
    Thanks very much
    EK (ekraffmiller at hotmail dot com)
  47. Dynamic Value Object[ Go to top ]

    Could someone please send me a copy of the source as well. Thanks.
  48. Dynamic Value Object[ Go to top ]

    Raffaele, do you mind sending me your sample code as well: olegf@sigma-systems.com
    Thanks.
  49. Dynamic Value Object[ Go to top ]

    Raffaele, can I have a copy of the source code please.
    Thanks.

    Madhu
  50. Dynamic Value Object[ Go to top ]

    oops, forgot to write my email id: please send the code to madhubalu at hotmail dot com

    Thanks

    Madhu
  51. Dynamic Value Object[ Go to top ]

    If you have a moment, I would be very interested in having a look at the source.

    My email is avantonder at gtech dot com.

    Best regards
    Andre van Tonder
  52. Dynamic Value Object[ Go to top ]

    Please send me the source code.
    email: tamidvj at hotmail dot com

    Thank you!
  53. Dynamic Value Object[ Go to top ]

    I would be very interested in the sample code. Please send to: alexanderl at moscow dot vestedev dot com

    Thank you
  54. Dynamic Value Object[ Go to top ]

    Raffaele,

    Thank you for sharing your Dynamic Value Object Pattern. We are very interested in obtaining a deeper understanding of this pattern. Can you please send us a copy of the code to ken dot danes at springbow dot com.

    Thank You.
  55. Raffaele had never sent this code to anyone, it appears, since over last year 5 or 6 people emailed me asking if I have received it from him. Looks like he created a thread, promised a code, but then abandoned it. I think there should be a business rule on serverside: if one creates a new thread, he is obligated to receive all responses directly to his email. Because what happens is, if one doesn't go to serverside to check the state of the thread he or she will never know how lively the discussion may become over time. Probably, he started the thread, noticed lack of initial interest, abandoned the thread, and while he wasn't there, the discussion got really populous.

    One can call it Dissapearance of the Thread Originator Phenomena :)
  56. Dynamic Value Object[ Go to top ]

    Could anyone e-Mail me code at vbatush at vivatconsulting dot com

    thanks in advace
    Vad
  57. Dynamic Value Object[ Go to top ]

    Could AnyOne Send me the code at gaikwad_rajesh@yahoo.com
  58. Dynamic Value Object[ Go to top ]

    I adopted the Dynamic Proxy as a prototype, using JBoss, together with a Dynamic Attribute and a Value Object pattern and a default implementation of dynamic loading and storing of SQL data. With a minor addition the implementaion of the dynamic proxy class seems to work well.

    I have one question/comment for those of you using this pattern.

    In the invoke member of the DefaultEJBProxyInvocationHandler class we have the following code fragment in the beginning of the invoke member:

    if (method.getName().equals("update") && (args==null || args.length==0)){
        Proxiable PI=(Proxiable)obj;
        PI.bulkSetAttribute(attributeMap);
        attributeMap.put("versionID",new Integer(((Integer)
            attributeMap.get("versionID")).intValue()+1));
        return null;
    }

    PI.bulkSetAttribute(attributeMap) generates a recursive call on invoke, which means that the map on the server
    side will not contain the versionId belonging to the last updated data. I don't think this was the intention. The problem can be fixed by implementing it as an end-recursion, moving the PI.bulkSetAttribute(attributeMap) call before the return statement.

    The reason for the recursion, is that bulkSetAttribute is a member of the Proxiable interface, which is implemented by the Dynamic Proxy class, and by the time this call is executed the Dynamic Proxy class has been instantiated. This is not the case for PI.getAllAttributes method call in DefaultProxyFactory class.

    Thanks for an interesting pattern.

    Eirik
  59. Hello!
    Could I get the full src-code of the implementation of this pattern - would help me much. Please send to formsupport at functionalblue dot com

    Thanks in advance!
    Siegfried
  60. I have open sourced a dynamic data transfer object framework that's been used in a few production J2EE applications. Check it out at dynadto.dev.java.net it's based on interfaces and dynamic proxies configured using a very minimalistic XML file and includes a JBoss Service for integration.

    Brian
  61. Dynamic Value Object[ Go to top ]

    I was very interested in seeing this pattern posted. I have done something similar in a project that I'm involved with, but it was done before the 1.3 dynamic proxies came along. It started out as dynamic value objects and it has since grown into a whole busines object framework that includes XML serialization, object self awareness(dirty, new, etc), and a declarative persistence layer.

    Like the questions concerning type checking, we dealt with those as well, and ours has a lot of casting in it, but the benefits have far outweighed the drawbacks. We use the java.beans package for doing validation, similar to an article on JavaWorld, using the Veto exceptions, and we even use reflection in the persistence layer.

    While I didn't read this one in detail, I thought I would let others know that this is being done to some extent in other systems.

    Robert
  62. Yes, interesting. I am willing to spend my energy reading the source code. Please send it to
    vgritsenko at acm dot org

    I've done something similar, but only similar.

    My idea was: Let's treat Entities as Atoms, groups of Entities which are coherent based on the fact of their participation in given Use Case, will be treated as Molecules. Session EJB methods will represent elementary steps in Use Case. Every step is one transaction.

    We will make snapshots of state of the whole Molecule before and after a transaction. These will be Molecules of Value objects, since one Value object is a snapshot of an Atom. Methods of Session EJB take Molecular Value Objects as parameters and return them as well.

    Yada, yada, yada, as part of the whole thing, I wrote an utility that uses reflection/introspection to flow instance variables values between Entity EJBs and Value Objects back and forth.

    I may post separate thread with more articulate description of what I have done if anyone is interested.

    Viktor Gritsenko
  63. Robert/Viktor,

    I've been trying to find the time to write up a simple dynamic value object from Entity bean generator as well. I think that it would be a good thing for most developers to have in their arsenal.
    One thing I'd also like to include would be a code-generator for the value objects that also includes proxies for aggregated objects within the top-level value object. The proxies would have the ability to reconnect to the EJB server to obtain the requested data without the front-end guys having to write all the networking code requried to perform the home lookups and method calling.
    I'd be interested to see what both you guys, Robert and Viktor, have. Perhaps we could get something to Floyd to post in the "Resources" section. I know that this site is not filled with too many code resources, so I've sent a msg to Floyd to see if he'd include something like this in the "Resources" section.

    Clay Roach
    croach@middleware-company.com
    Trainer/Consultant
    The Middleware Company
    http://www.middleware-company.com
    http://www.TheServerside.com
  64. Clay/Everyone else....

    I think a sample code respository would be a great idea for TSS. I have sure seen a lot of code samples on this site, so maybe being able to either download it, or at least view it online would be benefitial to all.

    What does everyone else think? Floyd?

    Robert
  65. Victor,

    I think your idea worth a separate discussion. "Strategy for mapping Usecases into a J2EE architecture" tread posted here does great job of developing strategy for a Use Case that is a part of a "one-shot" process. Developing a strategy for long living, data maintenance processes needs more and that's where the State comes quite handy. Your Molecule-Atoms looks a lot like Composite. Post it separately and we'll talk more about it. Please, send the code to syndex at sympatico dot ca.
    Thanks, Michael
  66. Dynamic Value Object[ Go to top ]

    Interesting... Please, send it to me on the following e-mail stepanosov#hotmail.com
    Thanks
  67. Dynamic Value Object[ Go to top ]

    Great strategy. We will definetely try it. Please, send the code to syndex at sympatico dot ca. Thanks, Michael
  68. Dynamic Value Object[ Go to top ]

    Hi all,

    Can somone send me the code at achouicha at aol dot com. Thanks

    Amine.
  69. Dynamic Value Object[ Go to top ]

    Such a pity that it works only with JDK 1.3.
    We still have Application Servers with JDK 1.2.... like iPlanet
  70. Dynamic Value Object[ Go to top ]


    Can I get a copy of the source code? Thanks in advance.

    Yvon Lavoie
    ylavoie@magma.ca
  71. Dynamic Value Object[ Go to top ]

    I would also enjoy checking out some sample source code for this pattern. Please email craig at rampventures dot com

    Thanks
    CT
  72. Dynamic Value Object[ Go to top ]

    Hi,

    This is interesting. Can someone please
    send me a code. Thanks.

    rgeneblazo2000@yahoo.com
  73. Dynamic Value Object[ Go to top ]

    Great pattern Raffaele! I've used Dynamic Proxies for many things, such as to generate dynamic value objects, create fat keys (see my Fat Key Pattern also posted here), generate retryable InitialContext stubs (in case ALL ejb servers in a cluster are down and I don't want my servlet request to fail to the client), implement dynamic SSB-to-entity-bean method evocation, method-evocation logging and performance timing, etc...

    Those who condemn dynamic proxies simply do not realize and appreciate this WONDERFUL tool that JDK 1.3 has provided us. Even the latest application servers running on 1.3, such as WL 6.0, use DPs to generate stubs and skeletons.

    For those who need more convincing, check out the following articles:

    http://www.javaworld.com/jw-11-2000/jw-1110-proxy.html
    http://java.sun.com/j2se/1.3/docs/api/index.html


  74. Dynamic Value Object[ Go to top ]

    Would you please mind sending me the sample code @ jthirsch at hotmail dot com...

    Thank you much!
     -Jeff
  75. Dynamic Value Object[ Go to top ]

    Nice pattern.
    Could you please send source to jpalmiero at paymentech dot com

    Thanks,
    Jeff
  76. I have a situation where I have a bunch of EB... I want to add a VO to each one.. I would be interested in see this Dynamic Value Object, however, if strong type checking is very important, then a tool that allowed easy creation of VO that are NOT dynamic might reduce the advantages of a DVO...

    Eric
  77. Of course, I need to post my email! epugh at museumcompany dot com!
  78. Hi!

    Cud u pls send me the implementation source.

    SB

    surajit.13@usa.net
  79. Dynamic Value Object[ Go to top ]

    Could you please send me the source code of DVO (vdutta at ebusinessdesign dot com)

     Thanks
     Vivek
  80. Dynamic Value Object[ Go to top ]

    Raffaele, I would like to take a look at your code. Could you send it to natesh_gk at hotmail dot com

    Thanks
  81. Dynamic Value Object[ Go to top ]

    Raffaele,
    if it is possible, please send me the sample code to
    a_sarhovsky at yahoo dot com.
    Thanks in advance.
    Alex Sarhovsky
  82. Dynamic Value Object[ Go to top ]

    Can you please send the sample code to ind66ra at yahoo dot com

    Thanks,
    Nag
  83. Dynamic Value Object[ Go to top ]

    Hello Raffaele. 2 things:

    1) you state "Since the business methods are implemented in the business object and the Prixable methods are implemented in the ProxyDelegate the only methods that must be implemented in the entity beans are the container oriented ones......"
    How can this be true if the Entity Bean implements Proxyable?

    2) could you send me the code to examine?
  84. Dynamic Value Object[ Go to top ]

    Could you send the source code to kurt_mccaw at hotmail dot com

    TIA,
    Kurt
  85. Dynamic Value Object[ Go to top ]

    Can you send the code to tmwiega at netscape dot net

       Thanks.
  86. Dynamic Value Object[ Go to top ]

    Would anybody send me the code ? Thanks
    e-mail: joem001@yahoo.com
  87. Dynamic Value Object[ Go to top ]

    Would appreciate it if anyone could send me the detailed code example to this pattern. Please send it to brian dot jordan at starpower dot net.

    Thanks!
  88. Dynamic Value Object[ Go to top ]

    Could someone mail the Code example for this pattern to it_teky at hotmail dot com

    Thanks
  89. Dynamic Value Object[ Go to top ]

    Interesting,

    can you post the sample code to d dot antonelli at cribisnetgroup dot com

    thanks in advance

    Dino Antonelli
  90. Dynamic Value Object[ Go to top ]

    Interesting Indeed.

    Can u pls post the code on gurmeetsbhui at yahoo dot com

    Thanks
    Gurmeet
  91. Dynamic Value Object[ Go to top ]

    i'am interested in this code, plze would u like to send it to aitabaid at reef dot com

    Cheeeeeeeeeeeeeeeers

    Said,
  92. Dynamic Value Object[ Go to top ]

    Can someone send me the code also!!!
    hfu1 at yahoo dot com

    thanks
  93. Dynamic Value Object[ Go to top ]

    Rafaelle,
    This sounds great! Can I have a look at your code?
    Please e-mail to xy_zet at hotmail dot com
    Thanks. Cheers:)
  94. Dynamic Value Object[ Go to top ]

    Can you send me sample code.Thanks.
  95. Dynamic Value Object[ Go to top ]

    Can you send me sample code of use Dynamic Value Object to igarcia at bilbomatica dot es .Thanks.
  96. Dynamic Value Object[ Go to top ]

    Can you send me sample code to leafun at netvigator dot com? Thanks.
  97. Dynamic Value Object[ Go to top ]

    Please send source. Thanks.
    bmiddlebrook@taliantsoftware.com
  98. Dynamic Value Object[ Go to top ]

    Could anyone send me(pmsarma at yahoo dot com) the code.
    Thanks,
    Madhav
  99. Dynamic Value Object[ Go to top ]

    Very interesting,

    Could you please post the sample code to threehook at hotmail dot com

    Thanks in advance,
    Jim
  100. Dynamic Value Object[ Go to top ]

    Could I have a copy of the source at ceeenvee at hotmail dot com ?

    TIA,
    Cee
  101. Variation of this pattern[ Go to top ]

    I've just noticed this pattern and it's remarkably similar to one I've used.

    My design is different in that the clients using the proxies must request a key before they are allowed to call the set methods. All set invocations are cached in the proxy; this ensures that other proxies will see the 'old' values when calling any getter methods.

    When the key holding client has finished, it can call commit() and then releaseKey(). When commit is called, the state of the target object is updated. Calling release key will allow other clients to obtain the key. The client code *must* call the release method or the target VO will never release it's lock.

    Because only one client may hold the key at any time, transaction management becomes simple - the client object must ensure that it has keys for all the objects in a related transaction before calling commit on them all and releasing their keys.

    Another interesting difference is in the class hierarchy I've chosen:

    I've defined an interface ValueObject that defines the above methods. I've also implemented AbstractValueObject which implements these methods and provides thread-safe behaviour for key management and proxy creation.

    To implement a VO for my application I just need to:

    1) Create an interface for the new VO which extends the ValueObject interface, eg:

        interface MyVO extends ValueObject {
            //getters
            //setters
            //other methods
        }


    2) Create an implementation of that interface which extends AbstractValueObject

        public class MyVOImpl extends AbstractValueObject implements MyVO {
            //
        }


    The only two methods that AbstractValueObject does not implement are those concerned with persisting the data.

    Here's the code for the ValueObject interface:

    public interface ValueObject {
        //The following are imlemented by AbstractValueObject
        public abstract Object getProxy(Class proxyClass);
        public abstract void requestLock();
        public abstract void commit();
        public abstract void delete();
        public abstract void rollback();
        public abstract void releaseLock();

        //These must be implemented by concrete Value Objects
        public abstract void persist(Connection c);
        public abstract void remove(Connection c);
    }

    Client code would then look like this:

        MyVO vo = new MyVOImpl();
        MyVO proxy = (MyVO)vo.getProxy(MyVO.class);

        proxy.requestLock();
        //read and write to the proxy here
        proxy.commit();
        proxy.releaseKey();


    If anyone has any other variations on this I'd be really interested to hear about it.

         Cheers - Steve.
  102. Need Code::Variation of this pattern[ Go to top ]

    Raffaele, could I get a copy of your ref. implementation of this pattern.

    Thanx in advance,
    -sk
  103. need code too - thanks[ Go to top ]

    Could I get a copy of your ref. implementation of this pattern - too?
    Please send to formsupport at functionalblue dot com

    Thanx in advance,
    Siegfried