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:[email protected]
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
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.
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 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).
Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012) ISSN: 2089-9815 Yogyakarta, 10 Maret 2012
Amazon eBay Yahoo!Shooping Paypal
Enterprise Service Bus (Java Business Integration) Client (Web Browser) Basisdata
Lokal
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
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.
Layanan sementara standardi antarmuk SOA dibangun berorienta Kanchana 2009; Li merupaka yang mer memisahk
Hal dipecah k dinamaka sama lai berinterak komunika mendefin deskripsi dengan memungk yang di berkomun peminta layanan lain, sed layanan.
Selain beberapa Kadang k framewor pada Gam
Gambar Lu Layan berperan menyedia layanan.
layanan pendaftar sama lain fungsiona yang dip pendaftar dengan d dapat dit ini Erl m masih s framewor
sendiri mem a itu arsitekt sasi data da ka layanan (Vo
merupakan ar n menggunaka asi layanan avipu, 2008;
et al, 2010), an konsep dal representasika kan kepenting ini berarti b ke dalam uni an layanan. L in, tetapi me ksi satu sam asi tertentu.
nisikan komp , dan pesa yang lain kinkan intera itetapkan ole nikasi satu sa layanan dan adalah layan dangkan yang n definisi S definisi SOA kala definisi rk WS, yang mbar 2.
2. Service Ori uthria et al, 20 nan menyed sebagai akan deskrips
Peminta lay dari penye ran layanan in n, untuk pertu alitas lain. In perluas denga
ran layanan in deskripsi layan temukan oleh memperluas d
sangat mend rk WS, yang m
mbentuk ars tur informasi an ketersediaa os-Matthee, 2 rsitektur peran an prinsip-prin (Erl, 2005 Nikayin, 200 , sedangkan o lam rekayasa an pendekatan gan.
bahwa fungs it lojik yang Layanan-layan empunyai kem ma lain mel
Karena it ponen SOA s an. Layanan
n melalui aksi antar eh deskripsi.
ama lain yan n penyedia la nan yang mem g dipanggil d SOA oleh E A yang mirip d SOA ini din g secara umu
iented Archite 09; Andary-S diakan layan
penyedia si layanan nya
yanan, memi edia layanan ni. Dua layana ukaran data da ni sesuai den an pendaftaran
ni, layanan d nan nya, sehin
peminta laya efinisinya ten dasar dengan merupakan de
sitektur aplik dicapai mela an data mela 011)
ngkat lunak y nsip perancan
; Sterff, 20 09; Reddy et orientasi laya perangkat lu n berbeda un sionalitas sist lebih kecil y nan ini lepas s
mampuan un lalui mekanis tu, Erl (20 sebagai layan
berkomunik pesan y layanan-layan . Dua laya ng diacu seba
ayanan. Pemi manggil laya disebut penye Erl, masih
dari sumber la namakan seba um dapat dili
ecture (Erl, 20 Sage, 2010) nan ke pub
layanan ya a ke pendafta inta pengirim n menggunak an ini diikat s an menggunak ngan definisi
n layanan. P dapat didaftark
ngga layanan anan. Dalam ntang SOA y n menggunak efinisi SOA y
kasi, alui alui yang ngan 006;
t al, anan unak ntuk tem yang satu ntuk sme 005) nan, kasi yang nan, anan agai inta anan edia ada ain.
agai ihat
005;
blik, ang aran man kan satu kan Erl ada kan ini hal ang kan ang
kon tek dip a.
b.
c.
d.
ditu ten Na asp den kon fon yan (Er me bes ber tert dal ter me seb per yai lay did did bel me me pen SO kon mid me ber 4.
me me uku dan me sud SO beb me ses me seh me dep
nkrit yang did Framework knologi yang petakan ke dal
Layanan-lay Pesan didesk Deskripsi dit Pada model i menggunaka Hal ini pad unjukkan pa ntang SOA amun definisi pek teknologi ngan solusi be nsep ini dapa ndasi SOA sec SOA adalah ng mengikuti rl, 2005).
elakukan pen sar menjadi rtujuan untu tentu. Setelah lam beberapa sebut haru emungkinkan buah orkestr
rmasalahan y itu bagaimana yanan berko desain, dan definisikan Erl Seperti yan lakang masal enurut Erl (2 elakukan inte
nelitian ini t OA Delivery s nsep lain yan ddleware i emanfaatkan
rbasis SOA.
ENTERPR ESB me engintegrasika emperkuat SO
uran, dan kom n layanan-la elakukan kone
dah ada dan y OA. ESB dipe berapa sumbe enggabungkan suai dengan elakukan kone hingga me engintegrasika ploy secara b
dasarkan pada WS ini m didasarkan lam model SO
anan direalisa kripsikan oleh tetapkan oleh ini, pendaftara an UDDI da dasarnya s ada Gambar
ini digunaka SOA ini ha SOA. Hal in erbasis WS da at diabstraksik cara umum.
h sebuah bent prinsip-prins Konsep be dekatan deng
sekumpulan uk menyele h seluruh perm a layanan, sol us bisa seluruh layan rasi. Untuk yang harus d
a layanan be omunikasi,
bagaimana l (2005).
ng telah di lah, bahwa k 2005) ini b egrasi berbas tidak hanya m
saja, melainka ng telah mema integrasi. Ju ESB sebaga
RISE SERVIC erupakan an aplikasi
OA melalui mpleksitas ant
ayanan. ESB eksi komponen yang baru unt erlukan untuk erdaya TI. ESB n dan memas
perubahan k eksi kompone enyediakan an sistem ke bertahap (Juri
WS.
merupakan fr secara standa OA sebagai be
asikan sebagai protokol SOA WSDL an layanan sesuai dengan
2. Pengertia an di banyak anya berurusa ni sangat berk an kebutuhann kan untuk me tuk teknologi sip berorientas rorientasi-laya gan membagi
layanan ke esaikan perm
masalahan dap lusi dari perm diselesaikan nan berpartisip
itu ada dimiliki oleh erhubungan, b
bagaimana pesan antar inyatakan pa
konsep SOA elum memad sis SOA. K
mengacu pad an akan meng anfaatkan ES uric (2006) ai arsitektur
CE BUS (ESB infrastruktur
dan layana pengurangan tarmuka antar B digunaka n perangkat lu tuk membangu melakukan k B harus fleksi sang ulang k kebutuhan bis en yang terika kemampuan dalam SOA c, 2007; And
framework ard, yang
rikut:
i WS AP
n korelasi an umum
k artikel.
an dengan kaitan erat nya, tetapi embangun arsitektur si layanan anan ini i masalah ecil yang masalahan
pat dibagi masalahan dengan pasi dalam beberapa h layanan,
bagaimana layanan r layanan
ada latar Delivery dai untuk Karena itu da konsep
gacu pada B sebagai ) sudah
integrasi
B) untuk an. ESB n jumlah, ra aplikasi an untuk
unak yang un sebuah koneksi ke ibel untuk komponen snis. ESB at longgar, n untuk
dan men- dary-Sage,
Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012) ISSN: 2089-9815 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)
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.
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.
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.
Database Server Glassfish ESB
Web Service Web Service
MySQL
Client
browser Web Service Pihak ke 3
Amazon.com eBay.com Yahoo.com
Enterprise Service Bus
Web Service Web Service BPEL
BPEL BPEL BPEL
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) ISSN: 2089-9815 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
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
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 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
Talca – Chile
Nikayin, F.A., 2009, Adopting A Theoretical Method For The Development Of A Service- Oriented 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:51–63, 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 Universität München, Fakultät für 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)
