camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <>
Subject Re: Service architecture
Date Tue, 29 Mar 2011 09:36:33 GMT

just my 0.02$ on a container/runtime.
My best experience as runtime for Camel is to use Karaf.
If you need more out of the box components like ActiveMQ and so forth
you might also consider to use Servicemix.

regards, Achim

2011/3/29 John McDonald <>:
> I was hoping people with more insight into this would contribute - its a good set of
questions and this forum is pretty good so I would have appreciated their thoughts and musings.
 So to ignite things  I will chip in.
> I too want some kind of container support for my java apps that are run from jars.  The
use of initd and all works but it doesnt feel right - whereas a container like tomcat does.
 I am considering OSGI containers - but lack any experience there.  J2EE app servers seem
too heavyweight.  So much container that I will never use and I would sooner gnaw off my
own arm than do EJBs to myself
> In terms of exposure I would go for REST over soap all day long.  As soon as you go
for SOAP you have to accept that all SOAP toolkits suck differently.  I fully agree with
the REST zealots - it is blissfully simple making it easy to understand and consume.  I'm
not sure I have seen a CAMEL component that gives you the sophistication needed - or I haven't
seen an example.  I would generally build an app for this kind of exposure - either Spring
MVC or - and I think I am warming more to this - a grails app.  I like the grails app because
it gives you the URL mapping config explicitly.  Spring would tempt you to use the annotations
which are cool - but distribute your URL mappings throughout the code base
> You have Websphere and you have my sympathies.  I have been dealing with that lately
and its made me consider a career change!!!
> Hope this helps - significantly to coax contributions from some of the guys on here.
 They seem pretty good to me
> On 28 Mar 2011, at 13:50, 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
>> 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

View raw message