Linked-USDL


Linked-USDL könnte man als eine Art Weiterentwicklung der bekannten WebService-Beschreibungssprachen, wie WSDL, OWL-S, WSMO oder hREST ansehen. Im Gegensatz zu den genannten Beschreibungssprachen geht Linked-USDL aber über die rein technische Beschreibung eines Dienstes hinaus. Ergänzt werden die technischen Beschreibungen um operative und betriebswirtschaftliche Informationen. Damit wird Linked-USDL nicht nur den IT-, sondern auch den wirtschaftlichen Bedürfnissen gerecht und passt sich damit der allgemeinen Service-Entwicklung an.

Linked-USDL wurde ursprünglich unter der Bezeichnung USDL (Unified Service Description Language) entwickelt und maßgeblich von SAP Research vorangetrieben. Im Jahr 2012 erfolgte mit Version 4.0 die Umbenennung in Linked-USDL, um auch namentlich zu zeigen, dass USDL nun den Linked Data Prinzipien folgt.

Linked-USDL setzt sich aus den nachfolgenden fünf Modulen zusammen. Ziel der Aufteilung war die Reduktion der Service-Komplexität, sodass Provider nur noch die Module nutzen können, die sie selbst auch wirklich brauchen. Nachfolgend die aktuell fünf bekanntesten Module
  • usdl-core: grundlegende Informationen
  • usdl-price: Kosten, Preismodelle usw.
  • usdl-agreement: Vertragliche Einigung, wie bspw. QoS-Eigenschaften (ersetzt usdl-sla)
  • usdl-legal: Vertragsdetails
  • usdl-sec: Sicherheitsaspekte

USDL-CORE im Detail

Nachfolgend die einzelnen Bestandteile von USDL-Core in der Übersicht.

usdl:ServiceOffering

Eine BusinessEntity kann über ein ServiceOffering einen oder mehrere Services dem Kunden anbieten. Ein Angebot enthält normalerweise einen Preis, rechtliche Informationen und auch Service Level Agreements. Durch ein Servie Offering wird ein Service handelbar gemacht.

usdl:Includes

Mit der Eigenschaft Includes kann man einen Service einem Service Offering hinzufügen. Dadurch kann ein Bundle von Services erzeugt werden, falls mehrere Dienste benötigt werden.

usdl:Service

Ein usdl:Service ist eine „BlackBox“-Beschreibung eines Dienstes, sprich die genaue Implementierung der verschiedenen angebotenen Funktionen wird nicht kommuniziert. Der Interessent bekommt hingegen eine Beschreibung des Zwecks des Dienstes, die unter anderem funktionale als auch nicht-funktionale Eigenschaften des Services beschreibt.

usdl:hasServiceModel

Mit der Eigenschaft hasServiceModel kann man ein ServiceModel einen Service zuweisen, das die Eigenschaften des Services beschreibt.

usdl:ServiceModel

Ein ServiceModel repräsentiert „Klassen“ von Services, d.h. Dienste die eine bestimmte Anzahl an Eigenschaften vereinen.

usdl:InteractionPoint

Eine InteractionPoint repräsentiert einen Schritt beim Zugriff oder Ausführung einer Operation eines Services. Dies kann auch dann relevant sein, falls Kunde und Anbieter sich in der Realität treffen müssen, um Parameter oder Ressourcen auszutauschen.

usdl:receives

Input (Ressource) die ein InteractionPoint benötigt.

usdl:yield

Output (Ressource) eines InteractionPoints.

usdl:hasContactMedium

InteractionPoints können verschiedene Kontaktmedien haben, z.B. Telefon oder Email.

usdl:hasInteractionType

Mit der Eigenschaft hasInteractionType kann man einem InteractionType ein ContactMedium zuweisen.

usdl:InteractionType

Verschiedenen Arten von Interaktionen die eine Entität mit einen InteractionPoint haben kann. Das kann beispielsweise Remote oder On-Site sein und auch die Beziehung Mensch-Maschine, Manuell/Automatisch kann hier spezifiziert werden.

usdl:involvedEntity

Beschreibt die Beziehungen der involvierten Entitäten.

usdl:InteractionEntity

Beschreibt die Beziehungen der interagierenden Entitäten.

usdl:BusinessRole

BusinessRole einer Entität. Dies kann beispielsweise ein Provider, Producer, Regulator, Intermediary, Consumer oder Customer sein.

Quellen und Verweise



Artikel vom 25.07.2016

Kommentare zum Artikel

comments powered by Disqus