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.

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

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 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.

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?)

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 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