camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Straube <>
Subject Re: Service architecture
Date Tue, 29 Mar 2011 11:24:03 GMT
On 29.03.2011 12:58, gonzalo diethelm wrote:
>> Hi Gonzalo.
> Hi Claus, thanks for your insight.
>>> 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?
>> If you feel hungry - do it. I think you can do everything without JEE in
>> a smart way, too. ;)
> Great.
>>> 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?
>> I think there is no REST vs. SOAP. They have both advantages and
>> disadvantages. With camel you're free to provide both with a little more
>> effort. If you only want to provide simple CRUD style services, REST
>> seems a little bit easier to use. And in combination with camel and
>> jetty (the jetty component) you can do great things like internally non
>> blocking sync calls.
> Excellent. And yes, until now all I see in my requirements are CRUD services.
> One thing I have not been able to figure out is how to expose all these CRUD services
over jetty. Just as an example, let's say I will handle account objects and will want to support
three actions on them:
> GET /account/{id} =>  retrieve that account
> PUT /account/{id}/balance/{bal} =>  update that account's balance
> DELETE /account/{id} =>  delete that account
> How many end points do I need to expose with a from("jetty")? If it is only one endpoint
for all actions (which would be great), how do I route to the proper bean method given the
HTTP method and the set of parameters I received? If it is one endpoint for each action, how
do I specify the endpoints so that they are differentiated by their HTTP method and URL parameters?
I don't know, if this /account/{id} stuff works with jetty, but it works 
well with RESTLET (wich starts an internal http server and is a REST 
component by default). I would create for all operations a single 
endpoint. They could look like:




The placeolders in the curly brackets are always stored as variable in 
the message header. Of course you can put get and delete together, but 
then you have to do some routing with choice on the "CamelHttpMethod" 
header var. The 'myService' is your Spring service while 'myService' is 
the bean id.
>>> 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?
>> It makes sense to have a camel context in each service. It light weight
>> and extremely useful. Creating a REST interface with Jetty or RESTLET.
>> It looks to me, if your services are very fine grained - so if a service
>> consists of an interface and some logic to get data into or out of a db,
>> you could think about writing your services completely in camel (as a
>> camel route).
> I am leaning more towards using pure Spring (REST / JMS templates) to invoke the services;
it seems more natural to me and I think the developers would find it an easier path.
I don't see why this should be easier - but okay :)
>>> 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.
>> I don't think camel makes your client fat at all. The footprint of camel
>> is very low. The only thing is - you will have some more jars in your
>> classpath (which is no issue, if you're using OSGi).
> OK.
>>> 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 think it is. They're leightweight (of course the create overhead
>> compared to start a Main class). Try it out.
> I definitely will. Thanks for clarifying this for me; this area is where my expertise
is the least (close to zero), and to my newbie eyes OSGi seems "too good to be true".
I'm not sure if your services have a good granularity to deploy each of 
them as a single application in an OSGi container, because there is some 
little overhead to make them ready for OSGi.
>> Best regards - Claus
> Thanks again.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message