5 Replies Latest reply on Nov 5, 2012 8:56 AM by Keith Babo

    Dynamic Endpoint Resolution

    Eduardo de Vera Toquero Newbie

      Is it possible to have such a feature in Switchyard? Is there any API to allow interact with the service registry at runtime in order to register new instances of known service types? If not, would it be of any interest to Switchyard?

        • 1. Re: Dynamic Endpoint Resolution
          Keith Babo Master

          The ServiceDomain instance can be used to dynamically register services.  It's what we use in the deployer to register services in a deployment.  Now, the real question is in what context would you be doing this?  A concrete example / use case would help.

          • 2. Re: Dynamic Endpoint Resolution
            Eduardo de Vera Toquero Newbie

            The reality which we are facing is the following:

             

            1. We have a set of different Service Types (potentially running with different versions).
            2. Service Types are known at development time.
            3. Service Instances have a different life cycle than the Switchyard Application. These are created and destroyed at runtime.
            4. Directing a message to one instance or the other depends on logic that takes into account the exchange information (headers and/or body) as well as the service Instance information.

             

            From my point of view this would require having a publicly available API for dealing with the registry in order to register/deregister service instances references.

             

            I took the time to come up with the following two possibilities to solve this particular problem (please note grayed elements are dynamic) but I would really like to know your opinion on this:

             

            dynamicEndpointResolution.png

            • 3. Re: Dynamic Endpoint Resolution
              Keith Babo Master

              This is great, thanks.  Comments inline:

               

              1. We have a set of different Service Types (potentially running with different versions).

              2. Service Types are known at development time.

              This is an important point - dependencies are known at development-time for a service.  The actual resolution of an implementation/endpoint for the dependencies is external from the service implementation.  IOW, document the dependency and contract and defer the resolution to the runtime.

               

               

              3. Service Instances have a different life cycle than the Switchyard Application. These are created and destroyed at runtime.

              4. Directing a message to one instance or the other depends on logic that takes into account the exchange information (headers and/or body) as well as the service Instance information.

               

              #3 is true for any referenced service that resides outside the application.  So agree there.

               

              #4 is likely an extension point that's required in SY core.  Something like an addressing handler which has access to the exchange and a reference to the registry.  I actually think this might coincide with another change I've been thinking of which specifically identifies bindings and includes binding metadata in the registry.  That would give you the information you needed to make an addressing decision I think.

              From my point of view this would require having a publicly available API for dealing with the registry in order to register/deregister service instances references.

               

              Yes on having a hook in a handler to get a reference to the registry.  I view this as an extension/customization point for the runtime vs. something a service implementation uses directly.

               

              In terms of registering endpoints dynamically, that's something that requires more thought.  I understand what you're after here and just need to give it a bit more consideration in terms of how that would wire in.  Going back to our conversation on IRC, I think another use case that can be satisfied with this approach is WS-Addressing style cases where an endpoint reference is included with an invocation.

              • 4. Re: Dynamic Endpoint Resolution
                Eduardo de Vera Toquero Newbie

                what's the recommended wait to access Switchyard's registry? Is it possible by using CDI?

                • 5. Re: Dynamic Endpoint Resolution
                  Keith Babo Master

                  For this case, you should be able to register an interceptor/auditor and pull the service domain off of the exchange as it's in flight.  Unfortunately, it looks like the API only permits the service domain to be retrieved from the service and not the service reference.  This is a problem for your use case, since you want to preempt the addressing handler and supply your own address based off the service reference.  I have filed a JIRA to take care of this oversight:

                   

                  https://issues.jboss.org/browse/SWITCHYARD-1151

                   

                  We should be able to bang that out in the first week of 0.7, so please come back and holler if you don't see an update.  Once that is in place, you will want to register an @Auditor around Processors.ADDRESSING and query/assign a provider there.  Some background on auditing:

                  https://docs.jboss.org/author/display/SWITCHYARD/Auditing+Exchanges