Jangle's architecture is intended to enable any ILS system to be plugged in via a Connector, using one of these mechanisms:

1. BaseConnector with local data (read-only)

In this scenario, a user exports data from their ILS into a format suitable for importing into the Jangle BaseConnector store. They then use a cron job or similar to take the formatted data and push it into the BaseConnector store. However, there would be no means for the BaseConnector to write back into the real ILS database.

Example: export from III catalog into BaseConnector.

See: BaseConnectorWithLocalDataTutorial for an example of how to do this.

2. RESTful adapter for existing API (read/write, depending on what the existing API supports)

If the ILS provides an API (e.g. XML), Jangle could be used to adapt this API and present it via REST services. This may be useful in situations where the ILS provides XML output data in response to non-REST requests (e.g. CORBA, SOAP), but you want to provide a simpler REST interface to the ILS. It could also be useful where you want to provide a coarse-grained facade to a fine-grained set of low-level services.

Example: building a Jangle connector for an ExLibris Aleph installation which wraps its X-server API.

3. Bolt-on RESTful API (read/write)

Another approach would be to bypass the ILS's API altogether, and recreate the business logic of the ILS in the Jangle connector. Domain objects from the ILS could then be transformed into Jangle objects and mediated through Jangle to clients. This approach is only possible where you have direct access to the source code/business logic/SQL used in the ILS. It could be useful where you want to add a standard REST layer to an ILS which lacks one.

Example: building a Jangle connector for a SirsiDynix Unicorn installation.