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? -- View this message in context: http://www.nabble.com/How-to-partition-business-logic-into-components-t1535641.html#a4172222 Sent from the ServiceMix - User forum at Nabble.com.
