PENERAPAN ENTERPRISE SERVICE BUS (ESB) SEBAGAI MIDDLEWARE INTEGRASI BERBASIS SOA

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:[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 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: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)

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 91