On 5/1/06, Nicanor <[EMAIL PROTECTED]> wrote:
I'm very new to ServiceMix, although I'm an experienced Java developer. I
installed SM, ran a few of the examples, and read quite a bit of the
documentation. Now I'm ready to plan my first pilot project and would like
suggestions for an effective component design.
Here is the scenario (somewhat simplified to get to the criticial
decisions). There is a piece of lab equipment that emits structured data
over a LAN by making a TCP/IP connection to a configured host:port. The
protocol is very simple: it just connects, sends a small "start of
transmission" pattern, then a stream of structured data, followed by a "end
of transmission pattern" and the close of the socket. The structured data is
well-defined but not XML. I want to use SM to accept such sessions, convert
the data into XML messages, and route the messages to various service
engines configured for processing the messages in various ways.
I can build a Binding Component that conducts this trivial protocol on top
of TCP/IP, and I can build logic that converts the structured data into XML.
But I'm not sure whether it's best to place these two tasks in the same
component or not. One approach seems to be to write a Service Engine that
transforms this kind of structured data into XML, and a separate Binding
Component that just handles the protocol. But since the content is not
already XML, I think the binding component would need to route the non-XML
content as an attachment (or use some other trick) to get it to the SE for
conversion to XML.
Another approach would place the XML conversion directly into the binding
component, but that seems have serious "separation of concerns" issues, and
seems to go against the intent of an ESB.
It would also be nice to be able to easily handle this kind of strucured
data coming from other sources (files, emails, ...) for testing and
demonstration purposes. So separting the logic of handling the TCP/IP
protocol with its start-of-transmission, end-of-transmission logic from the
routing of the non-XML message itself sounds like a good thing. That sounds
like 3 components: one to handle the socket protocol, one to route the
non-XML legacy messages, and one to convert the messages into XML for
further processing by other components.
Suggestions? Is there a better alternative to "attachements" for routing the
non-XML content before it gets tranformed into XML?
Scott,
I agree that you'll need a Binding Component (BC) to handle the
protocol for accepting the messages. This is exactly the intended use
of BCs from the JBI spec. I also agree that you should develop some
thing to handle the conversion of the message into an XML format. IMO,
I'd make this convertor thing an independent piece of software that is
simply utilized for the conversion. Turning the convertor thing into a
Service Engine (SE) is not necessary. I would simply make use of the
convertor from the BC to handle the conversion.
Consider the EJB model for a moment as a point of comparison. IMO it
is never a good idea to turn all of your software modules into EJBs,
just make use of your software components from within EJBs. This eases
the testing of the software module itself outside of the EJB and it
makes reuse that much easier. The same is true here - make the
software module that handles the conversion something that works
outside the model of a JBI BC and just make use of it from the BC that
you're developing.
As for creating something to route the non-XML messgages, this is the
job of ServiceMix, or more to the point, the Normalized Message Router
inside of ServiceMix. Consider the fact that with the BC and the
convertor, your flow would look like this:
lab equipment --> host:port/BC --> other ServiceMix components
As far as the problem described above, this should be all that is needed.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
