From Smooks

This section looks at the different ways in which Smooks can produce "Output" from the Filtering process.

Smooks can "present" output to the outside world in the following ways:

1. "In-Result" Instances: Returned in the Result instances passed to the Smooks.filterSource method.
2. During the Filtering Process: Output generated and sent to external endpoints (ESB Services, Files, JMS Destinations, DBs etc) during the Filtering process. This is where message fragment events are used to trigger routing of message fragments to external endpoints e.g. when Splitting and Routing fragments of a message.

A very important point to remember is that Smooks can generate output/results in either or both of the above ways, all in a single filtering pass of a message stream. It doesn't need to filter a message stream multiple times in order to generate multiple outputs/results. This is critical in terms of performance/efficiency.

"In-Result" Instances

A look at the Smooks API reveals that Smooks can be supplied with multiple Result instances:

public void filterSource(Source source, Result... results) throws SmooksException

In terms of the types of Result that Smooks can work with, we're talking about the standard JDK StreamResult and DOMResult types, as well as some Smooks "specializations":

1. JavaResult: Result type for capturing the contents of the Smooks Java Bean context.
2. ValidationResult: Result type for capturing Validation Results.
3. StringResult: Simple Result type used mainly when writing tests. Simple StreamResult extension wrapping a StringWriter.

This is obviously the most common method of capturing output from the Smooks filtering process.

NOTE:

As yet, Smooks does not support capturing of Result data to multiple Result instances of the same type. For example, you can specify multiple StreamResult instances in the Smooks.filterSource method call, but Smooks will only output to one of these StreamResult instances (the first one).

StreamResults / DOMResults

These Result types receive "special" attention from Smooks. As Smooks process a message Source, it produces a stream of events. If a StreamResult or DOMResult is supplied in the Smooks.filterSource call, Smooks will (by default - see default.serialization.on global parameter) serialize the event stream (produced from the Source) to the supplied StreamResult or DOMResult as XML. Obviously, Visitor logic can be configured/applied to the event stream before serialization.

This is the mechanism used to perform a standard 1-input/1-xml-output character based transformation.

During the Filtering Process

Smooks is also able to generate different types of output during the Smooks.filterSource process i.e. as it is filtering the message event stream and before it reaches the end of the message. A classic example of this being when it is used to split and route message fragments to different types of endpoints for processing by other processes.

So one might wonder why Smooks doesn't "batch up" the message data and produce all the results/outputs after filtering the complete message. Well the answer is straightforward enough:

1. Performance!!
2. It's just easier this way because you can utilize the message event stream to trigger the fragment transform and routing operations.

Consider an Order message that has hundreds of thousands (or millions) of Order Items that need to be split out and routed to different departments in different formats, based on different criteria. The only way of handing messages of this magnitude is by streaming the process.