9 Replies Latest reply on Sep 8, 2011 6:36 AM by tfennelly

    Switch Yard and jboss esb

    hifly81

      Hi,

      I would like to know why there is a need of a new ESB system.

      I mean what will be the differences between switch yard and jboss esb?

      I red the main page of switch yard but I couldn't understand in what will it be different from a ESB/EAI system.

      Is it not better to improve jboss esb?

       

      Thanks,

      Giovanni

        • 1. Switch Yard and jboss esb
          kcbabo

          Hi Giovanni,

           

          Rest assured that we are still improving JBoss ESB.  I address the reason why we created a new project in the SwitchYard FAQ:

          There are things that we would like to add/change/remove in JBoss ESB that would simply be to disruptive to our current deploy base to introduce.  The initial plan was to introduce these changes in version 5, but it is much cleaner and easier for the community to pick up if we split off the development completely.

           

          For background on some of the things we would like to change, you can check out this presentation and this presentation.  A number of these changes have a significant impact on the core of the ESB.  We want to incubate these changes in the SwitchYard project, make sure they are rock solid, and move the existing functionality in JBoss ESB forward.

           

          In terms of what we are doing to get there, you can visit the developer forum to see what's going on:

          http://community.jboss.org/en/switchyard/dev

           

          We will also be posting more end user materials, examples, etc. to the User community over the next couple weeks.  I hope that you will check them out and provide feedback on the direction we are taking.

           

          regards,

          keith

          • 2. Switch Yard and jboss esb
            hifly81

            Hi Keith and thank you for your clear explanation.

            of course I'm only happy if jboss people works on new solutions and new projects and I really hope that switch yard will be a successful EAI project.

            But because of I work on jboss esb and I think there is a lot of work to do in order to improve it, I'm afraid if switch yard will be what jbpm 4 was for jboss soa platform.

            I will try to explain: current soa platform still rely on jbpm 3 and I think next version will move to jbpm 5; I think that jboss lost 2 years of improvements in soa market because of too much fragmentation on bpm projects inside jboss community. It's true that a soa platform is not only bpm: but it is a consistent part of it.

            Moreover jbpm4 will remain a community project and will never go in a soa platform.

             

            I mean too much fragmentation on similar projects is not positive if there is not a group of people that work for the same targets and in the same direction.

             

            I hope this will not happen with switch yard because I think that the final artifact must be a better jboss soa platform and if this will rely on rosetta or on switch yard could be a detail.

             

            I hope you can understand my position and I will give you all the feedbacks to give a good contribution to this new project.

             

            Giovanni

            • 3. Switch Yard and jboss esb
              kcbabo

              Hey Giovanni,

               

              I appreciate your perspective and we certainly do not plan on having JBoss ESB or SwitchYard idle over the next two years.  You will still see improvements and future releases of JBoss ESB.  I absolutely agree that the end goal here is an improvement to the overall SOA platform and I firmly believe that the path we are on is the best way to get there.

               

              cheers,

              keith

              • 4. Switch Yard and jboss esb
                mpiraccini

                In my opinion, SwitchYard vs JBossESB is similar as the old SCA vs JBI dispute.

                 

                For what I've understand of SwitchYard, it's a runtime that can be used used to expose services in a "SOA" way

                (plz, correct me if i'm wrong, I'm just starting playing with SwitchYard).

                On the other hand, JBossESB is a full functional, traditional ESB dedicated to EAI

                 

                The question is: will ever be SwitchYard ant JBossESB integrated? For example, will JBossESB ever include a "SwitchYard Gateway"?

                • 5. Switch Yard and jboss esb
                  kcbabo
                  In my opinion, SwitchYard vs JBossESB is similar as the old SCA vs JBI dispute.

                   

                  For what I've understand of SwitchYard, it's a runtime that can be used used to expose services in a "SOA" way

                  (plz, correct me if i'm wrong, I'm just starting playing with SwitchYard).

                   

                  This is correct.

                   

                  On the other hand, JBossESB is a full functional, traditional ESB dedicated to EAI

                  The question is: will ever be SwitchYard ant JBossESB integrated? For example, will JBossESB ever include a "SwitchYard Gateway"?

                   

                  I think you can, and should, have support for EAI and SOA integration styles within an ESB.  IMHO, the most important aspects of EAI support are transformation, connectivity/adapters, and routing.  JBoss ESB had these and we will continue to have these in SwitchYard, albeit with tweaks (e.g. Camel will be used for definition action pipelines).  What's unique to SwitchYard is the focus on the contact of the service and creating well-defined service compositions based on those contracts.  I think the combination of these two perspectives will be very powerful and will help address a number of problems with traditional EAI-based SOA solutions.  In this sense, it's best to look at SwitchYard as an evolution of JBoss ESB and not something that's going to be used alongside it.

                  • 6. Re: Switch Yard and jboss esb
                    ssatguru

                    Keith,

                     

                    You mentioned  

                    "I think the combination of these two perspectives will be very powerful and will help address a number of problems with traditional EAI-based SOA solutions."

                    Do you mind elaborating on these problems?

                     

                    Also, would I be correct in saying that the major difference  between JBoss ESB and Switchyard/SCA approach is that JBoss ESB is based on the messaging paradigm and Switchyard is based on distributed objects and object method invocation paradigm ?

                    So in JBoss ESB if  ServiceA needs to invoke ServiceB it does so by passing a JBoss message to it. In Switchyard, ServiceA sees ServiceB as a java object and invokes java methods on it.

                    • 7. Re: Switch Yard and jboss esb
                      kcbabo

                      Hey Satguru,

                       

                      "I think the combination of these two perspectives will be very powerful and will help address a number of problems with traditional EAI-based SOA solutions."

                      Do you mind elaborating on these problems?

                       

                      Here are a few things that I've been annoyed with in the past.  I'm sure there are plenty more. :-)

                      • Ability to define and query dependency information between services. 
                      • Providing a human-readable, machine interpretable contract for each service. 
                      • Flexibility to bind a given service implementation to different or multiple endpoints. 
                      • Absence of implementation and/or binding details in service implementation logic.

                       

                      With that said, EAI products are generally great at solving fine-grained, system/application-level integration problems, and you need that when you actually look to implement SOA in any organization.  It's a piece of a successful SOA solution.

                       

                      Also, would I be correct in saying that the major difference  between JBoss ESB and Switchyard/SCA approach is that JBoss ESB is based on the messaging paradigm and Switchyard is based on distributed objects and object method invocation paradigm ?

                      So in JBoss ESB if  ServiceA needs to invoke ServiceB it does so by passing a JBoss message to it. In Switchyard, ServiceA sees ServiceB as a java object and invokes java methods on it.

                       

                      I think it depends on what you mean by messaging.  Message-based contracts for services are a central part of SOA design, so there will always be a core concept of message-based delivery in an ESB.  What's not required is that an ESB sits on top of a MOM infrastructure - that's more of an implementation choice.  For SwitchYard, you can expect to see JMS-style messaging as an integration point (i.e. something you interact with through a gateway) and not as a required element of service configuration.  In other words, the internal bus in SwitchYard is message-based, but it will not require a messaging provider.

                      • 8. Re: Switch Yard and jboss esb
                        ssatguru

                        Hi Keith

                         

                        Here are a few things that I've been annoyed with in the past.  I'm sure there are plenty more. :-)

                        • Ability to define and query dependency information between services. 
                        • Providing a human-readable, machine interpretable contract for each service. 
                        • Flexibility to bind a given service implementation to different or multiple endpoints. 
                        • Absence of implementation and/or binding details in service implementation logic.

                        I can see how references, wiring and binding  in SCA composite file can address these issue.To be queryable I am assuming some provision will be made to store the composites in some sort of registry / repository.

                         

                         

                         

                        I think it depends on what you mean by messaging.  Message-based contracts for services are a central part of SOA design, so there will always be a core concept of message-based delivery in an ESB. 

                        As far as messaging is concerned I was looking at this from a developer perspective.
                        So for example, in JBOSS ESB if ServiceA has to invoke ServiceB (and both are "internal"/"non gateway" services) here is how a developer will code


                                  ServiceInvoker invoker = new ServiceInvoker("DemoServices","ServiceB");

                                  Message message = MessageFactory.getInstance().getMessage();

                                  message.getBody().add("Hi there!");

                                  invoker.deliverAsync(message);


                        Create message , set message , send message.

                         

                        Here is how he would do in SCA


                                  @Reference

                                  public ServiceB svc;

                                  String value = svc.sayGreeting("Hi there!");


                         

                        No messages

                        • 9. Re: Switch Yard and jboss esb
                          tfennelly

                          As far as SwitchYard goes, the @Reference invocation pattern you've shown above actually translates into a SwitchYard Exchange invocation (under the hood) i.e. you are invoking through an injected @Reference intereface, but that invocation gets translated into soimething akin to the JBoss ESB invocation pattern you described (create, set, send).