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

Put together a proof-of-concept on version compatibility

    Details

    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      Based on the recommendations that Savoir is putting together, build one or more proof-of-concepts using real Rice services to demonstrate how this stuff will work.

        Attachments

          Activity

          Hide
          ewestfal Eric Westfall added a comment -

          Note that the first poc has been put together and is available here:

          https://test.kuali.org/svn/rice/branches/versioning-poc-1-1-0-br

          Show
          ewestfal Eric Westfall added a comment - Note that the first poc has been put together and is available here: https://test.kuali.org/svn/rice/branches/versioning-poc-1-1-0-br
          Hide
          ewestfal Eric Westfall added a comment -

          Notes and docs on version compatibility poc's can be found here:

          https://wiki.kuali.org/display/KULRICE/Version+Compatibility+Proof-of-Concepts

          Show
          ewestfal Eric Westfall added a comment - Notes and docs on version compatibility poc's can be found here: https://wiki.kuali.org/display/KULRICE/Version+Compatibility+Proof-of-Concepts
          Hide
          ewestfal Eric Westfall added a comment -

          Based on discussion with Jason, second round of poc will include the following;

          1) We decided that we would only version services when it is necessary to do so and on every "major" release.
          2) Work on moving data types out to separate module from remote api? This could allow for reuse in things like xml import/export.
          – Allows us to use same compatibility principles for xml import/export!
          – maybe instead, move all of this stuff back into the API module?
          3) Modify all DTOs such that they have the appropriate JAXB annotations on them
          – also need to fix AttributeSetDTO, it's schema is messed up
          4) Move the adapter out of a "version-specific" location
          – also move to impl module
          5) Update the namespaces such that everything under group is generated under the same namespace (including versions)
          – should put DTOs in a different namespace, to help allow for reuse elsewhere
          – could create a separate "type" module
          6) Do a proof of concept with an actual version change example
          7) Try a "compatible" change
          8) Work on way to publish web service with a specific wsdl
          – generate wsdls so they are on the classpath as well
          9) Create a poc on one of the "kim type" services to show invocation from newer client to older client

          Branch is:

          https://test.kuali.org/svn/rice/branches/versioning-poc2-1-1-0-br

          Show
          ewestfal Eric Westfall added a comment - Based on discussion with Jason, second round of poc will include the following; 1) We decided that we would only version services when it is necessary to do so and on every "major" release. 2) Work on moving data types out to separate module from remote api? This could allow for reuse in things like xml import/export. – Allows us to use same compatibility principles for xml import/export! – maybe instead, move all of this stuff back into the API module? 3) Modify all DTOs such that they have the appropriate JAXB annotations on them – also need to fix AttributeSetDTO, it's schema is messed up 4) Move the adapter out of a "version-specific" location – also move to impl module 5) Update the namespaces such that everything under group is generated under the same namespace (including versions) – should put DTOs in a different namespace, to help allow for reuse elsewhere – could create a separate "type" module 6) Do a proof of concept with an actual version change example 7) Try a "compatible" change 8) Work on way to publish web service with a specific wsdl – generate wsdls so they are on the classpath as well 9) Create a poc on one of the "kim type" services to show invocation from newer client to older client Branch is: https://test.kuali.org/svn/rice/branches/versioning-poc2-1-1-0-br
          Hide
          ewestfal Eric Westfall added a comment -

          Added Jason as a watcher

          Show
          ewestfal Eric Westfall added a comment - Added Jason as a watcher
          Hide
          ewestfal Eric Westfall added a comment -

          Just committed first version of the "framework" module for kim which has some code for the KimTypeService and the KimGroupTypeService.

          Show
          ewestfal Eric Westfall added a comment - Just committed first version of the "framework" module for kim which has some code for the KimTypeService and the KimGroupTypeService.
          Hide
          ewestfal Eric Westfall added a comment - - edited

          Have the general framework in place and committed for an app that wants to publish a KIM GroupTypeService (though still need to implement the code that converts between types). Next up is the following:

          1) Create a test client that I can fire up in a test harness to test publishing of the aforementioned service.
          2) Come up with a strategy for implementing the server-side which calls back into the older client-side versions. Not sure what this is going to look like yet, probably need to play out a scenario of three different versions of the service and 3 different clients (each with a different version of a GroupTypeService) all being invoked from the server. Could decorator pattern come in handy here to create a "chain" of conversions for a particular service call?

          Show
          ewestfal Eric Westfall added a comment - - edited Have the general framework in place and committed for an app that wants to publish a KIM GroupTypeService (though still need to implement the code that converts between types). Next up is the following: 1) Create a test client that I can fire up in a test harness to test publishing of the aforementioned service. 2) Come up with a strategy for implementing the server-side which calls back into the older client-side versions. Not sure what this is going to look like yet, probably need to play out a scenario of three different versions of the service and 3 different clients (each with a different version of a GroupTypeService) all being invoked from the server. Could decorator pattern come in handy here to create a "chain" of conversions for a particular service call?
          Hide
          ewestfal Eric Westfall added a comment -

          This was done long ago with the help of Jason and Travis.

          Show
          ewestfal Eric Westfall added a comment - This was done long ago with the help of Jason and Travis.
          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: