To avoid the overhead of remote method invocation, J2EE application often adopt the Value Object (now called 'Transfer Object') Pattern (J2EE blueprints). The client receives just a copy of the actual stored data, which can then used without generating additional network traffic.
If the client needs to make changes on this object, the application can use the "Updatable Transfer Objects" strategy as described in Sun's pattern catalogue.
However, this introduces additional complexity: "There is an impact on the design using the updatable Transfer Objects in terms of update propagation, synchronization, and version control." (Sun).
In other words, the developer must take care of a mechanism on the server side to apply changes in the TOs back to the storage tier. If serveral clients access the same data, he will also need to implement a locking mechanism to avoid inconsistencies.
There are several possibilites to solve this problems:
The SVO project has adopted the latter approach to solve the problem, as adding behaviour by adding code to the TOs is very intrusive and error-prone. Code generation has its own quirks and adds another layer of complexity which must be dealt with.
AOP allows for a clean seperation between the aspects "data transfer" and "version control". However, we chose not to use AOP for the moment mainly because it would add yet another dependency (think remote deployement where size is crucial) and doesn't offer the full flexibility of "low-level" bytecode manipulation.
This low-levelness is often regard as hack, but most of the 'smart stuff' is actually happening 'outside' the bytecode modification, so the code is easy to change without having to step down to bytecode level. Think of the bytecode modification merely as providing the 'hooks' to plug in normal, unmodified classes.
Ideally, these modification should be transparent to the user, i.e you code your TOs as before without having to worry about version control etc. On deployment (or on runtime), the needed functionality is automatically added and can be used instantly.
back | index | next |