myEquivalents Configuration
##Composition of myEquivalents Managers
As explained elsewhere, managers are the way to access myEquivalents functionality. These consists of a set of interfaces and several implementations, such as the database implementation or the web service implementation.
Implementation flavours can be flexibly chained and combined, to suit a variety of functional and access needs. This is an example:
Here, there is a command line interface accesses a relational back-end directly (which is how the command line is configured by default), while another user is using another command line instance, which in turn uses the web service client (and the web service server) to gain access to the relational back-end. The same web service server is used by an app, by means of the web service client.
##Configuration based on Spring bean configuration file The above composition is achieved by means of the Spring framework. If you are not familiar with this, all you need to know is that you can configure the myEquivalents components in an XML file, the Spring bean configuration file, where you can specify which kind of concrete managers your interface will be coupled with and, possibly, a manager composition like the example above.
Please note that the example about RDF in the figure is about our future plans and you cannot really do that at present (there isn't any RDF version yet).
For instance,
- this is the default configuration, used in both the command line, programmatic database-based API and the web service.
- In this other example, you can see that the command line interface accesses myEquivalents through the web service client. Because the latter forwards requests to an HTTP web service, in this case you need to run such service separately, with its own spring bean configuration file (like the one for a relational database, so that the web service is backed by Oracle or MySQL). So, in the case of the web service, part of the manager chaining is implicitly realised by the HTTP layer and is based on different configuration files, on the client and the server side respectively. Obviously, in this scenario you might be the client only and rely on a server side already set up by some other organisation.
One important concept we want to stress is that components and endpoints in the above work flows are independent and transparently used. For example, you could switch from the command line accessing a database straight to the one that reaches it through the web service layer and you or your application using line commands would see no difference, i.e., wouldn't need to be changed. At least that is the idea, sometimes there are a few very minor inevitable exceptions to that, which are described elsewhere in myEquivalents documentation.
myEquivalents's distribution files can be build with predefined configurations. This is done with Maven and Maven profiles, as explained in the myEquivalents building page.
Whatever the component composition you choose to have in your myEquivalents installation, you must have the necessary distribution packages in order for your configuration to work. For example, if you want to use the programmatic interface, directly connected to the database back end, you'll need myequivalents-db_XXX.jar (which includes myequivalents-core_XXX.jar, also needed). If, instead, you're going to use the command line interface via the web service client, you'll need myequivalents-shell-XXX.zip and myequivalents-wscli_XXX.jar (and you don't need the web service's .war file on the client side, since this is on the server only).