In terms of the expansion - i assume its the Grails v Spring thing - so here
goes
The annotations in Spring look great - you can specify what method they should
match, mapping variables and paths onto the pojo methods and parameters. Very
sexy. My concern is that when you are trying to get a one-shot view of how the
mapping works you could potentially have your annotated directives decorating
several classes which together form this mapping. To understand all the
mapping you have to visit all the classes and be confident that you have done
so. Not a super issue - we would all tend to follow a convention that helped
in this - e.g. all the controllers in the same package?
Grails is like Rails in so much that you have a mapping file. All your URL to
method mappings appear there so you know where to go and that when you do its
complete. That kind of certainty appeals to me.
Thats not to rubbish Spring MVC by any means - just my preference and rationale
On 29 Mar 2011, at 11:48, gonzalo diethelm wrote:
> 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
>
