camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Service architecture
Date Wed, 30 Mar 2011 08:44:42 GMT
Hi Gonzalo

Nice to meet you at TSSJS, and signing your copy of the Camel in
Action book. Now you gotta go to Canada to have Jon sign it as well :)
Or stop by DC next month for the Camel One conference.

Anyway I can see this thread has picked up and a lot of good feedback.

The one item I would object against was that it was mentioned that an
Apache stack would be more complex to setup than JEE. I really don't
see that. It really depends on a per product basis comparison. Some
JEE stacks is terrible heavy and complex to setup, and others is more
lean and simpler. Likewise it depends a bit what you put in your
Apache stack. If you eg use Apache ServiceMix, its just a matter of
unzipping and running the start script. Likewise for Apache Tomcat its
also just to unzip and run its start script. Then you can deploy your
Camel application as plain WAR files that its a very solid and proven

The point with Camel is that its not a choice of either or - Camel is
a lightweight framework which you host in your server of choice. So
you can use both. Camel running in whatever server/infrastructure you
like - that server could be JEE or it could be any other, in the
cloud, etc. its your pick.

Usually this allows you to pick a server infrastructure that your
operations team may already support and use. Often its not "very easy"
to introduce a new server infrastructure. So being able to re-use
existing is a major win with Camel.

Also Camel allows you to tap into the enterprise features of your
server infrastructure, whether its clustering, management,
provisioning, hot-deploy, monitoring, security etc. We dont try to
reinvent the wheel here with Camel.

On Mon, Mar 28, 2011 at 2:50 PM, gonzalo diethelm <> wrote:
> 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).
> The first point is what really got me started in this search.  Everything we do today
is based on J(2)EE, and it seems to me more and more that the overhead we pay for that is
enormous.  So it has been with much joy that I have been getting more deeply into Camel,
which I have known for the past two years.  The final catalyst for me to get into Camel with
more gusto was attending TSSJS at Las Vegas this month, where I met with James and Claus,
and got a much better feeling for what Camel can deliver.
> So what I envision as a basis for this architecture of services is this:
> 1. Each service is a bundle running on an OSGi container; there could be one or more
containers running on one or more JVMs, on one or more servers.
> 2. Each service could export its entry points on several endpoint types; at least one
type for RPC (SOAP, REST, etc.) and one type for MOM (basically JMS).
> 3. I MIGHT want to support "standard" web services (SOAP), although I am more inclined
to provide a RESTful interface for my synchronous services.
> 4. I would like some level (not fully defined yet) of resilience built into the architecture.
> 5. I require the ability to monitor the running state of a deployment of services, and
take action against certain events (such as "service down").
> So, I come now to my specific questions, some directly related to Camel, some more generic:
> 0. First off, does it really make sense to turn my back to J(2)EE?  I know I would be
giving up a significant amount of "baseline", but I am really hungry for some lean and mean
architecture.  Opinions?
> 1. How do you feel about RESTful vs. SOAP?  Do you think it is a good idea to ignore
frameworks such as CXF and go with something like jetty for my (RESTful) RPC endpoints?
> 2. How do I build the client part for the REST services? One (very common) user of these
services will be a servlet, invoked from a web page, that will ask one or more services for
data.  I don't think it makes a lot of sense for these clients to have a Camel instance embedded
(or does it?).  So, how do I go about writing the equivalent to my stubs on the SOAP world,
to make sure I am invoking the REST services with the correct parameters?
> 3. Same question applies for a client that will invoke a service asynchronously.  Say
a client will use a JMS endpoint to send a message to a service; should that client have a
Camel instance embedded into it, just to be able to pump a JMS message?  It LOOKS much easier
having Camel there, but I am worried about my clients becoming too fat.
> 4. Is OSGi a good way to deploy services?  Can I really expect to be able to forego
having a J(2)EE application server (WebSphere, gasp!) and replace that with lightweight OSGi
containers? Are they really that lightweight?
> I understand I am being a little vague in my description, but I don't really know where
exactly more detail would be needed; I guess my mind has become a little brittle, after all
these years of "pure" J(2)EE.  Let's get the ball rolling with this information and I will
provide more if required.
> Thanks in advance for any wisdom shared, and best regards.
> --
> Gonzalo Diethelm

Claus Ibsen
Twitter: davsclaus
Author of Camel in Action:

View raw message