Domino Webservices: Was ist das?

[flaite]

Hi,

wichtiger Hinweis: Ich bemühe mich, verständlich zu bleiben. Nur ist es schwierig jedes Detail von Operationen wo ich nicht selber immer ganz genau weiss was ich da gerade tue haarfein zu erklären. Sollte Interesse bestehen und Unklarheiten auftauchen, bitte eine Frage posten.

thx Axel

nachdem ich nun erfolgreich eine Version von Domino 7 installiert habe, versuche ich mich an Domino Webservices.
Hier ist z.B. ein ganz sinnvoll aussehendes Tutorial:
http://www-128.ibm.com/developerworks/edu/i-dw-ls-domino7ws-i.html
(die IBM ID erhält man, indem man sich registriert, keine Kosten, keine Probleme).

1. Wofür gibt es Webservices?
Was mir zunächst auffällt ist, dass die Einführungssektion "What are Webservices" ein paar Lücken hat.
Man findet Sätze wie

The basic components of Web services are based on a series of technology standards.

Hier ein Versuch einer ein bischen allgemeinverständlicheren Definition:
Die Idee hinter Webservices besteht darin, dass man verschiedenste Internetprotokolle und Standards für den Austausch von Daten zwischen Computern verwendet.
Die traditionelle Interaktion mit dem Internet sieht so aus:
Ein Mensch bedient einen Browser und kommuniziert damit mit einem Programm auf einem Webserver.
Die Idee hinter Webservices ist, dass sich Programme austauschen können. Und zwar Programme unterschiedlichster Plattformen. Ich versuche z.B. jetzt mit einem Java1.5 Programm auf einen Domino-Webservice zuzugreifen. Python, Perl, Objective C, Assembler, C++, C#, Ruby, Ruby on Rails uvam ginge aber auch.

Webservice ist also wieder so eine weitere Integrationsgeschichte wie z.B. COM/OLE. Irgendwie vergleichbar auch mit Remote Procedure Calls (RPC) über die z.B. der Domino Client mit dem Domino Server interagiert.
Hier liegt vielleicht auch ein psychologische Verständnishürde. Bei Web denkt man unwillkürlich an Frontend/User Interface Technlogien wie html, css oder dhtml. Webservices ist aber eine Backendtechnologie für Systemintegration.
Webservices ist so etwas wie COM. Nur wird die ausgetauschte Information nicht in binärer Form enkodiert sondern als Text als xml.

2. Lotus favorisiert unter den verschiedenen Webservice Standards SOAP
Lotus favorisiert als Webservice Standard den sogenannten SOAP Standard. Dieser Standard wurde vor allem auf Grund der Komplexität kritisiert. Es existieren konkurrierende Standards wie z.B. die REST-Architektur oder Hessian & Burlap. But wait: Komplexität heisst hier nicht unbedingt, dass es für den Entwickler kompliziert wird. Es ist Tradition bei SOAP, dass die komplexen Deskriptoren-Dateien wie z.B. die WSDL Dateien von Tools erzeugt werden (so ist das auch bei Lotus Notes 7). Zumindest mit Webservices des Typs RPC bekommt man als Entwickler noch nicht einmal xml zu sehen.

Auch wenn man als Anwendungsentwickler vielleicht erstmal nichts von der Komplexität mitbekommt, wirkt sie sich natürlich aus. SOAP gilt aufgrund der hohen internen Komplexität als im zweifelsfall nicht besonders performant. Für viele Anwendungsfälle kann es aber ausreichend sein und attraktiv dürfte v.a. der reichhaltige Tool-Support sein.
Eine andere Stelle, an der die unterliegende Komplexität ihren hässlichen Kopf erhebt sind Datentypen, va. komplexere. Wenn ein Microsoft.NET Client von einem Lotus Webservice Daten in Form eines Lotus Datentypen List erhält, weiss der MS-NET Client vielleicht nicht, wie er diesen Datentyp zu verstehen hat. Komplexere Datentypen sind aber teilweise von Lotus SOAP konform definiert worden. Aber das hat natürlich Grenzen. Z.B. wird sowas noch viel komplexeres wie Notes-Document niemals in SOAP definiert.

UDDI ist erstmal nicht so wichtig. 

3. Kurzes Beispiel (serverseitig)
Erstmal teste ich mit verschiedenen im Java Umfeld vorhandenen dedizierten Webservice Testtools, ob ein Zugriff auf Domino Webservices mit Java möglich ist und wenn ja, welche Probleme auftreten.
In einer realen Anwendung wird man diese Testtools selbst nicht einbinden. Aber sie benutzen dieselben openSource Komponenten, die man bei seinen eigenen auf Webservices zugreifenden Java Code auch verwenden wird (jakarta-axis). 
Später erstelle ich noch eine kleine Swing-Gui als reale Mini-Beispielanwendung. Vielleicht auch eine Web-Anwendung auf Tomcat.

Wie sieht jetzt so ein Webservice aus. Im Tutorial ist ein Beispiel. Ich hab auch eins.
Es ist eigentlich alles ganz einfach.

Man kann als Webservice scheinbar nur Klassen verwenden. Ist aber nicht so schlimm. Hier ist die Klasse.

Code

Class Land
	Private ses As NotesSession
	Private db As NotesDatabase
	Private vwLand As NotesView
	
	
	Public Sub New 
		Set ses = New NotesSession()
		Set db = ses.currentDatabase
		Set vwLand = db.getView("land")
	End Sub
	
	
	Public Function getHauptstadt (land As String) As String
		Dim docLand As NotesDocument
		Set docLand = vwLand.GetDocumentByKey(land)
		If docLand Is Nothing Then 
			getHauptstadt = "LAND <" & land & "> kann in der Datenbank nicht gefunden werden." 
		Else
			getHauptstadt = docLand.Hauptstadt(0)
		End If
		
	End Function
	
End Class

Dann gibt es noch in der Eigenschaftenbox 3 Tabs die man füllen kann:
Im ersten Tab gibt man den Namen und den Namen der Klasse an.
Der 2. Tab enthält Security Zeugs wie "run on behalf of" und Security Levels. Um mich selber nicht zu verwirren habe ich das offenste Security Level und run on behalf of Server gewählt.
Der 3. Tab ist ein bischen komisch. Man kann dort Messaging Model und Message Format wählen. Ich habe mich für RPC/encoded und RPC entschieden. Ich vermute stark, dass man für die anderen Typen mehr eigene xml-Programmierung braucht.
Unten sind dann noch 3 seltsame Felder "Port Type Name", "Service Element" und "Service Port Name". Das sind Grüße von der komplexen SOAP Spezifikation und diese Felder werden beim ersten Speichern automatisch gefüllt.

Man kann das ganze speichern.

Dann gibt es noch oben WSDL buttons (import/show/export). Dieses WSDL wird automatisch generiert. Ich versuche damit später mit dem jakarta axis 1.0 Paket einen Client zu generieren.
Dort kann nämlich - soweit ich mich erinnere - aus einem WSDL File automatisch die Zugriffs-Klassen für diesen Webservice generiert werden.

Das WSDL (Webservice description Language) File ist länger als die Klasse selber, aber na gut. Lotus hat es generiert. Normal finde ich das nicht.

Code

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="urn:DefaultNamespace" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="urn:DefaultNamespace" xmlns:intf="urn:DefaultNamespace" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <wsdl:message name="GETHAUPTSTADTResponse">
  <wsdl:part name="GETHAUPTSTADTReturn" type="xsd:string"/>
 </wsdl:message>
 <wsdl:message name="GETHAUPTSTADTRequest">
  <wsdl:part name="LAND" type="xsd:string"/>
 </wsdl:message>
 <wsdl:portType name="Land">
  <wsdl:operation name="GETHAUPTSTADT" parameterOrder="LAND">
   <wsdl:input message="impl:GETHAUPTSTADTRequest" name="GETHAUPTSTADTRequest"/>
   <wsdl:output message="impl:GETHAUPTSTADTResponse" name="GETHAUPTSTADTResponse"/>
  </wsdl:operation>
 </wsdl:portType>
 <wsdl:binding name="DominoSoapBinding" type="impl:Land">
  <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
  <wsdl:operation name="GETHAUPTSTADT">
   <wsdlsoap:operation soapAction="GETHAUPTSTADT"/>
   <wsdl:input name="GETHAUPTSTADTRequest">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:DefaultNamespace" use="encoded"/>
   </wsdl:input>
   <wsdl:output name="GETHAUPTSTADTResponse">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:DefaultNamespace" use="encoded"/>
   </wsdl:output>
  </wsdl:operation>
 </wsdl:binding>
 <wsdl:service name="LandService">
  <wsdl:port binding="impl:DominoSoapBinding" name="Domino">
   <wsdlsoap:address location="http://localhost"/>
  </wsdl:port>
 </wsdl:service>
</wsdl:definitions>

[flaite]

Der Soap Standard wurde von Microsoft und IBM gemeinsam entwickelt.
Vermutlich wollten die sich gegenseitig mit irgendwelchen coolen Spec-Features übertrumpfen, die kein Mensch nachvollziehen kann.

Jedenfalls brachte jetzt der mitgelieferte Testclient des Webtools Projekt von Eclipse die Rettung (die Webservices Abteilung von WSAD ist ähnlich).

Ich hab einfach das von Domino generierte wsdl file in diesem Tag ein bischen erweitert (

Code

<wsdl:service name="LandService">
  <wsdl:port binding="impl:DominoSoapBinding" name="Domino">
   <wsdlsoap:address location="http://localhost/webservices/FirstTest.nsf/FirstTest?openWebservice"/>
  </wsdl:port>
 </wsdl:service>

(interessierte mögen das mit oben vergleichen.

Dann ein eclipse (3.1) mit installierten Web Tools Platform Plug-ins.
Einfach das wsdl reinimportieren.
Rechte Maustaste auf das wsdl. Webservice / Test with webservice explorer.
Und voila. Man kann sich da dann durchklicken. Man bekommt ein Ergebnis und poppt auch noch unten ein netter Monitor auf, der die ausgetauschten SOAP Messages anzeigt (von Byte auf xml wechseln).

Offenbar hat sich in den Webservices unter Domino 7 seit den Beta Releases auf denen sich das Tutorial bezieht einiges geändert. Probiere weiter.

Die Response Zeit von 4.5 Sekunden bestätigt sämtliche meine Vorurteile gegen SOAP. Jedoch ist natürlicher dieser von Eclipse Web Tools Platform generierte Client wohl auch sehr inperformant.

(vergl. Rückgabe mit Klasse Land oben:
Zeile:

Code

getHauptstadt = "LAND <" & land & "> kann in der Datenbank nicht gefunden werden." 

Das Tool (s. Screenshot) finde ich Klasse, zumindest wenn man das nicht jeden Tag ist.
Ganz oben in Navigation kann man navigieren und Testwerte einfügen.
Im Panel Status wird der Rückgabewert angezeigt.
Unten sieht man die ausgetauschten Soap Messages.
Eclipse hat die linke geschickt und Domino hat die rechte zurückgesendet.

bleib weiter am Ball.

Axel 

[koehlerbv]

Vielen Dank, Axel, für diesen Bericht.

Kannst Du kurz nochmal aufmalen, welche Applikationen / Pakete / Plug-Ins Du jetzt für Deine Tests verwendest und auf wievielen Maschinen diese laufen (sollte ja auf einer möglich sein für Deine Studien, oder ?).

Bernhard

[flaite]

1 Maschine. Tomcat läuft standardmässig auf port 8080, Domino auf 80.
 
Wichtig ist Eclipse mit Webtools Plattform Plugin.
Das wtp-all-in-one-0.7 auf dieser Seite (da ist eclipse dabei).
http://download.eclipse.org/webtools/downloads/drops/R-0.7-200507290654/
Das zip vermutlich einfach nur auspacken.
   wtp-all-in-one-0.7-win32.zip(md5)

Ein JSDK 1.4 sollte installiert sein.

Und Tomcat. Ich hab Tomcat 5 genommen.
http://tomcat.apache.org/download-55.cgi#5.0.28 (für windows user die windows executable. Ist ein einfaches Installationsskript dabei.

In Eclipse muss noch Tomcat angemeldet werden.

Erste Aktion in Eclipse:
File / New Project / Dynamic Web Project. In dem Dialog advanced Klicken und dort kann man Tomcat eintragen (Target Server drop down). 
Dem Projekt muss dann noch ein beliebiger Name gegeben werden (ohne Leerzeichen).
Dann File / Import und im Eclipse Menü auf das vorher aus Domino exportierte .wsdl File. In das Projekt. 
Die Änderung im WSDL ist absolut notwendig.
Sieht so aus:

Code

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="urn:DefaultNamespace" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="urn:DefaultNamespace" xmlns:intf="urn:DefaultNamespace" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="">
 <wsdl:message name="GETHAUPTSTADTResponse">
  <wsdl:part name="GETHAUPTSTADTReturn" type="xsd:string"/>
 </wsdl:message>
 <wsdl:message name="GETHAUPTSTADTRequest">
  <wsdl:part name="LAND" type="xsd:string"/>
 </wsdl:message>
 <wsdl:portType name="Land">
  <wsdl:operation name="GETHAUPTSTADT" parameterOrder="LAND">
   <wsdl:input message="impl:GETHAUPTSTADTRequest" name="GETHAUPTSTADTRequest"/>
   <wsdl:output message="impl:GETHAUPTSTADTResponse" name="GETHAUPTSTADTResponse"/>
  </wsdl:operation>
 </wsdl:portType>
 <wsdl:binding name="DominoSoapBinding" type="impl:Land">
  <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
  <wsdl:operation name="GETHAUPTSTADT">
   <wsdlsoap:operation soapAction="GETHAUPTSTADT"/>
   <wsdl:input name="GETHAUPTSTADTRequest">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:DefaultNamespace" use="encoded"/>
   </wsdl:input>
   <wsdl:output name="GETHAUPTSTADTResponse">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:DefaultNamespace" use="encoded"/>
   </wsdl:output>
  </wsdl:operation>
 </wsdl:binding>
 <wsdl:service name="LandService">
  <wsdl:port binding="impl:DominoSoapBinding" name="Domino">
   <wsdlsoap:address location="http://localhost/webservices/FirstTest.nsf/FirstTest?openWebservice"/>
  </wsdl:port>
 </wsdl:service>
</wsdl:definitions>

Dann einfach rechte Maustaste auf das WSDL File und Webservices / Test with Webservices Explorer.

Im WSDL file wird in Eclipse ein Fehler angezeigt. Scheint aber nicht zu stören.

Ich such dann noch nach einer Möglichkeit den Client Code einfach als Java Code zu erzeugen. Ich kann das dann mit Ant oder Maven Build Umgebung posten. Dann werden die Pakete automatisch runtergeladen. Kann aber noch ein paar Tage dauern.

Diese Eclipse WTP Geschichte ist sehr WSAD/Rational Developer ähnlich.

WSDL: Geändert ist wie gesagt der untere Tag.

Code

<wsdlsoap:address location="http://localhost/webservices/FirstTest.nsf/FirstTest?openWebservice"/>
  

Notes erzeugt:

Code

<wsdlsoap:address location="http://localhost"/>

Und das funktioniert nicht. (Imho kann das nicht funktionieren = bug).
Mein Fehler. Ich weiss nicht wie ich das mit den Eclipse WTP Tools anders machen soll als eine lokale Kopie der WSDL Datei zu laden. Wie unten zu sehen ist, funktioniert alles, sobald man das WSDL File per Url anspricht: In meinem Fall ist das: http://localhost/webservices/FirstTest.nsf/FirstTest?WSDL

Im WSDL Element erzeugt WTP immer dieses name="" Attribut. Keine Ahnung warum. Stört aber wie gesagt nicht.

Axel

[flaite]

Ausserdem will ich später im Sinne von ganz bestimmt nicht dieses WE ein Beispiel für eine REST Architektur aufbauen. SOAP steht unter heftiger Kritik. Der Aufwand der unter der Haube von SOAP passiert, um
a) an einen Webserver ein xml File zu senden und
b) ein xml File zurückzubekommen
ist obzön und macht das Leben für Anwendungsentwickler imho oft nicht gerade einfacher. Jedenfalls war diese ganze Aktion relativ hektisch, v.a. da das von Domino generierte WSDL File einen bug hatte und apache.axis.java wenig zielführende Fehlermeldungen ausgab.
Vom Springframework bin ich genau das nämlich nicht mehr gewohnt. 

Gruß Axel 

[flaite]

Das WSDL hat offenbar doch keinen Bug
Es liegt an meinen Verständnislücken von SOAP.
Vermutlich liegt es daran, dass ich mit einer lokalen Copy des WSDL Files gearbeitet habe. Weiss allerdings auch nicht wie das anders gehen soll mit den Tools von Eclipse Web Tools Platform 0.7.

ABER: Ich habe jetzt in SoapUI die URL des WSDL Files getan und da läuft alles ok.
Was ist die URL des WSDL Files? In meinen Fall: http://localhost/webservices/FirstTest.nsf/FirstTest?WSDL
Man kann das in die Adresszeile eines Browsers eingeben.

Was ist SoapUI? In diesem Blog Eintrag von Julian Robinchaux ist davon die Rede:
http://www.nsftools.com/blog/blog-09-2005.htm#09-19-05
Einfach auf die Projektseite klicken (http://www.soapui.org/index.html) und auf den mit Webstart runterladen Button klicken (der große blaue).
Der Rest geht automatisch.
in die Gui von SoapUI klicken. Neues Projekt. Speicherort für die xml Konfig Datei eingeben. Rechte Maustaste auf das Projekt. Add Wsdl from Url.
Zum Starten dann den grünen Pfeil.
Unten sieht man das Ergebnis.
Der Spaß dauert dann nur noch 0.1 bis 0.2 Sekunden (ab dem zweiten Aufruf).

[flaite]

Hab ins Notes 7 Forum gepostet. Vielleicht kann mir da jemand was sagen:
https://www-10.lotus.com/ldd/nd6forum.nsf/DateAllThreadedweb/b80f5d81791033e7852570a300247105?OpenDocument

[flaite]

Hier noch die derzeitige Beispieldatenbank. Basiert stark auf der von Bill Buchan.
Der Mann ist kein Anfänger.
Selbst die Kommentare konnte ich wiederverwenden. 
Ich hab nur das Design auf mein Standard-Design geändert.
Die Datenbank muß auf einen Notes Server getan werden. Sie funktioniert z.Zt. nur mit dem Notes Client (also nicht Browser, auch wenn das Webservices heisst).


Neu ist hier ein Notes Webservice Client, der auf den Notes Webservice Server zugreift.
Das ist eigentlich ein bischen Schwachsinn, weil es innerhalb einer NotesDatenbank selber natürlich effizientere Wege des Datenaustauschs gibt. Webservices sind eben für den Austausch von Daten zwischen unterschiedlichen Systemen gedacht. Aber als Beispiel ist das ganz instruktiv, weil eben so gezeigt wird, wie beide Enden der Kommunikation in Notes programmiert werden können (Client und Server).
Ich werde - wenn Zeit und Lust da ist - dieses Beispiel ausbauen auf Zugriff auf z.B. Amazon Webservices und Beispiele mit Tomcat, Java Swing Clients und vielleicht Ruby Clients.
Dann vielleicht noch Beispiele für alternative Technologien zu SOAP wie z.B. REST.

Diese Datenbank habe ich auch für die Zugriffe von den Java Testtools oben verwendet.

Zu der Implementierung von Webservice Clients in Notes 7 sind noch ein paar Sachen zu sagen.

Achso. Das obskure WSDL File könnt ihr euch - wenn die Datenbank installiert ist - mit der folgenden URL in einen Browser laden:
http://<server>/<pfad>/FirstTest.nsf/FirstTest?WSDL

Gruß Axel

[flaite]

Inzwischen hat ein Herr Steve Nikopulous eine Antwort für meine service-adress location Probleme geliefert.
Er sagt sinngemäss, dass muss so sein, weil sich ja Pfad oder Server der Datenbank ändern kann.
Es ist deshalb immer besser, sich das WSDL File vom Server zu holen.
https://www-10.lotus.com/ldd/nd6forum.nsf/DateAllThreadedweb/a2d16a6bf0422218852570a3004e0116?OpenDocument

Ich weiss nicht ganz, ob ich dem voll und ganz zustimmen kann.
Zumindest sollte es imho beim WSDL exportieren eine Option geben, dass man die aktuelle Adresse im WSDL haben will bzw. zumindest eine Warnung erscheinen. Mit diesen ziemlich fetten Export WSDL Buttons ein nicht vollständiges Konfigurationsdokument für einen wirklich komplexen Standard (SOAP) zu liefern, halte ich für problematisch.

Axel

[flaite]

Der Zugriff geht über Web Tools Platform auf Eclipse auch mit
1. Projekt - Web - Dynamic Web Project
2. Server auswählen (Tomcat sollte auf Rechner installiert sein. Es gibt noch "Generic Versions" von verschiedenen Servern u.a. Websphere und Bea Weblogic, hab aber auf eigenes Vertraut).
3. Web Services - Web Services Client
4. Eclipse fragt dann nach der WSDL. Man muß dafür die Domino URL angeben. In meinen Fall ist das: http://localhost/webservices/FirstTest.nsf/FirstTest?WSDL
5. Eclipse erzeugt dann 5 Klassen und deployed sie in einem Tomcat Projekt. Auf der Web Tools Platform Oberläche liegen sie im Source-Ordner Java Source.
6. Tomcat kann gestoppt werden (falls er läuft).
6. In die Klasse *Proxy Klasse (in meinem Fall LandProxy) muß unten die folgend static main hinzugefügt werden.

Code

  public static void main (String [] args) {
	  try {
		System.out.println(new LandProxy().GETHAUPTSTADT("Chile"));
	} catch (RemoteException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
  }

7. Klasse einfach starten.
8. Axis meldet erst - Unable to find required classes (javax.activation.DataHandler and javax.mail.internet.MimeMultipart). Attachment support is disabled.
Das ist eigentlich kein Fehler sondern eine Warnung, die hier auch fehlplaziert ist.
9. ... und dann das Ergebnis.

Werd das mal ein bischen ausarbeiten und noob-freundlich machen.

Jedenfalls ist das möglicherweise eine ganz attraktive Möglichkeit, um Daten zwischen Domino und Java Umgebungen (als Beispiel) auszutauschen.

[flaite]

Was ist jetzt daran so toll?

Ganz einfach. Nachdem diese 5 Klassen generiert habe, kann ich aus der Anwendung den Webservice einfach über eine normale Methode einer normalen Klasse aufrufen.
Die 5 generierte Klassen kann ich in beliebige Java Projekte tun (ob auf Webspere, Tomcat, in einer Standalone Anwendung oder egal)
Und anders als in vielen Notes-Ad-on Produkten wie z.B. Domino Workflow habe ich den Source Code des Zusatzes und kann den auch zur Not Debuggen.
Über die komplexen Details von Webservices Clients in Java brauche ich mir keine Gedanken zu machen.
 
Werd hiermit weitermachen. Um wirklich die Grenzen einer Technologie auszuloten, müßte man sich an praxisnaheren und komplexeren Aufgaben nähern. Z.B. eine Webservices Schnittstelle für einige Funktionen von !!!Help!!!. Wollte das ja sowieso mal installieren.
Webservices werden auch stark im Architektur Paradigma der Service Oriented Architecture (SOA) genannt. Bestell mir jedenfalls mal das 2005 Buch von Erl.

[Ralf_M_Petter]

Hallo Axel!

Super Bericht Danke für die vielen Informationen.

Grüße

Ralf

[flaite]

Hier ein sehr einfacher Client seitiger Webservice von Notes, der einen Service aufruft, der 20 min. verzögerte Aktienkurse zurückgibt.

Code

Sub Initialize
	Const urlWSD = "http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl"							' This is the URL of the server hosting this web service
	Dim result As Double
	Dim stockSymbol As String ' liste: http://stocks.tradingcharts.com/stocks/symbols
	
	'Create a new MSSOAP client object		
	Dim client As Variant
	Set Client =CreateObject("MSSOAP.SoapClient")
	
	'Initialize connection to the WSDL file and get WSDL structure		
	Call Client.mssoapinit (urlWSD)
	
	stockSymbol = "IBM"
	' calling the SOAP function
	
	result = Round(Client.getQuote(stockSymbol), 2)
	
	'output result to message box		
	Messagebox result, 48, "20 min verzögerter Aktienkurs von " & stockSymbol 
End Sub

[flaite]

Für eine ernsthaftere Beschäftigung mit dem Thema gibt es eine Gratis-Angebot von Sun:
http://www.javapassion.com/webservices/
Nix Streaming, Multimedia und so einen neumodischen Quatsch. Dafür gibts Hausaufgaben, die man als Zip-File an die Kursleiter schicken kann  (ich versuch da mitzumachen).

[flaite]

Um der Beispielsammlung noch ein Baustein hinzuzufügen, bin ich jetzt dabei einen Java Client in Swing zu entwickeln, der via Webservices auf Domino zugreift.

Ist schon fertig. Muß nur noch an der Errorbenachrichtigung arbeiten.

Selbstverständlich sind da wieder Tonnen an Zusatzpackages dabei. Um das einfach installierbar zu machen ohne diesen Server groß zu belasten, will ich den ganzen extrem interessanten Prozess des downloadens von Zusatzpackages, z.T. entzippen, kompilieren, classpath setzen und starten über ein ant-file steuern (eigentlich nicht so schwierig). Interessierte müssen dann nur noch ant installieren (einfach), jsdk 1.4 auf dem Rechner haben und diese Buchstaben in eine Kommandozeile zu tippen:

Code

ant

Hier schon mal die Preview.

[flaite]

worum geht es hier eigentlich
Wie ich oben beschrieben habe, liegt die Stärke von Webservices daran, dass Informationen zwischen unterschiedlichen Plattformen ausgetauscht werden können. Und das ist hier ein Beispiel, in dem eine Java Swing Anwendung auf einen Domino Webservice zugreift. Ich habe jetzt versucht, die Installation des Java Swing Clients möglichst einfach zu machen.

warum ant?
So hier ist jetzt next generation der Verteilung von Java Beispielen über Foren.

Es geht mit Ant.

Aber was ist das Problem?

Für Beispiele wie Webservices mit Domino benötigt man eine Menge Zusatzpackages, v.a. wenn ich noch mit neuerem Swing-Zeug rumexperimentiere.
Das heisst für die Leute, die sich das Beispiel anschauen wollen, dass sie diese ganzen langweiligen Schritte wie die ganzen Zusatz-Libraries im Internet aufstöbern, classpath setzen, kompilieren, etc. nachvollziehen müssen.
Für Java gibt es aber ein einfach zu bedienendes Kommando-Zeilen buildtool namens ant.
Dann muß der Benutzer des Beispiels nur noch einen command prompt öffnen zu dem Verzeichnis wechseln, wo das zip file mit meinen Klassen und das build.xml File (s. Attachments) von ant ist und die drei Buchstaben ant eingeben. Den Rest erledigt dann die Ameise. Vor allem wird damit auch dieser Server sehr wenig belastet, weil ant die ganzen jar-Zusatzlibraries von anderen Servern holt. 

Wenn die Benutzer ant haben, brauche ich nur eine ant Deskriptor-Datei für den Build und die von mir geproggten unkompilierten Java Source Files in einer Zip Datei posten.

Im Attachment sind diese beiden Dateien.

Um das build.xml File für ant zu benutzen, muß erstmal ant installiert werden.

ant installieren
Wie ant installieren?
Ganz einfach. Es muß allerdings ein Java Standard Developer kit (j2sdk) auf dem Rechner installiert sein

Hier ist der download.
http://ant.apache.org/
Dann müssen noch ein paar Umgebungsvariablen für das OS gesetzt werden:
ANT_HOME -> Das root Verzeichnis von ant (bei mir ist es: C:/ant/apache-ant-1.6.5)
PATH -> das bin Verzeichnis von ant muß hinzugefügt werden: (Bei mir ist es C:/ant/apache-ant-1.6.5/bin)
Ausserdem muß die Umgebungsvariable JAVA_HOME gesetzt sein (bei mir ist es D:\j2sdk1_4_2_05
Vermutlich muß noch das bin Verzeichnis von JAVA_HOME (also %JAVA_HOME%\bin) in der PATH Umgebungsvariable sein. Bin mir aber nicht so 100% sicher.

Ich bin ziemlich windows lastig. Es würde mich freuen, wenn das mal jemand mit Linux ausprobieren könnte. Die Installation von ant wird auf der Webseite von ant (s.o.) beschrieben.

Ihr könnt die korrekte Java und ant Installation testen, indem ihr in den command prompt (cmd, dos-box) javac und danach ant eingibt.

Bei javac wird etwas ausgegeben, dass mit usage: anfängt (dann ist es richtig)
Bei ant wird Buildfile: build xml does not exist! ausgegeben (dann ist es richtig).

Bei unklarheiten posten.

Ant nutzen mit dem geposteten Beispiel
Schritt 1: Beide hier angehängten Dateien (das zip und die build.xml) einfach in ein beliebiges Verzeichnis kopieren (besser ohne Leerzeichen).
Schritt 2: Mit dem cmd-prompt in das Verzeichnis navigieren (cd Befehl von DOS).
Schritt 3: ant eingeben und Returntaste drücken.
Das ist alles

Danach passiert eine Menge (erst werden ein paar Jars aus dem Internet geholt, rumkopiert, Classpath gesetzt, kompiliert und der Client gestartet).
Im CMD-Fenster erscheinen die entsprechenden Meldungen.
Die oben gepostete Notes Datenbank (serverseitige Webservices) muß in dem exakten Pfad wie ich es auch habe erreichbar sein (http://localhost/webservices/FirstTest.nsf). Das heisst nachtürlich auch: der http Server von Domino muß laufen. Ist dies nicht der FAll, dann startet der Client trotzdem, nur wird dann immer eine Fehlerbox (Verbindung nicht gefunden. Vermutlich läuft der Server nicht) ausgegeben.

Weitere Probleme können auftauchen. Ich hole mir 2 jar-Libraries aus http-Oberflächen von cvs Maschinen. Die haben schon mal Ausfälle. Das wird aber in der Dos-Box gemeldet. Bitte posten bei Problemen. Die meisten jar-libraries lasse ich von einem maven-repository runterladen. Das dürfte sehr stabil sein.

Ok. Wenn ihr Ant startet erscheinen ein paar Meldungen in der DosBox: V.a. der Download dauert ein bischen länger (mit relativ schneller Internet-Verbindung bis zu 4 Minuten). Ant ist schlau genug, dass er merkt, dass bestimmte Dateien schon da sind, so dass beim zweiten starten viele Operationen nicht mehr ausgeführt werden.
Die Meldungen sehen ungefähr so aus:

Am Anfang kommt download und die einzelnen libraries. Das kann je nach Internet-Verbindung ein bischen länger dauern. Z.B. ist axis.jar 1.6 MB groß, xerces 875 kb, looks 329 kb, die restlichen aber deutlich kleiner. 
Dann unzip, compile, copy, execute (wesentlich schneller).
Es erscheint dann der Java Client. Eine ca. 100 x 50 Pixel große nett anzuschauende Box. Das Programm ist einfach zu bedienen. In das obere Kästchen ein Land eingeben. Return oder Fragezeichen drücken und Domino sendet dann die Hauptstadt zurück (falls von diesem Land eine als Dokument vorliegt (s. nsf Beispiel oben).

Der Source Code von dem Client selber ist ziemlich übel zusammengeschustert. Aber ich finds erstmal nicht schlimm. Ich bin mit den neuen Möglichkeiten von swing erst noch am experimentieren.
Würde mich freuen, wenn das mal jemand ausprobieren könnte.
Ant ist im Java-Bereich sehr weit verbreitet und viel besser als maven 

OOOPS ich stelle gerade fest, dass sich Dateien mit .xml Endungen hier nicht anhängen lassen. Ich nenne die Datei jetzt in build.txt um. Ihr müsst die dann nach dem kopieren wieder in build.xml umbenennen.

Ich hab versucht, die einzelnen Schritte des build.xml ein bischen zu beschreiben:
http://atnotes.de/index.php?topic=26707.msg170000#msg170000

Gruß Axel

[flaite]

[bitte löschen]

[flaite]

(meine letzten Worte zu diesem Thema, promised)
This is actually easy to use.
Bedingung:
a) Ein Jsdk1.4 oder 1.5 ist auf dem Rechner installiert.
b) ant installieren (download und 2 Umgebungsvariablen setzen, oben beschrieben)
c) die beiden attachten Dateien in dem vorletzten Posting dieses Thread runterladen und in ein Verzeichnis tun.
d) ant.txt in ant.xml umbenennen
d) zu dem Verzeichnis, wo die beiden runtergeladenen Dateien sind, mit dem DOS-Prompt navigieren.
e) ant eingeben
f) Return Taste drücken

Den Rest macht ant.

(screenshot ist bei Schritt e)
[verschieb den Inhalt noch rüber]

[flaite]

Julian Robinchaux und Bruce Elgort haben nun eine 2-teiligen Podcast über Webservices veröffentlicht (http://www.eknori.de/archives/147). Und zwar auf LotusUserGroup.org, eine relativ interessante Webseite, die sich mit Domino Entwicklung und Administration beschäftigt.
Podcast heisst für mich zur Zeit noch mp3 Files und Filme, die man sich in den Gratis Realplayer runterladen und vorm Einschlafen/beim Bügeln/ beim Aufräumen anhören/anschauen kann. Gibt aber auch Podcast Player. Weiss aber nicht, wo der Vorteil ist.

Anyway. Wie ist nun dieser Podcast von Julian und Bruce?
Beide Teile bringen eine sehr high level Einführung in das Thema. Das muß nicht schlecht sein. Im ersten Teil werden einige typische Begriffe rund um Webservices kurz angerissen.
Webservices dienen dem Austausch von Programmen. RPC-Type Webservices sind einfach API-artige Aufrufe gegen ein Programm auf einem anderen Rechner auf einer möglicherweise anderen Plattform.
Ich persönlich finde die einseitige Fokussierung auf RPC-Type Webservices ein bischen problematisch. Es gibt eine Menge von Fällen, in denen der andere SOAP-Type (Document-Style) absolut notwendig ist. Ist aber richtig, dass man mit RPC-Type anfangen sollte, wenn man ein bischen mit Webservices rumspielt.
Als nächstes werden WSDL Files besprochen. WSDL-Files dienen der Beschreibung des Webservices und sind auf vielen Plattformen stark mit Code-Generierung verknüpft. Wie Julian sagt, sollte ein Anfänger nicht versuchen WSDL Files zu verstehen. Diese Dinger werden in der Regel von den WebServices IDEs automatisch generiert. Bzw kann man die IDE auch aus einem bestehenden WSDL Files einen Webservices Client generieren lassen.
Dann wird kurz UDDI besprochen. Dies ist eine Art Registry für Webservices. Sowas wie ein Telefonbuch. Zu Anfang von Webservices wurde dieses Konzept stark überdehnt. Man träumte von globalen Telefonbüchern von Programmfunktionalitäten. Dies ist aber als Konzept zu unsicher und spacig. Wenn viele Webservices in einer Organisation benutzt werden, machen vielleicht lokale UDDI-Registries Sinn, um den Überblick zu erhalten.
Julian nennt dann SOA (Service Oriented Architecture) als Folge-Architektur-Paradigma von UDDI. Das ist mir neu und nicht dumm. Er sagt richtig, dass in SOA Webservices eine prominente Rolle spielen auf der anderen Seite aber über die rein technischen Webservices weit hinausgeht (es ist ein Architekturkonzept, um z.B. die Technologie Webservices sinnvoll in einer Organisation zu nutzen.
In SOA geht es u.a. um das Zusammenspiel von Webservices. Sowie um die Realisierung von verschiedene automatisch bereitgestellte Dienste wie z.B. Transaktionen, Security, State-Management und Fail-Over.
SOA ist sehr interessant. Mit J2EE hat man die Möglichkeit aus der IT-Infrastruktur einer Organisation ein riesiges Objekt-Modell zu machen. Man kann über J2EE alles in ein Objekt-Modell einbinden (Domino, RDBMS, existierende Cobol-Anwendungen, SAP, uvam). Seit den sogenannten JCA-Adaptern gibt es da sehr wenig Grenzen. Man hat aber nun festgestellt (und genau das glaube ich z.Zt. in der freien Wildbahn zu erleben), dass ein großes Objekt-Modell sehr schwierig zu verstehen und managen ist. Webservices bieten nun die Möglichkeiten, ein Objektmodell in mehrere kleinere und einfachere Objektmodelle zu teilen und über letztlich nicht-OO Schnittstellen (die Webservices Endpoints) zu integrieren.

Im zweiten Teil des Vortrags von Julian sagt er, dass Domino intern apache-axis - eine robuste und u.a. auch von mir präferierte openSource Webservices Plattform auf Java - benutzt. Dann geht er noch kurz auf die Motivation ein, warum Lotus das eingebaut hat.
Webservices werden in der Zukunft mehr benutzt. Sie sind relativ einfach zu realisieren und sämtliche IT-Vendors spielen da mit (Oracle, Microsoft, Java/J2EE, Schnittstellen zu Host-Anwendungen, etc..). Es ist die dominante Plattform für Enterprise Application Integration und besitzen reale Vorteile gegenüber css-Files.

Es ist ziemlich klar, dass Julian und einer aus dem TSG-Team auf der nächsten LotusSphere einen Vortrag über SOA halten werden.

Für einen Reality Check, könnte man nun versuchen, einen Webservices Layer für eine größere Notes-Anwendung wie z.B. Help!!! zu erstellen. 

[flaite]

Ein wichtiger Punkt ist aber, dass man das mit code einmal ausprobieren sollte, damit diese ganzen buzzwords wie WSDL, RPC-Call, SOAP, etc. ein bischen mit Leben gefüllt werden.
Also nochmal: In diesem Thread gibt es eine NotesDatenbank als Webservices Server Beispiel und 2 Clients:
- Einen Notes Client
- Einen supereinfach über ANT zu installierenden Java Client, den keiner runterlädt. 



Axel