Uploaded image for project: 'Kuali Rice Roadmap'
  1. Kuali Rice Roadmap
  2. KRRM-84

Modularization - Investigate how KIM can be modularized to run standalone

    Details

    • Type: Rice Research Item
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Component/s: KIM
    • Labels:
      None
    • Rice Theme:
      Modularity
    • Priority Score:
      0
    • Priority - KFS:
      No Priority
    • Priority - KC:
      No Priority
    • Priority - KS:
      Critical
    • Priority - Rice:
      High
    • Theme:
      Modularity
    • Application Impact:
      Low
    • Effort Estimate:
      Low ~ 200 hrs

      Description

      This is a research item to investigate how KIM can be deployed "standalone" from the rest of Rice so that implementing institutions can run it standalone. Some of the questions that should be investigated are:

      • What do we mean by "standalone". What business objective are we trying to achieve?
      o decoupling the KIM services (AuthN, AuthZ, etc.) from the rest of Rice?
      o Other?
      • What viable options exist to accomplish these objectives?
      o For example, writing KIM as a Rice client application?
      o Other options?
      • Should we try to do this? Is there community support for it?
      • Why would we do it? What are the business benefits?
      o Performance benefits?
      o Failover benefits?
      o Other?
      • What would it cost to do it? How much effort? Who needs to participate?

      This research work should involve gathering input internally from the existing project investors as well as gathering input from the external community of potential implementers.

      Summary of work involved: This is for investigating the possibility of including an option to run KIM standalone, either as the only component of Rice that you might want to leverage or as a way to scale KIM horizontally for load purposes. For current Rice applications, the benefits would be minimal due to the fact that most use KIM in conjunction with the other Rice modules, however the ability to scale load could improve performance for users. However, as we look to KIM as possibly being a basis for KIM as a more fully featured Identity Management suite, the ability to run KIM separate from Rice could be of benefit to potential implementations that would only need KIM.

        Attachments

          Issue Links

            Activity

            Hide
            coppola Chris Coppola (Inactive) added a comment -

            Tentatively marking this for v1.1. Needs to be validated by voting ARC members.

            Show
            coppola Chris Coppola (Inactive) added a comment - Tentatively marking this for v1.1. Needs to be validated by voting ARC members.
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

            This did not make it into the 2.0 Modularity effort, moving back to voting queue.

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - This did not make it into the 2.0 Modularity effort, moving back to voting queue.
            Hide
            masargen Matt Sargent added a comment -

            Gary Prohaska - Hi Matt, thanks for summarizing these issues, especially in bite-sized chunks. Makes it much easier to comprehend. My feedback on both of these items is similar to earlier comments … I think we should uniformly look at making Rice service-oriented, meaning that applications never talk to infrastructure databases (KRRM-86), they only talk to services. The deployment of services should also allow for code decoupling (KRRM-84). So, rather than looking at these as individual issues, to me they part of a bigger architectural research effort, i.e. transforming Rice into independent services which also means Rice as “embedded” is deprecated at some point. I believe there is already a jira ticket related to SOA but not sure if it’s a good fit. Eric would know. Even if we conduct the research separately I believe there is benefit in relating these re-architecture items thematically so the end goal is readily apparent.

            Show
            masargen Matt Sargent added a comment - Gary Prohaska - Hi Matt, thanks for summarizing these issues, especially in bite-sized chunks. Makes it much easier to comprehend. My feedback on both of these items is similar to earlier comments … I think we should uniformly look at making Rice service-oriented, meaning that applications never talk to infrastructure databases ( KRRM-86 ), they only talk to services. The deployment of services should also allow for code decoupling ( KRRM-84 ). So, rather than looking at these as individual issues, to me they part of a bigger architectural research effort, i.e. transforming Rice into independent services which also means Rice as “embedded” is deprecated at some point. I believe there is already a jira ticket related to SOA but not sure if it’s a good fit. Eric would know. Even if we conduct the research separately I believe there is benefit in relating these re-architecture items thematically so the end goal is readily apparent.

              People

              • Assignee:
                ewestfal Eric Westfall
                Reporter:
                cfairlie Cath Fairlie (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: