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 >
