We're a defining an architecture for our company applications, so that architecture has to take care of integrations with other applications/systems. The first thing that came our mind was to centralize all integrations in an ESB (Mule), which would run in standalone mode. But new requirements appeared and the thing is that every application has to manage its own integrations (which are not defined yet, but they shouldn't be very complex). Now we´re evaluating using Apache Camel or Mule but in an embebbed scenario. Discusing about it with some mates, it isnt very clear to us which is the best (or more suitable) way to set up this architecture. At my opinion, as its responsability of each application, I would integrate Camel directly in my application (as a library); but they say it´s a better option to deploy Camel in a separate project. These are the scenarios, as I see them:
My application with Camel embebbed. If my application has to invoke a webservice, for example, I just code it and send it (From(...).to(...) etc) My application and another application with Camel embebbed. If my application has to invoke a webservice, and I want to manage all integrations through Camel, I think I have to call the camel project (by JMS, or calling an interface it exposes), define a route in that project which says: when I read from X (the interface im calling) call this WS. I mean, it adds more complexity when I think it´s not needed. Probably I missunderstanding how Camel really works so I´ll be glad to hear what I´m wrong about ;) -- View this message in context: http://camel.465427.n5.nabble.com/Best-suitable-architecture-using-Camel-tp5752219.html Sent from the Camel - Users mailing list archive at Nabble.com.
