Following the previous thread introducing the project and its concepts, the SmartValueObject 1.0 has now been released.

The Smart Value Object (SVO) allows server components to track client-side modifications of business objects in a rich client/J2EE server environment, by using the latest features offered by bytecode processing tools.

To avoid the overhead of remote method invocation, J2EE applications often adopt the Value Object (now called 'Transfer Object') Pattern. The client receives just a copy of the actual stored data, which can then be used without generating additional network traffic.

If the client needs to make changes on this oject, 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 several 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:

* Handcoding these mechanisms for each project
* Use a code generator to do this task (cf. Carrierwave)
* Add version control by AOP / bytecode processing

The Smart Value Object (SVO) project has adopted the bytecode processing approach to solve the problem : 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; finally, AOP would add yet another dependency (think remote deployement where size is crucial) and doesn't offer the full flexibility of "low-level" bytecode manipulation.

The design makes the SVO independent from the persistence layer (entity EJB, JDO, Hibernate, ...). However, in the current state of development this is not fully implemented yet: work is underway to provide an implementation for entity EJBs.

See by yourself how this package could help you by launching the online SVO demo

This project is part of the Bright Side Framework (http://www.bs-factory.org), whose goal is to provide ready-to-use high level components to quickly build business J2EE applications accessed by rich java/Swing clients on HTTP.

Links:
SVO technical description : http://www.bs-factory.org/BSFDocs/Features/SVO.html
download : http://forge.objectweb.org/projects/bsframework/

after enhanced by JDO, can it be reenhanced by SmartValueObject?

While it's clear that SVO and JDO have similar concepts (flagging objects as
modified on runtime via bytecode enhancement), the scope is different: JDO is
mainly focusing on the persistence mechanism, SVO was designed as a simple
library to optimize the client-server interactions in a rich client
environment. While JDO might be used for this task (I guess), it's not what it
was designed for.

Thanks for the nice implementation of the DTO pattern. Combining MDA and SmartValueObject would be the way, IMO. I'll check SmartValueObject further!

Cheers,
Lofi.

Any plans on making this SDO compliant? SDO does mostly the same thing and is where the standards are going.

Billy

I think we can't make it SDO compliant because, even if the domain is the same, the approach are very different.

SDO use Data Objects to holds the data as a set of properties. We holds the datas within an enhanced Value Object.

The access to datas is done dynamically with SDO:
    
    account.getFloat("balance");

and statically with SVO:
   
    account.getBalance();


We did this project as a solution to a common issue. It's not the only one and it's good to have some non-standard solutions...

<gaten>SDO use Data Objects to holds the data as a set of properties. We holds the datas within an enhanced Value Object. The access to datas is done dynamically with SDO:
    account.getFloat("balance");
and statically with SVO:
    account.getBalance();
</gaetan>

SDO does support static Java interfaces such as Account.

<bea-website>
SDO enables both a static (or strongly typed) programming model and a dynamic (or loosely typed) programming model. This enables a simple programming model without sacrificing the dynamic model needed by tools and frameworks.
</bea-website>

The SDO document on the IBM website goes into this in a little more detail.
http://ftpna2.bea.com/pub/downloads/commonj/Next-Gen-Data-Programming-Whitepaper.pdf

William Louth
Product Architect
JInspired

Yes but it's optionnal and not defined yet :

"While code-generation rules for static data APIs is outside the
scope of this core SDO specification, it is the intent that SDO supports codegenerated approaches for Data Objects."

I imagine they will use some kind of dynamic proxies to navigate through Data Objects and and Data Graph.

Gaetan Zoritchak
Bright Side Factory
http://www.bs-factory.com

This really seems to give us some great new features. But I'm having the same problem (well, it's more kind of a rebel mind problem) for web interfaces. I like to know if there's a framework out there that can easily let me know which fields are modified in the browser form, so that i don't have to do all the check over and over again, and enhancing performace.

We'll implement these smartvalue object sometime next week, let you folks now how it went.

Grtz

When did bytecode engineering get rid of it's own quirks and another layer of complexity ;-)

When did bytecode engineering get rid of it's own quirks and another layer of complexity ;-)

Why is bytecode engineering either quirky or complex? The Java ClassFile structure is defined quite strictly, certainly more clean and clear than something like XML. ;-)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

As well as the interest of the SVO pattern, the demonstration using Java Web Start is really convenient and 'sexy'. The use of JGoodies gives a really nice user experience.