Hi Gonzalo, I am a big fan of camel so don´t understand me wrong.
If you are using JEE all over the place then you should at least think about migrating to JEE6 I am regularly reading the blog prosts of Adam Bien and from what he writes the modern JEE implementation could be a great platform. I never really did JEE as it really sucked below EJB 3 but I think it has become quite good. Using JEE would allow you to use the knowledge your developers have with it. Having said that camel will also be a great platform to build your applications on. Especially when you do the step to OSGi nd Karaf like Achim suggested. OSGi has a steep learning curve though so be prepared for some problems at the start. For async Services I really like camel´s pojo messaging with jms. Where you use a plain java interface for the handler. The serialization can be Java serialization or JAXB. This is very simple to setup. For synchronous calls you have to decide between SOAP and REST or even Spring HttpInvoker. If you want to create client code then SOAP will be better. If you go java first then REST or HTTPInvoker are simpler. For multi language SOAP again may be easier but REST will also be possible with e.b. JAXB seralzation. So what I propose is that you invite specialists for the apache stack (Camel, CXF, Karaf) and specialists for JEE and let them create a POC scenario. Then you can decide which looks better. >From my point of view I think JEE will be simpler to get running but less >innovative and less open. The apache stack above will be more complex to setup >but provide more flexibility. So it will be a tradeoff like always in >architecture. Christian http://www.liquid-reality.de -----Ursprüngliche Nachricht----- Von: gonzalo diethelm [mailto:[email protected]] Gesendet: Montag, 28. März 2011 14:51 An: [email protected] Betreff: Service architecture This is my first post to this list, and I declare myself a Camel newbie. Let me start by first saying that Camel is great; a big thanks to the whole team for such a wonderful piece of engineering. I have been searching for some time now for a new way (to me) to build a service architecture, to be used _within_ the company; that is, this is not intended for web facing services, at least not directly, but more for the "pure" business logic layer. My goals for this service architecture are: 1. Light-weight. 2. Easy to use for callers of services. 3. Support for synchronous (RPC) and asynchronous (MOM) invocation styles. 4. Ability to invoke services from different languages (desired). Thanks in advance for any wisdom shared, and best regards. -- Gonzalo Diethelm
