Domino 9 und frühere Versionen > ND6: Entwicklung
Zugriff auf Webservices
topsys:
hi,
irgendwie ärgere ich mich gerade darüber, das lotus notes (IBM) nicht in der lage ist, die zeichen der zeit zu verstehen und wenigstens ein workouround für eine lösung zum konsum von webservices (egal welcher programmiersprache und welcher plattform)herausbringt. oder binn ich einfach zu blöd.
ich möchte mich viel lieber mit connectoren beschäftigen.
irgendwie habe ich so das gefühl, ibm pusht zu sehr ihren websphere.
und ich kann kein java.
habe letztens eine vielleicht spannende alternative gesehen:
ich habe mir mal den neuen biztalk server (2004) angeschaut. sieht ganz vielversprechent aus. was mir ein wenig bauschmerzen bereitet, ist das es von microsoft ist.
aber sah seeeeehhhr interessant aus.
desweiteren habe ich mich wieder beruhigt und arbeite weiter an einem agent.
topsys
Axel_Janssen:
ich habs auch nicht leicht. ;)
--- Zitat von: topsys am 26.09.03 - 06:24:37 ---habe das mit dem soapconnector erstmal auf eis gelegt.
versuche es mal mit dem soap toolkit von microsoft.
1. versuch: notes webserviceanfrage und webservice auf einem PC, klappt.
2. versuch: webservice auf einem pc und webservice aufruf über einen Notes server (soaptoolkit inst.), klappt nicht. klappt es vielleicht, wenn ich den serviceaufruf in einen agent packe?
--- Ende Zitat ---
Punkt 1 ist hochinteressant. Dann dürfte vielleicht nur noch eine Kleinigkeit fehlen. Wo hast du das SOAP Toolkit installiert. Auf dem Notes-Server? Ist es auch auf dem Client installiert. Falls die Anwendung im Notes-Client (nicht Browser) läuft, bedenke, dass sowas wie QuerySave und auch Agenten, die user-getriggert sind, auf dem Client laufen. Das SOAP Toolkit muß also auf dem Client installiert sein. Was bekommst du für Fehlermeldungen?
Mein Problem, das SOAP Toolkit aus Notes zu nutzen, um einen Axis SOAP-RPC Webservice aufzurufen, besteht darin, dass Microsoft neben WSDL ein proprietäres Zusatzdeskriptions-File fordert. Name kommt morgen. Bin zu faul jetzt den Lapptop zu öffnen.
Wir implementieren derzeit den Client-Teil einfach ohne Toolkit. Wir erzeugen das vom Server erwartete XML und benutzen HTTPUrlConnection. S. unten. Ganz trivial ist das teilweise auch nicht. V.a. für Attachments. Funktioniert aber. Es gibt Meldungen über Instabilitäten für Java1.3.1. Bei uns geht es jetzt aber (noch nicht voll durchgetestet).
--- Zitat von: topsys am 26.09.03 - 06:24:37 --- zu 4. das mit dem tcp monitor ist vielleicht gar keine schlechte idee. habe auf der schnelle leider auf microsoft seite nichts vergeleichbares gefunden. wäre echt nett wenn du mir mal posten könntest, wie ich da dran komme ;)
--- Ende Zitat ---
Du mußt doch eine Serverkomponente installieren. Poste morgen wie das geht. Es geht.
--- Zitat von: topsys am 26.09.03 - 06:24:37 ---zu 3. was ist HTTPSocketConnections in java? ist das ein http get/post aufruf?
habe es auch mit dem http get probiert, habe aber dann erfahren das es ein bug in der version 6.0.2 cf1 gibt. http get funktioniert dort nicht, war echt toll.
--- Ende Zitat ---
nö. wieso? funktioniert. HttpUrlConnection implementiert sowohl http-get als auch post. Die Header-Felder kann man auch setzen. Vermutlich hast du noch firewall-Probleme. Neben meiner am Freitag gepostete Lösung gibt es noch weitere. Unser Webservice läuft im Intranet. Da gibt es keine Firewall.
--- Zitat von: topsys am 26.09.03 - 06:24:37 ---die beispiel db´s aus der "the view" sahen ganz gut aus, leider fehlt mir aber der text dazu.
hast du die beispiele schon einmal ausprobiert?
--- Ende Zitat ---
Ich hab wie gesagt das Problem mit den proprietären Zusatzdateien, die von Microsoft SOAP Toolkit erwartet werden. Ich könnte die wohl auch von Hand erzeugen und auf den Axis-Tomcat stellen. Weiß aber nicht wie ich das von Hand machen soll. Interoperabilität von Webservices ist nach wie vor nicht einfach zu lösen.
--- Zitat von: topsys am 26.09.03 - 06:24:37 ---irgendwie ärgere ich mich gerade darüber, das lotus notes (IBM) nicht in der lage ist, die zeichen der zeit zu verstehen und wenigstens ein workouround für eine lösung zum konsum von webservices (egal welcher programmiersprache und welcher plattform)herausbringt. oder binn ich einfach zu blöd.
--- Ende Zitat ---
Das ist trotz aller Hochglanzbroschüren nach wie vor eine n.e.u.e T.e.c.h.n.o.l.o.g.i.e. Da sind selbst auf dem Spezifikationen-Level viele Sachen noch nicht geklärt. Dies betrifft scheinbar v.a. das Thema Interoperationalität von Webservices. IBM hat diese Woche ein neues Toolkit herausgebracht. Vielleicht ist da was dabei.
Das Problem von LotusDomino ist eben, daß es eine historisch gewachsene Plattform mit Altlasten ist. Selbst für Java-Toolkits muß man XML4J.jar ersetzen. Hat irgendwas mit der internen Folge des Class-Loadings von Java Paketen zu tun. Das ist nie ein triviales Problem. In Java gibt es seit 2001, angekündigt 2000 mit JAXP eine standardisierte Lösung, wo man gegen Standard-Interfaces programmiert und den Parser und die xslt-engine immer problemlos austauschen kann. Die fixen Nasenbären von IRIS haben natürlich ganz schnell xml implementiert. Die brauchten sie v.a. für diese tollen irsinnig praxisrelevanten Äpflets in Domino5. Das war bevor es JAXP gab. Viel code geht eben geben diese proprietären IRIS-Java libraries. Und austauschen wollen sie es wohl auch nicht. Ich vermute das IBM kein Geld für Doppelt- Entwicklungen für JAXP (das von Sun, IBM, openSource, Oracle, SAP, BEA, Peoplesoft, 10.000 weiteren Unternehmen, sämtlichen Universitäten, 98% aller Java-Programmierern inklusive mir benutzt wird) und IRIS-Java-für-xml ausgibt. Lotus hat damals den source code dem apache.xml openSource Projekt übergeben. Normalerweise macht man das, damit im openSource Projekt billig neues entwickelt wird, das man selber nutzt. IRIS macht es anders. Die erzählen in Redbooks, dass sie den anfänglichen source code von apache.xml.xerces und apache.xml. xalan erstellt haben. Sehen dann aber keine Notwendigkeit die gratis Weiterentwicklungen im open Source Projekt in ihr Produkt zu integrieren. Warum weiss ich nicht. Normal ist das nicht. ;D
Das Problem ist aus meiner Sicht IRIS. Bei IRIS ist die Gleichgültigkeit gegenüber der s.a.u.b.e.r.e.n Implementierung von Standards Bestandteil der Firmenkultur. Das ist die Wurzel aller meiner Bedenken gegenüber LotusDomino. Der Vorteil von Websphere besteht darin, dass IBM es sich nicht leisten kann, Standards zu missachten, weil sonst die Kunden zu Oracle oder zu BEA überlaufen.
--- Zitat von: topsys am 26.09.03 - 06:24:37 ---ich möchte mich viel lieber mit connectoren beschäftigen.
--- Ende Zitat ---
Was ist das ???
--- Zitat von: topsys am 26.09.03 - 06:24:37 ---irgendwie habe ich so das gefühl, ibm pusht zu sehr ihren websphere.
und ich kann kein java.
--- Ende Zitat ---
Wie gesagt: Ich glaube IBM würde liebend gerne ein vernünftiges Toolkit für Domino-Webservices auf den Markt werfen. Glaub aber nicht, dass das bei Domino wirklich so einfach ist.
Die haben ja auch z.B. bis heute kein vernünftiges Multi-Thredading für Web-Agenten. Sowas gehört IMHO seit 1996 zur Grundausstattung eines Webservers.
Websphere/J2EE ist eben eine durchdachte, neue, objektorientierte, erweiterbare Plattform. Genau deshalb ist es einfacher, dort Fortschritt zu implementieren.
--- Zitat von: topsys am 26.09.03 - 06:24:37 ---habe letztens eine vielleicht spannende alternative gesehen:
ich habe mir mal den neuen biztalk server (2004) angeschaut. sieht ganz vielversprechent aus. was mir ein wenig bauschmerzen bereitet, ist das es von microsoft ist.
aber sah seeeeehhhr interessant aus.
--- Ende Zitat ---
Gute Idee. Ich finde ärgerlicherweise nicht die Zeit mich mal wirklich intensiv mit MS.NET und den ganzen Servern zu beschäftigen. Ich sehe seit einiger Zeit IBM als genau so einen Konzern wie Microsoft. Das letzte mal, dass die mir was geschenkt haben war eine Süssigkeitentüte auf einer Weihnachtsfeier als 6-jähriger, weil mein Vater da beschäftigt war.
Emotional bin ich auf der Seite von openSource und vielleicht SUN. Wobei. Wenn du da in den source code von Apache Java Projekten schaust, da lachen dir soviel email-Adressen von IBM und Oracle Entwicklern entgegen. ;D
Ich hab in den letzten Jahren einige Sachen von .NET Umsteigern von Java mitgekriegt. Sooo ganz das Gelbe ist das auch nicht. Ohne irgendwelche selbstgeschriebenen COM-Zusatzklassen wird man da angeblich auch nicht glücklich. Ich will nächstes Jahr beides machen. Für viele Aufgabenstellungen ist das IMHO eine sehr gute Plattform und diese ganzen schlecht dokumentierten openSource packages sind auf die Dauer auch nicht gut für meine Gesundheit.
Die .NET-Programmiersprachen sind aber ziemlich Java-ähnlich. Ohne jetzt von C# anzufangen, aber es wird gesagt, dass VB.NET mehr ein Java mit funny Syntax als VB.6 ist. Aber vielleicht bin ich da auch beeinflußt von Java-Propaganda.
Gruß Axel
letztlich baust du da ja eine systemübergreifende Integration auf. Früher gab es dafür CORBA und das galt als mega-guru. Bin in dem Projekt zusammen mit 2 erfahrenen Java-Programmierern und 1 guten C-Programmierer und zur Zeit machen wir 95% in Java. Und obwohl Notes angeblich Java kann, müssen wir selbst bei Domino6 ziemlich low-level gehen (einfach weil wir diesen XML4J.jar-Tausch dem Kunden nicht zumuten wollen und können).
Im Attachment noch ein bischen Text zu HTTP-URL-Connection aus einem alten Sun-Tutorial, das ich bei Sun nicht mehr finden konnte. Der 2. Teil behandelt HTTP-Post. Dein Problem ist die Firewall.
Meine am Freitag gepostete Lösung im Java für Anfänger ist nämlich leider keine. Es gibt aber workarounds. Kann das aber erst am Montag testen, weil bei mir im Wohnzimmer gibts keine Firewall. Werde ich in den Thread Java für Anfänger stellen.
topsys:
Hi.
Mein Problem ist es, einen Webservice zu konsumieren, der auf einem Server läuft (ich kann ja nicht bei ca. 2000 Anwendern das SoapToolkit installieren). ???
Da scheint es noch keine brauchbare Lösung zu geben. Der SoapConnector konsumiert nur Webservices mit Soap-RPC. Ich weiss nicht ob das mit bei Microsoft Webservices funktioniert?! Das schein auch mein problem zu sein. Na ja muss mal schauen. Anscheinend gibt es keinen der serverbasiert in lotus notes einen ms webservice über soap konsumieren kann. :'(
--- Zitat von: Axel_Janssen am 28.09.03 - 02:15:47 ---Punkt 1 ist hochinteressant. Dann dürfte vielleicht nur noch eine Kleinigkeit fehlen. Wo hast du das SOAP Toolkit installiert. Auf dem Notes-Server? Ist es auch auf dem Client installiert. Falls die Anwendung im Notes-Client (nicht Browser) läuft, bedenke, dass sowas wie QuerySave und auch Agenten, die user-getriggert sind, auf dem Client laufen. Das SOAP Toolkit muß also auf dem Client installiert sein. Was bekommst du für Fehlermeldungen?
--- Ende Zitat ---
Habe ich das Soap-Toolkitt auf beiden (Server & Client) installiert kommt die Meldung: No Resume, wenn ich das Soap-Toolkitt nur auf dem Server installiert habe kommt die Fehlermeldung: Cannot Create Automation Object (kann mit dem Soap aufruf nichts anfangen).
Anscheinend kommt mann nicht darum herum auf dem Client das Soap Toolkit zu installieren!!!
--- Zitat von: Axel_Janssen am 28.09.03 - 02:15:47 ---Mein Problem, das SOAP Toolkit aus Notes zu nutzen, um einen Axis SOAP-RPC Webservice aufzurufen, besteht darin, dass Microsoft neben WSDL ein proprietäres Zusatzdeskriptions-File fordert. Name kommt morgen. Bin zu faul jetzt den Lapptop zu öffnen.
--- Ende Zitat ---
Meinst du "Disco"?
--- Zitat von: Axel_Janssen am 28.09.03 - 02:15:47 ---nö. wieso? funktioniert. HttpUrlConnection implementiert sowohl http-get als auch post. Die Header-Felder kann man auch setzen. Vermutlich hast du noch firewall-Probleme. Neben meiner am Freitag gepostete Lösung gibt es noch weitere. Unser Webservice läuft im Intranet. Da gibt es keine Firewall.
--- Ende Zitat ---
bei mir auch nicht
"ich möchte mich viel lieber mit connectoren beschäftigen."
Was ist das ???
RE: meine damit, webservices anzunehemen und weiter zu verarbeiten
Denke mal darüber nach erstmal mit einer xml datei zu arbeiten, die ich von der c# anwendung erzeuge und dann in domino einlese.
bis bald,
bleibe aber am ball
topsys
Axel Janssen temp:
--- Zitat von: topsys am 02.10.03 - 06:43:59 ---Mein Problem ist es, einen Webservice zu konsumieren, der auf einem Server läuft (ich kann ja nicht bei ca. 2000 Anwendern das SoapToolkit installieren). ???
Da scheint es noch keine brauchbare Lösung zu geben.
--- Ende Zitat ---
Mit Domino lässt sich mit Tricks sicher erreichen, dass der Agent auf dem Server läuft.
- Vielleicht läßt sich etwas mit Agent.RunOnServer auf Domino Seite erreichen.
- Wie gut kennst du dich damit aus, wenn ein Agent auf dem Server läuft und wann auf dem client? Bei entsprechenden Kenntnissen lässt sich da mit Tricks oft etwas machen.
--- Zitat von: topsys am 02.10.03 - 06:43:59 ---Der SoapConnector konsumiert nur Webservices mit Soap-RPC.
Ich weiss nicht ob das mit bei Microsoft Webservices funktioniert?! Das schein auch mein problem zu sein. Na ja muss mal schauen.
--- Ende Zitat ---
Das Soap Toolkit unterstützt auf jeden Fall SOAP-RPC. Ich glaube er unterstütz beides: Dokument-basiert und SOAP-RPC.
--- Zitat von: topsys am 02.10.03 - 06:43:59 ---Habe ich das Soap-Toolkitt auf beiden (Server & Client) installiert kommt die Meldung: No Resume, wenn ich das Soap-Toolkitt nur auf dem Server installiert habe kommt die Fehlermeldung: Cannot Create Automation Object (kann mit dem Soap aufruf nichts anfangen).
--- Ende Zitat ---
Das hat vermutlich etwas mit fehlenden WSML files zu tun. Diese Files scheinen Toolkit3.0 spezifisch zu sein. Ich habe den starken Verdacht, dass es diese WSML-Files in Version 2.0 des Toolkit noch nicht gab (die Beispiele aus theView basieren auf dieser 2.0er Version. Ich bin mir relativ sicher, dass es diese WSML Files für MS.NET Webservices nicht gibt. Nur im Toolkit, das ja nicht für .NET sondern für VB.Classic, VC++.Classic da ist. Diese Fehlermeldungen kenne ich sehr gut.
--- Zitat von: topsys am 02.10.03 - 06:43:59 ---Meinst du "Disco"?
--- Ende Zitat ---
nein. WSML.
--- Zitat von: topsys am 02.10.03 - 06:43:59 ---"ich möchte mich viel lieber mit connectoren beschäftigen."
Was ist das ???
RE: meine damit, webservices anzunehemen und weiter zu verarbeiten
--- Ende Zitat ---
Also business-logic. Tja. Kommt mir irgendwie sehr bekannt vor. Bei Enterprise Java Beans wurde auch versprochen, dass programmatisch komplexe Dienste wie Pooling, Transaction, Security, Object Relational Mapping, Datenbank Integrität/Performance uvam von EJB transparent und einfach zu benutzen geliefert wird und sich der Anwendungsentwickler eben auf die Anwendungsentwicklung und nicht um low-level Zeug (wie z.B. hier SOAP-Kommunikation) kümmern braucht.
Das stimmt bisher noch nicht. Meine Erfahrung besagt, dass man schon wissen muß, was unter der Haube geschieht, um es sinnvoll nützen zu können (gilt für Webservices und EJB, bei EJB v.a. auch für Beachtung nicht-funktionaler requirements wie Performance). Vermutlich wird sich das irgendwann ändern. Und nach der EJB-Erfahrung kann mich nix mehr schocken, wie genau ich das wissen muß.
--- Zitat von: topsys am 02.10.03 - 06:43:59 ---Denke mal darüber nach erstmal mit einer xml datei zu arbeiten, die ich von der c# anwendung erzeuge und dann in domino einlese.
--- Ende Zitat ---
Das ist sicher erst einmal ein akzeptabler workaround.
topsys
Wir benutzen nun für alles Java: Dokumentbasiert und RPC. Das klappt soweit. Eine wichtige Funktionalität ist mehr batch-mässig. Und da schreibt Domino erstmal files raus, die über ein geschedultes Java Programm an den Webservice dokumentenbasiert mit SAAJ übertragen werden.
Die RPC calls müssen aus dem Domino client laufen und da erzeugen wir die SOAP Messages inklusive Connection mit dem SOAP-Server (auf Tomcat) per Hand. Den entsprechenden code werde ich auf keinen Fall rausgeben (sorry), obwohl er weitgehend von mir ist (bin hier eben angestellt).
Ich halte Webservices für eine vielversprechende Technologie für Integration von Anwendungen (bin nicht der erste der das sagt).
Vielleicht findest du was mit google. Weil eigentlich muß es da Möglichkeiten geben. Das SOAP Toolkit 3.0 lässt sich in Domino integrieren und die Server sind auch Microsoft (wenn auch .net).
Hab gehört, dass bei der Interoperability C#/Java noch eine Reihe von Dingen noch nicht geklärt sind. Wenn ich richtig verstanden habe, auch so einfache Dinge wie Kompatibilität von mit Webservices übertragenen Objekten, die etwas komplexer sind (z.B. HashMaps).
Deshalb und weil wir besser in Java sind lassen wir für dieses Projekt die Finger von Microsoft. Halte da aber die Augen offen, weil die Integration zwischen Java und Net/MS-Classic ist sicher ein interessanter Anwendungsfall. IBM und Microsoft arbeiten da auch an Inititativen.
Gruß Axel
Navigation
[0] Themen-Index
[*] Vorherige Sete
Zur normalen Ansicht wechseln