aplikacja desktop/www - co wybrać?

Witam.

mam do zrobienia aplikacje, która będzie składać się z dwóch części: aplikacji okienkowej i panelu www. Wszystko będzie działać na jednej bazie. I zastanawiam się jak to rozwiąząć.
Czy podzielić to na dwie oddzielne aplikacje i w każdej zastosować Hibernate. Czy może lepiej utworzyć jedną dużą aplikacje enterprise używając hibernate i glassfisha?
Chciałbym zrobić jakieś szyfrowane łączenie sie z serwerem aplikacji. W panelu www pójdzie to po sslu. A co z aplikacją desktopową?
Proszę o jakieś sugestie i pomysły do rozwiązania tego problemu.

Skoro glassfish to moze:

1. glassfish + EJB3 + JPA zamiast czystego hibernate, zdaje sie ze tam providerem JPA jest TopLink, ale mozesz wladowac hibernate jak chcesz; jesli zalezy ci na funkcjonalnosci ktora ma hibernate a nie ma JPA, to mozesz calkiem zrezygnowac z JPA i dzialac tylko z hibernatem, lub uzywac JPA, a w miejsach gdzie nie wystarcza uzywac natywnych interfejsow hibernate
2. klient WWW - cokolwiek w czym piszesz, laczy sie z EJB3. Jesli uzywasz servletow itp, to w web.xml mozna dodac wpisy bedace nazwami i typami EJB na serwerze, pozniej zrobic lookup w niezbednych miejscach (jak ServletContextListener), i wolac zdalne metody
3. swing czy cokolwiek do desktop GUI - rowiez bedzie laczyc sie z EJB3 na serwerze, JNDI aby zlokalizowac fasolki i ich uzywac
   W koncu po to sa EJB, prawda? Zaznaczam, ze klienty beda cienkie, cala logika na serwerze, w EJB.
   Napisz co sadzisz. Pozdrawiam.

pytanie, tylko czy zaprzęganie ejb nie jest przerostem formy nad treścią...może spring po prostu??

Kolega wspominal o glassfishu, wiec moze aplikacja jest wymagajaca i rzeczywiscie EJb sa dobrym wyborem?
Co do springa, przyznam ze nie znam za dobrze tego frameworka, tylko takie hasla marketingowe i jakies przykladowe kody. Co mi przychodzi do glowy to to, ze autor chcial miec serwer i 2 rodzaje klientow: web i desktop. Z tego jak ja to zrozumialem to chcialby miec na serwerze cala logike, a klienty tylko by ja wolaly. Ze springiem chyba nie da sie tak? Mozna wrzucic go do tomcata czy innego kontenera, mozna wrzucic do aplikacji desktopowej, ale czy mozna zrobic tak zeby sobie byl serwer i czekal na polaczenia od zarowno weba jak i desktopowych Nie trzeba by wtedy napisac serwera swojego? Moze mozna i przez RMI jechac... Jesli to co pisze to bzdury, to przepraszam z gory i obiecuje poprawe, to jest na mojej TODO liscie jak tylko sie uporam z tym czym sie teraz zajmuje :D
Pozdrawiam.

@malamyga
właśnie o to mi chodziło, myślałem własnie o połączeniu hibernate z glassfishem. tylko chciałem się zapytać o zdanie.
potem kiedyś do tego ma dojść klient mobilny więc takie rozwiązanie byłoby chyba najlepsze.

tworzenie ejb i wywoływanie fasolek mam opanowane :)

a czy można jakoś zaszyfrować taką sesje? bo klient będzie uruchamiany z różnych lokalizacji. najprostszym sposobem byłoby chyba base64, ale nie o to mi chodzi.

@ollerm, jest jeszcze prostsza metoda jak już chcesz EJB(3). Wykonaj komunikację na webservices. Można to sobie spokojnie szyfrować SSLem lub javax.crypt. W każdym razie jeżeli wykonasz całość na WS to będzie ci wisiało jaki rodzaj klienta się zapina. Można go napisać nawet w Dephi i będzie git.

jakos nie jestem przekonany do ws. a calosc i tak bedzie na javie.

zastanawiam sie tylko jak zrobic z klasami i obiektam jak bede wyciagal dane przez hibernate. czy przez rmi uzywac tych klas na kliencie? a polaczenia do glassfisha do korzystania z ejb nie mozna zaszyfrowac?

Połączenia bezpośrednio do EJB nie za bardzo ponieważ to co dostajesz jest w rzeczywistości ulepszonym RMI z własnym javowym protokołem.
Generalnie serwer powinien udostępniać:

• obsługę utrwalania
• statystykę
• autoryzację
  Klient powinien pytać serwer o obiekty, a nie samodzielnie korzystać z bazy danych. Najłatwiej obiekty wysyłać przez WS, bo to jest tylko jedna anotacja na klasę na serwerze. Resztę załatwiają narzędzia.

właśnie takie jest moje zalożenie żeby klient nie odpytywał bazy bezpośrednio.

Niebardzo wiem jak wyciągać te obiekty z ejb w aplikacji klienckiej. Zawsze kończy się to RemoteException

1. Obiekty są Serializabe.
2. Metoda EJB jest wywoływalna czyli adnotacja @Remote jest na interfejsie.
3. Metoda zwraca obiekt.
4. Generujesz klienta a podstawie interfejsu zdalnego.
5. Jesz obiad i pijesz kawę (serio generowanie potrafi trwać)
6. Piszesz testy dla interfejsu zdalnego.
7. Implementujesz interfejs zdalny, aż będzie przechodził wszystkie testy.
8. Testy dla klienta.
9. Implementacja klienta.
10. powinno być dobrze :)

nie bardzo łapie to co jest od punktu 4 :-/

niektóre rzeczy nie są jeszcze dla mnie do końca zrozumiałe w J2EE, ale nie chce rezygnować z tej technologii.

o co chodzi z tym generowaniem klienta? i tak nie wiem jak klient ma rozpoznać obiekt :-/

Skoro EJB pozwala na wywołanie metody zdalnie to można na tej podstawie wygenerować klienta. Jeżeli weźmiesz IDE typu Eclipse to jest tam zazwyczaj wizard, który wygeneruje odpowiedni kod z pięknym komentarzem "TODO auto-generated stub" i wystarczy te todo zamienić w coś rozsądnego.

Swoją drogą zmuszasz mnie do tego mbym odzyskał w SPACJA końcu starego bloga tam był przykład.

no przydałby się przykład :)

a jakby tak utworzyć biblioteke z klasami i dodać ja do projektu ejb i projektu klienta?

Oto i przykładowa aplikacja oparta o webservices:
http://blog.runelord.eu/?title=title&more=1&c=1&tb=1&pb=1