Article: Structured Event Streaming with Smooks
- Share
-
- |
Read later
My Reading List
The Smooks project has been around for a while but probably started to come to prominence when JBossESB used it as the default transformation engine. Over the last year we've seen other open source ESBs also add support for Smooks transformation technology as well. However, as this InfoQ article from Tom Fennelly, the Smooks lead, shows Smooks is capable of much more than just transformation.
Read Structured Event Streaming with Smooks on InfoQ.
Smooks is 90ties retro?
by
Anthavio Lenz
Re: Smooks is 90ties retro?
by
Tom Fennelly
Re: Smooks is 90ties retro?
by
Ivan L
Stax Support [was: Smooks is 90ties retro?]
by
Tom Fennelly
oh and any plans to move to Stax Reading/Writing?
I've done some playing with a Stax based filter and for some use cases, I think it can bring quite significant performance increases. For others, it's of no benefit at all. For many users however, it's actually irrelevant (performance aside) because unless they are actually writing custom visitor logic, they don't actually see the details of SAX, Stax etc... that's hidden away under the hood.
Re: Smooks is 90ties retro?
by
Anthavio Lenz
I work on ESB like projects screaming for some standardized way of converting messages, but smooks looks like clear overkill to me. Reader and writers of different formats are good, but rest of smooks only complicates job.
Re: Smooks is 90ties retro?
by
Tom Fennelly
1. Writing your own custom code (to do?),
2. Handcoding Stax (or manually using a CSV jdbc driver),
3. And "programmed converter" in java binding case (whatever that is exactly).
Is more maintainable than:
1. Smooks configuration of 20 to 30 lines of XML.
I guess we all have different ideas re what is maintainable and what is not.
Re: Smooks is 90ties retro?
by
Anthavio Lenz
Is it possible even use xml schema to validate sources and products of transformations? What about per (one or more) record transactions?
Re: Smooks is 90ties retro?
by
Anthavio Lenz
1. reader, router, binder... could be done in java code, not current xml
2. some sort of more controlled way over whole transformation. Not only visitor pattern where are you limited only to current event and some custom made context. In stax you can chain easily chain readers and writers and make nice pipeline on one stream of events. Plus you can whenever you want stop consume stream. (in case of invalid or malformed message) Great, but not possible in smooks now.
Re: Smooks is 90ties retro?
by
Maurice Zeijen
Directly using a stax, sax, dom, csv or any other reader has the disadvantage that you are writing code that is very specific to the data format that you are reading. Switching format, which does happen, isn't so easy then. Writing code that can process two different formats in the same way isn't easy to do then either. You could, of course, write an abstraction layer to solve that. However Smooks already provides that and a lot more. So why take the trouble to reinvent the wheel? Another is that code that uses low API readers get a lot complexer and there for a lot less readable and lot harder to maintain, when the complexity of the input data model increases. A great thing about Smooks is that complex data models still result in a consistent easy to read, easy to maintain configuration.
Smooks especially fits very good in ESB environments. Because ESB's are also about declarative configuration they both fit naturally togehter.
It is correct that a good Java API is just as important as a good XML configuration. At the moment the Smooks configuration API is a bit complex because of it's highly flexible nature. But you can expect that in the future Smooks will have an improved Java API in a similar way as the new XML namespaced based configuration improved the XML configuration.
It is correct that hard coding the properties in the XML file isn't that great because the refactoring won't work in those places. Hopefully the Smooks Eclipse plugin will provide a solution for that in the future. It could also be that Smooks will get an annotation based way to do the bean binding directly in the Java beans.
Per record transactions can be done within Smooks. However no default visitor is available for that now. It is only a small deal to provide a feature like that.
Chaining readers and writers, if I understand you correctly, is already possible. For instance the DomModelCreator visitor does that. It creates DOM model from the selected node that can be used in other visitors like the freemarker visitor.
The Smooks team has talked about the feature where you can stop consuming a document on a certain condition. That will probably be available in the Smooks 1.2 release.
Smooks is a very good solutions for processing any structured data model. But there is always room for improvement and the Smooks team, hopefully with help from outside contributers, will work hard on it.
Re: Smooks is 90ties retro?
by
Tom Fennelly
I don't think we would ever suggest that Smooks is the answer to all transformation needs that anyone would ever have. I think it's inevitable that you'll end up rolling your own in some situations and that some transforms would be more easily implemented outside Smooks. There's no silver bullet.
I think you are coming to this from the position of someone that has effectively written their own "Smooks", and you're happy with your own solution. It also sounds like you're coming with the philosophy/preference for a Java based config, which is perfectly valid too. I don't think everyone starts from a position of already having a solution of their own (that they are happy with), or a preference for a non-XML based configuration. Smooks fills a gap here!
Your comment re stax vs sax and not being able to abort sax is totally valid. This is a shortcoming that others have identified too and is something we plan on addressing. As I said in an earlier post... we plan on introducing stax support i.e. Smooks is not wedded to any of these technologies and can take advantage of them all. It's a process of evolving the project!
I'd love to see your solution to one of the problems looked at in the article i.e. where you split a huge CSV message (or XML/EDI/Java... whatever) out into Java objects and route them to e.g. a JMS destination (or file or database - in a controlled manner!!). I mean that genuinely... I would be interested in seeing how you've done it in a way that can be standardized into a library that others can reuse easily (i.e. what we're striving to achieve with Smooks), and is also consistent with solutions to a number of other use cases. Maybe you could post your equivalent solution here, or email it to us on the Smooks mailing list.
Very simple and useful
by
Tomasz Juchniewicz
Don' be afraid of <50 lines od XML! ;-)
Re: Very simple and useful
by
John Dondapati
Love the xml configuration and love Smooks. Good work Tom!
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Concurrency in Clojure
Stuart Halloway May 17, 2013
Confessions of an Agile Addict
Ole Friis Østergaard May 16, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think