HELP: Re-Design der Webservices

[flaite]

Hi,

bisher sehe ich die gesamten Aktivitäten eher als Technologie Test an. Die waren weitgehend erstmal erfolgreich. Was aus meiner Sicht wichtig & sinnvoll wäre ist, mit Hilfe einer Anwendungsfall-Analyse erst einmal herauszufinden, welche Service wie angeboten werden sollen.
Das soll nicht in einer Meta-Diskussion enden. Und ich halte Anwendungsfall-Analysen für eine gute Sache, die man nicht Accenture oder IBM Global Services Consultants überlassen muß.

Am besten würde sich imho ein Wiki eignen, um die Analyse gemeinsam durchzuführen. Wir hatten einen für Anti-Patterns. Der wurde leider wieder abgeschaltet. 

Auch wenn kein Wiki da ist, kann ich damit morgen mal anfangen. Dafür werde ich dann (endlich) HELP installieren.

[eknori]

sich imho ein Wiki eignen

kann ich am WE installieren.

[flaite]

Halt ich für eine gute Idee.
Seh das so:
1. Wir haben festgestellt, dass - solange man auf SOAP-RCP - d.h. ohne eigene xml-Programmierung - bleibt, stellen Webservices keine großen Programmieranforderungen. Serverseitig auf Notes ist das sehr ähnlich wie Agenten programmieren und auf allen Client-Plattformen gibt es Generatoren.
2. Vernünftige Kommunikationsinterfaces zu schreiben ist aber nicht so einfach. Und das soll über eine solche Methode erruiert werden.
3. Genau dann, wenn wir anfangen, die Services realitätsnäher zu gestalten, werden einige Herausforderungen auftauchen. Z.B. die Implementierung der Security in den Clients.
4. Wenn wir in der Realität einsetzbare Webservices Clients, die ein umfangreiches Angebot an Funktionen anbieten, haben wir wirklich etwas geleistet.

Gruß Axel

[Mark³]

die Implementierung der Sicherheit scheint sehr einfach zu sein

http://www-10.lotus.com/ldd/nd6forum.nsf/DateAllThreadedweb/07e5178f145f85d68525709d00331d40?OpenDocument

[eknori]

Das können wir ja am WE einmal testen.

[Mark³]

der Beispielcode scheint die Implementierung in Microsoft VB oder so zu sein. In Java muss scheinbar nur dem Web Service Stub folgendes mitgeteilt werden:

Code

stub._setProperty(
          javax.xml.rpc.Stub.USERNAME_PROPERTY,
            username);
stub._setProperty(
          javax.xml.rpc.Stub.PASSWORD_PROPERTY,
            password);

Vielleicht kannst du auf deinem Server Basic Authentication einrichten (oder ist es bereits an?) und mir einen User mit Passwort zukommen lassen, so dass ich das mal testen kann? Bleibt nur die Frage, wie ich sehe, ob es klappt. Vielleicht baust du eine Methode ein, die irgendwo session.username o. ä. zurückliefert?

Natürlich ist dies keine Implementierung von

Sicherheit

wie ich so lax sagte sondern nur die Anmeldung am Server. Zusätzlich müsste dann noch SSL genutzt werden. Ein Hinweis, wie das auf der Client-Seite implementiert wird findet sich hier am Ende: http://www.jeckle.de/secureSOAP.html

[Mark³]

hier ist ein Beispiel für die Implementierung:

Code

package mutualauthclient;

import javax.xml.rpc.Stub;

public class HelloClient {

    public static void main(String[] args) {
    
        if (args.length !=5) {
          System.out.println("HelloClient Error: Need 5
        runtime arguments!");
          System.exit(1);
        }
        
        String keyStore=args[0];
        String keyStorePassword=args[1];
        String trustStore=args[2];
        String trustStorePassword=args[3];
        String endpointAddress=args[4];


      // print to display for verification purposes
        System.out.println("keystore: " + keyStore);
        System.out.println("keystorePassword: " +
        keyStorePassword);
        System.out.println("trustStore: " + trustStore);
        System.out.println("trustStorePassword: " +
        trustStorePassword);
        System.out.println("Endpoint address: " +
        endpointAddress);

    try {
      Stub stub = createProxy();
      System.setProperty("javax.net.ssl.keyStore",
        keyStore);
      System.setProperty("javax.net.ssl.keyStorePassword",
        keyStorePassword);
      System.setProperty("javax.net.ssl.trustStore",
        trustStore);
      System.setProperty("javax.net.ssl.trustStorePassword",
        trustStorePassword);
      stub._setProperty(
          javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,
            endpointAddress);

      HelloIF hello = (HelloIF)stub;
      System.out.println(hello.sayHello("Duke! (        secure!"));
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }    

    private static Stub createProxy() {
        // Note: MyHelloService_Impl is implementation-specific.
        return (Stub)(new
          MySecureHelloService_Impl().getHelloIFPort());
    }
} 

_{Quelle: Kapitel 27 in http://www.ti5.tu-harburg.de/manual/Java/j2ee-tutorial-1.4/doc/}

[Mark³]

scheint zu klappen 
User 'username' gibt es wohl nicht bei dir...

Code

AxisFault
 faultCode: {http://xml.apache.org/axis/}HTTP
 faultSubcode: 
 faultString: (401)Unauthorized
 faultActor: 
 faultNode: 
 faultDetail: 
	{}:return code:  401
<html>
<head>
<title>Error</title></head>
<body text="#000000">
<h1>Error 401</h1>User not authenticated</body>
</html>

	{http://xml.apache.org/axis/}HttpErrorCode:401

(401)Unauthorized

[eknori]

dann versuche es mal mit

Hein Bloed
blauerBaer

[flaite]

Kannst du bitte mal in die Methode GETALLTICKETSBYUSER ein print session.getUsername eingeben. Dann könnten wir sehen ob das tatsächlich funktioniert.

[flaite]

Ich bekomme auch mit dem User, Password ein 401 zurück.

[eknori]

Habe gerade in die Class Ticket noch ein Public AuthUser As String eingebaut; darin ist dann s.UserName.

Zumindest beim WebServices Studio hat es fun ktioniert, da musste ich UserName und PWD eingeben.

[eknori]

Der RückgabeWert ist aber immer der Servername; klar, der fürht ja auch den Agenten / Service aus ...

[Mark³]

die Anmeldung scheint zu klappen, ich muss nun aber meinen Webservice Proxy neu generieren lassen...

[flaite]

Sieht bei mir auch so aus:

Code

3203 [main.300] ERROR de.atnotes.help.wsclient.domain.BasicTicketsRepository .loadNewTicketsBySupporter - loadNewTicketsBySupporter(String)
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode: 
 faultString: org.xml.sax.SAXException: Invalid element in de.atnotes.help.wsclient.ws.TICKET - AUTHUSER
 faultActor: 
 faultNode: 
 faultDetail: 

Kriegst du sowas auch?

Ich hab das in diesem Constructor der generierten Klassen eingefügt:

Code

public DominoSoapBindingStub(javax.xml.rpc.Service service) throws org.apache.axis.AxisFault {
    	super._setProperty(
    	          javax.xml.rpc.Stub.USERNAME_PROPERTY,
    	            "Hein Bloed");
    	super._setProperty(
    	          javax.xml.rpc.Stub.PASSWORD_PROPERTY,
    	            "blauerBaer");

[flaite]

Läuft nach Regenerierung der Client-Stubs. 

[Mark³]

getAUTHUSER() liefert mir nix zurück 
Sonst klappt dat alles.

[eknori]

Huch, so viele neue Tickets  . Übrigens kümmert das die BB Simulation herzlich wenig, daß man sich authentifizieren muss; Da wird gnadenlos alles zurückgeliefert, was angefragt wird ...

[flaite]

Damit können wir aber lediglich den Transportweg sichern (wenn wir auf ssl gehen, ist das ja sicher).
Es gibt aber noch weiteres.
Ein User hat (vielleicht) nicht das Recht, alle Tickets zu sehen.
Oder Assigns zu machen.
Oder Todos für alle Tickets erstellen.
Das ist glaub ich ein bischen schwieriger.
Aber dazu später.
Das war schon mal ziemlich gut.

Axel

[eknori]

Bisher wird ja im Request noch nichts an Informationen mitgegeben, wer denn da requested. Wenn das übermittelt wird, sollte es Producer seitig nicht allzu schwer sein, festzustelen, ob der ümmel denn auch die angeforderten Informationen als Response bekommen darf ...