Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4D91CD69.1040100@catify.com>
Date: Tue, 29 Mar 2011 14:15:37 +0200
From: Claus Straube <claus.straube@catify.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: users@camel.apache.org
Subject: Re: Service architecture
References: <A2304C0501639840B9D248F682E60C65304DA5@aowmail1.dcv.net>
 <4D91A6E1.3030701@catify.com>
 <A2304C0501639840B9D248F682E60C65306153@aowmail1.dcv.net>
 <4D91C153.4000101@catify.com>
 <A2304C0501639840B9D248F682E60C653063AB@aowmail1.dcv.net>
In-Reply-To: <A2304C0501639840B9D248F682E60C653063AB@aowmail1.dcv.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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