witrak() (w...@h...com) wrote in
news:hdrbv2$5f5$1@atlantis.news.neostrada.pl:
> Zażartować można mając blade pojęcie o temacie. Żeby jednak prowadzić
> polemikę *coś* trzeba wiedzieć. A polemikę na wysokim poziomie - dużo
> wiedzieć.

Śmiem twierdzić, że na ten temat wiem jednak sporo. Ale tu chyba nie ma co
się wdawać w dyskusję, bo zaraz się skończy porównywaniem, kto ma
dłuższego...

>> Czepiam się, bo mBank, Multi i PKO BP mają ten sam system :) Gwoli
>> ścisłości - mBank i Multi bardzo bliskie sobie wersje (prawie takie
>> same), a PKO BP coś, co wywodzi się z wersji z BRE.
>
> Nie, nie mają tego samego systemu. Rzeczywiście, mają systemy na tej samej
> platformie (Altamira), ale to nie są systemy identyczne, choć korzystają
> zapewne z bardzo wielu tych samych komponentów.


Gwoli ścisłości - od paru lat Altamira nazywa się Alnova. I różnice pomiędzy
dwoma instancjami w BRE są mocno kosmetyczne. Wersja dla PKO jest już
znacznie inna, sporo jej fragmentów było przepisanych prawie od zera, ale
nadal są tam komponenty, które swoją ostatnią modyfikację miały właśnie w
BRE (a nawet udawało się takie dinozaury odkopać, co przez Hiszpanów
ostatnio były modyfikowane). A zasada komunikacji systemu ze światem
zewnętrznym się nie zmieniła, przynajmniej w kontekście kanałów
samoobsługowych i grubego klienta, od czasów implementacji tego w BRE.

>> Kwestia tego, czy przelewy, podgląd kart i inne rzeczy działają online
>> jest wynikiem tylko i wyłącznie tego, jak projektant system zaprojektował
>> (co z kolei wynika z wymagań banku).
>
> Zależy to również od bazowej architektury całego systemu. Projektant
> podsystemu internetowego z reguły zastaje system transakcyjny i do niego
> musi dostosować swoje rozwiązania architektoniczne.

Aczkolwiek czasem oba te systemy rozwijane są równolegle.
Albo system core jest rozwijany z myślą o udostępnianiu usług na zewnątrz
dla dowolnego kanału - wtedy nie ma różnicy, czy jest to back-office,
front-office czy self-service - wszystko chodzi na przykład na tych samych
webserwisach.

Co nie zmienia faktu, że opisana przez Ciebie sytuacja ma często miejsce.
Trzeba się podłączyć do tego, co jest. I wtedy to, co piszesz niżej (kolejki
MQ, cykliczne przetwarzanie wsadowe i parę jeszcze innych mechanizmów)
często jest rozsądnym kompromisem.

[...]
> Jeżeli proces obsługi użytkownika (interakcja na ekranie) kończy się
> przyjęciem zlecenia transakcji i przekazaniem go do kolejki odrębnego
> procesu, wykonującego transakcje, to użytkownik dowiaduje się tylko o
> przyjęciu zlecenia do wykonania. Dopiero po sprawdzeniu, że stany
> odpowiednich kont zmieniły się, użytkownik wie, że transakcja faktycznie
> została zrealizowana.
> Pomiędzy jednym a drugim może upłynąć dowolnie wiele czasu (np. jeśli z
> jakichś powodów proces drugi nie wykonuje zakolejkowanych transakcji, to
> może to trwać nawet wiele godzin). Jednak jeśli ten proces jest bardzo
> wydajny i jego kolejka jest prawie stale pusta, to użytkownikowi nigdy nie
> udaje się zauważyć opóźnienia - zanim wyświetli stan kont, już transakcja
> zostaje zakończona. Do czasu: przeciążenie systemu wykonującego transakcje
> na bazie spowoduje, że iluzja pryśnie.
>
> Z drugiej strony, jeżeli proces obsługi użytkownika sam wykonuje
> transakcje (w przeciwieństwie do przypadku, kiedy tylko zostawia zlecenie
> w kolejce zleceń do wykonania), to w chwili zakończenia takiego procesu
> zlecenie jest już zawsze zrealizowane (z takim, czy innym wynikiem).
> Innymi słowy, wyświetlenie formatki informującej, że zlecenie się
> zakończyło, następuje dopiero, gdy faktycznie w bazie danych banku stany
> odpowiednich kont zostały zmodyfikowane: *nigdy nie ma* sytuacji, w której
> na poziomie interfejsu użytkownika sygnalizowane jest zakończenie
> operacji, a sam przelew nie został wykonany, bo tkwi w kolejce.


No fajnie. Samą prawdę napisałeś :)

>> Z mojej perspektywy dziwnym jest rozwiązanie hybrydowe a la ING (online w
>> dni robocze, jakiś batch w dni wolne), ale powody pewnie jakieś mieli.
>
> Dziwność - należy do ocen subiektywnych, więc nie polemizuję.
> Jednak tylko na tej podstawie, że podsystem internetowej (interakcyjnej)
> obsługi klienta nie działa całą dobę, można powiedziec jedynie, że jest b.
> niewygodny dla klienta.
>
> Natomiast jeśli przez rozwiązanie hybrydowe rozumieć takie, w którym
> przyjmowanie zleceń (interaktywne) z realizacją transakcji jest połączone
> kolejką, a tę drugą aktywność robi się na systemie zbudowanym z myślą o
> przetwarzaniu wsadowym z ewentualnymi przybudówkami, to takie rozwiązania
> występują w bardzo wielu bankach, nie tylko w ING.

Znowu - prawdę napisałeś.

Ja tylko przypomnę Twoją wcześniejszą wypowiedź, z którą rozpocząłem
polemikę:

> Bo tylko mBank ma system bankowy pracujący rzeczywiście on-line.
> Wszystkie inne banki mają systemy front-end obsługujące dostęp
> internetowy, połaczony kolejką z systemami back-end, wykonującymi
> operacje.

Czy nadal się pod tym podpisujesz? Szczególnie chodzi mi o słowa "tylko" i
"Wszystkie"...

A może zgadzasz się z Ra, że AS/400 to tak kiepsko się integruje online z
systemami samoobsługowymi:
> ironia nie trafiona, co prawda nie tylko mbank pracuje w pełni online
> ale że cześć internentowa jest tylko przybudówką jest chyba oczywiste
> przynajmniej w przypadku as/400 na których działa wiele banków

PS. Proszę, nie próbuj mi udowodnić, że nie znam się na systemach core
banking. Spędziłem trochę czasu pisząc i projektując jeden z nich - od
programowania po projekty wysokiego poziomu. I naprawdę wiem, co ma w środku
i jak działa...

Pozdrawiam,
G.

--
GIT d++ s:+ a->? c++$ U P L+ !E W+ N++ o? K? w O---- M-- V- PS+ PE+++ Y+
PGP t+@ 5- X- !R tv+ b++ DI+++ D+ G+ e+++ h--- y?
* Adres w nagłówku to pułapka *