-
1. Re: ESB vs. SOAP community
heiko.braun May 26, 2008 8:35 AM (in response to thomas.diesler)In general I do agree. But it would be nice to get some feedback from the ESB folks where they do see the boundary between ESB and SOA-P.
-
2. Re: ESB vs. SOAP community
thomas.diesler May 26, 2008 8:47 AM (in response to thomas.diesler)For the sake of the argument (this thread) lets use the terminology JBossSOA, ESB, SOAP. All of which have a different meaning
-
3. Re: ESB vs. SOAP community
tom.baeyens May 26, 2008 9:10 AM (in response to thomas.diesler)I don't really have an opinion on the open sourceness of the soap project itself.
But the main benefit consequence I see would be a simplification of the build. Just pointing to an svn repo, check it out and build it.
This would make it much easier for me/us to work with the soap. -
4. Re: ESB vs. SOAP community
kconner May 27, 2008 4:40 AM (in response to thomas.diesler)I assume you mean SOA-P instead of SOAP as SOAP definitely has a different meaning. :)
The ESB is the closest we have to SOA-P at the moment, at least from a project perspective. The platform guys take our build and 'productise' it by updating some of the components (jBPM, drools etc) and adding the security to make single sign on work.
One of the tasks we have on our list is to refactor our build and pull in the other components based on a configuration. This will bring the ESB even closer to the current SOA-P build and help ease the integration issues for the platform guys.
Kev -
5. Re: ESB vs. SOAP community
marklittle May 27, 2008 5:00 AM (in response to thomas.diesler)There is no such thing as JBossSOA. As Kevin points out, the closest thing we have to a community SOA-P is JBossESB. The team and the platform guys are working to make the transition from JBossESB (community edition of SOA-P) to SOA-P (productization release) as smooth as possible. There is no need for some other project to do this: it should be part of JBossESB.
-
6. Re: ESB vs. SOAP community
thomas.diesler May 27, 2008 5:42 AM (in response to thomas.diesler)
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.
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.
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.
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
SOA-P should not touch project code - including the build. -
7. Re: ESB vs. SOAP community
thomas.diesler May 27, 2008 5:46 AM (in response to thomas.diesler)Mark sais
Anyway, to cut a long story short: the whole governance infrastructure needs to have hooks into all of the projects (platforms) at various levels, not just for SAMM.
The home for this governance infrastructure, should also be JBossSOA and not JBossESB -
8. Re: ESB vs. SOAP community
heiko.braun May 27, 2008 6:01 AM (in response to thomas.diesler)
Thirdly, the JBossESB project should only be concerned with ESB aspects and not try to act as an umbrella project, which it is not.
Separation of concerns, right? -
9. Re: ESB vs. SOAP community
kconner May 27, 2008 6:11 AM (in response to thomas.diesler)'thomas.diesler@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@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@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@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 :) -
10. Re: ESB vs. SOAP community
kconner May 27, 2008 6:17 AM (in response to thomas.diesler)"thomas.diesler@jboss.com" wrote:
The home for this governance infrastructure, should also be JBossSOA and not JBossESB
You obviously know something that I don't in that case, governance is external to the ESB in the same way that the SSO work is external.
Governance affects us all, as does the SSO. When those teams come up with a solution then we will integrate with them. -
11. Re: ESB vs. SOAP community
thomas.diesler May 27, 2008 9:56 AM (in response to thomas.diesler)How as a community member do I verify and contribute to SSO for SOA-P?
AFAIU, I cannot because it is part of some proprietary build. This is just a simple example, but it can reasonably be expected that the delta between JBossESB and the SOA-P will grow (not every SOA aspect is an ESB concern)
As things stand now the ESB team would have to deal with all those aspects.
Also it concerns me that calls to test-drive the SOA-P are being ignored because folks don't care about some proprietary build that is not available to the community.
More positively, the call to test drive the next SOA-P release should of course reach the entire community.
Finally one should not forget that EAP is successful because a large community had access to JBossAS. The same obviously applies to SOA-P -
12. Re: ESB vs. SOAP community
kconner May 27, 2008 10:10 AM (in response to thomas.diesler)"thomas.diesler@jboss.com" wrote:
How as a community member do I verify and contribute to SSO for SOA-P?
I assume that you are referring to the project that has just been started to create this, in which case contributing to the SSO project (or whatever Mike Brock/Anil call it) would be a good move."thomas.diesler@jboss.com" wrote:
AFAIU, I cannot because it is part of some proprietary build. This is just a simple example, but it can reasonably be expected that the delta between JBossESB and the SOA-P will grow (not every SOA aspect is an ESB concern)
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."thomas.diesler@jboss.com" wrote:
As things stand now the ESB team would have to deal with all those aspects.
Sorry Thomas, you are reading far too much into this. The current SSO stuff will be replaced by the new project, that is why it was started in the first place. What other aspects are you thinking about?"thomas.diesler@jboss.com" wrote:
Also it concerns me that calls to test-drive the SOA-P are being ignored because folks don't care about some proprietary build that is not available to the community.
Which is, of course, not true. They can 'test-drive' it through the projects and their integration with AS. We certainly have a lot of people 'test-driving' the ESB integration."thomas.diesler@jboss.com" wrote:
More positively, the call to test drive the next SOA-P release should of course reach the entire community.
Our community does help to test drive the ESB integration, I'm sure the WS one does the same on behalf of WS/EAP."thomas.diesler@jboss.com" wrote:
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? -
13. Re: ESB vs. SOAP community
kconner May 27, 2008 10:17 AM (in response to thomas.diesler)"Kevin.Conner@jboss.com" wrote:
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. -
14. Re: ESB vs. SOAP community
kconner May 27, 2008 11:02 AM (in response to thomas.diesler)Thomas, I think I need you to explain further what it is that you expect to get out of this 'integration project' and why it will be any different to the integration currently done within ESB.
The work to create the platform did discover a number of issues but those have been fed back into the appropriate projects (WS, ESB, jBPM, drools) or resulted in new projects being created (SSO, governance).
The remaining work in the platform is the additional QE, docs and pre-configuration of the 'production' instance. I don't believe any of this is different from the work that goes into the EAP.
The aspect that appears to be missing at present is the ability to take an ESB build and specify the versions of our dependencies, hence the platform team is also responsible for building and overwriting those versions within the generated ESB artifacts. This is being worked on and will be in place before the next platform GA release.
Given all this, what is still missing? What do you see this new project adding that is not currently being covered?