Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-8867

Applications access data via Rest services versus via direct database access

    Details

    • Similar issues:
      KULRICE-5212Implement RuleService, RuleAttributeService, and related such that they are accessed remotely via SOAP instead of via direct database calls to the rule tables
      KULRICE-6519Service which deal with cross-application data should implement appropriate fine-grained security models for access to that data
      KULRICE-8197Expose access to CacheManagerRegistry through an api service locator
      KULRICE-14202Implement a mechanism by which access can be granted to REST-ful apis
      KULRICE-8696Some KEW API classes/services are not accessible via any service locator
      KULRICE-13450Load Test Data - DB access tool
      KULRICE-4140KimTypeInfoService cannot be accessed by "remote" KIM clients directly
      KULRICE-7184Please provide a framework or api call to allow access to CacheManagers
      KULRICE-14143POC: REST-ful API to KIM Groups
      KULRICE-12410Modify KEW so the rule tables are accessed directly in embedded mode
    • Epic Link:
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Security
    • Application Requirement:
      KS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      For CRUD operations.

      Based on conversations with Garey, we would like this to focus on Rest services and how they can be better integrated with KRAD.

        Issue Links

          Activity

          Hide
          William Washington (Inactive) added a comment -

          Ability to write a screen only using XML and noting what the service is and the method to call. This would allow the more easily creation of CRUD screens for things like code tables (e.g. Org admin, Academic Time Period.).

          Rationale/Background - KS currently has to write controller logics that translates and update button to call the update method in the service for the object. The workaround has been to write the glue code for each controller (using maintainable & lookable). KS doesn't want to have to maintain all that code. But in some cases, KS screens are so complex that we need custom controllers anyway.

          Show
          William Washington (Inactive) added a comment - Ability to write a screen only using XML and noting what the service is and the method to call. This would allow the more easily creation of CRUD screens for things like code tables (e.g. Org admin, Academic Time Period.). Rationale/Background - KS currently has to write controller logics that translates and update button to call the update method in the service for the object. The workaround has been to write the glue code for each controller (using maintainable & lookable). KS doesn't want to have to maintain all that code. But in some cases, KS screens are so complex that we need custom controllers anyway.
          Hide
          Garey Taylor added a comment -

          I believe KRAD has been looking into having the client call directly to REST/JSON services. I'd be interested in hearing Rice's thoughts on that possible path. This might allow more of a decoupling of the front end, designed with krad beans and the backend.

          Show
          Garey Taylor added a comment - I believe KRAD has been looking into having the client call directly to REST/JSON services. I'd be interested in hearing Rice's thoughts on that possible path. This might allow more of a decoupling of the front end, designed with krad beans and the backend.
          Hide
          Jessica Coltrin (Inactive) added a comment -

          We need more info here since it's not clear what's wanted here. Peter and Garey should meet and generate user stories so we know what's needed. Also if the estimate is over 200 hours this needs to go to KRRM queue.

          Show
          Jessica Coltrin (Inactive) added a comment - We need more info here since it's not clear what's wanted here. Peter and Garey should meet and generate user stories so we know what's needed. Also if the estimate is over 200 hours this needs to go to KRRM queue.
          Hide
          Larry Symms added a comment -

          please include me in any conversations on theis topic

          Show
          Larry Symms added a comment - please include me in any conversations on theis topic
          Hide
          Peter Giles (Inactive) added a comment - - edited

          I chatted with both Garey and Larry this week on this issue.

          Garey's take was, in a nutshell, that they want to be able to author pages with KRAD that work more like angular.js pages in that all the back end interaction is done via RESTful services. The wins would be:

          • a stronger separation of concerns that frees front end developers from writing custom controllers.
          • faster development of new screens
          • improved performance and scalability

          Talking to Larry, the heart of this request is that instead of dealing with data objects and persistence in KRAD, they would like to be able to configure a screen (e.g. a maint doc) to utilize a RESTful service to handle the CRUD operations on the data. They specifically want to use JSON data formats and client side data binding. This will help KS to achieve its architectural objectives and allow them to develop screens in a way that meets their needs.

          A key issue that Larry brought up is one of timing. Currently, 2.6 is the last version of Rice that KS is definitely going to take. After that they will be making their upgrade decisions based on impact that they are willing to accept. That imposes an aggressive time line on us to deliver this functionality if they are going to be able to take advantage of it.

          Show
          Peter Giles (Inactive) added a comment - - edited I chatted with both Garey and Larry this week on this issue. Garey's take was, in a nutshell, that they want to be able to author pages with KRAD that work more like angular.js pages in that all the back end interaction is done via RESTful services. The wins would be: a stronger separation of concerns that frees front end developers from writing custom controllers. faster development of new screens improved performance and scalability Talking to Larry, the heart of this request is that instead of dealing with data objects and persistence in KRAD, they would like to be able to configure a screen (e.g. a maint doc) to utilize a RESTful service to handle the CRUD operations on the data. They specifically want to use JSON data formats and client side data binding. This will help KS to achieve its architectural objectives and allow them to develop screens in a way that meets their needs. A key issue that Larry brought up is one of timing. Currently, 2.6 is the last version of Rice that KS is definitely going to take. After that they will be making their upgrade decisions based on impact that they are willing to accept. That imposes an aggressive time line on us to deliver this functionality if they are going to be able to take advantage of it.
          Hide
          Jerry Neal (Inactive) added a comment -

          Is client side binding an absolute requirement for this? That requires KRAD to shift to a client side MVC framework, which even if we determined today we wanted to do would take a lot of time. We can get the benefits of Rest services with the server side binding. In fact, you can get 2 of the three mentioned benefits today. The back end can be provided with Rest services that your front end connects to (over the service bus). The only difference is currently you need to translate the data from the Rest services to data objects that KRAD can work with, so it is extra work for developing the screens. However, in general data from the backend needs to be transformed (for the presentation) in some way anyhow, with the exception of Maintenance, Lookup, and Inquiry. The real win I see would be allowing those frameworks to connect directly do a service for its CRUD operations, which is a long standing enhancement we have talked about.

          Show
          Jerry Neal (Inactive) added a comment - Is client side binding an absolute requirement for this? That requires KRAD to shift to a client side MVC framework, which even if we determined today we wanted to do would take a lot of time. We can get the benefits of Rest services with the server side binding. In fact, you can get 2 of the three mentioned benefits today. The back end can be provided with Rest services that your front end connects to (over the service bus). The only difference is currently you need to translate the data from the Rest services to data objects that KRAD can work with, so it is extra work for developing the screens. However, in general data from the backend needs to be transformed (for the presentation) in some way anyhow, with the exception of Maintenance, Lookup, and Inquiry. The real win I see would be allowing those frameworks to connect directly do a service for its CRUD operations, which is a long standing enhancement we have talked about.

            People

            • Assignee:
              Unassigned
              Reporter:
              William Washington (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:

                Structure Helper Panel