Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-4528

Implement ability for rice server to know what version of a client server they are calling

    Details

    • Rice Module:
      KSB
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      The requirement here as to do with a rice standalone server making a callback into an older client application. There are many places where this might occur, most notably with the Kim*TypeServices which service derived roles and custom permission logic, as well as WorkflowAttribute which is used by the rule system and the SecurityAttribute used in doc search (among others).

      Typical access to a remote service will be done in the following way:

      Object serviceProxy = GlobalResourceLoader.getService(new QName(..., ...));

      So the challenge here is determining what the service should be cast to in the calling client code. Which could possibly be one of the following:

      org.kuali.rice...v1.MyService serviceProxy = (org.kuali.rice...v1.MyService)GlobalResourceLoader.getService(new QName(..., ...));

      or:

      org.kuali.rice...v2.MyService serviceProxy = (org.kuali.rice...v2.MyService)GlobalResourceLoader.getService(new QName(..., ...));

      Depending on what version the client application is using.

      So I think there are a few options that I can think of off the top of my head:

      1) Add a method to the service registry to query for the service information (or just add it to the ServiceDefinition):
      – ServiceDefinition def = ServiceRegistry.getServiceDefinition(QName);
      – if (def.getVersion() == 1) // get service from GRL and cast to v1.MyService
      – if (def.getVersion() == 2) // get service from GRL and cast to v2.MyService

      2) Add a method to GRL that returns more information about the service
      – ServiceDefinition def = GRL.getServiceDefinition(QName);
      – if (def.getVersion() == 1) // get the remote service proxy off of the service definition

      3) I'm not sure how possible this is, but if we wrote adapters between the different service versions, perhaps we could have GRL.getService always return the same service interface which is essentially a proxy that delegates to the appropriate service version behind the scenes? The thing that worries me about the previous two approaches is that if you add a version 3 you have to go back and remember to manually update the code to add a new condition. So if we can prevent this from being done manually, that's probably ideal.

        Attachments

          Issue Links

            Activity

            Hide
            ewestfal Eric Westfall added a comment -

            Added Jason and Jeff as watchers.

            Show
            ewestfal Eric Westfall added a comment - Added Jason and Jeff as watchers.
            Hide
            ewestfal Eric Westfall added a comment -

            Work related to this has been done and completed as part of KULRICE-4816. In order to determine the version of a service, a client simply needs to do the following:

            ServiceBus serviceBus = KsbApiServiceLocator.getServiceBus();
            Endpoint endpoint = serviceBus.getEndpoint(new QName("my", "service"));
            String serviceVersion = endpoint.getServiceConfiguration().getServiceVersion();
            
            Show
            ewestfal Eric Westfall added a comment - Work related to this has been done and completed as part of KULRICE-4816 . In order to determine the version of a service, a client simply needs to do the following: ServiceBus serviceBus = KsbApiServiceLocator.getServiceBus(); Endpoint endpoint = serviceBus.getEndpoint( new QName( "my" , "service" )); String serviceVersion = endpoint.getServiceConfiguration().getServiceVersion();
            Hide
            ewestfal Eric Westfall added a comment -

            Resolving this jira as it has been satisfied by a previous commit to KULRICE-4816.

            Show
            ewestfal Eric Westfall added a comment - Resolving this jira as it has been satisfied by a previous commit to KULRICE-4816 .
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

            Closing since these items are now in the release notes.

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - Closing since these items are now in the release notes.

              People

              • Assignee:
                ewestfal Eric Westfall
                Reporter:
                ewestfal Eric Westfall
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: