The CTS2 Development framework Overview.

1. CTS2 Overview
CTS2 DEVELOPMENT
FRAMEWORK

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

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

4. CTS2 Development Framework
• A MVC architecture that is compliant
with the CTS2 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, …)

5. CTS2 Development Framework
• Can be used to (continued)
• Implement new views (21090,
cRDF, …)
• Extend the controller with
business rules and workflow
constraints

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

7. CTS2 Development Framework
“View” Component
• Implements the static portion of the
CTS2 model
• CodeSystemCatalogEntry, …
• (Indirectly) enforces some
invariants

8. CTS2 Development Framework
“Controller” Component
• Implements the behavioral portion of
the CTS2 model
• Accepts events
• Validates invariants
• Enforces preconditions

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

10. Why a Development Framework?
• One CTS2 implementation probably
can‟t, most likely shouldn‟t, and
certainly doesn‟t need to implement
all of CTS2

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

12. 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 CTS2 implementers
writing boilerplate code!

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

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

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

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

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

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

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

20. 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 CTS2 services
• …

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

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

23. Implemented Plugins
• eXist XML Database Plugin:
• http://informatics.mayo.edu/exist/cts2/rest/codesystems
• NCBO Bioportal Wrapper
• http://informatics.mayo.edu/cts2/rest/codesystems

24. Implemented Plugins
• eXist XML Database Plugin:
• Based on the eXist XML Database
• Supports:
• READ
• QUERY
• MAINTENANCE

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

26. Planned Plugins
• RDF Triple-Store Plugin
• LexEVS Plugin

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

28. 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
• OSGi?

29. Resources
http://informatics.mayo.edu/cts2/framework/example-plugin-tutorial/
http://informatics.mayo.edu/cts2/framework/installation/
http://informatics.mayo.edu/cts2/framework/create-a-plugin/

30. Questions?