While looking through the server-side representation of data objects for a middleware server, I noticed something that really set me off…
When my simple components (CRUD + custom-operations) were deployed to the middleware server, the marshaling code was all generated Java code.
What struck me was the presence of a TON of generated repetitive code – and all I could think was – why didn’t they use a table??
What I was thinking – for each data value-object that needed to be marshaled to/from the server – can’t it be represented as attributes in a table (one entry for each parameter) which is then iterated by the marshaling engine. The engine would evaluate each parameter type and size, do the appropriate marshaling, then go onto the next parameter.
The advantage of a marshaling table:
- One place to focus any maintenance – the engine.
Fix a bug in the engine and all legacy components will benefit from the fix.
- One place to focus any performance optimizations – the engine.
Performance fix here will benefit all components.
- Compact representation – the only thing which grows with the number/complexity of the components is the table itself.
- Both future-proofing and easier support for legacy components.
With a version tag in the table in the component repository, a newer version of the engine with new features will have a chance to ‘drop back’ when encountering an old component.
Anyways – that design team had an architect or implementer that liked code generators.
This guy likes being table driven as much as possible.
BTW – the CORBA and COM support within the PowerBuilder runtime is all table driven with a single marshaling engine (which I wrote AGES ago).