Smooks Transformation Integrated

[tfennelly]

I completed round 1 of integrating Smooks into the ESB. This included modifying the Trailblazer to use the "SmooksTransformer" for one of the transfomrations.

I've also started and commited a Message Transformation Guide into SVN. I've still to fill out some of the sections in there but at least it's a start. It already has a fair bit of detail on Smooks and how it's used in the Trailblazer.

I'd really appreciate peoples feedback on this please!

As I see it, one of the next big tasks re Smooks integration is that of storing the Smooks transformation configurations in an RDBMS (instead of XML) and fronting that with some sort of admin UI that will make it easier for a human to comprehend what transformations are taking place in a given message flow etc. I think this may be of particular interrest to people like David Degroff. I'll obviously be touching base with Mark before any of this however, because there may be other priorities.

T.

[marklittle]

"tfennelly" wrote:
I completed round 1 of integrating Smooks into the ESB. This included modifying the Trailblazer to use the "SmooksTransformer" for one of the transfomrations.

I've also started and commited a <a href="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/docs/MessageTransformation.doc">Message Transformation Guide</a> into SVN. I've still to fill out some of the sections in there but at least it's a start. It already has a fair bit of detail on Smooks and how it's used in the Trailblazer.

Congratulations Tom. However, what's the service API look like? How will someone go about replacing this transformation service with another one? I know you have ideas around this, so a separate forum discussion would be good. If this information is in the guide, just point me there. If it isn't, then hopefully the fallout from the subsequent discussion can be used to update the manual.

I'd really appreciate peoples feedback on this please!

As I see it, one of the next big tasks re Smooks integration is that of storing the Smooks transformation configurations in an RDBMS (instead of XML) and fronting that with some sort of admin UI that will make it easier for a human to comprehend what transformations are taking place in a given message flow etc.

Add some JIRA tasks around your ideas, and assign them to 4.1. I'll take a look later today and we can have a chat about priorities. We already know that we need to improve our tooling, so I can see some of this happening in the 4.0 release.

I think this may be of particular interrest to people like David Degroff. I'll obviously be touching base with Mark before any of this however, because there may be other priorities.

T.

[tfennelly]

However, what's the service API look like?

Sorry about the delay.... I was busy fixing the build ;-)

Transformation Service API

SmooksTransformer implements the TransformationService interface.

How will someone go about replacing this transformation service with another one?

I suppose that depends on whether we're talking about the current or a future architecture... Currently, as far as the ESB is concerned, Transformation Service implementations need to be ActionProcessors same as any other ActionProcessor (terrible name ;-( ).

So, from a code perspective, replacing any ActionProcessor with another ActionProcessor is seemless because they all implement that interface. From a configuration perspective, it'd be a case of replacing the processor on the "Action" configuration to reference that "different" transformation service - thereby getting it to transform (process) the message instead. Of course, the "different" transformation service would need to work against the same action properties.

This should all become more decoupled in our future archs once we get all the "Action" configurations into the registry and get our normalised message structures + EPRs etc in there with the routing info (and other message metadata).

[marklittle]

Thanks Tom.

I think we have different expectations of what gets stored in the Registry by the way.

[tfennelly]

I think we have different expectations of what gets stored in the Registry by the way.

Probably not Mark - I was just thinking out loud and loosely there. Don't mind me :-)

[marklittle]

"tfennelly" wrote:

I think we have different expectations of what gets stored in the Registry by the way.

Probably not Mark - I was just thinking out loud and loosely there. Don't mind me :-)

Hey, variety is the spice of life ... apparently ;-)