1 / 9

CTP Migration

This document outlines the migration and release processes of the CTP (Clinical Trial Processor) software at CBIIT. It details how JP generates new CTP releases utilizing CIP requests, the integration of new features, and manual regression testing conducted for stability. The tech stack and architecture are discussed, focusing on a monolithic structure, goals for future development, improving stability, and maintaining a pipeline. Steps for enhancing system functionality such as improving structure and moving toward SOA services are also included.

cornelia-corbin
Télécharger la présentation

CTP Migration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CTP Migration

  2. Overview and Background • Release Process • JP generates a new release of CTP. This could be based off CIP request, or other user of CTP. • CIP asks NBIA/CBIIT to incorporate new CTP. • We incorporate at next possible release depending on our schedule. • Incorporation includes manual regression testing. • We lock down the server-side version of the CTP. • We prescribe client-side version of CTP but no current way to lock this down.

  3. Files/Batch submission Data Filtering Local configuration Local status monitoring Architecture Client #1 CTP Client (HTTPS) Pipeline Process Admin Console Queue Mgmt (MONOLTHIC) Server Side Server Side CTP Client Configure File CTP Server Configure File NBIA accessible file system CTP Server (HTTPS) CTP/NBIA Adapter Client #2 CTP Client (HTTPS) DICOM Queue NBIA Database CTP Client Configure File DICOM Queue

  4. POSSIBLE GOALS • Prepare CTP for future development by CBIIT (leading to service development). • Insulate ourselves from JP and increase stability of CTP and CTP-NBIA integration. • Be able to accept new features and bug fixes from JP.

  5. Goal #1: Prepare for Future Development • Adding more security to CTP will require custom development at least. • CTP is developed from scratch with no dependence on J2EE. • For admin console (web interface), this means no JSP/JSF or Servlets, etc. All custom code. • Cannot plug in a “J2EE developer” without big learning curve. • Developing new functionality slow compared to J2EE.

  6. Goal #1: Prepare for Future Development (cont’d) • CTP is monolithic • CTP has admin console and pipeline processor coupled together. • CTP uses in-memory objects and files to integrate these two pieces fairly tightly. • Break apart into pipeline and admin console. • Definitely re-design console as J2EE webapp. • Investigate moving the pipeline to mainstream technology (MQ?)

  7. Goal #2:Insulating Ourselves • If the only goal is just to increase the stability, we can get a pretty big bang for our buck by creating a suite of automated functional regression tests. • I don’t believe JP has a rigorous testing scheme, but NBIA team hasn’t done an ideal job testing the integration either. • This won’t cover new features of CTP but will cover the important stuff – submission and the NBIA database adapter. • Regardless of whether we fork CTP source, this task should be a top priority.

  8. Goal #3: New Features from JP • If we fork the CTP code base at CBIIT and start to make drastic changes, new features and bug fixes from JP will become more difficult to integrate. • We will have to do a diff per release, and map the diff into our source base by hand. As our changes become larger, this process becomes more involved.

  9. Technical Approach thatplaces less weight on goal #3 • Step 1: Improve Stability and Maintainability • Fork the code • Add automated functional regression • Step 2: Improve Structure • Add management API to pipeline and alter existing console to use new API • Strip the Admin Console and move it to J2EE • Add necessary security to both pipeline and console • Investigate moving the Pipeline/Queue to mainstream tech (MQ?) • Step 3: Move towards SOA Services • Integrate with other Imaging Services, libraries • Move to Submission Service

More Related