For sending to the proprietary broker, you'll want to implement a Producer class. At minimum, you need a Component and Endpoint implementation. If you're using a singleton connection that's shared amongst all clients in a single JVM, then you can use a static class variable or just pass around the connection to each created Endpoint and Producer.
>From your Producer, you'll translate the Camel Message headers and body (and whatever else may be relevant) into the proprietary API. As for endpoints, I'd recommend making a URI format that's easy to use and reflects the more common parts of what gets addressed in your broker. For instance, the JMS components use the scheme specific part of the URI to contain the queue or topic name/path. You'd use the query parameters for any additional configurations. I'd recommend taking a look at the bean component in camel-core for some rather simple component stuff. You could also take a look at the camel-sjms component for a more message-oriented type of component. If you go the ActiveMQ route, the neat thing is that you can add your custom Camel components to ActiveMQ and add it as a Messaging Gateway to simplify your messaging needs. Then you can just use a messaging protocol that ActiveMQ supports, or you can still use Camel to route to ActiveMQ itself. On 30 June 2014 12:17, Jon Mithe <[email protected]> wrote: > Hi, > > I thinking about using camel but struggling a bit / getting a bit lost, > wondering if anyone can help me get some direction on my problem > > I have a client that connects to multiple servers via 1 connection to a > proprietary message broker. > > Essentially the app connects to broker and TCP communication is multuplexed > over the connection in channels specified by the broker config (broker > connects to all the servers locally). > > Channels are quite raw, proprietary API's over proprietary protocols or > protobuff, often channels use own ssl and authenticated sessions (i.e. > connect to remote server via broker, exchange logon message / auth). > > The system architecture is getting large enough that integration is > becomming problematic / painful. So I want to improve the situation by > adding some integration framework / patterns. > > I'm thinking of adding camel into the main app and then servers to decouple > API's from the transport mechanism. But all the custom components I see > are > mutually exclusive, i.e one thing connects to another thing using 1 > connection. > > ==> So I'm unsure how the idea of one connection to a server that spawns > multiple connections off of tif fits in with camel / how I would start > architecting my camel components. > > Especially as the message broker is essentially optional, i.e. I could > connect to all servers directly if need be. Suppose, this maybe more of > camel proxing issue, need to google that. > > I'd love to get a generic broker in there and start removing some of the > proprietary protocls but I dont think that is gonna happen anytime soon. > It > may be possible with some custom plugins to deal with the proprietaryness. > Need to probably chat to ApacheMQ forums. > > Any help / insight on my problems would be great. I'm a bit stuck as where > to go from here. Probably going to install ApacheMQ and write a hello > world > app -> multiple servers to see a more perfect solution to learn / > understand > more. > > Thanks, > Jon > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Help-understanding-a-custom-component-tp5753068.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- Matt Sicker <[email protected]>
