Value Object Assembler

[Arnold Reuser]

Something I always build from scratch for each project is a mapping between my Presentation Model ( implemented as POJO's ) and my Business Model ( implemented as POJO's ).The pattern I use for this mapping is the Value Object Assembler.
What I'm looking for are some hints, best practices and open source projects that will give me a better understanding on how to actually implement the details of this pattern in a generic way.
What I've collected so far, based on my own experience, is that I've noticed that I often implement logic that could be presented in the following sequence :


Presentation Model ( or Business Model ) -> Validation of model
-> Enrichment of model
-> Transformation of model
-> Business Model ( or Presentation Model )

Which is always known as the VET(R)O pattern within SOA architectures
to transform data between the different tiers.
Do you have the same experience? Can you present a more fine grained sequence of logic? Are you aware of any open source projects that focus on this sequence of logic? Or any other remarks related to this problem are appreciated.
[ May 01, 2006: Message edited by: Arnold Reuser ]

[Stan James]

I worked with a home-made generic server gateway that could produce new custom XML output built of any combination of existing fields from existing services. We defined new input request and output response structures in XML files that looked like XSL but were really interpreted by the home-made engine. The overall flow was:

 
accept input request
get the request name and look up the definition
using the request definition
   extract arguments from the request
   call the appropriate service
get the response name and look up the definition
using the response definition
   extract fields from the service outputs
   build the response 

If we had to break a big web page into three or build new pages that used existing data we could define new request/response pairs for each page to retrieve different subsets of the model all in XML. I didn't get to stick around long enough to see how all this XML handling scaled.

Does this sound like what you're doing? I think there are commercial products that do this. Maybe WebMethods? Whatever IBM calls MQSI nowadays?
[ May 01, 2006: Message edited by: Stan James ]

[Arnold Reuser]

Yes indeed, and in particular my question is related to the phase between the extraction of the arguments from the request and the call to the appropriate service.
The extraction of the arguments is in itself not difficult, but in some way you need to determine whether or not the input is valid.
Furthermore its possible that the arguments are not in the correct format to actually call the appropriate service, therefore often a enhancement and transformation is required.
As a result I'm looking for a refinement for the phase between the extraction and the actual call to the appropriate service.

[Stan James]

Ah, much clearer now. It's been about 5 years since I touched that thing but I think it did no validation on the arguments. If the service didn't like what it got it could throw an exception.

I suppose one could specify a certain amount of validation in the input description but I think I prefer the validation in the service. It has the resonsibility to not accept invalid inputs and can't trust the universal input transmogrifier or any other client.

Transformations might be interesting. You could specify various implementations of ArgumentTransformer. Any other ideas? I'd maybe rather see another tiny layer between the generic processor and the called service. Yet, my first preference is to make the clients do the work of providing proper arguments. Is that not practical for you?
[ May 01, 2006: Message edited by: Stan James ]