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

Identify and document all services in Rice that can be invoked remotely

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Labels:
      None
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      Scott has essentially already done this here, but we should follow up with him on whether he thinks it is complete or not:

      https://spreadsheets.google.com/a/kuali.org/ccc?key=0Am1eZDsMy7yYdHRmdWVLcW00NGZ5U3ZSOHpaOTI0VlE&hl=en#gid=0

      What I want to do at the end of the day is be able to provide some sort of documentation on the services available in rice to our end users. So I wonder if there is some sort of way we can generate or derive such information (either via an annotation based solution or something else, as long as it's not manual).

      Also, this will feed into the refactoring we do to put externally available services into the "api" module of the Rice project.

        Attachments

          Activity

          Hide
          jwhaley Jason Whaley (Inactive) added a comment -

          @Scott - "We could possibly do something with the package naming convention to separate remotable vs non-remotable services." <-- agree 100% on this one.

          Also what about the case of exported services that come from plugins created by a university running Rice? Those register themselves somehow to the bus but not until runtime, right? It might be out of scope for this particular issue, since I think we are only concerned with the base distribution of Rice (without plugins), but it's a good case for some automated discovery mechanism that's machine-readable if those plugin services can't be found until runtime. Perhaps this should be spun off into another issue, with reduced priority as Eric suggested.

          Show
          jwhaley Jason Whaley (Inactive) added a comment - @Scott - "We could possibly do something with the package naming convention to separate remotable vs non-remotable services." <-- agree 100% on this one. Also what about the case of exported services that come from plugins created by a university running Rice? Those register themselves somehow to the bus but not until runtime, right? It might be out of scope for this particular issue, since I think we are only concerned with the base distribution of Rice (without plugins), but it's a good case for some automated discovery mechanism that's machine-readable if those plugin services can't be found until runtime. Perhaps this should be spun off into another issue, with reduced priority as Eric suggested.
          Hide
          sgibson Scott Gibson (Inactive) added a comment -

          For finding services where kew calls the client I have in my notes to search for stuff like

          DocumentType documentType = KEWServiceLocator.getDocumentTypeService().findByDocumentId(documentId);
          String serviceNamespace = documentType.getServiceNamespace();

          The servicenamespace in that case is usually used to indentify the client app.

          Show
          sgibson Scott Gibson (Inactive) added a comment - For finding services where kew calls the client I have in my notes to search for stuff like DocumentType documentType = KEWServiceLocator.getDocumentTypeService().findByDocumentId(documentId); String serviceNamespace = documentType.getServiceNamespace(); The servicenamespace in that case is usually used to indentify the client app.
          Hide
          ewestfal Eric Westfall added a comment -

          Generally services in the plugin register themselves with the "internal bus" (the resource loader stack) but not with the "external bus" (the service registry). So in those cases they are deployed as locally available services and aren't even exported as SOAP or http invoker, etc.

          Show
          ewestfal Eric Westfall added a comment - Generally services in the plugin register themselves with the "internal bus" (the resource loader stack) but not with the "external bus" (the service registry). So in those cases they are deployed as locally available services and aren't even exported as SOAP or http invoker, etc.
          Hide
          jwhaley Jason Whaley (Inactive) added a comment -

          Full listing of exposed services can be found here: https://wiki.kuali.org/display/KULRICE/Version+Compatibility+Recommendations+-+Client-Server+Implementations

          Additionally, should another issue be opened to address "What I want to do at the end of the day is be able to provide some sort of documentation on the services available in rice to our end users. So I wonder if there is some sort of way we can generate or derive such information (either via an annotation based solution or something else, as long as it's not manual). "

          Show
          jwhaley Jason Whaley (Inactive) added a comment - Full listing of exposed services can be found here: https://wiki.kuali.org/display/KULRICE/Version+Compatibility+Recommendations+-+Client-Server+Implementations Additionally, should another issue be opened to address "What I want to do at the end of the day is be able to provide some sort of documentation on the services available in rice to our end users. So I wonder if there is some sort of way we can generate or derive such information (either via an annotation based solution or something else, as long as it's not manual). "
          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:
              jwhaley Jason Whaley (Inactive)
              Reporter:
              ewestfal Eric Westfall
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 25 minutes
                25m