CTP Migration Overview and Background Release Process JP

CTP Migration

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.

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

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

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 J 2 EE. • For admin console (web interface), this means no JSP/JSF or Servlets, etc. All custom code. • Cannot plug in a “J 2 EE developer” without big learning curve. • Developing new functionality slow compared to J 2 EE.

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 J 2 EE webapp. • Investigate moving the pipeline to mainstream technology (MQ? )

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.

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.

Technical Approach that places 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 J 2 EE – 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