[sockety]Model komunikacji klient-serwer

Discussion:

(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)

Lukasz

2009-04-05 13:45:15 UTC

Witam,
interesują mnie sposoby wymiany informacji w Javowych aplikacjach typu
klient-serwer. Do tej pory używałem PHP i w podobnych sytuacjach
stosowałem SOAP. Javę dopiero poznaję, jednak w PHP obiektowo piszę już
od dobrych kilku lat. Teraz zamierzam przenieść się na środowisko Javy:
na początek serwer zarządzający dostępem do bazy i desktopowe aplikacje
klienckie. Zakładam że przekazywanie informacji powinno odbywać się za
pomocą socketów. Zastanawiam się w jaki sposób obsługuje się taką
komunikację w Javie. Materiały w sieci dot. programowania socketów
pokazują najwyżej jak przesyłać komunikaty tekstowe między klientem a
serwerem. Czy i tu komunikacja odbywa się podobnie jak w WebServices?
Wiem o serializacji obiektów, ale potrzebuję bardziej praktycznych
przykładów. Np. wysyłam do serwera żądanie pobrania z bazy danych
klienta i dane te od niego otrzymuję. Byłby ktoś łaskaw wytłumaczyć mi,
zielonemu jak trawa, jak rozwiązuje się coś takiego w sieciowych
aplikacjach Javy? Czy są jakieś dobre wzorce i sprawdzone uniwersalne
sposoby na obsługę przekazywania informacji na linii klient-serwer?
Mam nadzieję, że nie namotałem za bardzo. Będę wdzięczny za opinie i
wskazówki kolegów, którzy w Javie (i nie tylko) już nie takie rzeczy
robili ;)

--
Pozdrawiam, Lukasz

A.L.

2009-04-05 14:12:09 UTC

Permalink

Post by Lukasz
Witam,
interesują mnie sposoby wymiany informacji w Javowych aplikacjach typu
klient-serwer. Do tej pory używałem PHP i w podobnych sytuacjach
stosowałem SOAP. Javę dopiero poznaję, jednak w PHP obiektowo piszę już
na początek serwer zarządzający dostępem do bazy i desktopowe aplikacje
klienckie. Zakładam że przekazywanie informacji powinno odbywać się za
pomocą socketów. Zastanawiam się w jaki sposób obsługuje się taką
komunikację w Javie. Materiały w sieci dot. programowania socketów
pokazują najwyżej jak przesyłać komunikaty tekstowe między klientem a
serwerem. Czy i tu komunikacja odbywa się podobnie jak w WebServices?
Wiem o serializacji obiektów, ale potrzebuję bardziej praktycznych
przykładów. Np. wysyłam do serwera żądanie pobrania z bazy danych
klienta i dane te od niego otrzymuję. Byłby ktoś łaskaw wytłumaczyć mi,
zielonemu jak trawa, jak rozwiązuje się coś takiego w sieciowych
aplikacjach Javy

Rozumiem ze wytlumaczyc nie przerywajac snu?... A do ksiazek Szanowny
Kolega zajrzec nie raczy?

Skoro ksiazka taka jak "Java network programming" (Hughes, Shoffner,
Hamner) ma 800 stron, to widzocznie nie jest to takie proste aby komus
"zielonemu jak trawa" wytlumaczyc to w 3 linijkach.

Proponuje aby Kolega postudiowal i pojawil sie tu z pytaniami
KONKRETNYMI, a nie "jak to dziala'

A.L.

Lukasz

2009-04-05 14:31:31 UTC

Permalink

Post by A.L.
Rozumiem ze wytlumaczyc nie przerywajac snu?... A do ksiazek Szanowny
Kolega zajrzec nie raczy?
Skoro ksiazka taka jak "Java network programming" (Hughes, Shoffner,
Hamner) ma 800 stron, to widzocznie nie jest to takie proste aby komus
"zielonemu jak trawa" wytlumaczyc to w 3 linijkach.
Proponuje aby Kolega postudiowal i pojawil sie tu z pytaniami
KONKRETNYMI, a nie "jak to dziala'

"Czy i tu komunikacja odbywa się podobnie jak w WebServices?".
Zadałem konkretne pytanie, aby wiedzieć przynajmniej od czego zacząć,
jak podejść do nowego dla mnie zagadnienia.

Nie czekam tylko na gotowe, będę wdzięczny za informacje, gdzie mogę np.
poczytać o podstawach innych niż przesyłanie komunikatów "Hello" i
odsyłanie echo. Czytam grupę już jakiś czas, wiem że zagląda tu wielu
doświadczonych programistów, dlatego pytam. Za przytoczoną książkę
dziękuje.

Jacek Czerwinski

2009-04-05 20:05:37 UTC

Permalink

Post by Lukasz

"Czy i tu komunikacja odbywa się podobnie jak w WebServices?".
Zadałem konkretne pytanie, aby wiedzieć przynajmniej od czego zacząć,
jak podejść do nowego dla mnie zagadnienia.

Jeśli w PHP (rzeczywiście - bo nie jest to dla mnie oczywiste) poznałeś
SOAP, to wiedz, że do PHP-a poszło to już mocno sprawdzone w Javie, w
ogóle to protokół z półki 'corpo'.

Plus kilka innych protokołów też jest dostępnych.

Lukasz

2009-04-05 21:01:18 UTC

Permalink

Post by Jacek Czerwinski
Jeśli w PHP (rzeczywiście - bo nie jest to dla mnie oczywiste) poznałeś
SOAP, to wiedz, że do PHP-a poszło to już mocno sprawdzone w Javie, w
ogóle to protokół z półki 'corpo'.
Plus kilka innych protokołów też jest dostępnych.

Brałem udział w kilku projektach opartych o SOAP i XML-RPC, znam tego
typu technologie. Postaram się uprościć pytanie: czym warto się
zainteresować podczas projektowania aplikacji klient-serwer, która w
całości ma być wykonana w Javie? Chodzi mi głównie o sposoby wymiany
informacji. Skoro jest to ten sam język, to może nie trzeba do tego
zaprzęgać usług sieci Web? Czytałem o CORBA i RMI, również o przesyłaniu
serializowanych obiektów. Próbuję tylko uzyskać informację, jaka
technologia sprawdza się najlepiej (lub chociaż dobrze - wiadomo,
wszystko zależy) przy komunikacji Java <-> Java.

Waldek Kot

2009-04-05 22:21:39 UTC

Permalink

Post by Lukasz
Skoro jest to ten sam język, to może nie trzeba do tego
zaprzęgać usług sieci Web?

Masz rację, chociaż oprócz tego, że po obu stronach jest ta sama
technologia, dochodzi jeszcze sprawa sieci pomiędzy nimi. Webservices
powinno się używać "z głową" (ta rekomendacja nie jest to specyficzna
dla Javy ;-))

Post by Lukasz
Czytałem o CORBA i RMI, również o przesyłaniu
serializowanych obiektów. Próbuję tylko uzyskać informację, jaka
technologia sprawdza się najlepiej (lub chociaż dobrze - wiadomo,
wszystko zależy) przy komunikacji Java <-> Java.

RMI, bo do takiej komunikacji zostało stworzone. Z tym, że RMI jako
protokołów komunikacyjnych używa JRMP, IIOP (CORBA), a czasem i innych
implementacji (np. serwer aplikacyjny WebLogic i wiele innych
produktów ze stajni Oracle pomiędzy "swoimi" komponentami używa
bardziej wydajnej implementacji o nazwie T3). Oczywiście zwykle tych
różnych implementacji na poziomie RMI nie widać (albo zapewniona jest
współpraca różnych implementacji ze sobą, np. JRMP z T3 albo JRMP z
IIOP). Te z kolei używają znanych protokołów sieciowych TCP, IP, itd.

Jeśli znasz webservice's typu SOAP, to wiesz, że najczęściej stos
wygląda tak: SOAP-HTTP-TCP-IP-Ethernet. Możliwe są inne konfiguracje,
ale analogię mam nadzieję widać. SOAP dotyczy zresztą bardziej
struktury komunikatu (header, body, attachments), czyli _w pewnym
sensie_ odpowiada serializacji (możesz transportować komunikaty SOAP
poprzez RMI, choć serializacja Javy - standardowa bądź własna - zwykle
będzie szybsza).

RMI wymaga jednak odpowiedniej konfiguracji firewall'i (w każdym razie
jest z nim trudniej niż z HTTP), co raczej nie jest problemem wewnątrz
sieci, ale na zewnątrz (szczególnie do internetu) owszem. Niektóre
implementacje RMI pozwalają "zawrzeć" RMI w HTTP (tunelować), ale to
tylko częściowo rozwiązuje sprawę i nie jest bezkosztowe (np. gorsza
wydajność niż "czyste" RMI). Inne podejście to zrobić specjalną
warstwę dostęp do obiektu. Tu możesz użyć różnego rodzaju web services
(SOAP/WSDL/HTTP, REST), bądź kombinacji serializacji i HTTP (tu co do
serializacji masz wybór od własnego, poprzez XML, po choćby takie jak
Hessian, Burlap, czy XML-RPC - mogę się mylić, ale te ostatnie trzy
chyba też są znane w społeczności PHP).

Pozdrawiam,
Waldek Kot

Waldek Kot

2009-04-05 22:47:42 UTC

Permalink

Post by Lukasz
Zakładam że przekazywanie informacji powinno odbywać się za
pomocą socketów. Zastanawiam się w jaki sposób obsługuje się taką
komunikację w Javie. Materiały w sieci dot. programowania socketów
pokazują najwyżej jak przesyłać komunikaty tekstowe między klientem a
serwerem. Czy i tu komunikacja odbywa się podobnie jak w WebServices?

Zapomniałem jeszcze do tych wyjaśnień dodać, że zarówno WebServices,
RMI, jak większość innych technologii sieciowych wykorzystuje
socket'y, bo najczęstszym protokołem komunikacyjnym (przynajmniej w
internecie ;-)) jest IP. Komunikację na poziomie socket'ów (TCP
socket'ów, UDP socket'ów i innych-socket'ów) warto rozumieć, ale z
racji, że jest to dosyć niskopoziomowa komunikacja, w aplikacjach
takich jak Twoje skorzystałbym raczej z API wyższego poziomu. RMI (a
raczej jeszcze wyżej - EJB, Spring i ewentualnie, zgodnie z poprzednim
mailem, warstwa zdalnego dostępu - webservices, etc.).

Pozdrawiam,
Waldek Kot

Lukasz

2009-04-06 14:30:43 UTC

Permalink

Post by Waldek Kot
Zapomniałem jeszcze do tych wyjaśnień dodać, że zarówno WebServices,
RMI, jak większość innych technologii sieciowych wykorzystuje
socket'y, bo najczęstszym protokołem komunikacyjnym (przynajmniej w
internecie ;-)) jest IP. Komunikację na poziomie socket'ów (TCP
socket'ów, UDP socket'ów i innych-socket'ów) warto rozumieć, ale z
racji, że jest to dosyć niskopoziomowa komunikacja, w aplikacjach
takich jak Twoje skorzystałbym raczej z API wyższego poziomu. RMI (a
raczej jeszcze wyżej - EJB, Spring i ewentualnie, zgodnie z poprzednim
mailem, warstwa zdalnego dostępu - webservices, etc.).
Pozdrawiam,
Waldek Kot

Właśnie takich odpowiedzi było mi potrzeba!
Wielkie dzięki i pozdrawiam serdecznie.

Maciej Sobczak

2009-04-06 12:55:37 UTC

Permalink

Post by Lukasz
Skoro jest to ten sam język, to może nie trzeba do tego
zaprzęgać usług sieci Web? Czytałem o CORBA

Z tego samego powodu tego też nie trzeba zaprzęgać. CORBA ma
największy sens wtedy, gdy system jest heterogeniczny (komponenty
pisane w różnych językach) i *dodatkowo* gdy w systemie stosuje się
złożone mechanizmy zarządzania czasem życia logicznych obiektów. W
praktyce to drugie wymaganie występuje znacznie rzadziej, niż
projektanci CORBY sądzili gdy to projektowali. Jednocześnie ciężar
użycia tej technologii jest dość duży a popularne implementacje są do
d...

Jeśli potrzebujesz coś prostego i naprawdę lekkiego, to możesz
spróbować tego:

http://www.msobczak.com/prog/yami/

Tutorial do Javy jest tutaj:

http://www.msobczak.com/prog/yami/impl/files/javatut.html

Disclaimer: ten projekt nie był nigdy robiony z myślą o Javie, ani też
nikt się nie upiera, że moduł dla Javy spełnia jakiekolwiek powszechne
konwencje Javy - to raczej powstało na kolanie jako uzupełniająca
wtyczka dla większego projektu, który używa YAMI. Niemniej wersja dla
Javy jest mała i działa i w tym kontekście może być dla Ciebie dobrym
wyborem zanim ugrzęźniesz w enterprajzowym spaghetti. ;-)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Waldemar Kłaczyński

2009-04-05 21:18:42 UTC

Permalink

Tu także zalecany jest SOAP, jak nie chcesz wgryzać się na początek w
JAX-WS, to możesz użyć NetBeans, ma wizualny generator klienta WS. Co do
serwera to wystarczy dodać annotacje @WebService, @WebMethod, itp...,
oraz w encjach można notować pola używając annotacji JAXB. Ja używam
JBoss, z opisu wynika, że obsługuje WS-Addresing, WS-Eventing, a nawet
WS-Security, niestety WS-Policy nie działa najlepiej, ale rzadko to jest
przydatne, do tego udało mi się odpalić WS-Transaction i zsynchronizować
z JTA, niestety musiałem napisać swoją wtyczkę do JBoss, zaproponowałem
ją tutaj:

https://jira.jboss.org/jira/browse/JBTM-44
https://jira.jboss.org/jira/secure/attachment/12324499/jbossxts-bridge.zip

Nie sprawdzałem ale może działać także z JTS
Jak ktoś potrzebuje transakcji AT po B2B, automatycznie synchronizującej
się z lokalnym menadżerem transakcji, to chętnie służę tutaj radą:). U
mnie to rozwiązanie działa świetnie.

Jeszcze jest biblioteka zrobiona przez Macieja Muchalaka do obsługi
transakcji BA
http://www.jboss.org/jbosstm/baframework/index.html
Super sprawa, dla JBoss 5.0 modyfikuje się lekko jboss-aop.xml i także
powinna śmigać.

Witold Szczerba

2009-04-06 22:10:15 UTC

Permalink

Może zainteresuj się serwerem aplikacyjnym z EJB. Prosty przykład
aplikacji klient-serwer można pokazać w 5 minut z wykorzystaniem np.
serwera Glassfish.
Przykładowo: instalujesz NetBeans 6.5.1 razem z Glassfish 2.1.
Odpalasz NetBeans'a, z jego poziomu Glassfish'a i teraz:
a) tworzysz projekt EAR...
b) ...z modułem EJB
c) prosty projekt typu biblioteka
d) projekt typu aplikacja

Dla ułatwienia wszystkie 4 projekty umieszczasz w jednym katalogu i
dodajesz piąty katalog: lib - podłączając go do wszystkich projektów,
dzięki czemu wszystkie biblioteki są w jednym miejscu.
Teraz do projektu (c) podłączasz bibliotekę z plikiem javaee.jar (z
katalogu glassfish/lib). Tworzysz interfejs np.: test.HelloRemote

@Remote
public interface HelloRemote {
public String sayHello(String name);
}

W projekcie (b) tworzysz zdalny session bean - tzn. tworzysz klasę
test.HelloBean:

@EJB
public class HelloBean implements HelloRemote {
@Override
public String sayHello(String name) {
return "Hello " + name;
}
}

Żeby to zadziałało musisz dodać projekt (c) jako bibliotekę projektu
(b), inaczej to się w ogóle nie skompiluje, bo kompilator nie będzie
wiedział co to jest test.HelloRemote.

OK, strona serwera załatwiona. Teraz pozostaje kliknąć na projekcie
(a) prawym i wybrać "Deploy". Aplikacja powinna zainstalowac się na
serwerze.

Teraz klient. Na początek dodaj do projektu (d) projekt (c) jako
bibliotekę - analogicznie jak to było dla (b). Teraz musisz
zaimportować klika plików z katalogu glassfish/lib - możesz to zrobić
w postaci jednego zestawu bibliotek - tak, żeby były pod jednym
szyldem w bibliotece. Lista plików:
appserv-rt.jar
appserv-deployment-client.jar
appserv-ext.jar
być może o jakimś zapomniałem: listę uzupełniającą znajdziesz wewnątrz
appserv-rt.jar/META-INF/MANIFEST.MF.

Teraz pozostaje zrobić prostą aplikację typu hello world:
public class test.Client {

private static final Logger logger = Logger.getLogger
(Client.class.getName);

public static void main(String[] args) throws Exception {
InitialContext ic = new InitialContext();
HelloRemote helloBean =
(HelloRemote) ic.lookup(HelloRemote.class.getName());

logger.info(helloBean.sayHello("WORLD!"));
}
}

W razie problemów zacznij od:
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html

--
Witold Szczerba

Lukasz

2009-04-07 16:19:24 UTC

Permalink

Post by Witold Szczerba
Może zainteresuj się serwerem aplikacyjnym z EJB. Prosty przykład
aplikacji klient-serwer można pokazać w 5 minut z wykorzystaniem np.
serwera Glassfish.
Przykładowo: instalujesz NetBeans 6.5.1 razem z Glassfish 2.1.
a) tworzysz projekt EAR...
b) ...z modułem EJB
c) prosty projekt typu biblioteka
d) projekt typu aplikacja
(...)
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
--
Witold Szczerba

Dziękuję Ci za cierpliwość i chęć dokładnego opisania. Któregoś wieczora
usiądę sobie i na spokojnie, krok po kroku przestudiuję podany sposób.
Jeszcze raz dzięki i pozdrawiam.

--
Łukasz

Maciej Sobczak

2009-04-07 20:20:31 UTC

Permalink

Post by Lukasz
interesują mnie sposoby wymiany informacji w Javowych aplikacjach typu
klient-serwer.

Prosty przykład [...]
NetBeans [...] Glassfish [...] EAR [...] EJB

[...]

Dla ułatwienia [...] 4 projekty (!)

To powyżej przypomina mi stary dowcip o ewolucji programisty i o
programie Hello World.
Mam wrażenie, że społeczność Javowa zatraca umiejętność rozwiązywania
prostych problemów prostymi metodami.

Zmodyfikowane zadanie: są dwa programy, A i B. Fakt że one już
istnieją oznacza, że mają już swoją formę, również w sensie sposobu
ich uruchamiania. Program A chce wysłać programowi B pozdrowienie jako
uzupełnienie jednej z ich istniejących akcji.
Potencjalne rozwiązanie powinno dać się przedstawić jako *patch* do
istniejącego kodu (ewentualnie z uzupełnieniem o jakiegoś jara, jeśli
rozwiązanie jest spoza JDK).
Co teraz? Da się to zrobić?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Witold Szczerba

2009-04-08 10:46:55 UTC

Permalink

Post by Maciej Sobczak

Post by Lukasz
interesują mnie sposoby wymiany informacji w Javowych aplikacjach typu
klient-serwer.

Prosty przykład [...]
NetBeans [...] Glassfish [...] EAR [...] EJB

[...]

Dla ułatwienia [...] 4 projekty (!)

Wystarczą 3 projekty: klient, serwer i ich część wspólna, chyba, że
chcesz całą komunikację oprzeć na czymś w rodzaju komunikatów, wtedy
wystarczą dwa, ale to średni pomysł. Czwarty podałem tylko dlatego, że
sam serwer może składać się z wielu komponentów EJB, dlatego od razu
zrobiłem EAR - kontener na moduły EJB. Tak, nie jest wymagany.

Nie powiesz mi chyba, że komponent EJB (zwykła prosta klasa z jedną
metodą) + interfejs, dzięki któremu klient może wykonać zdalne
wywołanie + klient na 3 linijki tekstu to jakieś specjalnie
skomplikowane rozwiązanie?

Nie rozumiem twojego trolowania. Po jaką cholerę nieustannie marudzisz
i smęcisz, że Java jest do bani zamiast zabrać swoje 4 litery w
miejsce, które będzie ci odpowiadać?

Post by Maciej Sobczak
Zmodyfikowane zadanie: są dwa programy, A i B. Fakt że one już
istnieją oznacza, że mają już swoją formę, również w sensie sposobu
ich uruchamiania. Program A chce wysłać programowi B pozdrowienie jako
uzupełnienie jednej z ich istniejących akcji.
Potencjalne rozwiązanie powinno dać się przedstawić jako *patch* do
istniejącego kodu (ewentualnie z uzupełnieniem o jakiegoś jara, jeśli
rozwiązanie jest spoza JDK).
Co teraz? Da się to zrobić?

Czy nie wydaje ci się chociażby odrobinę nieuprzejme wtrynianie się w
nie swój wątek i dokładanie swoich pytań zupełnie nie na temat? Bawisz
się w adwokata autora tego wątku? Piszesz o jakiejś abstrakcyjnej
sytuacji typu: mamy dwie aplikacje - jak je teraz skomunikować ze
sobą, podczas gdy autor chciał się dowiedzieć jak zbudować relację
klient-serwer.

--
Witold Szczerba

Maciej Sobczak

2009-04-08 12:07:02 UTC

Permalink

Post by Witold Szczerba
Nie powiesz mi chyba, że komponent EJB (zwykła prosta klasa z jedną
metodą) + interfejs, dzięki któremu klient może wykonać zdalne
wywołanie + klient na 3 linijki tekstu to jakieś specjalnie
skomplikowane rozwiązanie?

Specjalnie proste też nie jest, bo narzuca formę. Ba - nie tylko
formę, ale też infrastrukturę.
Dlatego zapytałem o możliwości w projektach, które mają już jakąś (być
może inną) formę.

Post by Witold Szczerba
Nie rozumiem twojego trolowania.

To nie jest trolowanie. Postronny początkujący czytelnik (albo nawet
sam pytacz) czytający ten wątek może odnieść wrażenie, że nie da się
tego problemu rozwiązać w Javie w prosty sposób a to by była bardzo
destrukcyjna konkluzja - obaj wiemy, że tak nie jest.

Post by Witold Szczerba
Po jaką cholerę nieustannie

Nieustannie? Z miesiąc nic tu nie napisałem. :-)

Post by Witold Szczerba
marudzisz
i smęcisz, że Java jest do bani

Nie napisałem, że Java jest do bani. Napisałem, że społeczność Javowa
traci umiejętność rozwiązywania prostych problemów prostymi metodami.
Zastanów się nad różnicą.

Różnica polega na tym, że pytaczowi należało zapodać np. to:

http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html

I wtedy byłoby jasne, że Java nie jest do bani, że jak najbardziej
pozwala rozwiązać prosty problem prostą metodą i że być może najpierw
należy przejechać się parę razy rowerem zanim się wsiądzie do
ciężarówki.

Post by Witold Szczerba
zamiast zabrać swoje 4 litery w
miejsce, które będzie ci odpowiadać?

"Java" ma 4 litery. Ta grupa jest odpowiednim miejscem.

Post by Witold Szczerba

Zmodyfikowane zadanie: są dwa programy, A i B. [...]

Czy nie wydaje ci się chociażby odrobinę nieuprzejme wtrynianie się w
nie swój wątek

A czyj to jest wątek? Gdzie się kupuje bilety?

Post by Witold Szczerba
i dokładanie swoich pytań zupełnie nie na temat?

Jak najbardziej na temat. Chodzi o komunikację klient/serwer.

Post by Witold Szczerba
Bawisz
się w adwokata autora tego wątku?

Jako osoba początkująca autor ma prawo mieć adwokata.
Ja jako osoba początkująca mam prawo włączyć się ze swoimi pytaniami -
zwłaszcza wtedy, gdy te dodatkowe pytania mogą rozszerzyć zakres
użytecznych odpowiedzi.

Oczywiście zawsze istnieje też taka opcja, że ogłosisz się
właścicielem i administratorem tego wątku.

Post by Witold Szczerba
Piszesz o jakiejś abstrakcyjnej
sytuacji typu: mamy dwie aplikacje - jak je teraz skomunikować ze
sobą, podczas gdy autor chciał się dowiedzieć jak zbudować relację
klient-serwer.

Przeczytałem to zdanie kilka razy i nadal nie kumam, co chciałeś
napisać.
Chcesz mieć "relację klient-serwer" bez komunikowania się?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Witold Szczerba

2009-04-08 14:08:54 UTC

Permalink

Post by Maciej Sobczak
Specjalnie proste też nie jest, bo narzuca formę. Ba - nie tylko
formę, ale też infrastrukturę.
Dlatego zapytałem o możliwości w projektach, które mają już jakąś (być
może inną) formę.

Nie jest proste bo narzuca formę? Zwykły interfejs + zwykła klasa +
zwykły klient + coś, co to wszystko obsłuży czyli kontener EJB. Chyba
nie spodziewasz się, że mając POJO + interfejs + klienta, obiekty będą
się same przesyłały przez sieć. Podaj jakiś prostszy sposób na tak
transparentną komunikację klient-serwer jaką masz w EJB3 (tylko bez
rozwiązań w tylu przesłanie komunikatu tekstowego). To są zwykłe
klasy, zwykłe interfejsy, żadnej magii - tylko kontener, który to
wszystko zrobi.

Post by Maciej Sobczak
To nie jest trolowanie. Postronny początkujący czytelnik (albo nawet
sam pytacz) czytający ten wątek może odnieść wrażenie, że nie da się
tego problemu rozwiązać w Javie w prosty sposób a to by była bardzo
destrukcyjna konkluzja - obaj wiemy, że tak nie jest.

To JEST prosty sposób. Fakt, że trzeba się zapoznać najpierw z EJB,
ale równie dobrze można zarzucić, że trzeba się Javy nauczyć...

Post by Maciej Sobczak
Nie napisałem, że Java jest do bani. Napisałem, że społeczność Javowa
traci umiejętność rozwiązywania prostych problemów prostymi metodami.

Raz jeszcze: rozwiązanie jest proste i daje "out-of-the-box" o wiele
więcej niż tylko komunikacja klient-serwer. Jeśli przykładowy
Glassfish v2 jest taki straszny to na pocieszenie powiem, że niebawem
wydanie zostanie Glassfish V3, który będzie jeszcze prostszy w
obsłudze (rozpakuj, uruchom, zapomnij). Konfigurację można wyklikać w
interfejsie web, jak ktoś się boi linii poleceń.

Post by Maciej Sobczak
http://java.sun.com/docs/books/tutorial/networking/sockets/clientServ...

Och, jak to dobrze, że ty jedyny wiesz co należało odpowiedzieć...
Tak na poważnie, należało pokazać to autorowi wątku to co pokazałeś,
żeby uświadomić, że nie trzeba używać serwerów aplikacyjnych i kto tam
wie czego jeszcze do prostego przesyłana komunikatów. Super.

Tylko powiedz: nie można było tego zrobić normalnie? Dodać po prostu
kolejna odpowiedź na pytanie autora do wątku? Dorzucić ewentualnie
komentarz w stylu: po co się męczyć z serwerem EJB jak można to zrobić
tak czy siak? Autor wątku ma swój rozum, sam sobie oceni, porówna,
doczyta. Zamiast tego wymachujesz tekstami od rzeczy, przyrównując
wykorzystanie serwera EJB3 do głupoty rodem z jakiegoś dowcipu.

Post by Maciej Sobczak
I wtedy byłoby jasne, że Java nie jest do bani, że jak najbardziej
pozwala rozwiązać prosty problem prostą metodą i że być może najpierw
należy przejechać się parę razy rowerem zanim się wsiądzie do
ciężarówki.

Tak, powtórz to jeszcze 100 razy, że EJB3 i jego możliwości
komunikacji zdalnej są do bani w typowej sytuacji, bo ich zastosowanie
ogranicza się do jakiś abstrakcyjnie skomplikowanych przypadków
prowadzonych przez głupich javowców co rozdmuchują prosty problem do
rangi lotu na księżyc.

Post by Maciej Sobczak
A czyj to jest wątek? Gdzie się kupuje bilety?

Wątek jest autora. Masz jakieś swoje sprawy do załatwienia na grupie
to rozpocznij nowy wątek. Oczywiście biletów nie trzeba.

Post by Maciej Sobczak

Post by Witold Szczerba
i dokładanie swoich pytań zupełnie nie na temat?

Jak najbardziej na temat. Chodzi o komunikację klient/serwer.

Nie.
Napisałeś o sytuacji, że mamy dwie gotowe aplikacje i teraz trzeba je
ze sobą skomunikować. Też mi przypadek klient-serwer....

Post by Maciej Sobczak
Jako osoba początkująca autor ma prawo mieć adwokata.
Ja jako osoba początkująca mam prawo włączyć się ze swoimi pytaniami -
zwłaszcza wtedy, gdy te dodatkowe pytania mogą rozszerzyć zakres
użytecznych odpowiedzi.

Prawo oczywiście masz. Forma, styl i treść odrobinę nie taka. Powtórzę
raz jeszcze: miałeś coś do powiedzenia autorowi - trzeba było to
zrobić podając swój punkt widzenia. Zamiast tego wciskasz mu jakieś
mity o EJB3 i dodajesz retoryczne pytanie, które ma niby naprowadzić
na jakąś niby odpowiedź.

Post by Maciej Sobczak

Przeczytałem to zdanie kilka razy i nadal nie kumam, co chciałeś
napisać.
Chcesz mieć "relację klient-serwer" bez komunikowania się?

Serwer i klient to nie są jakieś dwie aplikacje, które zostały
najpierw napisane, a potem ktoś doszedł do wniosku, że dobrze by było,
jakby mogły się ze sobą komunikować. Dlatego wydaje mi się, że twoje
pytanie "naprowadzające" było zupełnie bez sensu w kontekście pytania
otwierającego wątek.

--
Witold Szczerba

Maciej Sobczak

2009-04-19 20:54:01 UTC

Permalink

Post by Witold Szczerba
Jeśli przykładowy
Glassfish v2 jest taki straszny to na pocieszenie powiem, że niebawem
wydanie zostanie Glassfish V3, który będzie jeszcze prostszy w
obsłudze (rozpakuj, uruchom, zapomnij).

To fantastycznie. My też używamy pewnego produktu (również w branży
komunikacyjnej, btw), który się tylko "rozpakowuje, uruchamia i
zapomina". Po kilku latach zapominania stworzyliśmy w końcu dedykowane
stanowisko i zatrudniliśmy człowieka specjalnie po to, żeby zapominał.
Wysłaliśmy go za kupę kasy na szkolenie, żeby nauczył się zapominać.
Nawet telefon dostał, żeby mógł zapominać w trybie 24/7.

(nie, nie troluję - ot, taka zawodowa ostrożność)

Post by Witold Szczerba
Tylko powiedz: nie można było tego zrobić normalnie?

Było normalnie, tylko masz za nisko ustawiony próg detonacji i
eksplodujesz bezsensowną agresją.

Post by Witold Szczerba
Tak, powtórz to jeszcze 100 razy, że EJB3 i jego możliwości
komunikacji zdalnej są do bani w typowej sytuacji, bo ich zastosowanie
ogranicza się do jakiś abstrakcyjnie skomplikowanych przypadków
prowadzonych przez głupich javowców co rozdmuchują prosty problem do
rangi lotu na księżyc.

No właśnie. Po co się tak rozgrzewasz?

A wracając do tematu - ja absolutnie nie obwiniam autorów
jakiejkolwiek technologii. Obwiniam (to za mocne słowo, ale niech
będzie) tylko tych, co jej zbyt frywolnie używają.

Przykład z życia - w pewnym projekcie okazało się po jakimś czasie, że
programiści używają 3 różnych frameworków do perzystencji.
Równocześnie.
Czy to jest wina autorów tych frameworków? Nie. Czy ktoś był głupi i
cokolwiek rozdmuchał do jakiejś rangi? Też nie. Problem tylko w
lekkości z jaką podejmuje się decyzje o użyciu jakiegoś gotowca. Ja
właśnie o tej lekkości.

Post by Witold Szczerba

Post by Maciej Sobczak

Post by Witold Szczerba
i dokładanie swoich pytań zupełnie nie na temat?

Jak najbardziej na temat. Chodzi o komunikację klient/serwer.

Nie.
Napisałeś o sytuacji, że mamy dwie gotowe aplikacje i teraz trzeba je
ze sobą skomunikować. Też mi przypadek klient-serwer....

Masz na to jakąś inną nazwę?

Post by Witold Szczerba
Powtórzę
raz jeszcze: miałeś coś do powiedzenia autorowi - trzeba było to
zrobić podając swój punkt widzenia. Zamiast tego wciskasz mu jakieś
mity o EJB3

Pomówienia. Nie napisałem ani słowa o EJB3, więc w szczególności nie
mogłem też napisać żadnego mitu. :-)

Post by Witold Szczerba
Serwer i klient to nie są jakieś dwie aplikacje, które zostały
najpierw napisane, a potem ktoś doszedł do wniosku, że dobrze by było,
jakby mogły się ze sobą komunikować. Dlatego wydaje mi się, że twoje
pytanie "naprowadzające" było zupełnie bez sensu w kontekście pytania
otwierającego wątek.

Mylisz się (może dlatego, że skupiłeś się na wojnie zamiast na
temacie).
Istnieje bardzo wiele programów, które swoje cechy klienckie bądź
serwerowa nabyły w procesie dojrzewania a nie w dniu urodzin.
Przykład 1: program zapisuje na dysk pewne dane, które okresowo
produkuje (pomiary, logi, whatever). W wersji 2.0 autor wymyślił, że
zamiast pisać na dysk lepiej by było te dane publikować. W ten sposób
program stał się serwerem.
Przykład 2: program czyta swoje ustawienia konfiguracyjne z dysku. W
wersji 2.0 autor wymyślił, że konfigurację można trzymać w bazie
danych albo w jakimś serwisie, skąd są pobierane wtedy, gdy są
potrzebne. W ten sposób program stał się klientem.

Ten drugi przypadek jest tak powszechny (zwłaszcza wersja z bazą
danych), że większość programistów nawet nie rozpoznaje w nim schematu
klient-serwer. Powszechność pokazuje, że się mylisz w swojej ocenie
tego zjawiska. Łatwość typowego rozwiązania pokazuje, jak bardzo ważne
jest to, aby takie problemy dały się rozwiązać nieintruzyjnie.

Różnica między naszymy podejściami w nawiązywaniu relacji klient-
serwer ma swoje konsekwencje nie tylko w tym w jaki sposób używa się
istniejącej infrastruktury (i czy w ogóle się jakąś używa), ale
również w tym kiedy można takie decyzje podjąć i jak bardzo są one
kosztowne w kontekście całego projektu. Jestem zwolennikiem technik
nieintruzywnych, które dają się zaaplikować nawet do istniejących
struktur.
Stąd moje pytanie. Myślę, że nie było bez sensu.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Lukasz

2009-04-08 19:45:56 UTC

Permalink

Post by Maciej Sobczak
http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html
I wtedy byłoby jasne, że Java nie jest do bani, że jak najbardziej
pozwala rozwiązać prosty problem prostą metodą i że być może najpierw
należy przejechać się parę razy rowerem zanim się wsiądzie do
ciężarówki.

Tutaj ja jednak staję po stronie Witolda. Prosiłem właśnie o jakiś
troszkę bardziej ambitny przykład, niż tylko wysyłanie "Hello", czy
innych "Knock knock!". Proste przykłady znam, m.in. ten podany przez
Ciebie, rozumiem już że samo przesyłanie tekstu nie jest niczym
skomplikowanym. Brak mi umiejętności, żeby od razu ocenić czy sposób
Witolda jest lepszy, czy gorszy. Ja po prostu jestem mu wdzięczny, że
zechciał opisać swoje rozwiązanie - o to właśnie chodziło mi przy
zakładaniu tego wątku. Może trzeba do tego podejść w ten właśnie sposób:
kolega pokazał mi możliwe rozwiązanie, nie napisał że jest jedyne i
najlepsze.
Mam świadomość tego, że jeszcze nie raz przyjdzie mi zwrócić się na
grupę z mniej lub bardziej banalnymi dla starych wyjadaczy pytaniami. Z
tego powodu oczywiście nie mam zamiaru w żaden sposób atakować Ciebie,
również biorę sobie do serca wszystko co napisałeś. Po prostu to trochę
nie w porządku krytykować kogoś tylko za chęć pomocy.

--
Pozdrawiam,
Łukasz

Maciej Sobczak

2009-04-19 21:09:26 UTC

Permalink

Tutaj ja jednak staj po stronie Witolda. Prosi em w a nie o jaki
troszk bardziej ambitny przyk ad, ni tylko wysy anie "Hello", czy
innych "Knock knock!".

Nie rozumiem. Przecież Witold zużył ogromną ilość energii pokazując
jak prosty był jego przykład. Dlaczego więc uważasz, że pasuje do
Twoich oczekiwań w kategorii "ambitny"? :-)

Proste przyk ady znam, m.in. ten podany przez
Ciebie, rozumiem ju e samo przesy anie tekstu nie jest niczym
skomplikowanym.

Bingo. Te przykłady pokazują przesyłanie tekstu tylko dlatego, że
tekst jest banalny i nie zaciemnia istoty tego, co jest prezentowane.
A powinno być oczywiste, że skoro już jest ustanowiony jakiś kanał
komunikacyjny i jest dostępny jako np. OutputStream, to wysłać można
*cokolwiek*. Zserializuj sobie dowolną strukturę danych i wyślij.
Jeśli standardowy serializator jest niedobry, skorzystaj z
zewnętrznych standardów (ASN.1, etc.). I tak dalej - tu naprawdę nie
ma ograniczeń.
W tych przykładach nie chodzi o tekst, tylko o połączenie. Jeżeli te
przykłady wydają Ci się za mało atrakcyjne tylko z powodu użycia tam
komunikatów tekstowych, to najwyraźniej ich autorzy nie osiągnęli tego
co chcieli.

Brak mi umiej tno ci, eby od razu oceni czy spos b
Witolda jest lepszy, czy gorszy.

Nikt tego nie oceni, dopóki nie przedstawisz wszystkich swoich
oczekiwań i kryteriów oceny. Tych kryteriów może być cała masa. Np.
zużycie pamięci albo czas uruchomienia czy nawet takie egzotyczne
pierdoły jak polityka licencyjna.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com