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

Transkripsi

1 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 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, s, 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). 85

2 Basisdata Lokal Client (Web Browser) 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 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 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 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 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

3 Seminar Nasional Teknologi Informasi dan Komunikasi 2012 (SENTIKA 2012) ISSN: Layanan sendiri membentuk arsitektur aplikasi, sementaraa itu arsitektur informasi dicapai melalui standardisasi data dan ketersediaan data melalui antarmuka layanan (Vos-Matthee, 2011) SOA merupakan arsitektur perangkat lunak yang dibangunn menggunakan prinsip-prinsip perancangan berorientasi layanan (Erl, 2005; Sterff, 2006; Kanchanavipu, 2008; Nikayin, 2009; Reddy et al, 2009; Li et al, 2010), sedangkan orientasi layanan merupakan konsep dalam rekayasa perangkat lunak yang merepresentasikan pendekatann berbeda untuk memisahkan kepentingan. Hal ini berarti bahwa fungsionalitas sistem dipecah ke dalam unit lojik yang lebih kecil yang dinamakan layanan. Layanan-layanan ini lepas satu sama lain, tetapi mempunyai kemampuan untuk berinteraksi satu sama lain melalui mekanisme komunikasi tertentu. Karena itu, Erl (2005) mendefinisikan komponen SOA sebagai layanan, deskripsi, dan pesan. Layanan berkomunikasi dengan yang lain melalui pesan yang memungkinkan interaksi antar layanan-layanan, yang ditetapkan oleh deskripsi. Dua layanan berkomunikasi satu sama lain yang diacu sebagai peminta layanan dan penyedia layanan. Peminta layanan adalah layanan yang memanggil layanan lain, sedangkan yang dipanggil disebut penyedia layanan. Selain definisi SOA oleh Erl, masih ada beberapa definisi SOA yang mirip dari sumber lain. Kadang kala definisi SOA ini dinamakan sebagai framework WS, yang secara umum dapat dilihat pada Gambar 2. Gambar 2. Service Oriented Architecture (Erl, 2005; Luthria et al, 2009; Andary-Sage, 2010) Layanan menyediakan layanan ke publik, berperan sebagai penyedia layanan yang menyediakan deskripsi layanan nya ke pendaftaran layanan. Peminta layanan, meminta pengiriman layanan dari penyedia layanann menggunakan pendaftaran layanan ini. Dua layanan ini diikat satu sama lain, untuk pertukaran data dan menggunakan fungsionalitas lain. Ini sesuai dengan definisi Erl yang diperluas dengan pendaftarann layanan. Pada pendaftaran layanan ini, layanan dapat didaftarkan dengan deskripsi layanan nya, sehingga layanan ini dapat ditemukan oleh peminta layanan. Dalam hal ini Erl memperluas definisinya tentang SOA yang masih sangat mendasar dengann menggunakan framework WS, yang merupakan definisi SOA yang konkrit yang didasarkan pada WS. Framework WS ini merupakan framework teknologi yang didasarkan secara standard, yang dipetakan ke dalam model SOA sebagai berikut: a. b. c. d. Layanan-layanan direalisasikan sebagai WS Pesan dideskripsikan oleh protokol SOAP Deskripsi ditetapkan oleh WSDL Pada model ini, pendaftaran layanan menggunakan UDDI Hal ini pada dasarnya sesuai dengann korelasi ditunjukkan pada Gambar 2. Pengertian umum tentang SOA ini digunakan di banyak artikel. Namun definisi SOA ini hanya berurusan dengan aspek teknologi SOA. Hal ini sangat berkaitan erat dengan solusi berbasis WS dan kebutuhannya, tetapi konsep ini dapat diabstraksikan untuk membangun fondasi SOA secara umum. SOA adalah sebuah bentuk teknologi arsitektur yang mengikuti prinsip-prinsip berorientasi layanan (Erl, 2005). Konsep berorientasi-layanan ini melakukan pendekatan dengan membagi masalah besar menjadi sekumpulan layanan kecil yang bertujuan untuk menyelesaikan permasalahan tertentu. Setelah seluruh permasalahan dapat dibagi dalam beberapaa layanan, solusi dari permasalahan tersebut harus bisa diselesaikan dengan memungkinkan seluruh layanan berpartisipasi dalam sebuah orkestrasi. Untuk itu ada beberapa permasalahan yang harus dimiliki oleh layanan, yaitu bagaimanaa layanan berhubungan, bagaimana layanan berkomunikasi, bagaimana layanan didesain, dan bagaimana pesan antar layanan didefinisikan Erl (2005). Seperti yang telah dinyatakan pada latar belakang masalah, bahwa konsep SOA Delivery menurut Erl (2005) ini belum memadai untuk melakukan integrasi berbasis SOA. Karena itu penelitian ini tidak hanya mengacu pada konsep SOA Delivery saja, melainkan akan mengacu pada konsep lain yang telah memanfaatkan ESB sebagai middleware integrasi. Juric (2006) sudah memanfaatkan berbasis SOA. ESB sebagai arsitektur integrasi 4. ENTERPRISE SERVICE BUS (ESB) ESB merupakan infrastruktur untuk mengintegrasikan aplikasi dan layanan. ESB memperkuat SOA melalui pengurangann jumlah, ukuran, dan kompleksitas antarmuka antara aplikasi dan layanan-layanan. ESB digunakan untuk melakukan koneksi komponenn perangkat lunak yang sudah ada dan yang baru untuk membangun sebuah SOA. ESB diperlukan untuk melakukan koneksi ke beberapa sumberdaya TI. ESB harus fleksibel untuk menggabungkann dan memasang ulang komponen sesuai dengan perubahan kebutuhan bisnis. ESB melakukan koneksi komponen yang terikat longgar, sehingga menyediakan kemampuan untuk mengintegrasikan sistem ke dalam SOA dan men- deploy secara bertahap (Juric, 2007; Andary-Sage, 87

4 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 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. 88

5 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. Gambar 4. Diagram Use Case Eshop 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. Pihak ke 3 Amazon.com ebay.com Yahoo.com Glassfish ESB BPEL BPEL BPEL BPEL Enterprise Service Bus 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 update 20, Netbeans IDE 6.7.1, serta Glassfish ESB 2..1 (Open ESB). 89

6 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 v 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 90

7 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 Erl, T., 2004, Service Oriented Architecture: A Field Guide to Integrating XML and Web services, Prentice Hall PTR, Upper Saddle River, New Jersey 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 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 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 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 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) 91