1

We're a defining an architecture for our company applications, so that architecture has to take care of integration with other applications/systems. The first thing that came our mind was to centralize all integration in an ESB (Mule), which would run in standalone mode. However new requirements appeared and the thing is that every application has to manage its own integration's (which are not defined yet, but they shouldn't be very complex).

Now we´re evaluating using either Apache Camel or Mule but in an embedded scenario. Disusing about it with some mates, it isn't very clear to us which is the best (or more suitable) way to set up this architecture. At my opinion, as its responsibility 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:

  1. My application with Camel embedded. If my application has to invoke a web service, for example, I just code it and send it (From(...).to(...) etc)

  2. My application and another application with Camel embedded. If my application has to invoke a web service, and I want to manage all integration 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 misunderstanding how Camel really works so I´ll be glad to hear what I´m wrong about ;)

Namphibian
  • 12,046
  • 7
  • 46
  • 76
user1093643
  • 251
  • 1
  • 3
  • 13
  • I gave an answer below. I tried to keep it short however if you need more information please let me know. – Namphibian Jun 13 '14 at 01:39
  • Can I know why it was decided that each application should manage its own transformation? In my opinion using a centralized solution will be a better one unless there are specific reasons which will force the second solution that you are trying to implement. – Naveen Raj Jun 13 '14 at 06:26
  • Of course a centralized solution is a better option, but it was a decision made by the organization we´re working for (I mean, my company develops apps for that organization). – user1093643 Jun 13 '14 at 06:50

1 Answers1

3

The best architecture for Camel? That depends on your needs. It seems that you have several applications that will need to integrate with each other. So for each application that needs to integrate with another application there will be a integration route.

Lets expand this a little.

Assume we have two applications a Customer Management application and an Order Management application. These two will have to be integrated with each other. Conceptually on a high level there will be two routes for the applications that you need to create and maintain.

Two Application Integration

For such simple integration having the application integrate with each other it makes sense to use camel/mule in the application itself(embedded mode).The amount of integration is minimal.

Since the two applications are now tightly coupled by the integration routes themselves changes in the customer application might lead to changes in the order application. However since the systems are small this is a minimal amount of work.

However if there was more system involved this approach is going to become maintenance nightmare. Lets turn up the complexity a bit.

Lets go to four systems. A customer, order, accounting and shipping system that needs to be integrated with each other. Just adding two more system to integrate will bring your total routes to 12 routes. We doubled the amount of system but we increased the amount of routes by a factor of 6. That is a 600% increase in what can go wrong.

enter image description here

Using a ESB will simplify this design a lot. Hope you understand a little more.

Note: Using camel to just call a web-service from an application is overkill. Rather do this with Apache CXF which is much more suited for this.

Namphibian
  • 12,046
  • 7
  • 46
  • 76
  • @Namphibian- The explanation are good and the diagrams as well. Can you suggest me the application that you are using to draw these diagrams.Is it open source? – Naveen Raj Jun 13 '14 at 06:30
  • @naveenraj I used visio from MS for this diagram. For a open source alternative look for dia. It will do the same thing. – Namphibian Jun 13 '14 at 06:38
  • Thanks @Namphibian for your explanation. I agree that if there are more integrations an ESB will simplify design. But in my scenario we can't deploy a cross middleware for all applications: each application should take care of its integrations. So I wondered which strategy would suit better: using Camel embebed in my apps or deploy another application which uses only camel for routing,etc for each application. The example of invoking a WS was just that, an example of one of the integrations an application could have, but would not be the only one. – user1093643 Jun 13 '14 at 06:47
  • 1
    If you just need web services then embedding cxf into your applications seems to make the most sense. If there are only rare cases where you need more exotic transports then you can perhaps extract these to a separate server using camel to bridge between these protocols and the services your application provides. – Christian Schneider Jun 13 '14 at 08:55
  • @user1093643 in your case I would use the ESB route as much as possible and only do integration between applications as a exception. – Namphibian Jun 14 '14 at 23:55