MODUL ARSITEKTUR BERBASIS LAYANAN

(SERVICE-ORIENTED ARCHITECTURE, SOA)

(PTI414)

MODUL SESI 12
ENTERPRISE SERVICE BUS (ESB)

DISUSUN OLEH
ADI WIDIANTONO, SKOM, MKOM.

UNIVERSITAS ESA UNGGUL

2021

Universitas Esa Unggul

http://esaunggul.ac.id
 Enterprise Service Bus (ESB)

A. Kemampuan Akhir Yang Diharapkan

Setelah mempelajari modul ini, diharapkan mahasiswa mampu :

1. Memahami konsep teknologi Enterprise Service Bus.
2. Memahami pemanfaatan ESB dalam Arsitektur Berbasis Layanan dengan baik.

B. Uraian dan Contoh

Universitas Esa Unggul

http://esaunggul.ac.id
1. Enterprise Service Bus
1.1. Konsep
Konsep ESB merupakan dapat dianalogikan dengan konsep bus yang ditemukan
dalam arsitektur perangkat keras komputer yang dikombinasikan dengan desain
modular dan bersamaan dari sistem operasi komputer berkinerja tinggi. Motivasi
pengembangan arsitektur adalah bertujuan untuk menemukan konsep standar,
terstruktur, dan umum untuk menggambarkan implementasi komponen perangkat lunak
yang digabungkan secara longgar (disebut layanan/service ) yang diharapkan dapat
digunakan secara independen, heterogen, dan berjalan dalam jaringan yang berbeda.
ESB juga merupakan pola implementasi umum untuk arsitektur berorientasi layanan,
termasuk desain jaringan World Wide Web yang diadopsi secara intrinsik.

Tidak ada standar global untuk konsep atau implementasi ESB. Namun sebagian
besar penyedia middleware yang berorientasi pesan telah mengadopsi konsep ESB
sebagai standar de facto untuk arsitektur berorientasi layanan (SOA). Implementasi
ESB menggunakan middleware berorientasi pesan yang digerakkan oleh event dan
berbasis standar dalam kombinasi dengan antrian pesan sebagai kerangka kerja
teknologi. Namun, beberapa produsen perangkat lunak memberi nama ulang
middleware dan solusi komunikasi yang ada sebagai ESB tanpa mengadopsi aspek
penting dari konsep bus.

Sebagai permulaan, Enterprise Service Bus (ESB) disebut juga Enterprise

Architecture Interface (EAI) hanyalah sebuah arsitektur perangkat lunak yang
terintegrasi dengan serangkaian aturan dan prinsip yang dapat mengintegrasikan
serangkaian aplikasi yang berbeda dalam satu infrastruktur. ESB adalah arsitektur
seperti bus di mana pengembang perangkat lunak dapat mengintegrasikan aplikasi
yang berbeda dan memungkinkan komunikasi di antara mereka. Dengan cara ini,
aplikasi perangkat lunak berkomunikasi atau "berbicara" dengan bus.

Arsitektur ESB adalah middleware, artinya perangkat lunak yang ada untuk
menyatukan program yang ada dan kompleks dan melakukannya dengan
menghubungkan semua jenis aplikasi dan layanan lain-lain.

Universitas Esa Unggul

http://esaunggul.ac.id
 Jadi ESB, atau bus layanan perusahaan, adalah pola arsitektur di mana
komponen perangkat lunak terpusat melakukan integrasi antar aplikasi. Ini melakukan
transformasi model data, menangani konektivitas, melakukan perutean pesan,
mengubah protokol komunikasi, dan berpotensi mengelola komposisi beberapa
permintaan. ESB dapat membuat integrasi dan transformasi ini tersedia sebagai
antarmuka layanan untuk digunakan kembali oleh aplikasi baru.

Pola ESB biasanya diimplementasikan menggunakan integrasi runtime dan toolset

yang dirancang khusus (yaitu, produk esb) yang memastikan produktivitas sebaik
mungkin.

Gambar 1.1. Konsep Arsitektur ESB

Universitas Esa Unggul

http://esaunggul.ac.id
 1.2. Fungsi ESB
ESB menerapkan konsep desain sistem operasi modern untuk layanan
independen yang berjalan dalam jaringan komputer yang berbeda dan independen.
Seperti sistem operasi bersamaan, ESB menyediakan layanan komoditas selain adopsi,
terjemahan, dan perutean permintaan klien ke layanan penjawab yang sesuai.
Tugas utama ESB adalah:
 Rutekan pesan antar layanan
 Memantau dan mengontrol perutean pertukaran pesan antar layanan
 Selesaikan perselisihan antara komponen layanan yang berkomunikasi
 Mengontrol penerapan dan pembuatan versi layanan
 Marshal menggunakan layanan yang berlebihan
 Menyediakan layanan seperti penanganan event, transformasi dan pemetaan data,
antrian dan pengurutan pesan dan event, penanganan keamanan atau
pengecualian , konversi protokol dan menerapkan kualitas layanan komunikasi
yang tepat.

Fungsi utama dari ESB dapat diilustrasikan pada gambar berikut ini :
 Transparasi Lokal

 Transport Protocol Conversion

Universitas Esa Unggul

http://esaunggul.ac.id
 Message Routing

 Message Enhancement

 Security

Universitas Esa Unggul

http://esaunggul.ac.id
 Monitoring dan Management

1.3. Mengapa Membutuhkan ESB?

Jika diinginkan melakukan interface antara aplikasi enterprise tanpa ESB dapat
digambarkan seperti gambar dibawah ini.

Gambar 1.2. Point to Point Architecture without EAI/ESB

Diperlukan banyak perangkat lunak yang menyediakan interface antar aplikasi yang
berbeda-beda, dan spesifik. Jika terjadi perubahan di salah satu aplikasi, maka
interface juga akan mengalami perubahan, menjadi rumit dan tidak fleksibel.

Universitas Esa Unggul

http://esaunggul.ac.id
 Jika menggunakan ESB, maka arsitektur menjadi seperti pada gambar dibawah
ini.

Gambar 1.3. Using ESB over Point to Point

Manfaat
Dari arsitektur pada gambar 1.3. Secara teori, ESB terpusat menawarkan potensi untuk
menstandarisasi—dan secara dramatis menyederhanakan—komunikasi, pengiriman
pesan, dan integrasi antar layanan di seluruh perusahaan. Biaya perangkat keras dan
perangkat lunak dapat dibagi, menyediakan server sesuai kebutuhan untuk
penggunaan gabungan, memberikan solusi terpusat yang terukur. Satu tim spesialis
dapat ditugaskan (dan, jika perlu, dilatih) untuk mengembangkan dan memelihara
integrasi.

Aplikasi perangkat lunak cukup menghubungkan ('berbicara') ke ESB dan

menyerahkannya ke ESB untuk mengubah protokol, mengarahkan pesan, dan
mengubah ke dalam format data yang diperlukan dengan menyediakan interoperabilitas
untuk menjalankan transaksi. Pendekatan arsitektur bus layanan perusahaan
mendukung skenario untuk integrasi aplikasi, integrasi data, dan otomatisasi gaya
orkestrasi layanan dari proses bisnis. Hal ini memungkinkan pengembang
menghabiskan lebih sedikit waktu untuk mengintegrasikan dan lebih banyak waktu
berfokus pada penyampaian dan peningkatan aplikasi mereka. Dan kemampuan untuk
Universitas Esa Unggul
http://esaunggul.ac.id
menggunakan kembali integrasi ini dari satu proyek ke proyek berikutnya menawarkan
potensi peningkatan produktivitas dan penghematan yang lebih besar di hilir.

Kelemahan
Sementara ESB berhasil diterapkan di banyak organisasi, tetapi di banyak organisasi
lain ESB dipandang sebagai penghambat. Membuat perubahan atau peningkatan pada
satu integrasi dapat mengganggu kestabilan orang lain yang menggunakan integrasi
yang sama. Pembaruan pada middleware ESB sering memengaruhi integrasi yang ada,
sehingga diperlukan pengujian signifikan untuk melakukan pembaruan apa pun. Karena
ESB dikelola secara terpusat, tim aplikasi segera menunggu dalam antrean untuk
integrasi mereka. Seiring dengan meningkatnya volume integrasi, penerapan
ketersediaan tinggi dan pemulihan bencana untuk server ESB menjadi lebih mahal.
Dan sebagai proyek lintas-perusahaan, ESB terbukti sulit untuk didanai, membuat
tantangan teknis ini menjadi lebih sulit untuk diselesaikan.

Pada akhirnya tantangan untuk mempertahankan, memperbarui, dan menskalakan

ESB terpusat terbukti sangat besar dan mahal sehingga ESB sering menunda
perolehan produktivitas yang dimaksudkan untuk menghasilkan, dan SOA, membuat
lini tim bisnis frustrasi yang mengantisipasi kecepatan yang lebih besar dari inovasi.

1.4. Contoh Penerapan ESB

Berikut ini kita lihat bagaimana menerapkan ESB pada arsitektur monolithic/n-tier.
Pada gambar 1.4. merupakan arsitektur tipikal untuk aplikasi berbasis JEE. Diharapkan
akan membangun aplikasi khusus pengguna (client) yang merupakan gabungan
informasi dari aplikasi enterprise lainnya. Dalam padangan dari sisi pengguna, maka
tidak perduli dibelakangnya ada aplikasi lain yang mendukung. Maka pandangan dari
sisi pengguna (client) dapat dilihat pada gambar 1.5. Kemudian diterapkan integrasi
aplikasi-aplikasi dalam arsitektur n-tier (gambar 1.6).

Universitas Esa Unggul

http://esaunggul.ac.id
 Gambar 1.4. Tipikal arsitektur aplikasi monolithic/n-tier

Gambar 1.5. pandangan aplikasi disisi pangguna

Universitas Esa Unggul

http://esaunggul.ac.id
 Gambar 1.6. Integrasi Aplikasi

Integrasi aplikasi diterapkan solusi dengan konsep ESB, maka arstiektur menjadi
seperti pada gambar 1.7.

Gambar 1.7. Arsitektur dengan solusi ESB

Universitas Esa Unggul
http://esaunggul.ac.id
2. ESB dan SOA
2.1. Arsitektur
Dilihat dari sisi arsitektur, Enterprise Service Bus hanyalah sebuah arsitektur
perangkat lunak yang terintegrasi dengan serangkaian aturan dan prinsip yang dapat
mengintegrasikan serangkaian aplikasi yang berbeda dalam satu infrastruktur.
Arsitektur ESB adalah middleware, artinya perangkat lunak yang ada untuk
menyatukan program yang ada dan kompleks dan melakukannya dengan
menghubungkan semua jenis aplikasi dan layanan lain-lain.

Di sisi lain, SOA, atau Arsitektur Berorientasi Layanan, juga merupakan arsitektur
perangkat lunak yang digunakan untuk membangun aplikasi bisnis yang berfokus pada
pengembangan berbasis layanan dan hasil akhir dari layanan tersebut. Dengan kata
lain, arsitektur berorientasi layanan adalah jenis desain perangkat lunak di mana
layanan disediakan oleh komponen aplikasi melalui serangkaian protokol komunikasi
dalam jaringan.

Dari hal di atas, keduanya adalah arsitektur perangkat lunak, tetapi bukan jenis
arsitektur biasa, tetapi yang berbasis bisnis. Dan, meskipun mereka mungkin tampak
serupa, mereka sebenarnya tidak. SOA dan ESB tidak boleh dilihat hanya sebagai
solusi perangkat lunak, tetapi sebagai prinsip integrasi aplikasi perusahaan. Pada
dasarnya, SOA harus dianggap sebagai seperangkat ide untuk mendekati integrasi
aplikasi, sedangkan ESB adalah inti sebenarnya dari struktur arsitektur ini.

Jika diperhatikan (gambar 2.1.), maka ESB adalah alat yang dapat digunakan
untuk mencapai prinsip dan ide yang menyusun SOA. Sederhananya, dalam konsep,
baik SOA dan ESB adalah arsitektur perangkat lunak, tetapi ketika mempraktikkannya,
SOA menjadi tujuannya, sedangkan ESB menjadi alat yang memungkinkan integrasi
aplikasi perangkat lunak dan komponen dapat digunakan untuk memberikan layanan
dan meningkatkan kelincahan dalam proses pengembangan perangkat lunak.

Pikirkan seperti ini, SOA adalah arsitektur berorientasi layanan yang

memungkinkan layanan yang dipisahkan untuk berinteraksi satu sama lain, terlepas
dari platform atau protokol yang dimilikinya. Namun, cara pertukaran data ini
dimungkinkan melalui ESB. Pada dasarnya, ESB bertindak seperti tulang punggung
arsitektur SOA dan kemungkinan besar akan hadir dalam arsitektur perangkat lunak
berbasis integrasi aplikasi.
Universitas Esa Unggul
http://esaunggul.ac.id
 Gambar 2.1. Contoh Arsitektur SOA dengan ESB

Sekarang sudah diketahui bahwa kedua arsitektur ini sangat berbeda satu sama
lain, dalam arti SOA fokus pada membangun aplikasi bisnis yang dapat dengan mudah
diratakan dan memungkinkan perusahaan untuk tumbuh, sementara bus layanan
perusahaan hanyalah bagian dari strategi untuk melakukan itu, itu saatnya untuk
mempertimbangkan penerapan ESB untuk mencapai arsitektur berorientasi layanan.

2.2. ESB dan MicroService

Arsitektur layanan mikro memungkinkan internal satu aplikasi dipecah menjadi bagian-
bagian kecil yang dapat diubah, diskalakan, dan dikelola secara independen. Layanan
mikro muncul dan memperoleh kekuatan dengan munculnya virtualisasi , komputasi
awan , praktik pengembangan Agile, dan DevOps . Dalam konteks ini, layanan mikro
menawarkan yang berikut:

 Peningkatan kelincahan dan produktivitas, pengembang dengan memungkinkan

pengembang menggabungkan teknologi baru ke dalam satu bagian aplikasi tanpa
menyentuh atau 'mengejar' bagian lain dari aplikasi.
Universitas Esa Unggul
http://esaunggul.ac.id
 Skalabilitas yang lebih sederhana dan lebih hemat biaya, dengan memungkinkan
komponen apa pun untuk diskalakan secara independen dari yang lain, untuk
kemungkinan respons tercepat terhadap tuntutan beban kerja dan penggunaan
sumber daya komputasi yang paling efisien.

 Ketahanan yang lebih besar, karena kegagalan satu komponen tidak berdampak
pada yang lain, dan setiap layanan mikro dapat melakukan persyaratan
ketersediaannya sendiri tanpa mempertaruhkan komponen lain ke persyaratan
'ketersediaan umum terbesar'.

Granularitas yang sama yang dibawa layanan mikro ke desain aplikasi dapat dibawa ke
integrasi, dengan manfaat serupa. Ini adalah ide di balik integrasi tangkas , yang
memecah ESB menjadi komponen integrasi yang terdesentralisasi dan berbutir halus,
tanpa saling ketergantungan, yang dapat dimiliki dan dikelola sendiri oleh tim aplikasi
individu.

Gambar 2.2. Contoh Arsitektur Microservice

Universitas Esa Unggul

http://esaunggul.ac.id
 Gambar 2.3. Contoh lain Microservice

ESB dipecah menjadi API sebagai komponen integrasi dengan format/arsitektur API
yang standar dalam bentuk Library yang dapat digunakan komunikasi dan bersifat
independen. Dengan konsep arsitektur ini dan kelebihan dari API (lihat materi
sebelumnya tentang API), hal ini mengatasi kelemahan dari ESB yang telah diuraikan
sebelumnya.

Universitas Esa Unggul

http://esaunggul.ac.id
 2.3. Produk ESB
Notable products include:
Proprietary:
 Candle's Roma ESB - bought by IBM and became WebSphere ESB
 IBM App Connect, formerly IBM Integration Bus and IBM WebSphere ESB
 InterSystems Ensemble
 Information Builders iWay Service Manager
 Microsoft Azure Service Bus
 Microsoft BizTalk Server
 Mule ESB
 Oracle Enterprise Service Bus
 Progress Software Sonic ESB (acquired by Trilogy)
 SAP Process Integration
 TIBCO Software ActiveMatrix BusinessWorks
 webMethods enterprise service bus (acquired by Software AG)
 Sonic ESB from Aurea
Open-source software :
 Apache Camel
 Apache ServiceMix
 Apache Synapse
 Fuse ESB from Red Hat
 JBoss ESB
 NetKernel
 Open ESB
 Petals ESB
 Spring Integration
 UltraESB
 WSO2 ESB

Universitas Esa Unggul

http://esaunggul.ac.id
C. Daftar Pustaka

1. H. Taylor, Service-Oriented Architecture (SOA) 101 What’s Hype – What’s Real,

Juniper Network Inc. 2007.
2. Wiehler, Gerard, Mobility, Security and Webservice: Technologies and Service-
Oriented Architecture for new era of IT Solution, Public Corporate Publishing,
2004.
3. What’s Service-Oriented Architecture?, Software Development Community, 2019
4. Pattern: Service-Oriented Arschitecture and Web Service, IBM RedBook, 2004
5. https://en.wikipedia.org/wiki/Enterprise_service_bus
6. https://www.rootstack.com/en/blog/esb-vs-soa-key-differences-keep-mind

Universitas Esa Unggul

http://esaunggul.ac.id