//
// IIOP.NET
// 

--> (11.2013) jest nowa wersja iiop.net v1.9.3
zdaje sie ze nie ma bledow poprzednich wersji!!!
teraz dziala jako klient!!!
bardziej zlozone typy (patrz ./111) tez dzialaja!
valuetype jednak nie dzialaja (patrz ./222)
klient i serwer iiop.net spod eagle dzialaja!!! (patrz ./333)
co wymaga dalszych eksperymentow: any, ...

--> co jest w IIOPChannel.dll ?
monop -r:IIOPChannel.dll; # wyswietla wszystkie typy
monop -r:IIOPChannel.dll omg.org.CosNaming.NamingContext
  # + w iiop.net nie ma met. narrow(); zamiast tego 
      robi sie konw. na typ interfejsowy, np NamingContext

--> nowe bledy (niestety):
1. jest jakis warning podczas kompilacji
2. CLSToIDL... nadal nie dziala!
3. serwer HelloServer.exe przestaje dzialac po pewnym czasie
   moze to jakies przeterminowanie z powodu braku aktywnosci?!?!
   tak, to sie dzieje po 2min. braku aktywnosci...
   zdaje sie ze to jest std. zachowanie ob. remotingowych?!?!
4. valuetype jednak nie sa zaimpl. na iiop.net ???
   przynajmniej nie od strony serwera...


............................
stare notatki
dotycza wersji < 1.9.3
............................

--> problem po stronie klienta z IOR
iiop.net nie potrafi odczytac zlozonych IORow...
czy mozna uzyc corbaloc ?!?!?!?
  corba::string_to_object corbaloc::192.168.0.1:10000/qqq
to dziala pod combat-em, jesli wczesniej wykonac:
  RemotingConfiguration.RegisterWellKnownServiceType(
    HelloImpl,"qqq",WellKnownObjectMode.Singleton)
czyli pod iiop tez powinno dzialac...
  string loc = "iiop://192.168.0.1:10000/qqq"; // to dziala
  string loc = "corbaloc::192.168.0.1:10000/qqq"; // to NIE dziala
  qqq1.Hello hello = (qqq1.Hello)
    RemotingServices.Connect(typeof(qqq1.Hello), loc);
Uwaga1: po ukosniku w corbaloc jest to co iordump pokazuje jako "Key:" !
Uwaga2: zeby zobaczyc efekt RegisterWellKnownServiceType w IOR
  trzeba utorzyc ob. poprzez Activator.GetObject(),
  i potem wygenerowac IOR...
Uwaga3: nadal nie wiadomo jak kli iiop.net moze sie podlaczyc
  do ob. corba na ser combat !!!
  patrz: iiop.net/333

--> CLS2IDL nie dziala w iiop.net!!!
+ wniosek: mech. generowanie IDL sie nie sprawdza a Javie i .NET !!!
  tylko "wraper/dekorator corbowy" ma sens...

--> ./222 (eksperyment 06.2011)
+ ob. remotingowy moze byc dostepny rownoczesnie przez 2 kanaly
  np przez kanaly tcp i iiop
+ Activator.GetObject() i IOR zwaracaja 2 rozne obiekty!
  co trzeba zrobic zeby to byl jeden obiekt?!?!?!?!!?
    oby stworzyc IOR musze najpierw utworzcy serwanta...
    jak spowdowac zeby ten wlasnie serwant 
      byl zwracany przez aktywator???
    ODP: wystarczy na serwerze nie tworzyc recznie serwanta
      tylko wlasnie przez aktywator !!! (patrz ser2.tcl)

--> stare uwagi  
* iiop.net dziala dobrze po stronie serwera
  (latwo uczynisc ob. remotinigowy ob. corby!)
  ale jest problem po stronie klienta!!! (patrz pzr420/temat C)
  moze chodzi tylko o interpret. pliku IOR??

(06.2011) 
* IDLToCSL... dziala dobrze! patrz: ./111
  potrafi skompilowac COS_Prop.idl i COS_trans.idl
  nie potrafi COS_ns.idl (prawd. dlatego ze te klasu juz sa...)
* serwanty w boo?
  NIE, w ogole klasy nie dzialaja w boo0.7.9?!?!?!?!
* CLSToIDL NIE dziala !!!
  czyli pozostaje "dekorator/wrapper corbowy"
  ... mechaniczne generowanie IDL sie nie sprawdza
    tak jest w Javie (rmi_over_iiop) i w .NET!!!
  ... aby udostepnic ob. Javy/.NET przez Corbe
    trzeba RECZNIE napisac dekoratory corbowe!!!
    niektore struktury danych trzeba przystosowac do Corby
    (np java.util.Vector zamienic na sekwencje struktur?)



