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...
-
Dynamic Value Object (102 messages)
- Posted by: raffaele spazzoli
- Posted on: December 15 2000 02:39 EST
Threaded Messages (102)
- Dynamic Value Object by raffaele spazzoli on December 15 2000 02:40 EST
- Dynamic Value Object by Tarek Hammoud on December 17 2000 19:08 EST
-
Dynamic Value Object by raffaele spazzoli on December 18 2000 05:48 EST
-
Dynamic Value Object by James Webster on December 19 2000 01:30 EST
- jumping through hoops by Stu Charlton on January 03 2001 11:54 EST
-
Dynamic Value Object by Tarek Hammoud on December 26 2000 04:43 EST
- Dynamic Value Object by Fried Hoeben on January 03 2001 09:33 EST
-
Compile time type checking considered harmful by Stu Charlton on January 03 2001 11:52 EST
-
Compile time type checking considered harmful by Tarek Hammoud on January 06 2001 12:30 EST
- JavaBeans by Stu Charlton on January 14 2001 07:40 EST
-
Compile time type checking considered harmful by Tarek Hammoud on January 06 2001 12:30 EST
-
Dynamic Value Object by James Webster on December 19 2000 01:30 EST
-
Dynamic Value Object by raffaele spazzoli on December 18 2000 05:48 EST
- Dynamic Value Object by Fried Hoeben on January 03 2001 09:59 EST
-
Dynamic Value Object by raffaele spazzoli on January 04 2001 01:17 EST
- Dynamic Value Object by Fried Hoeben on January 05 2001 08:36 EST
- Dynamic Value Object by SeshKumar Jalagam on January 08 2001 09:11 EST
-
Dynamic Value Object by Himanshu Gupta on January 09 2001 04:02 EST
- Dynamic Value Object by Stephen Cotes on September 06 2001 08:29 EDT
- Dynamic Value Object by Lim Teck-Hooi on January 19 2001 01:00 EST
- Dynamic Value Object by Yasmin Akbar-Husain on January 23 2001 06:00 EST
- Dynamic Value Object by Anonimous Anonimous on January 25 2001 07:47 EST
- Dynamic Value Object by Rakesh Rajendran on January 27 2001 09:27 EST
- Dynamic Value Object by Brian Sam-Bodden on February 07 2001 10:40 EST
- Dynamic Value Object by Mary Chen on February 11 2001 02:16 EST
- Dynamic Value Object by Yan Delcroix on March 04 2001 08:00 EST
-
Dynamic Value Object by giovanni pirola on March 13 2001 06:17 EST
- Dynamic Value Object by Neeraj Nargund on March 13 2001 11:47 EST
- Dynamic Value Object by sonika narula on March 14 2001 02:23 EST
- Dynamic Value Object by Paul Knepper on March 29 2001 02:02 EST
- Dynamic Value Object by Vel Saran on April 05 2001 01:46 EDT
-
Dynamic Value Object by Asit Bhattacharya on April 10 2001 07:22 EDT
- Dynamic Value Object by Doctor Zoidberg on April 11 2001 11:11 EDT
-
Dynamic Value Object by Bora Gonul on May 26 2001 02:09 EDT
- Dynamic Value Object by Bora Gonul on May 26 2001 02:36 EDT
- Dynamic Value Object by matt mikulics on May 01 2001 02:35 EDT
- Dynamic Value Object by Joao Cunha on May 04 2001 09:23 EDT
- Dynamic Value Object by Branko Koprivica on May 08 2001 12:53 EDT
- Dynamic Value Object by Farhat Kaleem on May 28 2001 10:39 EDT
- Dynamic Value Object by C Masuda on June 04 2001 09:15 EDT
- Dynamic Value Object by Jee-Meng Ang on June 12 2001 11:51 EDT
-
Dynamic Value Object by andreas reitsam on July 06 2001 02:34 EDT
- Dynamic Value Object by Dhanujkumar Ayirala on July 24 2001 03:35 EDT
- Dynamic Value Object by Giovani Salvador on October 23 2001 09:44 EDT
- Dynamic Data Object by null on April 23 2007 04:35 EDT
-
Dynamic Value Object by raffaele spazzoli on January 04 2001 01:17 EST
- Dynamic Value Object by Robert Lentz on February 01 2001 16:40 EST
- Dynamic Value Object by Yongwon Lee on March 20 2001 08:03 EST
- Dynamic Value Object by Ellen Kraffmiller on April 27 2001 10:12 EDT
- Dynamic Value Object by Brad Harper on April 30 2001 13:46 EDT
- Dynamic Value Object by Oleg Fonarev on May 14 2001 11:06 EDT
- Dynamic Value Object by Madhu Krishnan on May 16 2001 12:37 EDT
- Dynamic Value Object by Madhu Krishnan on May 16 2001 06:54 EDT
- Dynamic Value Object by Andrew johnson on June 21 2001 09:53 EDT
- Dynamic Value Object by tami yumg on July 31 2001 07:22 EDT
- Dynamic Value Object by Alexander Lapygin on September 07 2001 13:48 EDT
- Dynamic Value Object by Ken Danes on September 25 2001 10:09 EDT
- Dissapearance of the Thread Originator Phenomena by viktor gritsenko on September 25 2001 05:35 EDT
- Dynamic Value Object by vad batush on February 19 2002 19:04 EST
- Dynamic Value Object by j j on February 22 2002 12:13 EST
- Dynamic Value Object by Eirik Gr??nsund on May 03 2002 04:26 EDT
- would like to get the full impl. code by Siegfried M?ller on March 10 2004 15:49 EST
- Open Source Implementation of Dynamic Data Transfer Object by Brian Sam-Bodden on August 25 2005 12:43 EDT
- Dynamic Value Object by Tarek Hammoud on December 17 2000 19:08 EST
- Dynamic Value Object by Robert McIntosh on January 06 2001 23:46 EST
- Dynamic Value Object (DVO) - Molecularization Of DVO Pattern by viktor gritsenko on January 07 2001 20:52 EST
-
Dynamic Value Object (DVO) - Molecularization Of DVO Pattern by Clay Roach on January 08 2001 12:16 EST
- Dynamic Value Object (DVO) - Molecularization Of DVO Pattern by Robert McIntosh on January 10 2001 01:15 EST
- Dynamic Value Object (DVO) - Molecularization Of DVO Pattern by Michael Linetsky on January 29 2001 11:16 EST
-
Dynamic Value Object (DVO) - Molecularization Of DVO Pattern by Clay Roach on January 08 2001 12:16 EST
- Dynamic Value Object (DVO) - Molecularization Of DVO Pattern by viktor gritsenko on January 07 2001 20:52 EST
- Dynamic Value Object by Anonimous Anonimous on January 23 2001 08:47 EST
- Dynamic Value Object by Michael Linetsky on January 29 2001 10:41 EST
- Dynamic Value Object by Amine Chouicha on February 04 2001 01:03 EST
- Dynamic Value Object by Anonimous Anonimous on February 09 2001 05:59 EST
- Dynamic Value Object by Web Master on February 09 2001 13:43 EST
- Dynamic Value Object by Craig Tadlock on February 20 2001 20:14 EST
- Dynamic Value Object by Ronald Geneblazo on February 28 2001 11:50 EST
- Dynamic Value Object by Gene Chuang on March 01 2001 18:02 EST
- Dynamic Value Object by Jeffrey Hirsch on March 07 2001 14:19 EST
- Dynamic Value Object by Jeff Palmiero on March 11 2001 06:45 EST
- Boy, we need an code repository! Could I get a copy as well... by david pugh on April 12 2001 16:47 EDT
- Boy, we need an code repository! Could I get a copy as well... by david pugh on April 12 2001 16:48 EDT
- Dynamic Value Object by Surajit Bhattacharjee on April 19 2001 06:34 EDT
- Dynamic Value Object by Vivek Dutta on May 04 2001 14:44 EDT
- Dynamic Value Object by N krishnan on May 09 2001 12:45 EDT
- Dynamic Value Object by Alex Sarkovsky on May 16 2001 10:09 EDT
- Dynamic Value Object by Nagendra Turaga on May 16 2001 13:33 EDT
- Dynamic Value Object by Jonathan Asbell on May 23 2001 01:22 EDT
- Dynamic Value Object by Kurt McCaw on June 26 2001 09:14 EDT
- Dynamic Value Object by Tony Wiegand on July 24 2001 11:59 EDT
- Dynamic Value Object by Joe M on July 25 2001 10:16 EDT
- Dynamic Value Object by Brian Jordan on August 28 2001 16:31 EDT
- Dynamic Value Object by M S on September 09 2001 18:02 EDT
- Dynamic Value Object by Dino Antonelli on November 05 2001 04:04 EST
- Dynamic Value Object by Gurmeet Bhui on February 16 2002 07:31 EST
- Dynamic Value Object by said aitabaid on February 19 2002 11:08 EST
- Dynamic Value Object by Humphrey Fu on March 08 2002 07:32 EST
- Dynamic Value Object by ivo ivanov on March 15 2002 09:59 EST
- Dynamic Value Object by Israel Garcia on April 09 2002 04:23 EDT
- Dynamic Value Object by Israel Garcia on April 09 2002 04:29 EDT
- Dynamic Value Object by Victor Lo on April 19 2002 12:27 EDT
- Dynamic Value Object by barry middlebrook on April 22 2002 15:48 EDT
- Dynamic Value Object by Madhava Sarma on April 29 2002 01:43 EDT
- Dynamic Value Object by Jim Wever on August 03 2002 07:22 EDT
- Dynamic Value Object by Cee Vee on August 06 2002 17:02 EDT
-
Variation of this pattern by s n on September 06 2003 08:05 EDT
- Need Code::Variation of this pattern by Shahid Khan on October 01 2003 11:55 EDT
- need code too - thanks by Siegfried M?ller on March 10 2004 03:47 EST
-
Variation of this pattern by s n on September 06 2003 08:05 EDT
- Dynamic Value Object by Cee Vee on August 06 2002 17:02 EDT
-
Dynamic Value Object[ Go to top ]
- Posted by: raffaele spazzoli
- Posted on: December 15 2000 02:40 EST
- in response to raffaele spazzoli
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.
-
Dynamic Value Object[ Go to top ]
- Posted by: Tarek Hammoud
- Posted on: December 17 2000 19:08 EST
- in response to raffaele spazzoli
And give up all compiler type checking ? No thanks. -
Dynamic Value Object[ Go to top ]
- Posted by: raffaele spazzoli
- Posted on: December 18 2000 05:48 EST
- in response to Tarek Hammoud
Tarek Hammound,
if you read the pattern carefully you will see that you don't have to give up any compiler type checking. -
Dynamic Value Object[ Go to top ]
- Posted by: James Webster
- Posted on: December 19 2000 01:30 EST
- in response to raffaele spazzoli
This is all too complicated!!!
If the technology (J2EE) makes us jump through hoops like this, why do we use it?!?!?! -
jumping through hoops[ Go to top ]
- Posted by: Stu Charlton
- Posted on: January 03 2001 23:54 EST
- in response to James Webster
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.
-
Dynamic Value Object[ Go to top ]
- Posted by: Tarek Hammoud
- Posted on: December 26 2000 16:43 EST
- in response to raffaele spazzoli
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 -
Dynamic Value Object[ Go to top ]
- Posted by: Fried Hoeben
- Posted on: January 03 2001 09:33 EST
- in response to Tarek Hammoud
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.
-
Compile time type checking considered harmful[ Go to top ]
- Posted by: Stu Charlton
- Posted on: January 03 2001 23:52 EST
- in response to Tarek Hammoud
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.
-
Compile time type checking considered harmful[ Go to top ]
- Posted by: Tarek Hammoud
- Posted on: January 06 2001 12:30 EST
- in response to Stu Charlton
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.
-
JavaBeans[ Go to top ]
- Posted by: Stu Charlton
- Posted on: January 14 2001 07:40 EST
- in response to Tarek Hammoud
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.
-
Dynamic Value Object[ Go to top ]
- Posted by: Fried Hoeben
- Posted on: January 03 2001 09:59 EST
- in response to raffaele spazzoli
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.
-
Dynamic Value Object[ Go to top ]
- Posted by: raffaele spazzoli
- Posted on: January 04 2001 13:17 EST
- in response to Fried Hoeben
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. -
Dynamic Value Object[ Go to top ]
- Posted by: Fried Hoeben
- Posted on: January 05 2001 08:36 EST
- in response to raffaele spazzoli
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. -
Dynamic Value Object[ Go to top ]
- Posted by: SeshKumar Jalagam
- Posted on: January 08 2001 21:11 EST
- in response to raffaele spazzoli
I would like to check the code email me at jseshkumar at hotmail dot com
thanks
seshu -
Dynamic Value Object[ Go to top ]
- Posted by: Himanshu Gupta
- Posted on: January 09 2001 16:02 EST
- in response to raffaele spazzoli
Could someone send me a sample code of dynamic value objects at himanshug at idapta dot com
Thanks,
Himanshu Gupta
-
Dynamic Value Object[ Go to top ]
- Posted by: Stephen Cotes
- Posted on: September 06 2001 20:29 EDT
- in response to Himanshu Gupta
Could someone send me a sample code of dynamic value objects at scotes at excite dot com
Thanks;
Steve Cotes -
Dynamic Value Object[ Go to top ]
- Posted by: Lim Teck-Hooi
- Posted on: January 19 2001 01:00 EST
- in response to raffaele spazzoli
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/ -
Dynamic Value Object[ Go to top ]
- Posted by: Yasmin Akbar-Husain
- Posted on: January 23 2001 06:00 EST
- in response to raffaele spazzoli
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 -
Dynamic Value Object[ Go to top ]
- Posted by: Anonimous Anonimous
- Posted on: January 25 2001 07:47 EST
- in response to raffaele spazzoli
Please, send it to stepanosov@hotmail.com -
Dynamic Value Object[ Go to top ]
- Posted by: Rakesh Rajendran
- Posted on: January 27 2001 21:27 EST
- in response to raffaele spazzoli
Hi,
Could u please send me the sample code too at rakeshr at indya dot com .
Thx,
Rakesh -
Dynamic Value Object[ Go to top ]
- Posted by: Brian Sam-Bodden
- Posted on: February 07 2001 10:40 EST
- in response to raffaele spazzoli
Raffaele, could I get a copy of the your ref. implementation of this pattern. Thanks, Brian
bsbodden@integrallis.com -
Dynamic Value Object[ Go to top ]
- Posted by: Mary Chen
- Posted on: February 11 2001 14:16 EST
- in response to raffaele spazzoli
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. -
Dynamic Value Object[ Go to top ]
- Posted by: Yan Delcroix
- Posted on: March 04 2001 20:00 EST
- in response to raffaele spazzoli
Hi Rafaelle,
Would you mind please to send me your sample code at yan at fr dot uu dot net
Thanks in advance,
Yan -
Dynamic Value Object[ Go to top ]
- Posted by: giovanni pirola
- Posted on: March 13 2001 06:17 EST
- in response to raffaele spazzoli
raffaele, ottimo lavoro.
vorrei dare un'occhiata al codice. puoi inviarmene
una versione a g_pirola at yahoo dot it.
grazie in anticipo, giovanni -
Dynamic Value Object[ Go to top ]
- Posted by: Neeraj Nargund
- Posted on: March 13 2001 11:47 EST
- in response to giovanni pirola
Great strategy.
I will definetely try it.
Can you Please, send the code to neeraj_nargund at yahoo dot com
Thanks,
Neeraj... -
Dynamic Value Object[ Go to top ]
- Posted by: sonika narula
- Posted on: March 14 2001 02:23 EST
- in response to raffaele spazzoli
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 -
Dynamic Value Object[ Go to top ]
- Posted by: Paul Knepper
- Posted on: March 29 2001 14:02 EST
- in response to raffaele spazzoli
Please email the sample code that uses dinamic value objects.
Thanks,
Paul
pknepper@cardionow.com -
Dynamic Value Object[ Go to top ]
- Posted by: Vel Saran
- Posted on: April 05 2001 13:46 EDT
- in response to raffaele spazzoli
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 -
Dynamic Value Object[ Go to top ]
- Posted by: Asit Bhattacharya
- Posted on: April 10 2001 19:22 EDT
- in response to raffaele spazzoli
Could I have the source code to try it myself? Please send it to asit at homemail dot com.
Thanks. -
Dynamic Value Object[ Go to top ]
- Posted by: Doctor Zoidberg
- Posted on: April 11 2001 11:11 EDT
- in response to Asit Bhattacharya
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 -
Dynamic Value Object[ Go to top ]
- Posted by: Bora Gonul
- Posted on: May 26 2001 14:09 EDT
- in response to Asit Bhattacharya
How can i get source codes ? -
Dynamic Value Object[ Go to top ]
- Posted by: Bora Gonul
- Posted on: May 26 2001 14:36 EDT
- in response to Bora Gonul
My mail is bgonul@veripark.com -
Dynamic Value Object[ Go to top ]
- Posted by: matt mikulics
- Posted on: May 01 2001 14:35 EDT
- in response to raffaele spazzoli
Can I get a copy of the code sent to mrm60 at cvip dot net ?
thanks -
Dynamic Value Object[ Go to top ]
- Posted by: Joao Cunha
- Posted on: May 04 2001 21:23 EDT
- in response to raffaele spazzoli
Hi
Can i have a copy of the source ? (jcunha at mail dot telepac dot pt)
Thanks
Joao
-
Dynamic Value Object[ Go to top ]
- Posted by: Branko Koprivica
- Posted on: May 08 2001 00:53 EDT
- in response to raffaele spazzoli
Could you please send examples and source code of the pattern to: sbrkic at excite dot com
Thanks,
Slav Brkic -
Dynamic Value Object[ Go to top ]
- Posted by: Farhat Kaleem
- Posted on: May 28 2001 10:39 EDT
- in response to raffaele spazzoli
Hello,
is this thread still active ? if it is, could I get the sample code:
m dot kaleem at tuhh dot de
thanks, -
Dynamic Value Object[ Go to top ]
- Posted by: C Masuda
- Posted on: June 04 2001 21:15 EDT
- in response to raffaele spazzoli
I would be very interested in the sample code. Please send to:
cmasuda at ipnetsolutions dot com
Thank you. -
Dynamic Value Object[ Go to top ]
- Posted by: Jee-Meng Ang
- Posted on: June 12 2001 23:51 EDT
- in response to raffaele spazzoli
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.
-
Dynamic Value Object[ Go to top ]
- Posted by: andreas reitsam
- Posted on: July 06 2001 02:34 EDT
- in response to raffaele spazzoli
I would be very interested in the sample code. Please send to: andreas dot reitsam at sigel dot de
Thank you -
Dynamic Value Object[ Go to top ]
- Posted by: Dhanujkumar Ayirala
- Posted on: July 24 2001 03:35 EDT
- in response to andreas reitsam
Can you send me the source code?........
My Email : dayirala at yahoo dot com
Thanks in advance, -
Dynamic Value Object[ Go to top ]
- Posted by: Giovani Salvador
- Posted on: October 23 2001 09:44 EDT
- in response to raffaele spazzoli
Please Rafaelle, i need the code implmenting the Dynamic Value Object.
Thanks
Giovani Salvador -
Dynamic Data Object[ Go to top ]
- Posted by: null
- Posted on: April 23 2007 04:35 EDT
- in response to raffaele spazzoli
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 -
Dynamic Value Object[ Go to top ]
- Posted by: Robert Lentz
- Posted on: February 01 2001 16:40 EST
- in response to raffaele spazzoli
Hi,
very interesting stuff! Could please send me the sample code to Robert.Lentz@Dresdner-Bank.com.
Thx
Robert
-
Dynamic Value Object[ Go to top ]
- Posted by: Yongwon Lee
- Posted on: March 20 2001 08:03 EST
- in response to raffaele spazzoli
Would you please mind sending me the sample code. ywlee73 at hotmail dot com...
Thank you much!
-
Dynamic Value Object[ Go to top ]
- Posted by: Ellen Kraffmiller
- Posted on: April 27 2001 10:12 EDT
- in response to raffaele spazzoli
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) -
Dynamic Value Object[ Go to top ]
- Posted by: Brad Harper
- Posted on: April 30 2001 13:46 EDT
- in response to raffaele spazzoli
Could someone please send me a copy of the source as well. Thanks. -
Dynamic Value Object[ Go to top ]
- Posted by: Oleg Fonarev
- Posted on: May 14 2001 11:06 EDT
- in response to raffaele spazzoli
Raffaele, do you mind sending me your sample code as well: olegf@sigma-systems.com
Thanks. -
Dynamic Value Object[ Go to top ]
- Posted by: Madhu Krishnan
- Posted on: May 16 2001 12:37 EDT
- in response to raffaele spazzoli
Raffaele, can I have a copy of the source code please.
Thanks.
Madhu -
Dynamic Value Object[ Go to top ]
- Posted by: Madhu Krishnan
- Posted on: May 16 2001 18:54 EDT
- in response to Madhu Krishnan
oops, forgot to write my email id: please send the code to madhubalu at hotmail dot com
Thanks
Madhu -
Dynamic Value Object[ Go to top ]
- Posted by: Andrew johnson
- Posted on: June 21 2001 09:53 EDT
- in response to raffaele spazzoli
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 -
Dynamic Value Object[ Go to top ]
- Posted by: tami yumg
- Posted on: July 31 2001 07:22 EDT
- in response to raffaele spazzoli
Please send me the source code.
email: tamidvj at hotmail dot com
Thank you! -
Dynamic Value Object[ Go to top ]
- Posted by: Alexander Lapygin
- Posted on: September 07 2001 13:48 EDT
- in response to raffaele spazzoli
I would be very interested in the sample code. Please send to: alexanderl at moscow dot vestedev dot com
Thank you -
Dynamic Value Object[ Go to top ]
- Posted by: Ken Danes
- Posted on: September 25 2001 10:09 EDT
- in response to raffaele spazzoli
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. -
Dissapearance of the Thread Originator Phenomena[ Go to top ]
- Posted by: viktor gritsenko
- Posted on: September 25 2001 17:35 EDT
- in response to Ken Danes
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 :) -
Dynamic Value Object[ Go to top ]
- Posted by: vad batush
- Posted on: February 19 2002 19:04 EST
- in response to raffaele spazzoli
Could anyone e-Mail me code at vbatush at vivatconsulting dot com
thanks in advace
Vad -
Dynamic Value Object[ Go to top ]
- Posted by: j j
- Posted on: February 22 2002 12:13 EST
- in response to vad batush
Could AnyOne Send me the code at gaikwad_rajesh@yahoo.com -
Dynamic Value Object[ Go to top ]
- Posted by: Eirik Gr??nsund
- Posted on: May 03 2002 04:26 EDT
- in response to raffaele spazzoli
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
-
would like to get the full impl. code[ Go to top ]
- Posted by: Siegfried M?ller
- Posted on: March 10 2004 15:49 EST
- in response to raffaele spazzoli
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 -
Open Source Implementation of Dynamic Data Transfer Object[ Go to top ]
- Posted by: Brian Sam-Bodden
- Posted on: August 25 2005 12:43 EDT
- in response to Siegfried M?ller
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 -
Dynamic Value Object[ Go to top ]
- Posted by: Robert McIntosh
- Posted on: January 06 2001 23:46 EST
- in response to raffaele spazzoli
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 -
Dynamic Value Object (DVO) - Molecularization Of DVO Pattern[ Go to top ]
- Posted by: viktor gritsenko
- Posted on: January 07 2001 20:52 EST
- in response to Robert McIntosh
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 -
Dynamic Value Object (DVO) - Molecularization Of DVO Pattern[ Go to top ]
- Posted by: Clay Roach
- Posted on: January 08 2001 00:16 EST
- in response to 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
-
Dynamic Value Object (DVO) - Molecularization Of DVO Pattern[ Go to top ]
- Posted by: Robert McIntosh
- Posted on: January 10 2001 13:15 EST
- in response to Clay Roach
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 -
Dynamic Value Object (DVO) - Molecularization Of DVO Pattern[ Go to top ]
- Posted by: Michael Linetsky
- Posted on: January 29 2001 11:16 EST
- in response to viktor gritsenko
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
-
Dynamic Value Object[ Go to top ]
- Posted by: Anonimous Anonimous
- Posted on: January 23 2001 08:47 EST
- in response to raffaele spazzoli
Interesting... Please, send it to me on the following e-mail stepanosov#hotmail.com
Thanks -
Dynamic Value Object[ Go to top ]
- Posted by: Michael Linetsky
- Posted on: January 29 2001 10:41 EST
- in response to raffaele spazzoli
Great strategy. We will definetely try it. Please, send the code to syndex at sympatico dot ca. Thanks, Michael -
Dynamic Value Object[ Go to top ]
- Posted by: Amine Chouicha
- Posted on: February 04 2001 01:03 EST
- in response to raffaele spazzoli
Hi all,
Can somone send me the code at achouicha at aol dot com. Thanks
Amine. -
Dynamic Value Object[ Go to top ]
- Posted by: Anonimous Anonimous
- Posted on: February 09 2001 05:59 EST
- in response to raffaele spazzoli
Such a pity that it works only with JDK 1.3.
We still have Application Servers with JDK 1.2.... like iPlanet -
Dynamic Value Object[ Go to top ]
- Posted by: Web Master
- Posted on: February 09 2001 13:43 EST
- in response to Anonimous Anonimous
Can I get a copy of the source code? Thanks in advance.
Yvon Lavoie
ylavoie@magma.ca -
Dynamic Value Object[ Go to top ]
- Posted by: Craig Tadlock
- Posted on: February 20 2001 20:14 EST
- in response to raffaele spazzoli
I would also enjoy checking out some sample source code for this pattern. Please email craig at rampventures dot com
Thanks
CT -
Dynamic Value Object[ Go to top ]
- Posted by: Ronald Geneblazo
- Posted on: February 28 2001 11:50 EST
- in response to Craig Tadlock
Hi,
This is interesting. Can someone please
send me a code. Thanks.
rgeneblazo2000@yahoo.com -
Dynamic Value Object[ Go to top ]
- Posted by: Gene Chuang
- Posted on: March 01 2001 18:02 EST
- in response to raffaele spazzoli
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
-
Dynamic Value Object[ Go to top ]
- Posted by: Jeffrey Hirsch
- Posted on: March 07 2001 14:19 EST
- in response to raffaele spazzoli
Would you please mind sending me the sample code @ jthirsch at hotmail dot com...
Thank you much!
-Jeff -
Dynamic Value Object[ Go to top ]
- Posted by: Jeff Palmiero
- Posted on: March 11 2001 06:45 EST
- in response to raffaele spazzoli
Nice pattern.
Could you please send source to jpalmiero at paymentech dot com
Thanks,
Jeff -
Boy, we need an code repository! Could I get a copy as well...[ Go to top ]
- Posted by: david pugh
- Posted on: April 12 2001 16:47 EDT
- in response to raffaele spazzoli
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 -
Boy, we need an code repository! Could I get a copy as well...[ Go to top ]
- Posted by: david pugh
- Posted on: April 12 2001 16:48 EDT
- in response to david pugh
Of course, I need to post my email! epugh at museumcompany dot com! -
Dynamic Value Object[ Go to top ]
- Posted by: Surajit Bhattacharjee
- Posted on: April 19 2001 06:34 EDT
- in response to raffaele spazzoli
Hi!
Cud u pls send me the implementation source.
SB
surajit.13@usa.net -
Dynamic Value Object[ Go to top ]
- Posted by: Vivek Dutta
- Posted on: May 04 2001 14:44 EDT
- in response to raffaele spazzoli
Could you please send me the source code of DVO (vdutta at ebusinessdesign dot com)
Thanks
Vivek -
Dynamic Value Object[ Go to top ]
- Posted by: N krishnan
- Posted on: May 09 2001 12:45 EDT
- in response to raffaele spazzoli
Raffaele, I would like to take a look at your code. Could you send it to natesh_gk at hotmail dot com
Thanks -
Dynamic Value Object[ Go to top ]
- Posted by: Alex Sarkovsky
- Posted on: May 16 2001 10:09 EDT
- in response to raffaele spazzoli
Raffaele,
if it is possible, please send me the sample code to
a_sarhovsky at yahoo dot com.
Thanks in advance.
Alex Sarhovsky -
Dynamic Value Object[ Go to top ]
- Posted by: Nagendra Turaga
- Posted on: May 16 2001 13:33 EDT
- in response to raffaele spazzoli
Can you please send the sample code to ind66ra at yahoo dot com
Thanks,
Nag -
Dynamic Value Object[ Go to top ]
- Posted by: Jonathan Asbell
- Posted on: May 23 2001 01:22 EDT
- in response to raffaele spazzoli
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? -
Dynamic Value Object[ Go to top ]
- Posted by: Kurt McCaw
- Posted on: June 26 2001 09:14 EDT
- in response to raffaele spazzoli
Could you send the source code to kurt_mccaw at hotmail dot com
TIA,
Kurt -
Dynamic Value Object[ Go to top ]
- Posted by: Tony Wiegand
- Posted on: July 24 2001 11:59 EDT
- in response to raffaele spazzoli
Can you send the code to tmwiega at netscape dot net
Thanks. -
Dynamic Value Object[ Go to top ]
- Posted by: Joe M
- Posted on: July 25 2001 10:16 EDT
- in response to raffaele spazzoli
Would anybody send me the code ? Thanks
e-mail: joem001@yahoo.com -
Dynamic Value Object[ Go to top ]
- Posted by: Brian Jordan
- Posted on: August 28 2001 16:31 EDT
- in response to raffaele spazzoli
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! -
Dynamic Value Object[ Go to top ]
- Posted by: M S
- Posted on: September 09 2001 18:02 EDT
- in response to raffaele spazzoli
Could someone mail the Code example for this pattern to it_teky at hotmail dot com
Thanks -
Dynamic Value Object[ Go to top ]
- Posted by: Dino Antonelli
- Posted on: November 05 2001 04:04 EST
- in response to raffaele spazzoli
Interesting,
can you post the sample code to d dot antonelli at cribisnetgroup dot com
thanks in advance
Dino Antonelli -
Dynamic Value Object[ Go to top ]
- Posted by: Gurmeet Bhui
- Posted on: February 16 2002 07:31 EST
- in response to raffaele spazzoli
Interesting Indeed.
Can u pls post the code on gurmeetsbhui at yahoo dot com
Thanks
Gurmeet -
Dynamic Value Object[ Go to top ]
- Posted by: said aitabaid
- Posted on: February 19 2002 11:08 EST
- in response to Gurmeet Bhui
i'am interested in this code, plze would u like to send it to aitabaid at reef dot com
Cheeeeeeeeeeeeeeeers
Said, -
Dynamic Value Object[ Go to top ]
- Posted by: Humphrey Fu
- Posted on: March 08 2002 07:32 EST
- in response to raffaele spazzoli
Can someone send me the code also!!!
hfu1 at yahoo dot com
thanks -
Dynamic Value Object[ Go to top ]
- Posted by: ivo ivanov
- Posted on: March 15 2002 09:59 EST
- in response to raffaele spazzoli
Rafaelle,
This sounds great! Can I have a look at your code?
Please e-mail to xy_zet at hotmail dot com
Thanks. Cheers:) -
Dynamic Value Object[ Go to top ]
- Posted by: Israel Garcia
- Posted on: April 09 2002 04:23 EDT
- in response to raffaele spazzoli
Can you send me sample code.Thanks. -
Dynamic Value Object[ Go to top ]
- Posted by: Israel Garcia
- Posted on: April 09 2002 04:29 EDT
- in response to raffaele spazzoli
Can you send me sample code of use Dynamic Value Object to igarcia at bilbomatica dot es .Thanks. -
Dynamic Value Object[ Go to top ]
- Posted by: Victor Lo
- Posted on: April 19 2002 12:27 EDT
- in response to Israel Garcia
Can you send me sample code to leafun at netvigator dot com? Thanks. -
Dynamic Value Object[ Go to top ]
- Posted by: barry middlebrook
- Posted on: April 22 2002 15:48 EDT
- in response to raffaele spazzoli
Please send source. Thanks.
bmiddlebrook@taliantsoftware.com -
Dynamic Value Object[ Go to top ]
- Posted by: Madhava Sarma
- Posted on: April 29 2002 01:43 EDT
- in response to barry middlebrook
Could anyone send me(pmsarma at yahoo dot com) the code.
Thanks,
Madhav
-
Dynamic Value Object[ Go to top ]
- Posted by: Jim Wever
- Posted on: August 03 2002 07:22 EDT
- in response to raffaele spazzoli
Very interesting,
Could you please post the sample code to threehook at hotmail dot com
Thanks in advance,
Jim -
Dynamic Value Object[ Go to top ]
- Posted by: Cee Vee
- Posted on: August 06 2002 17:02 EDT
- in response to Jim Wever
Could I have a copy of the source at ceeenvee at hotmail dot com ?
TIA,
Cee -
Variation of this pattern[ Go to top ]
- Posted by: s n
- Posted on: September 06 2003 20:05 EDT
- in response to Cee Vee
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. -
Need Code::Variation of this pattern[ Go to top ]
- Posted by: Shahid Khan
- Posted on: October 01 2003 11:55 EDT
- in response to s n
Raffaele, could I get a copy of your ref. implementation of this pattern.
Thanx in advance,
-sk -
need code too - thanks[ Go to top ]
- Posted by: Siegfried M?ller
- Posted on: March 10 2004 15:47 EST
- in response to s n
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