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 12:15:37 GMT
On 29.03.2011 13:59, gonzalo diethelm wrote:
>>> 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:
> Great, this works. And I guess you meant that you would create one endpoint for each
operation, right?
For me it's more transparent - but you can do this like you want ;) 
Something like this would work as well


>   Oh, and this only works with restlet v1, right? I was unable to make Camel work with
restlet v2.
I worked only with v1, but with camel 2.7.0 v2 should work, too (see 
>> from("restlet:http://localhost:9080/account/{id}?restletMethod=get")
>> .setBody("${}")
>> .to("bean://myService?method=get");
> The only weird thing I am seeing is warnings such as:
> com.noelios.restlet.http.HttpConverter addAdditionalHeaders
> WARNING: Addition of the standard header "User-Agent" is not allowed.
>   Please use the Restlet API instead.
> Any ideas?
Here're the restlet header vars:

I think this is the key to remove these warnings.
>>> 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 :)
> It is just that I would like the team building the clients not to think in terms of a
service bus or integration, but in terms of simple RPC.
>>> 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.
> I guess some testing (on my part) is called for.

View raw message