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

Investigate whether the "embedded" workflow engine model should be changed to not require direct database access from client applications

    Details

    • Type: Rice Research Item
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Component/s: KEW
    • Labels:
      None
    • Rice Theme:
      Ease of Implementation
    • Priority Score:
      0
    • Functional Justification :
      There really isn't much of a functional justification for this issue. There is the potential for functional impact depending on which direction we might go. See issue description for more details.
    • Technical Justification:
      See issue description for technical justification.
    • Priority - KFS:
      No Priority
    • Priority - KC:
      No Priority
    • Priority - KS:
      No Priority
    • Priority - Rice:
      No Priority
    • Theme:
      Ease of Implementation, Service Orientation, Versioning Compatibility
    • Application Impact:
      Medium
    • Effort Estimate:
      High ~ 1000 hrs

      Description

      I've gotten suggestions and questions from some clients about how they worry about the embedded workflow integration model because it requires direct database access to the Rice standalone server's database from all of their client applications. I've long held concerns about this myself but at the time it was really the only way to implement what we needed for the embedded workflow engine to work and be transactional. A couple of things to consider here:

      1) At the time (and it may still be the case) WS-AtomicTransaction was not mature and functional, especially not in the context of open source free software. Maybe the landscape has changed here now. If we had support for distributed transactions over web services, then we could add support for that instead of requiring the client application to participate in a transaction with the rice database via a global JTA transaction.

      2) Currently, using the KNS requires the embedded KEW model. This requirement is in place because of transactional issues that arise when using KEW in thin client mode (i.e. remote web services). However, for some clients it would be really nice if we offered this as an option if they can deal with occasional synchronization issues between their application and the workflow services. The KNS is written to use the API services of KEW exclusively, so the only issue to deal with here really is the transaction and visibility problems.

      3) Another option to consider would be to allow for the workflow engine itself to still be embedded in the client application, but have all processing happening locally, and then synchronized (in near real time) to the central Rice database (this would include documents created, action requested that would feed the action list etc.). This is an intriguing option although it seems like it would result in a fairly complex architecture with the potential to lose data if it's not implemented correctly. Also, the synchronization to the rice central services would have to be done quickly without much lag or user experience would suffer greatly.

      One other comment here. The embedded model with direct access to the database is really a very, very difficult issue to deal with in terms of version compatibility because it requires certain database tables to essentially remain unchanged between versions since we aren't going through a proper service layer from client to server.

      Summary of work involved: The embedded workflow model currently requires direct database access from client application. This is inherently insecure since every client application maintains database connections to the Rice database server and therefore theoretically can read or have access to document data they should have no business having access to. While the functional benefits of this are minimal, depending on the direction we go, the additional flexibility in relation to version compatibility and added security would be large technical benefits.

        Attachments

          Issue Links

            Activity

            Hide
            ewestfal Eric Westfall added a comment -

            Depending on which of the options we choose to go with, we are looking at potentially a lot of work to address this, so I will set the work estimate at the worst possible scenario.

            Show
            ewestfal Eric Westfall added a comment - Depending on which of the options we choose to go with, we are looking at potentially a lot of work to address this, so I will set the work estimate at the worst possible scenario.
            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:
                ewestfal Eric Westfall
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: