1 2 Previous Next 19 Replies Latest reply on May 27, 2008 1:46 PM by Mark Little

    ESB vs. SOAP community

    Thomas Diesler Master

      Folks,

      from what I learned last week it seems that ESB is not really the SOA project community edition. Instead we don't seem to have a SOA project for the community.

      By definition the SOA project would consume other related SOA projects (i.e. messaging, bpm, rules, esb, web services, etc) and bring these technologies together in a meaningful way. Release cycles would be fast and the barrier for community involvement low. It would be the home for integration tests and the umbrella project that everybody is equally involved in.

      We have JBossAS which gets productized in EAP. In the same way we should have JBossSOA that gets productized into SOAP.

        • 1. Re: ESB vs. SOAP community
          Heiko Braun Master

          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 Master

            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 Master

              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
                Kevin Conner Master

                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
                  Mark Little Master

                  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 Master

                     


                    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 Master

                      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 Master

                         


                        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
                          Kevin Conner Master

                           

                          '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
                            Kevin Conner Master

                             

                            "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 Master

                              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
                                Kevin Conner Master

                                 

                                "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
                                  Kevin Conner Master

                                   

                                  "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
                                    Kevin Conner Master

                                    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?

                                    1 2 Previous Next