InterDataNet Service Architecture

From InterDataNet

(Redirected from Service architecture)
Jump to: navigation, search
InterDataNet Service Architecture

IDN Service Architecture (IDN-SA) is made up of four layers: Storage Interface, Replica Management, Information History and Virtual Repository. Each layer interacts only with its upper and lower level but also relies on the services offered by IDN naming system. IDN-Nodes are the information that the layers exchange in their communications. In each layer a different type of IDN-Node is used: SI-Node, RM-Node, IH-Node and VR-Node. Each layer has as input a specific type of IDN-Node and applies on it a transformation on the relevant metadata to obtain its own IDN-Node type. The transformation (adding, modifying, updating and deleting metadata) recalls the encapsulation process used in the TCP/IP protocol stack. The different types of IDN-Nodes have different classes of HTTP-URI as identifiers.

  • Storage Interface (SI) provides the services related to the physical storage of information and an interface towards legacy systems. It offers a REST interface enabling CRUD operations over SI-Nodes. SI-Nodes identifiers are URLs.
  • Replica Management (RM) provides a delocalized view of the resources to the upper layer. It offers a REST interface enabling CRUD operations over RM-Nodes. RM-Nodes identifiers are HTTP-URI named PRI (Persistent Resource Identifier). RM presents a single RM-Node to the IH layer hiding the existence of multiple replicas in the SI layer.
  • Information History (IH) manages temporal changes of information. It offers a REST interface enabling CRUD operations over IH-Nodes. IH Nodes identifiers are HTTP-URI named VRI (Versioned Resource Identifier). The IH layer presents the specific temporal version of the Node to the VR layer.
  • Virtual Repository (VR) manages the document structure. It offers to IDN compliant applications a REST interface enabling CRUD operations on VR-Node. VR-Nodes identifiers are HTTP-URI named LRI (Logical Resource Identifier).

On top of the four layers of the Service Architecture, the IDN-Application layer uses the documents’ abstraction defined in the Container-Content principle. Interfacing to the VR layer, the application is entitled to specify the temporal instance of the document requested.

The communications between IDN-SA layers follow the REST paradigm through the exchange of common HTTP messages containing a generic IDN-Node in the message body and IDN-Node identifier in the message header.

IDN architecture envisages a three layers naming system [1]:

  • in the upper layer are used Logical Resource Identifier (LRI) to allow IDN-application to identify IDN-nodes. Each IDN-node can be referred thanks to a global unique canonical name and one or more "aliases";
  • in the second layer are used Persistent Resource Identifiers (PRI) in order to obtain a way to unambiguously, univocally and persistently identify the resources within IDN-middleware independently of their physical locations;
  • in the lower layer are used Uniform Resource Locators (URL) to identify resource replicas as well as to access them. Each resource can be replicated many times and therefore many URLs will correspond to one PRI.

Figure 4 outlines implementations of IDN -SA as a set of different software modules, one module for each layer. Each module, implemented using an HTTP server, will offers a REST interface. The interaction between IDN-compliant applications and IDN-SA follows the HTTP protocol as defined in REST architectural style too. CRUD operations on application-side will be enabled for the manipulation of data on a global scale within the Web.

IDN Middleware
IDN Middleware.png


  • [1] Chini, D., Pirri, F., Pettenati, M. C., Innocenti, S. & Ciofi, L. InterDataNet Naming System: a Scalable Architecture for Managing URIs of Heterogeneous and Distributed Data with Rich Semantics. Procedings of the FIS2009 Future Internet Symposium, Bernin 1-3 September 2009.
Personal tools