What would tomcat bring 'extra' to the mix? On Apr 21, 2010, at 9:54 AM, Charles Moulliard wrote:
> Hi JB, > > Many thanks for your feedback. As jetty is an important component in > camel and servicemix, I'm not quite sure that it makes sense to remove > it for the moment while camel-tomcat and servicemix-http are not > available. > > We can also design the product using jetty and Apache HTTP Server: > http://wiki.eclipse.org/Jetty/Tutorial/Apache > So we don't need to design new components. Apache HTTP Server is use > in plenty projects where Websphere AS is deployed and WAR file can be > deployed in Jetty : > http://www.enavigo.com/2008/08/29/deploying-a-web-application-to-jetty/. > As a wrapper exist, it can be started as a Service on Windows, ... > > Kind regards, > > Charles Moulliard > > Senior Enterprise Architect (J2EE, .NET, SOA) > Apache Camel Committer > > ******************************************************************* > - Blog : http://cmoulliard.blogspot.com > - Twitter : http://twitter.com/cmoulliard > - Linkedlin : http://www.linkedin.com/in/charlesmoulliard > > > > On Wed, Apr 21, 2010 at 5:25 PM, Jean-Baptiste Onofré <[email protected]> > wrote: >> Hi Charles, >> >> as already discussed together, the idea looks very interesting to me. >> >> By packaging Tomcat, Camel, ODE and JBI components in ServiceMix (and of >> course working on the documentation :)), we can provide a wide scope and >> powerful ESB. Combining with the OSGi/Karaf give us a very flexible and >> modern platform. >> >> Tomcat can be an interesting alternative to Jetty to in components (there is >> some work to migrate). >> >> Definetely +1 for me. >> >> Regards >> JB >> >> Charles Moulliard wrote: >>> >>> Hi, >>> >>> ServiceMix EAI. The name should be probably changed but the idea >>> having an Enterprise Integration Server is to combine the strength of >>> the ServiceMix ESB server and Routing Engine with Tomcat to offer a >>> platform where J2EE applications can also be deployed. >>> >>> Why : Many clients are still designing and developing their projects >>> as J2EE applications which are deployed as WAR or EAR in an >>> Application Server. People in charge of the infrastructure have skills >>> and competences to manage such J2EE applications. When they have to >>> manage a new kind of server like ServiceMix, they are more reluctant >>> as they have less skills and return of experience. But if we can >>> propose a packaged version of Tomcat where ServiceMix is already >>> deployed, they will accept. We can also say the same thing for the >>> development team because the clients have invest since more than a >>> decade in Java/Web developers + Spring recently. >>> >>> The other advantage that I see also concerning this product is that we >>> can propose to the clients an environment where there applications can >>> be easily load-balanced, services could be deployed as bundles and >>> accessed from J2EE application using OSGI service (like IBM WebSphere >>> does - see Aries project for that and WAB). In fact, we can propose an >>> Open Source SOA solution leveraging of the stregnth of Application >>> Server World, OSGI modularity, Messaging Bus, Routing, ... Combining >>> with REST/WebService, ... who can inter-operate with any other >>> existing >>> system. Loadbalancing is a key success factor in the architecture when >>> we have to process thousands of requests quickly and when we have to >>> distribute the work load between different servers (= cloud >>> computing). >>> >>> What do you think about that ? >>> >>> Charles Moulliard >>> >>> Senior Enterprise Architect (J2EE, .NET, SOA) >>> Apache Camel Committer >>> >>> ******************************************************************* >>> - Blog : http://cmoulliard.blogspot.com >>> - Twitter : http://twitter.com/cmoulliard >>> - Linkedlin : http://www.linkedin.com/in/charlesmoulliard >> Johan Edstrom [email protected] They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety. Benjamin Franklin, Historical Review of Pennsylvania, 1759
