Użytkownik "MarekM" <m...@w...interia.i-to.pl> napisał w wiadomości
news:cl40eh$m6s$1@srv.cyf-kr.edu.pl...
>
> Nie no, jasne - to jest bardzo istotne, gdyż to determinuje, czy próby
> wysłania przelewu kolejną sesją są ponawiane, czy nie, ale wydaje mi
> się, że ta cecha nie jest powiązana z off/on-lineowością. Wszystko
> zależy od tego, jak system potraktuje brak środków do wykonania
> zlecenia. Zauważ, że w systemie off-line też kiedyś takie zlecenie musi
> mieć ustawiony status na nieaktywny (bo dziwnie wyglądałby "przelew
> przyszły" z wsteczną datą na liście oczekujących, nieprawdaż?). Zmierzam
> do tego, że tak naprawdę to jest odrębna cecha samego systemu, a nie
> sposobu jego działania (w sensie off/on-line). BYĆ MOŻE w systemie
> off-line jest to łatwiejsze do zaimplementowania (bo algorytm może być
> taki: z systemów front-end zbierane są dane o zleceniach do wykonania,
> jak się uda wykonać - to zlecenie dostaje status "zrealizowane", a w
> "przetwarzaniu nocnym" wszystkie zlecenia z datą bieżącą (lub
> wcześniejszą) dostają status "nieaktywne/niezrealizowane").
[..]
> OK - myślę, że to dobra definicja (bardziej precyzyjna i techniczna od
> mojej). Zauważ jednak, że ten "jakiś czas" może być baaardzo krótki i z
> off-line'a się robi niemalże-on-line ;-)
[...]
> No właśnie: przelewy wychodzące i tak stoją w jakiejś kolejce, a czy
> 1. taka kolejka powstaje na bieżąco w systemie backend (on-line),
> 2. czy uzupełniana jest co jakiś czas (w trakcie "synchronizacji"
> backend<->frontend),
> 3. czy też tworzona jest w systemie backend tuż przed sesją na podstawie
> danych zgromadzonych w systemach frontend (i tylko wtedy),
> to nie ma chyba nic wspólnego z tym, czy zlecenie z kolejki w momencie
> braku środków zostanie wyrzucone, czy dostanie kolejną szansę.
> Czyli nie jest ważny sposób wejścia do kolejki zleceń, tylko sposób jej
> opuszczenia. A tu już różnice pomiędzy systemem on-line a off-line są
> niewielkie: w pierwszym przypadku będzie wiadomo "od razu", że się nie
> udało, w drugim może być co najwyżej jakieś opóźnienie z aktualizacją
> statusu.
>
> Właściwie to miałem na myśli :-)

Marku, dla jasności trzeba pewnie rozdzielić operacje wewnątrz banku i te
realizowane na zewnątrz.

W operacjach wewnętrznych (przelewy wewnętrzne, lokaty etc):
Jeżeli jesteś na stronie banku (frontend) )i wykonane przez ciebie operacje
natychmiast mają odzwierciedlenie w systemie banku (backend) to jest to
system on-line.
Jeżeli system transakcyjny jest obciążony to ty też czekasz dłużej niż
zwykle na potwierdzenie realizacji u siebie na ekranie.

W operacjach zewnętrznych (przelewy zewnętrzne):
System on-line niewiele różni się od systemu off-line.
Nawet w systemie on-line przelewy zewnętrzne funkcjonują na zasadzie
off-line (bo sesje ELIXIR mają ustalone godziny) i nie da się tego zrobić
inaczej.
Co zaś do np. prób powtarzania zleceń odrzuconych ze względu na brak środków
tak jak piszesz łatwiej jest to zrobić w systemie off-line, bo jest to 'przy
okazji'...
Pisałeś że w BGŻ czy Pekao24 (nie znam, znałem i do dziś tęsknię za
Telepeako24) system pracuje on-line. Jeżeli więc przelewy wewnętrzne między
rachunkami działają tam on-line to raczej nikt nie podejmie się zbudowania
systemu obsługującymi na 100% sytuacje powtarzania zleceń który będzie tak
naprawdę działał naprawdę 7dni/24godziny.
Ryzyko jest takie że kiedyś znajdzie się np. dociekliwy czytelnik
pl.biznes.banki :-) który potem napisze że nie działa a nikt nie ostrzegał.
Dlaczego ? No bo co się stanie gdy mamy:
- zlecenie przelewu wewnętrznego z datą przyszłą na 01-04-2004
- po północy z 31-03-2004/01-04-2004 brak środków na realizację
- o 23:59:55 dnia 01-04-2004 na rachunek wpływają środki z innego rachunku w
banku
Biedny projektant systemu musiałby w takiej sytuacji uwzględnić po każdej
operacji sprawdzanie czy aby nie ma zleceń oczekujących które w najbliższych
5 sekundach powinny zostać zrealizowane.
Co gorsza, na rachunku docelowym mogłaby pojawić się identyczna sytuacja o
23:59:59 :-)
Wiem że przykład mocno naciągany, ale w dobrym projekcie projektuje się na
najgorszy przypadek. Nie mówiąc już o tym że obciążenie systemu
koniecznością przeprowadzania dodatkowych kontroli (czy trzeba zrealizować
zaległe zlecenie) które w ułamku procentów doprowadzą do dokonania operacji
jest po prostu nieefektywny.

Wydaje mi się że systemy on-line są droższe na starcie, ale łatwiejsze w
utrzymaniu i rozwoju. Trudniej jednak jednak wprowadzać zmiany (stąd taka
ilość przerw konserwacyjnych w MBanku).
Systemu off-line łatwiej i taniej na początku rozwijać ale administrować
nimi to koszmar (stąd tak mało przerw konserwacyjnych w VW i dość sporo
wpadek typu coś nie przeszło albo wykonało się 2x). Ponadto istnieje poziom
krytyczny rozwoju systemu off-line ponad którym nie da się dalej go rozwijać
bez pogorszenia niezawodności i dostępności.

TomekD