Hi Charles,
We have already talked a lot about this topic :)
You make a good summary of our discussion and let.
After playing a while with the features list of ServiceMix, NMR, Camel and
Karaf, I have discovered that we have some discrepancies between the
different files. This is really painful for users having to package
solutions and wanting to use a modular solution based on OSGI specification.
Moreover, I'm convince that if we want that ServiceMix 4 (or Fuse) becomes
an important player in the field of Enterprise Application Server (designed
around OSGI) and including ESB, Web, EJB, JPA, ... containers, it is
absolutely necessary that we improve what is already packaged in ServiceMix
4 but also the documentation. Without such approach, the future of
Servicemix 4 will be dark compare to what GlassFish v3 / Websphere
Application Server v7 + Aries / Glassfish v3 already propose.
I think that ServiceMix 4, especially thanks to Felix Karaf and feature,
is a really good OSGi container. It offers a very wide solution to
deploy heteregeneous and different applications. However, if Felix Karaf
is a kernel and OSGi engine, it's normal that it offers the capability.
But, we need to keep in mind that ServiceMix is an ESB first.
My question is how we consider SMX4:
- is it an ESB ?
- is it a more global OSGi container ?
- is it a multi-purpose container (supporting web application, JPA, JTA,
DOSGI, etc) ?
From my point of view, we have all the material to extend SMX 4 to a
more global container. But what's the position of SMX comparing to
Geronimo and Aries ?
Action plan:
- Refactor the features file of ServiceMix 4 to include more features (even
if we have to copy/paste them from Karaf like HTTP feature, Spring,
Spring-DM)
Agree. As Felix Karaf is a kernel, I think that we need to try to
maximum limit the feature coming from the kernel. Basicly, the feature
provider should by SMX4 and can gather feature coming from other
provider such as Karaf, Aries, Spring, Geronimo, etc ...
- Add support for Blueprint, Aries application to deploy EBA archives
- Add JPA, JTA, ... containers
Agree. I think that we can add a kind of aries feature to propose
blueprint/aries in SMX4.
- Work on documentation to present ServiceMix 4, how to install it,
start/stop it, debug, install examples, ...
Fully agree. I have already start stuff about this:
- refactoring of the website (http://servicemix.apache.org/home2.html)
- https://issues.apache.org/activemq/browse/SMX4-434 and
http://svn.apache.org/repos/asf/servicemix/sandbox/jbonofre/. I started
a docbook maven plugin and begin a docbook structure.
- you have already provided OSGi samples. I think that we need to gather
all samples in a central maven project to easily share it and include in
the documentation.
An alternative for J2EE features like EJB, Web Container could be that we
work in collaboration with existing Web Application Servers to integrate
ServiceMix 4 in. In this case, it really depends on the positioning of
ServiceMix 4 / Fuse in the future :
- standalone application server (we depend on people in charge of
infrastructure and so could be seen as a competitor of existing application
server for which resources to administrate them exist and have the
knowledge, ...),
- server embedded in Web Application Server (more visibility, can reduce
project risk, project can be designed using J2EE or OSGI Enterprise
specifications, ...)
- standalone application server providing also J2EE features
My point of view is first to provide SMX4 as a standalone container
which provide deployment of a lot of different kind of applications:
- OSGi bundle
- OSGi blueprint bundle
- WAR
- DOSGi/Aries/EBA
- JBI
- JBI/OSGi with EndpointExporter
Nevertheless, we need to provide the capability to deploy SMX into
another container like web container (like servicemix-web) and JEE server.
Regards
JB
Remark : What I present here comes from discussion that we have had with
Jean-Baptiste Onofré.
Regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard
Linkedlin : http://www.linkedin.com/in/charlesmoulliard
Apache Camel Group :
http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
--
Jean-Baptiste Onofré (Nanthrax)
BuildProcess/AutoDeploy Project Leader
http://buildprocess.sourceforge.net
[email protected]
PGP : 17D4F086
