Devices Profile for Web Services

Präsentation zum Thema: "Devices Profile for Web Services"—  Präsentation transkript:

1 Devices Profile for Web Services
Workshop Oldenburg,

2 DPWS Multi Edition Stack DPWS gSOAP Stack DPWS-AXIS2
Tagesablauf SOA • Web Services DPWS DPWS Explorer DPWS Multi Edition Stack DPWS gSOAP Stack DPWS-AXIS2 OSGi/DPWS-Integration WS4D-Pipes

3 SOA • Web Services

4 Abstraktes Konzept einer Software-Architektur
SOA Was ist SOA? Abstraktes Konzept einer Software-Architektur Dienste anbieten, suchen und nutzen Eigenschaften von Diensten in SOA Wieder verwendbar Offen zugreifbar Plattform- und sprachenunabhängig Lose gekoppelt Unter einer SOA versteht man ein abstraktes Konzept einer Software-Architektur, die vielfältige, verschiedene und eventuell inkompatible Applikationen als wieder verwendbare und offen zugreifbare Dienste repräsentiert und dadurch ihre plattform- und sprachenunabhängige lose gekoppelte Nutzung ermöglicht. Wieder verwendbar: einmal entwickelt kann ein Dienst immer wieder von mehreren Benutzer verwendet werden Offen zugreifbar: ein Dienst wird zur Verfügung gestellt und kann zugegriffen werden Plattform- und sprachenunabhängig: der Dienst wird auf einem Mac-Rechner angeboten, kann aber von einem Windows-Rechner verwendet werden Lose gekoppelt: Dienste werden bei Bedarf dynamisch gesucht, gefunden und angebunden

5 SOA – Infrastruktur Rollen in der SOA Anbieter Nutzer Vermittler
Dienst- vermittler veröffentlichen finden Dienst- anbieter Dienst- nutzer interagieren In der SOA Infrastruktur nehmen 3 Parteien Teil: Dienstanbieter, Dienstnutzer und Dienstvermittler. Ein Dienstanbieter hat einen Dienst anzubieten. Diesen macht er einem Dienstvermittler bekannt. Möchte ein Dienstnutzer den Dienst nutzen (Client), so sucht er nach dem gewünschten Dienst beim Dienstvermittler. Dieser liefert ihm die notwendigen Informationen über den Dienst. Anhand von welchen kann der Client den Service direkt verwenden. Was man noch extra betonen muss, SOA ist nur ein Konzept, das in verschiedenen Technologien eine Verwendung findet. Service Client

6 Umsetzung des SOA-Konzepts Maschine-Maschine Interaktion im Netzwerk
Web Services Was sind Web Services? Umsetzung des SOA-Konzepts Maschine-Maschine Interaktion im Netzwerk Realisierung durch Standards XML SOAP WSDL UDDI Web Services sind eine Umsetzung des SOA-Konzept, die einen Rahmen zur Maschine-Maschine Interaktion im Netzwerk festlegen. Die Realisierung von Web Services basiert auf den gängigen Standards: XML (Extensible Markup Language eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten), SOAP (Simple Object Access Protocol als Kommunikationsprotokoll), WSDL (Web Service Description Language als Beschreibungssprache) und UDDI (Universal Description, Discovery and Integration als standardisiertes Verzeichnisdienst).

7 Web Services – Infrastruktur
Rollen in der Web Services Architektur Anbieter Nutzer Verzeichnis (Vermittler) UDDI Dienst- verzeichnis WSDL WSDL veröffentlichen Verweis auf Dienst SOAP suchen Dienst- anbieter Dienst- nutzer Abfrage der Beschreibung Dass Web Services die SOA umsetzen, sieht man an der Infrastruktur. In dem Prozess nehmen die folgenden Teilnehmer teil: Dienstanbieter, Dienstnutzer und Dienstverzeichnis, das die Rolle des Vermittlers übernimmt. Ein Anbieter, der einen Dienst in Form eines Web Service anbieten möchte, erstellt von diesem zunächst eine WSDL-Schnittstellenbeschreibung in Form eines entsprechenden XML-Dokuments. Dieses s.g. WSDL-Dokument wird veröffentlicht, indem es zu einem UDDI-basierten Verzeichnisdienst transferiert wird (click). Ein Dienstnutzer(click) hat den Wunsch den Diesnt zu benutzen, dafür sucht er den passenden Dienst sucht (click). Laut Spezifikation müssen UDDI-Implementierungen zu diesem Zweck eine SOAP-Schnittstelle zur Verfügung stellen, die vom UUDI-Gremium mittels WSDL-Dokumenten beschrieben ist. Hat der Dienstnutzer einen für sich geeigneten Web Service gefunden, so fordert er die Schnittstellenbeschreibung (das WSDL-Dokument) an. Der Verzeichnisdienst liefert hierzu eine Referenz (URI) auf das WSDL-Dokument (click), das der Dienstnutzer in einem weiteren Schritt anfordert (click). So ist der Client in der Lage, mit dem Service mittels SOAP zu kommunizieren (click). An der Stelle möchte ich auf die für DPWS relevanten Protokolle (SOAP und WSDL) etwas genauer eingehen. Service SOAP Client Nutzung

8 SOAP beschreibt das XML-basierte Nachrichtenformat der Kommunikation
Web Services – SOAP SOAP beschreibt das XML-basierte Nachrichtenformat der Kommunikation und dessen Einbettung in ein Transportprotokoll Aufbau einer SOAP-Nachricht SOAP Envelope, Header, Body Verwendung Datentransport Methodenaufruf (SOAP-RPC) Transportprotokolle HTTP, SMTP, FTP, RMI, … Envelope Header Body Der SOAP Envelope bildet das Wurzel des XML-Dokuments, in ihm sind die anderen beiden Teilen der SOAP-Nachricht gekapselt. Hier wird festgelegt, welche Version der SOAP-Spezifikation in der vorliegenden Nachricht verwendet wird. Zugleich wird der Namensraum des Dokuments festgelegt. Der SOAP Header ist ein optionales Element, der zusätzliche Informationen speichern kann (typisches Anwendungsgebiet ist das Übertragen von Sicherheitsrelevantsinformationen). Eine SOAP-Nachricht muss nicht immer direkt von Sender zum Empfänger übertragen werden. Das Ziel kann auch über mehrere Zwischenstationen erreicht werden. SOAP-Header-Elemente können direkt an solche Zwischenstationen adressiert werden und müssen deshalb von den Zwischenstationen verstanden werden. Der SOAP Body enthält den eigentlichen payload der Nachricht, derer Inhalt anwendungsbezogen ist. Beispielsweise kann der SOAP-Body zur Datenübertragung eingesetzt werden. Des Weiteren ist es möglich, einen Methodenaufruf zu übertragen. Um diesen RPC-Mechanismus umzusetzen, wird in der SOAP-Spezifikation eine besondere Syntax festgelegt. Bei der Kommunikation während eines RPC-Mechanismus kann man drei Arten unterscheiden: Anfrage - Request (Der Anfragender ruft eine Methode des Anbieters auf und übergibt dazu die geforderten Parameter in der richtigen Reihenfolge), Antwort - Response (Die Anfrage konnte fehlerfrei bearbeitet werden und das Ergebnis wird nun vom Anbieter an den Anfragen übergeben) und Fehlerfall (An irgendeiner Stelle ist ein Fehler aufgetreten, den an den Dienstnutzer weitergereicht wird). Bei einer Kommunikation können an beliebiger Stelle in der Kommunikationskette Fehler auftreten. Im Falle eines Fehlers können bzw. müssen in dem SOAP-Body in einem Fault Block fehlerspezifische Daten übertragen werden (Code – Kodierung der Fehlerquelle, Reason – textuelle Beschreibung, Node – wo der Fehler aufgetreten ist, Role, Detail). Die SOAP-Spezifikationen schreibt nicht vor, mit welchem Protokoll die Nachrichten übertragen werden sollen. Die Wahl des Transportprotokolls hängt von den jeweiligen Anwendungen ab (am häufigsten - HTTP). So viel zu SOAP.

9 WSDL ist eine XML-basierte Sprache, um Web-Services-Schnittstellen
Web Services – WSDL WSDL ist eine XML-basierte Sprache, um Web-Services-Schnittstellen zu beschreiben Aufbau eines WSDL-Dokuments Types Interface (portType) Bindings Services description types portType operation input output binding operation Die Web Service Description Language ist eine XML-basierte Sprache, die zur Beschreibung der Web Services Schnittstellen dient. Dabei werden die einzelnen Operationen mit ihren Parametern und Rückgabewerten definiert. Die Hauptelemente eines WSDL-Dokuments sind in der Abbildung dargestellt. Der Types-Abschnitt eines WSDL-Dokuments beinhaltet Definitionen von Datentypen Der Interface (portType)-Teil (eigentliche Schnittstellendefinition) fasst eine Menge von Operationen zusammen. Wobei mit jeder Operation (die einer Interaktion mit einem Service entspricht) sind ein- und ausgehende Nachrichten verbunden (aus der Sicht der Dienstes). Im Abschnitt binding der WSDL-Datei wird festgelegt, welches Protokoll für den Nachrichtenaustausch für jede Operation verwendet wird. Mittels Service-Elementen kann für jedes Interface eines Dienstes eine Menge von Endpoints festgelegt werden, über die der Dienst erreicht werden kann (also physikalisch unterschiedliche Orte, an denen eine Schnittstelle des Dienstes angeboten wird – konkrete Software-Komponte auf einem Rechner, die sich hinter einer bestimmten Netzwerkadresse verbirgt und den Dienst zur Verfügung stellt). service endpoint

10 Keine dynamische Suche von Diensten Keine Ereignisverarbeitung
Web Services – DPWS Problem Keine dynamische Suche von Diensten Keine Ereignisverarbeitung Keine Ressourcen-Optimierung Jetzt ist man an der Stelle gelandet, wo die eigentliche Motivation für DPWS erfolgen soll. Die Web Services Architektur, so elegant und einfach wie sie ist, ist trotzdem nicht für alle Anwendungsfälle ideal. Ein paar Aspekte möchte ich erwähnen. Es ergibt sich keine Möglichkeit nach Diensten dynamisch zu suchen. Damit meine ich, dass das UDDI-Verzeichnis eine zentrale Rolle spielt (Ausfall?). Kein Mechanismus ist für eine standardisierte Ereignisverarbeitung vorgesehen. Ein UPnP-ähnliches-Konzept wäre für diese Punkte notwendig. Darüber hinaus ist die ganze Architektur nicht besonders optimiert für Geräte mit beschränkten Ressourcen. DPWS bietet eine Lösung für diese Probleme.

11 DPWS

12 Devices Profile for Web Services Specification:
DPWS Devices Profile for Web Services Specification: „DPWS defines a minimal set of implementation constraints to enable secure Web service messaging, discovery, description, and eventing on resource-constrained endpoints.“ Fakten Erstveröffentlichung in 2004 Seit 2008 existiert OASIS WS-DD TC Standard von Microsoft, Intel, Nortel, Lexmark, Red Hat, … Integraler Bestandteil von Windows Vista Devices Profile for Web Services definiert eine minimale Menge von Spezifikationen, um sicheren Nachrichtenaustausch, Erkundung, Beschreibung und Ereignissteuerung von Web Services auf Geräten mit beschränkten Ressourcen zu ermöglichen. OASIS (Organization for the Advancement of Structured Information Standards) Web Services Discovery and Web Services Devices Profile Technical Committee

13 DPWS Sriram Rajagopalan, Leiter von Program Management for Windows Device and Storage Technologies in Microsoft: "The formation of the WS-DD Technical Committee is an important milestone and builds upon mature WS-* base protocols by expanding the scope to include the wide variety of devices being used today in homes and enterprises. Defining protocols for discovering, securely consuming and exposing Web services in a lightweight footprint that suits these devices has the potential to greatly broaden the reach of Web services to meet customers' needs."

14 Device (Dienstanbieter) Client (Dienstnutzer)
DPWS – Infrastruktur Terminologie Device (Dienstanbieter) Client (Dienstnutzer) Discovery ersetzt Vermittler Device (Hosting Service) Hosted Services Client Messages Die DPWS Spezifikation verwendet eine etwa andere Notation, deshalb muss man die Terminologie festlegen. Im Gegensatz zur Web Services (bzw. SOA) Architektur sieht DPWS nur zwei Hauptdarsteller vor: Device als Dienstanbieter und Client als Dienstnutzer. Anstatt von UDDI-verzeichnisdienst (Vermittler) hat man den DPWS spezifischen Discovery-Mechnismus. Client ist ein Netzwerk-Endpunkt, der einen Dienst benutzt. Unter Device versteht man einen bestimmten Typ von Service, welcher andere Services hostet, man spricht also von einen Hosting Service. Die von ihm hostenden Services sind bzw. Hosted Services. Messages (Nachrichten) sind Protokollelemente, welche werden über das Netzwerk ausgetauscht, um Web Services zu betätigen (SOAP in Transportprotokollnachricht eingepackt).

15 Protokolle und Spezifikationen SOAP 1.2 HTTP/1.1 WS-Addressing UUID
DPWS – Messaging Protokolle und Spezifikationen SOAP 1.2 HTTP/1.1 WS-Addressing UUID URI UDP MTOM R0029: A SERVICE SHOULD NOT send a SOAP ENVELOPE that has more octets than the MTU over UDP. R0034: A SERVICE MUST at least receive and send SOAP 1.2 SOAP Envelopes. R0004: A DEVICE SHOULD use a urn:uuid scheme URI as the [address] property of its Endpoint Reference. DPWS legt die Anforderungen an den Nachrichtenaustausch zwischen den Client und Service. Als Basis für die Nachrichtenaustausch im Rahmen von DPWS dient die SOAP 1.2. Protokoll, HTTP 1.1 und WS-Addressing (die transportunabhängiger Mechanismus, um Web Services zu adressieren). Die Spezifikation legt auch die Anforderungen an den Nachrichtenaustausch bzgl. der Benutzung von UUID (Universally Unique Identifier), URI (Uniform Resource Identifier), UDP (User Datagram Protocol) und MTOM (Message Transmission Optimization Mechanism). Damit man eine Vorstellung hat, wie die DPWS Spezifikation aussieht, habe ich ein paar Beispiele ausgeschrieben.

16 Resolve Match / unicast
DPWS – Discovery Spezifikation WS-Discovery Nachrichten Hello Bye Probe und Probe Match Resolve und Resolve Match Device Client Hello / multicast Probe / multicast Probe Match / unicast Resolve / multicast Resolve Match / unicast Um Services zu lokalisieren, bietet DPWS die WS-Discovery Spezifikation, welche den Prozess von Erkundung von Services definiert. Wie schon erwähnt, sieht DPWS kein zentrales UDDI-Repository vor, sondern ist der Entdeckungsmechanismus auf selbständiges Beschreiben und dynamisches Entdecken von Services aufgebaut. WS-Discovery legt das Modell des Entdeckungsprozesses fest, d.h. wann welche Nachrichten versendet werden, und wie diese Nachrichten aussehen müssen. Wir betrachten den Prozess anhand eines Beispiels. Wir haben zwei Endpunkte, einer spielt die Rolle von Device, der andere tritt als Client auf. Beim Betreten eines Netzwerks (oder Änderung von Metadaten) sendet der Device eine Hello-Nachricht im Multicast-Modus. Ein Client, falls er nach einem Service suchen möchte, verschickt eine Probe-Nachricht. Dabei kann er nach Bestimmten Servicetypen oder Scopes (log. Gruppen von Services) suchen. Falls der Device der Probe-Nachricht entspricht, so muss er mit einer Probe Match-Nachricht antworten. Analog geht es mit dem Versenden von Resolve-Nachrichten (In diesem Fall handelt es sich um eine Suche nach einem konkreten Namen). Letztendlich, beim Verlassen des Netzwerks versucht der Service eine Bye-Nachricht im Multicast-Modus zu versenden. Ein Client in seiner Reihe lauscht auf die eingehenden Hello- und Bye-Multicast-Nachrichten, kann Probe-Nachrichten versenden, um nach Services zu suchen, oder Resolve-Nachrichten, um nach einem konkreten Service zu suchen. Selbstverständlich darf ein Endpunkt gleichzeitig mehrere Rollen annehmen. Bye / multicast

17 Device-Eigenschaften Manufacturer, ModelName, FriendlyName, …
DPWS – Description <wsdp:Hosted> <wsa:EndpointReference> <wsa:Address> </wsa:Address> </wsa:EndpointReference> <wsdp:Types> img:MakeCappucinoPortType img:MakeEspressoPortType </wsdp:Types> <wsdp:ServiceId> CoffeeService </wsdp:ServiceId> </wsdp:Hosted> Spezifikationen WSDL 1.1 WS-MetadataExchange WS-Policy WS-Transfer Device-Eigenschaften Manufacturer, ModelName, FriendlyName, … Service-Eigenschaften Beschreibung, Zugehörigkeit, Nachrichten, Transport, Security, … <wsdp:ThisDevice> <wsdp:FriendlyName xml:lang=„en-US“> Our New Coffee Maker </wsdp:FriendlyName> <wsdp:FirmwareVersion> CM_v01 </wsdp:FirmwareVersion> <wsdp:SerialNumber> </wsdp:SerialNumber> </wsdp:ThisDevice> Ein weiterer wichtiger Aspekt, der unbedingt betrachtet werden muss, ist die Beschreibung von Diensten in DPWS. In wenigen Fällen liegt einem Client eine wirklich vollständige Information über den für ihn interessanten Device und seinen Hosted services vor. Meistens, braucht ein Client erstmal die Beschreibung (Metadaten) von den Device und seinen HostedServices zu holen. Damit beschäftigt sich der Bereich von Description. Die Spezifikationen, die für den Bereich relevant sind, sind hier aufgelistet. Welche Eigenschaften gehören zur Beschreibung von Web Services? Erstens, devicespezifische Daten (Manufacturer, Modelname, ModelNumber, PresentationsUrl). Zweitens, Service-Eigenschaften (welche HostedSrevices hostet der Device, welche Nachrichten können sie versenden und empfangen (WSDL), mittels WS-Policy wird festgelegt, welche Anforderungen ein HostedService bzgl. Transport und Security hat)

18 Event Source (Hosted Service) Subscription Manager Subscription
DPWS – Eventing Observer Design Pattern Spezifikation WS-Eventing Parteien Event Sink (Client) Event Source (Hosted Service) Subscription Manager Subscription Notifications (Event Messages) zeitliche Dauer Delivery Mode Push Observable Observer HostedSevice Client subscribe() setChanged() notifyObservers() sendEvent(…) Eventing (Subscribe, Unsubscribe) unsubscribe()

19 Transport Layer Security (https)
DPWS – Security Spezifikationen WS-Security Integrität XML Signature Vertraulichkeit XML Encryption Authentifizierung Transport Layer Security (https) Darüber hinaus empfiehlt DPWS eine Grundlinie für die Gewährleistung der Daten- und Funktionssicherheit in der Kommunikation zwischen Device und Client. Zusätzliche oder andere Sicherheitsmechanismen können angewendet werden. Mittels WS-Security definierten Methoden und Protokolle können Anforderungen an den Austausch von Nachrichten (z. B. bezüglich der Integrität, Vertraulichkeit oder Echtheit) gewährleistet werden. Dabei wird die Integrität von Nachrichten z. B. mittels XML Signature sichergestellt, und die Vertraulichkeit mittels XML Encryption. TLS stellt die Authentifizierung von Device und Client bereit und schafft einen Secury Channel über welchen die Nachrichten sicher ausgetauscht werden können. Security (Spezifikation vgl. mit Vista)

20 DPWS Explorer

21 DPWS Explorer Funktionen Discovery Eventing Methodenaufrufe Filter
WSDL-Import Unterstützung bei Fehlersuche Vorstellung mit Übung

22 DPWS Java Multi Edition Stack

23 DPWS Java Multi Edition Stack – Historie
Stack wird entwickelt in Zusammenarbeit von Entwicklung wurde im Herbst 2005 begonnen Open Source seit 2007 Sourceforge: WS4D.org Java Multi Edition DPWS Stack Aktuelle Version: 0.9.5 Website:

24 DPWS Java Multi Edition Stack – Spezifkationen
Implementierung der DPWS-spezifischen Anforderungen von WS-Discovery Erkennung von Geräten im lokalen Netzwerk WS-Eventing Ereignisgesteuerter Nachrichtenaustausch WS-Transfer und WS Metadata Exchange Metadatenaustausch von Entitäten WS-Security SSL-Transportsicherheit MTOM Versand von Binärinformationen

25 DPWS Java Multi Edition Stack – Features Teil 1
Vielseitigkeit durch Unterstützung aller Java-Laufzeitumgebungen Java SE, Java ME (CLDC und CDC) Skalierbarkeit durch Anpassungsfähigkeit Verwendung spezifischer Plattformen und Module Generisches Webinterface PresentationURL

26 DPWS Java Multi Edition Stack – Features Teil 2
Interoperabilität mit anderen DPWS-Implementierungen Vista (WSDAPI), gSOAP, Axis2, Schneider WSDL-Generierung und Interpretation zur Laufzeit On-the-fly Generierung von Proxies zu DPWS-Devices und Services Device (Hosting Service) Hosted Services Client Remote Device ... <wsdl:portType name="HelloWorldService"> <wsdl:operation name="SayHelloWorld"> <wsdl:input ... /> </wsdl:operation> </wsdl:portType> Remote Services

27 DPWS Java Multi Edition Stack – Architektur
Application Core Platform Toolkit (SE, CDC, CLDC) Java Virtual Machine Remote Client SOAP UDP HTTP TCP Plug-ins Attachment PresentationURL DeviceAdmin Discovery Eventing Service Security Aufbau Verschiedene Module Core Optionales Einbinden einzelner Module Plattformen CLDC, CDC, SE Gerätespezifische Wahl

28 DPWS Java Multi Edition Stack – Klassenübersicht
HostingService Device HostedService Service Action Operation Client QualifiedName Port-Typen Parameter Operanden von Actions Device (Hosting Service) Hosted Services Client Remote Device ... <wsdl:portType name="HelloWorldService"> <wsdl:operation name="SayHelloWorld"> <wsdl:input ... /> </wsdl:operation> </wsdl:portType> Remote Action A Action B

29 DPWS Java Multi Edition Stack – Klasse HostingService
Funktion: DPWS Device Konstruktor: public HostingService( QualifiedName deviceType ) Aufgaben: Device-Port-Type setzen Device-Metadaten setzen Client: RemoteDevice public class SampleDevice extends HostingService { public static final String NAMESPACE=" public static final String PORTTYPE="SampleDevice"; public static final QualifiedName QN_PORTTYPE = new QualifiedName( PORTTYPE, NAMESPACE ); public SampleDevice() { super(QN_PORTTYPE); // Metadaten setFriendlyName("de-DE", "Marcus' Device"); setModelName("de-DE", "Model 42"); } ...

30 DPWS Java Multi Edition Stack – Klasse HostedService
Funktion: DPWS Service Konstruktor: public HostedService() Aufgaben: Service-Port-Type definieren Actions erzeugen Actions hinzufügen Client: RemoteService public class HelloWorldService extends HostedService { public static final String NAMESPACE=SampleDevice.NAMESPACE; public static final String PORTTYPE="HelloWorldService"; public static final QualifiedName QN_PORTTYPE= new QualifiedName(PORTTYPE, NAMESPACE); public HelloWorldService() { super(); // -- hello world action -- HelloWorldAction helloWorldAct = new HelloWorldAction(); addAction(helloWorldAct); } ...

31 DPWS Java Multi Edition Stack – Klasse Action
Funktion: DPWS Action / Operation Konstruktor: public Action( String actionName, QualifiedName serviceType, boolean oneway) Aufgaben: Parameter definieren und erzeugen Input/Output-Parameter hinzufügen Eventing: EventedAction Client: RemoteAction public class HelloWorldAction extends Action{ public static final StringACT_HW_NAME= "SayHelloWorld"; public static final StringPARAM_HW_INPUT= "Name"; public static final StringPARAM_HW_OUTPUT= "Greetings"; public HelloWorldAction() { super(ACT_HW_NAME, QN_PORTTYPE, false); Parameter helloWorldInput = new Parameter( PARAM_HW_INPUT, NAMESPACE, ParameterType.PARAMETER_TYPE_STRING); Parameter helloWorldOutput = new Parameter( PARAM_HW_OUTPUT, NAMESPACE, ParameterType.PARAMETER_TYPE_STRING); addInputParameterDefinition( helloWorldInput ); addOutputParameterDefinition( helloWorldOutput ); } ... } Klasse ParameterType enthält primitive Typen Parameter-Typen (XML-Schema): primitive, simple, complex

32 DPWS Java Multi Edition Stack – Methode Action.invoke()
Funktion: Eingehende Remote-Operation-Aufrufe verarbeiten Aufgaben: Input-Parameter holen, Wert auslesen Output-Parameter holen, Wert setzen @Override public void invoke() throws DPWSException { Parameter helloWorldInput = getInputParameter(PARAM_HW_INPUT); Parameter helloWorldOutput = getOutputParameter(PARAM_HW_OUTPUT); String name = helloWorldInput.getValue(); String outputGreetings = "Hello World from Marcus' Service, " +name+ "!"; helloWorldOutput.setValue(outputGreetings); }

33 DPWS Java Multi Edition Stack – Device starten
Aufgaben: Device erzeugen Services erzeugen Services zum HostingService hinzufügen Eventing initialisieren (optional) Device starten public static void main(String[] args) { SampleDevice device = new SampleDevice(); HelloWorldService service = new HelloWorldService(); device.addHostedService(service); device.start(); }

34 DPWS Java Multi Edition Stack – Klasse Client
Funktion: DPWS Client Konstruktor: public Client() Aufgaben: Client erzeugen und starten Suche definieren und starten Device Port Type Service Port Type Scope Device UUID public class HelloWorldClient extends Client { public static void main(String[] args) { HelloWorldClient client = new HelloWorldClient(); client.start(); // Definiere und starte Suche SearchParameter search = new SearchParameter(client); search.addDeviceType(SampleDevice.QN_PORTTYPE); search.addServiceType(HelloWorldService.QN_PORTTYPE); SearchManager.getInstance().searchService(search); } @Override public void onServiceFound( ISearchResult result ){ ...

35 DPWS Java Multi Edition Stack – Such-Callback
Funktion: Ergebnis eigener Suche (Client) Callback-Methoden: onServiceFound(...) onDeviceFound(...) onDeviceProbe(...) Aufgaben: z. B. RemoteAction aufrufen @Override public void onServiceFound( ISearchResult result ){ IRemoteService service = result.getRemoteService(); // RemoteAction aufrufen ... }

36 DPWS Java Multi Edition Stack – Operationsaufruf
Funktion: Aufruf einer Remote-Operation Methodenaufruf: RemoteAction.invoke() @Override public void onServiceFound( ISearchResult result ){ IRemoteService service = result.getRemoteService(); AbstractAction action = service.getAction( HelloWorldService.HelloWorldAction.ACT_HW_NAME, HelloWorldService.QN_PORTTYPE); Parameter input = action.getInputParameter( HelloWorldService.HelloWorldAction.PARAM_HW_INPUT); input.setValue("Marcus' Client"); try { action.invoke(); } catch (DPWSException e) { e.printStackTrace(); } Parameter output = action.getOutputParameter( HelloWorldService.HelloWorldAction.PARAM_HW_OUTPUT); System.out.println(output.getValue()); Aufgaben: Hole Input-Parameter, Wert setzen Hole Output-Parameter, Wert auslesen Lokale Aufrufe auch möglich

37 OSGi/DPWS-Integration
Web-Service-Integration für eingebettete Systeme mittels DPWS-fähiger OSGi-Plattformen

38 OSGi/DPWS-Integration – Symbolik
Bundle mit OSGi Service Physikalisches Gerät mit OSGi Framework (Server/Client) Import von Paketen Verwendung von Empfang/Versand einer DPWS-Nachricht

39 OSGi und Verteilung – Ist-Zustand
OSGi Services können nur innerhalb einer VM interagieren Eine plattformübergreifende Nutzung ist nicht vorgesehen Verteilte Lösungen lassen sich somit nicht realisieren Im Draft RFC 119 wird ein Konzept für eine transparente verteilte Kommunikation spezifiziert X Physical Device: OSGi Framework Physical Device: OSGi Framework Verteilung und OSGi Bundle Bundle Bundle Bundle

40 OSGi und Verteilung – Unsere Anforderungen
Einbettung von OSGi in eine verteilte SOA Verschmelzung von SOA und OSGi Nutzung offener und plattformunabhängiger Standards (Web Services) Einsatz auf ressourcenbeschränkten Geräten Keine Anpassungen der OSGi-Konzepte und -mechanismen Keine Unterscheidung zwischen lokalen und entfernten Services Anbieten von Legacy Services als entfernte Services ohne Anpassung Einsetzbarkeit auf möglichst allen OSGi Frameworks Rückgriff lediglich auf OSGi Standard Services Konzept  Physical Device: OSGi Framework Physical Device: OSGi Framework Bundle Bundle Bundle Bundle

41 OSGi/DPWS-Integration – Adaptergenerierung
Physical Device: OSGi Framework Bundle Repository Default Serialization Custom Serialization Bundle A Adapter Generator DPWS Device A Hosted Service A DPWS Stack Hello-Msg

42 OSGi/DPWS-Integration – Proxy-Generierung
Physical Device: OSGi Framework Bundle Repository Proxy A Remote Service A Default Serialization Custom Serialization Bundle B (Client) Package (Host-Bundle) Interface X Y Proxy Generator DPWS Client DPWS Stack Hello-Msg

43 OSGi/DPWS-Integration – Service-Nutzung (Proxy)
Physical Device: OSGi Framework Default Serialization Custom Serialization Bundle B (Client) Package (Host-Bundle) Proxy A Interface X Remote Service A Interface Y Ausblick DPWS Stack Invocation-Msg

44 OSGi/DPWS-Integration – Service-Nutzung (Adapter)
Physical Device: OSGi Framework Bundle A Default Serialization Custom Serialization DPWS Device A Service A Adapter Generator DPWS Stack Invocation-Msg

45 OSGi/DPWS-Integration – Events (Source)
Physical Device: OSGi Framework Event Admin Default Serialization Event Converter (Event Handler) DPWS Device Event Converter DPWS Service DPWS Stack Subscription-Msg Event-Msg

46 OSGi/DPWS-Integration – Events (Target)
Physical Device: OSGi Framework Event Admin Default Serialization Event Converter (Event Handler) DPWS Device Event Converter DPWS Service DPWS Stack Event-Msg

47 OSGi/DPWS-Integration – Herausforderungen
Unter welchen Interfaces wird ein Proxy registriert? Wie werden Properties eines Service übertragen? Wie wird die Vererbungshierarchie der Java-Interfaces rekonstruiert? Wie werden Methoden den Java-Interfaces zugeordnet? Welche lokalen Services/Bundles sollen entfernt zugreifbar sein? Welche entfernten Services/Bundles sollen lokal eingebunden werden? Kann die entfernte Service-Nutzung gesichert erfolgen?

48 OSGi/DPWS-Integration – Zusatz-Services
Zusätzliche Attribute eines DPWS-Service geben an, unter welchen Interfaces ein Service registriert wird Je nach Bedarf werden DPWS-Zusatz-Services für ein Bundle-Device verfügbar gemacht: OSGi-Zusatz-Service: Überträgt die Eigenschaften eines Service (Properties) Java-Zusatz-Service: Liefert Informationen über die Interface-Vererbungshierarchie und die Zuordnung der Methoden zu den Interfaces

49 OSGi/DPWS-Integration – Filter
Der Proxy- und Adapter-Generator sind (im Sinne von OSGi) managebar Adapter-Generator: White List über die Services, die entfernt zugreifbar sein sollen (BUNDLE-SYMBOLIC_NAME, INTERFACE_NAME) White List über die zu sicherenden Services (BUNDLE-SYMBOLIC_NAME, INTERFACE_NAME) Proxy-Generator: White List über die einzubindenden Services (FRAMEWORK-ID, BUNDLE-SYMBOLIC_NAME, SERVICE_IMPL)

50 OSGi/DPWS-Integration – Beispielszenario
(max, min) Setze Schwellenwerte ALARM Starte Videokonferenz Klinik (Supervisor) Home Gateway Ergometer (Überwachtes Training)

51 OSGi/DPWS-Integration – Beispielszenario (schematisch)
Videostream Klinik Home Gateway Sensor OSGi Framework Video Konferenz Proxy EKG Proxy EKG Monitoring Video Konferenz EKG Proxy EKG OSGi Framework OSGi Framework DPWS ALARM ALARM

52 OSGi/DPWS-Integration – Offene Punkte
Unterstützung von REQUIRE-BUNDLE Berücksichtigung der OSGi-Security-Mechanismen Evaluierung und Abgrenzung zu: Distributed OSGi R-OSGi Nyota Tests in praxisnahen Szenarien Definition komplexer Datentypen für das Java Collection Framework Mapping eines nativen DPWS-Service auf seinen Proxy (Interface-Name, Registrierung, Properties, …)