Chapter 1

ESB je novi pristup integraciji koji omogucava loosely coupled, visoko

distribuirane integracijske mreze. Ono kombinuje messaging, web servise, data
transformacije i inteligentno rutiranje.

ESB u kontekstu SOA omogucava integraciju vise servisa u logicku cjelinu,

omogucavanjem asihrone komunikacije medju njima.

Chapter 2

Prica oko stvari kojima je potrebna integracija ili oni koji su to lose uradili:
The accidental architecture - nastaje kao rezultat nepostojanja integracijske
strategije na nivou koorpooracije. Svako vodi svoju politiku. Stvara se krhka i
rigidna invrastruktura, koja nije kohezivna i tesko podnosi promjene.

-Business drivers motivating integration-

nista pametno za rad.

-The current state of enterprise integration-

Sometimes the application is considered a legacy system in which you are unwilling
or unable to make changes simply beacuse it has been put into maintenance mode.

Problemi sa accidental architectures:

*Nepouzdanost - Nemogucnost koristenja asihronih poruka. Ako veci proces propadne,
potrebno je transakcijski vratiti citav proces i poceti iz pocetka.

*Analiza performansi i skalabilnosti - jako je tesko napraviti procjenu.

*Rjesavanje problema postaje tesko zbog nepostojanja adekvatne dijagnostike i

izvjestavanja. Ovaj problem povecava troskove odrzavanja i posjedovanja sistema.

*Tesko je definisati Service-Level Agreements zbog nepostojanja konzistentnog

nacina integracije.

*Monitoring and managament - ne postoji konzistentan nacin da se prati i upravlja

slucajnom arhitekturom.

Na 31. stranici ima fina lista stvari koje ne valjaju na ovim arhitekturama.

Ovaj dio oko slucajne arhitekture predstavlja fin dio za zavrsni, jer legacy
aplikacija nije ocekivala integraciju sa sistemom novim, treba je osmisliti bla
bla.

**ISTRAZI HUB-AND-SPOKE i EAI BROAKER**

EAI brokeri pomazu protiv "slucajne arhitekture" koristenjem hub-and-spoke

arhitekture, tj. centralizovanim rutiranjem. Takodjer, pomazu u razdvajanju biznis
procesa od integracijskog koda koristeci se BPM(business process management)
softverom. Hub-and-spoke ne daje regionalnu kontrolu. BPM alati napravljeni navrh
hub-and-spoke topologije ne mogu kreirati koreografiju ili poslovni proces koji se
prostire kroz poslovne jedinice.

--Leveraging Best Practices from EAI and SOA--

*Prihvatanje XMLa
*Adopt Web Services and implement SOA
Razmisljanje i planiranje u pogledu SOA je osnovni korak u
 u refaktorisanju ka ESBu. Service-level interfejsi pruzaju zajednicki
sloj apstrakcije koji stvara granicu/razdvojenost izmedju interfejsa i
implementaciju.

-Refactoring to ESB-
Prvi korak bi bio uvodjenje ESB-a na jednom projektu.
Service containers?? (Chapter 6) - Sluzi za konektovanje na ESB (valjda)
Za konektovanje starih aplikacija, moguce je koristiti mostove, tako da se na
starim aplikacijama koje jos nisu usle u koristenje busa direktno, ne moraju
praviti nikakve izmjene.

Sljedeci korak je uvodjenje ESBa na ostalim aplikacijama (dijelovima sistema), tako

da dva ili vise postojecih ESBova mogu medjusobno komunicirati.

Sljdeci korak (nakon sto je citav interni sistem presao na ESB) je ukljucivanje
partera.

or it could involve installing an ESB node at the partner site as well. The
decision of which approach to use could depend entirely on how close a relationship
your organization has with the partner, whether the partner would allow you to
install software at their site, or whether they already have an ESB that can link
with yours.

---Chapter 3---

ESB je arhitektura.
Tehnologije koje su katalizirale kreaciju ESBa su Java message service, Applicatoin
servers, EAI...

Slika historje ESBa i tehnologija koje su joj prethodile. (mogla bi biti dobar
materijal).

---Chapter 4---

--XML the foundation for business data integration--

XML je postao standard u industriji, kada je u pitanju ramjenu informacija izmedju
aplikacija. Benefiti koje pruza sam xml su:
*XML je globalno prihvacen, te je postao "standard"
*XML daje mogucnost predstavljanja kompleksnih objekata na jednostavan nacin.
Omogucuje zapisivanje lista, hijerarhije... na mnogo jednostavniji nacin od npr
RDBMs-a kojem su potrebne tabele, spojevi medju tabelama itd
*XML ima svojstvo samo-opisivosti
*XML je loosley coupled sa podacima koje predstavlja, odnosno nije "zakovan"
nikakvom prethodnom shemom.
*XML nije ogranicen formatom koji moze biti upisan(mislim da je ovo povezano i sa
ovom prethodnom stavkom)
*XML je citljiv i za korisnika

*XML je moguce i nadograditi bez katastrofalnog ucinka po slusaoce poruka. Ukoliko

se stvori potreba za dodavanjem novog polja unutar XMLa, jedino ce slusaoci tog
dijela poruke morati napraviti korekcije, dok ce slusaoci ostalih dijelovai ste
poruke ostati nepromijenjeni. Ovo omogucava da se svaka aplikacija prosiruje
neovisno od drugih, tj da su aplikacije medjusobno loosely ocupled.

by applying some basic ESB concepts: a business process definition, content-based

routing, and data transformation. All of these concepts are inherently part of the
ESB.

A business process definition represents a series of steps in a flow between

applications. For example, a purchase order document might follow these basic,
logical steps: credit check, inventory check, order fulfillment, and invoice.
Koristeci se buseiness process definicijom, moguce je primijeniti flow podataka, a
da se pri tome aplikacije ne mijenjaju.
Moguce je pri tome koristiti data transormacije, koje su dio ESBa, kako bi svaka
aplikacija dobila ocekivanu poruku. Medjutim, ovaj nacin tranformacije ne skalira
dobro.The downside of this approach is that it requires direct knowledge of each
point-to-point interaction between the various flavors of X and Y applications

CBR - Content-based routing - ovo doprinosi rjesavanju gore navedenog problema.

-Data translation to and from a canonial format-

Canonical data predstavlja neki set formata poruka unutar necijeg ESBa. (Treba ovo
mozda jos malo protaboriti).
Transformacija u ovaj fromat poruke/a se ne mora desiti odjednom, moguce je
koristiti tranformacije poruka u pocetku, dok se svi ne adaptiraju.

Alternative ovom nezgrapnom cudu opisanom gore:

Da li je potreban transformation engine za svaki ulazni sistem u ESB?

Applying the canonical XML data exchange technique on a larger scale yields the
following benefits:

Each application needs to focus on only one type of transformation to and from a
common format. This illustrates an important philosophy of the bus that will be
reinforced throughout the book. If you are the owner of an individual application,
your only concern is that you plug into the bus, you post data to the bus, and you
receive data from the bus. The bus is responsible for getting the data where it
needs to go, in the target data formats that it needs to be in, and using the
protocols, adapters, and transformations necessary to get there.

New applications being written to plug into the bus can use the canonical XML
format directly. And multiple applications not anticipated today can tap into the
flow of messages on the bus to create heretofore unimagined uses.

ESB services such as the CBR and the splitter can be written to use the canonical
XML format. As we will see in Chapter 7, a service type can be written once and
then customized on a per-instance basis by supplying different XSLT stylesheets,
endpoint definitions, and routing rules. Having an agreed-upon format for common
things such as address tags and purchase order numbers can be a tremendous
advantage here.

Standard stylesheet templates and libraries can be created and reused throughout
the organization.

---Chapter 5---Message oriented middleware---

applications are abstractly decoupled; senders and receivers are never aware of
each other.Instead, they send and receive messages to and from the messaging
system. It is the responsibility of the messaging system (MOM) to get the messages
to their intended destinations. (pogledaj sliku)The messaging system is usually
implemented as a software process, which is commonly known as a message server or a
MESSAGE BROKER. - OVO JE BITNO!!!! Serveri se mogu grupisati u klastere kako bi se
radile razlicite karafeke (load balancing, fault tolerance, sofisticirano
rutiranje...)

-Tightly Coupled Versus Loosely Coupled Interfaces-

Prica o RPC...
Asynchronous request/response patterns are also possible

Svaka aplikacija se samo mora brinuti oko stvari koje salje i da ih je poslala
MOMu, response ce primiti naknadno. Cononical data format smanjuje broj
transformacija.
If you are the owner of a service or an application domain, you need only be
concerned with three operations: plugging into the bus, posting data to the bus,
and receiving data from the bus.

-MOM concepts-

Abstract decoupling - messageing aplikacije koriste messaging client API kako bi

komunicirale jedna sa drugom preko messaging sistema. Aplikacije imaju dvije uloge:
konzument ili producent. Takodjer, jedna aplikaicja istovremeno moze biti i
producent i konzument. Producent kreira i salje poruke, dok ih konzument prima. Ove
dvije uloge su loosley coupled kroz virtuelne kanale (publish-subscribe kanale,
point-to-point kanale...njih zovu topics and queues - ova dva tipa
kanala...valjda).

Producent ne mora znati kome salje poruku, niti koliko ljudi slusa poruku, kao sto
ni konzument ne mora znati od koga prima poruku. Ukoliko postoji potreba za
odgovorom na poruku, poruka zadrzi "ReplyTo" atribut, putem kojeg aplikacija zna
kome da odgovori tj. na koji kanal.

Messaging models:
*Publish-subscribe - namjenjeno za 1-to-many komunikaciju - ukoliko niko ne
primi poruku ona moze biti odbacena
*Point to point - namjenjeno za jedng primaoca - Moze vise aplikacija slusati
(npr. u cilju load balancinga), ali ce samo jedna ili nijedna aplikacija primiti
poruku. Poruka ostaje u redu dok je neko ne pokupi.
(ima fina slika pogledaj)

Topic hijerarhija - Nacin imenovanja topica tj tema, tj grupacija poruka. Mogu se

posloziti u stablo nesto.nesto.nesto, tako da je veoma lagano subscribati se na
jednu ili vis tema.

ACL - access control list - mogu se kreirati prava pristupa za razlicite korisnike.
A message is typically composed of three basic parts: the headers, the properties,
and the message payload or body (Figure 5-9). The headers are used by both the
messaging system and the application developer to provide information about things
such as the destination, the reply-to destination, the message type, and the
message expiration time.The format of the message payload can vary across messaging
implementations. Most common formats are plain text, a raw stream of bytes for
holding any type of binary data, or a special XML message type that allow the
message payload to be accessed using any number of common XML parsing technologies.

-Asynchronous Reliability-
Tri su djela pouzdanog asihronog komuniciranja:
*Message autonomy -poruke su self-contained, autonomni entiteti koji predstavljaju
biznis transakciju. Kada producent posalje poruku, njegov posao je gotov. Na ESBu
je da tu porukusigurno posalje do primaoca.

*Store and forward - Postoje garantovane dostavne semantike, koje garantuju da ce

poruka biti dostavljena i trenutno nedostupnim servisima kasnije.emantics cover a
range of delivery options, from exactly-once delivery to at-least-once delivery to
at-most-once delivery. In the exactly-once (a.k.a. once-and-only-once) delivery
mode.xactly-once delivery guarantee is accomplished in part by the use of a
technique known as store and forward (see Figure 5-10).
Opisuje sada pojedninacne. Npr at-most-once ima mnogo vecu propusnost.
Jos jedan QoS je garantovani redoslijed dostave poruka

*Message Acknowledgments - izvrsava se na "wire protocol level" TCP UDC? ili sta je
vec u pitanju? Ovo je kljucni faktor kako bi Messaging sistem znao u kojem su
stadiju poruke.

-Reliable Messaging Models-

Reliable Publish-and-Subscribe
When an application registers its interest in receiving messages on a
particular topic, it can specify that the subscription is durable. A durable
subscription will survive the failure of the subscribing client. This means that if
the intended receiver of a message becomes unavailable for any reason, the message
server will continue to store messages on behalf of the receiver until the receiver
becomes available again. Ima fina slikica.

Reliable Point-to-Point Queues

Poruke mogu biti perzistentne i neperzistentne. but it is not guaranteed to
survive a failure and recovery of the messaging server - neperzistentne poruke.

Neka prica o store and forward...kako se poruka moze kretati kroz vise messaging
servera.

-Transacted Messages-

Local transaction - Moguce je napraviti slanje vise poruka koje se salju kroz jednu
transakciju, pa da se onda radi commit, kako bi se mogao raditi callback.

-The Request/Reply Messaging Pattern-

Ima fina slika ovog patterna. Koriste se dva kanala za request i response. u
request poruci se nalazi polje reply to. Odgovor sadrzi i Id prvobitne poruke, tako
da se zna na sta se odnosi. "replyto" je samo ideja kako bi se to polje moglo
zvati, a ne standard.
The Reply-Forward Pattern - odgovor ne ide istom, nego nekom drugom servisu. Tj. ne
ide onome ko je originalno poslao poruku.

-Messaging Standards-

The Java Message Service (JMS)

Nista pametno u ovom poglavlju

--Service Containers and Abstract Endpoints--

Many things contribute to making the ESB highly distributed, but the three
components that stand out the most are the use of abstract endpoints for
representing remote services, Internet-capable MOM, and a distributed lightweight
service container.

-SOA Through Abstract Endpoints-

This endpoint abstraction allows an integration architect to use higher-level tools
to assemble service endpoints into process flow.From the point of view of the
integration architect (you), service endpoints are just logical abstractions of
services that are plugged into the bus.

The service endpoint provides an abstraction away from the underlying protocol (or
MOM channel). The ESB allows the underlying protocol to vary depending on the
deployment situation and the QoS requirements.
Diversity in connectivity is a core capability that is fundamental to making the
ESB a realistic approach across a global enterprise.
Because the ESB can support multiple ways of connecting into it, applications don't
require any drastic changes to "get on the bus."
This means that applications should be able to connect into the bus with as little
modification as possible. It is the bus, not the applications, that provides the
flexibility in connection technologies.

Integracijske mogucnosti/uslue ESBa su implementirani kao odvojeni servisi

(transformacijski servis, logging serivs, servis za rutiranje...). Na ovaj nacin se
omogucuje tacno postavljanje onih servisa na onim mjestima na kojima su potrebni.

-The ESB Service Container-

A service container is the physical manifestation of the abstract endpoint, and
provides the implementation of the service interface. A service container is a
remote process that can host software components. In that respect, it has some
similarities to an application server container, but with the specific goal of
hosting integration services. (Ima fina slika).

Skaliranje: An ESB service is also scalable in a fashion that is independent of all

other ESB services. A service container may manage multiple instances of a service
within a container. Several containers may also be distributed across multiple
machines for the purposes of scaling up to handle increased message volume

Ovaj servis ima i endpoint za konfiguraciju kroz koju se namjestaju svi parametri
koji su potrebni za rad ESBa.

(Pogledaj sliku za endpoint)

Application-level auditing, logging, and fault handling are accomplished through
additional endpoints that are available to each service.
Tracking can be handled at both the individual service level and the business
process level.

Ima slika sta sve objedinjava esb container, ne znam da li ima ista interesatno?

Quality of Protection (QoP) and security, Quality of Service (QoS), and transaction
services are also provided to the service via the ESB container. The method of
administration of ESB facilities can range from a full-blown GUI to a command-line
interface to an administrative API, depending on the implementation.

-Service Containers, Application Servers, and Integration Brokers-

Razlika izmedju esb service containera i integration brokera (integration broker je

monolitan i ne skalira)
Razlika izmedju esb service containera i application containera je sto application
container sadrzi samo biznis logiku i ne zamara se sa integracijakom logikom, dok
esb container sadrzi integracijsku logiku, i samo onu biznis logiku koja je
potrebna za integraciju.

Malo treba razjasniti sta je container, sta servis, gdje je ustvari ESB? U svakoj
aplikaciji je sta? Gdje je ESB?

--ESB Service Invocations, Routing, and SOA--

-Find, Bind, and Invoke-

Prije su, standardne SOA aplikacija kreirane kao klijent-server aplikacije,
prilikom pokusaja spajanja klijenta sa serverom zahtjevale da se rade
find/bind/invoke metode. Odnosno morao je postojati registar lokacija servera, onda
bi klijent morao pretraziti registar, izvrsiti spajanje (http) i na kraju poslati
poruku. Ovo je velika prednost ESBa jer klijenske aplikacije ne moraju vise
implementirati ovu logiku.

-ESB Service Invocation-

Like its predecessor, the client-server SOA, an ESB has the concept of a registry
or directory service in which information about service endpoints is stored. An
inherent find/bind/invoke operation occurs as part of the ESB mechanics, but it is
separated out from the business logic.

-Itinerary-Based Routing: Highly Distributed SOA-

The role of the integration architect is to administratively define a composite
business process flow by plugging services together into a message itinerary. The
itinerary represents a set of discrete message routing operations, such as the
basic steps introduced in Chapter 4 (see Figure 7-1).

-Content-Based Routing (CBR)-

Opisani nacini na koji se CBR moze implementirati.

-Service Reusability-
ESB servisi su reusable. Instancira se vise instanci ESB servisa (istog tipa)
kojima se postavljaju razlicite konfiguracije.

-Specialized Services of the ESB-

Postoje nacini na koji se ESB moze poboljsati za rjesavanje nekih kompleksnih
integracijskih problema.

Multi-itinerary splitter pattern

Sometimes you need a more sophisticated means of controlling process flow. More
complex business processes might involve multiple paths of execution to happen in
parallel. These multiple paths can be handled through a combination of process
itineraries and special services by placing a fan-out service within an itinerary
that splits the process into two parallel subprocesses.
Ima fina slika. Na kraju se iskoristi agregator koji spoji poruke (ceka da dodju
sve).

Multi-itinerary CBR pattern

A CBR service may need to choose between multiple possible paths, and at some point
these parallel paths may need to converge. This is commonly known as a join
operation, where a business process blocks and waits for one or more conditions to
be satisfied before proceeding to the next step (Figure 7-12). This is also
accomplished by some coding techniques in an aggregator service.

7.6.2 Sophisticated Process Flow Using an Orchestration Service (BPEL4WS)

An orchestration service is a special processing engine that can be plugged into
the bus to coordinate other services that are on the bus, such as a BPEL4WS engine.
Kada obicne metode nisu dovoljne.
An orchestration service can manage multiple conversations by correlating the
requests with the appropriate responses.

Moguce je dodati i servise za kesiranje i spasavanje XML poruke. Na ovaj nacin se

mogu spasavati neke bitne poruke. Moze se koristiti za reporting.

Tri nacina upravljanja koracima u biznis procesu su opisana u ovom chapteru:

itinerary-based routing, sophisticated process orchestration using an orchestration
service that is layered on top of the ESB, and the XML processing pipeline in an
XML persistence service, also a layered service on top of the ESB

Kada koji koristiti ima fina slikica.

--Protocols, Messaging, Custom Adapters, and Services--

QOS, Clustering i dijeljenje po geografskim lokacijama je sve delegirano na MOM.

The MOM, along with the ESB containers, is deployed in as many places as you have
control over. This is because the MOM provides scalability through clustering of
message servers, a unified view of security, and asynchronous reliable delivery of
messages using the store-and-forward capabilities discussed in Chapter 5.

-MOM interoperability-
When using a MOM, the sender and receiver need a piece of client software supplied
by the MOM vendor in order to participate in a messaging conversation.

Prica oko JMS standarda i da svi MOMovi koji implementiraju ovaj standard pruzaju
mogucnost da se poruke sa jednom MOMa mogu slati na drugi MOM. Cesto se spominje
JMS standard...mozda ga jos istraziti?

-The 80/20 Rule of MOM Backbone Versus External Protocols-

Prica da je 80% korisnenog MOMa od istog vendora u jednom projektu, a da je onih
20% mozda neki MOM od drugog proizvodjzaca pa se mora raditi integracija dva
MOMa...valjda. Ugl ne vjerujem da ce mi ovo trebati.

-Generic Message Invocation Framework-

Slika protokola koji transportuju XML preko ESBa.

Bridging is one way to attach a legacy protocol such as FTP or SMTP (email) into an
ESB. As illustrated in Figure 8-5, an FTP or SMTP bridge is implemented as a
specialized messaging client, which converts data from one protocol to and from the
MOM channel.
An ESB also provides a bridge across MOM implementations.
One form of integrating an ESB MOM core with another protocol is through direct
support for that protocol within the MOM's message broker. In this scenario, the
message broker itself provides the bridging, or mapping, between the external
protocol and the internal MOM channe
The ability to process HTTP requests, both inbound and outbound, is a critical
component that enables two of the four basic parts of an ESB as described by
Gartner: MOM and web services.
This introduces the concept of an HTTP protocol handler, which allows an ESB
message broker to listen for inbound HTTP or SOAP requests, much like a web server
or application server would. The protocol handler performs a mapping of the HTTP
content into a JMS message and places the JMS message into a queue or a pub/sub
topic destination. In an asynchronous messaging environment, a request/reply is
accomplished by setting up two messaging channels: one for the request and one for
the reply.
Sihroni HTTP vrati timeout error (potencijalno) prije vracanja responsa. Asihroni
odmah vrati 200 kao da je primio poruku, i naknadno posalje odgovor HTTPom.
SOAP handler.

-Case Study: Partner Integration-

Nista posebno

--Batch Transfer Latency--

This chapter will examine the most common form of integration being done today: the
practice of performing bulk data transfer and batch updating using Extract,
Transform, and Load (ETL) techniques.
Overnite vise nije opcija jer aplikacija se mora uvijek vrtiti, nema down time-a.
Ne djeluje kao nesto sto je interesantno za zavrsni.
Ideja za zavrsni: napraviti proces migracije na ESB. U ovom chapteru ima primjer.

--Java Components in an ESB--

- Java Business Integration (JBI)-
specification describing the way integration components, such as ESB services, can
be plugged together in a vendor-neutral and portable fashion. the goal of the JBI
EG is to not require the entire J2EE application server stack. The JBI model
consists of a JBI container, which houses JBI Service Engines (SEs), which in turn
hold services.

-The J2EE Connector Architecture (JCA)-

has become a popular means of connecting legacy applications to a Java environment
using a standard set of contracts.
JCA is to applications what JDBC is to database connectivity.
Pogledaj sliku.

-Java Management eXtensions (JMX)-

Java Management eXtensions (JMX) is a technology aimed at management and monitoring
using the Java platform. JMX provides standard interfaces for connecting an
application with a management infrastructure and management consoles. Mnoge stvari
se mogu pratiti sa ovim.

--ESB Integration Patterns and Recurring Design Solutions--

-VETO pattern-
validate, Enrich, Transform, Operate
Bilo bi pozeljno da je validacija prvi korak i centralizovan, tako da svaki naredni
korak ne mora razmisljati o tome.
The Enrich step involves adding additional data to a message to make it more
meaningful and useful to a target service or application.
The Transform step converts the message to a target format.
The Operate step invokes the target service or interacts in some way with the
target application.
Moguce je dodati i routing step.

-The Two-Step XRef Pattern-

Za transformaciju podataka, gdje neka baza ili drugi izvor istine raspolaze sa
zamjenskim podacima. Ovo se moze uraditi sa monolitnim servisom ili sa dva
autonomna servisa (ovaj drugi nacin je ovaj pattern).
Razdvajanje u dva servisa dobijamo skalabilnije rjesenje sa mnogim benefitima
separation of concerna. Prvi servis radi transformaciju, a drugi xref lookup
servis. Oba su konfigurabilni.

-Portal Server Integration Patterns-

A portal application is normally used to pull data from multiple backend sources
and represent it in a unified view via a web browser.
The ESB can act as a reliable buffering mechanism between the portal application
and the backend systems.
Forward Cache
The ability to move data from distributed systems close to the presentation tier
for low-latency, read-only access to the data.
Federated Query
The ability to efficiently query multiple systems and aggregate the responses
asynchronously at the presentation tier.
Djeluje arhaicno i da mi ne treba.

-The Forward Cache Integration Pattern-

--ESB and the Evolution of Web Services--

Opisuje WS standarde, ali trebalo bi ovo neke nove podatke uzeti u razmatranje.