Hi Gonzalo.
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?
If you feel hungry - do it. I think you can do everything without JEE in
a smart way, too. ;)
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?
I think there is no REST vs. SOAP. They have both advantages and
disadvantages. With camel you're free to provide both with a little more
effort. If you only want to provide simple CRUD style services, REST
seems a little bit easier to use. And in combination with camel and
jetty (the jetty component) you can do great things like internally non
blocking sync calls.
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?
It makes sense to have a camel context in each service. It light weight
and extremely useful. Creating a REST interface with Jetty or RESTLET.
It looks to me, if your services are very fine grained - so if a service
consists of an interface and some logic to get data into or out of a db,
you could think about writing your services completely in camel (as a
camel route).
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.
I don't think camel makes your client fat at all. The footprint of camel
is very low. The only thing is - you will have some more jars in your
classpath (which is no issue, if you're using OSGi).
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 think it is. They're leightweight (of course the create overhead
compared to start a Main class). Try it out.
Best regards - Claus
