Programiranje

ActiveMQ, NodeJS, Angular - ispit na faksu

REX500 pet 11.5.2018 15:09

Pozdrav ekipa.

Ime je Filip, faks je KEA (Copenhagen School of Design & Tech u Kopenhagenu) a smjer je Software Dev top-up (bachelor).

Ime predmeta je System Integration i bavi se vise manje time.

Grupa i ja Imamo projekt napraviti simulaciju gdje integriramo vise sustava u jednu cjelinu koristeci: rest api, soap, SOA, message brokere, legacy systems itd...

 

Dali mi netko kao 1. moze pojasniti koja je uloga message brokera i dali se isti mogu koristiti tj integrirati u Node aplikacije i koliko to ima smisla.

Kada god citam o tome spominju se jezici kao Java, c#, c++...

Mrzim OOP i necu u tome raditi (mrzite vi mene slobodno).

 

Moje pitanje je vezano uz message brokere (kada se koriste te kako) te micro services tj SOA.

Requirements su da koristimo oboje uz gore navedene te me ovo dvoje najvise zbunjuju.

 

Koji bi bio primjer micro services-a u nekoj maloj/demo aplikaciji?

 

Ideja koju mi imamo je sljedeca:

napraviti business process model u kojem osoba zeli bookirati hotel ili let u nekoj destinaciji.

Flow je sljedeci:

login je kroz facebook (legacy systems) te se ulazi u nas FE app. Osoba u input field pise destinaciju te app napravi call na soap client koji vrati lat i lon od te destinacije (SOAP). Kasnije se ti lat i lon saljii u nodejs REST API koji vraca vremensku prognozu za tu lokaciju (REST API).

Ono sto nam fali je jos jedna standalone aplikacija koje moze raditi potpuno neovisno o ovima nabrojanima do sada i za komunikaciju ne smije koristiit api calls ili soap (moze neki drugi HTTP call).

I nekakav micro service koji bi tu ubacili.

 

Nadam se da nije 100% zbunjujuce te da mi mozete pomoci.

 

Hvala unaprijed!  

dalu sri 6.6.2018 11:28

Message broker ti je komponenta gde saljes poruke i subscriberi dobiju te poruke.

Samo ja licno mislim da je to pogresan pristup. Svi "cloud native" taj design paradigm koriste... dobro neka

 

MQ u node, zasto ne?

SOAP valjda zato sto je to legacy Java, koje u stvari i jos se uvek koristi.

 

Pa posaljes call preko soap i rezultat posaljes preko MQ na subscribers.

 

Microservice design je..

svaka komponenta ima svoj environment

kako to da objasnim..

imas 10 ljudi, i svako zna samo ono sto on zna.

Ni jedan od tih ljudi nezna sta drugi zna.

To je baza.

Sad ti ljudi moraju komunicirati nekako : MQ mozes zamilsiti kao mobilni telefon, nije isto samo kao demonstracija.

 

Tako sad imas jedan servis koji samo zna poslati i preradivati SOAP requests.

Taj servis samo radi to.

Da komuniciraju imas MQ. "Ja sam gotov i rezultat je xyz"

 

Onda imas REST ili RESTful client koji salje RESTful service upite

Znaci imas 1 client koje se samostalan i 1 "server" koji je samostalan. U ovom primeru nemas "server" nego je "server" od nekog drugog.

 

Znaci nemas 1 monolith od aplikajice, nego "separation of concerns" svako igra svoju ulogu.

 

Sta je pitanje?