camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gonzalo diethelm <gdieth...@dcv.cl>
Subject RE: Service architecture
Date Tue, 29 Mar 2011 10:48:32 GMT
Hi John, great insights (and confirmations) of my guesses...

> I too want some kind of container support for my java apps that are run
> from jars.  The use of initd and all works but it doesnt feel right -
> whereas a container like tomcat does.  I am considering OSGI containers -
> but lack any experience there.  J2EE app servers seem too heavyweight.  So
> much container that I will never use and I would sooner gnaw off my own
> arm than do EJBs to myself

Exactly my feelings. In fact, we DO use EJBs "to ourselves" all over the place, and it sucks
(or so it seems to me) in terms of performance and maintainability.

> In terms of exposure I would go for REST over soap all day long.  As soon
> as you go for SOAP you have to accept that all SOAP toolkits suck
> differently.  I fully agree with the REST zealots - it is blissfully
> simple making it easy to understand and consume.

Great, thanks for confirming this.

> I'm not sure I have seen
> a CAMEL component that gives you the sophistication needed - or I haven't
> seen an example.  I would generally build an app for this kind of exposure
> - either Spring MVC or - and I think I am warming more to this - a grails
> app.  I like the grails app because it gives you the URL mapping config
> explicitly.  Spring would tempt you to use the annotations which are cool
> - but distribute your URL mappings throughout the code base

Could you expand on this? The proof-of-concept I am working on has:

* A RESTful service that exposes queries and updates on a set of entities (accounts, balances,
etc.).
* A servlet client that uses this service to provide information to a web app. The web app
itself is not yet built (and that is not my cup of tea anyway), but my design implies that
the servlet should be able to call my RESTful service in order to access its business logic.

I have concluded that a good way to build the client part (my servlet) is via Spring; it provides
templates for all the ways I foresee to access my services (REST and JMS) and it makes it
simple to call all the services by using "{}" placeholders.

I am still not sure how to package this thing. It seems to me a good architecture for my example
would have all these layers:

1. A pure POJO defining a model object (such as an Account).
2. On the service side, POJO #1 is used in conjunction with an ORM layer (Hibernate, JPA,
etc.) to access the RDBMS.
3. On the client side, POJO #1 is used to encapsulate data returned from my service.
4. On the client side, I would also need an AccountManager class to encapsulate all the REST
comings and goings, so that any code that has to call the service can simply do it through
an instance of this class. This way the URL mappings would be consolidated in a single place.
5. This would all have to be packaged smartly, so that the client side does not require any
unneeded JARs (such as Hibernate).

This is what I meant when I asked about "the stubs on the client side". If I change POJO #1,
I would have to modify AccountManager; if I wanted to keep track of this automatically, things
start looking pretty close to more traditional Web Service tooling.

> You have Websphere and you have my sympathies.  I have been dealing with
> that lately and its made me consider a career change!!!

I try to look at it as a black box, but I can see the operations guys slowly loosing their
minds managing the beast...

> Hope this helps - significantly to coax contributions from some of the
> guys on here.  They seem pretty good to me

It helps a lot, thanks again.

-- 
Gonzalo Diethelm


Mime
View raw message