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

Review all services published from each module and determine which should be exported to the bus under which run modes (local, embedded, remote)

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.1
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-4622When running with standalone Rice, ImmediateEmailService never runs locally
      KULRICE-2721Add switch on KIM Configurer to make run in local or remote modes
      KULRICE-3721The "remote" run mode for KIM (and other Rice modules?) does not allow proper consumption of services from the bus
      KULRICE-2758Split KNS services for local vs. embedded
      KULRICE-7169Rice object lookup quickfinders not working when related module is in EMBEDDED mode
      KULRICE-4193Local/Standalone Rice cannot customize the exportation of certain SOAP services
      KULRICE-6783Incorrect service reference to RoutingReportService while running Routing report in embedded mode
      KULRICE-7354Standalone server is attempting to load remotable attributes locally
      KULRICE-6609KSB run mode should default to "remote"
      KULRICE-5069Determine best strategy for declaring/throwing exceptions from (remote) service layer
    • Rice Module:
      KIM

      Description

      When configuring a rice client application to use KIM "embedded" as opposed to "local" the various KIM soap and non-soap services shouldn't get published to the service bus. We need to check this for other services as well from all of the modules.

      We really only want the services to be hosted by default out of the rice standalone server. We should look at how this was set up in Rice 0.9.1.4 using the PropertyConditionalKSBConfigurer.

        Issue Links

          Activity

          Hide
          Eric Westfall added a comment -

          Setting as 1.0.1, will work on merging in PropertyConditionalKSBExporter as part of that work.

          Show
          Eric Westfall added a comment - Setting as 1.0.1, will work on merging in PropertyConditionalKSBExporter as part of that work.
          Hide
          Eric Westfall added a comment -

          This will be addressed when the changes are merged in for KULRICE-3492

          Show
          Eric Westfall added a comment - This will be addressed when the changes are merged in for KULRICE-3492
          Hide
          Eric Westfall added a comment - - edited

          Here are the notes I took when reviewing all of these services:

          if the "mode" for a particular module is local, then that means that it is "bundled". In these cases then this means the application is either the Rice standalone server or an application with all of Kuali Rice bundled with it and intended to be deployed without a Rice standalone server. In the case that the mode is "embedded" there are certain services that should not be published to the service bus.

          Next I'll break down each of the services for the different module and include whether it should be exported when the run mode is "local" or "embedded". For those that are exported when "embedded" they should also be automatically exported if the run mode is "local" (but not vice-versa!)

          Also, I will indicate which namespace the service is deployed under whether it's "constant" or "application" namespace. The former would mean that it's always published under a specific namespace (i.e. KEW) the later means it's published under a namespace which matches the client application from which the service is published (i.e. KFS)

          The items with stars have notes related to them below.

          KEW:

          WorkflowDocumentActionsService - embedded - application
          WorkflowDocumentActionsServiceSOAP - embedded - constant
          WorkflowUtilityService - embedded - application
          WorkflowUtilityServiceSOAP - embedded - local
          simpleDocumentActionsService - local - constant

          • enActionListEmailService - local - application
            WorkgroupMembershipChangeService - local - application
            ResponsibilityChangeService - local - constant (namespace is empty)
            DocumentRoutingService - embedded - application
            BlanketApproveProcessorService - embedded - application
            SearchableAttributeProcessorService - embedded - application
            DocumentRequeueProcessorService - embedded - application
            RuleCacheProcessorService - local - constant (namespace is empty)
          • RolePokerProcessorService - embedded - application
          • ImmediateEmailService - local - constant (namespace is empty)
            ActionInvocationProcessor - embedded - application
            MoveDocumentProcessor - embedded - application
            routeLogDerivedRoleTypeService - local - constant
            actionRequestDerivedRoleTypeService - local - constant
            adhocReviewPermissionTypeService - local - constant
            reviewResponsibilityTypeService - local - constant

          Notes:

          1) Why is enActionListEmailService being exposed on the bus? It was published in 0.9.1.4 but I'm not sure exactly what it's needed for
          Update: discovered this wasn't really used so it's no longer being exported
          2) Should the RolePokerProcessorService really be published by every client application
          Update: Yes it should because the implementation uses FlexRM which should essentially run in the context of the embedded workflow engine
          5) In 0.9.1.4 it was possible to run the immediate email service locally instead. Is this something we even want to allow?
          Update: I really can't think of a good reason for this to be run for embedded clients because it would require the client application to configure the email service.
          6) General question: do we need to allow client applications to individually choose services that can run locally or remotely? For example, run the Identity and Group services remotely, but run the permission service locally?
          Update: Possibly, but that would probably be something that's out of scope for the 1.0.1 patch.

          KIM:

          All of these services are - local - constant

          IdentityManagementNotificationService - local - constant
          kimIdentityService
          kimIdentityServiceSOAP
          kimRoleService
          kimRoleServiceSOAP
          kimRoleUpdateService
          kimRoleUpdateServiceSOAP
          kimGroupService
          kimGroupServiceSOAP
          kimGroupUpdateService
          kimGroupUpdateServiceSOAP
          kimPermissionService
          kimPermissionServiceSOAP
          kimPermissionUpdateService
          kimPermissionUpdateServiceSOAP
          kimResponsibilityService
          kimResponsibilityServiceSOAP
          kimResponsibilityUpdateService
          kimResponsibilityUpdateServiceSOAP
          documentInitiatorRoleTypeService
          documentEditorRoleTypeService
          documentOpenerRoleTypeService
          activePrincipalRoleTypeService
          permissionPermissionTypeService
          responsibilityPermissionTypeService
          rolePermissionTypeService
          groupPermissionTypeService

          These shouldn't be published at all I think (see notes below)

          • kimUiDocumentService
          • kimAuthenticationService

          Notes:

          1) kimAuthenticationService shouldn't even be exported
          Update: yes, this shoudl really only be deployed in a client application so there's no need to publish it on the bus. However, it's currently defined in KIMImplementationSpringBeans and should be in KIMInterfaceSPringBeans so that it gets loaded for the client application.
          2) All of the kim services should only be published to the service bus from the standalone Rice server and should have a constant value KIM (or a url in the case of webservices) for the namespace.
          3) kimUiDocumentService probably does not need to be exported to the service bus (is there a reason why it would need to be?)
          Update: I can't find a reason for this to be exported, I will remove it's exporter

          KNS:

          riceApplicationConfigurationService - embedded - application

          The following should not need to be published to the service bus as it should be expected that they will be deployed alongside KIM services where they don't need to be accessed over the bus.

          documentTypePermissionTypeService
          campusRoleService
          documentTypeAndAttachmentTypePermissionTypeService
          documentTypeAndRelationshipToNoteAuthorPermissionTypeService
          documentTypeAndNodeOrStatePermissionTypeService
          namespacePermissionTypeService
          namespaceOrComponentPermissionTypeService
          parameterPermissionTypeService
          batchFeedOrJobPermissionTypeService
          buttonPermissionTypeService
          actionRequestTypePermissionTypeService
          namespaceOrActionPermissionTypeService
          documentTypeAndEditModePermissionTypeService
          componentFieldPermissionTypeService
          componentSectionPermissionTypeService
          documentTypeAndNodeAndFieldsPermissionTypeService
          documentTypeAndExistingRecordsOnlyPermissionTypeService

          KCB:

          KCB-MessagingService - local - constant
          KCB-MessageDelivererRegistryAPI - local - constant

          KEN:

          sendNotificationKewXmlService - local - constant
          sendNotificationKewXmlSOAPService - local - constant
          KEN-KENAPIService - local - constant

          Notes (KCB/KEN):

          1) The KCB-MessagingService needs to be a constant and only exposed by the standalone server/local run mode, same with KCB-MessageDelivererRegistryAPI
          2) The KEN services should only be exposed in local mode

          Show
          Eric Westfall added a comment - - edited Here are the notes I took when reviewing all of these services: if the "mode" for a particular module is local, then that means that it is "bundled". In these cases then this means the application is either the Rice standalone server or an application with all of Kuali Rice bundled with it and intended to be deployed without a Rice standalone server. In the case that the mode is "embedded" there are certain services that should not be published to the service bus. Next I'll break down each of the services for the different module and include whether it should be exported when the run mode is "local" or "embedded". For those that are exported when "embedded" they should also be automatically exported if the run mode is "local" (but not vice-versa!) Also, I will indicate which namespace the service is deployed under whether it's "constant" or "application" namespace. The former would mean that it's always published under a specific namespace (i.e. KEW) the later means it's published under a namespace which matches the client application from which the service is published (i.e. KFS) The items with stars have notes related to them below. KEW: WorkflowDocumentActionsService - embedded - application WorkflowDocumentActionsServiceSOAP - embedded - constant WorkflowUtilityService - embedded - application WorkflowUtilityServiceSOAP - embedded - local simpleDocumentActionsService - local - constant enActionListEmailService - local - application WorkgroupMembershipChangeService - local - application ResponsibilityChangeService - local - constant (namespace is empty) DocumentRoutingService - embedded - application BlanketApproveProcessorService - embedded - application SearchableAttributeProcessorService - embedded - application DocumentRequeueProcessorService - embedded - application RuleCacheProcessorService - local - constant (namespace is empty) RolePokerProcessorService - embedded - application ImmediateEmailService - local - constant (namespace is empty) ActionInvocationProcessor - embedded - application MoveDocumentProcessor - embedded - application routeLogDerivedRoleTypeService - local - constant actionRequestDerivedRoleTypeService - local - constant adhocReviewPermissionTypeService - local - constant reviewResponsibilityTypeService - local - constant Notes: 1) Why is enActionListEmailService being exposed on the bus? It was published in 0.9.1.4 but I'm not sure exactly what it's needed for – Update: discovered this wasn't really used so it's no longer being exported 2) Should the RolePokerProcessorService really be published by every client application – Update: Yes it should because the implementation uses FlexRM which should essentially run in the context of the embedded workflow engine 5) In 0.9.1.4 it was possible to run the immediate email service locally instead. Is this something we even want to allow? – Update: I really can't think of a good reason for this to be run for embedded clients because it would require the client application to configure the email service. 6) General question: do we need to allow client applications to individually choose services that can run locally or remotely? For example, run the Identity and Group services remotely, but run the permission service locally? – Update: Possibly, but that would probably be something that's out of scope for the 1.0.1 patch. KIM: All of these services are - local - constant IdentityManagementNotificationService - local - constant kimIdentityService kimIdentityServiceSOAP kimRoleService kimRoleServiceSOAP kimRoleUpdateService kimRoleUpdateServiceSOAP kimGroupService kimGroupServiceSOAP kimGroupUpdateService kimGroupUpdateServiceSOAP kimPermissionService kimPermissionServiceSOAP kimPermissionUpdateService kimPermissionUpdateServiceSOAP kimResponsibilityService kimResponsibilityServiceSOAP kimResponsibilityUpdateService kimResponsibilityUpdateServiceSOAP documentInitiatorRoleTypeService documentEditorRoleTypeService documentOpenerRoleTypeService activePrincipalRoleTypeService permissionPermissionTypeService responsibilityPermissionTypeService rolePermissionTypeService groupPermissionTypeService These shouldn't be published at all I think (see notes below) kimUiDocumentService kimAuthenticationService Notes: 1) kimAuthenticationService shouldn't even be exported – Update: yes, this shoudl really only be deployed in a client application so there's no need to publish it on the bus. However , it's currently defined in KIMImplementationSpringBeans and should be in KIMInterfaceSPringBeans so that it gets loaded for the client application. 2) All of the kim services should only be published to the service bus from the standalone Rice server and should have a constant value KIM (or a url in the case of webservices) for the namespace. 3) kimUiDocumentService probably does not need to be exported to the service bus (is there a reason why it would need to be?) – Update: I can't find a reason for this to be exported, I will remove it's exporter KNS: riceApplicationConfigurationService - embedded - application The following should not need to be published to the service bus as it should be expected that they will be deployed alongside KIM services where they don't need to be accessed over the bus. documentTypePermissionTypeService campusRoleService documentTypeAndAttachmentTypePermissionTypeService documentTypeAndRelationshipToNoteAuthorPermissionTypeService documentTypeAndNodeOrStatePermissionTypeService namespacePermissionTypeService namespaceOrComponentPermissionTypeService parameterPermissionTypeService batchFeedOrJobPermissionTypeService buttonPermissionTypeService actionRequestTypePermissionTypeService namespaceOrActionPermissionTypeService documentTypeAndEditModePermissionTypeService componentFieldPermissionTypeService componentSectionPermissionTypeService documentTypeAndNodeAndFieldsPermissionTypeService documentTypeAndExistingRecordsOnlyPermissionTypeService KCB: KCB-MessagingService - local - constant KCB-MessageDelivererRegistryAPI - local - constant KEN: sendNotificationKewXmlService - local - constant sendNotificationKewXmlSOAPService - local - constant KEN-KENAPIService - local - constant Notes (KCB/KEN): 1) The KCB-MessagingService needs to be a constant and only exposed by the standalone server/local run mode, same with KCB-MessageDelivererRegistryAPI 2) The KEN services should only be exposed in local mode
          Hide
          Eric Westfall added a comment -

          All service exporters have been updated.

          Show
          Eric Westfall added a comment - All service exporters have been updated.

            People

            • Assignee:
              Eric Westfall
              Reporter:
              Eric Westfall
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 hours
                2h
                Remaining:
                Remaining Estimate - 2 hours
                2h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Structure Helper Panel