---Introduction---

Rijetko koja aplikacija u danasnjem svijetu zivi u izolaciji, te komunicira sa

ostalim aplikacijama, kako bi poboljsala ili omogucila sve zeljene funkcionalnosti.
Medjutim, komuniciranje sa ostalim aplikacija nosi odredjene izazove kao sto su
nestabilnost i brzina mreze, razlika programskih jezika u kojima su aplikacije
napisane, promjene na aplikacijama (loose coupling), itd.

Cetiri osnovna nacina za postizanje ove komunikacije su:

*file transfer
*shared database
*remote procedure invocation
*messaging

"Messaging is a technology that enables high-speed, asynchronous, program-to-

program communication with reliable delivery."
Chanel/queue - dijeljena kolekcija poruka
sender - upisuje poruke u chanel
receiver - cita i brise poruke iz kanala

Za sam messaging izmedju aplikacija se brine messaging sistem, koji upravlja

porukama i komunikacijom.

Dva veoma vazna koncepta prilikom asihrone komunikacije su:

*fire and forget - kada aplikacija upise poruku na lokalni kanal, ona zaboravlja na
nju
*store and forward - slanje poruke sa lokalnog kanala, na kanal prijemnika tj. na
njegov kompjuter. Ovaj proces se moze ponavljati vise puta, ako iz nekog razloga
slanje poruke nije proslo.

---Zasto koristiti messaging?---

*Remote communication
*Platform/language integration - In these circumstances, a messaging system can be
a universal translator between the applications that works with each one’s language
and platform on its own terms, yet allows them to all communicate through a common
messaging paradigm. This universal connectivity is the heart of the Message Bus
pattern.
*Asynchronous Communication
*Variable Timing - svako moze primati ili slati poruke brzinom koja njemu odgovara,
kao i u trenucima koji njemu odgovaraju.
*Reliable Communication - store and forward omogucava sigurnost dostave, za razliku
od RPCa
*Thread Management

------

integrated applications are independent applications that can each run by itself,
but coordinate with each other in a loosely coupled way.

UMLEAI - ( EAI - enterprise application integration) - prosirenje UMLa, tako da je

pogodan za prikazivanje integration patterna.

---Solving integration problems using patterns---

Prilikom kreiranja velikih enterprise aplikacija, funkcionalnosti se odvajaju u

vise aplikacija, kako bi se olaksao rad i smanjila kompleksnost posla koju svaka
aplikacija po na osob treba obavljati. Rad nad velikim aplikacijama, sa velikim
brojem ljudi je gotovo nemoguce za izvedbu. Podjela sistema na vise aplikacija
donosi problem komunikacije izmedju servisa, koju je potrebno (u zavisnosti od
situacije) adekvatno rijesiti.

Jedan od cestih problema prilikom integracije legacy sistema je kolicina izmjena,

tj. pristup kodu i kolicina dozvoljenih izmjena koja se smije izvrsiti nad datim
sistemom.

---how can integration patterns help---

We intentionally left the definition of “integration” very broad. To us it means

connecting computer systems, companies or people.

Najcesci tipovi integracije su:

*Information Portals
Ukoliko korisnik ima potrebu da za jednu akciju mora pozivati vise sistema.
Information portals agregiraju podatke.

*Data Replication
Ukoliko vise servisa treba da ima iste, replicirane podatke. Moze se
implementrati putem replikacijskih funkcija koje nude neke baze podataka, ili pute
message-orijentisanog middlewarea za transport podataka kroz poruke.

*Shared Business Functions

Kao sto i podaci mogu biti zajednicki, moguce je da vise dijelova sistema ima
potrebu za zajednickom funkcijom. Rjesavanje ovog problema moze rijesti i neke
probleme koji se javljaju i prilikom data replicationa.

*Service-Oriented Architectures
These two functions, service discovery and negotiation, are the key elements
that make up a service-oriented architecture.On the other hand a service-oriented
architecture usually provides tools that make calling an external service almost as
simple as calling a local method (performance considerations aside). Because all
services are available in a consistent manner, SOAs are sometimes referred to as
“service bus architectures”.

*Distributed Business Processes

Komponenta koja koordinira i nadgleda proces koji se izvrsava preko vise
servisa unutar sistema.

*Business-to-Business Integration
Nacin integracije odvojenih sistema, koji funkcionisu zajedno.

---Loose coupling---

Osnovni princip loose couplinga je smanjiti pretpostavke koje dvije

aplikacije/komponente/itd. stvaraju jedno o drugoj prilikom razmjene informacija.

Waldo et al. reminded us back in 1994 that "objects that interact in a distributed
system need to be dealt with in ways that are intrinsically different from objects
that interact in a single address space" [Waldo]

In summary, trying to portray remote communication as a variant of a local method

invocation is asking for trouble. Such architectures typically result in brittle,
hard to maintain and poorly scalable solutions.

Rjesavanje ovih problema se moze izvesti na sljedeci nacin:

-Koristenje standardiziranih formata za slanje podataka XML/JSON
-Koristenje kanala za slanje poruka, gdje kanal predstavlja virtualnu adresu oko
koje su se dogovorili oba clana komunikacije. Na ovaj nacin ucesnici ne moraju biti
svjesni jedan drugoga, vec samo kanala na koji salju poruke.
-Transformacije se desavanju u kanalu.
-Queue unutar kanala za izbjegavanje temporalne/vremenske ovisnosti izmedju
servisa.

Ovim se uvodi kompleksnost u nas kod, koja zahtjeva izgradnju middlewarea koji ce
se brinuti o komunikaciji i porukama vezene za komunikaciju izmedju servisa.

Osnovni elementi middlewarea su endpoint, poruka, kanal, rutiranje, translacija i

system management.

--Integracijski stilovi--
Prilikom integracije samih aplikacija potrebno je razmotriti sljedece cinjenice:
Grupisanje podataka - Aplikacije koje su integrisane medjusobno trebaju imati
minimalnu zavist jedna od druge, na ovaj nacin svaka aplikacija moze rasti i
razvijati se za sebe bez da na taj nacin utjece na drugu aplikaciju.
Jednostavnost integracije - integracija aplikacija bi trebala minimalno uticati na
biznis logiku i na kod.
Tehnologija integracije - neke su bolje neke losije
Format podataka - obje aplikacije se trebaju dogovoriti oko formata podataka ili
imati prevodioca izmedju sebe.
Asihronost

-Messaging-
Sending a message does not require both systems to be up and ready at the same
time.