Implementation of the BSP Services Architecture in the Tufts Morphology Service

Created by Bridget Almas
Last updated: Apr 18, 2013 by Former user (Deleted)
2 min read

The following diagram describes how the Tufts Morphology Service implements the BSP Services Architecture.

Blue identifies packages in the ROA layer, Red identifies packages in the SOA layer, Yellow identifies packages in the OOA layer.

Brown identifies the interfaces which consumers of/on the Bamboo platform need to be aware of in order to use the Morphology Service.

Purple highlights packages which have been derived from previously existing Perseus java code and modified for their use in Bamboo. They are integrated as classes under the org.projectbamboo package namespace. Gray highlights packages which have been reused from other open source projects, and included in the source tree but not changed in anyway (ideally, only the jar would have been included here, but for various reasons it was simplest at this point to include the code itself).

The Repository Service is in the SOA layer, but does not strictly follow the separation between SOA/OOA prescribed for scholarly services, which is the reason it is highlighted in an orangish-red. This package is used by both the Tufts Morphology and the Tufts Syntactic Annotation services and provides an SOA level service interface to different types of external text repositories. The Repository Service does not present a REST based interface to clients, or any direct access to clients outside the deployment environment, and so does not offer a corresponding ROA layer interface. The original intention was for this service also to mediate access to CMIS repositories, but this was deferred pending decisions about the approach to integrating the CI HUB into the BSP. If the Repository Service is extended and/or more widely used by other services on or consumers of the BSP platform, it might be worthwhile to do some refactoring so that it is more consistent with the other utility services.

Note that source code in the SOA and OOA packages is a mixture of Groovy and Java code. The Groovy code gets compiled to Java code at compile type, and the decision to use Groovy over Java was primarily one of convenience (the reused CTS libraries are in Groovy, and the initial service prototype, developed prior to definition of the BSP scholarly architecture, was done by Tufts in Groovy). Code references of interest: