3 Replies Latest reply on Jun 3, 2013 10:33 PM by dustin.barlow

    Switchyard Equivalent of JBoss ESB's ServiceInvoker?

    dustin.barlow
    dustin.barlow Jun 3, 2013 1:54 PM

      I have been developing in the JBoss ESB for the last year or so and have a number of instances running in production environments. 

       

      I am looking for a migration path of my existing JBoss ESB implementations to Switchyard.

       

      One feature of the JBoss ESB that I've made extensive use of is the ServiceInvoker.

       

      I like how from any ESB Action class, I can call another InVM service pipeline simply by using its logical name as defined in the jboss-esb.xml file.

       

      ServiceInvoker invoker = new ServiceInvoker("MyServices","SomeService");
Message message = MessageFactory.getInstance().getMessage();
message.getBody().add("something");
invoker.deliverAsync(message);

       

      The loose coupling of using a logical name allows me to drive complex service routing at run-time from a meta-data database (Oracle in this case).

       

      From my admittedly limited experience with Switchyard thus far, I've only seen examples that use the following:

       

       @ServiceOperation("SomeService")
 private Invoker service;

       

      This is certainly nice, clean, and simple, but it requires knowing at compile time what logical service names a particular client of Switchyard or even other beans/services inside of Switchyard would be invoking.

       

      So, my question is, is there a more dynamic way to invoke services similar to how the JBoss ESB's ServiceInvoker works?

       

      Thanks!

        • 1. Re: Switchyard Equivalent of JBoss ESB's ServiceInvoker?
          tadayosi
          tadayosi Jun 3, 2013 9:08 PM (in response to dustin.barlow)

          Hello,

           

          Have you checked RemoteInvoker [1]?  I believe this is the closest equivalent to JBoss ESB's ServiceInvoker.

           

          [1] https://docs.jboss.org/author/display/SWITCHYARD/Remote+Invoker

           

          Hope this helps,

          Tadayoshi

          1 of 1 people found this helpful
            • Actions
          • 2. Re: Switchyard Equivalent of JBoss ESB's ServiceInvoker?
            kcbabo
            kcbabo Jun 3, 2013 9:20 PM (in response to tadayosi)

            I agree with the comment on RemoteInvoker, but wanted to follow up with a few more comments.

             

            The @ServiceOperation annotation you referenced in your post is actually just for unit tests.  If you want to refer to another service from within a CDI Bean service, then you can use @Reference:

            https://github.com/jboss-switchyard/quickstarts/blob/master/bean-service/src/main/java/org/switchyard/quickstarts/bean/service/OrderServiceBean.java#L30

             

            As a general rule, we attempt to encourage declaration of dependencies in a service through reference definitions in the application metadata. The choice of which service can be dynamic, but the set of services to choose is static.  If you want 100% dynamic, then RemoteInvoker is the ticket.  One thing to keep in mind is that any service invoked via RemoteInvoker must have a binding.sca defined.  You can see an example of this in the RemoteInvoker quickstart.

              • Actions
            • 3. Re: Switchyard Equivalent of JBoss ESB's ServiceInvoker?
              dustin.barlow
              dustin.barlow Jun 3, 2013 10:33 PM (in response to kcbabo)

              Thanks for the clarification of @ServiceOperation vs @Reference.  I had wondered at one point what the distinction was.

               

              Regarding design, I agree with the notion that the choosing of which service is dynamic but the set of services to choose from is static.  I am just using a database meta-data driven approach to both define what services are available on the ESB as well determining which service will be called for a particular service definition.

               

              I chose this approach primarily because most of the routing logic I found required introspection of the inbound payload to determine where to route the request.  I didn't want the routing logic having to introspect or force clients to adopt a convention to send along a particular routing token within their custom payloads.  In other words, the target service knows how to handle the payload, but all the infrastructure in front of that service doesn't need to.

               

              This is what made the ServiceInvoker nice in the JBoss ESB in that it wasn't just useful for invoking remote services, but it also gave me a way to jump across pipelines in a such a way that the calling pipeline had no dependency at all on the target.  It funtioned more like a proxy.

               

              I will certainly take a look at the RemoteInvoker even though I'm looking to basically call, in JBossESB speak, "InVM" not necessarily remotely.

                • Actions