'thomas.diesler(a)jboss.com wrote : The benefit is, that JBossESB can have a different lifecycle than JBossSOA, With the current approach JBossESB determines the release cycle, which may be slower than what our community expects of JBossSOA. For example we cannot update JBossWS before JBossESB is ready for the next release. We are already working on a timeboxed release schedule, so we will have frequent releases. 'thomas.diesler(a)jboss.com wrote : Additionally, all folks that are currently involved in the various SOA projects should become members of JBossSOA. This is important to improve project integration. The integration point for JBossWS is through the app server and the EAP platform, why do we need to create an additional project for this? 'thomas.diesler(a)jboss.com wrote : Thirdly, the JBossESB project should only be concerned with ESB aspects and not try to act as an umbrella project, which it is not. It isn't acting as an umbrella project in the sense you mean. WS has a very specific integration point (ignoring ESB for now) and that is through the AS. Any additional work done by the ESB team lies with the ESB team. 'thomas.diesler(a)jboss.com wrote : Forthly, component updates and SSO should not be a property of the SOA-P they should be available to the community, develeoped and QAed in JBossSOA. Productisaztion should be the only concern of the SOA-P Which is why we have started a project to tackle that very issue :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153538#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...