Page History
Scrollbar | ||
---|---|---|
|
...
Page info | ||||
---|---|---|---|---|
|
Panel | ||||
---|---|---|---|---|
| ||||
|
Panel | ||
---|---|---|
| ||
Author: Craig Stancl, Scott Bauer, Kevin Peterson |
...
Version | Date | Description of Changes | Author |
---|---|---|---|
1.0 | 2013/02/21 | Initial Version | --- |
CTS2 REST Services
...
Peterson, Kevin Bauer, Scott |
1 Architecture Design
The CTS2 Development Framework is a development kit for rapidly creating CTS2 compliant applications. The Development Framework allows for users to create plugins which may be loaded into the Development Framework to provide REST Web Services that use CTS2 compliant paths and model objects. Because the Development Framework is plugin based, users are required only to implement the functionality that is exclusive to their environment. For example, in any REST service, a large portion of code must be written to accept HTTP requests, handle errors, accept parameters, etc. The Development Framework provides all of this infrastructure, as well as utilities to help create plugins. The developer then is left to create the implementation plugin, which is the code specific to the individual environment. For example, this code may retrieve data from a database, read data from a file system, aggregate two more other services, etc.
CTS2 is modeled abstractly (the Platform Independent Model or ‘PIM’) and for specific platforms (the Platform Specific Model or ‘PSM’). The CTS2 Development Framework attempts to transform these ideas into the MVC architecture style. Much like a traditional MVC implementation, multiple ‘Views’ expose the ‘Model’ with the help of the ‘Controller’. If we think of a ‘PSM’ as a ‘View’, and the CTS2 Development Framework acting as the ‘Controller’, a developer needs only to produce the ‘PIM’ based ‘Model’. Going further:
2 Model View Architecture (MVC)
2.1 Model
Transforms View (CTS2 PIM) structures into state (aka “backing store”)
Enforces post-conditions
May also enforce some invariants
2.2 View
Implements the static portion of the CTS2 model
(Indirectly) enforces some invariants
2.3 Controller
Implements the behavioral portion of the CTS2 model
Accepts events
Validates invariants
Enforces preconditions
1.1 Logical View
1.2 Software Architecture
1.2.1 High Level Structure
1.2.2 Basic Request Sequence
More
—
...
3 Logical View
The CT2 Development Framework (CTS2DF) is a Plugin-based Java toolkint. It is built on the OSGi
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
After initialization, the CTS2DF will use Service Plugin Implementations (or OSGi bundles) to implement the CTS2 functionality. These Service Plugins conform to a standard CTS2 interface, and are intended to be implemented according to the requirements of the implementer or organization. Furthermore, additional (non-CTS2) plugins can be registered to the service to provided extra functionality, such as security or caching. An added benefit of these plugins is that they can be shared across CTS2 implementations. Ultimately, the CTS2DF process the results of calls to these Service Plugins and transforms the responses into CTS2 compliant XML, JSON, or HTML.
4 Software Architecture
4.1 High Level Structure
The main responsibility of the CTS2DF is to accept incoming HTTP requests and delegate to the appropriate Service Plugin implementations. At a high level, the logic of accepting an incoming request is as follows:
START
WHILE TRUE:
ACCEPT HTTP REQUEST
SERVICE_INTERFACE = ServiceProvider.getService() #Ask the ServiceProvider for an Implementation
IF SERVICE_INTERFACE == NULL
THEN: RETURN NOT_IMPLEMENTED_ERROR #If not found, assume CTS2 Service is not Implemented
ELSE: SERVICE_INTERFACE.execute() #If matching implementation is found, execute it
END IF
END WHILE:
END
HTTP Requests are accepted and validated by a series of RestControllers. The responsibility of these RestControllers is to accept requests, parse parameters, and check all possible pre-conditions. They also connect the various HTTP requests to the appropriate CTS2 Profile Interfaces
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Service Discovery happens via the ServiceProvider
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
NOTE: Service Plugins are not required to implement all of the CTS2 Profile Interfaces. They may implement one, or all, or (most likely) some subset that matches the desired CTS2 functionality.
4.2 Basic Request Sequence
Represented graphically, an incoming request will follow the general sequence as outlined below. It is important to note the Condition case, as this allow Service Plugins to leave CTS2 Profile Interfaces unimplemented if the functionality is not needed. In this case, a "No-Op" Service is defaulted. The responsibility of this No-Op Service is to inform the requester, via the appropriate message, that the requested CTS2 Functionality is not available in this service implementation.
4.3 Independent Module Structure
LexEVS, implemented as a CTS2 Service Plugin, will implement the following CTS2 Profile Interfaces
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.1 CodeSystemVersionReadService
The CodeSystemVersionReadService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Specifically, the resolveCodingScheme
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.2 CodeSystemVersionQueryService
The CodeSystemVersionQueryService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Specifically, the getSupportedCodingSchemes
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.3 EntityDescriptionReadService
The EntityDescriptionReadService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.4 EntityDescriptionQueryService
The EntityDescriptionQueryService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.5 AssociationQueryService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.6 MapReadService
The MapReadService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.7 MapQueryService
The MapQueryService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.8 ValueSetReadService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.9 ValueSetQueryService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.10 ValueSetDefinitionReadService
The ValueSetDefinitionReadService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
4.3.11 ValueSetDefinitionQueryService
The ValueSetDefinitionQueryService
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
5 URI Resolution
One of the requirements of Resource Oriented Architecture is that every resource must have an identifier. As the Universal Resource Identifier (URI) is the primary identifier used by the Semantic Web, the CTS2 specification calls for all of its resources to be identified by URIs. This results in the need to distinguish the identity of the resource being described from the identity of the description itself, and the basic requirement that all servers in a CTS2 ‘ecosystem’ need to use the same identifiers if information is to be aggregated and shared in a meaningful fashion. The EVS solution for this problem is a URI resolution service, which provides a canonical URI for any local URI and does so as a service. For the EVS implementation of this service, a URI Resolver Service has been implemented and runs in conjunction with the EVS CTS2 implementation. While CTS2 users may install their own resolving service, based on the installation instructions here, a service is also running at this location. A thorough description of this service is to be found here.
6 Glossary
Service Plugin: An OSGi bundle capable of being loaded into the CTS2 Development Framework. In order to be recognized as a Service Plugin, the bundle must export one (and only one) Service of type ServiceProvider
Multiexcerpt include | ||||||
---|---|---|---|---|---|---|
|
Platform Independent Model (PIM): A implementation agnostic description of program functionality.
Platform Specific Model (PSM): An implementation model targeted towards a specific technical platform.
Scrollbar | ||
---|---|---|
|