Corba Tutorial

  • Hier ist auch noch ein RMI-Tutorial, obwohl das eigentlich nicht nötig wäre...:D


    Das unexportObject vor dem rebind bringt aber nichts, das sollte wohl eher ein new MyRemoteObjectImpl(...) sein. unexportObject liefert übrigens einen boolean-Wert zurück, der angedeutete cast ist eher beim Client hilfreich.

  • Müssen wirklich alle Objekte die über RMI übergeben werden Serializable implementieren? Ich habe das weder bei der Übung noch bei den Beispielen die ich als Übung für den Test geschrieben habe gemacht und es hat dennoch funktioniert.

  • beim erstellen eines neuen seminars im srs hab ich irgendwie ne andere vorgehensweise... weiß nicht ob das irgendwie falscher is als das andere, dem bot hats jedenfalls gefallen:


    createdSem = new SeminarImpl(seminarID, name, lecturer, places);
    poa.activate_object(createdSem);
    seminars[numSeminars] = createdSem._this(orb);
    numSeminars++;


    statt:


    semObject = poa.servant_to_reference(sem);
    BaseSeminar bSem = BaseSeminarHelper.narrow(semObject);
    bSems.add(bSem);

    Es genügt nicht, keine Meinung zu haben. Man muss auch unfähig sein, sie auszudrücken. Karl Kraus

  • Hier ist auch noch ein RMI-Tutorial, obwohl das eigentlich nicht nötig wäre...:D


    noch ein paar details die vielleicht bzgl UnicastRemoteObject anzumerken wären:


    Die im tutorial gezeigte möglichkeit funktioniert _nur_ wenn das RemoteObject (z.B. FileManagerImpl) die klasse UnicastRemoteObject erweitert und im konstruktor den superkonstruktor aufruft. dieser konstruktor exportiert nämlich das remoteobject automatisch.

    Zitat von JavaDoc


    Creates and exports a new UnicastRemoteObject object using an anonymous port.


    erst dann ist es möglich einfach mittels Naming.rebind(name, remoteObject) das objekt an den nameserver zu binden.


    edit: noch eine bemerkung zu unexport: der zweite parameter (boolean false) gibt an ob das objekt gleich entfernt werden soll (bestehende verbindungen und methodenaufrufe werden beendet) oder ob gewartet werden soll, bis alle verbindungen getrennt wurden. afaik hat beim lab beides funktioniert...


    mfg
    stefan

  • bzgl seminar erstellen, mein code sieht so aus:

    Code
    1. SeminarImpl semi = new SeminarImpl(seminarID, name, lecturer, places);
    2. Seminar s = (Seminar)semi._this(mOrb);


    das _this sollte das selbe automatisch machen, wie das was im pdf steht.

    concealer
    bei deinem code müsstest du sogar das activate_object weglassen können.
    zumindest hat bei mir ebenfalls alles funktioniert.

  • ich hab lab5+6 nicht gemacht, daher kenn ich mich bei der Struktur des ganzen seminar-dings nicht aus. daher eine ganz allgemeine frage für ein einfaches Corba-Beispiel.


    Versteh ich das richtig???:


    - irgendwo auf einem Server ist ein Programm-System, dass zB MyProgramm heisst.


    - um als client über corba auf mit diesem MyProgramm arbeiten zu können, brauch ich das interface dazu. das kann über das idl-file generiert werden (mit all seinen anderen klassen).
    mit dem Bash-Befehl idl -d MyProgramm.idl


    - Client: es gibt ein Client-Programm mit einer main, das
    ORB orb = ORB.init(args, null);
    org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
    NamingContext... usw.


    und dann erstell ich welches Objekt um die Referenz zu holen? Dieses?
    MyProgrammInterface object = MyProgrammInterfaceHelper.narrow(ncRef.resolve(name));


    und dann kann ich lustig drauf los Funktionen davon anwenden (wenns die gibt?)
    also object.insert(), etc.


    ----------------------------
    und noch eine Frage zum Server:


    (brauch ich immer dieses poa dings, oder gehts einfacher auch?)
    also nach aktivierung von POA....


    Object myprog = poa.servant_to_reference(new MyProgramm());
    dann "Name Service" holen, und NamingContextExt rebind auf server, mit Objekt)


    nc.rebind(nc.to_name(args[0]+"."+server"),myprog)
    orb.run();


    <- und jetzt ist es erreichbar (von clientseite) oder?



    Muss ich noch irgendwas für den einfachen Client-Server-Corba-Aufbau wissen?
    Wie sehen die Klassendefinitionen aus? also
    public Server extends ??
    public MyProgramm implements MyProgrammInterface??
    public Client ??


    tut mir leid, wenn das sehr laienhaft klingt, aber ich hatte keine zeit, dass alles durchzublicken und versuche, die wichtigsten konstrukte einfach auswendig zu lernen.... :(

    :awake: :awake: ...there's no life before coffee!!!!! :awake: :awake:

  • was ich fix sagen kann ist, dass du dieses poa dings immer brauchst


    danke, das hilft schon mal!!!


    hat sonst irgendjemand hints, tipps, korrekturen, ergänzungen, antworten?...
    hm ich hoff so dass ich die 11punkte zusammenkrieg... sonst kann ich wieder ein jahr auf mein bakk warten...

    :awake: :awake: ...there's no life before coffee!!!!! :awake: :awake:

  • Versteh ich das richtig???:

    Schaut ganz gut aus.

    (brauch ich immer dieses poa dings, oder gehts einfacher auch?)

    Wie Baby schon geschrieben hat: Ja.

    <- und jetzt ist es erreichbar (von clientseite) oder?

    Ja.

    public Server extends ??

    Braucht nix extenden, aber "class" nicht vergessen ;)

    public MyProgramm implements MyProgrammInterface??

    Wenn das Interface MyProgrammInterface heißt, dann sieht die Definition jener Klasse, in der die Methoden implementiert werden, die über CORBA vom Client aus aufgerufen werden, so aus:

    Code
    1. public class MyProgramm extends MyProgrammInterfacePOA


    public Client ??

    Braucht nix extenden; auch hier "class" nich vergessen.


    Alle Klarheiten beseitigt? :)


  • Server und Client musst du nicht ableiten.


    Die Interface-Implementierungen (also MyProgramm in deinem bsp) werden von den per idl generierten POAs abgeleitet (MyProgramm extends MyProgrammPOA) und sollen das interface nicht explizit implementieren.


    wenn du transactions verwendest musst du das interface, das die änderungen vornimmt, die dann committed oder rolledback werden, in der idl von CosTransactions::Resource und CosTransactions::TransactionalObject ableiten, in java dann die implementierung wieder nur vom generierten POA (wie oben).


    EDIT: paulchen war schneller und verständlicher aber was solls :)

    Es genügt nicht, keine Meinung zu haben. Man muss auch unfähig sein, sie auszudrücken. Karl Kraus

  • wenn du transactions verwendest musst du das interface, das die änderungen vornimmt, die dann committed oder rolledback werden, in der idl von CosTransactions::Resource und CosTransactions::TransactionalObject ableiten, in java dann die implementierung wieder nur vom generierten POA (wie oben).


    auch dir vielen dank...
    naja transactions hab ich mir gar nicht angeschaut... :(
    ich hoff es geht sich trotzdem aus..!
    wieviel pkte braucht ihr noch so?

    :awake: :awake: ...there's no life before coffee!!!!! :awake: :awake: