Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012)

Yogyakarta, 10 Maret 2012

ISSN: 2089-9815

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
Menurut Shahzadam (2008), SOA merupakan solusi
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 interEAI 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 eShop yang mengintegrasikan Amazon, eBay,
Yahoo!Shoping, dan Paypal (Lihat Gambar 1).

1.

LATAR BELAKANG MASALAH

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.

85

Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012)

Yogyakarta, 10 Maret 2012

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 layananlayanan 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

Client (Web Browser)

Basisdata
Lokal

Enterprise Service Bus (Java Business Integration)

Amazon

eBay

Yahoo!Shooping

ISSN: 2089-9815

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 pointto-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

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.
86

Seminaar Nasional Teknoologi Informasi dan

d Komunikasi 2012
2
(SENTIKA 2012)
2
Yogyakkarta, 10 Maret 2012
2

ISSN
N: 2089-9815

kon
nkrit yang diddasarkan pada WS.
Framework WS ini m
merupakan framework
fr
tek
knologi yang didasarkan secara standaard, yang
dip
petakan ke dallam model SO
OA sebagai berikut:
a. Layanan-layanan direalisaasikan sebagaii WS
b. Pesan dideskkripsikan oleh protokol SOA
AP
c. Deskripsi dittetapkan oleh WSDL
d. Pada model ini,
i pendaftaraan layanan
menggunakaan UDDI
Hal ini padda dasarnya ssesuai dengan
n korelasi
ditu
unjukkan paada Gambar 2. Pengertiaan umum
ten
ntang SOA ini digunakaan di banyak
k artikel.
Naamun definisi SOA ini haanya berurusaan dengan
asp
pek teknologi SOA. Hal inni sangat berk
kaitan erat
den
ngan solusi beerbasis WS daan kebutuhann
nya, tetapi
kon
nsep ini dapaat diabstraksikkan untuk meembangun
fon
ndasi SOA seccara umum.
SOA adalahh sebuah benttuk teknologi arsitektur
yan
ng mengikuti prinsip-prinssip berorientassi layanan
(Errl, 2005). Konsep berorientasi-layaanan ini
meelakukan pendekatan denggan membagii masalah
bessar menjadi sekumpulan layanan keecil yang
berrtujuan untuuk menyeleesaikan perm
masalahan
terttentu. Setelahh seluruh perm
masalahan dap
pat dibagi
dallam beberapaa layanan, sollusi dari perm
masalahan
dengan
tersebut
haruus
bisa
diselesaikan
meemungkinkan seluruh layannan berpartisip
pasi dalam
seb
buah orkestrrasi. Untuk itu ada beberapa
perrmasalahan yang
y
harus ddimiliki oleh
h layanan,
yaiitu bagaimanaa layanan beerhubungan, bagaimana
b
lay
yanan berkoomunikasi,
bagaimana layanan
did
desain, dan bagaimana pesan antarr layanan
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
pen
nelitian ini tidak
t
hanya m
mengacu pad
da konsep
SO
OA Delivery saja,
s
melainkaan akan meng
gacu pada
kon
nsep lain yanng telah memaanfaatkan ESB sebagai
mid
ddleware integrasi.
i
Juuric (2006)) sudah
meemanfaatkan ESB sebagaai arsitektur integrasi
berrbasis SOA.

Layanan sendiri mem

mbentuk arssitektur aplikkasi,
sementaraa itu arsitekttur informasi dicapai melaalui
standardisasi data daan ketersediaaan data melaalui
antarmukka layanan (Voos-Matthee, 2011)
SOA merupakan arrsitektur peranngkat lunak yang
y
dibangunn menggunakaan prinsip-prinnsip perancanngan
berorientaasi layanan (Erl, 2005; Sterff, 20006;
Kanchanaavipu, 2008; Nikayin, 20009; Reddy ett al,
2009; Li et al, 2010),, sedangkan orientasi
o
layaanan
merupakaan konsep dallam rekayasa perangkat luunak
yang merrepresentasikaan pendekatann berbeda unntuk
memisahkkan kepentinggan.
Hal ini berarti bahwa
b
fungssionalitas sisttem
dipecah ke
k dalam uniit lojik yang lebih kecil yang
y
dinamakaan layanan. Layanan-layan
L
nan ini lepas satu
s
sama laiin, tetapi meempunyai kem
mampuan unntuk
berinterakksi satu sam
ma lain mellalui mekanissme
komunikaasi tertentu. Karena ittu, Erl (20005)
mendefinnisikan kompponen SOA sebagai
s
layannan,
deskripsi, dan pesaan. Layanan berkomunikkasi
dengan
yang
lainn
melalui
pesan
y
yang
memungkkinkan interaaksi antar layanan-layannan,
yang diitetapkan oleeh deskripsi.. Dua layaanan
berkomunnikasi satu saama lain yanng diacu sebaagai
peminta layanan dann penyedia laayanan. Pemiinta
layanan adalah layannan yang mem
manggil layaanan
lain, seddangkan yangg dipanggil disebut
d
penyeedia
layanan.
Selainn definisi SOA
S
oleh Erl,
E
masih ada
beberapa definisi SOA
A yang mirip dari
d sumber laain.
Kadang kala
k
definisi SOA ini dinnamakan sebaagai
frameworrk WS, yangg secara umuum dapat diliihat
pada Gam
mbar 2.

Gambar 2. Service Oriiented Architeecture (Erl, 20005;

Luuthria et al, 2009; Andary-S
Sage, 2010)

4.

ENTERPR
RISE SERVIC
CE BUS (ESB
B)
untuk
ESB
meerupakan
infrastruktur
meengintegrasikaan aplikasi dan layanaan. ESB
meemperkuat SO
OA melalui pengurangan
n jumlah,
uku
uran, dan kom
mpleksitas anttarmuka antarra aplikasi
dan
n layanan-laayanan. ESB
B digunakaan untuk
meelakukan koneeksi komponenn perangkat lu
unak yang
sud
dah ada dan yang
y
baru unttuk membangu
un sebuah
SO
OA. ESB dipeerlukan untuk melakukan koneksi
k
ke
beb
berapa sumbeerdaya TI. ESB
B harus fleksiibel untuk
meenggabungkann dan memassang ulang komponen
k
sessuai dengan perubahan kkebutuhan bissnis. ESB
meelakukan koneeksi komponeen yang terikaat longgar,
seh
hingga
meenyediakan
kemampuan
n
untuk
meengintegrasikaan sistem ke dalam SOA dan mendep
ploy secara bertahap
b
(Juric, 2007; And
dary-Sage,

Layannan menyeddiakan layannan ke pubblik,

berperan
sebagai
penyedia
layanan
yaang
menyediaakan deskripssi layanan nyaa ke pendaftaaran
layanan. Peminta layyanan, memiinta pengirim
man
layanan dari penyeedia layanann menggunakkan
pendaftarran layanan inni. Dua layanaan ini diikat satu
s
sama lainn, untuk pertuukaran data daan menggunakkan
fungsionaalitas lain. Inni sesuai denngan definisi Erl
yang dipperluas dengaan pendaftarann layanan. Pada
pendaftarran layanan inni, layanan dapat
d
didaftarkkan
dengan deskripsi
d
layannan nya, sehinngga layanan ini
dapat dittemukan oleh peminta layaanan. Dalam hal
ini Erl memperluas
m
definisinya tenntang SOA yang
masih sangat
s
menddasar dengann menggunakkan
frameworrk WS, yang merupakan
m
deefinisi SOA yang
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).

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 layananlayanan 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.

Gambar 3. Arsitektur ESB secara umum (Juric,

2007; Andary-Sage, 2010)

88

Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012)

Yogyakarta, 10 Maret 2012

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.

Gambar 4. Diagram Use Case Eshop

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

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.

Database Server

MySQL

Client

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).
89

Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012)

Yogyakarta, 10 Maret 2012

ISSN: 2089-9815

5.24 merupakan komponen penyusun Aplikasi

Komposit yang dideploy ke server aplikasi Glassfish
v2.1.

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.

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.

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

7.

KESIMPULAN
Pada penelitian ini telah berhasil dilakukan
integrasi beberapa web services yang berasal dari
eBay, Yahoo, Amazon dan Paypal dengan

Gambar 9 merupakan hasil implementasi

Diagram Komponen SearchingBP menjadi Aplikasi
Komposit SearchingBP.zip, sedangkan pada Gambar
90

Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012)

Yogyakarta, 10 Maret 2012

ISSN: 2089-9815

Talca Chile
Nikayin, F.A., 2009, Adopting A Theoretical
Method For The Development Of A ServiceOriented Information System, Dissertation,
Faculty of Computer Science and Information
Technology, University of Malaya, Kuala
Lumpur
Reddy, V.K., Dubey, A., Lakshmanan, S.,
Sukumaran, S. and Sisodia, R., 2009, Evaluating
legacy assets in the context of migration to SOA,
Software Qual Journal (2009) 17:5163,
Springer Science+Business Media
Shahzadam B.M., Jan, J., Wim, G., and Herwig, M.,
2008, Aligning Technology With Business An
Analysis Of The Impact Of Soa On Outsourcing,
Journal of Theoretical and Applied Information
Technology, published by www.jatit.org.
Sterff, A., 2006, Analysis of Service-Oriented
Architectures from a business and an IT
perspective,
Master
Thesis,
Technische
Universitt Mnchen, Fakultt fr Informatik
Vos, W., and Matthee, M.C., 2011, Towards A
Service-Oriented Architecture: A Framework For
The Design Of Financial Trading Applications In
The South African Investment Banking
Environment, South African Journal of Industrial
Engineering May 2011 Vol 22(1)

menggunakan ESB sebagai middleware integrasi.

Melalui integrasi web services ini telah dapat
diketahui pula peran ESB dalam melakukan routing,
dan transformasi pesan dan protocol.
Penggunaan ESB dalam metode integrasi ini juga
dapat mengatasi kompleksitas arsitektur TI yang
berasal dari aplikasi yang heterogen, yang dibangun
dari arsitektur dan bahasa pemrograman yang
berbeda, serta pada platform yang berbeda.

PUSTAKA
Andary, J.F. and Sage, A.P., 2010, The role of
service oriented architectures in systems
engineering, Information Knowledge Systems
Management 9 (2010), IOS Press
Erl, T., 2005, Service-Oriented Architecture:
Concepts, Technology, and Design, Prentice Hall
PTR, Upper Saddle River, New Jersey 07458
Erl, T., 2004, Service Oriented Architecture: A Field
Guide to Integrating XML and Web services,
Prentice Hall PTR, Upper Saddle River, New
Jersey 07458
Erl, T., Karmarkar, A., Walmsley, P., Haas, H.,
Yalcina, U., Liu, C.K., Orchard, D., Tost, A., dan
Pasley, J., 2008, Web service Contract Design
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 Gteborg
Chalmers University of Technology and
University of Gothenburg, Gteborg, 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
07181876 Electronic Version VOL 4 / ISSUE 1
/ APRIL 2009 / 39-56, 2009 Universidad de
91