Overview
When deployed in your DuraCloud server, the Image Server (imgserver) deploys an instance of the Djatoka JPEG2000 image server. This Djatoka server is itself a web application that needs to be deployed into a servlet container. That is why the System WebApp Utility (webapputil) must already be deployed/running on your DuraCloud server before it is possible to deploy the imgserver. In the process of deploying the imgserver, the webapputil installs a new instance of Apache Tomcat running on the next available port. See the design description of the webapputil service for more details. Then the Djatoka image server is deployed into the newly installed Tomcat. Along with the Djatoka image server, an IIPImage Viewer configured to reference the newly deployed Djatoka image server is deployed into the newly created Tomcat.
This image viewer is designed to act as the local mechanism for images hosted in your DuraCloud account to be viewable in the administration application (DurAdmin). If the imgserver is deployed and an item with mimetype image/<any> is select in DurAdmin, then both a thumbnail will be generated (with the help of the Djatoka server) and clicking on the thumbnail or the 'view' button will bring up the local IIPImage viewer. Note, if the mimetype of the image is set to a non-image value, such as binary/octet-stream, then the imgserver will not be active for that content item.
Integration with external applications
Using DuraCloud image viewer and image server
A common use case for the Image Server service is to integrate it with your existing website to serve the JP2 files that are hosted in your DuraCloud account. In order to do this you need to provide a link in your existing website to the imgserver viewer with an HTTP parameter specifying the direct DuraCloud URL of the image item. An example link would be
<a href="http://180.12.34.56/adore-djatoka-p18080/viewer.html?rft_id=http://my.duracloud.org:80/durastore/jp2s/image-file.jp2%3FstoreID%3D0">My Image</a><br>
So in this example, the DuraCloud server has domain name "my.duracloud.org" with associated I.P. address of "180.12.34.56". The content is accessible through this address and the Djatoka image server is running (on a separate Tomcat/port) at the same address.
Notice, the I.P. address of your instance is required when referencing the image viewer. Using "http://my.duracloud.org/adore-djatoka-p18080" instead of "http://180.12.34.56/adore-djatoka-p18080" will not work.
Also note the "storeID" parameter. Here is the URL encoded value "?storeID=0". This is an optional parameter that can be used to specify the exact underlying storage provider from whence the image should come. See the REST API documentation for more details.
Using your own image viewer with DuraCloud image server
If on the other hand you would prefer to use your own image viewer instead of the IIPImage viewer deployed with the imgserver, this is also an option. In this case, within your viewer code, you need to configure it to reference the DuraCloud-hosted Djatoka resolver. In the example above, the resolver URL would be
http://180.12.34.56/adore-djatoka-p18080/resolver
Other considerations
Performance
The basic flow of interaction with the imgserver is that a
- request is made from a client-side viewer (e.g IIPImage Viewer) to the Djatoka resolver
- the Djatoka resolver retrieves the requested image as identified in the request URL
- converts it to JPEG2000 format if it is not already a JP2 file
- the Djatoka server serves the requested tiles of the image in JPEG format
In this flow, there is considerable latency in the Djatoka resolver retrieving the image file from the underlying cloud content store. This latency is only experienced the first time the image is requested. After the initial request, the tiles are cached by the Djatoka server. Therefore, improved user performance can be achieved by pre-caching the images requesting them when they are made publicly available.
Access
When the Djatoka resolver is retrieving web-based content, the Djatoka software is not currently designed to supply authentication credentials with the HTTP request. As a result, the Djatoka server will not be able to serve content that resides in a "closed" DuraCloud space. We have a patch to the Djatoka baseline to address this issue and are working with the Djatoka developers to have it incorporated. In the meantime, all content that you would like to be served via the imgserver must reside in an "open" DuraCloud space.
