Named Pipes między Java a C/C++/Delphi etc

Witam

Czy któremuś z forumowiczów udało się nawiązać "połączenie" poprzez named pipes między Java a C etc? Czytam o tym i niektórzy na zagranicznych forach piszą że jest to możliwe a niektórzy że named pipe nie może wyjść poza JVM - named pipes "widzą się" tylko w obrębie jednej JVM.

Czy jezeli to prawda to czy jakimś rozwiązaniem byłoby utworzenie named pipe poprzez natywne wywołanie funkcji z dll? Wtedy wg. mnie powinna być na zewnątrz JVM i móc komunikować się z każda inną...czy dobrze myślę?

Myślałem tez nad komunikacją w odwrotną stronę-no bo dll sama z siebie mnie (jave) nie poinformuje że cos jej przyszło po rule z innej aplikacji. Ten kawałek jeszcze rozważam-zarejestrowanie w systemie komunikatu w dll i odbiór w javie jako callback...?

pozdrawiam

hmm...szczerze to dopatrywałem rozwiązania w klasach javowych PipedInputStream and PipedOutputStream ale tak jak myślałem - działają w jednej JVM i na zewn nie można ich wystawić. W ogóle nie da się wyjsć z pipem na zewn z javy bez użycia wywołania natywnego.

Ale znalazłem to:

http://v01ver-howto.blogspot.com/2010/04/howto-use-named-pipes-to-communicate.html

i wygląda prosto i obiecująco - tylko szkoda że java moze tylko podłączac się (w sumie to logiczne ze względów bezpieczeństwa ale jednak...).

Przeciez named pipes, z poziomu Javy, mozesz traktowac tak samo jak zwykle pliki. Jedyny zgrzyt to utworzenie takiego named pipe'a, bo potrzebne bedzie wywolanie funkcji natywnych dla OS'a (mkfifo() pod Unix'em lub CreateNamedPipe() w WinAPI). Ale to chyba nie bedzie problemem, skoro i tak musisz naskrobac natywny kod, do obslugi tego, cokolwiek tam chcesz przesylac. Zakladam, ze mowimy o komunikacji miedzy procesami na tym samym hoscie (lokalnie).

Użyj socketu do łączenia procesów.

Zalety:
-nie będziesz musiał używać wywołań natywnych
-będzie działać na wszystkich systemach
-łatwo będzie można zmienić tak, aby część w C++ i Javie działały na różnych komputerach, jeżeli w przyszłości będzie takie wymaganie
-jest to bardziej wydajne niż nazwane pipe'y (przynajmniej pod Linuksem)

Alternatywnie możesz pomyśleć o web services. Chociaż to może być mniej wydajne (można jednak włączyć kompresję).

@__krzysiek85

Wiem - zgadzam się z Tobą z zupełności...mam już za soba integrację różnych platform (projekty może i nie największe ale solidne) z Java poprzez sockety (m.in. z flexem). I działa super sprawnie i ma się kontrolę 100% nad tym co się dzieje i co najważniejsze jest stabilne...

Ale teraz mam integrować stary produkt z biblioteką z nowego (w javie) i szefostwo nie przyjeło wypróbowanego socketu bo "pociągałoby to za duze zmiany w już istniejacym produkcie". Więc szukam alternatywy:)

A co do tworzenia named pipes - w sumie nie jestem zmuszony by po stronie javy był tworzony pipe...wtedy tak jak w linku wyżej - podłaczam się tylko z javy i tyle i nie muszę natywnego kodu pisać (nie jest to problem ale chodzi o ewentualną przenośność - z javy mogę sie podłączyć do pipe i tyle bez względu na system,jego zabezpieczenia,uprawnienia etc).

Tak, cała logika bedzie odbywać się na localhoscie.

__krzysiek85 napisał(a)

-jest to bardziej wydajne niż nazwane pipe'y (przynajmniej pod Linuksem)

Jestes pewien? Przeciez sockety wymagaja zeby lecialo przez caly stos TCP, nawet jesli to localhost.

@__krzysiek85

Mógłbyś mi coś więcej powiedzieć, nakierowac z tymi webservicami - liczba danych to pojedyńćze kilobajty...miałbym wystawić webservice i na tym samym kompie C++ miałby go odebrać? (komunikacja w dwie strony?)

Szczerze gdzieś tam isę pojawił ten pomysł ale byly jakieś przeciwskazania-już nie wiem jakie ale czy Tobie jakies przeciwskazania przychodzą do głowy?

lipkerson napisał(a)

Szczerze gdzieś tam isę pojawił ten pomysł ale byly jakieś przeciwskazania-już nie wiem jakie...

Ja bym powiedzial, ze jest co najmniej kilka:

• WebServices wymagaja brokera (np. AS), ktory wystawi odpowiednie uslugi na zewnatrz i bedzie zarzadzal cyklem zycia. Broker potrzebuje pamieci i mocy obliczeniowej.
• narzut SOAP, ktory jest niczym innym, jak XML'em po HTTP (lub RMI)
• potrzebne jest napisanie klienta, ktory bedze wiedziec, jak dogadac sie z usluga sieciowa (WSDL/SOAP)
• komunikacja typu request-response, a nie w czasie rzeczywistym

Jesli powyzsze punkty nie maja wiekszego znaczenia w tym, co chcesz zrobic, to usluga sieciowa moglaby miec sens.