Details

      Description

      Create a REST services top level component with the following sub components: filemgr-services, workflow-services, and pcs-services. Filemanager and workflow services are for our core components and will build to a war project. PCS services will build to a war but will have cross cutting services and depend on filemgr and workflow services; this will be accomplished via a web overlay. UIs can then build on these services or tailor their own where necessary. This modularity will allow for a wide variety of deployment methods and would even allow the same set of filemanager services to be installed multiple times each configured to talk to a different filemgr. This breakdown will give us a clear path of where to develop services and will hopefully prevent duplication of effort.

        Issue Links

          Activity

          Hide
          Paul Ramirez added a comment -

          I believe this approach accomplishes the best of both worlds and avoids a "goober" project where everything is clumped in one tree with a ball of services. A good side benefit of this approach is it will allow multiple versions of a services component to be installed and configured differently. For example, this means that it would be easy to install the filemgr-serivces war three times in different contexts simply configured differently to talk to different filemanagers. Originally I thought the "goober" approach would be best but as it now stands I think this will give OODT Rest Services the most modularity in practice.

          Show
          Paul Ramirez added a comment - I believe this approach accomplishes the best of both worlds and avoids a "goober" project where everything is clumped in one tree with a ball of services. A good side benefit of this approach is it will allow multiple versions of a services component to be installed and configured differently. For example, this means that it would be easy to install the filemgr-serivces war three times in different contexts simply configured differently to talk to different filemanagers. Originally I thought the "goober" approach would be best but as it now stands I think this will give OODT Rest Services the most modularity in practice.
          Hide
          Paul Ramirez added a comment -

          I'll post a patch later this week (probably weekend) to show how the poms will be setup and the build artifacts created. This will give people something tangible to talk about.

          Show
          Paul Ramirez added a comment - I'll post a patch later this week (probably weekend) to show how the poms will be setup and the build artifacts created. This will give people something tangible to talk about.
          Hide
          Chris A. Mattmann added a comment -
          • classify
          Show
          Chris A. Mattmann added a comment - classify
          Hide
          Paul Ramirez added a comment - - edited

          Part of this should take the services built in OODT-139 and package them into this tree.

          Show
          Paul Ramirez added a comment - - edited Part of this should take the services built in OODT-139 and package them into this tree.
          Hide
          Chris A. Mattmann added a comment -
          • push out
          Show
          Chris A. Mattmann added a comment - push out
          Hide
          Chris A. Mattmann added a comment -
          • push out to 0.6
          Show
          Chris A. Mattmann added a comment - push out to 0.6
          Hide
          Chris A. Mattmann added a comment -

          It's been 2 years on this one, and I'm more a fan of the build services (JAX-RS) in each package, which is occurring (see fmprod and workflow CXF services). If someone wants to build a package like this, please do so, but for now I'm closing it.

          Show
          Chris A. Mattmann added a comment - It's been 2 years on this one, and I'm more a fan of the build services (JAX-RS) in each package, which is occurring (see fmprod and workflow CXF services). If someone wants to build a package like this, please do so, but for now I'm closing it.

            People

            • Assignee:
              Paul Ramirez
              Reporter:
              Paul Ramirez
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:

                Development