Ein generischer Webservice wird auch als Dienst bezeichnet. Diese beiden Begriffe werden in dieser Dokumentation gleichwertig verwendet.

Bei der Bearbeitung finden alle Änderungen direkt auf der Datenbank statt, d.h. alle Änderungen werden sofort gespeichert. Ein Speichern nach der Bearbeitung ist deshalb nicht erforderlich, und der Speichern-Knopf bleibt deaktiviert.

Um einen neuen generischen Webservice anzulegen, wählen Sie den Befehl Neu→Dienst.

Die Angaben Name, Titel, Name im Repository und Namensraum müssen bestückt werden. Für den Namensraum (Namespace) sind nur Werte zugelassen, die in der Datenbank definiert sind; diese werden in einer Combobox zur Auswahl gestellt.

Name und Name im Repository müssen jeweils eindeutig sein: Name ist der externe Name, unter dem der Dienst in Wsdl/Xsd angesprochen wird, Name im Repository der Name, unter dem der Dienst im Repository (Rochade) angelegt wird. Da für den Namen im Repository spezielle Regeln gelten (z.B. Großschreibung), können die beiden Namen abweichen.

Diese Angaben sind - mit Ausnahme des Titels - nach der Neuanlage nicht mehr änderbar.

Bei der Neuanlage wird der Dienst sowohl im Repository als auch in der PublEdge-Datenbank angelegt. Im Repository wird der Dienst der aktuell im Logon-Server eingestellten Anwendung zugeordnet.

Anschließend müssen Sie mindestens folgende Bestandteile definieren:

• Kommunikation: Nachrichten, i.d.R. mindestens jeweils eine Nachricht für Anfrage (Request), Antwort (Response) und Fehler, sowie deren Struktur.
• Bindings: Ein Binding und den Namen der dafür verwendeten Schnittstelle, und danach
• Schnittstelle: Zu der (oder den) Schnittstelle(n) jeweils eine Methode und deren Methodenkommunikation.

Um einen generischen Webservice zu löschen, wählen Sie den Befehl Bearbeiten→Löschen im Hauptmenü oder im Kontextmenü des Dienstes

Der Dienst wird sowohl aus dem Repository als auch aus der Datenbank gelöscht.

Alle bereits in der Datenbank gespeicherten Dienste können über den Öffnen-Dialog von PublEdge zur Auswahl angezeigt werden. Dienste, die als WSDL vorliegen, aber noch nicht in der Datenbank enthalten sind, können über die Import-Funktionalität angelegt werden.

Wenn Sie einen Dienst zur Bearbeitung öffnen, und dieser Dienst zwar in der Datenbank, aber nicht im Repository bekannt ist, wird beim Öffnen gefragt, ob Sie ihn im Repository anlegen möchten. Wenn Sie mit Nein antworten, wird kein Dokument angelegt, und der Dienst wird schreibgeschützt geöffnet.

Der erste Reiter, der für einen Dienst angezeigt wird, enthält Informationen, die im Repository gespeichert sind. Deshalb müssen hier vorgenommene Änderungen - z.B. am Kommentar - auch explizit gespeichert werden (der Speicherkopf ist nach Änderungen hier aktiviert).

Der Reiter „Definition“ zeigt an, welche Nachrichten in dem Dienst bekannt sind und wie sie verwendet werden. Er enthält die Reiter Kommunikation, Schnittstellen und Bindings.

Hier werden die für den Dienst definierten Nachrichten ¹⁾ dargestellt.

Wenn Sie in der Liste „Nachrichten“ einen Eintrag auswählen, werden in der Liste „Nachrichtenstruktur“ die Bestandteile der Nachricht ²⁾ angezeigt.

Sie können in der linken Liste Nachrichten entfernen und hinzufügen (Kontextmenü). Eine neu hinzugefügte Nachricht wird direkt in der Liste selektiert und in Bearbeitungsmodus versetzt, sodass direkt der Name für die neue Nachricht angepasst werden kann:

Um den Namen einer Nachricht nachträglich anzupassen, selektieren Sie die Zeile und aktivieren Sie die Bearbeitung des Felds mit F2 oder über das Kontextmenü.

Unter Nachrichtenstruktur wird der Inhalt der Nachricht festgelegt. Hier können Sie zu der jeweils selektierten Nachricht Bestandteile entfernen und hinzufügen (Kontextmenü).

Die Bearbeitung der Struktur einer Nachricht entspricht im Wesentlichen der Bearbeitung der Struktur eines komplexen Typs, mit folgenden Zusätzen und Einschränkungen:

• Element: Name des Elements.³⁾ Wenn das Verwendungsmuster Bindings"document/literal wrapped" eingehalten werden soll, muss hier ein Name angegeben werden, der der Operation entspricht, in der die Nachricht verwendet werden soll (für Anfrage: Name der Operation, für Antwort: Name der Operation + „Response“).
• Inline:: Nur ankreuzbar für Elemente, für die auch ein Elementname angegeben ist.

Ein Dienst hat einen oder mehrere Schnittstellen. Jede Schnittstelle definiert eine oder mehrere Operationen.

Schnittstellen werden gemeinsam mit den Operationen definiert, die sie enthalten soll:

• Um eine neue Schnittstelle anzulegen, fügen sie eine Operation hinzu und geben in dem Dialog den Namen einer neuen Schnittstelle an.
• Wenn Sie die letzte Operation zu einer Schnittstelle löschen, wird die betreffende Schnittstelle ebenfalls entfernt.

In der Liste Operationen können Sie

• neue Operationen anlegen und diese einer bestehenden oder neuen Schnittstelle zuordnen,
• oder bestehende Operationen löschen (Kontextmenu).
  

Standard-Gruppierung in dieser Liste ist nach der Schnittstelle, d.h. die Operationen werden gruppiert unter der Schnittstelle, zu der sie gehören. Der Aufbau der Liste ist allerdings anpassbar.

Die Liste enthält eine Spalte „Solicit-Response“, die standardmäßig ausgeblendet ist; die dazugehörige Funktionalität ist noch nicht implementiert.
Request-Response: Der Client sendet eine Anfrage und der Server gibt eine Antwort zurück.
Solicit-Response: Der Server sendet eine Anfrage und der Client gibt eine Antwort zurück.

Beim Hinzufügen einer Operation wird in einem Dialog der Name der Operation und die Schnittstelle abgefragt, zu der die Operation gehören soll. Sie können hier auch den Namen einer neuen Schnittstelle angeben. Der Name der Operation sollte innerhalb der Schnittstelle eindeutig sein.

Wenn Sie die letzte Operation zu einer Schnittstelle löschen, wird die betreffende Schnittstelle ebenfalls entfernt.

Zusätzlich kann zu jeder Operation eine Soap-Aktion angegeben werden⁴⁾. Für Webservices mit einer TAA-Verknüpfung muss die Option „Soap-Aktion automatisch bestücken“ aktiviert werden.

In der Liste Nachrichten wird für jede Operation die Kommunikation festgelegt, indem für die Verwendungen Anfrage, Antwort und Fehler eine der Nachrichten ausgewählt wird, die im Reiter Kommunikation angelegt wurden. Für die Nutzung Fehler können mehrere Nachrichten zugeordnet werden.

Wenn das Verwendungsmuster "document/literal wrapped" eingehalten werden soll, darf jede Nachricht (ausgenommen: Fehlernachrichten) nur ein Mal verwendet werden.

Zusätzlich können pro verwendeter Nachricht angegeben werden:

• Bindungsname (vgl. Bindings): Bei Anfrage und Antwort optional, bei Fehler muss ein Bindungsname angegeben werden.⁵⁾
• Aktion: Auszuführende Aktion ⁶⁾
• Aktionsnamespace: Die Namespace kann aus den in der Datenbank definierten Namespaces ausgewählt werden. Die Angabe entscheidet über den Prefix für die Aktion im Schema.

Dieser Reiter stellt die Bindings dar, die im Schema (Subschema „Binding“) definiert sind. Sie können diese hier auch bearbeiten bzw. Bindings hinzufügen oder entfernen.

Verwendungsmodell ist einer von vier möglichen „Wsdl Styles“; für weitere Informationen dazu vgl. den angegebenen Link.⁷⁾

Wenn als Verwendungsmuster Doc/Literal ausgewählt ist, können Sie über die Checkbox Verwendungsmuster 'document/literal wrapped überwachen' erreichen, dass bei der Definition der Nachrichten die Einhaltung dieses Verwendungsmusters überprüft wird. Wo dies nicht der Fall ist, wird ein Warnsymbol angezeigt und im Tooltip ein Hinweis gegeben, welche Änderung erforderlich ist, um die Vorgaben einzuhalten.

Binding-Angaben

• Name ist der Name, unter dem das Binding im Schema aufgenommen wird.
• Als Binding-Typ werden zur Zeit nur Soap, Soap12 und Http unterstützt. Abhängig vom Bindingtyp werden die Präfixe für die Binding-Informationen im Schema erzeugt.
• Die angebundene Schnittstelle ist der Verweis auf die entsprechende Definition im Reiter Schnittstellen ⁸⁾.
• In der Spalte Transport kann für den Binding-Typ „Soap“ oder „Soap12“ ein Inhalt für das Attribut transport angegeben werden⁹⁾
• In der Spalte HTTP-Verb kann für den Binding-Typ „Http“ angegeben werden, ob die GET- oder die POST-Methode genutzt werden soll; der Default ist GET.¹⁰⁾

Zu jedem Binding können mehrere Ports definiert werden. Die Namen der Ports müssen innerhalb des jeweiligen Bindings eindeutig sein. Jeder Port beschreibt eine Möglichkeit, den Dienst aufzurufen, unter Verwendung der in der Spalte Adresse angegebenen URL.

Zu jedem Port wird ein port-Element zu dem Binding im Schema erzeugt, wobei die in der Liste Argumente angegebenen Werte als Zusatzinfo zur Adresse erzeugt werden ¹¹⁾.

Argumente zu einem Port können nur hinzugefügt werden, wenn eine Port-Adresse angegeben ist. Wenn die Adresse zu einem Port entfernt wird, werden auch ggf. bereits definierte Argumente entfernt.

☞ Dienst mit einem existenden TAA-Modul verknüpfen

Hier wird die Wsdl angezeigt, so wie sie für den Webservice erzeugt werden würde, unterteilt nach Binding und Service. Diese Anzeige wird bei jeder Änderung aktualisiert.

Hinweise:
In den hier angezeigten Schemas wird für den Verweis auf Elemente als schemaLocation examplePath angezeigt. Dies wird nur für die hier angezeigte Preview des Schemas so erzeugt. Es ersetzt die „echten“ Pfadangaben auf XSD-Dokumente, die beim Verweis auf andere WebDatentypen zum Zeitpunkt der Preview-Erzeugung nicht zur Verfügung stehen.

Ein Schema kann Angaben enthalten, die in PublEdge nicht angezeigt werden. Dies trifft hauptsächlich auf Schemas zu, die für die Nutzung ohne PublEdge/ExpEdge erfasst wurden. Angaben, die von PublEdge oder ExpEdge nicht verwendet werden, werden zwar nicht angezeigt und können nicht bearbeitet werden, bleiben aber im Schema erhalten.