Abstract Service Interfaces

This page is a sub-page of our page on TELL ME.


The TELLME Reference Architecture:
The TELLME Reference Architecture

Intentional and realizational possibilities:
Intentional and realizational possibilities

Abstract interfaces for the TELLME system (large):
Abstract interfaces for the TELLME system (large)

Interacting through an Abstract Service Interface

We will illustrate service interoperability with an example from the cultural heritage sector, where interoperability of services presents huge challenges due to the underlying heterogeneity of the involved data structures. Two of the major representational standards for cultural heritage information, CIDOC and Spectrum, decided in 2015 to align their information models.

Service interoperability pattern
TELL ME D4.4 Figure 5: Service interoperability pattern

One way to do so, would be to “servicify” both of them by having them implement a common Abstract Service Interface (ASI) e.g., as depicted in Figure 5 where the ASI is called “Service”.

The implicit context of application of this interface is a specific service of type Service that we can call theService, and which has declared the following operational interface

• InputOutput whichOutput( ):
• InputOutput  whichInput( );
• Stakeholders forWhom( );
• Purpose why( );
• Workflow how( );
• Support fromWhom( );
• Constraints adheringToWhat( );
• PreConditions whichPreconditions( );
• PostConditions whichPostConditions( );

In the underlying programming language, typically Java or C++, you can then ask these interface questions to the service in question, by writing theService.fromWhom( ), theService.adheringToWhat( ), etc.. The result of this question/call to the service would then be of the type listed as the first words of the bulleted list. Hence, in our example, we would get back something of types Support respectively Constraints.

Abstract Service Factory:
Abstract Service Factory
TELL ME D4.4 Figure 6: An Abstract Service Factory (ASF)

Notation: GLAM is an achronym for Galleries, Libraries, Archives, Museums.

Notice how the GLAM_Client can create a CurationService purely by interacting with the abstract service classes ServiceFactory and CurationService. Therefore the GLAM_Client becomes more flexible since it is shielded from “concrete” (= realizational = implementational) knowledge about what kind of representation standard that is actually being used by the underlying system.

To ensure polymorphic (= “subtype-ignorant”) data binding, each representational standard must implement its own version of each of the abstract interface classes at the top of the type hierarchies shown in Figure 7.

Polymorphic data-type hierarchies
TELL ME D4.4 Figure 7: Polymorphic data type hierarchies

7 thoughts on “Abstract Service Interfaces

  1. I think this is one of the such a lot important info for me. And I am happy studying your article. The website style is wonderful, the articles are truly excellent : D. Good job, cheers!

  2. I blog quite often and I seriously thank you for your content. The article has really peaked my interest. I’m going to bookmark your site and keep checking for new information about once a week. I subscribed to your RSS feed too.

  3. Hello! I’ve been following your website for a while now and finally got the courage to go ahead and give you a shout out from Huffman Texas! Just wanted to mention keep up the fantastic work!

  4. Remarkable issues here. I am very happy to look your article. Thanks a lot and I’m having a look ahead to touch you. Will you please drop me a e-mail?

  5. It is in point of fact a nice and useful piece of info. I’m glad that you just shared this helpful info with us. Please keep us up to date like this. Thank you for sharing.

Leave a Reply