Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012) ISSN: 2089-9815

Yogyakarta, 10 Maret 2012

PENERAPAN ENTERPRISE SERVICE BUS (ESB) SEBAGAI MIDDLEWARE

INTEGRASI BERBASIS SOA
Wiranto Herry Utomo
Program Studi Sistem Informasi, Fakultas Teknologi Informasi, Universitas Kristen Satya Wacana
Jl. Diponegoro 52-60, Salatiga
E-mail:wiranto.utomo@staff.uksw.edu

ABSTRAKS
ESB merupakan salah satu pilar SOA, pilar lainnya adalah WS dan BPEL. ESB merupakan infrastruktur untuk
koneksi layanan SOA dan pertukaran pesan. Fungsionalitas utama ESB adalah melakukan rute, transformasi
protokol serta transformasi pesan atau data. Dengan adanya fungsi transformasi protokol dan pesan pada ESB
ini maka ketidaksesuaian protokol dan data dapat diatasi. ESB juga memudahkan koneksi dan mediasi,
menyederhanakan integrasi serta memudahkan penggunaan ulang komponen-komponen layanan, sehingga
skalabilitas integrasi menjadi tinggi. Pada penelitian ini telah berhasil dilakukan integrasi beberapa web
services yang berasal dari eBay, Yahoo, Amazon dan Paypal dengan menggunakan ESB sebagai middleware
integrasi. Melalui integrasi web services ini telah dapat diketahui pula peran ESB dalam melakukan routing,
dan transformasi pesan dan protocol.

Kata Kunci: ESB, SOA, Web Services, BPEL, integrasi

1. LATAR BELAKANG MASALAH Menurut Shahzadam (2008), SOA merupakan solusi

Sistem bisnis biasanya berkembang dengan
kecepatan yang berbeda dibandingkan dengan sistem
informasi. Seiring waktu, hal ini akan
mengakibatkan persoalan yaitu keselarasan sistem
bisnis dan sistem informasi. Masalah ini juga akan
mengakibatkan aplikasi yang tidak sepenuhnya
mendukung tugas-tugas bisnis. Kadangkala ada
suatu departemen dalam perusahaan yang terlepas
dari proses bisnis utama dan tidak mendukung
kebutuhan bisnis. Akibatnya organisasi menjadi
kurang fleksibel sulit beradaptasi dengan perubahan
di pasar. Hanya perusahaan-perusahaan yang
aplikasinya dengan cepat dan efisien disesuaikan
dengan perubahan kebutuhan bisnis bisa tetap
kompetitif di pasar global.
Ketidakselarasan antara sistem bisnis dan sistem
informasi ini biasa terjadi di hampir tiap perusahaan
atau organisasi. Untuk memperbaiki
ketidakselarasan ini biasanya kurang membawa hasil
karena disebabkan oleh dua hal yaitu 1)
kompleksitas arsitektur TI yang berasal dari aplikasi
yang heterogen, yang dibangun dari arsitektur dan
bahasa pemrograman yang berbeda, serta pada
platform yang berbeda serta 2) aplikasi yang sudah
ada ini harus tetap berjalan pada saat diperbaiki
.Untuk menyelaraskan sistem bisnis dan sistem
informasi tersebut diperlukan integrasi yang
berperan sebagai mediasi antara kedua lapisan
tersebut (Juric, 2010).
Dalam mengelola masalah keselarasan sistem
bisnis dan sistem informasi, telah diajukan beberapa
metode, namun hal ini sulit dicapai dengan hanya
menggunakan pendekatan tradisional. Pendekatan
arsitektural yang terakhir yang berkaitan dengan
keselarasan sistem bisnis dan informasi ini yang
berkaitan dengan integrasi sistem ini adalah SOA.
yang dapat digunakan untuk menyelaraskan
teknologi informasi dengan tujuan bisnis. Dengan
mengadopsi SOA akan dapat membawa ke arah
keseragaman dalam departemen TI/SI yang dapat
pula membawa pada peningkatan penggunaan
sumber daya luar perusahaan.
Selain itu, menurut Juric et al (2010) SOA bukan
merupakan arsitektur baru yang tiba-tiba saja
muncul, tetapi merupakan hasil evolusi metode
integrasi dan arsitektur terdistribusi. Sebelum SOA
telah berkembang metode integrasi antar aplikasi
yang diacu sebagai EAI (Enterprise Application
Integration). EAI awalnya memusatkan pada
integrasi aplikasi di dalam perusahaan (intra-EAI).
Dengan berkembangnya kebutuhan integrasi antar
perusahaan (B2B, business-to-business), maka fokus
EAI telah diperluas menjadi inter-EAI.
Integrasi intra-EAI berarti mengintegrasikan
aplikasi-aplikasi di dalam perusahaan dengan cara
menciptakan layanan-layanan sebagai fungsionalitas
aplikasi yang sudah ada. Integrasi B2B atau inter-
EAI berkaitan dengan pertukaran pesan yang berasal
dari layanan di luar perusahaan. SOA telah
memperbaiki dan memperluas fleksibilitas dari
metode integrasi sebelumnya (EAI) dan arsitektur
terdistribusi dan memusatkan pada penggunaan
aplikasi dan sistem yang sudah ada, interoperabilitas
dan integrasi aplikasi, serta komposisi proses bisnis
dari layanan-layanan atau fungsionalitas yang
disediakan oleh aplikasi.
Adapun sebagai proof of concept integrasi
menggunakan ESB maka akan dibangun aplikasi e-
Shop yang mengintegrasikan Amazon, eBay,
Yahoo!Shoping, dan Paypal (Lihat Gambar 1).

85
 Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012)
Yogyakarta, 10 Maret 2012
Client (Web Browser)
Basisdata
Lokal
Enterprise Service Bus (Java Business Integration)
Amazon eBay Yahoo!Shooping Paypal
Gambar 1. Model aplikasi Eshop
2. ARSITEKTUR INTEGRASI
Menurut Juric (2007), ada empat arsitektur
integrasi yaitu 1) point-to-point, 2) hub-and-spoke,
3) enterprise message bus (JMS) dan 4) ESB / SOA.
Arsitektur point-to-point merupakan sekumpulan
sistem independen yang dikoneksikan melalui
sebuah jaringan. Arsitektur hub-and-spoke
merepresentasikan tahap berikutnya dalam evolusi
integrasi sistem, dengan menggunakan hub sentral
untuk komunikasi antar jaringan. Dalam arsitektur
enterprise message bus, sistem independen
diintegrasikan menggunakan sebuah message bus.
Arsitektur integrasi berbasis SOA, menggunakan
layanan-layanan yang dilewatkan melalui
middleware yang disebut ESB.
Model integrasi point-to-point mempunyai
kelemahan tidak dapat diperluas dan sulit dalam
pemeliharaan. Hal ini berkaitan dengan
kompleksitas dalam mengintegrasikan secara point-
to-point. Pada model integrasi secara point-to-point
ini maka integrasi antara N aplikasi terhadap N
aplikasi lain memerlukan jumlah antarmuka sebesar
N(N-1)/2. Misalkan akan dilakukan integrasi 6
aplikasi maka akan diperlukan 15 antarmuka,
sedangkan untuk melakukan integrasi 150 aplikasi
maka akan diperlukan 11.175 antarmuka. Dengan
semakin banyaknya aplikasi yang akan
diintegrasikan secara point-to-point, akan semakin
sulit dilakukan modifikasi aplikasi tersebut,
demikian pula dalam hal pemeliharaan aplikasi.
Model integrasi hub-and-spoke mirip dengan
model integrasi point-to-point. Yang membedakan
adalah adanya tambahan sebuah hub yang
menghubungkan seluruh aplikasi. Transformasi
pesan dan routing terjadi di dalam hub. Model
integrasi ini merupakan peningkatan dari solusi
point-to-point dengan mengurangi jumlah koneksi
yang diperlukan untuk integrasi. Karena aplikasi
tidak terkoneksi secara langsung dengan aplikasi
lain, maka aplikasi dapat dihilangkan dari topologi
integrasi dengan menghilangkan dari hub. Hal ini
akan mengurangi kekacauan dalam pengaturan
integrasi. Namun ada kelemahan dalam arsitektur
86
ISSN: 2089-9815
hub-and-spoke, yaitu terletak pada sifat hub yang
terpusat. Jika hub mengalami kegagalan maka
keseluruhan integrasi juga akan kegagalan. Selain itu
model integrasi hub and spoke mempunyai
persoalan yaitu teknologi integrasinya
berkepemilikan yang terkunci oleh vendor.
Konsep integrasi aplikasi berbasis SOA pada
awalnya hadir sebagai solusi terhadap masalah
kompleksitas integrasi point-to-point serta integrasi
hub-and-spoke tersebut. SOA merupakan
arsitektural pengembangan aplikasi perangkat lunak
berbasis layanan, maka dalam integrasi layanan-
layanan akan terjadi ikatan-longgar. Hal ini
memungkinkan penggunaan ulang layanan-layanan
yang sudah ada dan menghasilkan aplikasi yang
dapat dibangun dan dirubah secara mudah dan cepat.
Orkestrasi menggunakan WS mempunyai dua
kelemahan yaitu dalam hal skalabilitas dan belum
mampu mengatasi ketidaksesuaian protokol dan
ketidaksesuaian data. Untuk mengatasi hal ini, pada
saat ini telah dikembangkan orkestrasi WS dengan
menggunakan ESB. ESB merupakan infrastruktur
untuk koneksi layanan SOA dan pertukaran pesan.
Fungsionalitas utama ESB adalah melakukan rute,
transformasi protokol serta transformasi pesan atau
data. Dengan adanya fungsi transformasi protokol
dan pesan pada ESB ini maka ketidaksesuaian
protokol dan data dapat diatasi. ESB juga
memudahkan koneksi dan mediasi,
menyederhanakan integrasi serta memudahkan
penggunaan ulang komponen-komponen layanan,
sehingga skalabilitas integrasi menjadi tinggi.
Kelebihan lain orkestrasi WS dengan ESB adalah
memungkinkan lapisan bisnis dan sistem informasi
mempunyai relasi yang lebih dekat, karena
orkestrasi WS disajikan pada abstraksi level tinggi
yang dinamakan proses bisnis dengan
menyembunyikan obyek middleware tradisional
yang telah digunakan untuk mendukung interaksi
bisnis-ke-bisnis. Selain itu, kebutuhan bisnis dapat
secara langsung diterjemahkan ke dalam aplikasi
proses bisnis melalui komposisi WS
3. SERVICE ORIENTED ARCHITECTURE
SOA merupakan kerangka kerja di dalam
arsitektur perusahaan dan bertujuan untuk mencapai
sasaran bisnis yang sama: meminimalkan biaya
kepemilikan, dan menciptakan solusi bisnis yang
fleksibel yang memperbaiki kekokohan bisnis,
mengurangi waktu ke pasar, dan menyediakan
dukungan ekspansi global. SOA secara substansial
berdampak pada keseluruhan aspek kunci dari
arsitektur enterprise. Layanan bisnis yang diajukan
oleh SOA membentuk dasar dari arsitektur bisnis
dan arsitektur proses. SOA membentuk arsitektur
bisnis karena fungsi bisnis dieskpose sebagai
layanan yang dapat dibagi dan dapat digunakan
ulang. Proses bisnis, layanan dan event dikonversi
untuk layanan aplikasi yang sesuai yang
menciptakan dan mendukung arsitektur layanan.
 Seminaar Nasional Teknoologi Informasi dan
d Komunikasi 2012
2 (SENTIKA 2012)
2 ISSN
N: 2089-9815
Yogyakkarta, 10 Maret 2012
2

Layanan sendiri mem mbentuk arssitektur aplikkasi, konnkrit yang diddasarkan pada WS.
sementaraa itu arsitekttur informasi dicapai melaalui Framework WS ini m merupakan framework
fr
standardisasi data daan ketersediaaan data melaalui tek
knologi yang didasarkan secara standaard, yang
antarmukka layanan (Voos-Matthee, 2011) dip
petakan ke dallam model SO OA sebagai berikut:
SOA merupakan arrsitektur peranngkat lunak yangy a. Layanan-layanan direalisaasikan sebagaii WS
dibangunn menggunakaan prinsip-prinnsip perancanngan b. Pesan dideskkripsikan oleh protokol SOA AP
berorientaasi layanan (Erl, 2005; Sterff, 20006; c. Deskripsi dittetapkan oleh WSDL
Kanchanaavipu, 2008; Nikayin, 20009; Reddy ett al, d. Pada model ini, i pendaftaraan layanan
2009; Li et al, 2010),, sedangkan orientasi
o layaanan menggunakaan UDDI
merupakaan konsep dallam rekayasa perangkat luunak Hal ini padda dasarnya ssesuai dengan n korelasi
yang merrepresentasikaan pendekatann berbeda unntuk ditu
unjukkan paada Gambar 2. Pengertiaan umum
memisahkkan kepentinggan. ntang SOA ini digunakaan di banyak
ten k artikel.
Hal ini berarti bahwa
b fungssionalitas sisttem Naamun definisi SOA ini haanya berurusaan dengan
dipecah kek dalam uniit lojik yang lebih kecil yangy asp
pek teknologi SOA. Hal inni sangat berk kaitan erat
dinamakaan layanan. Layanan-layan
L nan ini lepas satu
s denngan solusi beerbasis WS daan kebutuhann nya, tetapi
sama laiin, tetapi meempunyai kem mampuan unntuk konnsep ini dapaat diabstraksikkan untuk meembangun
berinterakksi satu sam ma lain mellalui mekanissme fon
ndasi SOA seccara umum.
komunikaasi tertentu. Karena ittu, Erl (20005) SOA adalahh sebuah benttuk teknologi arsitektur
mendefinnisikan kompponen SOA sebagais layannan, yanng mengikuti prinsip-prinssip berorientassi layanan
deskripsi, dan pesaan. Layanan berkomunikkasi (Errl, 2005). Konsep berorientasi-layaanan ini
dengan yang lainn melalui pesan y
yang meelakukan pendekatan denggan membagii masalah
memungkkinkan interaaksi antar layanan-layannan, bessar menjadi sekumpulan layanan keecil yang
yang diitetapkan oleeh deskripsi.. Dua layaanan berrtujuan untuuk menyeleesaikan perm masalahan
berkomunnikasi satu saama lain yanng diacu sebaagai terttentu. Setelahh seluruh permmasalahan dap pat dibagi
peminta layanan dann penyedia laayanan. Pemiinta dallam beberapaa layanan, sollusi dari perm masalahan
layanan adalah layannan yang mem manggil layaanan tersebut haruus bisa diselesaikan dengan
lain, seddangkan yangg dipanggil disebut
d penyeedia meemungkinkan seluruh layannan berpartisip pasi dalam
layanan. buah orkestrrasi. Untuk itu ada beberapa
seb
Selainn definisi SOA
S oleh Erl,
E masih ada perrmasalahan yangy harus ddimiliki olehh layanan,
beberapa definisi SOA A yang mirip dari
d sumber laain. yaiitu bagaimanaa layanan beerhubungan, bagaimana
b
Kadang kala
k definisi SOA ini dinnamakan sebaagai lay
yanan berkoomunikasi, bagaimana layanan
frameworrk WS, yangg secara umuum dapat diliihat desain, dan bagaimana pesan antarr layanan
did
pada Gam mbar 2. did
definisikan Erll (2005).
Seperti yanng telah diinyatakan paada latar
bellakang masallah, bahwa kkonsep SOA Delivery
meenurut Erl (22005) ini belum memad dai untuk
meelakukan inteegrasi berbassis SOA. Karena K itu
pennelitian ini tidak
t hanya m mengacu pad da konsep
SOOA Delivery saja,
s melainkaan akan meng gacu pada
konnsep lain yanng telah memaanfaatkan ESB sebagai
midddleware integrasi.
i Juuric (2006)) sudah
meemanfaatkan ESB sebagaai arsitektur integrasi
Gambar 2. Service Oriiented Architeecture (Erl, 20005; berrbasis SOA.
Luuthria et al, 2009; Andary-S
Sage, 2010)
4. ENTERPR RISE SERVIC CE BUS (ESB B)
Layannan menyeddiakan layannan ke pubblik, ESB meerupakan infrastruktur untuk
berperan sebagai penyedia layanan yaang meengintegrasikaan aplikasi dan layanaan. ESB
menyediaakan deskripssi layanan nyaa ke pendaftaaran meemperkuat SO OA melalui pengurangan n jumlah,
layanan. Peminta layyanan, memiinta pengirim man ukuuran, dan kommpleksitas anttarmuka antarra aplikasi
layanan dari penyeedia layanann menggunakkan dann layanan-laayanan. ESB B digunakaan untuk
pendaftarran layanan inni. Dua layanaan ini diikat satu
s meelakukan koneeksi komponenn perangkat lu unak yang
sama lainn, untuk pertuukaran data daan menggunakkan suddah ada dan yang
y baru unttuk membangu un sebuah
fungsionaalitas lain. Inni sesuai denngan definisi Erl SO
OA. ESB dipeerlukan untuk melakukan koneksik ke
yang dipperluas dengaan pendaftarann layanan. Pada bebberapa sumbeerdaya TI. ESB B harus fleksiibel untuk
pendaftarran layanan inni, layanan dapat
d didaftarkkan meenggabungkann dan memassang ulang komponen k
dengan deskripsi
d layannan nya, sehinngga layanan ini sessuai dengan perubahan kkebutuhan bissnis. ESB
dapat dittemukan oleh peminta layaanan. Dalam hal meelakukan koneeksi komponeen yang terikaat longgar,
ini Erl memperluas
m definisinya tenntang SOA yang seh
hingga meenyediakan kemampuan n untuk
masih sangat
s menddasar dengann menggunakkan meengintegrasikaan sistem ke dalam SOA dan men-
frameworrk WS, yang merupakan
m deefinisi SOA yang depploy secara bertahap
b (Juric, 2007; And dary-Sage,

87
 Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012)
Yogyakarta, 10 Maret 2012
2010).
Pendekatan services bus untuk integrasi adalah
menggunakan teknologi yang menyediakan bus
untuk integrasi aplikasi. Aplikasi-aplikasi yang
berbeda tidak berkomunikasi satu sama lain secara
langsung melainkan berkomunikasi melalui
backbone middleware SOA. Fitur arsitektur ESB
yang paling membedakan adalah sifat terdistribusi
dari topologi integrasi. ESB merupakan sekumpulan
middleware layanan-layanan yang menyediakan
kemampuan integrasi. Middleware layanan-layanan
ini merupakan jantung arsitektur ESB yang
menempatkan pesan untuk dapat diroutekan dan
ditransformasikan (Juric, 2007; Andary-Sage, 2010).
Arsitektur umum dari ESB dengan komponen
yang terkoneksi dapat dilihat pada Gambar 3.
Komponen dapat mengambil peran penghasil
layanan atau pemakai layanan. Layanan-layanan
dapat berupa komponen spesial seperti mesin
orkestrasi, adapter untuk sumberdaya data atau
adapter untuk sistem eksternal dengan transformasi
pesan atau konversi transport protokol. ESB
melakukan mediasi pesan antar komponen,
memutuskan lokasi untuk rute pesan, dan
transformasi pesan. ESB memerlukan memori
persisten seperti terkoneksi dengan basisdata (Juric,
2007; Andary-Sage, 2010).
Menurut Juric (2007) dan Andary-Sage (2010),
satu pendekatan dalam mendefinisikan arsitektur
umum ESB adalah spesifikasi Java Business
Integration. JBI merupakan standard untuk ESB,
sedangkan ESB sendiri merupakan sebuah pola
arsitektural untuk SOA. Spesifikasi JBI
mendeskripsikan arsitektur pluggable bagi kontainer
untuk penyedia layanan dan pemakai komponen.
Layanan melakukan koneksi melalui Binding
Component (BC) atau dapat di-host kedalam
kontainer sebagai bagian dari Service Engine (SE).
Layanan-layanan dideskripsikan menggunakan
WSDL. Pesan selalu diterjemahkan ke dalam format
pesan umum dan dirutekan oleh Normalized
Message Router (NMR).
Gambar 3. Arsitektur ESB secara umum (Juric,
2007; Andary-Sage, 2010)
88
ISSN: 2089-9815
ESB menyediakan infrastruktur komunikasi antar
layanan yang kuat, dapat diandalkan, aman dan
dapat diperluas. ESB juga menyediakan kendali
komunikasi dan kendali atas penggunaan layanan-
layanan yang mencakup (Juric, 2007):
a. Kemampuan menangkap pesan, yang
memungkinkan untuk menangkap pesan request
untuk layanan-layanan dan pesan response dari
layanan, serta memberikan pemrosesan
tambahan. Dengan cara ini, ESB dapat bertindak
sebagai intermediary.
b. Kemampuan routing, yang memungkinkan ESB
melakukan routing pesan ke layanan-layanan
yang berbeda didasarkan pada isi (content), asal,
atau atribut lain.
c. Kemampuan transformasi, yang memungkinkan
transformasi pesan sebelum dikirimkan ke
layanan-layanan. Untuk pesan format XML,
transformasi semacam ini dilakukan
menggunakan XSLT (Extensible Stylesheet
Language for Transformations) atau mesin
XQuery.
d. Kendali atas deployment, penggunaan dan
pemeliharaan layanan-layanan. Hal ini
memungkinkan adanya logging, profiling, load
balancing, performance tuning, ongkos
penggunaan layanan-layanan, distributed
deployment, on-the-fly reconfiguration, dsb.
Fitur manajemen lain yang mencakup definisi
korelasi antar pesan, definisi path komunikasi yang
handal, definisi security constraints yang berkaitan
dengan pesan dan layanan-layanan, dsb.
5. HASIL PENELITIAN & PEMBAHASAN
5.1 Diagram Use Case
Diagram Use Case ini menggambarkan
kebutuhan sistem. Diagram Use Case digunakan
untuk mendeskripsikan yang akan dikerjakan sistem,
mendeskripsikan kebutuhan fungsional sistem, serta
mendeskripsikan fungsionalitas sistem yang
diinginkan dan lingkungannya. Spesifikasi
pelengkap merupakan kebutuhan yang belum
dipetakan pada spesifikasi Use Case yang berisi
kebutuhan non fungsional, seperti pemeliharaan
kode, kehandalan, kinerja dan dukungan atau
kendala sistem, serta keamanan. Gambar 4
menunjukkan kebutuhan system dari aplikasi eShop.
5.2 Diagram Kelas
Diagram Kelas berisi kelas-kelas analisis yang
menyajikan model konseptual awal untuk things
(benda) dalam sistem yang mempunyai property dan
perilaku. Diagram Kelas pada perancangan statik ini
terdiri dari empat komponen kelas yaitu Kelas
Boundary, Kelas Kontrol, Kelas Entitas dan Kelas
Layanan (Gambar 5). Kelas layanan sendiri terdiri
dari inbound service dan outbound service.
 Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012)
Yogyakarta, 10 Maret 2012
Gambar 4. Diagram Use Case Eshop
Gambar 5. Diagram Kelas Eshop
5.3 Diagram Sequence
Diagram Sequence merepresentasikan aspek
dinamik dari sistem. Perancangan ini menunjukkan
interaksi dan kolaborasi antar kelas-kelas analisis.
Dua elemen dasar yang digunakan pada Model
Perilaku adalah obyek dan pesan. Obyek merupakan
instan dari kelas, sedangkan pesan merupakan
bentuk komunikasi antar obyek. Output dari fase ini
berupa Diagram Sequence yang terdiri dari 6
Diagram Sequence yaitu: Diagram Sequence
Searching, Diagram Sequence Shopping, Diagram
Sequence UserRegistration, Diagram Sequence
Payment, Diagram Sequence OrderFullfillment, dan
Diagram Sequence OrderNotification.
89
ISSN: 2089-9815
Gambar 6. Diagram Sequence Searching
Diagram Sequence Searching pada Gambar 6
menunjukkan aliran pesan dari antarmuka (browser)
menuju ke controller, kemudian ke WS internal
(InboundSearching) dan akhirnya ke WS yang
disediakan provider eksternal seperti Amazon.com,
eBay.com, dan Yahoo.com. Fungsi diagram ini
untuk menjalankan fungsi Searching yang dilakukan
oleh pelanggan dengan menjabarkan dalam aliran
pesan nya dari obyek satu ke obyek lainnya.
5.4 Arsitektur Sistem
Pada penelitian ini platform yang akan
digunakan untuk merealisasikan integrasi ini adalah
platform Java EE, dengan dukungan kakas
OpenESB sebagai infrastruktur middleware ESB.
Adapun arsitektur sistem yang akan digunakan
untuk merealisasikan model integrasi ini dapat
dilihat pada Gambar 7.
Web Service Pihak ke 3
Amazon.com eBay.com Yahoo.com
Glassfish ESB
BPEL BPEL BPEL BPEL
Enterprise Service Bus
Web Service Web Service Web Service Web Service
Database Server Client
MySQL browser
Gambar 7. Arsitektur sistem Eshop
Adapun spesifikasi perangkat keras yang
digunakan sebagai berikut: Prosesor Intel Pentium
Core 2 Duo 2.0 Ghz, Memori 3.0 GB RAM DDR2,
dan Hardisk 300 GB, sedangkan spesifikasi
perangkat lunak yang digunakan adalah Sistem
Operasi Microsoft WindoWS XP SP3, Java SDK
Standard Edition versi 1.6.0. update 20, Netbeans
IDE 6.7.1, serta Glassfish ESB 2..1 (Open ESB).
 Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012)
Yogyakarta, 10 Maret 2012
5.5 Implementasi dengan Glassfish ESB
Implementasi Proses Bisnis menggunakan BPEL
2.0 pada Glassfish ESB yang dapat dilihat pada
Gambar 8. Pada Gambar 8 dapat dilihat proses bisnis
searchingBP.BPEL. Pada proses bisnis ini proses
dimulai oleh pemakai layanan (TriggerSearchingBP)
yang melakukan permintaan ke SearchingBP.
Pemakai layanan diimplementasikan dengan WSDL
yang dikirim dengan menggunakan SOAP BC,
sedangkan penyedia layanan berupa Database BC
yang dibungkus dengan WSDL. Kemudian response
diterima oleh scSearchingBP berupa SOAP BC. Dari
kasus ini tampak adanya perbedaan protokol
maupun format pesan yang digunakan antara
pemakai layanan dengan penyedia layanan. Pemakai
layanan menggunakan SOAP, sedangkan penyedia
layanan menggunakan basisdata.
Gambar 8. Proses bisnis SearchingBP yang
diimplementasikan menjadi SearchingBP. bpel
Diagram Komponen akan diimplementasikan
menggunakan Glassfish ESB dalam bentuk Aplikasi
Komposit yang tersimpan pada file dengan ekstensi
.zip yang dapat dilihat pada Gambar 9.
Gambar 9. Hasil implementasi Diagram Komponen
SearchingCA menjadi Aplikasi Komposit
SearchingBP.zip
Gambar 9 merupakan hasil implementasi
Diagram Komponen SearchingBP menjadi Aplikasi
Komposit SearchingBP.zip, sedangkan pada Gambar
90
ISSN: 2089-9815
5.24 merupakan komponen penyusun Aplikasi
Komposit yang dideploy ke server aplikasi Glassfish
v2.1.
6. ESB SEBAGAI MIDDLEWARE
INTEGRASI
ESB merupakan salah satu pilar SOA, pilar
lainnya adalah WS dan BPEL. WS hanya
menyediakan integrasi point-to-point saja yang tidak
lagi cocok untuk mengintegrasikan aplikasi dalam
jumlah banyak. Penyelesaian terhadap masalah ini
adalah dengan koneksi secara tidak langsung antar
aplikasi melalui ESB yang menyediakan fasilitas
untuk melakukan routing pesan berbasis content
atau context.
Selain itu ada dua masalah heterogenitas yaitu
ketidak cocokan antar protokol komunikasi yang
digunakan antara pemakai layanan dan penyedia
layanan. Ketidak cocokan ini tidak memungkinkan
pemakai layanan untuk melakukan permintaan
layanan yang disediakan oleh penyedia layanan.
ESB dapat mengatasi masalah ini dengan
menyediakan fasilitas untuk mengkonversi sebuah
protokol transport/komunikasi ke dalam protokol
lain yang diperlukan. Misalnya fasilitas ini akan
mentransformasikan protokol HTTP ke dalam
protokol SMTP. Melalui fasilitas ini, aplikasi dapat
saling berkomunikasi walaupun protokol antara
pemakai layanan dan penyedia layanan tidak sama.
Masalah heterogenitas yang kedua berkaitan
dengan ketidaksesuaian antara format pesan yang
digunakan oleh pemakai layanan dan penyedia
layanan. masalah ini dipecahkan oleh ESB yang
menyediakan fasilitas untuk melakukan transformasi
format pesan yang digunakan oleh penyedia layanan
maupun pemakai layanan. Misalnya, fasilitas ini
dapat melakukan transformasi pesan SOAP ke
dalam format lain berbasis XML.
Ketiga peran ESB dalam hal routing,
transformasi protokol maupun transformasi pesan /
data telah berhasil dijalankan dalam penelitian ini.
Modul JBI yang telah dihasilkan dari penelitian ini
telah membuktikan penggunaan ESB untuk
melakukan routing dari pemakai layanan ke
penyedia layanan lokal maupaun penyedia layanan
eksternal (Amazon.com, eBay.com, dan
yahoo.com).
Demikian halnya dalam hal transformasi
protokol juga telah berhasil dijalankan melalui ke
modul JBI tersebut. Dari modul JBI tersebut, dapat
dilihat komunikasi antara protokol HTTP dengan
JDBC, atau antara HTTP dengan SMTP, atau antara
HTTP dengan FILE. Demikian halnya untuk
transformasi pesan dapat dilakukan melalui format
data XML.
7. KESIMPULAN
Pada penelitian ini telah berhasil dilakukan
integrasi beberapa web services yang berasal dari
eBay, Yahoo, Amazon dan Paypal dengan
 Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012) ISSN: 2089-9815
Yogyakarta, 10 Maret 2012

menggunakan ESB sebagai middleware integrasi. Talca – Chile

Melalui integrasi web services ini telah dapat Nikayin, F.A., 2009, Adopting A Theoretical
diketahui pula peran ESB dalam melakukan routing, Method For The Development Of A Service-
dan transformasi pesan dan protocol. Oriented Information System, Dissertation,
Penggunaan ESB dalam metode integrasi ini juga Faculty of Computer Science and Information
dapat mengatasi kompleksitas arsitektur TI yang Technology, University of Malaya, Kuala
berasal dari aplikasi yang heterogen, yang dibangun Lumpur
dari arsitektur dan bahasa pemrograman yang Reddy, V.K., Dubey, A., Lakshmanan, S.,
berbeda, serta pada platform yang berbeda. Sukumaran, S. and Sisodia, R., 2009, Evaluating
legacy assets in the context of migration to SOA,
Software Qual Journal (2009) 17:51–63,
PUSTAKA Springer Science+Business Media
Shahzadam B.M., Jan, J., Wim, G., and Herwig, M.,
Andary, J.F. and Sage, A.P., 2010, The role of 2008, Aligning Technology With Business An
service oriented architectures in systems Analysis Of The Impact Of Soa On Outsourcing,
engineering, Information Knowledge Systems Journal of Theoretical and Applied Information
Management 9 (2010), IOS Press Technology, published by www.jatit.org.
Erl, T., 2005, Service-Oriented Architecture: Sterff, A., 2006, Analysis of Service-Oriented
Concepts, Technology, and Design, Prentice Hall Architectures from a business and an IT
PTR, Upper Saddle River, New Jersey 07458 perspective, Master Thesis, Technische
Erl, T., 2004, Service Oriented Architecture: A Field Universität München, Fakultät für Informatik
Guide to Integrating XML and Web services, Vos, W., and Matthee, M.C., 2011, Towards A
Prentice Hall PTR, Upper Saddle River, New Service-Oriented Architecture: A Framework For
Jersey 07458 The Design Of Financial Trading Applications In
Erl, T., Karmarkar, A., Walmsley, P., Haas, H., The South African Investment Banking
Yalcina, U., Liu, C.K., Orchard, D., Tost, A., dan Environment, South African Journal of Industrial
Pasley, J., 2008, Web service Contract Design Engineering May 2011 Vol 22(1)
and Versioning for SOA, Prentice Hall PTR,
Upper Saddle River, New Jersey 07458
Juric, M.B., Loganathan, R., Sarang, P., dan
Jennings, F., 2007, SOA Approach to
Integration, Packt Publishing, Birmingham, B27
6PA, UK.
Juric, M.B., Mathew, B., dan Sarang, P. 2006,
Business Process Execution Language for Web
services, Packt Publishing, Birmingham, B27
6PA, UK.
Juric, M.B., Chandrasekaran, S., Frece, A., Hertis,
M., dan Srdic, G., 2010, WS-BPEL 2.0 for SOA
Composite Applications with IBM WebSphere 7,
Packt Publishing Ltd. 32 Lincoln Road Olton
Birmingham, B27 6PA, UK.
Kanchanavipu, K., 2008, An Integrated Model for
SOA Governance An Enterprise Perspective,
Master Thesis, IT University of Göteborg
Chalmers University of Technology and
University of Gothenburg, Göteborg, Sweden
Li, G., Muthusamy,V. and Jacobsen, H., 2010, A
Distributed Service-Oriented Architecture for
Business Process Execution, ACM Transactions
on The Web, Vol. 4, No. 1, Article 2, Publication
date: January 2010.
Luthria, H. And Rabhi, F., 2009, Service Oriented
Computing in Practice – An Agenda for
Research into the Factors Influencing the
Organizational Adoption of Service Oriented
Architectures, Journal of Theoretical and
Applied Electronic Commerce Research, ISSN
0718–1876 Electronic Version VOL 4 / ISSUE 1
/ APRIL 2009 / 39-56, © 2009 Universidad de

91