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
