HELP: Re-Design der Webservices

[flaite]

Am besten wäre es, wenn der Webservice Producer den Authentification Header auslesen könnte. Da wird ja sowieso schon der Username hochgeschickt. Man könnte dann den Webservice für User in der Gruppe WebServiceUsers freigeben oder so.
Mit ClientCert SSL sollte das sogar wirklich sicher sein, wenn das irgendwie geht.

[eknori]

hmm, wüsste jetzt nicht, wie ich das machen kann. Ich als producer lese ja den request nur insofern aus, als ich sage: " Du willst die und die Infos ? OK, dann gib mir mal den Namen des Supporters , ( und zur Berechtigungsprüfung deinen Usernamen ) . Dann kann ich anhand des Usernamens hergehen und nachschauen, ob du das überhaupt angezeigt bekommst"

Das eine ist ja, ob jemand überhaupt auf den Service zugreifen darf; das andere, welche Informationen er bekommt. Die Info, wer da klopft, muß aber imho im request übermittelt werden ...

[flaite]

Wie es momentan ist, wird Hein Bloed in dem xml-File, dass der Webservice verarbeitet mitgeschickt. Base 64 encoded im Header. Bei jedem Request.
Ich weiss aber auch nicht, ob es auf Lotus Seite Methoden gibt, um das auszulesen.
Es ist auf jeden Fall da.
Das Axis Projekt hat eine Art Proxy, in dem man anzeigen kann was tatsächlich ausgetauscht wird. Ich versuche das mal dazwischen zu klinken. Dann wird das klarer. Das Tool ist sowieso sinnvoll.

Gruß Axel

[flaite]

Keine Ahnung wie ich das Clientseitig einsetzen kann.

[eknori]

Bei jedem Request.
Ich weiss aber auch nicht, ob es auf Lotus Seite Methoden gibt, um das auszulesen.

Auf Producer Seite sehe ich da momentan nicht, daß man da irgendwie drankommt ... Aber schaun' mer mal

[flaite]

Wenn du lust hast kannst du das mal ausprobieren....
1. Schritt: axis-bin-1_3.zip  hier downloaden (http://apache.easy-webs.de/ws/axis/1_3/)
2. Schritt: entpacken
3. Schritt: Das unten angehängte .txt in .bat umbenennen und in den axis-1_3 folder des entpackten tun.

Das startet einen tcpMonitor, der anzeigt was wirklich übertragen wird.
Soweit ich weiss, müsste das angezeigt werden, wenn ich den Webservice dann auf Port 24000 anspreche (s. angehängte Datei).

[eknori]

OK, werde ich probieren.

wg. wiki: habe das auf meiner Webseite installiert .. mediawiki ... what a crap... frisst mir meinen Speicherplatz für die MySQL DB schon bei der Installation auf.
Meine komplette Webseite www.eknori.de kam mit SQL DB bis her mit 640 Kb aus. Mediawiki hat, ohne einen einzigen Eintrag getätigt zu haben schon 5 MB geschluckt.

Entweder nehme ich das wiki von OpenNTF und schmeisse das auf meinen Server atHome , oder ich klöppele morgen noch eine kleine ubuntu Kiste zusammen und bringe die über DSL an den Draht ...

[flaite]

Ich amüsiere mich momentan sowieso damit, meiner most brilliant Swing Konstruktion eine Funktion nach der anderen zu entreissen. Swing find ich momentan wirklich ein bischen verrückt, aber interessant. Wäre schön, wenn da mal jemand drüberschauen könnte, wenn ich das auf sourceforge bringe. Wenn ich Scottie Delap nicht als Richtschnur hätte, wäre das schon längst im Chaos geendet.

Gruß Axel

[flaite]

lass dir ruhig Zeit 

[flaite]

Vielleicht eine blöde Idee.
Aber könnten wir uns nicht vielleicht überlegen, die Design-Disussion in german-english zu führen?
Da sich ja einige cracks der Domino Community mit Webservices und Service Oriented Architecture auseinandersetzen, bekommen wir so vielleicht interessante Bonus-Beiträge.
Einen ernsthaften Webservice Layer für eine reale und relativ komplexe Notes Anwendung zu designen und zu implementieren könnte einige Leute zu konstruktiver Mitarbeit bewegen

Gruß Axel

[eknori]

hmm, bei Bedarf kann ich auch auf us-gb-en umschalten. Die Erfahrung durch die Resonanz auf !!HELP!! im ausser-europäischen Raum lassen mich leider daran zweifeln, daß sich irgendein citizen from abroard convincen lässt, einen benefit zu unserer discussion beizusteuern.

Ich fände es ergiebiger, wenn wir die Diskussion weiterhin in de führen und sich noch ein paar mehr Leute auf die producer und consumer Seite schlagen.

Wie sagte schon Bill Buchan im neuesten podcast von TakingNotes: " Take this 15 seconds it needs to learn how web services are working ... "

die producer Seite zu bedienen ist ebenso einfach, wie einen Agenten in script oder Java zu schreiben ... Also genau das, was ein Entwicker Tag für Tag tut.

Die consumer Seite ist da schon eindeutig schwieriger. ( zumindest für jemanden, der sich nicht tagtäglich damit beschäftigt ).

Evtl. ermutigt die bereits von euch ( Mark und Axel ) geleistete Arbeit, den einen oder anderen sich auch mit dem Thema zu beschäftigen. Möglicherweise kommt noch jemand mit einem .NET Client oder einer Lösung in PHP oder PERL dazu.

Konzeptionell muessen wir allerdings nun hingehen und über USE Cases die Services neu definieren.
Wie Axel ja schon erwähnt hat, ist das bisher zusammen geklöppelte eine Lösung, die zwar funktioniert, aber eher als proof-of-concept zu bezeichnen ist.

Mitlerweile habe ich nach dem heutigen Totalausfall meines heimischen Servers ein "neues" Serverlein gebastelt. Morgen werde ich dann das Wiki auf bewährter Domino Basis installieren und den Link hier posten.

[TMC]

wg. wiki: habe das auf meiner Webseite installiert .. mediawiki ... what a crap... frisst mir meinen Speicherplatz für die MySQL DB schon bei der Installation auf.
Meine komplette Webseite www.eknori.de kam mit SQL DB bis her mit 640 Kb aus. Mediawiki hat, ohne einen einzigen Eintrag getätigt zu haben schon 5 MB geschluckt.

Wie hast Du denn das geschafft?
Frische MediaWiki-Installation bei mir gute 700kB im MySQL Data Directory, gezippt knappe 200k. Hab erst kürzlich wieder so ein Teil aufgesetzt.
Danach speichert ein Wiki ja immer mehr Daten als ein CMS, wegen der Änderungen...
Aber who cares wegen ein paar MBs?

M.E. ist MediaWiki erste Wahl unter den ganzen Wikis, wobei ich http://wiki.splitbrain.org/wiki:dokuwiki schicker finde, aber der nimmt leider keine Datenbank sondern speichert in Textfiles 
Viele andere Wikis sind ein Graus im Bezug auf Accessibility, Tabellen, Tabellen, Tabellen, und das zu Positionierung (!) in der heutigen Zeit 

Wegen EN/DE in Eurem Projekt:
Will mich nicht einmischen, aber ich denke dass eine Discussion auf Englisch sicherlich sehr förderlich sein würde. IMHO würden sich durchaus einige Leute beteiligen, nicht nur von der Domino Blogsphere, man müsste das nur entsprechend publik machen.

[flaite]

Ich denke wir können das erstmal mit eigenen Kräften machen.
So schwierig erscheint es erstmal nicht zu sein.
Besondere Fragen kann man ja auch auf notes.net aka developerworks/lotus posten. 
Die Zugänglichkeit wird jedenfall sehr einfach sein. Dafür sorgen wir.
Mein (und möglicherweise Mark sein) Java Code können ab nächste Woche per cvs von Sourceforge in Eclipse geladen werden. Das ist wirklich sehr einfach und ich werds beschreiben.
Für die Design-Diskussionen gibts einen Wiki und HELP selbst gibts von openNTF.org.
Leute, die sich ein bischen auch meinen Code anschauen sind natürlich sehr willkommen.

Denkt dran: Die Chancen besonders peinliche bugs zu finden, sind gerade am Anfang sehr groß. Z.B. habe ich eben ca. 1 Stunde gebraucht, um einen absoluten Klassiker-Bug.
Für Java-Freunde: equals nicht überschrieben in einem Objekt, dessen Identität eindeutig an ein id-Feld im Objekt gebunden ist.

Zur Motivation: Ist zwar völlig i. O. Anfängerfragen zu beantworten, nur bringt ein solches Projekt vielleicht in bestimmten Bereichen ein größeres ROI an Wissen.

Architekturen mit lose gekoppelten Anwendungen (und nix anderes ist das hier) ist ein Kernthema von Enterprise Application Integration (EAI). Solche Messaging Infrastrukturen sind nicht nur für Webservices interessant sondern können auch auf Basis von Websphere MQ und ähnlichem oder Ralfs AS 400 Tricks (das DB2.Trigger-> PushData -> Domino von letzter Woche) aufgesetzt werden. 

V.a. sollte niemand von der Beteiligung an der Design-Diskussion abgeschreckt werden, nur weil er die entsprechende Literatur nicht gelesen hat. Ich les das zwar, vergess aber immer eine Menge. Der Planungs-Prozess ist sicher kein Hexenwerk und man kann das lernen. Wir haben hier ein konkretes Projekt.

Die Entwicklung von Lotus 7 zeigt imho, dass der Umfang an Funktionen in klassischen Domino-Feldern nicht besonders stark zugenommen hat. Die neuen Features (v.a. Webservices und die DB2 Integration) befinden sich eindeutig in Bereichen der Integration von Domino mit anderen Anwendungen. Man kann das natürlich bis zum nächsten Eintreffen von baby jeebus auf diesem Planeten mit csv-Dateien durchführen. Nur hab ich z.B. letztes Jahr in einen Projekt eindeutig die Vorteile eines Zusammenspiels mit Websphere MQ kennengelernt (weniger Probleme, aktuellere Daten). Webservices ist so ähnlich. 
Die stärkere Gewichtung von Integration setzte imho schon in R6 mit dem deutlich verbesserten xml-support ein. Sie wird mit Hannover zunehmen.
In diesen Integrationsbereichen bestehen imho auch Chancen für Projekte.

Es soll jedenfalls keiner von der Teilnahme abgeschreckt werden, nur weil er bestimmte Begriffe nicht kennt.
 
Gruß Axel