Temat: Jaka technologia na system rozproszony?

Witam,

Mam pytanie i prośbę o zgrubną ocenę możliwości implementacji (jakieś technologie) pewnego pomysłu. Architekturę wymyśliłem sobie sam, w odniesieniu do potrzeb klientów i możliwości wdrożenia rozwiązań i mam głębokie przekonanie, że jest optymalna, ale nie wiem jeszcze czy da się to w miarę standardowo (tj. przy użyciu std. rozwiązań) i wydajnie zaimplementować.

System jest w założeniach bardzo złożony, więc ograniczę opis do przykładowej funkcjonalności (która akurat nie będzie implementowana, ale chyba dobrze odzwierciedla problem). Załóżmy więc, że chodzi o system do ankiet osobowych (różne dane "twarde" o pracowniku w firmie). System ma umożliwiać klientowi (firmie): wpisywanie i przegląd danych, wyszukiwanie ludzi o konkretnych uprawnieniach i jakieś analizy (np. przekroje wykształcenia przez piony).

Załóżmy, że te analizy wymagają danych innych firm (np. benchmarki wynagrodzeń). System nie może stać więc u klienta, musi być hostowany przez inny podmiot (np. mnie). Niestety klienci nie chcą za Chiny Ludowe udostępniać nazwisk osób (ale potrzebują ich w robieniu zestawień). Sytuacja jest wiec taka

a) gros systemu (SYS) stoi "u mnie", włączając w to bazę danych (BD-1) zawierającą większość informacji i kod do ich analiz, wyjście na świat przez internet,

b) u klienta stoi okrojona baza danych zawierająca tylko nazwiska (BD-2) oraz aplikacja dostępowa (APP - też webowa, tj. w ich intranecie) stanowiąca tylko interface do SYS, łącząca w locie info z DB-1 i DB-2.

Czyli analizy są robione w zanonimizowanej postaci przez SYS, a dopiero na poziomie prezentacji są uzupełniane o nazwiska z DB-2 przez APP. SYS z APP komunikuje się przez XML (WDSL, SOAP?), prezentuje wykorzystując AJAX (?), wszystko oczywiście szyfrowane jak trzeba itd. APP tak na prawdę jest więcej (do różnych funkcjonalności), bo dla klienta to są po prostu moduły systemu.

Czy to ma prawo działać? Chodzi mi głownie o wydajność. Ponieważ jest tu kilka warstw, komunikacja przez internet w potencjalnie rozdmuchanym XMLu, a całość zapewne w Java i niekoniecznie na superkomputerze, to zapewne jest to schemat raczeje z tych wolniejszych. Wiem, że nie da się tego zdiagnozować bez konkretnych liczb, dlatego chodzi mi o ocenę typu: "na skali od 1 - 10, ślamazarność takiej konstrukcji wynosi X".

Dzięki

Temat: Jaka technologia na system rozproszony?

Ciekawy pomysł chociaż nie do końca "czaję" ideę z nazwiskami i bazą danych znajdującą się w firmie u klienta, ale rozumiem że możesz po prostu nie chcieć udostępniać zbyt wieli informacji o samym pomyśle w obawie o konkurencję :-)

Jeśli chodzi o samo przesyłanie danych to od samego wyboru technologii ważniejsze jest zastanowienie się nad takimi problemami jak:
- częstotliwość przesyłania danych:
a) czy dane muszę być przesyłane w 'real time' (na każde żądanie) i ile tego będzie na dzień
b) czy też w trybie batchowym (np. raz na dobę o 2 w nocy)
- ile tych danych będzie
a) czy to będą dane indywidualnych pracowników (liczba przesyłanych danych rośnie z liczbą pracowników)
b) czy też tak jak piszesz 'benchmarki' czy też statystkyki grupowe (liczba danych niezależna od liczby pracowników)

Łatwo się domyślić które z dwóch podejść do każdego z zagadnień jest wydajniejsze :-) No i generalnie projektując aplikację trzeba się starać stosować jak najwięcej rozwiązań typu b)

Jeśli faktycznie danych będzie dużo i często to możesz pomyśleć o http://en.wikipedia.org/wiki/Fast_Infoset. Skoro zakładasz że obie aplikacje komunikujące się ze sobą będą tworzone przez Ciebie, to nie powinieneś musieć się martwić o interoperability.

Ale generalnie - uważam że jeśli przemyślisz dobrze liczbę i rodzaj komunikatów to każdy protokół/technologia sieciowa powinna dać sobie radę, no - chyba że chcesz od razu proponować rozwiązanie firmom rozmiaru Microsoftu, wtedy warto by się przyjrzeć problemowi dokładniej :-)

ps. jeśli interesowała by Cię jakaś głębsza analiza - daj znać na privMichał Słociński edytował(a) ten post dnia 10.02.08 o godzinie 19:05

Temat: Jaka technologia na system rozproszony?

Na wstępie dzięki za odpowiedź i pzdr z WrocLOVE :-)

Michał Słociński:
Ciekawy pomysł chociaż nie do końca "czaję" ideę z nazwiskami i bazą danych znajdującą się w firmie u klienta, ale rozumiem że możesz po prostu nie chcieć udostępniać zbyt wieli informacji o samym pomyśle w obawie o konkurencję :-)

Akurat to nie wynika z "czajenia się", tylko tak faktycznie jest. Firmy z jednej strony chcą mieć rozbudowane systemy HRIC, ale z drugiej nie mają ochoty ich wewnętrznie wdrażać. Chcą mieć dostęp do danych z rynku, ale wcale nie chcą ich przekazywać. Takie błędne koło.

Tutaj naprawdę chodzi po prostu o to, że dane potrzebne do analiz (wykonywanych zdalnie) są przekazywane jako anonimowe, a że prezentacja wymaga jednak wstawienia tam nazwisk, to firma musi móc je jakoś przypisać. Stąd dwie bazy i join po stronie klienta.

a) czy dane muszę być przesyłane w 'real time' (na każde żądanie) i ile tego będzie na dzień

Tak, i to w obie strony (tj. zarówno APP wysyła dane źródłowe, jak i SYS zwraca analizy). Inna rzecz, że wyniki analiz są w ogromniej większości dość proste, bo z natury większości procesów wynika że dotyczą one pojedynczych wskaźników opisujących jednego człowieka. Czyli schemat: dużo małych żądań do serwera w real-time.

System będzie np. generował raporty w PDFie (więc będzie to parę kB), ale to raczej rzadkie zdarzenie: większość zapytań wymaga zwrócenia dosłownie parędziesięciu bajtów danych (inna rzecz, że xml może to rozdmuchać).

a) czy to będą dane indywidualnych pracowników (liczba przesyłanych danych rośnie z liczbą pracowników)

Tak.

b) czy też tak jak piszesz 'benchmarki' czy też statystkyki grupowe (liczba danych niezależna od liczby pracowników)

To też, ale zdecydowanie rzadziej.

BTW Sorry za żargon: benchmark w HR to np. analiza konkurencyjności płac (np. bierzemy zarobki swoich pracowników i patrzymy na którym centylu są w odniesieniu do branży; jak za mało to rozważamy podwyżkę :-)

Jeśli faktycznie danych będzie dużo i często to możesz pomyśleć o http://en.wikipedia.org/wiki/Fast_Infoset.

To już jest na tapecie. Dzięki za utwierdzenie mnie w tym :-)

Skoro zakładasz że obie aplikacje komunikujące się ze sobą będą tworzone przez Ciebie, to nie powinieneś musieć się martwić o interoperability.

BTW Przy okazji chcę udokumentować i opublikować standard, bo akurat mam kilku opiniotwórczych znajomych w branży, z którymi można to pociągnąć ponadfirmowo.

Ale generalnie - uważam że jeśli przemyślisz dobrze liczbę i rodzaj komunikatów to każdy protokół/technologia sieciowa powinna dać sobie radę, no - chyba że chcesz od razu proponować rozwiązanie firmom rozmiaru Microsoftu

To miło. M$ nie wchodzi w rachubę, to raczej dla małych/średnich firm, ok. 4-5 operatorami systemu (specjalistami HR).

ps. jeśli interesowała by Cię jakaś głębsza analiza - daj znać na priv

Dzięki - rozważę. Szkoda, że wybyłeś za Kanał :-)

Temat: Jaka technologia na system rozproszony?

Dla małych, średnich firm chyba najlepiej sprawdzają się rozwiązania od Microsoft - moim zdaniem są relatywnie najtańsze i najwydajniejsze w swojej klasie (składa się na to wiele aspektów).
Do komunikacji w architekturze heterogenicznej i przetwarzania backoffice'owego potrzebny jest Middleware, a Microsoft proponuje tu BizTalk'a. Interfejsy dla zewnętrznych systemów można wystawić za pomocą webservice'ów.
Można też samemu zbudować taki system, ale potrzeba do tego 3-4 ludzi i ok. pół roku.
Jeśli nie masz superkomputera, to M$ będzie najwydajniejszy.Edward Weinert edytował(a) ten post dnia 10.02.08 o godzinie 21:13

Temat: Jaka technologia na system rozproszony?

Zasada działania jak zwykłe api.
APP musi generować unikalne identyfikatory /skoro firmy nie chcą danych osobowych udostępniać/ i na ich podstawie liczyć wskaźniki.
Myślę, że na taką skalę każda architektura się sprawdzi, w końcu to tylko tekst.

Jeżeli boisz się 'rozdmuchiwania' kB przez XML, pomyśl o JSONie - wspomniałeś o AJAXie więc to będzie idealne połączenie.

JSON vs. XML

Temat: Jaka technologia na system rozproszony?

XML'e można zipować na czas wysłania.

Temat: Jaka technologia na system rozproszony?

Edward: dzięki za wskazania. Tak BTW o M$ mówiłem że odpada w kontekście wielkości firmy (jako klient), nie autora rozwiązań. Inna rzecz, że nie znam sie zupełnie na M$owych technologiach (i szczerze mówiąc dobrze mi z tym ;-) ale oczywiście nie ma to wymiaru fanatycznego i trzeba to rozważyć. Pozgłębiam sobie...

Kuba: dzięki na namiar na JSONa - pierwsze słyszę, a wygląda ciekawie. Ale wariant z FI w sumie chyba bardziej mi leży (bo chcę żeby protokół był możliwie uniwersalny, właśnie do opublikowania). Co do IDów to oczywiście generuje je w założeniu APP (albo wręcz zasysa z innego systemu u klienta) - mi to obojętne, mam swoje :-)

Aha, Długość projektu (w wersji dla klienta, bo potem rozwój dalej już bez ograniczeń) to max 6 miesięcy i raczej do 3-4 devów, tak jak pisał Edward.Michał K. edytował(a) ten post dnia 10.02.08 o godzinie 21:54