Hi Gonzalo Nice to meet you at TSSJS, and signing your copy of the Camel in Action book. Now you gotta go to Canada to have Jon sign it as well :) Or stop by DC next month for the Camel One conference.
Anyway I can see this thread has picked up and a lot of good feedback. The one item I would object against was that it was mentioned that an Apache stack would be more complex to setup than JEE. I really don't see that. It really depends on a per product basis comparison. Some JEE stacks is terrible heavy and complex to setup, and others is more lean and simpler. Likewise it depends a bit what you put in your Apache stack. If you eg use Apache ServiceMix, its just a matter of unzipping and running the start script. Likewise for Apache Tomcat its also just to unzip and run its start script. Then you can deploy your Camel application as plain WAR files that its a very solid and proven way. The point with Camel is that its not a choice of either or - Camel is a lightweight framework which you host in your server of choice. So you can use both. Camel running in whatever server/infrastructure you like - that server could be JEE or it could be any other, in the cloud, etc. its your pick. Usually this allows you to pick a server infrastructure that your operations team may already support and use. Often its not "very easy" to introduce a new server infrastructure. So being able to re-use existing is a major win with Camel. Also Camel allows you to tap into the enterprise features of your server infrastructure, whether its clustering, management, provisioning, hot-deploy, monitoring, security etc. We dont try to reinvent the wheel here with Camel. On Mon, Mar 28, 2011 at 2:50 PM, gonzalo diethelm <gdieth...@dcv.cl> 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 > > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
