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...

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.

And give up all compiler type checking ? No thanks.

Tarek Hammound,
if you read the pattern carefully you will see that you don't have to give up any compiler type checking.

This is all too complicated!!!

If the technology (J2EE) makes us jump through hoops like this, why do we use it?!?!?!

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.

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

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.

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.

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.

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.

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.

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.

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.

I would like to check the code email me at jseshkumar at hotmail dot com
thanks
seshu

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

Thanks,
Himanshu Gupta

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

Thanks;

Steve Cotes

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/

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

Please, send it to stepanosov@hotmail.com

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

Thx,
Rakesh

Raffaele, could I get a copy of the your ref. implementation of this pattern. Thanks, Brian
bsbodden@integrallis.com

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.

Hi Rafaelle,

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

Yan

raffaele, ottimo lavoro.

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

grazie in anticipo, giovanni

Great strategy.
I will definetely try it.
Can you Please, send the code to neeraj_nargund at yahoo dot com
Thanks,
Neeraj...

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

Please email the sample code that uses dinamic value objects.
Thanks,
Paul
pknepper@cardionow.com

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

Could I have the source code to try it myself? Please send it to asit at homemail dot com.
Thanks.

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

How can i get source codes ?

My mail is bgonul@veripark.com

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

thanks

Hi

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

Thanks

Joao

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

Thanks,
Slav Brkic

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

thanks,

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

Thank you.

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.

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

Thank you

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

Thanks in advance,

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

Thanks
Giovani Salvador

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

Hi,

very interesting stuff! Could please send me the sample code to Robert.Lentz@Dresdner-Bank.com.
Thx
Robert

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

Thank you much!

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)

Could someone please send me a copy of the source as well. Thanks.

Raffaele, do you mind sending me your sample code as well: olegf@sigma-systems.com
Thanks.

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

Madhu

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

Thanks

Madhu

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

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

Thank you!

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

Thank you

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.

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 :)

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

thanks in advace
Vad

Could AnyOne Send me the code at gaikwad_rajesh@yahoo.com

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

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

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

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

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

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
https://www.theserverside.com

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

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

Interesting... Please, send it to me on the following e-mail stepanosov#hotmail.com
Thanks

Great strategy. We will definetely try it. Please, send the code to syndex at sympatico dot ca. Thanks, Michael

Hi all,

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

Amine.

Such a pity that it works only with JDK 1.3.
We still have Application Servers with JDK 1.2.... like iPlanet

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

Yvon Lavoie
ylavoie@magma.ca

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

Thanks
CT

Hi,

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

rgeneblazo2000@yahoo.com

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

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

Thank you much!
 -Jeff

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

Thanks,
Jeff

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

Of course, I need to post my email! epugh at museumcompany dot com!

Hi!

Cud u pls send me the implementation source.

SB

surajit.13@usa.net

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

 Thanks
 Vivek

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

Thanks

Raffaele,
if it is possible, please send me the sample code to
a_sarhovsky at yahoo dot com.
Thanks in advance.
Alex Sarhovsky

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

Thanks,
Nag

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?

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

TIA,
Kurt

Can you send the code to tmwiega at netscape dot net

   Thanks.

Would anybody send me the code ? Thanks
e-mail: joem001@yahoo.com

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!

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

Thanks

Interesting,

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

thanks in advance

Dino Antonelli

Interesting Indeed.

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

Thanks
Gurmeet

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

Cheeeeeeeeeeeeeeeers

Said,

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

thanks

Rafaelle,
This sounds great! Can I have a look at your code?
Please e-mail to xy_zet at hotmail dot com
Thanks. Cheers:)

Can you send me sample code.Thanks.

Can you send me sample code of use Dynamic Value Object to igarcia at bilbomatica dot es .Thanks.

Can you send me sample code to leafun at netvigator dot com? Thanks.

Please send source. Thanks.
bmiddlebrook@taliantsoftware.com

Could anyone send me(pmsarma at yahoo dot com) the code.
Thanks,
Madhav

Very interesting,

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

Thanks in advance,
Jim

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

TIA,
Cee

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.

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

Thanx in advance,
-sk

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