90 likes | 216 Views
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.
E N D
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 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
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.
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 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