camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Straube <claus.stra...@catify.com>
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

from("restlet:http://localhost:9080/account/{id}?restletMethod=get,delete")
.setBody("${header.id}")
.choice()
	.when(header("CamelHttpMethod").isEqualTo("get"))
		.to("bean://myService?method=get")
	.when(header("CamelHttpMethod").isEqualTo("delete"))
		.to("bean://myService?method=delete");



>   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 
CAMEL-3701).
>> from("restlet:http://localhost:9080/account/{id}?restletMethod=get")
>> .setBody("${header.id}")
>> .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: 
http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/130-restlet.html

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.
>


Mime
View raw message