Service-Orientierte Architekturen

Größe: px
Ab Seite anzeigen:

Download "Service-Orientierte Architekturen"

Transkript

1 Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 3: Design Prinzipien Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda

2 Aufbau der Vorlesung Kapitel Thema Referent 1 Einführung in Software-Architektur Sascha Alda 2 Einführung in SOA Sascha Alda 3 Entwurfsprinzipien für SOA Sascha Alda 4 Web Services I Sascha Alda 5 Web Services II Sascha Alda 6 Modellierung von Geschäftsprozessen (BPEL) Sascha Alda 7 Vertiefung SOA (BAM, BPEL4People, Ontologien) Sascha Alda 8 Exception Handling in SOA (Gastvortrag) 9 Einführung in Swordfish Alda, Preissler 10 RESTful Architekturen Sascha Alda 11 OSGi Service Plattform Sascha Alda 12 SOA für Shared Service Center (Gastvortrag) Folie 2

3 Ziele Besseres Verständnis der typischen (und komplexen) SOA-Eigenschaft Lose Kopplung Verstehen des Grundprinzipien eines Enterprise Service Bus Kennenlernen von Entwicklungsprinzipien für lose gekoppelte Architekturen Anwendung von Entwicklungsprinzipien für nicht-funktionale Eigenschaften Allgemeine Vertiefung der Erkenntnisse von SOA Folie 3

4 Aufbau der Vorlesung Kapitel 3: Design Prinzipien von Service-Orientierten Architekturen 1 Enterprise Service Bus 2 Entwurfsprinzipien für die Lose Kopplung 3 Entwurfsprinzipien für nicht-funktionale Anforderungen 3.1 Anpassbarkeit 3.2 Skalierbarkeit 3.3 Verfügbarkeit 3.4 Performanz 3.5 Benutzerfreundlichkeit (Exkurs) 4 Zusammenfassung und Ausblick Folie 4

5 Enterprise Service Bus (ESB) Bisherige Realisierung der Kommunikation zwischen Services: Point-to-Point: Service Consumer Application Sendet Anfragen an: <<ServiceProvider>> <<service>> Buchführung Überweisen( ) Empfängt Anfragen an: Endpunkt Nachteile: Geringe Zuverlässigkeit des Systems beim Ausfall Service Provider Hoher Anpassungsaufwand bei Änderung der IP-Adresse des Provider Hohe Kopplung in der Architektur Folie 5

6 Enterprise Service Bus (ESB) Service Consumer Application Service Provider 1 Service Provider 2 Sendet Anfragen an: Provider Bereitgestellt als: Provider Bereitgestellt als: Provider ESB {Falls ServiceProvider 1 ausfällt} Alternativer Ansatz: Einführung einer Mittlerkomponente (ESB) Alle Anfragen werden an den ESB geschickt Service Provider hat einen symbolischen Name, keine feste IP-Adresse Vorteile: Geringere Anpassungen beim Client, höhere Ausfallsicherheit, geringe Kopplung der Applikationen Nachteile: erhöhte Entwicklungskosten Weitere Anwendungen eines ESBs: Intelligentes Routing (Load Balancing, fachliches Routing, Failover) Ermittlung von Kennzahlen Folie 6

7 Aufbau einer SOA mit einer ESB und verschiedenen Services Service Registry Business Service (Entity Centric) Composed Service Business Service (Task Centric) Backend (z.b. SAP, DBs, Legacy, ERPs) Business Process Service Business Process Service ESB Application Service (z.b. Proxy) Trennung nach Eigentümern Web-Client Application Rich-Client Application Client- Ebene Portal Portal- / Präsentations- Ebene Orchestrierungs- Ebene Business Service (Entity Centric) Business Service (Task Centric) Service- Ebene Backend (z.b. SAP, DBs, Legacy, ERPs) Backend- Ebene Folie 7

8 Abgrenzung Service gegenüber Komponente Komponente KontoHandling Consumer Application Interface von Komponente KontoHandling Implementierung von Komponente KontoHandling Component Provider (Download Server) Download Interface Business Service (Entity Centric) Backend (z.b. SAP, DBs, Legacy, ERPs) Komponentenbasierte Applikationen besitzen oft eigenes User Interface (z.b. Java Beans, MFC) Hybride Komponentenbasierte Architektur SOA definiert kein Modell zur Abbildung von Service-Interfaces auf User Interfaces (Tools vorhanden z.b. )... sind zu erwerben (Komponentenmärkte), gehen in das Eigentum des Konsumenten über Business Services: keine Eigentümerschaft, obliegt weiterhin dem Service Provider... können ihrerseits (intern) über ein Service-Modell verfügen, um somit entfernt auf andere Services zugreifen zu können ( OSGi Service Plattform, Kapitel 8) Folie 8

9 Aufbau der Vorlesung Kapitel 3: Design Prinzipien von Service-Orientierten Architekturen 1 Enterprise Service Bus 2 Entwurfsprinzipien für die Lose Kopplung 3 Entwurfsprinzipien für nicht-funktionale Anforderungen 3.1 Anpassbarkeit 3.2 Skalierbarkeit 3.3 Verfügbarkeit 3.4 Performanz Diskussion: Sicherheit 3.5 Benutzerfreundlichkeit (Exkurs, Selbststudium) 4 Zusammenfassung und Ausblick Folie 9

10 Zentrale Anforderungen an eine SOA: Lose Kopplung Forderung bei SOA: Lose Kopplung der Services einer Anwendungslandschaft Vorteil: Reduktion der Abhängigkeiten zwischen Service Provider und Consumer Bessere Flexibilität bei notwendigen Änderungen, Wartungen, Austauschbarkeit von Services Erhöhte Effektivität (höhere Zuverlässigkeit bei Services) Nachteil: Erhöhter Aufwand für Integrationstechnik und Fehlerbehandlung U.u. schlechtere Performance Grad der Kopplung ist abhängig von Grad der fachlichen Entfernung einer rufenden Komponente zu einem gerufenen Service (verschiedene Anwendungsdomäne) Vertrauen in der Zuverlässigkeit des gerufenen Service z.b. hinsichtlich funktionale Korrektheit, Performance Wissen über Datentypen, Implementierungen Folie 10

11 Mögliche Formen loser Kopplung Vertrauen Wissen hoch viel gering wenig Entfernung nah fern Bereich Enge Kopplung Lose Kopplung Physikalische Verbindung Punkt-zu-Punkt Kommunikationsstil Synchron Asynchron Über Vermittler (ESB) Datenmodell Komplexe gemeinsame Typen Einfache gemeinsame Typen Binding Statisch Dynamisch Plattformspezifika Stark / viel Schwach / wenig Transaktionssicherheit 2PC (Two-Phase-Commit) Kompensation Deployment / Änderungen Gleichzeitig Zu verschiedenen Zeitpunkten Folie 11

12 Formen der Kopplung bei der Service Kommunikation Point-to-Point Synchron (z.b. innerhalb einer Java VM oder Netzwerk) :localcomponent :ServiceHandler :ServiceImplement :Backend AufrufComponent( ) Z.B. gekapselte Remote-Interaktion über RPC oder Java RMI zahlein( 30 EUR ) zahlein( 30 EUR ) checkkonto() Komponente ist während der Bearbeitung geblockt! zahlein( 30 EUR ) resultofoperation resultofoperation Folie 12

13 Formen der Kopplung bei der Service Kommunikation Point-to-Point Asynchron (z.b. innerhalb einer Java VM oder Netzwerk) :localcomponent :ServiceHandler :ServiceImplement :Backend AufrufComponent( ) Z.B. gekapselte Remote-Interaktion über RPC oder Java RMI Komponente ist während der Bearbeitung nicht geblockt! zahlein( 30 EUR ) Weitere Aufrufe möglich zahlein( 30 EUR ) checkkonto() zahlein( 30 EUR ) callbackresult resultofoperation (resultofoperation) Problem: Programmiersprachen (z.b. Java) oder Netzwerkprotokollen (z.b. HTTP) unterstützen meist nur synchrone Methodenaufrufe Folie 13

14 Formen der Kopplung bei der Service Kommunikation Implementierung der Asynchronität in Java mit Thread-Technologie und Client-seitiger Calllback-Methode: Callback-Methode, wird von Service Handle aufgerufen Source Code des Client Folie 14

15 Formen der Kopplung bei der Service Kommunikation Remote-Aufruf möglich hier: Beispiel: - Socket - RMI - SOAP - JMI Source Code der Service Implementierung Source Code des Service Handles Folie 15

16 Formen der Kopplung bei der Service Kommunikation Asynchrone Point-to-Point Kommunikation in Java: Asynchronität durch Nebenläufigkeit (Thread) und Client-seitge Callback Methode Vorteile: Client-System ist nicht geblockt, damit verbesserte Performance wegen erhöhter Parallelität Nachteile: Austauschbarkeit des Client-Systems nicht möglich, da feste Referenz auf Client in Callback-Methode Austauschbarkeit des Service (ohne Änderung des Client) nicht möglich, da feste Referenz in Service Handle implementiert Optimierung: Interceptoren Enterprise Service Bus Publish Subscriber Muster Folie 16

17 Formen der Kopplung bei der Service Kommunikation Asynchrone Kommunikation über Interceptoren: Service Handle (= Interceptor) kann vollkommen transparent für den Client zur Laufzeit eine neue Service-Implementierung bestimmen Mögliche Kriterien: Ausfall eines Service, fachliche Gründe, Load-Balancing u.a. In Praxis eher weniger verwendet Erweiterter Source Code des Service Handles Nachteil: kein zentrales Routing oder Service-Suche, aufwändige Operationen auf dem Client-Host Folie 17

18 Formen der Kopplung bei der Service Kommunikation Asynchrone Kommunikation über Enterprise Service Bus: Der Client sendet eine asynchrone Nachricht (inkl. fachlicher Service-Name, Operation, Eingabe-Parameter) an einen ESB, der diese dann an den entsprechenden oder äquivalenten Service weiterleitet In Praxis meistens verwendet Erweiterter Source Code des Client Nachteil: Client kann nicht entkoppelt werden zur Laufzeit (wegen direkter Referenz auf Client) Folie 18

19 Formen der Kopplung bei der Service Kommunikation Asynchrone Kommunikation über Publish-Subscriber Muster Client und Service Provider werden einen zentralen Registrierungsmechnismus komplett entkoppelt beide können zur Laufzeit ausgetauscht werden Beide melden sich mit symbolischen Namen an und (zur Laufzeit) ab In Verbindung mit ESB auch asynchrone Kommunikation möglich Service Consumer Application Consumer Name IP-Adresse Eintrag für Consumer vom TYP Cons1 kann sich zur Laufzeit wechseln Sendet Anfragen an: Provider subscribe Cons Bereitgestellt als: Cons1 MyCons ESB publish Service-Request from Cons1 to Provider1 publish Service-Response from Provider1 to Cons1 Provider Name IP-Adresse Provider Provider subscribe Service Provider Application 1 Sendet Antwort an: Cons1 Bereitgestellt als: Provider1 Folie 19

20 Formen der Kopplung bei der Service Kommunikation Aufbau des Publish Subscriber Muster SubscriberPool Consumer <<interface>> void subscribe( Consumer ) void unsubscribe( Consumer ) publish( ) ; 1 subscribers 0..* update( ) ; for all client in subscribers { consumer.update( ); } ConcreteSubscriberPool ConcreteConsumer getmoreinfos( ) update( ) ; Folie 20

21 Formen der Kopplung bei der Service Kommunikation Zusammenfassung Komplexität Hoch Asynchron ESB + Publish-Subscriber Asynchron ESB Asynchron mit lokalen Interceptoren Asynchron Point-To-Point Synchron ESB Gering Synchron Point-To-Point Eng Lose Kopplung Folie 21

22 Weitere Java-Frameworks für die asynchrone Kommunikation Java Message Service API (JMS) Programmierschnittstelle für die Ansteuerung einer Message Oriented Middleware (MOM) basierend auf Java (J2EE) Asynchrone und zuverlässige Kommunikation Server-Komponente muss diese API implementieren Open Source (GlassFish, OpenJMS) und kommerzielle Implementierungen (z.b. WebSphere MQ, SAP JMS) vorhanden Tipp: Java Mail API Programmierschnittstelle für die Ansteuerung von Mail-Servern über IMAP, POP3 Protokolle Asynchrone und zuverlässige Kommunikation Kann mit beliebigen Mail-Servern verwendet werden (z.b. Account über GMX) Sehr schlank Folie 22

23 Transaktionen vs. Kompensation Szenario: Wie kann bei verteilten Transaktionen (= Bündelung mehrerer kohärenter Lese- und Schreibzugriffen) auf verschiedenen Backends der gemeinsame Erfolg oder das gemeinsame Fehlschlagen ermittelt werden? Einhaltung von Transaktionseigenschaften (z.b. ACID) Ansatz aus dem Bereich der Datenbanksysteme: 2PC (Two Phase Commit) Protokoll: 1. Commit-request Phase 2. Commit Phase Folie 23

24 Transaktionen vs. Kompensation Nachteile von 2PC für Service-orientierte Architekturen: Setzt die Verfügbarkeit von allen teilnehmenden Systemen und Services voraus Probleme insbesondere bei langläufigen Prozessen (Deadlocks) Bei Geschäftsprozessen wünscht man sich oft die Intervention mit dem Endbenutzer im Fehlerfall 2PC impliziert keine lose Kopplung Ansatz: Kompensation Die ersten n Teile einer verteilten Transaktion werden ausgeführt (d.h. Modifikation auf Backend-Systemen inkl. Commit) Bei Fehlschlagung (Abort) der n+1 Transaktion führt man eine fachliche Kompensation der bereits abgeschlossenen Transaktionen aus (abhängig vom Anwendungskontext) Beispiel: Stornierung einer Reise Folie 24

25 Beispiel einer Kompensation :InteraktionsKomp :ReservationProcess :FlightService :HotelServicce BookFlight ( Paris ) bookflight ( Paris, User) confirmation BookHotel( Hotel Plaza ) bookhotel( Plaza, User) Exception: Time OUT! Compensation [opt] AskUserOpinion() CancelFlight ( Paris, User) Folie 25

26 Aufbau der Vorlesung Kapitel 3: Design Prinzipien von Service-Orientierten Architekturen 1 Enterprise Service Bus 2 Entwurfsprinzipien für die Lose Kopplung 3 Entwurfsprinzipien für nicht-funktionale Anforderungen 3.1 Anpassbarkeit 3.2 Skalierbarkeit 3.3 Verfügbarkeit 3.4 Performanz 3.5 Benutzerfreundlichkeit (Exkurs) 4 Zusammenfassung und Ausblick Folie 26

27 Nicht-funktionale Anforderungen Nicht-funktionale Anforderungen definieren übergreifende Eigenschaften eines Software-Systems unabhängig von der zu implementierenden Funktionalität (Qualitätsanforderungen) Weitere Kategorien: Entwicklungsprozess Projekt Management Rechtliche Rahmen Manche nicht-funktionale Eigenschaften können als funktionale Eigenschaft reformuliert werden (z.b. Sicherheitsanforderungen)

28 Übersicht von nicht-funktionalen Anforderungen Zuverlässigkeit (Reliability) Anpassbarkeit (adaptability) Wartbarkeit (maintainability) Verständnis der Anwendung (understandability) Skalierbarkeit (scalability) Verfügbarkeit (availability) Effizienz (efficiency) Portabilität (portability) Bedienbarkeit (usability) Fehlertolerant (fault tolerance) Performanz (performance) Robustheit (robustness) Mobilität (mobility)

29 Formulierung von Nicht-funktionalen Anforderungen Nicht-funktionale Anforderungen werden in den Phasen Anforderungserhebung und Anforderungsanalyse beschrieben. Häufig High-Level Beschreibung in textueller Form. Beispiel (Performanz): Die Antwortzeit des Service sollte schnell sein Nicht-funktionale Anforderungen sollten quantifizierbar beschrieben sein: Die Antwortzeit des Service sollte weniger als 2 Sekunden betragen Bessere Verifikation und Testbarkeit Prototyping Testing (Akzeptanztests) Folie 29

30 Ableitung Entwurfszielen aus nicht-funktionalen Eigenschaften Aufgabe im System Design: Ableitung der nicht-funktionalen Eigenschaften hinzu konkreten Entwurfszielen (design goals) für die Ziel-Architektur Ableitung basiert auf fundamentalen Entwurfsprinzipien (tactics) [Bass, 2003]) Im Folgenden: Präsentation ausgewählter Entwurfsprinzipien: Verfügbarkeit Anpassbarkeit Performanz Skalierbarkeit Exkurs: Usability (in Englisch)

31 Anpassbarkeit Anpassbarkeit beschreibt Anforderungen an das System bezüglich der Einfachheit, notwendige Änderungen nach dem Deployment vorzunehmen. Subklassen: Adaptivität (Das System passt seine Struktur selber (autonom) an) Tailorabilität (Endbenutzer führen eigenständig Anpassungen durch) Bereiche: Antizipation von Änderungen Verzögerung von Entwurfsentscheidungen Policy-basierte Vereinbarungen (vgl. Übung)

32 Anpassung von Service Antizipieren von Änderungen Empfehlung: Identifikation von Services, die sich mit der Zeit angepasst werden Neue Technologien, neue Anbieter Änderung während des Software-Lebenszyklus (Mock-Up, Produkt) Anwendung des Strategie Pattern: <<serviceprovider>> <<concreteprovider>> :service Consumer AbstractService :Service (Mock-Up) <<concreteprovider>> :Service (Kommerzielles Produkt) <<concreteprovider>> :Service (OpenSource) Context

33 Anpassung von Service Verzögerung von Design- Entscheidungen Konventionelle Entwicklung: alle Design-Entscheidungen werden durch den Entwickler zur Entwicklungszeit herbei geführt Ergebnis: monolithische Architekturen, keine Anpassung möglich nach dem Deployment Ansatz: Verzögerung von Design-Entscheidungen zur Deployment Zeit oder während der Benutzungszeit des Systems Kontext-basierte Anpassung der Architektur durch einen Administrator den End-Benutzern oder durch das System selbst Kosten: Zusätzliche Infrastruktur zur Unterstützung von dynamischen Architektur-Anpassungen Gängige Techniken: Konfigurationsdateien (configuration files) Verzögerte Bindung der Services und Komponenten (late binding)

34 Anpassung von Service Verzögerung von Design- Entscheidungen durch Laufzeitumgebungen <<Laufzeitumgebung>> <<servicehandle>> :aservice <<service>> :aservice Anpassungservice Die Service-Laufzeitumgebung (service container) ermöglicht: Dynamisches (Nach-)Laden und De-Aktivierung von Services Definition von neuen Bindings Konfiguration von einzelnen Services Konfiguration von nicht funktionalen Eigenschaften (z.b. Sicherheit) Konfiguration von impliziten Diensten (z.b. Exception Handling, Persistenz von Daten, transaktionales Verhalten

35 Anpassung von Service Verzögerung von Design- Entscheidungen durch Laufzeitumgebungen <<Laufzeitumgebung>> <<servicehandle>> :aservice <<service>> :aservice Anpassungservice Technische Voraussetzungen: Anwendung von Late Binding Konzepten aus der OO (Polymorphismus, Vererbung) Mechanismen zum Laden von Klassen (class loading, siehe Java) Reflection (Laufzeitanalyse von Klassen) Beispiele: AXIS 2 (siehe Kapitel 4) EJB Container OSGi Container

36 Classloader in Java Java ermöglicht das Nachladen und Instanzieren (hot deployment) von Komponenten durch einen erweiterbaren Klassenlader-Mechanismus: java MainClass Load bootstrap classes Bootstrap Classloader Normaler Class Load Prozess Laufzeit-Archiv rt.jar Load extended classes Extended Classloader Verzeichnis lib / ext Load application classes Application Classloader Classpath Load further classes Falls neue Klassen instanziert New Classloader (z.b. URLClassload) File Server (URL) Folie 36

37 Skalierbarkeit Skalierbarkeit: die Fähigkeit einer Software-Architektur an einer erhöhten Nutzungsrate flexibel angepasst zu werden. Regel: Eine Software-Architektur skaliert gut, falls bei steigender Nutzungsrate der Ressourcenbedarf des Systems linear mit wächst und das Antwortverhalten der Architektur ebenfalls linear bleibt Eine Software-Architektur skaliert schlecht, falls bei steigender Nutzungsrate und bei Zugabe von Ressourcen ab einem gewissen Zeitpunkt keine Antwort mehr liefert (exponentielles Antwortverhalten) Horizontale Skalierung: Hinzufügen oder Replikation von Services in einem bestehenden Hardware-Umgebung Vertikale Skalierung: Hinzufügen von neuer Hardware Folie 37

38 Skalierbarkeit Herausforderungen für SOA Herausforderungen im Bereich SOA: Hohes Datenaufkommen durch komplexe Datenstrukturen (z.b. XML) SOAP: Größe einer Nachricht um Faktor 4-20 größer als Nutzdaten Hoher Aufwand für Serialisierung und Deserialisierung Java: 20% mehr Aufwand als normaler Methodenaufrufe Hohe Laufzeiten von Geschäftsprozessen durch Benutzerinteraktionen Resultierende Anforderungen: Service Konsumenten müssen Ihre Nutzlast explizit machen (z.b. über SLA) Nutzlast muss angemessen sein Geringere Kopplung fördert die Skalierbarkeit Folie 38

39 Wie kann man die Skalierbarkeit erhöhen? <<Service Consumer>> <<ServiceProvider>> <<service>> Buchführung Buchen( ) Kontrollieren( ) Überweisen( ) Szenario: Erhöhung der Anzahl Benutzer (Gesamtzahl der Zugriffe z.b. pro Woche) Erhöhung der parallelen Zugriffe auf den Service pro Sekunde (Durchschnitt, Max) Datenvolumen pro Zugriff erhöht sich, was die Zeit für Abarbeitung deutlich anhebt Folie 39

40 Wie kann man die Skalierbarkeit erhöhen? <<ServiceProvider>> <<Service Consumer>> <<LoadBalancer>> <<service>> Buchführung <<service>> Buchführung <<service>> Buchführung Ansatz 1: Klonen eines Services In einer Laufzeitumgebung (horizontale Skalierung) Über mehrere Server hinweg (vertikale Skalierung) Einführung eines Load Balancers Rule Of Three Servers Effekt: Es können mehrere Transaktionen parallel abgearbeitet werden Folie 40

41 Wie kann man die Skalierbarkeit erhöhen? <<ServiceProvider>> <<Service Consumer>> <<service>> Buchen( ) <<service>> Kontrollieren( ) <<service>> Überweisen( ) Ansatz 2: Fachliche Teilung eines Services Effekt: In einer Laufzeitumgebung (horizontale Skalierung) Über mehrere Server hinweg (vertikale Skalierung) Das Antwortverhalten wird erhöht, was auch auch die Skalierbarkeit verbessert Nicht zwingend eine Verbesserung für parallele Zugriffe Für Workflow-Komponenten weniger geeignet Folie 41

42 Wie kann man die Skalierbarkeit erhöhen? <<Service Consumer>> A - H <<ServiceProvider>> <<service>> Buchführung Buchen( ) Kontrollieren( ) Überweisen( ) <<Service Consumer>> I - Z <<service>> Buchführung Buchen( ) Kontrollieren( ) Überweisen( ) Ansatz 3: Teilung eines Service nach Typen von Service Consumer Effekt: In einer Laufzeitumgebung (horizontale Skalierung) Über mehrere Server hinweg (vertikale Skalierung) Es können mehrere Transaktionen parallel abgearbeitet werden Folie 42

43 Skalierbarkeitswürfel nach Abbott und Fisher In Praxis werden die drei Skalierbarkeitsmethoden vermischt. Darstellung in einem Würfel wie folgt denkbar: Z Optimum (hoch skalierte Architektur Aufteilung nach Service Konsumer Fachliche Aufteilung der Services Y Ursprung (0, 0, 0) Klonen von Services X Folie 43

44 Optimierte Architektur für die Skalierbarkeit <<ServiceProvider>> Y-Achse Split Service Consumer A - H <<service>> Buchen( ) <<service>> Buchen( ) <<service>> Buchen( ) X-Achse Split <<service>> Kontrollieren( ) <<service>> Kontrollieren( ) <<service>> Kontrollieren( ) Service Consumer I - Z <<service>> Buchen( ) <<service>> Buchen( ) <<service>> Buchen( ) X-Achse Split <<service>> Kontrollieren( ) <<service>> Kontrollieren( ) <<service>> Kontrollieren( ) X-Achse Split X-Achse Split <<service>> Überweisen( ) <<service>> Überweisen( ) <<service>> Überweisen( ) X-Achse Split <<service>> Überweisen( ) <<service>> Überweisen( ) <<service>> Überweisen( ) X-Achse Split Z-Achse Split Folie 44

45 Skalierbarkeit Weitere Heuristiken Einführung von schlanken Services mit einer einfachen Schnittstelle und wenigen Abhängigkeiten Vermeidung von Flaschenhälsen, Single Points of Failure Bessere Service-Replikation im Falle von horizontaler Skalierbarkeit Verwendung von einfachen, flexiblen Konnektoren Vermeidung von heterogenen Komponenten Migration von häufig verwendeten Services in die Nähe zu Konsumenten Folie 45

46 Architekturprinzipien nach Abbott und Fisher N+1 Design Design for Rollback Design to be diasbled Design to be monitored Use Mature Technologies Asynchronous Design Stateless Design Horizonal Scale, no vertical Scale Design for at least two axes of scale Buy Commodity Hardware Design for multiple live sites Folie 46

47 Architekturprinzipien nach Abbott und Fisher N+1 Design Design for Rollback Design to be Disabled Design for Rollback Availability Design for multiple live sites Use Mature Technologies Design to be monitored Asynchronous Design Stateless Systems Horizontal Scale Design for at least two axes of scale Buy Commodity Hardware Scalability Cost Folie 47

48 Verfügbarkeit Verfügbarkeit beschreibt Anforderungen bezüglich: Die von Endbenutzern geforderte Online-Zeit Die maximale Offline-Zeit oder die tolerierbare Ausfallrate Maßnahmen im Falle der Nicht-Verfügbarkeit des Systems des Zielsystems. Bereiche: Ausfallerkennung (failure detection): Wie können Ausfälle erkannt werden? Ausfallbehandlung (failure handling): Wie können auftretende Fehler behandelt werden? Ausfallprävention (failure prevention): Wie können Ausfälle vermieden werden? Ausfallbenachrichtigung (failure notification): Wie können Dritt-Services über Ausfälle benachrichtigt werden?

49 Verfügbarkeit - Ausfallerkennung Ping / Echo sendping() [t exceeds] handleexception :service Consumer confirmping( data ) :service Provider Heartbeat register() [t exceeds] handleexception :service Consumer sendheartbeat( data ) :service Provider Falls eine Bestätigung nach einem bestimmten Zeitraum ausbleibt, gilt der Service Provider als ausgefallen (nicht erreichbar)

50 Verfügbarkeit - Ausfallbehandlung Exception Handling :3rdparty Service delegateexception handleexception :service Consumer :service Provider ServiceProvider provider= ; try { supplier.usemethod( );. } catch (UnavailabilityException e) { handleexception( ); } Chain of Responsibility Design Pattern (hier: Delegation von Ausnahmen)

51 Verfügbarkeit Ausfallbehandlung Suche nach alternativen Service nach Ausfall query :service Registry :service Provider1 publish <<service>> :aservice :service Consumer :service Provider2 <<service>> :aservice Zustandsdelegation Backend Nach dem Ausfall eines Service Provider sucht der Service Consumer nach einem Provider, der einen äquivalenten Service anbietet. Realisierung: Konsumentenseitige Suche im globalen Verzeichnis (z.b. UDDI) Indirekt über Enterprise Service Bus Zustandsmanagement Zustandslos: nicht zu beachten Zustandsbehaftet: Eventueller Zustand des alten Service geht verloren Alternative: Delegation Zustand zwischen benachbarten Services oder über Backup

52 Verfügbarkeit Ausfallbehandlung / -prävention Aktive Redundanz :service Provider :service Consumer Bridge :service Provider redundante Services :service Provider Service-Request wird von einem Bridge-Service parallel zu einer Reihe von äquivalenten Services delegiert Service-Antwort wird von allen Komponenten parallel erzeugt und an die Bridge gesendet, erste (oder beste) Antwort wird an Konsument delegiert Vorteil: Alle Services befinden sich im gleichen Zustand (ggf. über gemeinsames Backend) Hohe Verfügbarkeit und hohe Performanz Nachteil: Hoher Ressourcenaufwand

53 Verfügbarkeit Ausfallbehandlung bei nicht redundanten Services compensatefailure( ) :service Consumer :service Provider <<service>> :aservice Bis jetzt: alle Methoden zur Ausfallbehandlung bedingen redundante Services Redundanz kann nicht immer garantiert werden oder ist nicht erwünscht Ausnahmebehandlung von nicht redundanten Services: Interaktion mit Benutzer zur Entscheidungsfindung Kompensation (siehe Lose Kopplung) Temporäre Aufgabe der Funktionalität

54 Performanz Service Policies Performanz: Annahmen bezüglich der Geschwindigkeit einer Operation Effizienz: Erfüllung der Performanz-Anforderungen bei gleichzeitiger minimaler Auslastung der System-Ressourcen Arten von Performanz-Anforderungen: Antwortzeiten (response) (wie schnell reagiert ein Service auf Nutzeranfragen) Durchlaufsatz (throughput) (wieviel kann ein Service in einem festgelegten Zeitraum erreichen) Bereiche: Reduzierung des Berechnungsaufwands Scheduling von Ereignissen Service Policies

55 Performanz Heuristiken Nachrichten werden produziert und werden übergeben :ProvidedService Generierte Antwort in vorgegebenen Zeitfenster Optimierung der Effizienz eines Service Vermeidung von vielen Loops, effizienter Aufbau Zugriff auf Backends nur wenn nötig Verringerung der Zugriffsrate seitens der Konsumenten Verwendung von effizienten caching/queue Strukturen (Scheduling) Vermeidung von Deserialsierung und Serialisierung Verwendung von asynchronen Kommunikations- und Verarbeitungsmethoden Umgehen von höheren Schichten, direkter Zugriff auf niedrigere Schichten Erhöhung der parallelen Prozesse (z.b. Threads, mehr Prozessoren) u.v.a.m.! Quelle: Shirazi, J.: Java Performance Tuning, O Reilly

56 Scheduling von Ereignissen Ein Scheduler verwaltet die Zuordnung von Ereignissen zu Ressourcen. Ressource: CPU, Netzwerk, Methode, Thread, weitere Services Drei wesentliche Bestandteile: (Neu-)Priorisierung von Ereignissen Queueing (Einreihen) von Ereignissen Zuordnung von Ereignissen auf Ressourcen Bekannte Scheduling-Implementierungen, z.b. First-in/First-out (FIFO) Keine Priorisierungen, alle Events werden gleich behandelt Scheduling-Implementierungen mit Prioritäten: Semantische Relevanz (Zuordnung von Priorisierungen anhand fachlicher, inhaltlicher, zeitlicher Relevanz) Deadline Relevanz (Höhere Priorität zu Ereignissen mit kürzerer Deadline) Ablauf Relevanz (Höhere Priorität zu Ereignissen mit kürzeren Durchlaufzeiten) Folie 56

57 Performanz Service Policies Eine Service Policy reguliert die Interaktion zwischen einem Service- Konsumenten und einem Service-Provider durch einen gegenseitigen Vertrag Beispiel SOA: Service Level Agreement (SLA) Verschiedene Aspekte können definiert werden: Verfügbarkeit eines Dienstes Garantierte Antwortzeit und Durchsatz eines Service Nutzungsrate seitens des Service-Konsumenten Anpassungen (z.b. Benachrichtigung vor einer Anpassung) :service Consumer :service Provider Service Policy zwischen Consumer and Provider : Verfügbarkeit: zwischen 10 a.m. and 11 p.m. Performanz: Antwortzeit < 2 sec Durchsatz: 50 parallele Aufrufe / sek Nutzungsrate: max. 30 parallele Aufrufe / min, Input 500kb / Aufruf

58 Literatur Generelle Entwurfsprinzipien: Josuttis, SOA in der Praxis, Performance, Skalierbarkeit, Anpassbarkeit, Sicherheit Bass, Clements, Kazmann: Software Architecture in Practice, SEI Series, 2. Auflage, 2003 Skalierbarkeit, Verfügbarkeit, generelle Entwurfsprinzipien: Abbott, Fisher: The Art of Scalability, Addison-Wesley, 2010 Folie 58

59 Security, Sicherheit Sicherheitsanforderungen definieren Eigenschaften des Systems, um den nicht authorisierten Zugriff auf Software-Systeme durch Dritte zu unterbinden und somit Risiken wie Datenklau, Spionage zu minimieren. Oftmals Anwendung bekannter Ansätze, um eine service-orientierte Architektur sicher zu machen. Wird oft unterschätzt, vernachlässigt (wie so oft) Diskussion in Teams (2-3 Leute, max 5-7 Minuten): wo finden aus Ihrer Security-Aspekte in einer Service-Orientierten Architekturen Anwendung? Folie 59

60 Usability Usability is concerned with how easy it is for the user to accomplish a desired task and the kind of support the system provides to the user Usability is the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of system or component Areas of concerns Runtime aspects (Nielsen s heuristics) Support user during system execution User interface design

61 Usability Principles according to Nielsen Visibility of system status Match between system and the real world User control and freedom Consistency and standards Recognition rather than recall Aesthetic and minimalist design Help users recognize, diagnose, and recover from errors Help and documentation Called Nielsen s heuristics of usability, 1994

62 Usability Principles according to Nielsen Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time For example, pay attention to response time 0.1 sec: no special indicators needed 1.0 sec: user tends to lose track of data 10 sec: max duration if user to stay focused on action for longer delays, use percent-done progress bars searching database for matches

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 2: Einführung in Service-Orientierte Architekturen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

SOA mit.net: Vom Geschäftsprozess zur Lösung

SOA mit.net: Vom Geschäftsprozess zur Lösung SOA mit.net: Vom Geschäftsprozess zur Lösung Manfred Steyer Aktuelles Buch.Net 4.0 Update ISBN 978-3866454439 http://tinyurl.com/net4update 1 Kontakt [www] www.softwarearchitekt.at [mail] Manfred.Steyer@SoftwareArchitekt.at

Mehr

Business Activity Monitoring Overall, Real Time Monitoring Daniel Jobst, TietoEnator Michael Herr, Deutsche Post SOPSOLUTIONS

Business Activity Monitoring Overall, Real Time Monitoring Daniel Jobst, TietoEnator Michael Herr, Deutsche Post SOPSOLUTIONS Business Activity Monitoring Overall, Real Time Monitoring Daniel Jobst, TietoEnator Michael Herr, Deutsche Post SOPSOLUTIONS CITT Expertengespräch TietoEnator 2006 Page 1 Data Freshness and Overall, Real

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 08 Einführung Service-Orientierte Architekturen

Enterprise Applikation Integration und Service-orientierte Architekturen. 08 Einführung Service-Orientierte Architekturen Enterprise Applikation Integration und Service-orientierte Architekturen 08 Einführung Service-Orientierte Architekturen Ist SOA immer noch aktuell? Prof. Dr. Holger Wache http://bhc3.files.wordpress.com/2009/07/gartner-emerging-technologies-hype-cycle-2009.png?w=552&h=451

Mehr

PRODATIS CONSULTING AG. Folie 1

PRODATIS CONSULTING AG. Folie 1 Folie 1 Führend im Gartner Magic Quadranten für verteilte, interagierende SOA Projekte Oracle ist weltweit auf Rang 1 auf dem Markt der Enterprise Service Bus Suiten (ESB) für SOA Software 2010 26,3 %

Mehr

Web Services Monitoring

Web Services Monitoring Web Services Monitoring Foliensatz zum Vortrag von der OIO Hauskonferenz am 17. Dezember 2009 predic8 GmbH Moltkestr. 40 53173 Bonn www.predic8.de info@predic8.de Ihr Sprecher Thomas Bayer Trainer, Berater,

Mehr

Wege zur Integration In und mit der Cloud. Wolfgang Schmidt Vorstand Cloud-EcoSystem. 2014 W.Schmidt, X-INTEGRATE

Wege zur Integration In und mit der Cloud. Wolfgang Schmidt Vorstand Cloud-EcoSystem. 2014 W.Schmidt, X-INTEGRATE Wege zur Integration In und mit der Cloud Wolfgang Schmidt Vorstand Cloud-EcoSystem Wie viele Cloud Integrationstechnologien braucht man? Antworten auf den 150+ Folien Quelle: Forrester Report: How Many

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Eclipse Equinox als Basis für Smart Client Anwendungen Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Übersicht Definition / Architektur Smart Client Smart Client mit RCP / Equinox Gesamtfazit

Mehr

Java 2, Enterprise Edition Einführung und Überblick

Java 2, Enterprise Edition Einführung und Überblick Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

Integration von Web Services in J EE Anwendungen mit XFire. 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire

Integration von Web Services in J EE Anwendungen mit XFire. 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire Integration von Web Services in J EE Anwendungen mit XFire 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire univativ : = Umsetzung durch Studenten und Young Professionals.

Mehr

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa Dr. Stefan Pietschmann, PF Service-Oriented Enterprise Applications, T-Systems MMS Dresden, 22.10.2013 About US PF42 Service-oriented enterprise

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

SaaS-Referenzarchitektur. iico-2013-berlin

SaaS-Referenzarchitektur. iico-2013-berlin SaaS-Referenzarchitektur iico-2013-berlin Referent Ertan Özdil Founder / CEO / Shareholder weclapp die Anforderungen 1.000.000 registrierte User 3.000 gleichzeitig aktive user Höchste Performance Hohe

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Service Oriented Architectures ICA Joh. Kepler Universität Linz Überblick Service-Oriented Architectures (SOAs) Verteilt Basierend auf Standards Lose gekoppelt Protokoll-unabhängig

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

Vortrag im Rahmen des Arbeitskreis i Informatik an der Schule. Prof. Dr. Stefan Sarstedt 04.02.2009

Vortrag im Rahmen des Arbeitskreis i Informatik an der Schule. Prof. Dr. Stefan Sarstedt 04.02.2009 Service-orientierte Architekturen (SOA) Ein Einblick Vortrag im Rahmen des Arbeitskreis i Informatik an der Schule Prof. Dr. Stefan Sarstedt 04.02.2009 Programmieren heute und damals 2009 182910* *************************************TRACE

Mehr

BPEL als Eckpfeiler einer Serviceorientierten Architektur

BPEL als Eckpfeiler einer Serviceorientierten Architektur BPEL als Eckpfeiler einer Serviceorientierten Architektur Stand der Technik und hands-on Demonstration 1. Dez. 2005 Marc Pellmann www.inubit.com inubit AG = Standardsoftware für integrierte Geschäftsprozesse

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

Mehr

WebSphere Portal 8 Migrationen

WebSphere Portal 8 Migrationen WebSphere Portal 8 Migrationen Enrico Regge IT Specialist reggeenr@de.ibm.com André Hagemeier IT Specialist andre.hagemeier@de.ibm.com 2014 IBM Corporation Agenda Suche & Security Theme WCM Applikationen

Mehr

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Zielsetzung: System Verwendung von Cloud-Systemen für das Hosting von online Spielen (IaaS) Reservieren/Buchen von Resources

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform 02 PROFI News

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Service Oriented Architecture & Enterprise Service Bus

Service Oriented Architecture & Enterprise Service Bus Service Oriented Architecture & Enterprise Service Bus 25.05.2005 Sven Stegelmeier 1 Inhalt Einführung in SOA Motivation Begriffsdefinitionen Bestandteile einer SOA Dienste als Bausteine Entwicklungsstadien

Mehr

Titelbild1 ANSYS. Customer Portal LogIn

Titelbild1 ANSYS. Customer Portal LogIn Titelbild1 ANSYS Customer Portal LogIn 1 Neuanmeldung Neuanmeldung: Bitte Not yet a member anklicken Adressen-Check Adressdaten eintragen Customer No. ist hier bereits erforderlich HERE - Button Hier nochmal

Mehr

Enterprise Service Bus

Enterprise Service Bus Enterprise Service Bus Christopher Weiß 25.01.2010 Gliederung 1 Motivation und Einordung Integrationsformen 2 Definition und Eigenschaften Definitionen Eigenschaften 3 Aufbau und Konzepte Aufbau Produkte

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE PROZESSE INTEGRIEREN leicht gemacht DURCH TransConnect Geschäftsprozesse ableiten mit der Universal Worklist (UWL) Integrationsszenarien effektiver verwalten und transportieren Optimierte Personalverwaltung

Mehr

Christoph Mathas. SOA intern. » Praxiswissen zu Service-orientierten IT-Systemen HANSER

Christoph Mathas. SOA intern. » Praxiswissen zu Service-orientierten IT-Systemen HANSER Christoph Mathas SOA intern» Praxiswissen zu Service-orientierten IT-Systemen HANSER Inhalt Vorwort XI 1 Einleitung 1 1.1 Wem nützt dieses Buch? 2 1.2 Weshalb dieses Buch? 3 1.3 Die Kapitelstruktur 4 1.4

Mehr

SOA Service Oriented Architecture

SOA Service Oriented Architecture SOA Service Oriented Architecture (c) Till Hänisch 2006, BA Heidenheim [IBM] [WS] Wir haben: Prog ramm Proxy Proxy K2 K1 Plattformunabhängiger RPC Wir haben: Prog ramm Proxy Proxy K2 K1 Plattformunabhängiger

Mehr

Abbildung 3-1: Clients und Server C+S

Abbildung 3-1: Clients und Server C+S Abbildung 3-1: Clients und Server C+S Abbildung 3-2: Interaktions-koordinations-arten Abbildung 3-3: Zuverlässige Nachrichtenübertragung a) durch individuell quittierte Nachrichten b) durch Quittierung

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

Der SBB Online-Ticketshop Mit SOA zum Erfolg

Der SBB Online-Ticketshop Mit SOA zum Erfolg Der SBB Online-Ticketshop Mit SOA zum Erfolg BAT 03 Stefan Meichtry, Stefan Becker Bern, den 17.03.2006 SBB Informatik 1 Das Ziel SBB Informatik 2 Agenda Problemraum Lösungsraum Analyse Wir sind hier Synthese

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

FH LU JEE Vorlesung SS 2010. Ralf Gitzel ralf_gitzel@hotmail.de

FH LU JEE Vorlesung SS 2010. Ralf Gitzel ralf_gitzel@hotmail.de FH LU JEE Vorlesung SS 2010 Ralf Gitzel ralf_gitzel@hotmail.de 1 Einführung + Organisatorisches Ralf Gitzel ralf_gitzel@hotmail.de 2 Dozent Dr. Ralf Gitzel Promotion an der Universität Mannheim in Wirtschaftsinformatik

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

Java Forum Stuttgart 2008

Java Forum Stuttgart 2008 Professionelle Open Source SOA in 45 Minuten! Java Forum Stuttgart 2008 Dr. Halil-Cem Gürsoy, CDI AG Der Referent Insgesamt ca. 10 Jahre Beratung, davor Forschung Senior Consultant - JEE Evangelist Hauptsächlich

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer Markus Urban.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform

Mehr

Sicherheit in Workflow-Management-Systemen

Sicherheit in Workflow-Management-Systemen Sicherheit in Workflow-Management-Systemen Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation KIT University of the State of Baden-Wuerttemberg and National Research Center of

Mehr

Oliver Zeigermann, Stefan Toth embarc GmbH. Flux Facebooks Beitrag zur UI- Architektur der Zukunft

Oliver Zeigermann, Stefan Toth embarc GmbH. Flux Facebooks Beitrag zur UI- Architektur der Zukunft Oliver Zeigermann, Stefan Toth embarc GmbH Flux Facebooks Beitrag zur UI- Architektur der Zukunft UI-Architektur Warum? User Experience wird wichtiger Rich Client Optionen werden rar Es gibt mehrere Philosophien

Mehr

Die Open Source SOA-Suite SOPERA

Die Open Source SOA-Suite SOPERA Architektur, Komponenten und Realisierung Jörg Gerlach Technische Universität Dresden Fakultät Informatik Institut für Angewandte Informatik Lehrstuhl Technische Informationssysteme 11. Juni 2009 Gliederung

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

OERA OpenEdge Reference Architecture. Mike Fechner PUG Infotag 19. Mai 05 Frankfurt

OERA OpenEdge Reference Architecture. Mike Fechner PUG Infotag 19. Mai 05 Frankfurt OERA OpenEdge Reference Architecture Mike Fechner PUG Infotag 19. Mai 05 Frankfurt Überblick OERA Separated presentation and integration layers Common business logic with advanced models Data access abstracted

Mehr

Architecture Blueprints

Architecture Blueprints Architecture Blueprints Daniel Liebhart, Peter Welkenbach, Perry Pakull, Mischa Kölliker, Michael Könings, Markus Heinisch, Guido Schmutz Ein Leitfaden zur Konstruktion von Softwaresystemen mit Java Spring,.NET,

Mehr

User Interface Guidelines

User Interface Guidelines User Interface Guidelines Von Anna-Lena Goebels und Alexander Fischer Definition Guidelines! eine Sammlung an Empfehlungen nach denen sich Designer und Entwickler von Applikationen speziell für User richten

Mehr

Isabel Arnold CICS Technical Sales Germany Isabel.arnold@de.ibm.com. z/os Explorer. 2014 IBM Corporation

Isabel Arnold CICS Technical Sales Germany Isabel.arnold@de.ibm.com. z/os Explorer. 2014 IBM Corporation Isabel Arnold CICS Technical Sales Germany Isabel.arnold@de.ibm.com z/os Explorer Agenda Introduction and Background Why do you want z/os Explorer? What does z/os Explorer do? z/os Resource Management

Mehr

Clustering von Application Servern am Beispiel von JBoss 3.2

Clustering von Application Servern am Beispiel von JBoss 3.2 Clustering von Application Servern am Beispiel von JBoss 3.2 Cluster Workshop iternum GmbH Alexanderstraße 7 60489 Frankfurt/Main www.iternum.com Agenda Clustertechnik allgemein Was ist Clustering? Gründe

Mehr

Open Source Data Center Virtualisierung mit OpenNebula. 22.05.2013 LinuxTag Berlin. Bernd Erk www.netways.de

Open Source Data Center Virtualisierung mit OpenNebula. 22.05.2013 LinuxTag Berlin. Bernd Erk www.netways.de Open Source Data Center Virtualisierung mit OpenNebula 22.05.2013 LinuxTag Berlin Bernd Erk VORSTELLUNG NETWAYS NETWAYS! Firmengründung 1995! GmbH seit 2001! Open Source seit 1997! 38 Mitarbeiter! Spezialisierung

Mehr

Open Source Data Center Virtualisierung mit OpenNebula. 05.03.2013 CeBIT 2013. Bernd Erk www.netways.de

Open Source Data Center Virtualisierung mit OpenNebula. 05.03.2013 CeBIT 2013. Bernd Erk www.netways.de Open Source Data Center Virtualisierung mit OpenNebula 05.03.2013 CeBIT 2013 Bernd Erk VORSTELLUNG NETWAYS NETWAYS! Firmengründung 1995! GmbH seit 2001! Open Source seit 1997! 35 Mitarbeiter! Spezialisierung

Mehr

Vorstellung Studienprojekt. Policy4TOSCA. Umsetzung eines Policy-Frameworks für sicheres und energieeffizientes Cloud Computing

Vorstellung Studienprojekt. Policy4TOSCA. Umsetzung eines Policy-Frameworks für sicheres und energieeffizientes Cloud Computing Vorstellung Studienprojekt Policy4TOSCA Umsetzung eines Policy-Frameworks für sicheres und energieeffizientes Cloud Computing Institute of Architecture of Application Systems (IAAS) www.iaas.uni-stuttgart.de

Mehr

MatchPoint. Wirtschaftlichkeit von SharePoint Plattformen optimieren

MatchPoint. Wirtschaftlichkeit von SharePoint Plattformen optimieren MatchPoint Wirtschaftlichkeit von SharePoint Plattformen optimieren MatchPoint at a Glance Build Solutions in Less Time Provide a Better User Experience Maintain Your Platform at Lower Cost 2 MatchPoint

Mehr

Anforderungen an Datenbankservices in SOA-basierten Lösungen. Liane Will SAP AG/ Otto-von-Güricke-Universität Magdeburg 6.5.2010

Anforderungen an Datenbankservices in SOA-basierten Lösungen. Liane Will SAP AG/ Otto-von-Güricke-Universität Magdeburg 6.5.2010 Anforderungen an services in SOA-basierten Lösungen Liane Will SAP AG/ Otto-von-Güricke-Universität Magdeburg 6.5.2010 Diplom-Mathematikerin Seit 1997 bei SAP AG Berlin im Active Global Support Best Practices

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Klausur Verteilte Systeme

Klausur Verteilte Systeme Klausur Verteilte Systeme SS 2005 by Prof. Walter Kriha Klausur Verteilte Systeme: SS 2005 by Prof. Walter Kriha Note Bitte ausfüllen (Fill in please): Vorname: Nachname: Matrikelnummer: Studiengang: Table

Mehr

Wiederholung: Beginn

Wiederholung: Beginn B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben

Mehr

Komponentenbasierte Softwareentwicklung

Komponentenbasierte Softwareentwicklung Seminar WS04 Komponentenbasierte Softwareentwicklung Karl Pauls Software-Komponente A software component is a unit of composition with contractually specified interfaces and explicit context dependencies

Mehr

Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de

Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de s & Servlet Integration Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Motivation Das Interface Stateful und Stateless s Programmierung einer Stateful

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Mobile Backend in der

Mobile Backend in der Mobile Backend in der Cloud Azure Mobile Services / Websites / Active Directory / Kontext Auth Back-Office Mobile Users Push Data Website DevOps Social Networks Logic Others TFS online Windows Azure Mobile

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Cloud Computing. Betriebssicherheit von Cloud Umgebungen C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

Cloud Computing. Betriebssicherheit von Cloud Umgebungen C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y Cloud Computing Betriebssicherheit von Cloud Umgebungen Urs Zumstein Leiter Performance Care Team Urs.Zumstein@DevoTeam.ch 079 639 42 58 Agenda Definition von Cloud Services Anforderungen an die Betriebssicherheit

Mehr

OSGi. The Next Generation Java Service Platform. SOA - The Java Way or My classpath is killing me. Michael Greifeneder

OSGi. The Next Generation Java Service Platform. SOA - The Java Way or My classpath is killing me. Michael Greifeneder Michael Greifeneder OSGi The Next Generation Java Service Platform SOA - The Java Way or My classpath is killing me Bilder von Peter Kriens W-JAX Keynote 2007 und Neil Bartletts Getting Started with OSGi

Mehr

JBoss 7 als Plattform für hochverfügbare Anwendungen

JBoss 7 als Plattform für hochverfügbare Anwendungen JBoss 7 als Plattform für hochverfügbare Anwendungen Orientierungspunkt 04/2013 24.05.2013, OIO Dirk Weil, GEDOPLAN GmbH Dirk Weil GEDOPLAN GmbH, Bielefeld Java EE seit 1998 Konzeption und Realisierung

Mehr

Security Technologien in Java EE 6

Security Technologien in Java EE 6 Security Technologien in Java EE 6 Java Forum Stuttgart 2010 Sebastian Glandien Acando GmbH sebastian.glandien@acando.de Agenda I. Einleitung II. Java Authentication SPI for Containers (JSR-196) I. Message

Mehr

Gemeinsam mehr erreichen.

Gemeinsam mehr erreichen. Gemeinsam mehr erreichen. Microservices in der Oracle SOA Suite Baden 10. September 2015 Ihr Ansprechpartner Carsten Wiesbaum Principal Consultant carsten.wiesbaum@esentri.com @CWiesbaum Schwerpunkte:

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren 1 Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren W3L AG info@w3l.de 2011 2 Agenda Softwarearchitektur und Architekturentwurf Definition Überblick

Mehr

Die Eclipse Rich Client Plattform - eine alternative Client-Technologie für Business Process Management Systeme Java Forum Stuttgart, Juli 2006

Die Eclipse Rich Client Plattform - eine alternative Client-Technologie für Business Process Management Systeme Java Forum Stuttgart, Juli 2006 Die Eclipse Rich Client Plattform - eine alternative Client-Technologie für Business Process Management Systeme Java Forum Stuttgart, Juli 2006 Dirk Günther Teammanager R&D e-business d.guenther@cenit.de

Mehr

GridMate The Grid Matlab Extension

GridMate The Grid Matlab Extension GridMate The Grid Matlab Extension Forschungszentrum Karlsruhe, Institute for Data Processing and Electronics T. Jejkal, R. Stotzka, M. Sutter, H. Gemmeke 1 What is the Motivation? Graphical development

Mehr

Integrating Architecture

Integrating Architecture Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Vorstellung und Einführung Ein beliebiger Zeitpunkt in einem beliebigen Unternehmen

Mehr

Aspektorientierte Middleware Florian Wagner

Aspektorientierte Middleware Florian Wagner Anwendungen der Aspektorientierung (5) Übersicht Middleware? Middleware-Concerns Java 2 Enterprise Edition AO Implementierung AOP & JBoss 2 mid dle ware (mĭd'l-wâr') n. Software that serves as an intermediary

Mehr

Web 2.0 Architekturen und Frameworks

Web 2.0 Architekturen und Frameworks Web 2.0 Architekturen und Frameworks codecentric GmbH Mirko Novakovic codecentric GmbH Quality Technische Qualitätssicherung in Software-Projekten mit Fokus auf Performance, Verfügbarkeit und Wartbarkeit

Mehr

Military Air Systems

Military Air Systems Trennung von Applikationen unterschiedlicher Kritikalität in der Luftfahrt durch Software en am Beispiel des Real-time Operating Systems PikeOS Dr. Bert Feldmann DGLR Workshop Garching, 09.10.2007 Seite

Mehr

ServiceGlobe: Flexible and Reliable Web Service Execution

ServiceGlobe: Flexible and Reliable Web Service Execution ServiceGlobe: Flexible and Reliable Web Service Execution Markus Keidl, Stefan Seltzsam und Alfons Kemper Universität Passau Fakultät für Mathematik und Informatik 94030 Passau @db.fmi.uni-passau.de

Mehr

FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN

FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master s Thesis in Wirtschaftsinformatik Anwenderunabhängige Flugdatenschnittstelle basierend auf Web Services am Beispiel der Flughafen München

Mehr

HIR Method & Tools for Fit Gap analysis

HIR Method & Tools for Fit Gap analysis HIR Method & Tools for Fit Gap analysis Based on a Powermax APML example 1 Base for all: The Processes HIR-Method for Template Checks, Fit Gap-Analysis, Change-, Quality- & Risk- Management etc. Main processes

Mehr

HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box?

HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box? HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box? 04. November 2008 ITC GmbH 2008 Agenda Was bringt der HP Service Manager 7? Überblick SM7 Module Neue / zusätzliche

Mehr

Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant

<Insert Picture Here> Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant Oracle Business Process Analysis Suite Gert Schüßler Principal Sales Consultant 1 Geschäftsprozesse Zerlegung am Beispiel Kreditvergabe Antrag aufnehmen Antrag erfassen Schufa Kunden

Mehr

Der Design-Workflow im Software-Entwicklungs-Prozess

Der Design-Workflow im Software-Entwicklungs-Prozess Der -Workflow im Software-Entwicklungs-Prozess Universität Bonn, Vorlesung Softwaretechnologie SS 2000 1 Der -Workflow stellt zum Ende der Elaborations- und Anfang der Konstruktionsphase den Schwerpunkt

Mehr

JONATHAN JONA WISLER WHD.global

JONATHAN JONA WISLER WHD.global JONATHAN WISLER JONATHAN WISLER WHD.global CLOUD IS THE FUTURE By 2014, the personal cloud will replace the personal computer at the center of users' digital lives Gartner CLOUD TYPES SaaS IaaS PaaS

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

Jens Zwer. End-to-End Monitoring für Web-, SOA- und Oracle Applikationen

Jens Zwer. End-to-End Monitoring für Web-, SOA- und Oracle Applikationen Jens Zwer Applications & Systems Management Solutions End-to-End Monitoring für Web-, SOA- und Oracle Applikationen Mai 2010 Kosten Online-Applikation vs. Nutzen & Kundenzufriedenheit? Entwicklung Test

Mehr

Christoph Behounek, eggs unimedia

Christoph Behounek, eggs unimedia Adobe Experience Manager6.1 Planung eines erfolgreichen AEM Upgrades Christoph Behounek, eggs unimedia Adobe Experience Manager Ohne Planung funktioniert es nicht Planung eines erfolgreichen AEM Updates

Mehr

Frontend Migration from JSP to Eclipse Scout

Frontend Migration from JSP to Eclipse Scout Frontend Migration from JSP to Eclipse Scout Peter Nüdling Raiffeisen Schweiz Jérémie Bresson, Peter Barthazy BSI Business Systems Integration AG Eclipse Finance Day, Zürich, 31. Oktober 2014 Seite 1 WebKat:

Mehr

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1 Web Services XML, WSDL, SOAP und UDDI Einblicke und Ausblicke 31.03.2003 J.M.Joller 1 Inhalt Architekturen Main Stream.NET J2EE und Applikations-Server Sicht der Anbieter Java J2EE J2EE versus.net Web

Mehr

RAC auf Sun Cluster 3.0

RAC auf Sun Cluster 3.0 RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung

Mehr

Integration mit Service Repositories zur SOA Governance

Integration mit Service Repositories zur SOA Governance Integration mit Service Repositories zur SOA Governance Nürnberg, 10.11.2009 I N H A L T 1. SOA Governance 2. Service Repository 3. Modelle und Service Repository 4. Modell-Driven SOA I N H A L T 1. SOA

Mehr

SAP NetWeaver Gateway. Connectivity@SNAP 2013

SAP NetWeaver Gateway. Connectivity@SNAP 2013 SAP NetWeaver Gateway Connectivity@SNAP 2013 Neue Wege im Unternehmen Neue Geräte und Usererfahrungen Technische Innovationen in Unternehmen Wachsende Gemeinschaft an Entwicklern Ausdehnung der Geschäftsdaten

Mehr