> 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?
> > 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.
> > 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".
> Best regards - Claus
Thanks again.
--
Gonzalo Diethelm
