On 03/29/2011 12:48 PM, 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.
Depending on the app, I usually use either Winstone or Jetty-runner
instead of a full blown appserver. Both are combined with spring.
With winstone I use the winstone-maven plugin to create a jarfile that
contains all dependencies. I then deploy the jar using a custum
puppetscript that gives the service a port number and builds the
surrounding infrastructure - i.e. a userid, a directory to run the
service in and an init.d script for the service.
Thus a run my services all as different processes on my hosts instead of
all existing in a single JVM. This makes it easy to debug and upgrade
single services without worrying about sideeffects - and I do not have
to learn OSGi.
It also makes it very easy to keep all dependencies in my pom file.
I haven't gotten quite as far using jetty-runner for my own wars, but it
works very well for Solr.
If someone has a simple maven setup for doing the same thing as the
winstone-maven plugin does but for Jetty, I'm all ears :)
Regards,
Tarjei
>> 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.
>
--
Regards / Med vennlig hilsen
Tarjei Huse
Mobil: 920 63 413
