=Paper= {{Paper |id=None |storemode=property |title=Meta-Services als zusätzliche Beschreibungsdimension von Cloud-Services |pdfUrl=https://ceur-ws.org/Vol-705/paper16.pdf |volume=Vol-705 |dblpUrl=https://dblp.org/rec/conf/zeus/Schmidt11 }} ==Meta-Services als zusätzliche Beschreibungsdimension von Cloud-Services== https://ceur-ws.org/Vol-705/paper16.pdf
    Meta-Services als zusätzliche Beschreibungsdimension
                     von Cloud-Services

                                    Rainer Schmidt

                                     HTW-Aalen
                                 Anton-Huber-Straße 25
                                     73430 Aalen



       Abstract. Meta-Services sind ein Konzept zur              Darstellung   von
       Verwaltungsinteraktionen im Kontext von Cloud-Services.

       Keywords: Cloud-Services, Meta-Services


1     Einleitung
Die Bereitstellung eines Service wird im Allgemeinen als die Bereitstellung einer
bestimmten Funktionalität betrachtet, die Qualitätsparametern wie Zuverlässigkeit,
Antwortzeit etc. erfüllen soll. Cloud-Services sind Services, die durch Cloud-
Computing [1], [2] bereitgestellt werden. Cloud Services unterscheiden sich von
Web-Services [3] durch die Bereitstellung von automatisierten Interaktionen [4] zur
Unterstützung des gesamten Lebenszyklusses. Ein Beispiel ist eine Beschwerde eines
Kunden. Diese hat zum Ziel, den Service wieder in den vom Kunden erwarteten
Zustand zu versetzen, ist aber nicht Teil des eigentlichen Cloud-Service.
 Die Verwaltungsinteraktionen zu einem Cloud-Service stellen eine vom
Diensterbringer zusätzlich bereitzustellende Funktionalität dar, die zudem mit
Qualitätsparameter erfüllen müssen. Sie sind nicht Bestandteil der Funktionalität des
Cloud-Service sondern wirken auf den Cloud-Service ein. Beispielsweise sollte eine
Beschwerde innerhalb einer bestimmten Zeit bearbeitet werden, was einem Service
Level Agreement entspricht [5]. Eine Verwaltungsinteraktion bietet also eine
bestimmte Funktionalität unter Einhaltung definierter Qualitätsparameter an.
  Daher sollen die Verwaltungsinteraktionen selbst wieder als Services dargestellt
werden. Diese Services unterscheiden sich vom Cloud-Service dadurch, dass sie nicht
auf das Objekt des Cloud-Service einwirken, sondern auf diesen selbst. Es handelt
sich also um einen Service, der einen Service als Objekt hat. Sie sollen daher als
Meta-Services bezeichnet werden. Die Menge der Meta-Services ist nicht
vorgegeben. So liegt es im Ermessen des Cloud-Service-Anbieters die Menge der von
ihm angebotenen Meta-Services festzulegen. Dies kann auch auf der Grundlage von
Marketingüberlegungen geschehen. Beispielsweise kann ein Basis-Cloud-Service mit
nur wenigen Meta-Services angeboten werden, während ein höherwertiges Angebot
zusätzliche Meta-Services enthält.
2        Rainer Schmidt


  Ein erster Ansatz für eine Methode zur Bestimmung von Meta-Services ist die
Analyse des Lebenszyklusses des Cloud-Service. Kandidaten für Meta-Services
ergeben sich aus Veränderungen des Lebenszyklusses. So kann jede Veränderung des
Zustands eines Cloud-Service als Meta-Service interpretiert werden. Wichtig ist
dabei, die Betrachtung auch auf die Ausprägungsebene auszudehnen. So gibt es Meta-
Services, die sich auf Ausprägungen des Service beziehen. Ein Beispiel ist eine
Beschwerde, die sich auf die Qualität der Service-Erbringung im Einzelfall und nicht
auf die Struktur des Service als solchen bezieht.
  Meta-Services sind von den Cloud-Services sowohl unter Funktionalitäts- als auch
unter Qualitätsaspekten unabhängig. Die Unabhängigkeit unter dem funktionalen
Aspekt zweigt sich auf Typ- und Ausprägungsebene. Auf Typ-Ebene zeigt sich dies,
indem ein und derselbe Meta-Service mehreren Cloud-Services zugeordnet sein kann.
Beispielsweise kann ein Meta-Service zur Bearbeitung von Beschwerden eine Menge
von Cloud-Services zugeordnet sein, die gänzlich unterschiedliche Aufgaben erfüllen.
Gleichzeitig können verschiedenen Cloud-Services unterschiedliche Mengen von
Meta-Services zugeordnet sein, um beispielsweise unterschiedlichen Kundenkreisen
Rechnung zu tragen. Auch auf Ausprägungsebene wird die Unabhängigkeit von
Cloud- und Meta-Services bei Kardinalitäts- und Zeitbeziehungen deutlich. So gibt es
keine allgemeine Kardinalitätsbeziehungen zwischen einer Ausprägung eines Cloud-
Service und eines Meta-Service. D.h. zur Ausprägung eines Cloud-Service kann es
keine, eine oder mehrere Ausprägungen des Meta-Service geben. So kann es zur
Ausprägung eines Cloud-Service keine, eine oder mehrere Beschwerden geben. Es
gibt weiterhin keine allgemeingültige zeitliche Beziehung zwischen Ausprägungen
von Services und Meta-Services. D.h. Ausprägungen von Meta-Services können vor,
während oder nach den Ausprägungen des Service existieren. Ein Beispiel sind
Verbesserungsvorschläge zu Services, die zu beliebigen Zeitpunkten vom Nutzer des
Cloud-Service gemacht werden können. Auf Qualitätsebene wird die Unabhängigkeit
dadurch      deutlich,    dass     Meta-Services       komplett     unterschiedliche
Qualitätseigenschaften wie der Cloud-Service haben können. Einem rund um die Uhr
verfügbaren Cloud-Service kann ein nur für kurze Zeit verfügbarer Meta-Service
zugeordnet sein.


2     Literatur
[1]    P. Mell and T. Grance, “The NIST Definition of Cloud Computing,” 10-Jul-2009.
      [Online]. Available: http://csrc.nist.gov/groups/SNS/cloud-computing/. [Accessed:
      14:17:52].
[2]    M. Armbrust et al., “A view of cloud computing,” Communications of the ACM, vol. 53,
      no. 4, pp. 50-58, 2010.
[3]    M. P. Papazoglou, “Service-oriented computing: Concepts, characteristics and
      directions,” in Web Information Systems Engineering, 2003. WISE 2003. Proceedings of
      the Fourth International Conference on, 2003, pp. 3-12.
[4]    M. Garschhammer et al., “Towards generic service management concepts a service
      model based approach,” in Integrated Network Management Proceedings, 2001
      IEEE/IFIP International Symposium on, 2002, pp. 719-732.
[5]    M. Glinz, “On non-functional requirements,” in Requirements Engineering Conference,
      2007. REʼ07. 15th IEEE International, 2007, pp. 21-26.