[marklittle]

There is no need for a separate integration project. JBossSOA is YALI and one too far: JBossESB is the ESB and glue for the other projects that it requires (AS, Drools, jBPM etc.) As Kevin pointed out, governance is happening within a separate project (Overlord) because it does not belong within a single project: it spans them all. SSO is similar.

The last thing we need is another project with associated management and development cycles!

Thomas, if you think there are problems with the way in which JBossESB pulls things together, then call them out. Given the work that the productization folks are doing as well as the ESB team (e.g., http://jira.jboss.com/jira/browse/JBESB-1763) this suggestion for another project seems like a solution looking for a problem.

[marklittle]

Owing to other work commitments I'm a little late to this, but thought I'd add some comments anyway ...

There is no such thing as JBossSOA

Exactly - and my point is that there should be a JBossSOA project that has a binary dependency on JBossESB like on any other project that goes into the SOA-P.

So there's a JBossEAP project somewhere that I don't know about ;-) ?

The benefit is, that JBossESB can have a different lifecycle than JBossSOA,

It already does, in the same way all of the projects do. There is no benefit of adding yet another project that simply pulls together what the ESB is already pulling together.

With the current approach JBossESB determines the release cycle, which may be slower than what our community expects of JBossSOA.

Actually the way it is at the moment the SOA-P and ESB are in lock-step precisely because of community and customer requirements! Were that to change then it would be in the same way as we see for all of the other projects.

For example we cannot update JBossWS before JBossESB is ready for the next release.

No, we cannot update JBossWS because we pull it in from EAP. Good project (JBossWS) to mention, but completely wrong target (JBossESB) to fire at!

Additionally, all folks that are currently involved in the various SOA projects should become members of JBossSOA. This is important to improve project integration.

Thirdly, the JBossESB project should only be concerned with ESB aspects and not try to act as an umbrella project, which it is not.

The ESB is being precisely what it is meant to be: a glue (and umbrella to some extent). The ESB is our SOA Infrastructure. It is JBossSOA. You want to have two names for the exact same project?

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

Wrong target again. As Kevin already pointed out, SSO is not happening within SOA-P or ESB! It's a company wide effort.

[marklittle]

Mark sais
The home for this governance infrastructure, should also be JBossSOA and not JBossESB

Hopefully by now you'll have done some homework and seen that governance is not happening within JBossESB, but it going on here.

[marklittle]

And it is a bad example as the only thing that the current SSO does is configure the normal security access inherent in the app server so that each console uses the same credentials. Pure jaas, nothing more, in the current SOA-P.

And, unless I am mistaken, the EAP productisation team make very similar changes when creating EAP. I don't believe this is unusual in SOA-P.

You're right. And in some cases (e.g., JBossWS) they even have their own build scripts!

[marklittle]

Finally one should not forget that EAP is successful because a large community had access to JBossAS. The same obviously applies to SOA-P

Sorry, are you suggesting that SOA-P is failing?

I hope not. JBossESB has one of the most vibrant and largest contributor and user communities within JBoss!