OASIS | Open Archiving System with Internet Sharing

Middleware Interface

The picture "CIANT: Front-end-Middleware-DBA Interfaces" describes two main interfaces implemented in the OASIS System. In this chapter we are going to describe the interface provided by the OASIS Middleware and used by the OASIS Frontend. The interface is based on HTTP protocol. Similarly to XML-RPC, our protocol uses XML-based responses. No other existing standards have been implemented in the protocol. We have created a new protocol designed specifically for OASIS needs which is far simpler that than existing standards such as XML-RPC or SOAP/WSDL.

While the protocol itself is based on HTTP, it is inherently state-less. The only exception is the parameter REQUESTID.

[bearbeiten]

CIANT: Front-end-Middleware-DBA Interfaces

[bearbeiten]

The communication runs in two phases

1. HTTP Request (it does not matter whether we use GET or POST method). 2. HTTP Response with the XML payload. The interface functionality can also be tested directly from a web-browser, which simplifies debugging of the middleware component. The idea of testing of separate components in component-based architecture has been described in [11]. The author adverts the advantages of component-based system, mainly the possibility of black-box unit and integration testing.

After entering the right URL into the web-browser without any parameters, the middleware responses in XML format.

The first line of the response must be a standard XML header defining the document encoding, which is UTF-8 by default. The next element in the response, the <response> root-element, contains all the information of the particular response. In this trivial case the response does not carry any data. However, as we can see, middleware provides a list of <action> elements defining the provided functionality. We also notice that the element <note> informs us about the most important parameter through which we may call a particular action. The name of such a parameter is ACT by default. Parameters may be either mandatory or optional depending whether <error> or <debug> element has been used.

[bearbeiten]

Action:AuthenticateUser

The action requires two parameters: USERNAME , PASSWORD. The response contains several elements <auth> depending on response from DB-Adapters.

[bearbeiten]

Example

#
<auth dbaprefix="ciant" dbadapter="CIANT" success="1"></auth>
<auth dbaprefix="mv" dbadapter="Montevideo" success="1"></auth>
<auth dbaprefix="zkm" dbadapter="ZKM" success="1"></auth>

[bearbeiten]

Action:Cleanup

[bearbeiten]

The action requires a single parameter REQUESTID. The response contains the element <done/>.

[bearbeiten]

Action:GetAllAttributes

The action requires a single parameter LANGUAGE. The response contains several <attribute> elements with additional sub-elements such as <name>, <type>, <label>...

Example

[bearbeiten]

Action:GetDbAdapters

The action does not require any parameters. The response contains several <dbadapter> elements.

Example

#<dbadapter prefix="ciant" 
baseurl="http://149.156.114.5/~oasis/ciant/">CIANT</dbadapter>
 <dbadapter prefix="mv" 
baseurl="http://149.156.114.5/~oasis/mv/">Montevideo</dbadapter>
 <dbadapter prefix="zkm"   
baseurl="http://149.156.114.5/~oasis/zkm/">ZKM</dbadapter>

[bearbeiten]

Action:GetDetail

The action requires two parameters: REQUESTID and RESOURCEID. The response contains a single <resource> element which comprises of many <attributes> elements. You should also notice that some attributes could be represented as multiple instances with the same name. The response might also contain additional elements <load-pending> or <seach-pending/> depending on middleware's asynchronous mechanism.

Example

[bearbeiten]

Action:GetResults

Required parameters are: REQUESTID, OFFSET, COUNT, ORDERBY, ORDERASC, VISIBLE. The response contains a single <total> element and several <resource> in same format as GetDetail action.

Example