Eine SQL Anywhere-Datenbank kann Webdienste bereitstellen und mit ihnen arbeiten. Das können über das Internet verfügbare Standard-Webdienste oder von SQL Anywhere-Datenbanken gelieferte Webdienste sein, solange nur der Webdienst sich nicht in derselben Datenbank wie die Clientprozedur bzw. -funktion befindet.

SQL Anywhere kann sowohl als HTTP- als auch als SOAP-Webdienstclient agieren. Diese Funktionalität wird durch gespeicherte Funtionen und gespeicherte Prozeduren erreicht.

Clientfunktionen und -prozeduren werden unter Verwendung der folgenden SQL-Anweisungen erstellt und verarbeitet:

• CREATE FUNCTION-Anweisung (Webdienste)
• CREATE PROCEDURE-Anweisung (Webdienste)
• ALTER FUNCTION-Anweisung
• ALTER PROCEDURE-Anweisung
• DROP FUNCTION-Anweisung
• DROP PROCEDURE-Anweisung

Die Syntax der CREATE FUNCTION- und CREATE PROCEDURE-Anweisungen zur Erstellung von Webdienstclientfunktionen sieht z.B. folgendermaßen aus:

CREATE FUNCTION [ Eigentümer.]Prozedurname ( [ Parameter, ... ] )
RETURNS Datentyp
URL URL_Zeichenfolge
[ Prozedurattribute ]

CREATE PROCEDURE [ Eigentümer.]Prozedurname ( [ Parameter, … ] )
URL URL-Zeichenfolge
[ Prozedurattribute ]

Der Schlüssel zu dieser Syntax ist die URL-Klausel, die verwendet wird, um den URL des Webdiensts zu liefern, auf den die Prozedur zugreifen soll. Die grundlegende Syntax die URL-Klausel lautet wie folgt:

URL-Zeichenfolge :
'{ HTTP | HTTPS | HTTPS_FIPS }://[Benutzer:Kennwort@]Hostname[:Port][/Pfad]'

Die optionalen Benutzer- und Kennwortinformationen ermöglichen es Ihnen, auf Webdienste zuzugreifen, die eine Authentifizierung erfordern. Der Hostname kann der Name oder die IP-Adresse des Computers sein, der den Webdienst verfügbar macht.

Die Portnummer ist nur erforderlich, wenn der Server eine andere als die Standard-Portnummer abhört. Die Standard-Portnummern sind 80 für HTTP-Dienste und 443 für HTTPS-Dienste.

Der Pfad identifiziert die Ressource oder den Webdienst auf dem Server.

Eine Anforderung kann an jeden Webdienst gesendet werden, ob er von einer anderen SQL Anywhere-Datenbank geliefert wird oder über das Internet verfügbar ist. Wenn der Webdienst vom Datenbankserver bereitgestellt wird, darf er nicht in derselben Datenbank wie die Clientfunktion liegen. Der Versuch, auf einen Webdienst in derselben Datenbank zuzugreifen, führt zum Fehler "403 Antwort verweigert".

Weil sie für die Parameterersetzung verwendet werden, müssen Rufzeichen, die in Zeichenfolgen in der Prozedurdefinition auftreten, mit Escapezeichen versehen werden. Weitere Hinweise finden Sie unter Das !-Zeichen mit Escapezeichen versehen Zeichen.

Häufige Klauseln

Die zusätzlichen Klauseln, mit denen Sie detailliertere Informationen über den Prozeduraufruf liefern können, sind folgende:

Prozedurattribute :
[ TYPE { 'HTTP[ :{ GET | POST[:MIME-Typ] | PUT[:MIME-Typ] | DELETE | HEAD } ]' |
                                   'SOAP[:{ RPC | DOC } ]' } ]
[ NAMESPACE Namespace-Zeichenfolge ]
[ CERTIFICATE Zertifikat-Zeichenfoleg ]
[ CLIENTPORT Clientport-Zeichenfolge ]
[ PROXY Proxy-Zeichenfolge ][ SET Protokolloption-Zeichenfolge ]

Die TYPE-Klausel ist wichtig, weil sie SQL Anywhere mitteilt, wie die Anforderung an den Webdienstprovider formatiert werden soll. Die Standard-SOAP-Typen RPC und DOC sind verfügbar. Die Standard-HTTP-Methoden GET und POST sind verfügbar und werden als HTTP:GET bzw. HTTP:POST angegeben. Die Angabe von HTTP impliziert HTTP:POST.

Wenn der Typ SOAP ausgewählt ist, formatiert SQL Anywhere die Anforderung automatisch als XML-Dokument im für SOAP-Anforderungen erforderlichen Standardformat. Da eine SOAP-Anforderung immer ein XML-Dokument ist, wird immer implizit eine HTTP POST-Anforderung verwendet, um das SOAP-Anforderungsdokument an den Server zu senden, wenn der Typ SOAP ausgewählt ist. Die Angabe von SOAP impliziert SOAP:RPC.

Namen für Webdienstclientfunktionen und -prozeduren

Der Prozedurname wird als SOAP-Vorgangsname verwendet, wenn die ausgehende SOAP-Anforderung erstellt wird. Zusätzlich treten Namen von Parametern in Markierungsnamen im SOAP-Anforderungsrahmen auf. Da der SOAP-Server erwartet, diese Namen zu erhalten, ist ihre korrekte Angabe ein wichtiger Teil einer gespeicherten SOAP-Prozedur. Dieser Umstand legt den Namen von SOAP-Prozeduren und -Funktionen Beschränkungen auf, die weiter als die allgemeinen Regeln gehen, die für Prozedur- und Funktionsnamen in SQL Anywhere gelten.

Die folgende Anweisung erstellt eine gespeicherte SOAP-Prozedur namens MyOperation.

CREATE PROCEDURE MyOperation ( a INTEGER, b CHAR(128) )
URL 'HTTP://localhost'
TYPE 'SOAP:DOC';

Wenn diese Prozedur aufgerufen wird, z.B. durch die folgende Anweisung, wird eine SOAP-Anforderung generiert:

CALL MyOperation( 123, 'abc' );

Der Prozedurname erscheint im <m:MyOperation>-Tag im Anforderungshauptteil. Die zwei Parameter a und b werden zu <m:a> bzw. zu <m:b>.

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:m="http://localhost">
  <SOAP-ENV:Body>
    <m:MyOperation>
      <m:a>123</m:a>
      <m:b>abc</m:b>
    </m:MyOperation>
  </SOAP-ENV:Body>
 </SOAP-ENV:Envelope>

Namespace-URIs

Alle SOAP-Anforderungen erfordern eine Methoden-Namespace-URI. Der SOAP-Prozessor auf dem Server verwendet diese URI, um die Namen der verschiedenen Entitäten im Nachrichtenhauptteil der Anforderung zu interpretieren.

Wenn Sie eine SOAP-Funktion oder -Prozedur (SOAP:DOC bzw. SOAP:RPC) erstellen, werden Sie möglicherweise aufgefordert, eine Namespace-URI anzugeben, damit der Aufruf erfolgreich ist. Sie können den erforderlichen Namespace-Wert dem WSDL-Beschreibungsdokument oder anderen verfügbaren Dokumentationen für den Dienst entnehmen. Die NAMESPACE-Klausel gilt nur für SOAP-Funktionen und -Prozeduren. Der Standard-Namespace-Wert ist die URI der Prozedur, bis zur aber nicht einschließlich der optionalen Pfad-Komponente.

HTTPS-Anforderungen

Damit eine sichere HTTPS-Anforderung ausgegeben werden kann, muss der Client Zugriff auf das Zertifikat des Servers oder auf das Zertifikat haben, das zur Unterzeichnung des Serverzertifikats verwendet wurde. Dieses Zertifikat teilt SQL Anywhere mit, wie die Anforderung zu verschlüsseln ist. Zertifikatwerte sind ebenfalls erforderlich, wenn eine an einen unsicheren Server gerichtete Anforderung an einen sicheren Server umgeleitet werden kann.

Es gibt zwei Möglichkeiten, die Zertifikatinformationen zu liefern. Sie können entweder das Zertifikat in eine Datei platzieren und den Dateinamen angeben, oder Sie stellen das gesamte Zertifikat als Zeichenfolgewert bereit. Es kann jeweils nur eine der beiden Möglichkeiten gewählt werden.

Die Zertifikatattribute werden als ein Zeichenfolgewert geliefert, der aus durch Semikolons getrennten Schlüssel=Wert-Paaren gebildet wird:

Zertifikat_Zeichenfolge :
{ file=Dateiname | certificate=Zeichenfolge } ; company=Organisation ; unit=Organisationseinheit ; name= allgemeiner_Name

Folgende Schlüssel sind verfügbar:

Beispiel: Die folgende Anweisung erstellt eine Prozedur, die eine sichere Anforderung an einen Webdienst stellt, der sich auf demselben Computer wie der Client befindet:

CREATE PROCEDURE test()
URL 'HTTPS://localhost/myservice'
CERTIFICATE 'file=C:\srv_cert.id;co=iAnywhere;
             unit=SA;name=JohnSmith';

Da keine TYPE-Klausel geliefert wurde, wird angenommen, dass die Anforderung vom Typ SOAP:RPC ist. Das öffentliche Zertifikat des Servers befindet sich in der Datei C:\srv_cert.id.

Clientports

Wenn Sie auf Webdienste über eine Firewall zugreifen, ist es manchmal notwendig, SQL Anywhere mitzuteilen, welche Ports beim Öffnen einer Verbindung zum Server verwendet werden sollen. Üblicherweise werden Portnummern dynamisch bezogen und Sie sollten sich auf das Standardverhalten verlassen, außer Ihre Firewall beschränkt den Zugriff auf einen bestimmten Portbereich.

Die ClientPort-Option bestimmt die Portnummer, mit der die Clientanwendung über TCP/IP kommuniziert. Sie können eine einzelne Portnummer, eine Kombination einzelner Portnummern oder Bereiche von Portnummern angeben, wie im folgenden Beispiel gezeigt:

CREATE PROCEDURE test ()
URL 'HTTPS://localhost/myservice'
CLIENTPORT '5040,5050-5060,5070';

Es empfiehlt sich, eine Liste bzw. einen Bereich von Portnummern anzugeben. Wenn Sie nur eine Portnummer angeben, wird jeweils nur eine Verbindung aufrechterhalten. Sogar wenn Sie die eine Verbindung schließen, gibt es eine Zeitüberschreitungsperiode von mehreren Minuten, während der keine neue Verbindung zu demselben entfernten Server und Port hergestellt werden kann. Wenn Sie eine Liste bzw. einen Bereich von Portnummern verwenden, sucht die Anwendung solange nach Portnummern, bis sie einen Port gefunden hat, mit dem Sie erfolgreich eine Verbindung herstellen kann.

Diese Funktion ähnelt der ClientPort-Netzwerkprotokolloption. Weitere Hinweise finden Sie unter ClientPort-Protokolloption [CPORT].

Proxies verwenden

Manche Webdienstanforderungen müssen möglicherweise über einen Proxy-Server gemacht werden. Wenn das der Fall ist, muss die URL des Proxy-Servers unter Verwendung der PROXY-Klausel geliefert werden.

Das Format des Werts ist dasselbe wie für die URL-Klausel, nur werden etwaige Benutzer-, Kennwort- und Pfadwerte ignoriert:

Proxy_Zeichenfolge :
'{ HTTP | HTTPS }://[ Benutzer:Kennwort@ ]Hostname[ :Port ][ /Pfad ]'

Wenn ein Proxy-Server angegeben wird, formatiert SQL Anywhere die Anforderung und sendet sie unter Verwendung des gelieferten Proxy-URLs an den Proxy-Server. Der Proxy-Server leitet die Anforderung an ihr Ziel weiter, empfängt die Antwort und leitet die Antwort an SQL Anywhere weiter.

Webdienst-Clientprozeduren protokollieren

Informationen von Webdienst-Clients, einschließlich HTTP-Anforderungen und Transportdaten, können in der Webdienst-Client-Logdatei protokolliert werden. Sie aktivieren die Protokollierung in dieser Datei, indem Sie den Datenbankserver mit der Serveroption -zoc starten oder die Servereigenschaft WebClientLogging mit der Systemprozedur sa_server_option aktivieren. Weitere Hinweise finden Sie unter Serveroption -zoc und sa_server_option-Systemprozedur.