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:
from("restlet:http://localhost:9080/account/{id}?restletMethod=get";)
.setBody("${header.id}")
.to("bean://myService?method=get");
from("restlet:http://localhost:9080/account/{id}/balance/{bal}?restletMethod=put";)
.setBody("${header.id};${header.bal}")
.to("bean://myService?method=put");
from("restlet:http://localhost:9080/account/{id}?restletMethod=delete";)
.setBody("${header.id}")
.to("bean://myService?method=delete");
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.
