CTS 2 Overview CTS 2 DEVELOPMENT FRAMEWORK Schedule

  • Slides: 29
Download presentation
CTS 2 Overview CTS 2 DEVELOPMENT FRAMEWORK

CTS 2 Overview CTS 2 DEVELOPMENT FRAMEWORK

Schedule • What is it? • Why a framework? • What does this do

Schedule • What is it? • Why a framework? • What does this do for me? • Plugins • Implementations available now • CTS 2 Compliance in two Java classes

CTS 2 Development Framework • Under development by Mayo Clinic • A Framework for

CTS 2 Development Framework • Under development by Mayo Clinic • A Framework for creating CTS 2 implementations • Uses Model View Controller (MVC) architectural pattern

CTS 2 Development Framework • A MVC architecture that is compliant with the CTS

CTS 2 Development Framework • A MVC architecture that is compliant with the CTS 2 API specification • Can be used to • Implement against different back ends (e. g. RDF, SQL, existing terminology structures or API’s) • Specify and/or create different import and export maps (IHTSDO, OWL, …)

CTS 2 Development Framework • Can be used to (continued) • Implement new views

CTS 2 Development Framework • Can be used to (continued) • Implement new views (21090, c. RDF, …) • Extend the controller with business rules and workflow constraints

CTS 2 Development Framework “Model” Component • Transforms View (CTS 2 PIM) structures into

CTS 2 Development Framework “Model” Component • Transforms View (CTS 2 PIM) structures into state (aka “backing store”) • Enforces post-conditions • May also enforce some invariants

CTS 2 Development Framework “View” Component • Implements the static portion of the CTS

CTS 2 Development Framework “View” Component • Implements the static portion of the CTS 2 model • Code. System. Catalog. Entry, … • (Indirectly) enforces some invariants

CTS 2 Development Framework “Controller” Component • Implements the behavioral portion of the CTS

CTS 2 Development Framework “Controller” Component • Implements the behavioral portion of the CTS 2 model • Accepts events • Validates invariants • Enforces preconditions

Why a Development Framework? • CTS 2 isn’t one implementation of the spec, it

Why a Development Framework? • CTS 2 isn’t one implementation of the spec, it (may be) many. • Different use-cases demand different implementations.

Why a Development Framework? • One CTS 2 implementation probably can’t, most likely shouldn’t,

Why a Development Framework? • One CTS 2 implementation probably can’t, most likely shouldn’t, and certainly doesn’t need to implement all of CTS 2

Why a Development Framework? • CTS 2 is large but very modular. You don’t

Why a Development Framework? • CTS 2 is large but very modular. You don’t want to support/maintain what you don’t need. • CTS 2 is a specification but you may need more – extensions may be needed. • Persistence back-ends are different.

What does this do for me? • Most web apps contain lots of boilerplate

What does this do for me? • Most web apps contain lots of boilerplate code – accepting HTTP requests, error handling, admin interfaces… etc. • We don’t want CTS 2 implementers writing boilerplate code!

What does this do for me? • Defines the CTS PIM interfaces in the

What does this do for me? • Defines the CTS PIM interfaces in the code. This is what implementers will implement. • Using these interfaces, the Development Framework will expose the implementation as HTTP REST (current), SOAP (planned)… etc. -- all using the same implementation.

What does this do for me? • Development tools provide • REST HTTP URL

What does this do for me? • Development tools provide • REST HTTP URL bindings • CTS 2 model as Java Beans • CTS 2 REST client • Various Builder pattern query building objects • Plugin admin structure

What DOESN’T this do for me? • Store content in a database/filesystem/triplestore • Read

What DOESN’T this do for me? • Store content in a database/filesystem/triplestore • Read content from a persistence store • Tell you what your persistence store should be

CTS 2 Implementations as Plugins • Actual implementations are bundled together as a “plugin”

CTS 2 Implementations as Plugins • Actual implementations are bundled together as a “plugin” to the framework. • Each plugin has its own classpath • May be implemented in Java, Groovy, Scala, Clojure… • Build support provided for Gradle and Maven

CTS 2 Implementations as Plugins Wait… is this OSGi? Yes – the Plugin Framework

CTS 2 Implementations as Plugins Wait… is this OSGi? Yes – the Plugin Framework is powered by Apache Felix. Any valid OSGi bundle is a valid CTS 2 Development Framework plugin.

CTS 2 Implementations as Plugins Is this OSGi (cont. )? OSGi allows you to

CTS 2 Implementations as Plugins Is this OSGi (cont. )? OSGi allows you to use off-the-shelf OSGi components and tools, along with custom created bundles.

What can a Plugin do? • • • Connect to a SQL database Connect

What can a Plugin do? • • • Connect to a SQL database Connect to a triple store Read from a file system Aggregate two or more existing CTS 2 services …

Plugin Behavior • Plugins may be • Activated • Deactivated • Removed • Uploaded

Plugin Behavior • Plugins may be • Activated • Deactivated • Removed • Uploaded • Discovered and Queried Plugins are hot-swappable. Changing plugins does NOT mean you must restart your container.

Plugin API • An admin API for plugin management is provided. The API is

Plugin API • An admin API for plugin management is provided. The API is REST based • Easy to hook into CI Servers to run integration tests

Implemented Plugins • e. Xist XML Database Plugin: • http: //informatics. mayo. edu/exist/cts 2/rest/codesystems

Implemented Plugins • e. Xist XML Database Plugin: • http: //informatics. mayo. edu/exist/cts 2/rest/codesystems • NCBO Bioportal Wrapper • http: //informatics. mayo. edu/cts 2/rest/codesystems • Others… (http: //informatics. mayo. edu/cts 2/index. php/Implementation s)

Implemented Plugins • e. Xist XML Database Plugin: • Based on the e. Xist

Implemented Plugins • e. Xist XML Database Plugin: • Based on the e. Xist XML Database • Supports: • READ • QUERY • MAINTENANCE

Implemented Plugins • NCBO Bioportal Wrapper • A Wrapper around the NCBO Bioportal REST

Implemented Plugins • NCBO Bioportal Wrapper • A Wrapper around the NCBO Bioportal REST • Service Supports: • READ • QUERY

Planned Plugins • Several… ongoing and expanding

Planned Plugins • Several… ongoing and expanding

A Service Plugin in two classes • http: //informatics. mayo. edu/cts 2/framework /example-plugin-tutorial/

A Service Plugin in two classes • http: //informatics. mayo. edu/cts 2/framework /example-plugin-tutorial/

Next steps • Solidify Development Framework Service Interfaces • Add a ‘Compliance Test’ suite

Next steps • Solidify Development Framework Service Interfaces • Add a ‘Compliance Test’ suite • Find common functionality and include it with the Development Framework • Add SOAP endpoint? • Allow ‘View’ plugins (allow for custom representations like CSV, text, Excel, etc…) • Loader Plugins

Resources Info: http: //informatics. mayo. edu/cts 2/framework/ Code: https: //github. com/cts 2

Resources Info: http: //informatics. mayo. edu/cts 2/framework/ Code: https: //github. com/cts 2

Questions?

Questions?