Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Webservices mit Notes

<< < (2/2)

flaite:
Webservices heisst nicht automatisch SOAP Webservices.
SOAP Webservices gibt es erst seit Version 7. Und hier auch nur als Server. Nicht als Client.
Ob das "komfortabel" ist, bezweifele ich.

POX Webservices, für das ich gerade ein Beispielanwendung in diesem Forum programmiere (zugegeben dauert das ziemlich lange) geht auch mit Version 6. Und zwar Server UND Client. In meinem Büro sitzen übrigens gerade 2 Leute, die auf einem Domino 6 Server diese von mir konzipierten Webservices auf die Art als Server beantworten. Wir sind am Integrations-Testen.
Theoretisch ginge es auch mit vorherigen Versionen, jedoch muß man das dann anders machen als wie wir das machen, weil die Java Versionen ab Domino 5 abwärts richtig alt werden. Zumindest kann man aber schon mit Domino 5 xml parsen.
Manche behaupten ja hier auch, dass sie für xml parsing sowieso lieber die soliden String-parsing Funktionalitäten von Notes nehmen, statt irgendwelchen neumodischen xml-Parsern zu vertrauen. Das ginge dann mit Notes 4.5 oder vielleicht noch ältere Versionen.

Alles was man für POX (Plain old Xml) Webservices benötigt ist:
a) die Möglichkeit per HTTP xml entgegenzunehmen.
b) xml zu parsen (ich nehme dafür xml Parser, geht aber auch mit String Parsing (haha).
c) xml als HTTP-Response zurückzuschicken.

Unter den Gelehrten ist btw. SOAP ziemlich umstritten. Es ist definitiv überdesigned. Viel wurde von REST Webservices geredet. Aber eigentlich meinen die Leute oft POX, wenn sie REST reden. REST ist ein bestimmtes Kommunikationsmodell. POX ist da ein Überbegriff.
Ich hab da einen anderen Zweig des oben angesprochenen Projekts, in dem ein Tomcat einen portugiesischen SAP Application Server per SOAP anquatscht. So wie ich das programmiert hab, könnte man das Webservice Client Subsystem problemlos in Domino7 und mit Änderungen vermutlich auch in Domino 6 einbinden. Bei SOAP gibts immer eine Beschreibungsdatei namens WSDL mit dabei, die oft per URL aufrufbar ist. Das kann in der Praxis ein paar Vorteile haben. Zum Beispiel haben wir eine Menge Spaß, wenn das Projektmanagement stolz neue Feldänderungen in Excel Dateien bekanntgeben, ich aber schon am Abend - nach Mitteilung des portugiesischen Kollegen - vorher ins WSDL geschaut habe und die Änderungen bereits umgesetzt sind, bevor ich offiziell über die Änderung informiert werde. Quasi Changemanagement jenseits der Lichtgeschwindigkeit.  ;D
Es gibt aber auch eine openSource Initiative, wo es darum geht Beschreibungsdateien für POX Webservices zu erstellen.

Vorteile kann SOAP bringen, wenn es dafür auf der jeweiligen Serverplattform wirklich extrem automatisierende Tools hat. Das gibts auch eher in .NET als in Java (Java holt auf). SAP Application Server scheint hier übrigens auch ganz gut zu sein. Die brauchen einfach nur ein paar Schalter umlegen und es gibt für einen RFC eine WSDL und man kann das mit SOAP ansprechen.
Auf dem Level bewegt sich die SOAP Unterstützung von Domino nicht.


Gruß Axel

flaite:
Vor mir alle haben Webservices im Sinne vom SOAP verstanden.

Deshalb noch einmal eine meiner Lieblingsgeschichten über "Enterprise IT":
SOAP wurde vom eigenen Standardisierungsgremium selbst der "Abkürzungs-Status" entzogen.
Es stand für Simple Object Access Protocol. Heute ist es explizit keine Abkürzung/Akronym mehr.
Warum?
Dem Standardisierungsgremium für SOAP gehörten von Anfang an IBM, Microsoft und einige weitere Schwergewichte an.
Und genau dieses Gremium hat dann irgendwann festgestllt, dass das Ergebnis ihrer Spezifizierungsarbeit
a) weder als Simple bezeichnet werden kann und
b) auch nichts aber auch gar nichts mit Objekten zu tun hat.  ;D

http://www.oreillynet.com/cs/user/view/cs_msg/67476

--- Zitat ---SOAP Acronym


If you read the specification for SOAP 1.2 you will find out that the author is correct about stating that SOAP no longer is an acronym and does not stand for "Simple Object Access Protocol" any longer!
While some members in the W3C committee may have not liked the acronym because it was coined by Microsoft (Did you know that IBM at one point suggested "Service-oriented Architecture Protocol"?) there was also a realization that SOAP is (a) not about accessing objects and (b) that it may not be that simple after all. So SOAP is just SOAP ...

--- Ende Zitat ---

flaite:
Als SOAP Webservice Client benötigt man eigentlich nur:
- die Möglichkeit einen HTTP POST Request aufzubauen und gegen die URL des Webservices abzusetzen: (geht nicht mit LotusScript aber mit Java. Mit eingebundenen Microsoft Objekten geht das btw. auch in LotusScript. Manfred Dillmann hat das glaub ich so in seinem RSS-Reader gemacht -> http://www.madicon.de/news/)
- xml Generierung für ausgehende Nachricht (geht mit jeder Programmiersprache, die in der Lage ist Strings zusammenzufügen -> Lotus Formelsprache, LotusScript, Java, sogar JavaScript).
- xml Parsing für zurückgehende Nachricht (geht mit LotusScript seit Version 6, mit Java seit 5). Oder einer der brauch-keinen-xml-parser-geht-auch-mit-String-Verarbeitung-in-Lotus-Script Programmierer.

In der Realität sinnvolle Dinge sind noch:
- SSL (seit Domino 5)
- etwas zum möglichst generischen Kappseln des xml Parsings von der Business Logik, sprich ein xml-to-objects Bindings Framework wie JAXB oder ein Programmierer, der selbst ein solches Framework programmiert (hab das für POX in LotusScript gemacht und für SOAP in Java). Die Kombination SOAP und LotusScript ginge aber auch. 

HALTET XML PARSING AUS EURER BUSINESS LOGIK HERAUS.

Z.B. macht Julian Robichaux ähnliche Dinge auch relativ häufig mit Domino6.

flaite:
und wenn man übertriebenen Respekt vor Organisationen ablegt, die an einem Spezifizierungsgremium teilnehmen, das irgendwann nach Jahren feststellt, dass der Titel ihrer eigenen Spezifikation Simple Object Access Protocol kompletter Humbug ist, ist es noch nicht mal besonders schwierig.

m3:

--- Zitat von: umi am 18.04.07 - 13:30:20 ---Ich rate nicht von 7 ab.

Notes 8 steht aber schon vor der Tür (Q3/Q4 :-) bis zum Release)

--- Ende Zitat ---
Plus ein halbes Jahr bis zur .1 Release, ab kann kann man das Teil vermutlich sinnvoll einsetzten. ;)

Navigation

[0] Themen-Index

[*] Vorherige Sete