Integracja aplikacji webowej z dekstopową

Witam,
jak z integrować aplikację desktopową (np. działającą wewnątrz firmy) z aplikacją webową? Przykładowo mamy sobie hotel, pensjonat... W budynku znajduje się recepcja, która przyjmuje telefoniczne rezerwacje albo ktoś przychodzi z ulicy i bierze pokój (jeśli jest wolny). Nasz hotelik posiada również stronę internetową z możliwością rezerwacji on-line.

Teoretycznie można byłoby zrobić wszystko na jednej bazie. Problem pojawia się gdy w naszym hoteliku nie będzie neta (tzn. będzie jakaś awaria od strony dostawcy netu).

Pewnie są jeszcze jakieś inne problemy do rozwiązania. Ogólnie chodzi o wymianę danych między dwoma światami: webowym i desktopowym.

To stawia się bazę lokalnie względem hoteliku i stronę się tam hostuje. Jeśli nie ma neta => nie działa strona, ale aplikacja desktopowa działa, bo baza jest lokalnie.

Postawienie serwera nie jest tanie. Zakładamy że serwer webowy jest na zewnątrz.

To co robisz w programie, zapisujesz do pliku. Inny podprogram będzie służył do wysyłania tych danych na stronę. Nie ma internetu - nie ma aktualnych danych na stronie. Pojawi się internet, pojawią się dane, wprowadzone, gdy nie było internetu.

Kupcie sobie telefon kom z dostępem do neta, aby w razie W móc na recepcji też rezerwować pokoje. Jak padnie net u dostawcy serwisu www, to i tak rezerwacji nikt nie złoży.

Ale to nie chodzi konkretnie o hotel, to był tylko przykład. Pytanie jest ogólne. Czy są jakieś sprawdzone już sposoby, rozwiązania?

Sprawdzone? Baza danych + web serwisy, do nich łączą się klienci desktopowi oraz aplikacja WWW. Baza danych, web serwisy i aplikacja WWW mogą być na różnych serwerach, mogą też być na jednym.

Dwie bazy nie zapewnią Ci spójności danych, więc to nie będzie sprawdzone rozwiązanie.

CAP Theorem:

When you build a distributed system, of three desirable properties you want in your system: consistency, availability, and tolerance of network partitions, you can only choose two.

Tak więc można mieć 2 bazy danych i uzyskać spójność danych, ale np. kosztem braku dostępności serwisu w przypadku awarii jednego segmentu sieci. Do tego celu używa się baz danych z obsługą protokołu 2 Phase Commit.
Albo możesz zbudować system, który będzie odporny na awarię poszczegóólnych segmentów sieci ale nie będzie zapewniał spójności danych (albo będzie zapewniał tylko częściową spójność danych). W tą stronę poszły NoSQLowe bazy danych.
Jeszcze inna kwestia to przepustowość i czas odpowiedzi takiego systemu. Systemy zapewniającą spójność mają mniejszą przepustowość i większy czas odpowiedzi, natomiast systemy nie gwarantujące spójności mają większą przepustowość i mniejszy czas odpowiedzi.
Tak więc wracając do Twojego przykładu z hotelem - zależy jak bardzo zależy Ci na dostępności i na spójności bo pomiędzy tymi dwoma trzeba wybrać. Jeżeli wolisz, żeby system był dostępny 24/7 to będziesz musiał tolerować częściową niespójność danych (np. 2 różne osoby dostaną ten sam pokój hotelowy) i w przypadku wykrycia niespójności powiadamiać klientów.
Jeżeli nie chcesz mieć niespójności to będziesz musiał się pogodzić, że awaria sieci powoduje awarię serwisu.

0x200x20 napisał(a)

Tak więc można mieć 2 bazy danych i uzyskać spójność danych, ale np. kosztem braku dostępności serwisu w przypadku awarii jednego segmentu sieci.

Ta, recepcjonista nie może wpuścić nikogo do hotelu, bo strona internetowa nie działa. [rotfl]

Teoretycznie, gdyby nie była potrzebna wymiana informacji na bieżąco, tylko np. na koniec dnia albo o jakieś godzinie. Można byłoby zrobić 2 bazy i np. z desktopa wysyłać kiedy będzie można.

Kozy napisał(a)

Postawienie serwera nie jest tanie. Zakładamy że serwer webowy jest na zewnątrz.

No i tam może być jedna baza danych o pokojach, zaleta - duża dostępność dla klienta (przez 99,9% czasu) i szybki czas przeszukiwania.
Druga baza musi być na portierni bo nie wszyscy mają możliwość/potrafią korzystać z Internetu.

Jeżeli nie działa internet w hotelu - działa dalej strona www. Jeżeli ktoś przez www chce zorientować się jaki jest stan rezerwacji, dostaje szybką odpowiedź bo serwer www ma własną bazę i obsługuje ją błyskawicznie w porównaniu z wysyłaniem zapytania do bazy hotelowej i czekania na odpowiedź.

Jeżeli ktoś chce zamówić pokój przez www w czasie kiedy nie działa internet w hotelu - dostaje uprzejmy komunikat o chwilowej niedostępności usługi rezerwacji przez www i prośbę o kontakt/rezerwację telefoniczną. Gdyby łączył się z bazą hotelową, też nic by nie załatwił bo Internet nie działa, nie dostałby nawet komunikatu z numerem telefonu :)

Dwie bazy to praktycznie same zalety. Ustalić trzeba tylko wyższy priorytet dla bazy w recepcji, tj. wszystkie zmiany rezerwacji powinny być potwierdzane w bazie danych recepcji.

olitary napisał(a):

Jeżeli nie działa internet w hotelu - działa dalej strona www. Jeżeli ktoś przez www chce zorientować się jaki jest stan rezerwacji, dostaje szybką odpowiedź bo serwer www ma własną bazę i obsługuje ją błyskawicznie w porównaniu z wysyłaniem zapytania do bazy hotelowej i czekania na odpowiedź.

Jeżeli ktoś chce zamówić pokój przez www w czasie kiedy nie działa internet w hotelu - dostaje uprzejmy komunikat o chwilowej niedostępności usługi rezerwacji przez www i prośbę o kontakt/rezerwację telefoniczną. Gdyby łączył się z bazą hotelową, też nic by nie załatwił bo Internet nie działa, nie dostałby nawet komunikatu z numerem telefonu :)

Więc co klientowi daje ta "błyskawiczna" baza do rezerwacji na serwerze zewnętrznym, skoro i tak nie może nic zarezerwować, gdy w hotelu nie ma internetu?
A skoro nic nie daje, to po co zatem dwie bazy?

No i widzicie na ile sposobów można spieprzyć prostą aplikacje bazodanową? A ponoć klepanie kodu biznesowego jest proste... [rotfl]

somekind napisał(a)

Więc co klientowi daje ta "błyskawiczna" baza do rezerwacji na serwerze zewnętrznym, skoro i tak nie może nic zarezerwować, gdy w hotelu nie ma internetu?
A skoro nic nie daje, to po co zatem dwie bazy?

Ona daje komfort użytkowania czyli szybkość dostępu. Daje też informację aktualnym stanie wolnych/zajętych pokoi lub braku możliwości podania takiego stanu. Baza danych zlokalizowana w recepcji w przypadku braku dostępu do Internetu nie podaje żadnych danych.
Praktycznie przez większość czasu stan bazy na serwerze www pokrywa się z bazą w recepcji a ma tą zaletę, ze jest szybciej dostępny. Gdyby tu chodziło o jakiś system wysokiej dostępności, np. obsługujący służby porządkowe na Stadionie Narodowym, mówienie że przez większość czasu działa dobrze było by dyskwalifikujące, ale w przypadku hoteliku jest moim zdaniem dopuszczalne. Przecież zdarzają się wyłączenia prądu a pewnie mało który hotelik ma rezerwowe źródła zasilania utrzymywane przez cały rok w technicznej sprawności.

Jak rozumiem problem jest w tym, ze w czasie, kiedy nie działa internet dwie bazy mogą się rozsynchronizować. I ja to rozumiem. Należy zwyczajnie w obsłudze obu baz przewidzieć możliwość przerwania połączenia internetowego i poinformować użytkownika www że ze względu na niezależną od hotelu przerwę połączenia internetowego w tej chwili jest możliwa wyłącznie rezerwacja telefoniczna. Ja widzę w takim rozwiązaniu problem w sytuacji kiedy przerwy w dostępie do internetu zdarzają się regularnie, np. kilka razy w tygodniu/miesiącu. Najczęściej jednak ma to miejsce 2-3 razy w roku albo mniej więc dla takiego hoteliku to żaden duży problem. Gdyby to była sieć kilkuset hotelików to oczywiście inne rozwiązanie byłoby brane pod uwagę.

..no każdy ma swój punkt widzenia :) Ja uważam że moje rozwiązanie jest dobre bo jest tanie i dobre :) Jak na hotelik powinno być OK. Gdyby chodziło o lot na Marsa albo Stadion Narodowy to oczywiście inne kryteria są ważniejsze i cena pewnie nie jest tak istotna jak w przypadku hoteliku.

Pozdrawiam.

olitary napisał(a):

Ona daje komfort użytkowania czyli szybkość dostępu.

Jaką szybkość? Skąd się bierze? Dlaczego arbitralnie twierdzisz, że któreś z tych rozwiązań jest szybsze? Przecież to zależy od prędkości łącza, mocy serwerów i obciążenia, a nie od tego, czy serwer jest zewnętrzny czy wewnętrzny. :|

Daje też informację aktualnym stanie wolnych/zajętych pokoi lub braku możliwości podania takiego stanu.

Czyli dokładnie to samo, co da strona z rezerwacją postawiona na serwerze w hotelu, nieprawdaż?

somekind napisał(a)

Jaką szybkość? Skąd się bierze? Dlaczego arbitralnie twierdzisz, że któreś z tych rozwiązań jest szybsze? Przecież to zależy od prędkości łącza, mocy serwerów i obciążenia, a nie od tego, czy serwer jest zewnętrzny czy wewnętrzny. :|

zakładam, że technologia wykonania zarówno sprzętu jak i łącza Internetowego u profesjonalnego dostawcy jest znacznie lepsza niż w hoteliku. To jest kwestia ceny. Hotelik najczęściej nie może sobie pozwolić na rozwiązania "z najwyższej półki" a nawet "z wysokiej" , dodatkowo jest mało prawdopodobne, żeby wymieniał ten sprzęt częściej niż co kilka lat, czyli technologicznie przegrywa z profesjonalistą. Oczywiście można powiedzieć że wszyscy mogą sobie kupić sprzęt "z najwyższej półki" ale zakładam, że koszty też w naszym przypadku są istotnie ważne.

Daje też informację aktualnym stanie wolnych/zajętych pokoi lub braku możliwości podania takiego stanu.

Czyli dokładnie to samo, co da strona z rezerwacją postawiona na serwerze w hotelu, nieprawdaż?

Prawda, jeżeli łącze internetowe i sprzęt będą funkcjonowały przez 99,9 procent czasu w roku, a należy się spodziewać, ze tak nie będzie. Tak jak wyżej pisałem jest to kwestia profesjonalizmu i ceny. Profesjonalista ma kilka łącz o dużej przepustowości /światłowody?/ a hotelik pewnie jedno być może 1-2 Mb/s i to pewnie niesymetryczne :)

Strona www na zewnętrznym serwerze ma też tą zaletę, ze prezentuje ofertę marketingową hotelu, co prawda bez informacji o zajętych pokojach, ale marketing to też rzecz bardzo ważna. W pierwszej kolejności potencjalni nowi klienci oglądają ofertę hotelu a potem przechodzą do rezerwacji. Dodatkowo zewnętrzna strona www podaje informację o numerze telefonu pod którym można zarezerwować pokój, czego nie poda strona postawiona na serwerze w hotelu jeżeli padnie łącze internetowe.

olitary napisał(a):

zakładam, że technologia wykonania zarówno sprzętu jak i łącza Internetowego u profesjonalnego dostawcy jest znacznie lepsza niż w hoteliku.

Do którego nurtu filozoficznego należysz?

To jest kwestia ceny. Hotelik najczęściej nie może sobie pozwolić na rozwiązania "z najwyższej półki" a nawet "z wysokiej" , dodatkowo jest mało prawdopodobne, żeby wymieniał ten sprzęt częściej niż co kilka lat, czyli technologicznie przegrywa z profesjonalistą.

Do obsługi takiego ruchu jaki będzie miał hotelik, zwykły pecet sprzed 5 lat to aż nadto.

Prawda, jeżeli łącze internetowe i sprzęt będą funkcjonowały przez 99,9 procent czasu w roku, a należy się spodziewać, ze tak nie będzie. Tak jak wyżej pisałem jest to kwestia profesjonalizmu i ceny. Profesjonalista ma kilka łącz o dużej przepustowości /światłowody?/ a hotelik pewnie jedno być może 1-2 Mb/s i to pewnie niesymetryczne :)

Ja w domu mam 10 Mbps, i to jest niewiele, a firma ma mieć 1 Mbps? :| Zwłaszcza hotel, w którym goście będą chcieli z internetu korzystać?
Te Twoje "założenia" są urwane z choinki. Takich rzeczy się nie zakłada, tylko przeprowadza obliczenia, a potem dokonuje wyboru, co się najbardziej opłaca w danej sytuacji.

Dostępność systemu rezerwacji zależy i tak wyłącznie od dostępności serwera w hotelu, więc jakie ma znaczenie, jakie łącza ma serwer zewnętrzny?
A skoro żadne, to po co dokładać sobie roboty z synchronizacją baz?

Strona www na zewnętrznym serwerze ma też tą zaletę, ze prezentuje ofertę marketingową hotelu, co prawda bez informacji o zajętych pokojach, ale marketing to też rzecz bardzo ważna. W pierwszej kolejności potencjalni nowi klienci oglądają ofertę hotelu a potem przechodzą do rezerwacji. Dodatkowo zewnętrzna strona www podaje informację o numerze telefonu pod którym można zarezerwować pokój, czego nie poda strona postawiona na serwerze w hotelu jeżeli padnie łącze internetowe.

No i?
Piszemy o SYSTEMIE REZERWACJI, a nie o STRONIE INTERNETOWEJ hotelu. Nikt nigdzie nie twierdził, że ma jej nie być, albo ma być ona na serwerze w hotelu. Masz jakiś problem z tym, żeby oddzielić jedno od drugiego, stronę umieścić na zewnętrznym hostingu, a system rezerwacji na serwerze w hotelu? Bo może to jest przyczyną Twoich postów.

a ja mam taki pomysł: bazę trzymać w hotelu. Na stronie zrobić tylko formularz z rezerwacją. Gdy ktoś go wypełni i wyśle, to do recepcji przychodzi choćby zwykły SMS z danymi z formularza. Wtedy recepcja potwierdza albo emailowo (jak ma neta) albo może nawet oddzwonić. Strona w momencie wysłania formularza próbuje połączyć się z serwerem w hotelu. Gdy ten nie odpowiada, to po prosty wysyła SMS, a gdy jest, to dodaje rezerwację do bazy, aby w recepcji miały jak najmniej do klepania.

W ten sposób aktualna baza zawsze jest w hotelu i są "odcięci" gdy neta nie ma - ani recepcja ani klienci, bo jakiś kontakt zawsze jest.

somekind napisał(a)

[...]

Możemy tak się przekonywać długo. To nie jest problem gdzie jest możliwe jedno rozwiązanie. Na przykład Ty masz 10 Mbps a ktoś ma tylko połączenie radiowe bo ma hotel poza centrum miasta. Ja z pierwszego postu w wątku zrozumiałem, że system rezerwacji ma być połączony ze stroną www. W jednym się chyba zgadzamy, to musi być rozwiązanie dostosowane do konkretnych warunków i konkretnego zamawiającego.

no_solution_found napisał(a)

a ja mam taki pomysł: [...]

Poczytaj dobrze wcześniejsze posty, wydaje mi się, że ktoś miał już podobny pomysł :)

Pozdrawiam.

olitary napisał(a):

Możemy tak się przekonywać długo. To nie jest problem gdzie jest możliwe jedno rozwiązanie. Na przykład Ty masz 10 Mbps a ktoś ma tylko połączenie radiowe bo ma hotel poza centrum miasta.

Zatem w 99% niepatologicznych przypadków możemy zastosować niepatologiczne rozwiązanie, w którym nie utrudniamy sobie życia.

Ja z pierwszego postu w wątku zrozumiałem, że system rezerwacji ma być połączony ze stroną www.

No i to od razu musi oznaczać, że oba muszą stać na jednym serwerze? :|
Myślisz, że taki np. onet.pl to jest jeden serwer? Bo przecież tam jest wszystko ze sobą połączone.

a ja mam taki pomysł: bazę trzymać w hotelu. Na stronie zrobić tylko formularz z rezerwacją. Gdy ktoś go wypełni i wyśle, to do recepcji przychodzi choćby zwykły SMS z danymi z formularza. Wtedy recepcja potwierdza albo emailowo (jak ma neta) albo może nawet oddzwonić. Strona w momencie wysłania formularza próbuje połączyć się z serwerem w hotelu. Gdy ten nie odpowiada, to po prosty wysyła SMS, a gdy jest, to dodaje rezerwację do bazy, aby w recepcji miały jak najmniej do klepania.

W ten sposób aktualna baza zawsze jest w hotelu i są "odcięci" gdy neta nie ma - ani recepcja ani klienci, bo jakiś kontakt zawsze jest.

A jak niepowiedzie się wysłanie smsa? A jeśli sms nie dojdzie? A co jeśli klient dostanie potwierdzenie, że ma rezerwacje a jednak jej nie będzie miał (bo recepcja nie ma listy dostępności pokojów)? A czym to się różni od stworzenia redundatnej bazy oprócz tego, że to człowiek musi sobie radzić z usterką?

Często padające lub słabe łącze oznacza albo często występującą całkowitą niedostępność rezerwacji, albo częsty brak synchronizacji między dwiema bazami, więc tez niedostępność. W takim przypadku w
ogóle nie bierzmy się za żadną internetową rezerwację, tylko wystawmy stronę z numerem telefonu na pierwszym lepszym hostingu i nie filozofujmy.

@997 - a propos tego, że nie każdego stać na drogie rozwiązania. Co będzie tańsze: prosta aplikacja do rezerwacji z jedną bazą, czy aplikacja z wieloma bazami, zapewniająca spójność i tranzakcyjność operacji?