Presentation is loading. Please wait.

Presentation is loading. Please wait.

Good Fences Make Good Neighbors 1 Middleware for Aleph’s REST API Rich Wenger, E-resource Systems Manager MIT Libraries 1. Frost, Robert. “Mending Wall”

Similar presentations


Presentation on theme: "Good Fences Make Good Neighbors 1 Middleware for Aleph’s REST API Rich Wenger, E-resource Systems Manager MIT Libraries 1. Frost, Robert. “Mending Wall”"— Presentation transcript:

1 Good Fences Make Good Neighbors 1 Middleware for Aleph’s REST API Rich Wenger, E-resource Systems Manager MIT Libraries 1. Frost, Robert. “Mending Wall” Collected Poems of Robert Frost. New York, Henry Holt and Co., Print

2 Agenda 1.Short review of Aleph XML APIs 2.What is the API adapter? 3.Why did we build it? 4.Design criteria 5.How does it work? 6.Use cases Aleph IGeLU 2014 Page 2

3 Aleph XML APIs: X-server Aleph IGeLU 2014 Page 3

4 Aleph XML APIs: REST* 1.http://walter.mit.edu:1891/rest-dlf/patron/50481/circulationActions/loanshttp://walter.mit.edu:1891/rest-dlf/patron/50481/circulationActions/loans 2.http://walter.mit.edu:1891/rest-dlf/patron/164423/circulationActions/cashhttp://walter.mit.edu:1891/rest-dlf/patron/164423/circulationActions/cash * REpresentational State Transfer - rest-web-servicesrest-web-services Aleph IGeLU 2014 Page 4

5 Aleph XML APIs Aleph IGeLU 2014 Page 5 Aleph REST API External system Standard access configuration

6 What is the API adapter? 1.A thin layer of programming between the Aleph REST API and external systems that use the API. 2.A Perl program that runs from Aleph’s cgi-bin directory. Aleph IGeLU 2014 Page 6

7 What is the API adapter? Aleph IGeLU 2014 Page 7 Aleph REST API External system Adapter Access configuration with adapter installed

8 Why did we build it?  To insulate Aleph and the calling system from each other, particularly in the case of a competing vendor. The software reflects the business model.  To provide an avenue for problem circumvention that does not depend on either Aleph or the calling system. Aleph IGeLU 2014 Page 8

9 Why did we build it?  To minimize the latency of network traffic by bringing multiple calls to the API inboard on the Aleph server instead of extending them across the network.  APIs change over time and between releases. An intermediate layer can mask such changes unless or until they prove useful. Aleph IGeLU 2014 Page 9

10 Why did we build it?  Simplifies access control. There is one place to whitelist external servers instead of multiple Aleph configuration files.  Provides the flexibility to augment Aleph data from other local systems if so desired. Aleph IGeLU 2014 Page 10

11 Design – the adapter should..  Integrate easily into the Aleph server environment.  Have a small footprint and be unobtrusive in its operation.  Return results ~identical to those generated by the Aleph REST API. before and after before and after Aleph IGeLU 2014 Page 11

12 Design – the adapter should..  Not interfere in any way with the standard use of the Aleph REST API through the Tomcat/JBOSS server and port.  Consume Aleph REST API URL syntax without modification. Aleph IGeLU 2014 Page 12

13 Design – the adapter should..  Function in a transparent pass-through mode for all REST API services except for those intentionally modified by the host site. Aleph IGeLU 2014 Page 13

14 How does it work?  The adapter uses an Apache rewrite rule to direct REST URLs to itself running on port 80.  The external system sends its REST calls to port 80 instead of  The adapter parses the incoming URL and sends the request to the Aleph REST API via ‘localhost’.  Output from the REST API is passed back to the caller after any desired processing. Aleph IGeLU 2014 Page 14

15 Use case 1, ID translation  For patron functions, the REST API requires the patron’s Aleph id. Few, if any, authentication systems return an Aleph id as an identifier.  The REST API has no function to convert an alias to the corresponding Aleph id, but the X-server does.  This forces calling systems to use two calls across the network instead of one, and two different API’s. Aleph IGeLU 2014 Page 15

16 External System Aleph server JBOSS REST API Port 1891 Apache Ports 80, 443 Calls to Aleph REST API without the adapter installed. Two calls. X-server API XML

17 External System Aleph server JBOSS REST API Port 1891 Apache Ports 80, 443 Calls to Aleph REST API with the adapter installed in passive mode. Two calls. X-server API / XML Adapter

18 External System Calls to Aleph REST API with the adapter installed and using the X- server transparently. One call. XML Aleph server Apache Rewrite rule Adapter JBOSS REST API Port 1891 X-server API

19 Use case 2, data filtering  When using the adapter with the X-server.  The bor-info method returns historical data, including paid fines.  The adapter can filter paid fines from the response XML. Aleph IGeLU 2014 Page 19

20 Good Fences Make Good Neighbors Aleph IGeLU 2014 Page 20 Aleph REST API External system Maintain control of the terrain where systems meet.

21 Useful Links  REST architecture  Aleph REST API https://developers.exlibrisgroup.com/aleph/apis/Aleph-RESTful-APIs https://developers.exlibrisgroup.com/aleph/apis/Aleph-RESTful-APIs  Aleph X-server https://developers.exlibrisgroup.com/aleph/apis/Aleph-X-Services https://developers.exlibrisgroup.com/aleph/apis/Aleph-X-Services  Ex Libris Developer Network https://developers.exlibrisgroup.com/ https://developers.exlibrisgroup.com Aleph IGeLU 2014 Page 21

22 Finis Rich Wenger Phone Fax Aleph IGeLU 2014 Page 22


Download ppt "Good Fences Make Good Neighbors 1 Middleware for Aleph’s REST API Rich Wenger, E-resource Systems Manager MIT Libraries 1. Frost, Robert. “Mending Wall”"

Similar presentations


Ads by Google