Hi, just my 0.02$ on a container/runtime. My best experience as runtime for Camel is to use Karaf. If you need more out of the box components like ActiveMQ and so forth you might also consider to use Servicemix.
regards, Achim 2011/3/29 John McDonald <mcdon...@gmail.com>: > I was hoping people with more insight into this would contribute - its a good > set of questions and this forum is pretty good so I would have appreciated > their thoughts and musings. So to ignite things I will chip in. > > 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 > > 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. 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 > > You have Websphere and you have my sympathies. I have been dealing with that > lately and its made me consider a career change!!! > > Hope this helps - significantly to coax contributions from some of the guys > on here. They seem pretty good to me > > > On 28 Mar 2011, at 13:50, gonzalo diethelm wrote: > >> This is my first post to this list, and I declare myself a Camel newbie. >> Let me start by first saying that Camel is great; a big thanks to the whole >> team for such a wonderful piece of engineering. >> >> I have been searching for some time now for a new way (to me) to build a >> service architecture, to be used _within_ the company; that is, this is not >> intended for web facing services, at least not directly, but more for the >> "pure" business logic layer. My goals for this service architecture are: >> >> 1. Light-weight. >> 2. Easy to use for callers of services. >> 3. Support for synchronous (RPC) and asynchronous (MOM) invocation styles. >> 4. Ability to invoke services from different languages (desired). >> >> The first point is what really got me started in this search. Everything we >> do today is based on J(2)EE, and it seems to me more and more that the >> overhead we pay for that is enormous. So it has been with much joy that I >> have been getting more deeply into Camel, which I have known for the past >> two years. The final catalyst for me to get into Camel with more gusto was >> attending TSSJS at Las Vegas this month, where I met with James and Claus, >> and got a much better feeling for what Camel can deliver. >> >> So what I envision as a basis for this architecture of services is this: >> >> 1. Each service is a bundle running on an OSGi container; there could be one >> or more containers running on one or more JVMs, on one or more servers. >> >> 2. Each service could export its entry points on several endpoint types; at >> least one type for RPC (SOAP, REST, etc.) and one type for MOM (basically >> JMS). >> >> 3. I MIGHT want to support "standard" web services (SOAP), although I am >> more inclined to provide a RESTful interface for my synchronous services. >> >> 4. I would like some level (not fully defined yet) of resilience built into >> the architecture. >> >> 5. I require the ability to monitor the running state of a deployment of >> services, and take action against certain events (such as "service down"). >> >> >> So, I come now to my specific questions, some directly related to Camel, >> some more generic: >> >> 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? >> >> 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? >> >> 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? >> >> 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. >> >> 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 understand I am being a little vague in my description, but I don't really >> know where exactly more detail would be needed; I guess my mind has become a >> little brittle, after all these years of "pure" J(2)EE. Let's get the ball >> rolling with this information and I will provide more if required. >> >> Thanks in advance for any wisdom shared, and best regards. >> >> -- >> Gonzalo Diethelm >> > >
