Details

    • Rice Theme:
      Modularity
    • Priority Score:
      10
    • Priority - KFS:
      Medium
    • Priority - KC:
      Medium
    • Priority - KS:
      High
    • Priority - Rice:
      High
    • Theme:
      Modularity
    • Application Impact:
      No Impact
    • Effort Estimate:
      Medium ~ 500 hrs

      Description

      Modularity
      This generalizes the OSGI JIRA. Modularity is expressed in several dimensions of software design and implementation.
      1) Separation of service definitions and implementations
      2) Management of components and dependencies (through both Maven and OSGI)
      3) Modularity in packaging (through configurable builds). Eg build KEW as stand-alone
      4) Modularity in deployment (through configurable builds). Eg run KEW as stand-alone

      Summary of work involved: OSGI is an initiative for creating a modular system and service platform with Java based applications. The main advantage being that "applications or components can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot. Application lifecycle management (start, stop, install, etc.) is done via APIs that allow for remote downloading of management policies. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly" (Wikipedia) With the 2.0 release of Rice we started down the path of modularizing Rice as a way of making development and upgrades easier on applications and implementations, however the work is still not complete.

      This task would involve analysis to define what modularity work remains as well as exploring and recommending how OSGI or similar standards could continue to improve process of development and lessen the impact of Rice upgrades on implementations and applicatio

        Attachments

          Issue Links

            Activity

            Hide
            coppola Chris Coppola (Inactive) added a comment -

            Leo, I'm assigning this to you based on our discussion at the Chicago f2f.

            Show
            coppola Chris Coppola (Inactive) added a comment - Leo, I'm assigning this to you based on our discussion at the Chicago f2f.
            Hide
            coppola Chris Coppola (Inactive) added a comment -

            Targeting for the v1.1 release. This was unanimously agreed to by the roadmap working group in Chicago.

            Show
            coppola Chris Coppola (Inactive) added a comment - Targeting for the v1.1 release. This was unanimously agreed to by the roadmap working group in Chicago.
            Hide
            ewestfal Eric Westfall added a comment -

            Set as no impact because this is a research item. Actual work done her would most likely result in impact.

            Show
            ewestfal Eric Westfall added a comment - Set as no impact because this is a research item. Actual work done her would most likely result in impact.
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

            This is planned to be researched as part of the modularity work for 1.1.

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - This is planned to be researched as part of the modularity work for 1.1.
            Hide
            ewestfal Eric Westfall added a comment -

            Assigning this one to myself. I have done a small amount of research on this in terms of Modularity for Kuali Rice 1.1. See the mention of it in this document:

            https://wiki.kuali.org/x/SoD8E

            Show
            ewestfal Eric Westfall added a comment - Assigning this one to myself. I have done a small amount of research on this in terms of Modularity for Kuali Rice 1.1. See the mention of it in this document: https://wiki.kuali.org/x/SoD8E
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

            Some modularity work was done on KIM in 2.0, but the content of this JIRA was out of scope, so adding back to queue.

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - Some modularity work was done on KIM in 2.0, but the content of this JIRA was out of scope, so adding back to queue.
            Hide
            masargen Matt Sargent added a comment - - edited

            Kymber Horn - Thanks Matt – how will OSGi benefit the applications - KFS, KC, KS, OLE, etc. Will functional users see a difference? Or is this primarily targeted at development? Or will it facilitate support functions – when I read start and stop without reboot, I thought about how we have to restart Tomcat daily (at least I think we are.).

            Matt Sargent - I'm hoping that some of the regular TRC/KTI folks might chime in on this, but OSGI and modularity in general would be more of a back end benefit to the applications and their developers more than something that would show an obvious outward benefit to functional users. However, modularity in general should allow for developers to more easily understand the system and accelerate the pace at which and application can be fixed or improved.

            David Elyea - I saw this e-mail from Matt earlier this week but haven’t seen a reply from anyone on the technical side. I’m not sure I have the knowledge to reply back to the whole ARC about it so I’m wondering if it’s something this little group should discuss. Can we simplify this and provide a more “ARC friendly” definition of how this will benefit a non-technical user? If seems like it should if in fact the end-game of this would be that each module of Rice could be run in a stand-alone fashion. The idea that if KEN fails to start it wouldn’t kill the entire Rice standalone server (or things of that nature). Anyway, just wanted to see if we should start a discussion. Thanks.

            Jerry Neal - I would say we would have to stretch things pretty far to come up with any functional benefit on this one. Really I see very little technical benefit, in particular compared to the amount of work that would be required. Your point is one. Also OSGI helps with dependency management. There are several benefits that come from the modularity of Rice, but that is independent of OSGI. Also, by the time we would have a chance to work on this (if ever) Java Modularity support will be there (I think this is java 8?) which will likely replace OSGI. Not sure who is championing this one but I really feel like we should not even be considering spending time on it.

            Eric Westfall - I suppose I'm the champion since I'm listed as assignee. I think OSGi is not a bad solution for modularity, but I think that if I was going to prioritize it I'd probably put it low down on the list in the face of others things that we need to deal with. Our modularity right now is still not great but we've made a lot of strides with 2.0 and now with the cleanup for some of the KRAD dependencies that will help as well. In general, the stack is still a bit intimate in certain areas which causes usability issues (you mean i have to learn about KRAD, KEW, KIM, and KSB before I can even get started?), but I think if we can keep that in mind as we continue to iterate on architecture and the KRAD framework we can continue to untangle some of the mess.

            That said, I would favor an approach that leverages built-in modularity features in Java once those come to light (though I don't think those are actually going to be in Java 8 unfortunately as my recollection is that the modularity component of that got delayed to Java 9 in 2015). This jira was mostly meant as a research item to say, "hey, should we be using OSGi or not"? I wonder if that was partially answered already here:

            https://wiki.kuali.org/display/KULRICE/Rice+2.0+-+Modularity+Design#Rice2.0-ModularityDesign-WhynotuseOSGitoimplementmodularityinRice2.0%3F

            I wouldn't be opposed to killing this roadmap item entirely unless others felt strongly about it. The only thing which might give me pause is that I think there would be value in having a good mechanism for modularity and module loading as part of KRAD. Right now we are accomplishing this in Rice through the use of module "Configurers" which are fairly course-grained components which load a bunch of spring files, but the behavior and implementation is a bit slovenly. I'm not convinced that something like OSGi is the answer to that though, and I'm not sure how much thought has been put into that part of the KRAD work. I've been disconnected from it for awhile now though so Jerry may have arrived at some insights through his adventures with Lattix.

            Show
            masargen Matt Sargent added a comment - - edited Kymber Horn - Thanks Matt – how will OSGi benefit the applications - KFS, KC, KS, OLE, etc. Will functional users see a difference? Or is this primarily targeted at development? Or will it facilitate support functions – when I read start and stop without reboot, I thought about how we have to restart Tomcat daily (at least I think we are.). Matt Sargent - I'm hoping that some of the regular TRC/KTI folks might chime in on this, but OSGI and modularity in general would be more of a back end benefit to the applications and their developers more than something that would show an obvious outward benefit to functional users. However, modularity in general should allow for developers to more easily understand the system and accelerate the pace at which and application can be fixed or improved. David Elyea - I saw this e-mail from Matt earlier this week but haven’t seen a reply from anyone on the technical side. I’m not sure I have the knowledge to reply back to the whole ARC about it so I’m wondering if it’s something this little group should discuss. Can we simplify this and provide a more “ARC friendly” definition of how this will benefit a non-technical user? If seems like it should if in fact the end-game of this would be that each module of Rice could be run in a stand-alone fashion. The idea that if KEN fails to start it wouldn’t kill the entire Rice standalone server (or things of that nature). Anyway, just wanted to see if we should start a discussion. Thanks. Jerry Neal - I would say we would have to stretch things pretty far to come up with any functional benefit on this one. Really I see very little technical benefit, in particular compared to the amount of work that would be required. Your point is one. Also OSGI helps with dependency management. There are several benefits that come from the modularity of Rice, but that is independent of OSGI. Also, by the time we would have a chance to work on this (if ever) Java Modularity support will be there (I think this is java 8?) which will likely replace OSGI. Not sure who is championing this one but I really feel like we should not even be considering spending time on it. Eric Westfall - I suppose I'm the champion since I'm listed as assignee. I think OSGi is not a bad solution for modularity, but I think that if I was going to prioritize it I'd probably put it low down on the list in the face of others things that we need to deal with. Our modularity right now is still not great but we've made a lot of strides with 2.0 and now with the cleanup for some of the KRAD dependencies that will help as well. In general, the stack is still a bit intimate in certain areas which causes usability issues (you mean i have to learn about KRAD, KEW, KIM, and KSB before I can even get started?), but I think if we can keep that in mind as we continue to iterate on architecture and the KRAD framework we can continue to untangle some of the mess. That said, I would favor an approach that leverages built-in modularity features in Java once those come to light (though I don't think those are actually going to be in Java 8 unfortunately as my recollection is that the modularity component of that got delayed to Java 9 in 2015). This jira was mostly meant as a research item to say, "hey, should we be using OSGi or not"? I wonder if that was partially answered already here: https://wiki.kuali.org/display/KULRICE/Rice+2.0+-+Modularity+Design#Rice2.0-ModularityDesign-WhynotuseOSGitoimplementmodularityinRice2.0%3F I wouldn't be opposed to killing this roadmap item entirely unless others felt strongly about it. The only thing which might give me pause is that I think there would be value in having a good mechanism for modularity and module loading as part of KRAD. Right now we are accomplishing this in Rice through the use of module "Configurers" which are fairly course-grained components which load a bunch of spring files, but the behavior and implementation is a bit slovenly. I'm not convinced that something like OSGi is the answer to that though, and I'm not sure how much thought has been put into that part of the KRAD work. I've been disconnected from it for awhile now though so Jerry may have arrived at some insights through his adventures with Lattix.

              People

              • Assignee:
                ewestfal Eric Westfall
                Reporter:
                lfernig Leo Fernig (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: