Buku Ajar Soa WHU

Penulis : Wiranto Herry Utomo
Pemrograman Web Services dan SOA dengan

Netbeans
Wiranto Herry Utomo
1
Kata Pengantar
Service Oriented Architecture (SOA) merupakan salah satu metode atau
teknologi yang digunakan untuk integrasi enterprise. Integrasi enterprise ini
mencakup integrasi di dalam enterprise (intra-enterprise integration) dan lintas
enterprise (inter-enterprise integration atau B2B). SOA sebagai teknologi dapat
diimplementasikan ke dalam berbagai platform tergantung vendor yang
membangun. Salah satu implementasi dari SOA adalah dengan ESB.
Buku ini disusun berdasarkan serangkaian kegiatan penelitian yang berkaitan

dengan SOA, yang memusatkan pada penerapan teknologi web services, BPEL,
dan ESB. Buku ini membahas integrasi aplikasi berbasis SOA dengan
menggunakan Glassfish ESB. Glassfish ESB ini merupakan teknologi
opensource yang diimplementasikan dengan IDE Netbeans. Saat ini Glassfish
ESB dikembangkan oleh komunitas opensource dengan alamat : http://open-
esb.net.
Agar lebih efektif, akan lebih baik jika pembaca sudah memahami pemrograman
berorientasi objek khususnya java, pemrograman web, pemrograman basisdata,
dan pemrograman XML.
Sasaran buku ini adalah masyarakat umum yang berminat dibidang teknologi
integrasi enterprise, tetapi buku ini secara khusus ditujukan bagi mahasiswa di
2
bidang ilmu komputer maupun teknik informatika. Buku ini dapat digunakan
sebagai referensi untuk mata kuliah Pemrograman Web Lanjut, Web Service,
Service Oriented Architecture, atau Komputasi Terdistribusi. Selain sebagai
perkuliahan, buku ini juga dapat digunakan untuk penelitian, atau sebagai acuan
bagi pengembang perangkat lunak yang memusatkan pada integrasi sistem.
Mengingat keterbatasan waktu dalam penulisan buku ini, maka tentunya masih
terdapat berbagai kelemahan, oleh karena itu penulis mohon saran dan kritik
yang berguna bagi pengembangan buku ini. Kritik maupun saran untuk
penyempurnaan buku ini, dapat dikirimkan ke alamat email :
wiranto.utomo@staff.uksw.edu.
Akhir kata, semoga buku ini dapat bermanfaat bagi pembaca dalam mempelajari
ilmu komputer, khususnya yang berkaitan dengan integrasi sistem, SOA dan
Web Service.
Salatiga, 12 Maret 2015
Penulis
3
Daftar Isi
BAB 1. Service Oriented Architecture (SOA) ............................................ 1
1.1 Integrasi Intra-Enterprise dan Inter-Enterprise ...................... 1
1.2 Evolusi SOA .......................................................................... 7
1.3 Konsep SOA .......................................................................... 17
1.4 Arsitektur Integrasi ................................................................. 23
1.4.1 Point-to-Point .............................................................. 23
1.4.2 Hub-and-Spoke ............................................................ 25
1.4.3 Enterprise Message Bus ............................................... 26
1.4.4 Enterprise Service Bus ................................................. 28
BAB 2. Web Service, BPEL dan ESB ......................................................... 33
2.1 Arsitektur Web service ........................................................... 34
2.2 Integrasi Web service ............................................................ 42
2.3 Business Process Execution Language (BPEL) ..................... 47
2.3.1 Evolusi standard BPEL ................................................ 48
2.3.2 Orkestrasi dan Koreografi ........................................... 55
2.4 Enterprise Service Bus (ESB) ............................................... 57
2.5 Java Business Integration ...................................................... 60
2.6 Instalasi GlassFish ESB ......................................................... 63
2.7 Memulai Glassfish ESB ......................................................... 69
BAB 3. Contoh 1 : Pemrograman Web service .......................................... 77
3.1 Membuat kontainer .................................................................. 77
3.2 Membuat Web service dari kelas Java ..................................... 78
3.3 Menambahkan Operation ke Web service ............................... 78
3.4 Deploying dan Testing Web service ........................................ 84
3.5 Klien Web service .................................................................... 87
3.5.1 Kelas Java ...................................................................... 87
3.5.2 Servlet ............................................................................ 90
3.5.3 Halaman web JSP ......................................................... 94
BAB 4. Contoh 2 : Pemrograman Web service ........................................... 98
4.1 Membangun Aplikasi Kelas Java .............................................. 98
4.1.1 Membuat Project Java .................................................. 98
4
4.1.2 Membuat Kelas Java ..................................................... 100

4.1.3 Menambahkan Method ................................................... 100
4.1.4 Mengimpor Reference ..................................................... 103
4.1.5 Menguji Kelas Java ........................................................ 106
4.1.6 Debugging Aplikasi Java ............................................... 109
4.1.7 Melengkapi Kode ............................................................ 113
4.1.8 Dokumentasi Kelas Java ............................................... 113
4.2 Membuat User Interface Java ............................................... 116
4.2.1 Membuat Layout ............................................... 116
4.2.2 Menambah Event Handler Behavior ............................ 120
4.2.3 Menguji Java User Interface ........................................... 123
4.3 Membangun Web service ............................................... 124
4.3.1 Membuat Proyek EJB ............................................... 125
4.3.2 Menambah Library ke Proyek ....................................... 129
4.3.3 Membuat Web service ............................................... 130
4.3.3 Menguji Web service ............................................... 133
4.4.4 Membangun Interface Browser ...................................... 136
Bab 5. Contoh 3: Pemrograman SOA ............................................... 150
5.1 Pengaturan Konfigurasi ............................................... 153
5.2 Melakukan select join untuk memindahkan data dari
Database Remote ke file (output.xml) .................................... 165
5.3 Melakukan insert hasil select join ke Database Lokal. ............. 180
5.4 Menghapus record yang ada di Database Lokal ................... 195
Bab 6. Contoh 4 : Pemrograman SOA ............................................... 209
6.1 Skenario ........................................................................... 210
6.2 Web service untuk Menetapkan Bunga Pinjaman ............... 212
6.2.1 Eksplorasi WSDL dan XSD ......................................... 220
6.2.2 Testing Web service ............................................... 222
6.3 Menghitung Pembayaran Pinjaman ......................................... 224
6.3.1 Eksplorasi WSDL dan XSD ......................................... 227
6.3.2 Testing Web service ............................................... 230
6.4 Orkestrasi dengan BPEL ............................................... 232
6.4.1 Membuat Proyek BPEL ............................................... 232
6.4.2 Membangun Skema XML .......................................... 239
6.4.3 Membangun Dokumen WSDL ..................................... 247
5
6.4.4 Menambah Partner Link ............................................... 252

6.4.5 Mengimport XSD dan WSDL ....................................... 262
6.4.6 Menambah Elemen Assign ........................................... 270
6.4.7 Membuat Aplikasi Komposit ........................................ 279
6.4.8 Testing Aplikasi Komposit ........................................... 286
6.5 Membangun User Interface ............................................... 290
6.5.1 Membuat Proyek Aplikasi Web ................................... 290
6.5.2 Membuat klien Web service .......................................... 294
6.5.3 Menemukan Port JBI Binding Component ................. 296
6.5.4 Deploying Proyek ............................................... 305
6.5.5 Testing User Interface ............................................... 309
6.6 Menyimpan Proses Pinjaman ke Database ............................... 310
6.6.1 Membuat Database ............................................... 310
6.6.2 Mengakses GlassFish Admin Console ........................... 315
6.6.3 Testing konektivitas antara GlassFish dan Java DB ..... 319
6.6.4 Membuat WSDL dari Database BC ......................... 321
6.6.5 Interaksi dengan Database via Database BC ................. 326
6.6.6 Melakukan Test Case .................................................... 331
Daftar Pustaka ............................................... 337
6
BAB 1
Service Oriented Architecture
1.1 Integrasi Intra-Enterprise dan Inter-Enterprise

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 .
7
Untuk menyelaraskan sistem bisnis dan sistem informasi tersebut

diperlukan integrasi yang berperan sebagai mediasi antara kedua lapisan
tersebut. 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 service-service sebagai fungsionalitas
aplikasi yang sudah ada. Integrasi B2B atau inter-EAI berkaitan dengan
pertukaran pesan yang berasal dari service di luar perusahaan. SOA telah
memperbaiki dan memperluas fleksibilitas dari metode integrasi sebelumnya
8
(EAI) dan arsitektur terdistribusi dan memusatkan pada penggunaan aplikasi dan
sistem yang sudah ada, interoperabilitas dan integrasi aplikasi, serta komposisi
proses bisnis dari service-service atau fungsionalitas yang disediakan oleh
aplikasi.
Menurut Pahl et al (2009) dan Chen et al (2010), SOA secara cepat
mencapai momentum sebagai arsitektur perangkat lunak dan platform teknologi
yang memungkinkan integrasi Enterprise Architecture Integration (EAI). EAI
ini berkenaan dengan integrasi sistem legacy, dengan interoperabilitas melalui
SOA dan Web service. Dalam hal ini integrasi SOA dan EAI sangat berkaitan
dengan integrasi informasi. Integrasi service tidak dapat dicapai tanpa integrasi
informasi untuk aplikasi heterogen. Integrasi informasi ini merupakan masalah
utama untuk EAI pada umumnya.
Integrasi informasi melalui SOA ini bukan hanya untuk EAI, namun juga
untuk inter-EAI (B2B), sehingga menurut Schroth-Janner (2007), ada beberapa
keunggulan dari SOA yaitu : pertama, SOA memungkinkan integrasi service
antar organisasi (inter-EAI). Dengan mengikuti standard umum dalam
mendeskripsikan antarmuka service, perusahaan dapat melakukan pengaturan
transaksi bisnis secara longgar dengan perusahan lain dan mengotomatisasikan
transaksi bisnis secara cepat. Kedua, SOA memudahkan integrasi intra-
perusahaan (EAI) dari service yang terpisah. Ketiga, pengembangan aplikasi
berbasis SOA secara nyata telah mengurangi waktu pengembangan dengan
ketersediaan blok bangunan aplikasi yang dapat digunakan ulang.
9
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 ESB/SOA, menggunakan service-
service yang dilewatkan melalui middleware yang disebut ESB (Enterprise
Service Bus).
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
10
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 service, maka dalam integrasi service-service akan terjadi ikatan-
longgar. Hal ini memungkinkan penggunaan ulang service-service yang sudah
ada dan menghasilkan aplikasi yang dapat dibangun dan dirubah secara mudah
dan cepat.
Definisi mengenai SOA sendiri sangat beragam, dan belum ada definisi
yang berlaku umum untuk SOA. Pada penelitian ini konsep SOA akan ditinjau
berdasarkan konsep SOA Delivery menurut Erl (2005). SOA Delivery menurut
Erl (2005), merupakan arsitektur perangkat lunak yang dibangun menggunakan
prinsip-prinsip perancangan berorientasi service. Perancangan berorientasi
service ini berarti bahwa fungsionalitas sistem dipecahkan ke dalam unit lojik
yang lebih kecil yang dinamakan service-service. Service-service ini bebas satu
11
sama lain, tetapi mempunyai kemampuan untuk berinteraksi satu sama lain
melalui mekanisme komunikasi tertentu. SOA tidak terkait dengan suatu
teknologi tertentu, tapi lebih ke arah pendekatan untuk pembangunan perangkat
lunak yang moduler.
Orkestrasi menggunakan Web service 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 Web service dengan menggunakan ESB. ESB
merupakan infrastruktur untuk koneksi service 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 service, sehingga
skalabilitas integrasi menjadi tinggi.
Kelebihan lain orkestrasi Web service dengan ESB adalah memungkinkan
lapisan bisnis dan sistem informasi mempunyai relasi yang lebih dekat, karena
orkestrasi Web service 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 Web service.
12
1.2 Evolusi SOA

Dengan melakukan penelusuran evolusi pola-pola integrasi, maka dapat
ditunjukkan bahwa SOA merupakan teknik integrasi yang dibangun berdasarkan
teknologi integrasi untuk sistem komputasi terdistribusi. Menurut Roshen
(2009) beberapa teknologi komputasi terdistribusi yang berkaitan dengan SOA
adalah pemrograman soket, Remote Procedure Call (RPC), Object Request
Broker (ORB) dan Asynchronous Messaging. Teknologi komputasi terdistribusi
tersebut memberikan kontribusi terhadap berbagai konsep integrasi berbasis
SOA. Pembahasan mengenai soket, RPC, ORB dan Asynchronous Messaging
akan mengacu pada Juric et al (2007), Roshen (2009), dan Kumar et al (2010).
Integrasi perusahaan sendiri merupakan perancangan aplikasi baru atau
modifikasi aplikasi yang sudah ada sehingga aplikasi ini dapat saling berbagi
data dan fungsionalitas. Sebelum munculnya pemrograman soket sudah ada
upaya-upaya pengintegrasian dalam arti berbagi data yaitu metode berbagi data
berbasis file dan database.
Metode berbagi data berbasis file merupakan metode paling lama. Metode
berbagi data berbasis file dan menggunakan database merupakan metode berbagi
data yang bukan untuk waktu-nyata. Jika memerlukan secara waktu-nyata maka
harus dibantu dengan metode soket yang menyediakan koneksi waktu-nyata
antar aplikasi.
Metode pertama berbagi data melalui file ini merupakan metode yang
paling umum karena penyimpanan data di file sudah mendunia. Jenis
penyimpanan ini diperbolehkan oleh semua sistem perangkat keras dan sistem
13
operasi. Pada metode berbagi data ini, sebuah aplikasi menuliskan data ke file,
sedangkan aplikasi lain yang berjalan pada mesin yang sama dapat melakukan
baca dan tulis di file tersebut. Walaupun metode berbagi data melalui file
merupakan metode paling umum, namun metode ini mempunyai kelemahan
yaitu data tidak dapat dibagi secara waktu-nyata.
Kemudian disusul dengan metode berbagi data melalui database. Metode
ini mirip dengan metode sebelumnya metode file. Pada metode database ini,
suatu aplikasi menuliskan data ke database, dan aplikasi lain membaca data dari
database tersebut. Perbedaan penting dengan metode file adalah basidata
berjalan pada mesin yang terpisah. Hal ini berarti transfer data antar aplikasi
selalu terjadi melalui jaringan, sedangkan metode file membagi data pada mesin
yang sama. Oleh karena itu, metode ini lebih lambat dari pada metode file.
Keunggulan metode ini adalah koneksi antar aplikasi tidak secara point-to-point,
seperti metode file. Sejumlah aplikasi dapat membagi data yang dituliskan pada
database. Penggunaan database untuk integrasi aplikasi cukup terkenal karena
penggunaan relasi database berbasis SQL. Kebanyakan platform pengembangan
mendukung SQL, sehingga tidak perlu mengkawatirkan adanya beberapa format
file yang berbeda. Karena itu, sekali mempelajari SQL, akan dapat digunakan
untuk platform yang berbeda.
Menurut Roshen (2009) komputasi terdistribusi dimulai dengan
pengembangan pemrograman soket yang memungkinkan aplikasi membangun
koneksi langsung dan berbagi data secara waktu-nyata (Gambar 1.1 dan 1.2).
Membangun koneksi melalui soket merupakan dasar dari ide mengenai service-
14
service dan SOA. Hal ini disebabkan pengembangan service dan SOA
berikutnya menggunakan landasan soket. Jadi sulit membayangkan ide service
dan SOA saat ini akan berkembang tanpa adanya soket.
Gambar 1.1 Sisi server soket untuk berbagi data waktu-nyata (Roshen,
2009)
15
Gambar 1.2 Sisi klien soket untuk berbagi data waktu-nyata (Roshen,
2009)
Soket hanya memungkinkan berbagi data saja. Soket tidak

memungkinkan berbagi fungsionalitas secara langsung. Karena itu
pengembangan selanjutkan diperlukan aplikasi yang dapat berbagi
fungsionalitas. Dan teknologi berikutnya yang dapat berbagi fungsionalitas
adalah RPC yang dikenal sebagai pemrograman klien-server. RPC dibangun
dengan landasan soket dan menyembunyikan pemrograman jaringan level
rendah (lihat Gambar 1.3). Berkaitan dengan berbagi fungsionalitas antar
aplikasi, RPC juga memperkenalkan cara elementer dalam mendeklarasikan
antarmuka service dan ide platform independen melalu penggunaan external
data representation (XDR).
16
Gambar 1.3 Remote Procedure Call (Juric et al, 2007)
Setelah RPC, disusul dengan teknologi Object Request Broker (ORB)

yang memperkenalkan ide pemrograman berorientasi obyek ke dalam komputasi
terdistribusi. Secara khusus, teknologi ORB (lihat Gambar 1.4) memperluas ide
obyek dalam pemrograman berorientasi obyek ke obyek jarak jauh. Pada obyek
jarak jauh ini, obyek dapat berada di aplikasi berbeda yang berjalan di komputer
yang berbeda pula. Teknologi ORB telah membuat obyek jarak jauh ini dapat
berkomunikasi satu sama lain. Obyek jarak jauh ini dapat berbagi fungsionalitas
dan data dalam banyak cara seperti teknologi RPC. Contoh teknologi ORB yang
sangat terkenal adalah CORBA dan Java RMI. Secara khusus, CORBA
memperkenalkan sejumlah ide baru yang berkaitan dengan service-service dan
17
SOA seperti antarmuka service yang bebas bahasa pemrograman, konsep awal
tentang registry dan pemisahan aplikasi yang berbeda dari fungsionalitas yang
berkaitan jaringan, dan kode untuk marshalling dan unmarshaling yang sangat
meningkatkan penggunaan kembali kode karena kode yang sama dapat
digunakan oleh sejumlah aplikasi yang berbeda. Server aplikasi semacam
WebSphere Application Server dan JBoss menggunakan teknologi ORB.
Gambar 1.4 Object Request Broker (Juric et al, 2007)
Paralel dengan pengembangan teknologi ORB, Asynchronous Messaging

juga dikembangkan, yang dikenal sebagai teknologi Message Oriented
Middleware (MOM). Teknologi MOM ini (lihat Gambar 1.5) juga dilandasi
18
oleh soket tetapi menyediakan beberapa kelebihan seperti skalabilitas integrasi

aplikasi. Skalabilitas ini dihasilkan dari sifat messaging yang asynchronous,
yang memungkinkan aplikasi pengirim tetap melanjutkan kerjanya tanpa
menunggu respon dari aplikasi penerima. Method pertukaran pesan antar aplikasi
menggunakan queues untuk pengiriman dan penerimaan pesan. Method
pertukaran pesan yang tidak langsung ini menyediakan ikatan longgar antara
aplikasi pengirim dan penerima. Kelebihan lain adalah bahwa pengiriman pesan
dapat dijamin dengan penyimpanan di dua sisi jaringan.
Gambar 1.5 Message Oriented Middleware (Juric et al, 2007)
19
Sinkronisasi pesan dapat disimulasikan menggunakan ID korelasi untuk

membandingkan request pesan dengan response pesan. Pengembangan yang
terkait erat adalah pengembangan router atau perantara pesan yang dapat
merutekan pesan berbasis isi atau konteks.
Kemudian hadir Web service, yang memperkenalkan standar untuk
mengurangi heterogenitas yang disebakan oleh penggunaan beberapa teknologi
(seperti RPC, ORB, dan messaging). Selain itu juga diperkenalkan standard
format data independen yang disebut Extensible Markup Language, atau XML.
Kemudian definisi antarmuka service sebelumnya diperbaiki dengan pengenalan
WSDL, yang memungkinkan antarmuka service dideklarasikan dalam bentuk
bahasa pemrograman, platform dan middleware yang independen. Sama seperti
WSDL, ide sebelumnya tentang pendaftaran service juga disempurnakan dengan
pengenalan antarmuka Universal Description, Discovery, and Integration
(UDDI). Akhirnya, format standard untuk pertukaran pesan telah dikenalkan
dalam bentuk SOAP.
Dalam banyak kasus, Web service sendiri belum cukup untuk mengurusi
segala masalah heterogenitas. Secara khusus, Web service belum dapat
menangani adanya ketidaksesuaian protokol komunikasi antara penyedia
service dengan pemakai service. Selain itu, Web service juga belum dapat
menyediakan solusi memuaskan dalam mengatasi ketidaksesuaian format
data/pesan antara penyedia service dan pemakai service. Kemudian muncul ESB
yang dapat mengatasi masalah tersebut. ESB menyediakan beberapa fungsi
yang mencakup transformasi protokol dan pesan, rmerutekan pesan didasarkan
20
pada isi dan konteks, transparansi lokasi, kualitas service, pengayaan data, dan
fungsi lain.
Selain Web service yang menggunakan aplikasi baru dan ESB, SOA harus
menyediakan cara untuk mengintegrasikan aplikasi yang sudah ada untuk
menawarkan solusi integrasi lengkap. Hal ini berarti memerlukan
pembungkusan (wrapping) aplikasi yang sudah ada ke dalam Web service atau
menggunakan adapter yang memungkinkan aplikasi yang ada berkomunikasi
satu sama lain. Mengenai perkembangan teknologi integrasi berbasis SOA ini
dapat dilihat pada Gambar 1.6.
21
SOA
Transformasi protokol
ESB Transformasi message / data
Routing berbasis content atau
context
Format data XML

Perbaikan konsep registry
Web Services Perbaikan definisi interface
SOAP
Pemisahan komponen dari jaringan

Messaging Marshaling fungsionalitas
Konektivitas yang dapat diperluas
Jaminan pengiriman message
Interface yang netral dari bahasa

pemrograman
ORB Pengenalan konsep registry
Pemisahan komponen untuk
jaringan
Marshalling fungsionalitas
Berbagi fungsionalitas
RPC Deskripsi interface
Bebas platform
Konektivitas
Socket
Berbagi data secara real time
Gambar 1.6 Perkembangan teknologi integrasi berbasis SOA (Roshen,

2009)
22
1.3 Konsep SOA

Menurut Erl, SOA merupakan arsitektur sofware yang dibangun
menggunakan prinsip-prinsip perancangan berorientasi service, sedangkan
orientasi service merupakan konsep dalam rekayasa sofware yang
merepresentasikan pendekatan berbeda untuk memisahkan kepentingan (Erl,
2005). Hal ini berarti bahwa fungsionalitas sistem dipecah ke dalam unit logik
yang lebih kecil yang dinamakan service. Service-service 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 service, descriptions, dan messages. Service
berkomunikasi dengan yang lain melalui message yang memungkinkan interaksi
antar services, yang ditetapkan oleh description. Dua service berkomunikasi satu
sama lain yang diacu sebagai service requestor dan service provider. Service
requestor adalah service yang memanggil service lain, sedangkan yang dipanggil
disebut service provider.
Service sendiri dapat dipandang sebagai enkapsulasi lojik dari satu
atau sekumpulan aktivitas tertentu. Otomasi bisnis merupakan sekumpulan
aktivitas yang disusun dalam langkah-langkah sebagai implementasi proses
bisnis. Setelah seluruh permasalahan dapat dibagi dalam beberapa service, solusi
dari permasalahan tersebut harus bisa diselesaikan dengan memungkinkan
seluruh service berpartisipasi dalam sebuah orkestrasi. Untuk itu ada beberapa
permasalahan yang harus dimiliki oleh service, yaitu bagaimana service
23
berhubungan, bagaimana service berkomunikasi, bagaimana service didesain,

dan bagaimana pesan antar service didefinisikan (Erl, 2005).
Selain definisi SOA oleh Erl, masih ada beberapa definisi SOA yang
mirip dari sumber lain. Kadang kala definisi SOA ini dinamakan sebagai
framework eb services, yang secara umum dapat dilihat pada gambar 1.7.
Gambar 1.7 : Service-Oriented Architecture (Erl, 2005)
Service menyediakan service ke publik, berperan sebagai service

provider yang menyediakan deskripsi service nya ke service registry. Service
requestor, meminta pengiriman service dari service provider menggunakan
service registry ini. Dua service ini diikat satu sama lain, untuk pertukaran data
dan menggunakan fungsionalitas lain. Ini sesuai dengan definisi Erl yang
diperluas dengan service registry. Pada service registry ini, service dapat
didaftarkan dengan service description nya, sehingga service ini dapat
ditemukan oleh service requestor. Dalam hal ini Erl memperluas definisinya
24
tentang SOA yang masih sangat mendasar dengan menggunakan framework

web service, yang merupakan definisi SOA yang konkrit yang didasarkan pada
web service.
Framework web service ini merupakan framework teknologi yang
didasarkan secara standard, yang dipetakan ke dalam model SOA primitif
sebagai berikut :
Services direalisasikan sebagai web service
Message dideskripsikan oleh protokol SOAP
Deskripsi ditetapkan oleh WSDL
Pada model primitif, service registry menggunakan UDDI
Hal ini pada dasarnya sesuai dengan korelasi ditunjukkan pada Gambar
2.1. 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 web service dan kebutuhannya, tetapi
konsep ini dapat diabstraksikan untuk membangun fondasi SOA secara umum.
Krafzig et al, mendefinisikan SOA dari sudut pandang enterprise,
sehingga definisinya tidak se abstrak definisi Erl. Namun Krafzig menjelaskan
bagian konkrit SOA yang digunakan untuk memecahkan masalah yang
berkaitan dengan enterprise. Krafzig et al. bahkan memberikan definisi eksplisit
dari SOA dan komponen masing-masing: "Service-Oriented Architecture (SOA)
adalah sebuah arsitektur software yang didasarkan pada konsep-konsep kunci
dari frontend aplikasi, service, service repository, dan service bus. Service terdiri
dari contract, satu atau lebih interface, dan implementasi. Elemen-elemen SOA
25
dan ketergantungan mereka seperti yang dijelaskan diatas dapat dilihat pada
gambar 1.8. Setiap entitas pada diagram ini disajikan sebagai segiempat.
Aplication frontend merupakan pemilik proses bisnis dan dikoneksikan
ke service melalui service bus. Service didefinisikan melalui interface yang
memungkinkan akses ke service, contract yang menetapkan fungsionalitas dan
implementasi service. Implementasi service menyediakan logika bisnis dan data
yang relevan. Service menyediakan fungsionalitas bisnis yang dapat digunakan
oleh application frontend atau service lain. Service repository digunakan untuk
menyimpan service contract dari service sehingga dapat menggunakan service.
Jelas ada kesamaan antara definisi SOA menurut Erl dan Krafzig.
Keduannya berisi service sebagai entitas dasar di dalam konsep mereka, dan
service description yang mendeskripsikan service yang disediakan. Keduanya
juga mengandung komponen komunikasi antar service, tetapi Erl menggunakan
message sebagai konsep abstrak, disisi lain Krafzig memanfaatkan sebuah
service bus. Dalam definisi Erl dalam SOA dasar, tidak ada elemen service
registry, sebaliknya pada Krafzig, service registry merupakan komponen SOA.
Tetapi dalam definisi web service berbasis SOA, menurut Erl, service registry
merupakan bagian penting SOA. Selain itu, definis Krafzig berisi beberapa
elemen tambahan yang tidak dapat ditemukan pada SOA dasar ataupun web
service SOA pada Erl.
26
Gambar 1.8 : Komponen SOA
SOA adalah sebuah bentuk teknologi arsitektur yang mengikuti prinsip-

prinsip service-orientation (berorientasi service). Konsep service-orientation ini
melakukan pendekatan dengan membagi masalah besar menjadi sekumpulan
service kecil yang bertujuan untuk menyelesaikan permasalahan tertentu.
Setelah seluruh permasalahan dapat dibagi dalam beberapa service, solusi dari
permasalahan tersebut harus bisa diselesaikan dengan memungkinkan seluruh
service berpartisipasi dalam sebuah orkestrasi. Untuk itu ada beberapa
permasalahan yang harus dimiliki oleh service, yaitu bagaimana service
27
berhubungan, bagaimana service berkomunikasi, bagaimana service didesain,

dan bagaimana pesan antar service didefinisikan (Erl, 2005).
Pembagian berdasarkan service ini sesungguhnya bukan sesuatu yang baru,
karena telah banyak diterapkan. Namun hal baru dari pendekatan service-
oriented ini terkait dengan sifat- sifat yang dimilikinya (Erl, 2005), yaitu:
1. Loosely coupled, yaitu setiap service berdiri sendiri secara independen
dan tidak tergantung service lain untuk berjalan. Ketergantungan
diminimalisir sehingga hanya butuh mekanisme komunikasi satu sama lain.
2. Service contract, yaitu setiap service memiliki kesepakatan mengenai cara
untuk komunikasi
3. Autonomy, yaitu service memiliki hak penuh terhadap semua lojik yang
dienkapsulasi
4. Abstraction, yaitu service tidak memperlihatkan bagaimana lojik
diimplementasi di dalamnya.
5. Reusability, yaitu lojik dibagi menjadi sekumpulan service yang dapat
memudahkan reuse.
6. Statelessness, yaitu service tidak memiliki status tertentu terkait dengan
aktivitas yang dilakukannya.
7. Discoverability, yaitu service didesain untuk deskriptif sehingga bisa
ditemukan dan diakses melalui mekanisme pencarian tertentu.
28
SOA terdiri atas sekumpulan service. Namun sekumpulan service tidak

cukup untuk membentuk sebuah arsitektur ini. Menurut (Erl, 2005), SOA terdiri
atas empat komponen, yaitu:
1. Message, yaitu data yang dibutuhkan untuk menyelesaikan sebagian atau
sebuah unit kerja, yang dipertukarkan antara satu service dengan yang lainnya
2. Operation, yaitu fungsi-fungsi yang dimiliki oleh sebuah service untuk
memproses message hingga menghasilkan sesuatu. Fungsi-fungsi inilah
yang nantinya akan saling berinteraksi untuk menyelesaikan sebuah unit
kerja
3. Service, merepresentasikan sekumpulan operation yang berhubungan
untuk menyelesaikan sekumpulan unit kerja yang berhubungan
4. Process, merupakan business rule yang menentukan operasi mana yang
digunakan untuk mencapai tujuan tertentu.
1.4 Arsitektur Integrasi

Untuk dapat memahami arsitektur integrasi adalah dengan memahami
topologi integrasi yang berbeda. Arsitektur integrasi secara mendasar dapat
dibedakan menjadi empat jenis yaitu (Binildas, 2008) : Point-to-Point, Hub-and-
Spoke, Enterprise Message Bus, dan Enterprise Service Bus.
1.4.1 Point-to-Point
EAI secara tradisional telah dikerjakan dengan menggunakan integrasi
secara point-to-point. Dalam integrasi point-to-point, maka terlebih dahulu
29
didefinisikan solusi integrasi untuk sepasang aplikasi, sehingga ada dua end
point yang akan diintegrasikan. Kemudian membangun protokol dan atau
format adapter, atau transformer pada satu atau kedua end points. Ini
merupakan cara termudah untuk integrasi, sepanjang jumlah yang diintegrasikan
masih sedikit. Teknologi yang digunakan untuk integrasi ini biasanya adalah
FTP, IIOP, remoting atau batch interfaces. Keunggulan arsitektur ini adalah
integrasi secara tight coupling, sehingga kedua end points saling mengetahui
pasangannya.
Gambar 1.9 berikut ini adalah merupakan gambar diagram dari integrasi
point-to-point:
Gambar 1.9 Arsitektur integrasi point-to-point

30
1.4.2 Hub-and-Spoke
Arsitektur hub-and-spoke juga dinamakan message broker dan mirip
dengan arsitektur point-to-point ditambah dengan sebuah hub (broker) yang
menghubungkan seluruh aplikasi. Fitur lain dari arsitektur hub-and-spoke
adalah bahwa setiap aplikasi dihubungkan dengan central hub melalui konektor
ringan (lightweight connectors). Lightweight connectors memudahkan integrasi
aplikasi dengan sedikit perubahan atau tanpa perubahan pada aplikasi yang ada.
Transformasi message dan routing terjadi di dalam hub. Arsitektur 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 setup integrasi.
Namun ada kelemahan dalam arsitektur hub-and-spoke, yaitu terletak
pada sifat hub yang terpusat. Jika hub gagal maka keseluruhan integrasi juga
gagal.
Gambar 1.10 berikut ini adalah gambar diagram dari integrasi hub-and-
spoke:
31
Gambar 1.10 Arsitektur integrasi hub-and-spoke
1.4.3 Enterprise Message Bus

Arsitektur hub-and-spoke menggunakan lightweight connectors untuk
mengintegrasikan aplikasi melalui sebuah central hub, sehingga aplikasi dapat
dengan mudah ditambahkan atau dihilangkan tanpa mempengaruhi yang lain.
Enterprise message bus menyediakan infrastruktur komunikasi umum yang
bertindak sebagai adapter antar aplikasi yang netral-platform dan netral-bahasa-
pemrograman.
32
Infrastruktur komunikasi ini mencakup message router dan atau saluran

Publish-Subscribe. Sehingga aplikasi berinteraksi satu sama lain melalui
message bus dengan bantuan antrian request-response. Jika aplikasi konsumer
ingin melakukan invoke ke service tertentu pada aplikasi provider yang lain,
maka aplikasi konsumer mengirimkan request message dengan format yang
cocok pada antrian request untuk service yang bersangkutan. Aplikasi provider
kemudian mendengarkan untuk response message pada antrian services reply.
Aplikasi provider mendengarkan untuk request pada antrian service's request,
menampilkan service, kemudian mengirimkan beberapa response untuk antrian
service's reply.
Vendor terbaik untuk solusi antrian message untuk integrasi aplikasi
dalam topologi message bus biasanya adalah IBM's Websphere MQ (WMQ) dan
Microsoft MQ (MSMQ). Seperti yang ditunjukkan pada gambar 10 berikut ini,
kadangkala aplikasi harus menggunakan adapter yang menangani skenario
seperti invokasi transaksi CICS. Adapter semacam ini akan menyediakan
konektivitas antar aplikasi dan message bus menggunakan bus API dan aplikasi
API berlisensi. Message bus juga memerlukan struktur perintah umum yang
menyajikan operasi yang berbeda pada bus. Perintah ini mengatur invoke bus
yang mencakup listening ke sebuah address, membaca bytes dari sebuah address,
dan menuliskan bytes ke sebuah address.
33
Gambar 1.11 Arsitektur integrasi Enterprise Message Bus
1.4.4 Enterprise Service Bus

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 Service Oriented Architecture (SOA). Fitur
arsitektur ESB yang paling membedakan adalah sifat terdistribusi dari topologi
integrasi. Kebanyakan solusi ESB berbasis pada teknologi Web service
Description Language (WSDL) dan menggunakan format Extensible Markup
Language (XML) untuk translasi dan transformasi message.
ESB merupakan sekumpulan middleware services yang menyediakan
kemampuan integrasi. Middleware services ini merupakan jantung arsitektur
ESB yang menempatkan message untuk dapat diroutekan dan ditransformasikan.
34
Mirip dengan arsitektur hub-and-spoke, dalam arsitektur ESB, aplikasi

melakukan koneksi ke ESB melalui intelligent connectors. Connectors ini
abstrak karena hanya mendefinisikan transport binding protocols dan service
interface, dan bukan merupakan rincian implementasi real. Connectors ini
intelegent karena mempunyai logic built-in pada ESB untuk melakukan bind
service secara selektif pada saat run time. Kemampuan ini meningkatkan
kecerdasan untuk aplikasi dengan memungkinkan late binding dari service dan
melakukan penundaan pilihan service.
Gambar 1.12 Arsitektur integrasi Enterprise Services Bus

35
Fitur dan fungsionalitas utama yang didukung ESB akan membantu

dalam memahami arsitektur ESB ini yaitu (Binildas, 2008):
a. Addressing dan routing
b. Jenis synchronous dan asynchronous
c. Multiple transport dan protocol bindings
d. Content transformation dan translation
e. Business process orchestration
f. Event processing
g. Adapter untuk berbagai platform
h. Integrasi dari tool perancangan, implementasi dan deployment
i. Fitur Qualtiy of Services seperti transaksi, keamanan dan persistence
j. Auditing, logging, dan metering
k. Manajemen dan monitoring
Enterprise Service Bus (ESB) merupakan infrastruktur software yang
bertindak sebagai lapisan intermediary dari middleware. ESB menambahkan
fleksibilitas yang memungkinkan koneksi service diimplementasikan dalam
teknologi yang berbeda (seperti EJB, messaging sistems, komponen CORBA,
dan aplikasi legacy) dalam cara yang mudah. ESB dapat bertindak sebagai
mediator antar protokol dan produk middleware yang berbeda atau bahkan tidak
kompatibel (Juric, 2007).
ESB menyediakan infrastruktur komunikasi antar service yang kuat,
dapat diandalkan, aman dan dapat diperluas. ESB juga menyediakan kendali
36
komunikasi dan kendali atas penggunaan services yang mencakup (Juric, 2007)
:
a. Kemampuan menangkap pesan (message interception), yang
memungkinkan untuk menangkap pesan request untuk services dan pesan
response dari service, serta memberikan pemrosesan tambahan. Dengan
cara ini, ESB dapat bertindak sebagai intermediary.
b. Kemampuan routing, yang memungkinkan ESB melakukan routing pesan
ke services yang berbeda didasarkan pada isi (content), asal, atau atribut lain.
c. Kemampuan transformasi, yang memungkinkan transformasi pesan sebelum
dikirimkan ke services. 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 services. Hal ini
memungkinkan adanya logging, profiling, load balancing, performance
tuning, ongkos penggunaan services, distributed deployment, on-the-fly
reconfiguration, dsb.
e. Fitur manajemen lain yang mencakup definisi korelasi antar pesan, definisi
path komunikasi yang handal, definisi security constraints yang berkaitan
dengan pesan dan services, dsb.
ESB menyediakan dukungan untuk keragaman teknologi atas service
yang diimplementasikan. ESB juga menyediakan konektor untuk range
penggunaan teknologi yang luas, seperti komponen J2EE dan .NET, messaging
middleware, aplikasi legacy, dan monitor Transactions Processing. ESB
37
menyediakan fleksibilitas dalam melakukan bind beberapa kombinasi service

tanpa adanya hambatan teknologi. ESB mendukung kombinasi dari model
interaksi yang berbeda, seperti queuing, routing, dsb., tanpa perubahan service
atau penulisan kode lagi.
ESB menyediakan service secara meluas. Ini berarti bahwa ESB akan
mudah ditemukan, dan dikoneksikan. Dengan service yang tersedia secara
meluas, ESB dapat meningkatkan penggunaan ulang dan menggabungkan
service secara lebih mudah. Akhirnya, ESB menyediakan kemampuan
pengelolaan, seperti message routing, interaksi, dan transformasi.
ESB yang menyediakan fitur-fitur ini menjadi bagian esensial dari SOA.
ESB ini menyediakan beberapa manfaat, termasuk fleksibilitas yang meningkat,
mengurangi ongkos deployment, pengembangan dan pemeliharaan, dan
meningkatkan kehandalan dan pengelolaan.
38
BAB 2
Web service, BPEL dan ESB
Seperti telah dijelaskan sebelumnya, SOA terdiri atas sekumpulan service.

Menurut Luthria et al, (2009), jika service mencerminkan fungsi bisnis di dalam
model komputasi berbasis service, maka SOA menyediakan kerangka kerja
untuk infrastruktur yang memudahkan interaksi dan komunikasi antar service.
SOA dapat dipandang sebagai arsitektur maupun model pemrograman, lebih
merupakan cara berpikir mengenai pengembangan perangkat lunak daripada
teknik pengembangan perangkat lunak. Hampir serupa dengan Luthria et al,
(2009), Mueller et al, (2010) juga menyatakan bahwa SOA merupakan
paradigma arsitektur terdistribusi, multi layer, yang membungkus bagian dari
sistem informasi sebagai service.
SOA juga merupakan paradigma perangkat lunak yang berlaku secara
dinamis untuk mengintegrasikan service secara longgar ke dalam satu proses
bisnis yang kohesif menggunakan kerangka kerja komponen perangkat lunak
secara standard. Sistem berbasis SOA dapat mengintegrasikan service legacy
maupun service baru, yang dibuat perusahaan dan dipasang di dalam atau di luar
penyedia service (Lin et al, 2009). Menurut Kart et al (2008) SOA
memungkinkan penggunaan ulang dari komponen perangkat lunak,
menyediakan protokol bebas, dan memudahkan integrasi aplikasi. SOA
menguatkan prinsip-prinsip arsitektur perangkat lunak dalam hal perancangan
39
modular, abstraksi dan enkapsulasi. Dengan standard terbuka seperti XML dan
SOAP, SOA menyediakan interoperabilitas antar service yang bekerja pada
platform berbeda dan antar aplikasi yang diimplementasikan dalam bahasa
pemrograman yang berbeda.
2.1 Arsitektur Web service

Dalam hal ini Web service merupakan sebuah teknologi yang dapat
digunakan untuk mengimplementasikan service . (Salter-Jennings, 2008).
Menurut Hwang et al, (2008), Web service secara fakta telah menjadi standard
untuk melakukan ekspose fungsi dari aplikasi bisnis, Web service akan menjadi
blok bangunan untuk pengembangan aplikasi generasi mendatang menggunakan
SOA. Walaupun arsitektur SOA saat ini mendukung registry, discovery dan
konsumsi Web service, namun cara efektif mengintegrasikan beberapa Web
service ke dalam sebuah komposit tetap merupakan sebuah tantangan dan
menarik perhatian dari industri dan akademis.
Web service telah banyak dipakai untuk membangun aplikasi berbasis
SOA. Malah dengan penggunaan Web service ini, potensi-potensi SOA baru
dapat dimunculkan. Hal inilah yang menyebabkannya Web service identik
dengan SOA. Selain itu, perluasan dari Web service yang disebut dengan WS-*,
memberikan pengaruh terhadap perkembangan SOA. Akibatnya, SOA semakin
identik dengan Web service. Atas dasar ini Erl (2005) menyebutnya sebagai
Contemporary SOA. Contemporary SOA merupakan SOA yang menggunakan
40
Web service dan XML dalam implementasinya. Untuk selanjutnya, yang disebut
sebagai SOA adalah Contemporary SOA.
Definisi yang diajukan oleh W3C tentang Web service adalah: Web
service merupakan aplikasi perangkat lunak yang diidentifikasi melalui URI
yang antarmuka dan binding nya mampu diidentifikasi, dideskripsikan dan
ditemukan melalui XML dan mendukung interaksi langsung dengan aplikasi
perangkat lunak lain menggunakan pesan berbasis XML melalui protokol
berbasis internet.
Perkembangan Web service yang begitu cepat menyebabkan lahirnya
ekstensi-ekstensi Web service yang memperluas fungsi Web service itu sendiri.
Untuk membedakan Web service dasar dengan ekstensi-ekstensinya, maka
keduanya dibedakan menjadi Web service generasi pertama dan Web service
generasi kedua. Web service generasi pertama adalah pondasi dari teknologi
Web service ini sendiri. Implementasi dari teknologi ini, yang berupa aplikasi
Web service, saling berinteraksi satu sama lain dengan menggunakan dokumen
berformat XML dan protokol pengiriman pesan SOAP (Simple Object Access
Protocol) melalui HTTP. Format XML, SOAP, dan HTTP ini juga merupakan
standar terbuka yang dapat diadopsi (Erl, 2004, Kumar, 2010).
Perkembangan teknologi Web service berlanjut pada munculnya
ekstensi-ekstensi dari Web service, yang biasa disebut generasi kedua Web
service atau WS-* (Erl, 2004, Kumar, 2010). Ekstensi ini merupakan
pengembangan dari teknologi Web service dasar yang muncul disebabkan
kebutuhan-kebutuhan yang ada di dalam perusahaan. Adapun beberapa ekstensi
41
yang jamak digunakan adalah WSCoordination, WSTransaction, Business

Process Execution Language for Web service (BPEL4WS atau WS-BPEL),
WS-ReliableMessaging, WSAddressing, WSPolicy, WSPolicyAssertions,
WS PolicyAttachments, WS Attachments, dan SOAP with Attachments (SwA).
Gambar 2.1 Arsitektur Web service (Juric et al, 2007)
Komponen Web service terdiri dari 3 yaitu SOAP, WSDL dan UDDI
(Gambar 2.1). Penjelasan dari ketiga komponen tersebut akan diuraikan dibawah
ini.
1. SOAP
Dalam komunikasi antara Web service diperlukan suatu standard format
pesan antara peminta service dengan penyedia service. SOAP adalah format
pesan yang digunakan untuk komunikasi tersebut. SOAP mendefinisikan
mekanisme pembungkusan yang mengatur pertukaran pesan antara Web
42
service. Pesan SOAP adalah dokumen XML yang mengandung tiga elemen
yaitu envelope, header, body. Struktur umum SOAP dapat dilihat pada
Gambar 2.2.
Envelope adalah elemen utama dari pesan SOAP. Elemen ini mengandung
elemen header yang opsional dan elemen body yang harus ada. Elemen
header adalah mekanisme umum untuk mendefinisikan fitur tambahan pada
SOAP. Elemen body berisi deskripsi pesan aktual ditujukan untuk penerima
akhir dan akan diproses. Komunikasi pesan SOAP antar Web service ini
ilakukan melalui protokol HTTP.
Gambar 2.2 Elemen SOAP (Erl et al, 2008)

43
2. WSDL
WSDL adalah spesifikasi dari W3C yang menyediakan bahasa untuk
mendeskripsikan definisi dari Web service (Erl et al, 2008). Dalam definisi
tersebut termasuk juga deskripsi service dan fungsifungsi yang disediakan oleh
Web service.
Gambar 2.3 menunjukkan ada 5 elemen WSDL yaitu types, message,
portType, binding, dan service/port yang menjelaskan service (Erl et al, 2008).
types Elemen ini mendefinisikan type data yang terdapat dalam pesan
yang dipertukarkan sebagai bagian dari service. Type data berupa
simple, complex, derviced, atau array. Type (baik definisi skema
maupun reference) yang diacu dalam elemen dokumen pesan WSDL
didefinisikan dalam elemen type dokumen WSDL.
message Elemen ini mendefinisikan pesan dari service yang
dipertukarkan. Dokumen WSDL mempunyai elemen pesan yang tiap
pesannya dipertukarkan dan elemen pesan berisi type data yang
diasosiasikan dengan pesan.
44
WSDL document
Abstract description
types Jenis data apa yang digunakan?
messages Pesan apa yang dikirim dan

diterima?
portTypes Fungsi apa yang didukung service?
operation
operation
operation
Concrete description
Bagaimana service digunakan
bindings protokol jaringan?
Rincian SOAP?
operation
services Dimana letak service?

operation
Gambar 2.3 Lima elemen WSDL (Erl et al, 2008)
portType Elemen ini menetapkan secara abstrak, operasi dan pesan yang
merupakan bagian dari service. Dokumen WSDL mempunyai satu atau
lebih definisi portType.
45
binding Elemen ini melakukan bind type port abstrak dan pesan dan
operasinya, untuk protokol transport dan untuk format pesan.
service and port Elemen-elemen ini bersama-sama mendefinisikan nama
service aktual dan menyediakan address tunggal untuk menetapkan end
point individual dari service. Port dapat mempunyai satu alamat.
Kelompok elemen service berkaitan dengan port dan melalui atribut nama,
menyediakan nama logikal untuk service.
3. UDDI Registry
UDDI adalah spesifikasi yang telah diakui secara luas untuk pendaftaran
suatu Web service. UDDI mendefinisikan metadata dan protokol yang digunakan
untuk mengetahui dan mengubah informasi dari suatu Web service. Langkah
pertama dalam menemukan Web service adalah dengan meminta alamat tempat
penyimpanan dari Web service yang akan dipakai yang biasa disebut dengan
direktori (Gambar 2.4).
Setelah menemukan direktori, peminta Web service dapat mengirimkan
permintaan lagi untuk mendapatkan informasi detail tentang Web service
(misalnya penyedia Web service dan dimana diletakkan). Selanjutnya perangkat
lunak menggunakan informasi yang didapat untuk secara dinamik mengakses
Web service yang diinginkan.
Tempat penyimpanan UDDI dapat dibagi dalam tiga cara, yaitu :
46
1. Public UDDI, dianggap sebagai resource bagi Web service berbasis internet.
Salah satu contohnya adalah UDDI Business Registry (UBR) yang dimiliki
oleh grup yang terdiri dari IBM, Microsoft, SAP.
2. Intra Enterprise UDDI, merupakan tempat penyimpanan yang private yang
menyediakan service bagi kalangan internal suatu perusahaan.
3. Inter Enterprise UDDI, merupakan repository yang dapat diakses oleh
perusahaan yang merupakan partner dalam suatu bisnis.
Seperti yang telah dijelaskan terdahulu, penemuan service memainkan
peranan yang penting dalam SOA. Banyak cara yang dapat dipakai untuk
mekanisme ini, tapi dalam teknologi Web service, UDDI menyediakan standard
yang baik dan fleksibel untuk penemuan service web.
Gambar 2.4 UDDI (Erl, 2005)
UDDI mengorganisasikan pendaftaran dalam enam tipe data (Erl, 2004):

1. Business Entity, menyimpan informasi profil mengenai bisnis yang
47
disimpan, termasuk nama, deskripsi, dan unique identifier.

2. Service bisnis, merepresentasikan service aktual yang ditawarkan oleh
bisnis terdaftar, disimpan dalam elemen businessEntity
3. Specification Pointers, menyimpan halaman dari service bisnis ke informasi
implementasi, disebut juga Binding Components
4. Service types, menyediakan informasi dari definisi internal
5. Business relationships, direpresentasi dengan publisherAssertion,
menyimpan hubungan antara entitas bisnis dengan yang lainnya
6. Subscriptions, direpresentasi dengan elemen subscription, memungkinkan
subscriber mendapatkan notifikasi saat profil business entity diperbaharui.
2.2 Integrasi Web service

Erl (2005) mengajukan metode integrasi yang dinamakan SOAD. Dalam
metode ini gap antara lojik bisnis dan aplikasi diisi oleh Interface Service Layer
yang berisi tiga lapisan yaitu Application Service Layer, Business Service Layer
dan Orchestration Service Layer. Siklus hidup SOAD diterapkan pada
pengembangan Interface Service Layer. Siklus hidup berisi enam fase yaitu
service-oriented analysis, service-oriented design, service development, service
testing, service deployment, dan service administration. Fase-fase ini mirip
dengan proyek pengembangan berorientasi obyek kecuali pada pengenalan
pertimbangan unik pada setiap fase dari konstruksi dan pengiriman service.
Misalnya pada fase analisis berorientasi service berisi tiga langkah 1)
48
mendefiniskan skope analisis, 2) mengidentifikasi sistem otomatisasi dan 3)

memodelkan kandidat service.
Seperti yang telah diuraikan pada latar belakang masalah, perangkat lunak
yang tidak menggunakan SOA secara umum dapat dibagi menjadi dua lapisan
utama, yaitu Lapisan Aplikasi tempat aplikasi dijalankan dan Lapisan Proses
Bisnis yang mendeskripsikan cara proses bisnis dalam perusahaan berjalan.
Proses bisnis organisasi akan didefinisikan dalam aplikasi bersamaan dengan
kode program yang bersifat teknis. Hal tersebut dapat dilihat pada Gambar 4.1.
Gambar 2.5 Lapisan lojik bisnis dan lojik aplikasi dalam SOAD (Erl,
2005)
Dalam implementasi SOA, konsep berorientasi service

diimplementasikan dalam sebuah lapisan di antara Lapisan Proses Bisnis dan
Lapisan Aplikasi yang keduanya merupakan bagian dari lojik perusahaan.
Lapisan tersebut dinamakan Interface Service Layer, dan dapat dilihat pada
49
Gambar 2.5 Fungsi dari lapisan ini adalah membungkus lojik yang ada di lojik
aplikasi, sekaligus proses bisnis yang ada di lojik bisnis. Dengan pendekatan ini,
aplikasi bisa lebih dimodularisasi dan menggunakan berbagai macam
teknologi.
Interface Service Layer ini juga terbagi atas 3 lapisan abstraksi, yaitu
Application Service Layer, Business Service Layer, dan Orchestration Service
Layer. Ilustrasi dari ketiganya dapat dilihat pada Gambar 2.6.
Gambar 2.6 Interface Service Layer pada SOA (Erl, 2005; Shirazi et al,
2009; Lee et al, 2010)
50
Aplication Service Layer

Dari Gambar 2.6, Aplication Service Layer. menyediakan sekumpulan
service yang spesifik untuk mengenkapsulasi teknologi tertentu yang terdapat
di dalam lojik aplikasi. Service yang disediakan dalam lapisan ini akan
melakukan abstraksi terhadap semua lojik yang tidak terkait dengan proses
bisnis, namun dibutuhkan untuk menjalankan fungsi-fungsi yang ada di proses
bisnis tersebut. Misalkan sebuah proses bisnis mengandung aktivitas notifikasi
yang mengharuskan pengiriman email kepada pihak yang dinotifikasi, maka
Aplication Service Layer menyediakan service untuk mengirimkan email.
Business Service Layer

Pada Gambar 2.6, Business Service Layer merepresentasikan lojik bisnis
dari aplikasi. Lapisan ini bisa diibaratkan sebagai controller dari Aplication
Service Layer. Pada Business Service Layer inilah fungsi-fungsi bisnis, yang
berupa aktivitas-aktivitas yang dilakukan untuk menjalankan proses bisnis
disediakan. Aktivitas-aktivitas tersebut akan menjalankan fungsi-fungsi yang
ada di Application Service Layer jika dibutuhkan. Lapisan ini sendiri
menyediakan abstraksi kepada pengguna servicenya mengenai fungsi-fungsi
bisnis yang ada, sehingga tidak perlu melihat bagaimana lojik aplikasi dijalankan
di sana.
Ada dua macam service yang mungkin disediakan oleh Business Service
Layer, yaitu:
51
1. Task-centric, yaitu sebuah service yang mengenkapsulasi lojik tertentu

dalam proses bisnis yang melibatkan satu atau dua entitas bisnis. Service
jenis ini memiliki potensi penggunaan ulang yang terbatas, namun proses
analisis untuk menghasilkannya akan lebih mudah
2. Entity-centric, yaitu service yang membungkus lojik yang sifatnya
spesifik terhadap entitas bisnis tertentu. Service jenis ini sangat baik dalam
penggunaan ulang, namun proses analisis yang dibutuhkan untuk
menghasilkannya lebih sulit.
Orchestration Service Layer

Orchestration Service Layer pada Gambar 2.6 merupakan sebuah
lapisan yang menyediakan abstraksi dengan level tertinggi dari aplikasi. Pada
lapisan ini semua proses bisnis yang ada di dalam sistem didefinisikan dan
dijalankan dengan menggunakan fungsi-fungsi yang terdapat pada
Orchestration Service Layer.
Walaupun siklus hidup SOAD menyediakan panduan umum yang bagus
untuk pengembang yang membangun Interface Service Layer, namun tidak ada
teknik pemodelan dan reverse engineering dari perusahaan yang sudah ada.
Selain itu SOAD juga tidak menyediakann dokumentasi UML.
52
2.3 Business Process Execution Language (BPEL)

Di dalam perusahaan, BPEL digunakan untuk standardisasi EAI dan
memperluas integrasi sistem yang masih terisolasi. Antar perusahaan, BPEL
memungkinkan integrasi dengan partner bisnis. BPEL memungkinkan
perusahaan untuk mendefinisikan proses bisnis, memperbaiki proses bisnis
sehingga lebih sesuai.
Penerapan suatu proses bisnis memerlukan standard dan bahasa khusus
untuk komposisi ke dalam proses bisnis yang menunjukkan proses bisnis secara
standard pula, dengan menggunakan bahasa yang dapat diterima umum. BPEL
merupakan bahasa yang dapat diterima umum dan cepat menjadi standard yang
dominan. Tujuan utama BPEL adalah untuk standardisasi otomasi proses antar
Web service.
Pada SOA, service-service menjadi blok bangunan utama dari
keseluruhan arsitektur. Service juga merupakan blok bangunan utama dalam
proses BPEL. Service-service tersebut merupakan operasi coarse-graine yang
disebut service bisnis. Operasi dalam service bisnis biasanya merepresentasikan
aktivitas bisnis. Service bisnis ini digunakan dalam proses bisnis atau tepatnya
BPEL menggunakan service bisnis ini untuk mengeksekusi aktivitas proses.
Dengan kata lain, proses pada BPEL merupakan komposisi dari service bisnis.
Service bisnis menyediakan fungsionalitas, sedangkan proses BPEL berisi aliran
proses (Juric et al, 2010).
Menurut Louridas (2008), program BPEL mempunyai empat bagian
utama yang terdiri dari :
53
1. Bagian <partnerLinks> mendefinisikan pihak-pihak yang bekerjasama

untuk memenuhi proses bisnis.
2. Bagian <variables> yang mendefinisikan struktur data yang akan digunakan
program. Definisi mengacu pada jenis pesan WSDL dan elemen dan jenis
XSD (XML schema definition)
3. Bagian <faultHandlers>, digunakan untuk menangani program yang akan
melakukan invokasi ketika ada kesalahan.
4. Bagian <sequence> mendefinisikan prosedur proses yang dikomposisi dari
BPEL activities.
2.3.1 Evolusi standard BPEL

Menurut Juric et al (2010) BPEL 1.0 dikembangkan oleh IBM, BEA dan
Microsoft pada Agustus 2002. Kemudian SAP dan Siebel kemudian bergabung
yang menghasilkan bebererapa modifikasi dan perbaikan yang muncul di versi
1.1 pada Maret 2003. Pada April 2003, BPEL dimasukkan ke OASIS
(Organization for the Advancement of Structured Information Standards) untuk
tujuan standardisasi, sementara itu WSBPEL TC (Web service Business Process
Execution Language Technical Committee) telah dibentuk. Sejak itu, banyak
vendor yang kemudian bergabung ke WSBPEL TC (http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=WSBPEL). Hal ini telah
mengakibatkan BPEL dapat diterima secara luas di industri. Pada april 2007,
BPEL versi 2.0 dikenalkan oleh OASIS. Evolusi perkembangan standard BPEL
54
dapat dilihat pada Gambar 2.7, sedangkan penjelasan tentang standard

manajemen proses bisnis dapat dilihat pada Tabel 2.1.
Gambar 2.7 Evolusi perkembangan standard BPEL (Josuttis, 2007;

Piispanen, 2008)
55
Tabel 2.1 Penjelasan Standard manajemen proses bisnis (Havey, 2005;

Piispanen, 2008)
Standard Organisasi Deskripsi
Business Process OASIS Bahasa BPM paling terkenal;
Execution Language menyajikan sebuah proses sebagai
(BPEL) XML dengan WS bindings
Business Process Business Bahasa proses XML yang mirip
Modeling Language Process dengan BPEL
(BPML) Modeling
Initiative
(BPMI)
Business Process BPMI Bahasa grafis dengan memetakan ke
Modeling Notation BPEL
(BPMN)
Workflow Reference Workflow Pendekatan arsitektur dasar ke
Model Management workflow/BPM
Coalition
(WfMC)
Workflow API WfMC API fungsional dan administrative
(WAPI) dengan definisi dalam bahasa C, IDL,
dan COM
XML Process WfMC Bahasa proses XML yang mirip
Definition Language dengan BPEL
(XPDL)
Workflow XML WfMC Bahasa XML untuk komunikasi
(WfXML) berbasis Web service antara workflow
runtime engines
Web service World Wide Bahasa XML yang matang untuk
Choreography Web koreografi Web service atau interaksi
Antarmuka (WSCI)
56
Standard Organisasi Deskripsi

Consortium berorientasi proses dari Web service
(W3C) diantara banyak partisipan
Web service W3C Bahasa koreografi XML resmi dari
Choreography W3C
Description Language
(WS-CDL)
Web service W3C Bahasa koreografi XML dasar yang
Conversation elegan
Language (WSCL)
Business Process Object Model untuk bahasa proses BPM yang
Definition Metamodel Management dibangun menggunakan Model Driven
(BPDM) Group Architecture (MDA)
(OMG)
Business Process OMG Model MDA untuk BPM API
Runtime Antarmuka fungsional dan administratif
(BPRI)
XLANG Microsoft Bahasa proses XML awal yang
dipengaruhi oleh perancangan BPEL
Web service Flow IBM Bahasa proses XML awal yang juga
Language (WSFL) dipengaruhi oleh perancangan BPEL
Business Process OASIS Bahasa proses untuk kolaborasi
Specification Schema business-to-business (B2B)
(BPSS)
Di antara cabang utama evolusi standard manajemen proses bisnis dapat

dibedakan sebagai berikut (Weske, 2007; Havey, 2005):
Cabang paling terkenal saat ini adalah BPEL
57
Cabang utama lain adalah Workflow Management Coalition (WfMC), yang

ditemukan tahun 1993 untuk menentukan standard untuk sistem manajemen
workflow. Standard pertama adalah Workflow Process Definition Language
(WPDL), tetapi standard definisi proses saat ini dalam pengaruh XML dan
dinamakan XML Process Definition Language (XPDL).
Standard ketiga yang penting adalah Business Process Modeling Notation
(BPMN), yang awalnya didefinisikan oleh Business Process Management
Initiation tetapi sekarang dijalankan oleh Object Management Group
(OMG).
Selain cabang utama, masih ada standard lain yang juga berkembang yang
mencakup (Weske, 2007; Havey, 2005):
Wf-XML, yang merupakan standard yang disediakan oleh WfMC untuk
mendefinisikan bagaimana menginstal definisi proses (yang didefinisikan
dengan BPEL dan XPDL) ke dalam sebuah mesin proses.
UML (Unified Modeling Language), yang menyediakan beberapa notasi
grafis (khususnya Diagram Activity) yang digunakan untuk aliran proses
(process flow).
WS-CDL (Choreography Definition Language), merupakan standard untuk
menentukan proses bisnis melalui koreografi.
BPSS (Business Process Specification Schema), yang merupakan bagian
dari standard ebXML (spesifikasi XML untuk electronic business)
58
EPC (Event-driven Process Chain), yang sekarang didukung oleh format

pertukaran EPC Markup Language (EPML). Format ini (lebih banyak di
Eropa) digunakan dengan SAP/R3 dan ARIS.
Hanya BPEL dan XPDL yang disediakan untuk mesin, dan BPEL saat ini
tidak mempunyai dukungan notasi (sering disebut business process
assembler). Untuk alasan ini perusahaan-perusahaan besar bekerja keras agar
dapat mentransfer bahasa pemodelan lain dan notasi ke dalam scenario
sederhana, karena mentransfer ke scenario yang lebih rumit dari satu model ke
model lain menjadi sangat suit. Namun ini lebih sulit dari kedengarannya. Ingat
bahwa OMG akhir-akhir ini telah memulai bekerja pada standard untuk
mentransfer Model Proses Bisnis. Standard ini dinamakan Business Process
Definition Metamodel (BPDM)
Notasi paling penting adalah BPMN (lihat Gambar 3.6), UML, dan EPC.
Tidak seperti BPEL, yang merupakan format XML murni untuk menentukan
proses bisnis, notasi grafis ini merupakan jaminan bahwa Diagram Proses Bisnis
akan kelihatan sama, sehingga tidak ada jawabn standar yang akan digunakan.
BPEL merupakan momentum dalam komunitas SOA, dan khusus dalam
dunia teknik Web service. Namun untuk masyarakat bisnis, BPMN dan EPC
nampak lebih intuitif, dan yang mendukung BPMN secara penuh adalah
kecanggihan XPDL.
Seperti telah dijelaskan sebelumnya, teknologi WS-* memberikan
peran terhadap berkembangnya SOAD, hingga menjadi Contemporary SOA.
Salah satu permasalahan pada SOA yang dapat diselesaikan oleh teknologi ini
59
adalah pembuatan proses bisnis, dengan WS-BPEL. Untuk mengkomposisi

sekumpulan Web service menjadi sebuah workflow, dibutuhkan sebuah
standar. Hal ini dimungkinkan dengan adanya WS-BPEL atau BPEL4WS.
Ekstensi Web service ini memiliki bahasa yang bisa dikompilasi dan
dijalankan oleh aplikasi yang mendukung orkestrasi. Ekstensi ini membawa
Web service ke dalam integrasi perusahaan. WS-BPEL adalah ekstensi Web
service yang digunakan untuk memfasilitasi proses pemodelan dan eksekusi
BPEL dalam Web service. BPEL sendiri merupakan sebuah bahasa pemodelan
berformat XML yang digunakan untuk mendeskripsikan proses bisnis. Model
yang dihasilkan oleh bahasa ini nantinya dapat dieksekusi oleh mesin BPEL.
Dengan demikian menurut Holanda et al (2010) BPEL telah menjadi standard
untuk menetapkan dan mengeksekusi spesifikasi alur kerja untuk invokasi
komposisi Web service.
Di dalam perusahaan, BPEL digunakan untuk standardisasi integrasi
aplikasi perusahaan dan memperluas integrasi dari sistem sebelumnya yang
terisolasi. Diantara perusahaan, BPEL memungkinkan lebih mudah dan lebih
efektif mengintegrasikan dengan partner bisnis. BPEL merangsang perusahaan
untuk mendefinisikan proses bisnis perusahaan, yang membawa prubahan ke
optimalisasi proses bisnis, reengineering, dan pemilihan proses yang paling
sesuai, sehinga dapat organisasi semakin optimal (Korherr, 2008).
60
2.3.2 Orkestrasi dan Koreografi

Tergantung pada kebutuhan, komposisi service dapat menekankan pada
proses publik atau privat, yang mengacu pada acuan orkestrasi atau koreografi.
Pada orkestrasi, proses sentral (yang dapat berupa Web service lain)
mengendalikan Web service yang terlibat dan mengkoordinasi eksekusi operasi
Web service yang berbeda yang terlibat dalam operasi. Hal ini dikerjakan sesuai
dengan kebutuhan dari orkestrasi. Web service yang terlibat tidak mengetahui
(dan tidak perlu tahu) baha Web service tersebut terlibat dalam komposisi dan
menjadi bagian dari proses bisnis yang lebih tinggi. Hanya koordinator sentral
dari orkestrasi yang mengetahui hal ini, sehingga orkestrasi disentralkan dengan
definisi operasi dan urutan invokasi dari Web service. Orkestrasi biasanya
digunakan untuk proses bisnis privat dan secara skematik dapat dilihat pada
Gambar 2.8 dibawah ini (Juric et al, 2010).
Orkestrasi service memungkinkan Web service dikomposisikan bersama
dengan pola yang telah ditetapkan sebelumnya, dideskripsikan menggunakan
bahasa orkestrasi dan dieksekusi pada mesin orkestrasi. Orkestrasi dapat
berlangsung di banyak aplikasi dan atau organisasi dan menghasilkan proses
transaksional yang lama. Service sendiri tidak mempunyai pengetahuan
mengenai keterlibatannya dalam aplikasi level yang lebih tinggi. Orkestrasi
service dideskripsikan dari sudut pandang partisipan tunggal (yang dapat berupa
Web service lain) dan karena itu , proses terpusat akan bertindak sebagai
pengendalii terhadap service yang terlibat. Bahasa orkestrasi mendeskripsikan
interaksi antara Web service melalui pengidentifikasian pesan, percabangan
61
lojik, dan rangkaian invokasi. BPEL merupakan bahasa pemodelan proses bisnis
yang dapat dieksekusi dan secara de facto menjadi standard cara melakukan
orkestrasi Web service. BPEL didukung oleh industri secara meluas yang
mencakup IBM, Microsoft, dan Oracle dengan implementasi yang konkrit.
(Barker et al, 2009)
Gambar 2.8 Orkestrasi Web service (Juric et al, 2010)
Koreografi pada sisi lain tidak tergantung pada koordinator sentral.

Setiap Web service yang terlibat dalam koreografi mengetahui secara pasti kapan
mengeksekusi operasi dan dengan siapa berinteriaksi. Koreografi merupakan
upaya kolaborasi yang dipusatkan pada pertukaran pesan dalam proses bisnis
publik. Semua partisipan dari koreografi sadar dalam proses bisnis, operasi
untuk eksekusi, pesan untuk pertukaran, dan waktu pertukaran pesan.
Koreografi dalam komposisi Web service ditunjukkan dalam Gambar 2.9 berikut
ini (Juric et al, 2010).
62
Gambar 2.9 Koreografi Web service (Juric et al, 2010)
2.4 Enterprise Service Bus (ESB)

ESB merupakan infrastruktur untuk mengintegrasikan aplikasi dan
service. ESB memperkuat SOA melalui pengurangan jumlah, ukuran, dan
kompleksitas antarmuka antara aplikasi dan service-service. ESB digunakan
untuk melakukan koneksi komponen 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 menggabungkan 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, 2010).
Pendekatan services bus untuk integrasi adalah menggunakan teknologi
yang menyediakan bus untuk integrasi aplikasi. Aplikasi-aplikasi yang berbeda
63
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 service-service yang menyediakan kemampuan
integrasi. Middleware service-service 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 2.10. Komponen dapat mengambil peran penghasil service
atau pemakai service. Service-service 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 database (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 service dan
pemakai komponen. Service melakukan koneksi melalui Binding Component
(BC) atau dapat di-host kedalam kontainer sebagai bagian dari Service Engine
(SE). Service-service dideskripsikan menggunakan WSDL. Pesan selalu
64
diterjemahkan ke dalam format pesan umum dan dirutekan oleh Normalized

Message Router (NMR)
Gambar 2.10 Arsitektur ESB secara umum (Juric, 2007; Andary-Sage,

2010)
ESB menyediakan infrastruktur komunikasi antar service yang kuat, dapat

diandalkan, aman dan dapat diperluas. ESB juga menyediakan kendali
komunikasi dan kendali atas penggunaan service-service yang mencakup (Juric,
2007) :
1. Kemampuan menangkap pesan, yang memungkinkan untuk menangkap
pesan request untuk service-service dan pesan response dari service, serta
65
memberikan pemrosesan tambahan. Dengan cara ini, ESB dapat bertindak

sebagai intermediary.
2. Kemampuan routing, yang memungkinkan ESB melakukan routing pesan
ke service-service yang berbeda didasarkan pada isi (content), asal, atau
atribut lain.
3. Kemampuan transformasi, yang memungkinkan transformasi pesan
sebelum dikirimkan ke service-service. Untuk pesan format XML,
transformasi semacam ini dilakukan menggunakan XSLT (Extensible
Stylesheet Language for Transformations) atau mesin XQuery.
4. Kendali atas deployment, penggunaan dan pemeliharaan service-service.
Hal ini memungkinkan adanya logging, profiling, load balancing,
performance tuning, ongkos penggunaan service-service, distributed
deployment, on-the-fly reconfiguration, dsb.
5. Fitur manajemen lain yang mencakup definisi korelasi antar pesan, definisi
path komunikasi yang handal, definisi security constraints yang berkaitan
dengan pesan dan service-service, dsb.
2.5 Java Business Integration

JBI merupakan sebuah standard yang dikembangkan oleh Java
Community Process sebagai sebuah pendekatan untuk mengimplementasikan
SOA. JBI mendefinisikan lingkungan untuk komponen plugin yang berinteraksi
menggunakan Model Service berbasis WSDL. Komponen plugin berfungsi
sebagai penyedia service atau pemakai service atau keduanya. Komponen yang
menyediakan atau mengkonsumsi service secara lokal (didalam lingkungan JBI)
66
dinamakan Service Engine. Komponen yang menyediakan atau mengkonsumsi

service menggunakan beberapa protokol komunikasi dinamakan Binding
Component. Binding Component dan Service Engine hanya berbeda secara
logika dan fungsinal, namun secara teknis keduanya mengimplemtasikan
antarmuka yang sama. Selain Service Engine dan Binding Component masih ada
satu komponen lagi yaitu Normalized Message Router (NMR). NMR merupakan
backbone dari JBI yang memudahkan interoperasi antara komponen JBI
menggunakan service descriptor berbasis WSDL. Pesan dirubah dalam format
normalized (Binildas, 2008, Kumar et al, 2010, Schmutz et al, 2010). Untuk
kejelasannya dapat dilihat pada Gambar 2.11.
Gambar 2.11 Arsitektur JBI Runtime Environment (Vinoski, 2005; Binildas,

2008; Rosenauer, 2008; Kumar et al, 2010; Schmutz et al, 2010)
67
Dari Gambar 2.11 dapat dilihat bahwa terdapat tiga komponen dalam JBI
Runtime Environment yang terdiri dari Normalized Message Router (NMR),
Binding Component (BC) dan Service Engine (SE) dengan fungsi masing-
masing komponen sebagai berikut (Vinoski, 2005; Binildas, 2008, Kumar et al,
2010, Schmutz et al, 2010):
Normalized Message Router berfungsi membawa pesan dari klien dan me-
routing-kan pesan ke SE yang sesuai untuk pemrosesan dan melewatkan
normalized message (WSDL) diantara komponen JBI.
BPEL Service Engine melakukan orkestrasi proses bisnis dengan WS-BPEL
2.0.
XSLT Service Engine berfungsi menjalankan transformasi dokumen XML
dari satu format ke format lain menggunakan XSL stylesheets dan
transformasi untuk dideploy sebagai Web service yang dapat digunakan oleh
klien eksternal.
SQL Service Engine berfungsi melakukan eksekusi SQL Data Definition
Language, SQL Data Manipulation Language dan stored procedures dari
sebuah database.
IEP Service Engine berfungsi memebaca data dari sebuah sumber input dan
kemudian memproses ke dalam format yang dapat digunakan untuk berbagai
tujuan seperti pelaporan atau informasi business intelegent.
Java EE Service Engine berperan sebagai jembatan antara container JBI
yang memungkinkan Java EE Web service dikonsumsi dari dalam
komponen JBI.
68
File Binding Component menyediakan mekanisme komunikasi untuk

komponen JBI untuk berinteraksi dengan sistem file. File Binding
Component dapat bertindak sebagai provider dengan melakukan
pengecekan untuk file baru yang akan diproses, atau sebagai konsumer
melalui outputting file untuk proses lain atau komponen lain.
SMTP Binding Component menyediakan service email ke JBI Server dan
bertindak sebagai provider dengan menerima pesan SMTP atau bertindak
sebagai konsumer dengan mengirimkan email SMTP ke alamat email
eksternal.
FTP Binding Component menyediakan service transport FTP ke container
JBI yang memungkinkan pesan diterima dan dikirim melalui protokol FTP.
HTTP Binding Component memungkinkan pesan JBI dikirim dan diterima
menggunakan SOAP melalui HTTP dan HTTPS. Komponen mendukung
RPC Literal, RPC Encoded, dan Document Literal encoding schemes.
JDBC Binding Component untuk berinteraksi dengan database (lebih
terbatas dibanding SQL Service Engine)
JMS Binding Component memungkinkan container JBI untuk
berkomunikasi dengan JMS message queues dan topics. Komponen dapat
bertindak sebagai penyedia atau pemakai dari pesan JMS.
2.6 Instalasi GlassFish ESB

Dalam proyek ini, sudah disediakan JDK 6 update 21 dan software
Glassfish ESB. Bagi yang menginginkan untuk mendapatkan langsung dari
69
sumbernya, dapat melakukan download di alamat :

https://netbeans.org/community/releases/old.html atau di alamat :
http://www.open-esb.net/index.php?option=com_content&view=article&id
=113& Itemid=583
Lakukan instalasi JDK terlebih dahulu sebelum menginstal GlassFish
ESB, dengan mengklik dua kali pada file exe dari JDK6, kemudian ikuti
perintah-perintahnya. Jika masih level pemula, maka ikuti default nya saja
selama instalasi JDK.
Glassfish ESB ini tidak lagi dikembangkan oleh Oracle tetapi dilanjutkan
oleh komunitas open source. Karena itu GlassFish ESB dapat didownload di
alamat : http://www.open-esb.net/ . Pada buku ini digunakan Glassfish ESB
V2.2)
70
Instalasi GlassFish ESB dilakukan dengan melakukan klik 2 kali pada file
Glasfish 2.2.exe, kemudian klik Run. Klik Next untuk melanjutkan. Statement
lisensi muncul. Respon lisensi dengan mengkklik Accept, kemudian klik Next
lagi untuk melanjutkan instalasi.
Prompt JDK dan NetBeans muncul. Perhatikan bahwa installer secara

otomatis menemukan JDK 6 Update 21 pada mesin. Jika tidak maka gunakan
tombol Browse dan temukan folder tempat instalasi JDK sebelumnya.
71
Terima default direktori Netbenas, kemudian klik Next untuk melanjutkan.

Prompt yang berkaitan dengan server aplikasi Glassfish akan tampak seperti
gambar berikut ini. Perhatikan apakah port 8080 sudah digunakan untuk server
lain. Jika tidak ingin mengganti port 8080 maka terima saja default.
72
Terima saja defaults, dan klik Next. Kemudian ringkasan konfigurasi akan
tampak. Gambar berikut ini merupakan ringkasan yang menunjukkan JBI Service
Engines dan Binding Components yang terdistribusi dengan GlassFish ESB.
73
Perhatikan progress bar untuk melihat ketika instalasi telah lengkap. Saat
instalasi selesai maka akan terlihat gambar berikut. Progress bar instalasi akan
memakan waktu 8-10 menit untuk instalasi yang lengkap.
74
Klik Finish dan dengan demikian proses instalasi telah lengkap. Halaman
registrasi akan tampak di browser dan menanyakan registrasi Glassfish ESB.
Jika melakukan register, maka ada keuntungan menjadi anggota komunitas dan
menerima update penting tentang perkembangan teknologi ini.
2.7 Memulai Glassfish ESB

Start GlassFish ESB dengan menggunakan Start / AllPrograms /
GlassFish ESB pada menu. {Start dapat dilakukan juga dengan menjalankan
file start_netbeans.bat pada direktori C:\GlassFishESB.}
Setelah NetBeans start, dan jika ada koneksi internet, maka software akan
melakukan pengecekan update yang tersedia. Akan tampak pesan seperti
75
gambar berikut.
Ketika pesan tampak, klik pada pesan pop-up dan ikuti langkah untuk
melakukan update Netbeans. Lihat daftar update seperti yang terlihat yang dapat
didownload. Jika tidak terlihat daftar plug- ins, ini menunjukkan bahwa NetBeans
sudah up-to-date.
76
Jika pesan pop-up yang menunjukkan update tidak terlihat maka gunakan
pilihan menu Help / Check for Updates untuk memulai pengecekan update.
Setelah instalasi selesai, maka lihat panel Services dan start aplikasi server
Glassfish dengan melakukan klik kana pada node GlassFish V2 dibawah Servers
dan pilih Start .
Setelah Glassfish start, cek JBI Service Engines dan Binding Components
yang terpaket dengan GlassFish ESB dengan melakukan ekspansi hirarki
GlassFish V2:
77
SOA middleware yang ada pada GlassFish ESB didasarkan pada standard
Java Business Integration 1.0 (JSR 208). JBI menetapkan model kontainer untuk
integrasi. Ada dua jenis komponen pada JBI yaitu Service Engines dan Binding
Components. Keduanya mini-containers.
78
Service Engines (SE) bertindak sebagai business logic dan Binding

Components (BC) sebagai proxy untuk berkomunikasi dengan dunia luar. Ikatan
longgar (loose coupling) antara SE dan BC disediakan oleh sebuah in- memory
bus yang disebut Normalized Message Router (NMR)
Sangat menarik mengetahui cara melihat status dan properti komponen
JBI. Sebuah komponen mempunyai tiga status yaitu shutdown, started atau
stopped. {JBI component mempunyai siklus hidup:
Shutdown Tidak tersedia
Started Siap menerima pesan:
Stopped Sementara tidak tersedia, tetapi dapat start lagi dengan

perintah start secara cepat:
Klik kanan pada node sun-bpel-engine dan pilih Properties:
79
Lihat properties pada komponennya. Selama troubleshooting, akan

membantu mengetahi soal property ini sehingga debugging dapat diketahui
lebih rinci.
80
Setelah GlassFish ESB diinstall dengan NetBeans IDE, jika mempunyai

akses web, maka dapat dilakukan pendalaman dengan melihat link tutorial
Getting Started pada : http://www.netbeans.org/kb/index.html. Jika GlassFish
ESB belum start, maka dapat melalui Windows desktop menggunakan opsi
menu Start / All Programs / GlassFish ESB.
81
Link Getting Started akan tampak diatas. Setelah memahami lingkungan

lingkungan Netbeans maka dapat pindah dengan memulai proyek.
82
BAB 6
Contoh 4: Pemrograman SOA
Sebagai pembuktian integrasi berbasis SOA maka akan dibangun

aplikasi bisnis fiktif berupa kredit perbankan yang dinamakan Aplikasi
Persetujuan Kredit BPR UKSW. Aplikasi ini mengacu dari tutorial yang
terdapat di http://www.open-esb.net, dan telah dilakukan modifikasi dan
pengkodingan ulang (Barrett, 2009).. Aplikasi ini merupakan proof of concept
dari integrasi berbasis SOA. Teknologi yang digunakan dalam membangun
aplikasi integrasi berbasis SOA ini adalah GlassFish ESB, dengan menggunakan
IDE Netbeans 6.7.1.
GlassFish ESB merupakan software open source yang dibangun diatas
arsitektur Java Business Integration (JBI) mengikuti spesifikasi JSR 208.
GlassFish ESB merupakan basis teknologi baru yang diproduksi oleh Sun
Microsystem yang sekarang telah diakuisisi oleh Oracle. Glassfish ESB
merupakan bagian dari fitur Open ESB. Tujuan dari buku ini adalah
menyediakan pengantar yang lengkap dalam memanfaatkan fitur JBI
menggunakan Glassfish ESB. Topik-topik yang akan dibahas mencakup :
Web service yang dibangun menggunakan modul EJB dan aplikasi web.
Pengembangan skema XML dan WSDL
Orkestrasi BPEL dari web service menggunakan BPEL Service Engine
83
Deployment dan pengujian aplikasi komposit

Perancangan interface usser dengan web
Penyimpanan data dalam database melalui JDBC Binding Component
6.1 Skenario
Pada Aplikasi Persetujuan Kredit BPR UKSW ini, pemilik
mempunyai ide menggunakan SOA sebagai strategi TI. Pemilik
menginginkan pegawainya memahami SOA dengan menggunakan web
service dan aplikasi komposit. Karena itu akan dibuat aplikasi sebagai
proyek proof of concept dari penerapan SOA. Aplikasi ini terbagi dalam 5
modul (Lihat gambar berikut ini) yang terdiri dari :
1. Penetapan Bunga Pinjaman: Penetapan bunga pinjaman akan
diimplementasikan menggunakan web service, yang dibangun dari EJB
stateless yang menyediakan lojik untuk menetapkan bunga pinjaman.
2. Menghitung Pembayaran Pinjaman.: Web service lainnya akan
mengambil input jumlah pinjaman, tingat bunga dan periode
dan menghitung jumlah cicilan bulanan. Rumus menghitung pembayaran
menggunakan rumus umum dalam keuangan. Web service akan
mengimplementasikan algoritma dari rumus tersebut. Akan digunakan
aplikasi web untuk menyediakan lojik penghitungan pembayaran..
3. Proses Peminjaman: Proses Business Process Execution Language (BPEL)
digunakan untuk melakukan orkestrasi (orchestration) dengan menggunakan
dua web service yang telah dibuat sebelumnya. BPEL akan menerima
84
parameter input jenisPinjaman, jumlah, dan periode serta

melakukan serangkaian eksekusi dua web service tersebut untuk
menghasilkan output berupa pembayaranPinjamanBulanan. Pada
saat runtime, BPEL Service Engine akan menyediakan dukungan untuk
melakukan eksekusi WS-BPEL 2.0. Aplikasi ini kemudian akan diperluas
dengan memanfaatkan JDBC Binding Component yang akan menyimpan
pinjaman ke sebuah database.
4. User Interface: Untuk melakukan pengujian proses BPEL, akan dibangun
sebuah user interface berbasis web browser menggunakan Visual
JavaServerPages sehingga dapat berinteraksi dengan proses peminjaman
melalui interface web service.
5. Database : Untuk melakukan penyimpanan data peminjaman ke sebuah
database menggunakan komponen JDBC Binding Component.
85
Call lewat
Form Submit Interface Web Java DB
pd hlm web 4 Kuota Pinjaman
Hlm Web JSP/JSF
5
Call lewat
Aplikasi Komposit Kuota Pinjaman hlm test
3 klien web
Proses BPEL
Call lewat Call lewat

hlm test 1 WS Penetapan WS Hitung Cicilan 2 hlm test
klien web Bunga Pinjaman klien web
WS berbasis EJB WS berbasis Servlet
6.2 Web service untuk Menetapkan Bunga Pinjaman

Pada proyek ini, akan dibuat modul EJB yang berisi lojik untuk
menetapkan tingkat bunga untuk dua jenis pinjaman (Mobil dan Rumah).
Seperti yang telah dijelaskan pada Skenario, lojik implementasi dibuat secara
sederhana saja, yang dapat digunakan untuk pembuktian saja. Selanjutnya,
organisasi BPR UKSW merencanakan melakukan plug-in sebuah mesin aturan
yang canggih pada implementasi nanti, sehingga implementasi dapat diubah,
tetapi interfacenya tidak berubah. Modul EJB akan bertindak sebagai endpoint
web service yang menerima input SOAP dan menghantar output SOAP.
Selanjutnya akan dibangun fungsionalitas untuk menghitung pembayaran
pinjaman dengan menggunakan endpoint web service berbasis servlet.
Langkah ini sangat mirip dengan pendefinisian implementasi java untuk web
service, dengan menyerahkan pada IDE Netbeans untuk menciptakan XSD,
WSDL dan dokumen XML.
86
Pertama kali lakukan start GlassFish ESB, dengan melakukan : Start / All
Programs / GlassFish ESB pada opsi menu. Sekarang akan dimulai proyek
pertama:
Pilih File / New Project from the menu bar, maka wizard windows New
Project akan tampak.
Pilih Java EE dari category dan EJB Module
Untuk jenis proyek. Kemudian klik Next.
Untuk Project Name, masukkan PenetapanBungaPinjaman. Untuk
Project Location, masukkan: C:\LatihanSOA. Jika direktori belum ada,
maka akan secara otomatis dibuatkan. Klik Next.
Terima sisanya sebagai defaults dengan melakukan klik Finish. Proyek
PenetapanBungaPinjaman akan tampak.
Praktek terbaik dalam membuat web service adalah dengan

mendefinisikan interfacenya sebelum membuat implementasinya. Sehingga,
pertama akan dibuat dokumen XML Schema Definition (XSD) yang
87
mendefinisikan jenis data (data types) yang digunakan dalam pesan (messages).
Kemudian membangun dokumen Web service Description Language (WSDL)
yang diimport dari XSD dan mendefinisikan penuh Web service nya. Ingat
bahwa ini merupakan penyimpangan dari best practices. Disini langsung
dibuat implementasi Web service tanpa membuat interfacenya dulu.
Selanjutnya akan diikuti jalur dalam implementasi yang sudah
disediakan, dan membiarkan Netbeans menciptakan interface (XSD dan
WSDL). Alasan melakukan shortcut ini adalah karena web service akan
diperoleh secara cepat dan dapat dilakukan build and testing.
Pada node PenetapanBungaPinjaman. pada panel Projects
lakukan klik kanan, dan pilih New / Web service. Windows wizard New Web
service akan tampak. Untuk Web service Name, masukkan
ServicePenetapanBunga , dan untuk package, masukkan bunga
Kemudian klik Finish. Web service ini dibuat dari awal, dan bukan dari EJB
yang sudah ada.
Web service yang baru telah ditambahkan ke proyek dan view Source
akan tampak :
88
Pilih kontrol Design untuk berpindah dari mode Source ke mode Design.
Kanvas Design akan tampak:
Klik pada tombol Add Operation untuk membuat sebuah operasi untuk
89
implementasi web service. Windows wizard Add Operation akan muncul.
Untuk Name, ketik getBunga. Untuk Return Type, ketik double.

Tombol Browse dapat diguankan untuk memilih jenis objek, tetapi tidak
membantu jika menggunakan tipe data primitif.
Pada tab Parameters, gunakan tombol Add untuk menetapkan argumen
input dengan Name ketik jenisPinjaman dan Type ketik java.lang.String
(default):
Klik OK untuk mengakhiri pembuatan interface operasi getBunga.

Ingat bahwa operasi getBunga terlihat pada view Design:
90
Ekspansi hirarki Web service pada panel Projects untuk melihat bahwa
operasi getBunga telah ditambahkan.
Klik pada kontrol Source untuk berpindah ke view kode Java dan
membuat implementasi dari metode getBunga seperti gambar berikut
ini :
91
Untuk memudahkan copy dan paste, berikut ini adalah kode untuk
metode getBunga():
if (jenisPinjaman.equals("RUMAH")) return 7.0;
else if (jenisPinjaman.equals("MOBIL")) return 10.0;
else return 15.0;
Gunakan Alt-Shift-F sebagai short-cut untuk melakukan reformat kode.

Alt-Shift-F merupakan short-cut untuk opsi menu Source / Format.
Save All seluruh pekerjaan.
Lakukan build proyek, dengan melakukan klik kanan node
92
PenetapanBungaPinjaman pada panel Projects dan pilih opsi Clean and

Build. Jika tidak ada masalah maka akan terlihat pesan BUILD
SUCCESSFUL pada panel Output.
Lakukan deploy modul EJB ke server aplikasi GlassFish dengan
melakukan klik-kanan pada node PenetapanBungaPinjaman pada panel
Projects dan memilih opsi Deploy. Akan terlihat pesan BUILD SUCCESSFUL
jika modul EJB telah berhasil dideploy.
Setelah deployment lengkap, cek untuk melihat apakah modul telah
berhasil dideploy dengan melakukan klik pada tab Services dan melakukan
ekspansi hirarki seperti gambar berikut ini:
93
Jika modul tidak tampak, perlu dilakukkan klik-kanan pada EJB Modules
dan pilih Refresh. Panel ServicePenetapanBunga.java dapat ditutup
dengan klik kanan pada tab X.
6.2.1 Eksplorasi WSDL dan XSD
WSDL (Web service Description Language) merupakan dokumen XML

yang mendeskripsikan interface untuk Web service. Jika service consumer
mempunyai akses ke service provider, maka ia mempunyai akses untuk
berkomunikasi dengan Web service.
Interface menyembunyikan rincian implementasi yang memungkinkan
provider untuk misalnya merubah implementasi dari modul EJB ke aplikasi
web, sepanjang interfacenya sama, klien tidak akan memperhatikan
perbedaannya.
Untuk melakukan eksplorasi WSDL ini maka selanjutnya, lakukan klik
pada tab Projects sehingga dapat terlihat hirarki proyek1.
Temukan ServicePenetapanBunga dibawah node Web service.
Lakukan klik-kanan dan pilih opsi Properties untuk mendisplay window
Properties. Pada bagian bawah, tercatat bahwa WSDL telah dibuatkan dan
tersedia pada sebuah URL:
94
Lakukan drag pada URL tersebut dan gunakan Ctrl-C untuk mengkopi
ke clipboard. Klik pada tombol Close.
Pada web browser, lakukan, paste dari URL yang baru saja dikopi.
Makan akan terlihat WSDL yang telahdibuat. Ini menjelaskan interface untuk
service baru. Namun beberapa informasi kunci disimpan di suatu tempat dan
ini hanya referensi saja.
Source lainnya berupa dokumen skema XML direferensi pada bagian
<types> dibawah ini:
Lakukan kopi URL dari bagian <types> ke dalam web browser baru
untuk melihat struktur data input dan output yang terlibat dalam definisi
interface web srvices. Ini adalah URL yang harus di-paste.
95
http://localhost:8080/ServicePenetapanBungaService/ServicePenetapanBung
a?xsd=1
Maka akan terlihat XSD berikut ini.
Tampak rincian data definition yang menunjukkan Web service

mengharapkan akan menerima struktur data getBunga yang berisi
jenisPinjaman string dan menjawab dengan struktur data
getBungaResponse yang berisi atribut yang dinamakan return dengan jenis
data double.
6.2.2 Testing Web service

Akhirnya, lakukan pengujian web service. Klik kanan pada node
ServicePenetapanBunga dan pilih Test Web service. Web browser akan
tampak. Perhatikan bahwa pada bagian atas halaman test, akan ditemukan link
WSDL File yang menyediakan cara mudah untuk menampilkan WSDL.
96
Ketikkan MOBIL dan tekan tombol getBunga:
Pastikan melakukan klik pada tombol getBunga dan bukan tombol

Enter. Pastikan pula memasukkan HURUF BESAR.
Web browser akan ditampilkan lagi dan terlihat SOAP request akan
terkirim dan respon akan diterima. Berdasarkan pada kode Java dari method
getBunga, diharapkan bunga pinjaman adalah 10.0:
Lakukan pengujian tambahan dengan jenis pinjaman selain RUMAH atau

MOBIL, misalnya SEPEDA. Jika selain MOBIL atau RUMAH, maka nilai
97
yang diharapkan adalah 15.0.
6.3 Menghitung Pembayaran Pinjaman

Pada proyek yang lalu, telah dibuat modul EJB yang digunakan untuk
menetapkan tingkat bunga pinjaman. Method getBunga ditampilkan sebagai
operasi web service. Pada proyek2 ini, akan dibangun fungsionalitas untuk
menghitung pembayaran pinjaman. Sekedar variasi, maka penghitungan
pembayaran pinjaman ini akan diimplementasikan sebagai web service
endpoint berbasis servlet. Langkah ini sangat mirip dengan pendefinisian
implementasi java untuk web service, dengan menyerahkan pada IDE Netbeans
untuk menciptakan XSD, WSDL dan dokumen XML.
Pilih File / New Project dari menu bar. Wizard windows New Project
akan tampak.
Pilih Java Web sebagai category dan Web Application untuk project
type. Kemudian klik Next.
Untuk Project Name, ketik HitungCicilanPinjaman dan simpan
dalam Project Location: C:\latihanSOA. Klik Next.
Terima semua default dengan klik Finish untuk mengakhiri dialog
wizard. Proyek HitungCicilanPinjaman project tampak di panel
Projects. Juga akan terlihat halaman index.jsp. Klik Close.
Pada node HitungCicilanPinjaman, klik-kanan dan pilih New /
Web service. Wizard window New Web service akan tampak.
Untuk Web service Name, ketik ServiceHitungCicilan
98
Untuk package, ketik cicilan dan klik Finish. Akan terlihat web
service baru ditambahkan pada panel Projects.
Seperti yang telah dikerjakan di proyek1, klik pada ontrol Design untuk
ke mode Design dan klik tombol Add Operation untuk membuat sebuah method
baru. Wizard window Add Operation akan tampak.
Untuk Name, ketik: getCicilan
Untuk Return Type, ketik: double
Pada tab Parameters, gunakan tombol Add tiga kali untuk
mengetikkan argumen input:
tingkatBunga (double)
jumlah (double)
periode (int)
Gunakan box drop-down list pada kolom Type untuk memilih type data
double dan int.
Klik OK untuk mengakhiri pembuatan interface untuk operasi
getCicilan. Klik pada kontrol Source untuk pindah ke mode Source. Maka
kerangka implementasi telah selesai dibuat.
Implementasikan method getCicilan seperti gambar dibawah ini.
99
Berikut ini kode yang dapat dicopy-paste.

double bunga = (tingkatBunga / 12) / 100;
int bulan = periode * 12;
return jumlah * (bunga * Math.pow(1 + bunga, bulan) /
(Math.pow(1 + bunga, bulan) - 1));
Gunakan shortcut Alt-Shift-F untuk penataan kode.

Klik Save All.
Lakukan compile Web service, dengan klik-kanan node
HitungCicilanPinjaman dan memilih opsi Clean and Build option. Jika
tidak ada error maka akan terlihat BUILD SUCCESSFUL.
Perhatikan window Output window untuk melihat feedback. Jika hasil
Clean and Build ada pesan error message ini menunjukkan bahwa direktori tidak
dapat dihapus, gunakan opsi Build saja (tidak dengan Clean).
Lakukan deploy modul web ke server aplikasi GlassFish dengan klik-
kanan node HitungCicilanPinjaman dan memilih opsi Deploy. Akan
terlihat pesan BUILD SUCCESSFUL.
100
6.3.1 Eksplorasi WSDL dan XSD

Seperti yang telah dikerjakan di proyek1, akan dieksplorasi dokumen
WSDL dan XSD yang secara otomatis dibuat oleh NetBeans.
Klik pada tab Projects dan temukan ServiceHitungCicilan
dibawah node Web service dalam proyek HitungCicilanPinjaman.
Klik-kanan dan pilih Properties.
Pada bagian bawah window, tercatat WSDL yang tersedia di URL:
Drag URL dan lakukan CtrlC untuk mengkopi ke clipboard. Pilih

tombol Close pada window Properties.
Pada web browser, lakukan paste URL. Akan terlihat WSDL yang telah
dibuat. WSDL ini mendeskripsikan interface dari service.
101
Disini ada dua jenis pesan yang dibuat berdasarkan dua elemen pada XSD.
Port Type menyediakan definisi interface yang menunjukkan bahwa operasi
getCicilan tersedia, yang mengharapkan pesan input dan mengirimkan pesan
output berdasarkan jenis pesan diatas. Untuk bagian konkrit dari WSDL, kaitkan
operasi ke SOAP sebagai sebuah protocol.
102
Seperti yang telah dikerjakan pada proyek terakhir, temukan baris yang
melakukan import skema XML untuk mendefinisikan pesan input dan output:
Lakukan kopi URL ini ke web browser lain untuk melihat definisi jenis
data web service sisanya.
Copy:
http://localhost:8080/HitungCicilanPinjaman/ServiceHitungCicilanService?xsd
=1
Ada dua complex types yang didefinisikan. Dan ini akan menjadi dasar
untuk dua elemen. Complex type pertama mendefinisikan inputs
(tingatBunga, jumlah dan periode). Yang kedua mendefinisikan nilai
return dengan tipe double.
103
6.3.2 Testing Web service

Lakukan pengujian Web service. Klik-kanan pada node
ServiceHitungCicilan pada panel Projects dan pilih opsi Test Web
service. Web browser akan tampak.
Ketikkan input berikut :
tingkatBunga: 10.0
jumlah : 100000.00
periode: 15
Klik tombol getCicilan. Terlihat bahwa data type adalah double,

double dan int. Lihat acuan pada type complex getCicilan dallam XSD
untuk melihat urutan parameter.
104
Akan terlihat SOAP Response:
Klik pada tab Services sehingga terlihat aplikasi web

(HitungCicilanPinjaman) yang telah berhasil dideploy:
105
Klik Close panel ServiceHitungCicilan.java dan panel editor lain

sebelum pindah ke proyek lain dimana akan dibuat proses BPEL yang
digunakan untuk orkestrasi ke dua web service tersebut.
6.4 Orkestrasi dengan BPEL

Pada ke dua proyek pertama, telah dibangun web service untuk menangani
langkah-langkah dalam proses pinjaman. Web service pertama,
PenetapanBungaPinjaman, merupakan modul EJB, yang mempunyai
argumen jenisPinjaman (seperti RUMAH atau MOBIL) dan mengirim
tingkat bunga sebagai output. Web service kedua,
HitungCicilanPinjaman, merupakan aplikasi web (servlet) yang
mempunyai argumen tingkatBunga, jumlah dan periode. Web service
ini menghasilkan perhitungan jumlah pembayaran bulanan.
Ke dua web service ini akan digunakan dalam sebuah rangkaian. Dengan
kata lain, kedua web service ini akan diorkestrasi. Salah satu komponen SOA
adalah BPEL yang digunakan untuk orkestrasi web service. Sehingga akan
dilakukan build modul BPEL yang mengeksekusi dua web service dalam
orkestrasi.
6.4.1 Membuat Proyek BPEL
Menurut kamus Merriam-Webster, Arsitektur adalah cara kompopnen

komputer atau sistem komputer diorganisasikan dan diintegrasikan. Berdasar
definisi arsitektur ini, dapat dikatakan bahwa SOA adalah cara atau jenis
106
pembuatan dan atau penggunaan ulang service-service yang loosely-couple dan

interoperable yang dapat diorkestrasi bersama untuk tujuan tertentu. Walaupun
SOA tidak berimplikasi pada teknologi tertentu, bentuk paling terkenal untuk
service adalah XML berbasis web service yang dideskripsikan oleh WSDL.
Wahana untuk orkestrasi adalah BPEL (Business Process Execution
Language).
Sebelum menjalankan proyek BPEL ini, direkomendasikan untuk
menutup semua tab window yang masih tampak dari dua proyek sebelumnya
sehingga dapat mulai baru. Klik saja X pada tab.
Pilih File / New Project. Maka Project baru akan tampak di window.
Pilih SOA sebagai category dan BPEL Module untuk project type.
Kemudian, klik Next.
Untuk Project Name, ketikkan KuotaPinjaman dan klik Finish.
Project KuotaPinjaman akan tampak dalam panel Projects:
Dapat dilihat bahwa tidak ada file dalam folder Process Files.
Klik tab Files untuk melihat view systems dari project:
107
BPEL adalah Business Processing Execution Language. Bersama Web

service, tujuannya adalah untuk melakukan orkestrasi sekumpulan service
yang menunjukkan tugas yang diperlukan untuk memenuhi tujuan bisnis.
BPEL merupakan bahasa yang lebih tinggi dari Java, yang lebih dekat
kepada kebijakan bisnis. BPEL merupakan bahasa berbasis XML dan
framework yang sangat restrictive yang melakukan operasi yang sangat
membantu yang memandu transisi status diantara sekumpulan services yang
loosely-couple.
Walau bekerja dengan objek yang mempunyai method dan atribut,
programer BPEL memanfaatkan konstruksi seperti :
<receive>: blocks menunggu pesan yang datang
<reply>: mengirim jawaban untuk pesan yang diterima lewat
receive
<invoke>: memulai satu jalur interaksi request- response dengan portType
108
yang disediakan oleh partner

partner: sebuah service yang berinteraksi dengan proses BPEL
portType: sekumpulan operasi yang servicenya dapat dieksekusi.
<assign>: memetakan nilai ke variables yang digunakan dalam service
yang dimanfaatkan oleh proses BPEL
Konstruksi dalam angle brackets (<>) adalah jenis statement BPEL. Jika
palette tidak tampak, gunakan opsi menu bar Windows / Palette untuk
menampilkannya.
Kembali ke panel Projects dan klik-kanan KuotaPinjaman dan pilih New
/ BPEL Process. Untuk File Name, ketik ProsesKuotaPinjaman Klik Finish.
BPEL Editor tampak pada panel kanan:
109
Perhatikan bahwa kerangka proses terlihat dengan elemen Process Start dan
Process End.
Klik pada kontrol Source pada bagian atas panel editor untuk melihat
statemen BPEL yang telah dihasilkan secara otomatis.:
Klik kontrol Design control untuk melihat view diagram lagi.

Pada mode Design akan terlihat panel palette BPEL tampak pada editor
proses sebelah kanan:
110
Proses bisnis BPEL dimulai dengan sebuah elemen receive dan diakhiri
dengan elemen reply. Taruh kedua elemen tersebut ditempatnya.
Dari panel Palette, lakukan drag Receive ke dalam kanvas design dan
drop pada lingkaran oranye setelah Process Start:
Kemudian icon receive dengan label Receive1 ditambahkan ke

kanvas.
Klik-double pada label Receive1 dan beri nama baru menjadi
StartKuotaPinjaman
Dimulai dengan <receive> dan berakhir dengan <reply> yang merupakan
standard pola pertukaran pesan request/reply.
Dapat berpindah dari view Source dari proses untuk melihat statement
<receive> yang telah ditambahkan. <receive> membawa data ke dalam proses
bisnis yang dapat digunakan pada langkah berikutnya.
Selanjutnya, tambahkan elemen reply dengan melakukan drag ikon Reply
icon dari palette ke kanvas. Drop ke dot oranye dibawah node receive
StartKuotaPinjaman:
111
Kemudian ikon reply dengan label Reply1 akan ditambahkan ke kanvas.

Klik-double pada label Reply1 dan beri nama baru menjadi
ReturnKuotaPinjaman.
Pada node reply labelnya diganti menjadi ReturnKuotaPinjaman

yang tidak cocok dengan StartKuotaPinjaman. Tapi hal ini tidak menjadi
masalah. Label ini murni hanya penjelasan saja. <reply> memungkinkan untuk
mengembalikan results ke pemanggil.
112
Sekarang akan terlihat dua statement BPEL pada view Source:

<receive name="StartKuotaPinjaman" createInstance ="yes"/>
<reply name="ReturnKuotaPinjaman"/>
6.4.2 Membangun Skema XML
Exposisi proses bisnis mirip dengan eksposisi Web service. Proses bisnis
perlu di bungkus seperti web service sehingga dapat dipanggil seperti
ServicePenetapanBunga dan ServiceHitungCicilan. Untuk
kedua Web service, telah ada dokumen WSDL yang merupakan interfaces.
NetBeans akan membuat WSDL (dan XSD). Namun pada proyek ini akan
dibuat WSDL dan XSD secara manual.
XSD mendefinisikan simple dan complex types. Complex types
memungkinkan adanya isi elemen dan atribut, sedangkan simple types tidak
berisi isi elemen dan menyimpan atribut.
Sebelum mendefinisikan langkah-langkah di dalam proses bisnis, akan
ditetapkan input proses dan outputnya. Maka akan didefinisikan skema XML
untuk menetapkan jenis data (data types). Kemudian akan dibangun WSDL
diatas skema XML untuk mendefinisikan interface publik.
Pada node KuotaPinjaman, klik-kanan dan pilih New / XML Schema. Jika
opsi ini tidak terlihat, gunakan menu New / Other / XML untuk menemukan XML
Schema. Klik Next.
Untuk File Name, ketik SkemaKuotaPinjaman dan pilih Finish. File
113
SkemaKuotaPinjaman.xsd akan ditambahkan pada proyek dan tampak

editor di sebelah kanan.
Masuk ke mode Design dengan klik pada kontrol Design:
Definisikan dua Complex Types, satu untuk input dan lainnya untuk
output.
Klik-kanan panel design Complex Types dan pilih Add / Complex Type:
Node newComplexType akan tampak dibawah.

Klik-double node baru dan beri nama baru InputKuotaPinjaman.
Dengan kursor di atas InputKuotaPinjaman, klik-kanan dan pilih
114
Add / Element:
Node newElement akan tampak. Klik-double dan beri nama baru

jenisPinjaman. Dengan tetap di atas node jenisPinjaman, temukan
Properties dan lihat property Definition:
115
Klik ikon ellipsis (lihat gambar) dan atur property Definition property
untuk jenisPinjaman menjadi Built-In Types / string.
Tambahkan elemen di bawah InputKuotaPinjaman dan atur properti
Definition:
jumlah (Built-In Types / double)
periode (Built-In Types / int)
Maka definisi complex type InputKuotaPinjaman telah lengkap:
Sekarang akan didefinisikan sisi output dari interface publik proses BPEL.
Lakukan hal yang sama dalam membuat complex type
OutputKuotaPinjaman.
Untuk membuat complex type, klik-kanan pada area Complex Types dan
116
pilih Add / Complex Type. Ganti nama dengan klik-double.

Tambahkan dua elemen:
deskripsi (Built-In Types / string)
cicilanBulanan (Built-In Types / double)
Untuk menambah elemen, klik kanan pada OutputKuotaPinjaman
complex type dan pilih Add / Element.
Maka akan terlihat file XSD seperti gambar dibawah ini:
117
Untuk menetapkan data types, klik pada elemen dan temukan Definition
property. Gunakan Built-In Types as yang sesuai seperti gambar. Jika ingin tahu,
pindah ke view Source untuk melihat XML yang telah dibuat Netbeans.
Lakukan penyimpanan dengan klik Save All.
Sekarang akan ditambahkan dua elemen top level skema untuk
menyajikan jenis data request yang datang dan response yang dikirim. Kedua
elemen ini didasarkan pda complex types yang baru saja dibuat.
Pada mode Design, klik-kanan Elements pada atas panel design.
Kemudian pilih Add / Element:
Sebuah node newElement akan tampak.

Klik-double pada node baru dan beri nama baru menjadi
RequestKuotaPinjaman
Untuk property Definition, klik ke Complex Types /
InputKuotaPinjaman:
118
Klik-kanan area Elements lagi dan pilih node Add / Element. Node
newElement lain akan tampak.
Klik-double pada node baru dan beri nama baru menjadi
ResponKuotaPinjaman
Untuk property Definition, klik Complex Types /
OutputKuotaPinjaman.
Simpan dengan melakukan klik Save All.
Gambar dibawah ini menunjukkan SkemaKuotaPinjaman secara
lengkap.
119
Dokumen XSD ini mendefinisikan data types yang akan melewatkan ke

dan mengirim dari proses bisnis. Dokumen XSD ini akan diimport ke dokumen
WSDL yang akan dibuat, sehingga web service mempunyai definisi data yang
diperlukan.
120
Pindah ke mode Source untuk melihat dokumen XSD:
Untuk mengecek error pada XSD, klik pada kontrol Schema untuk masuk
ke mode Schema. Kemudian temukan kontrol Validate XML dan klik. Lihat
apakah ada error pada panel Output.
6.4.3 Membangun Dokumen WSDL

Dengan XSD ini maka akan didefinisikan jenis data WSDL.
Selanjutnya akan dilakukan build pada definisi interface WSDL untuk
BPEL Process.
Klik-kanan pada node proyek KuotaPinjaman dan pilih New /
WSDL Document. Window wizard New WSDL Document akan tampak.
Gunakan Document / Literal yang paling sering digunakan untuk
121
kombinasi jenis pesan pada web service.

Jika menggunakan Document, berarti menyatakan bahwa body dari
dokumen SOAP akan berisi satu atau lebih element anak (part).
Jika menggunakan RPC sebagai jenis pesan, berarti menunjukkan bahwa
body dokumen berisi elemen yang menyediakan nama method yang diinvoke.
Elemen in mempunyai sebuah child element untuk mendapatkan parameter
yang dilewatkan pada saat pemanggilan method
Dalam memilih format serialisasi, ada dua pilihan: SOAP Encoding dan
Literal. Jika memilih SOAP Encoding, berarti mengadopsi rule dari spesifikasi
SOAP 1.1 yang berisi bagaimana struktur data diserialisasi sebelum ditransmisi.
Format serialisasi ini biasanya diasosiasikan dengan jenis RPC message. Jika
memilih Literal, data pada message body diserialisasi menggunakan XML
schema. Dengan kata lain, format dikontrol, dan tidak mengikuti default pada
rule spesifikasi SOAP.
Untuk File Name, ketik WSDLKuotaPinjaman
Pilih Concrete WSDL Document yang menunjukkan bawha akan
ditetapkan protokol dan alamat endpoint fisik.
Tetap pilih SOAP pada Binding, tetapi pada menu drop-down Type pilih
Document Literal. Klik Next.
122
Pada bagian Input, beri nama part1 menjadi InputPart

Untuk nilai Element atau Type untuk InputPart, klik pada ikon ... dan pilih
elemen RequestKuotaPinjaman (bukan complex type):
123
Klik OK untuk menyimpan record jenis pilihan.

Pada bagian Output, ganti nama part1 menjadi OutputPart. Untuk
Element atau Type, pilih elemen ResponKuotaPinjaman (bukan complex
type).
124
Klik Next. Wizard Concrete Configuration akan dieksekusi:
125
Klik Finish untuk menerima semua default. WSDL baru akan tampak di
panel Projects dibawah hirarki KuotaPinjaman. Untuk menemukan kanvas
desain BPEL klik-double pada node ProsesKuotaPinjaman.bpel di
hirarki KuotaPinjaman pada tab Projects.
Sekarang telah ada interface WSDL untuk proses bisnis, sekarang kembali
ke kanvas design dari ProsesKuotaPinjaman.bpel dan gunakan definisi
interface untuk melakukan build BPEL Partner Link.
6.4.4 Menambah Partner Link

Temukan tab untuk panel proses BPEL dan klik untuk melihat proses.
Dari panel Projects, drag node WSDLKuotaPinjaman.wsdl ke sisi kiri
kanvas design BPEL seperti gambar dibawah ini:
126
Apa perbedaan antar drag pada sisi kiri dan kanan? Drag WSDL di area
kiri maupun kanan akan tetap dibuat Partner Link. Partner Link
merepresentasikan saluran melalui proses bisnis yang dapat berkomunikasi
dengan dunia luar melalui interface yang ditetapkan dalam WSDL. Dunia
luar disini adalah beberapa klien yang memanggil proses bisnis. Pada tutorial
ini klien akan berupa user interface yang dihasilkan dengan NetBeans.
Partner Link dalam model BPEL mempunyai atribut partnerRole. Ini
menunjukkan proses BPEL apakah atau tidak mengimplementasikan web service
yang dipanggil melalui channel (saluran)
Kembali ke sisi kiri atau kanan. Jika membuat Partner Link pada sisi kiri,
menunjukkan bahwa proses BPEL merupakan implementer dari web service
endpoint.
partnerRole berupa myRole menunjukkan bahwa proses BPEL
bertanggung jawab untuk implementasi. Jika Partner Link pada sisi kanan, maka
partnerRole akan mengidentifikasikan web service endpoint external yang akan
berinteraksi dengan menggunakan <invoke>.
Elemen receive dan reply perlu dikoneksikan dengan Partner Link channel
sehingga <receive> dapat diinvoke dan membawa data masuk dan <reply> dapat
mengirim resspon kembali ke klien.
Pada saat selesai melakukan drag dan drop, maka Partner Link akan
tampak di kanvas. Ganti nama dengan melakukan klik-double pada nama
default PartnerLink1 dengan mengetikkan: KuotaPinjamanPL
127
Klik node StartKuotaPinjaman pada kanvas design. Ikon edit

(pensil) tampak diatas node:
Klik ikon edit untuk menampakkan node receive window Property

Editor. Ketikkan fields seperti gambar dibawah ini. Klik tombol Create untuk
menetapkan Input Variable.
128
Untuk membuat Input Variable, klik saja tombol Create dan terima
semua default. Pilih tombol Ok.
Akan terlihat bahwa node receive StartKuotaPinjaman telah
dihubungkan ke partner.
Perhatikan bahwa elemen akan ditandai silang merah. Ini menunjukkan

bahwa model masih belum lengkap. Pindah ke view Source pada proses BPEL:
129
Akan terlihat bahwa statement <receive> BPEL telah dibuat secara

otomatis.
<receive name="StartKuotaPinjaman"
createInstance="yes" partnerLink="KuotaPinjamanPL"
operation="WSDLKuotaPinjamanOperation"
xmlns:tns="http://j2ee.netbeans.org/wsdl/KuotaPinjaman
/WSDLKuotaPinjaman"
portType="tns:WSDLKuotaPinjamanPortType"
variable="WSDLKuotaPinjamanOperationIn"/>
<reply name="ReturnKuotaPinjaman"/>
Pindah kembali ke mode Design.
130
Antara node reply dan interface WSDL perlu dihubungkan, dan lakukan
klik pada node reply ReturnKuotaPinjaman, lalu lihat ikon edit akan
tampak.
131
Klik ikon edit (pensil) untuk menampilkan window Property Editor. Isi
fields mengikuti gambar dibawah. Seperti pada Input Variable sebelumnya,
gunakan pula tombol Create untuk menetapkan Output Variable:
Pilih tombol Ok . Sekarang kanvas design proses BPEL akan terlihat

seperti gambar dibawah.
132
Simpan dengan klik Save All. Kedua node request dan reply sekarang
dihubungkan ke Partner Link yang mendefinisikan inputs dan outputs dari
proses bisnis.
Pindah ke view Source untuk melihat statemen <reply> telah dibuat
oleh NetBeans:
<reply name="ReturnKuotaPinjaman"
partnerLink="KuotaPinjamanPL"
operation="WSDLKuotaPinjamanOperation"
xmlns:tns="http://j2ee.netbeans.org/wsdl/KuotaPinjaman/WS
DLKuotaPinjaman" portType="tns:WSDLKuotaPinjamanPortType"
variable="WSDLKuotaPinjamanOperationOut"/>
133
Lakukan pengecekan untuk meyakinkan bahwa NetBeans telah

menghasilkan XML BPEL yang well-formed. Pilih ikon Validate XML pada
bagian atas panel kanvas.
Kemudian akan terlihat seperti ini :
Perhatikan bahwa adanya warning, tetapi bukan error. Ini hanya

mengingatkan bahwa variabel input data yang datang ke node
StartKuotaPinjaman belum digunakan. Ini tidak masalah karena masih
ditengah pengembangan proses. Ini merupakan input variable untuk elemen
<receive> StartKuotaPinjaman yang ditetapkan ketika membuat
KuotaPinjamanPartnerLink.
Setelah memulai eksekusi elemen, StartKuotaPinjaman,
maka akan dieksekusi dua activities sebagai berikut:
ServicePenetapanBunga mengirim tingkatBunga
ServiceHitungCicilan untuk menentukan cicilanBulanan dan
membuat deskripsi.
Cara memanggil service luar ke BPEL adalah dengan menyisipkan elemen
134
invoke ke dalam model dan menghubungkan dengan Partner Link.

Kemudian dari palette, lakukan drag operasi Invoke ke dalam model dan
drop pada titik oranye diatas activity reply dari ReturnKuotaPinjaman:
Elemen Invoke1 ditambahkan ke model. Klik-double pada label Invoke1

dan ganti nama menjadi PenetapanBunga. Seperti node receive yang telah
dikonfigurasi dengan Partner Link, juga diperlukan konfigurasi node invoke
dari PenetapanBunga.
Pertama, perlu dibuat Partner Link untuk web service
ServicePenetapanBunga. Ini merupakan sebuah channel untuk
berbicara melalui ServicePenetapanBunga yang dibuat di proyek
terdahulu.
135
6.4.5 Mengimport XSD dan WSDL

Sebelum dapat menambahkan Partner Links ke model BPEL, diperlukan
WSDL dan XSD. Untuk menyediakannya maka keduanya harus diimport ke
dalam proyek KuotaPinjaman.
Untuk mengimport WSDL (dan XSD) yang mendeskripsikan interface
web service ServicePenetapanBunga, maka temukan web service dengan
klik hirarki PenetapanBungaPinjaman / Web service, kemudian klik-
kanan pada ServicePenetapanBunga dan pilih opsi Generate and Copy
WSDL. Maka window Generate and Copy WSDL akan tampak.
Sebagai tujuan, pilih direktori src pada KuotaPinjaman dan klik OK:
Perhatikan pada node Process Files untuk KuotaPinjaman dan tampak

bahwa WSDL dan XSD telah dikopi.
Lakukan langkah yang sama untuk Generate and Copy WSDL untuk web
136
service ServiceHitungCicilan pada proyek

HitungCicilanPinjaman. Jika telah selesai, akan terlihat dokumen
WSDL dan XML untuk web service ini. Pada Process Files untuk proyek
KuotaPinjaman.
Tutup hirarki pada panel PenetapanBungaPinjaman dan
HitungCicilanPinjaman.
Lakukan drag ServicePenetapanBungaService.wsdl dari
KuotaPinjaman/Process Files dan drop ke sisi kanan kanvas BPEL:
137
Window Create New Partner Link akan tampak. Untuk Name, ketik
PenetapanBungaPL. Klik Ok untuk menerima defaults. Node Partner Link
tampak pada kanvas.
Sekarang perlu dihubungkan antara Partner Link dengan activity invoke

dari PenetapanBunga. Klik elemen invoke PenetapanBunga. Klik ikon
edit (pensil) diatasnya. Window Property Editor akan tampak. Ketikkan seperti
gambar dibawah ini:
138
Seperti sebelumnya, buat Input dan Output Variables, dengan klik pada
tombol Create dan terima default. Sekarang <invoke> (dinamai
PenetapanBunga) dapat berbicara dengan ServicePenetapanBunga
melalui channel yang disediakan Partner Link.
Setelah memilih Ok, Partner Link akan dihubungkan dengan activity
invoke pada kanvas design:
139
Sekarang statement invoke telah ditetapkan, dan dapat dilihat dengan

berpindah ke view Source:
<invoke name="PenetapanBunga"
partnerLink="PenetapanBungaPL" operation="getBunga"
xmlns:tns="http://bunga/"
portType="tns:ServicePenetapanBunga"
inputVariable="GetBungaIn" outputVariable="GetBungaOut"/>
Tambahkan activity invoke lainnya ke model untuk web service ke dua

(HitungCicilanPinjaman). Kembali ke view Design.
Seperti yang telah dilakukan sebelumnya, dari palette, lakukan drag
140
operasi Invoke ke dalam model dan drop di bagian titik oranye diatas elemen
reply dari ReturnKuotaPinjaman.
Activity Invoke1 ditambahkan ke model. Klik-double pada label Invoke1
dan ganti nama menjadi HitungCicilanPinjaman.
Untuk membuat Partner Link dari Web service

HitungCicilanPinjaman, maka akan dilakukan langkah yang sama seperti
pada PenetapanBunga. Lalu lakukan drag
ServiceHitungCicilanService.wsdl dari KuotaPinjaman/Process
141
Files dan drop ke sisi kanan kanvas BPEL dibawah

PenetapanBungaPartnerLink
Seperti sebelumnya, window Create New Partner Link akan muncul.
Untuk Name, ketikkan HitungCicilanPinjamanPL dan pilih Ok untuk
menerima default.
Sekarang akan dihubungkan Partner Link ke activity invoke

HitungCicilanPinjaman. Klik activity invoke
HitungCicilanPinjaman. Klik pensil diatasnya. Window Property
Editor akan muncul. Ketikkan seperti gambar dibawah:
142
Gunakan tombol Create untuk menetapkan nama Input dan Output

Variables. Lalu terima semua nama default. Setelah memilih Ok, Partner Link
ini akan dihubungkan dengan activity pada kanvas design. Simpan dengan
mengklik Save All. Model BPEL akan terlihat seperti gambar dibawah ini:
143
Sekarang proses BPEL dapat berbicara kepada Web service. Dua web
service ini menggunakan interface yang dideskripsikan dalam dokumen WSDL
dan berbicara melalui channels yang disediakan oleh Partner Links.
Untuk menjalankan fungsinya dua web service memerlukan input.
Struktur data input didefinisikan dengan dikaitkan Partner Links sebagai input
variables. Maka perlu pemetaan nilai untuk penetapan input. Dalam BPEL, akan
dilakukan pemetaan dengan node Assign.
6.4.6 Menambah Elemen Assign
Dua Web service akan mendapatkan input dari input yang disediakan oleh
144
klien proses BPEL. Input akan dikirimkan melalui channel

KuotaPinjamanPartnerLink melalui WSDL yang telah didefinisikan
sebelumnya dalam proyek.
Drag node Assign dari Palette dan drop ke bagian oranye sebelum activity
PenetapanBunga. Klik-double pada label Assign1 dan ganti nama menjadi
InputPenetapanBunga.
Klik-double pada InputPenetapanBunga dan lihat display Mapper:
145
Seperti tampak pada gambar diatas, ekspansi node

WSDLKuotaPinjamanOperationIn di panel kiri (panel from) untuk
menunjukkan variabel yang berisi InputPart.
Juga ekspansi node GetBungaIn pada panel sisi kanan (panel to) untuk
menunjukkan parameter GetBungaIn.
Pada Mapper, output berada dikiri dan input tampak pada sisi kanan.
Lalu drag dan drop dari
WSDLKuotaPinjamanOperationIn.InputPart.jenisPinjaman
ke GetBungaIn.parameters.jenisPinjaman:
146
Tinggalkan Mapper dan kembali ke mode Design dengan melakukan klik

kontrol Design pada kanvas window. Drag node Assign lainnya dan drop ke area
oranye sebelum node activity HitungCicilanPinjaman. Klik-double
pada label Assign1 dan ganti nama menjadi InputHitungCicilan.
Jika ada masalah dalam menamai elemen Invoke, maka klik-kanan dan
pilih Properties dan rubah nama dengan mengedit property Name.
Klik-double pada node InputHitungCicilan dan lihat panel
Mapper lagi. Drag dan drop untuk memetakan output (sisi kiri) ke input (sisi
kanan):
tingatBunga (GetBungaOut.parameters.return -->
Variables.GetCicilanIn.parameters.tingatBunga)
jumlah (WSDLKuotaPinjamanOperationIn.InputPart.jumlah
--> Variables.GetCicilanIn.parameters.jumlah)
periode(WSDLKuotaPinjamanOperationIn.InputPart.periode
--> Variables.GetCicilanIn.parameters.periode)
147
Pindah kembali ke mode Design. Sekarang akan ditambahkan elemen

Assign lagi sehingga dapat dipetakan nilai ke output dari proses bisnis. Lalu,
drag node Assign dan drop ke node sebelum reply ReturnKuotaPinjaman.
Ganti nama assign menjadi AssignResults. Ganti nama Assign,
dengan klik-kanan dan pilih Properties dan rubah nama dengan mengedit Name
property. Klik-double node AssignResults untuk melihat display Mapper. Drag
dan drop untuk memetakan from (inputs pada sisi kiri) ke to (output pada sisi
kanan):
148
Ini merupakan kopi dari perhitungan jumlah pembayaran bulanan yang

dihasilkan oleh ServiceHitungCicilan ke dalam variabel
cicilanBulanan yang merupakan return dari proses bisnis.
Sekarang, lakukan build text string pada variabel deskripsi dalam
WSDLKuotaPinjamanOperationOut.OutputPart. Kemudian akan
digabungkan beberapa nilai variabel dari beberapa teks statik sepertii ini: <jenis
pinjaman> + " jumlah pinjaman : " + <jumlah>
Window BPEL Mapper mempunyai beberapa fitur yang membantu
membuat tambahan BPEL constructs. Pilih String / Concat untuk menunjukkan
bagaimana Mapper dapat menghasilkan tambahan statemen BPEL.
Hal ini akan menghasilkan deskripsi seperti MOBIL jumlah pinjaman
: 10000.00
149
Klik pada node deskripsi pada sisi kanan Mapper. Area biiru tampak
untuk menunjukkan titik sisipan pada Mapper:
Pilih operasi Concat dari menu String pada bagian atas panel BPEL
Mapper.
Node Concat ditambahkan ke kanvas Mapper pada area biru untuk node
description. Hubungkan variabel jenisPinjaman ke bagian pertama dari
string penggabungan (concat):
150
Klik-double pada String slot ke dua dan ketikkan teks loan for jumlah
of:
Akhiri penggabungan (concatenation) dengan menambahkan nilai

jumlah seperti gambar dibawah:
Jangan lupa hubungkan return String Concat ke

WSDLKuotaPinjamanOperationOut.OutputPart.description
sehingga menghasilkan penggabungan.
Pemetaan telah lengkap, lalu kembali ke mode Design. Simpan semua
pekerjaan dengan klik Save All. Setelah pemetaan lengkap, dilanjutkan dengan
validasi proses bisnis dengan memilih kontrol Validate XML pada bagian atas
window design.
151
Jika proses BPEL bebas dari error sintaks, maka akan terlihat pesan 0
Error(s), 0 Warning(s) pada panel cek XML.
Sekarang akan dilakukan build dengan klik-kanan node proyek

KuotaPinjaman dan memilih Clean and Build. Jika terlihat pesan BUILD
SUCCESSFUL maka bagian ini telah lengkap. Lakukan Build saja (bukan
Clean and Build) jika direktori tidak terhapus.
Jika diperhatikan maka tidak ada opsi Deploy untuk jenis proyek ini.
Pada langkah berikutnya, maka modul BPEL ini akan digabungkan dengan
aplikasi komposit dan dideploy di proyek ini.
Klik pada tab Files untuk melihat yang telah dihasilkan oleh Netbeans.
152
Klik pada tab Projects sehingga akan dibuat aplikasi komposit (composit
application) dan melakuan deploy.
6.4.7 Membuat Aplikasi Komposit

Topik aplikasi komposit lagi trendy saat ini. Ini digunakan untuk
membangun aplikasi yang terdiri dari ssekumpulan komponen (sub-assemblies)
yang terpisah. Masing-masing sub-assembly membungkus dari implementasi
dengan menyediakan well-defined public interface.
Untuk dapat melakukan pengujian proses BPEL KuotaPinjaman
pada proyek selanjutnya, maka akan dibuat aplikasi komposit dan
153
menambahkan proyek BPEL dalam aplikasi ini dan mendeploynya.

Selanjutnya, buat aplikasi komposit dengan memilih File / New Project /
SOA / Composite Application. Klik Next dan ketik AplikasiKuotaPinjaman
untuk Project Name. Klik Finish dan aplikasi komposit baru akan tampak pada
panel Projects:
Pada saat menambahkan proyek KuotaPinjaman ke aplikasi komposit, akan

terlihat editor CASA (Composite Application Service Assembly). Kemudian akan
ditambahkan modul BPEL KuotaPinjaman pada aplikasi komposit yang baru
ini.
Lakukan klik-kanan pada AplikasiKuotaPinjaman dan pilih Add
JBI Module. Window Select Project akan tampak, demikian pula CASA
(Composite Application Service Assembly) Editor juga muncul.
Pada window Select Project lakukan klik pada KuotaPinjaman dan
pilih tombol Add Project JAR Files. Pada editor CASA, akan tampak proyek
KuotaPinjaman telah ditambahkan pada kanvas.
154
Selanjutnya lakukan klik kontrol Build Project pada bagian atas editor
CASA. Editor CASA akan melakukan assembly pada kanvas dan menunjukkan
service units yang dapat diidentifikasikan untuk proyek KuotaPinjaman:
Terlihat adanya Consume endpoints berwarna ungu, tetapi tidak

berhubungan dengan Provide endpoints warna hijau.
Akan terlihat bahwa modul BPEL sedang diinvokasi melalui SOAP
request, tetapi tidak ada PenetapanBungaPartnerLink dan
HitungCicilanPinjamanPartnerLink yang mengkonsumsi dua web
service ini.
155
Karena itu, lakukan drag dua soap WSDL Bindings dari palette dan drop
ke area WSDL Ports area:
Hubungkan ke Partner Links:
Sekarang diperlukan informasi endpoint untuk ke dua WSDL ports yang

baru itu. Klik-kanan pada casaPort1 WSDL port (yang terkoneksi ke
PenetapanBungaPL) dan pilih Properties.
156
Untuk Location, klik pada ikon ... dan ketikkan :

http://localhost:8080/ServicePenetapanBungaService/Service
PenetapanBunga
http://localhost:${HttpDefaultPort}/AplikasiKompositKuotaService1/c
asaPort1
Untuk Endpoint Name, ketikkan: PenetapanBungaPort. Pilih Close
untuk merekam perubahan property. Klik-kanan pada casaPort2 WSDL port
(yang terkoneksi ke HitungCicilanPinjamanPartnerLink) dan pilih
Properties.
Untuk Location, klik pada ikon ... dan ketikkan :
http://localhost:8080/HitungCicilanPinjaman/ServiceHitun
gCicilanService
http://localhost:${HttpDefaultPort}/AplikasiKompositKuotaService2
/casaPort2
Perhatikan adanya dua nilai Location yang sesuai dengan service names
pada dokumen WSDL untuk setiap web service. Nilai Endpoint Name cocok
dengan port names pada dokumen WSDL. Untuk Endpoint Name, ketikkan:
HitungCicilanPinjamanPort. Pilih Close. Simpan semua pekerjaan
dengan Save All.
Klik kanan pada node AplikasiKuotaPinjaman pada panel
157
Projects dan pilih opsi Clean and Build. Perhatikan pada windows Output
adanya pesan BUILD SUCCESSFUL.
Klik-kanan node AplikasiKuotaPinjaman dan pilih opsi Deploy.

Perhatikan window Output adanya pesan BUILD SUCCESSFUL.
Sebelum pindah ke proyek4, maka akan digunakan fasilitas pengujian
NetBean's untuk melakukan beberapa unit testing. Perhatikan bahwa aplikasi
komposit yang dideploy tampak seperti framework JBI. Klik pada tab Services
dan ekspansi node Servers / GlassFish V2 untuk menemukan node JBI.
Ekspansi node JBI untuk menemukan bahwa terdapat satu service assembly
yang berisi dua service units yang telah dideploy.
158
Klik-kanan pada service unit dan pilih Properties, akan terlihat bahawa JBI
component (SE atau BC) akan terdeploy. Misalnya
AplikasiKuotaPinjaman- KuotaPinjaman dideploy di sun-bpel-
engine.
Inilah AplikasiKuotaPinjaman service assembly yang terlihat
pada CASA Editor:
Ada tiga WSDL ports yang direpresentasikan oleh

AplikasiKuotaPinjaman-sun-http-binding service unit. Modul
BPEL KuotaPinjaman JBI pada CASA Editor direpresentasikan oleh
AplikasiKuotaPinjaman- KuotaPinjaman service unit.
159
6.4.8 Testing Aplikasi Komposit

Sekarang akan dilakukan pengujian untuk aplikasi yang mencakup input
parameter jenis pinjaman, jumlah pinjaman dan periode, dan menghasilkan
deskprisi dan jumlah pembayaran bulanan. .
Dalam panel Projects pada node AplikasiKuotaPinjaman, klik
node Test dan pilih New Test Case:
Window New Test Case akan muncul. Untuk Test Case Name, ketikkan
HomeLoanTestCase kemudiah pilih Next. Kemudian pilih dokumen WSDL
yang akan ditest. Ekspansi KuotaPinjaman Source Packages dan pilih
WSDLKuotaPinjaman.wsdl:
160
Klik Next. Kemudian pilih WSDLKuotaPinjamanOperation dan

klik Finish.
161
Editor XML editor akan muncul dengan dokumen input. Akan ada tiga
fields delimited dengan simbol ?. Ketik fields ini dengan data yang akan
diuji.
<soapenv:Body>
<skem:RequestKuotaPinjaman>
<skem:jenisPinjaman>RUMAH</skem:jenisPinjaman>
<skem:jumlah>25000.00</skem:jumlah>
<skem:periode>15.0</skem:periode>
</skem:RequestKuotaPinjaman>
</soapenv:Body>
Simpan semua pekerjaan dengan klik Save All. Jalankan pengujian

dengan klik-kanan pada TestCasePinjamanRumah pada panel Projects
dan pilih Run. Pada saat run pertama dari test, output masih kosong, sehingga
selalu ada pesan dialog The expected output for the test case is empty .... Klik
saja Yes.
Jalankan test lagi dengan klik Run. Maka akan terlihat output dibawah
ini yang menunjukkan keberhasilan test.
162
Klik-double pada output test untuk melihat output XML yang

dikembalikan pada aplikasi komposit. Akan terlihat deskripsi dan pembayaran
telah benar.
Lihat pada field cicilanBulanan dan deskripsi. Terlihat aplikasi

telah melakukan passed unit testing. Proyek selanjutnya akan dibuat interface
berbasis web untuk menerapkan aplikasi komposit.
163
6.5 Membangun User Interface

Pada proyek terakhir, telah dibangun modul BPEL untuk mengorkestrasi
dua web service. Pada saat pengujian digunakan, fasilitas test built-in yang ada
pada aplikasi komposit. Pada proyek ini, akan dibuat user interface berbasis web
untuk berkomunikasi dengan proses BPEL.
6.5.1 Membuat Proyek Aplikasi Web

Pilih File / New Project dari menu bar. Window New Project akan
muncul. Pilih Java Web sebagai category dan Web Application untuk project
type. Kemudian klik Next. Untuk Project Name, ketik UIKuotaPinjaman
dan klik Next. Jika langsung klik Finish (bukan Next) maka framework interface
web tidak ditambahkan secara otomatis.
Pada langkah Server and Settings, klik Next (bukan Finish!). Pada bagian
Visual Web JavaServer Faces lakukan cek pada box. Kemudian pilih Finish.
User interface aplikasi Java atau JavaFX Script dapat digunakan, keduanya
didukung oleh NetBeans.
Proyek UIKuotaPinjaman akan tampak pada panel Projects.
Perhatikan bahwa kanvas design Page1.jsp tampak dengan widget palette. Jika
palette tidak tampak maka klik-kanan window, gunakan opsi menu bar Window
/ Palette untuk memunculkan.
Drag empat Labels dan satu Button dari palette dan drop ke kanvas
Page1.jsp:
164
Untuk merubah default pada label text, lakukan klik-double dan ketikkan
teks yang diinginkan. Tambahkan tiga Text Fields ke layout di sebelah kanan
label. Untuk meluruskan teks, klik semua label, kemudian klik-kanan dan
gunakan opsi Align. Coba juga gunakan opsi Align / Snap to Grid.
Gunakan opsi menu bar Window / Properties untuk menampilkan panel
Properties. Ubah id property dari tiga text fields menjadi :
jenisTextField
jumlahTextField
periodeTextField
Tambahkan sebuah Label dengan id adalah paymentLabel di sebelah

kanan label Perhitungan Cicilan Bulanan:.
165
Beri nama button menjadi Hitung deengan merubah pada text property
pada panel Properties.
Pada tiga data entry textField dan pada label yang menampilkan jumlah
pembayaran lakukan, add binding attribute dengan klik pada tiap widgets
(jenisTextField, jumlahTextField, periodeTextField dan
cicilanLabel) dan memilih opsi seperti dibawah ini.
166
Simpan semua pekerjaan dengan klik Save All. Klik pada kontrol JSP
pada bagian panel layout untuk melihat sintaks JSP yang secara otomatis dibuat
didasarkan pada widget yang ditambahkan pada kanvas design. Aksi Add
Binding Attribute telah ditambahkan pada sintaks yang disorot berikut ini.
167
Perhatikan bahwa statement binding mengacu pada Page1. Klik pada

kontrol Java pada bagian atas panel layout untuk melihat backing bean dari kode
Java untuk kelas Page1. Hubungan antara sintaks JSP dan Java backing bean
telah dijelaskan oleh spesifikasi JSF. Klik pada kontrol Design untuk kembali
ke mode Design.
6.5.2 Membuat klien Web service

Komponen JSF membawa kemampuan dari Java Swing berbasis desktop
ke perancangan web UI. Komponen semacam button mempunyai action
handlers yang berisi kode yang dieksekusi ketika user berinteraksi dengan
komponen JSF. Kode JSP pada sisi klien untuk melakukan invoke ke action
handler yang berjalan di dalam web container (server- side).
Klien web adalah kode JAX-WS yang dihasilkan untuk melapisi dengan
Java / XML marshaling dan unmarshaling yang berkomunikasi antara klien
(service consumer) dan server (service provider).
Selanjutnya diperlukan penetapan action handler untuk tombol Hitung
sehingga dapat melakukan invoke ke proses bisnis KuotaPinjaman dan
mendapatkan return pembayaran bulanan pada field cicilanLabel.
Proses bisnis KuotaPinjaman tersedia sebagai Web service. Karena itu
diperlukan beberapa kode sisi klien untuk memanggil web service. Sehingga
akan dibuat klien web service.
NetBeans dapat dengan mudah membuat kode sisi klien untuk
memanggil proses bisnis KuotaPinjaman sebagai web service. Hanya perlu
168
tahu dimana endpoint web service berada. Dengan kata lain, bagaimana proses
BPEL mendengarkan request SOAP/HTTP?
Untuk menjawabnya, dengan melihat WSDLKuotaPinjaman yang
dibuat untuk melakukan wrap proses BPEL sehingga dapat dipanggil via
SOAP. WSDL ini dapat berjalan karena telah ditest melalui
HomeLoanTestCase.
Kemudian, klik-double pada WSDLKuotaPinjaman.wsdl pada
Process Files untuk KuotaPinjaman sehingga dapat dilihat endpoint
address:
169
Lihat gambar diatas bahwa soap:address ditetapkan sebagai :

http://localhost:${HttpDefaultPort}/WSDLKuotaPinjaman
Service/WSDLKuotaPinjamanPort
6.5.3 Menemukan Port JBI Binding Component

Perhatikan bahwa walaupun mengacu pada port tertentu, WSDL masih
menggunakan environment variable (${HttpDefaultPort}) yang dibuat Netbeans
secara otomatis. UIKuotaPinjaman merupakan aplikasi web stand-alone dan
bukan bagian dari aplikasi komposit. Sehingga, UIKuotaPinjaman
mengambil manfaat dari substitusi variabel lingkungan. Karena itu hanya perlu
dijawab pertanyaan : Apa port aktual tempat endpoint mendengarkan ?
Untuk menjawab pertanyaan tersebut, maka akan ditanyakan pertanyaan
lainnya. Dimana kontainer JBI yang mendeploy endpoint SOAP? Jika diketahui
nomor port untuk komponen JBI yang menjadi tumpangan endpoint, maka akan
diketahui nomor port aktual untuk mengantikan ${HttpDefaultPort}.
Klik-double Service Assembly pada AplikasiKuotaPinjaman untuk
menampilkan service assembly pada CASA Editor:
170
Endpoint direpresentasikan oleh port SOAP WSDL yang dilabeli

WSDLKuotaPinjamanPort. Klik-kanan pada port ini dan pilih Properties:
171
Dapat dilihat dalam property Component Name bahwa port WSDL port
(SOAP endpoint) dideploy pada sun-http-binding JBI component. Komponen
binding HTTP merupakan salah satu dari lebih 40 komponen JBI dalam proyek
Open ESB.
Setelah diketahui port dari komponen sun-http-binding maka akan
diketahui nomor port untuk endpoint web service untuk memanggil proses
KuotaPinjaman.
Untuk menemukan port sun-http-binding component maka pindah ke
panel Services dan akses Properties nya:
172
Perhatikan bahwa Default HTTP Port Number adalah 9080.

Sehingga untuk mengakses endpoint SOAP web service:
http://localhost:${HttpDefaultPort}/WSDLKuotaPinjaman
Service/WSDLKuotaPinjamanPort
digunakan URL:
http://localhost:9080/WSDLKuotaPinjamanService/WSDLKu
otaPinjamanPort
Tambahkan ?wsdl pada bagian akhir the URL dan gunakan web browser
untuk melihat endpoints WSDL:
http://localhost:9080/WSDLKuotaPinjamanService/WSDLKu
otaPinjamanPort?wsdl
173
Akan terlihat dokumen WSDL yang memverifikasi bahwa endpoint ke

KuotaPinjaman adalah port 9080:
Dengan URL dari endpoint WSDL , maka akan siap dibangun klien web
service. Pada panel Projects, klik-kanan pada proyek UIKuotaPinjaman dan
pilih opsi New / Other / Web service / Web service Client. Klik Next untuk
memulai wizard.
Klik radio button WSDL URL. Kemudian paste dalam URL untuk WSDL
yang akan ditampilkan:
http://localhost:9080/WSDLKuotaPinjamanService/WSDLKuo
174
taPinjamanPort?wsdl
Klik Finish untuk mulai membuat sisi klien. WSDL diakses dan klien Web
service muncul pada proyek dibawah Web service References:
175
Perhatikan bahwa web service reference tidak dapat diklik-double. Yang

dikerjakan NetBeans adalah mengumpulkan yang diperlukan untuk
menghasilkan kode sisi klien JAX-WS untuk melakukan marshal dan
unmarshal XML dan Java object.
NetBeans memudahkan dalam menggunakan kode sisi klien tanpa
khawatir cara melakukan marshaling dan unmarshaling.
Akhirnya telah berhasil dibuat kode button handler yang menggunakan
klien Web service. Pada mode Design Page1.jsp, klik-doublepada tombol
Hitung untuk menampilkan kode untuk handler yang masih kosong:
Akan ditambahkan beberapa kode untuk memproses klien web service

176
yang baru saja dibuat. Klik pada bagian kode setelah komentar. Tekan Enter
untuk membuat baris kosong. Pada baris kosong, klik-kanan dan pilih Web
service Client Resources / Call Web service Operation. Pada window pop-up
pilih WSDLKuotaPinjamanOperation dan pilih OK.
Kode klien untuk mengakses proses KuotaPinjaman BPEL sebagai
web service per interface WSDL akan ditambahkan pada button handler:
Ini akan memberikan kerangka kode yang memungkinkan button handler

untuk menangani proses KuotaPinjaman BPEL melalui panggilan web
service. Sekarang perlu diketikkan rincian kodenya.
Ganti keseluruhan button handler dengan mengkopi-paste statemen
berikut ini sehingga kode pada button handler akan tampak seperti ini:
public String button1_action() {
try {
org.netbeans.j2ee.wsdl.kuotapinjaman.wsdlkuotapinjaman.WSDLKuo
taPinjamanPortType port = service.getWSDLKuotaPinjamanPort();
String jenisPinjaman = (String) jenisTextField.getText();
String jumlahString = (String) jumlahTextField.getText();
String periodeString = (String) periodeTextField.getText();
177
double jumlah = Double.valueOf(jumlahString);

int periode = Integer.valueOf(periodeString);
org.netbeans.xml.schema.SkemaKuotaPinjaman.InputKuotaPinjaman
inputPart = new
org.netbeans.xml.schema.SkemaKuotaPinjaman.InputKuotaPinjaman(
);
inputPart.setJenisPinjaman(jenisPinjaman);
inputPart.setJumlah(jumlah);
inputPart.setPeriode(periode);
org.netbeans.xml.schema.SkemaKuotaPinjaman.OutputKuotaPinjaman
result = port.wsdlKuotaPinjamanOperation(inputPart);
System.out.println("Result = " + result);
double cicilanBulanan = result.getCicilanBulanan();
String cicilanBulananString = String.valueOf(cicilanBulanan);
cicilanLabel.setValue(cicilanBulananString);
} catch (Exception ex) {
cicilanLabel.setValue("Error");
System.out.println("****** " + ex.getMessage());
System.out.println("****** " + ex.getCause());
}
return null;
}
}
Langkah-langkah dalam koding diatas melakukan beberapa pekerjaan

sebagai berikut:
1. Membangun channel komunikasi
2. Mendapatkan data yang dimasukkan melalui field user interface
3. Membangun struktur data yang digunakan komunikasi melalui channel
178
4. Memanggil Web service provider melalui channel

5. Membangun user interface widget dengan hasil dari Web service call
Gunakan reformat Alt-Shift-F to untuk merapikan Java code. Lakukan

Save All.
6.5.4 Deploying Proyek

Lakukan build proyek dengan klik-kanan pada node
UIKuotaPinjaman dan pilih Clean and Build.
Kemudian akan dilakukan deploy aplikasi web sehingga dapat dilakukan
test. Untuk deployment sebelumnya, lakukan klik-kanan dan pilih opsi Deploy.
Sementari itu, pindah ke GlassFish Admin Console. Hal ini akan memberi
kesempatan untuk melihat integrasi antara NetBeans IDE dan GlassFish
Enterprise Server. Pastikan server GlassFish telah aktif.
Untuk memulai deployment, pindah ke panel Services dan invoke
GlassFish Admin Console dengan klik-kanan GlassFish V2 dan pilih opsi View
Admin Console:
179
Akan muncul halaman web yang memerlukan otentifikasi. Untuk User

Name, ketik: admin. Untuk Password, ketik: adminadmin
Aplikasi UIKuotaPinjaman merupakan sebuah aplikasi web,
sehingga dibawah hirarki aplikasi pada sisi kiri, klik pada node Web
Applications. Perhatikan bawha HitungCicilanPinjaman adalah aplikasi
web yang telah dideploy.
180
Untuk mendeploy aplikasi UIKuotaPinjaman, klik pada tombol

Deploy. Display Deploy Enterprise Applications/ Modules akan muncul.
Pada field Location lakukan browse ke direktori D:\Latihan
SOA\UIKuotaPinjaman\dist dan pilih file UIKuotaPinjaman.war:
181
Klik pada tombol OK untuk mendeploy file.war. Setelah deployment

berakhir, maka daftar aplikasi web yang dideploy akan muncul:
Aplikasi UIKuotaPinjaman telah siap dilakukan testing.
182
6.5.5 Testing User Interface

Selanjutnya akan digunakan aplikasi web UIKuotaPinjaman untuk
menguji proses KuotaPinjaman BPEL.
Klik-kanan pada node UIKuotaPinjaman dan pilih Run. Sebuah
halaman web akan muncul yang menampilkan interface yang telah didesain.
Ketikkan data pinjaman pada tiga text box, seperti dibawah dan pilih
tombol Hitung:
Setelah menekan tombol Hitung jumlah pembayaran harusnya

tampak pada text box Perhitungan Cicilan Bulanan seperti gambar
diatas.
Jika muncul Error maka cek pada panel output GlassFish V2 untuk
pesan error.
183
6.6 Menyimpan Proses Pinjaman ke Database

Pada proyek sebelumnya, skenario pemrosesan pinjaman telah lengkap
dengan menambahkan interface berbasis web browser untuk menggerakkan
proses BPEL yang menghasilkan proses pinjaman. Pada proyek ini akan
dilakukan penyimpanan peminjaman ke dalam database. Akan dimulai dengan
kemampuan perluasan proses BPEL dengan pasangan invoke/ assign baru dan
Partner Link yang didasarkan pada WSDL yang merefleksikan struktur dari
tabel database. Database Binding Component akan melakukan pekerjaan JDBC
dengan Java DB.
6.6.1 Membuat Database

Sebelum dapat menggunakan Database Binding Component untuk
menyisipkan baris ke dalam tabel, perlu dilakukan beberapa konfigurasi.
NetBeans mempunyai database bawaan yang dinamakan Java DB. Akan
dibuat database dalam Java DB tempat menyimpan tabel KUOTAPINJAMAN.
Java DB didasarkan pada proyek open source Apache Derby. Sebelumnya
merupakan teknologi Cloudscape. Java DB sebagai bagian dari Java JDK.
Untuk membuat database, klik pada tab Services. Ekspansi node
Databases untuk menampilkan Java DB dan koneksi yang ada :
184
Klik-kanan pada node Java DB dan pilih Create Database. Window Java
DB Database akan tampak. Ketik windows seperti gambar dibawah ini:
Database Name: DBLatihan

User Name: admin
185
Password: admin
Jangan ubah default Database Location.

Lokasi didasarkan pada folder GlassFish
ESB, diinstall.
Tekan OK. Setelah DBLatihan berhasil dibuat, akan terlihat koneksi
berikut ini ditambahkan pada daftar panel Services:
Sekarang koneksikan database sehingga dapat dibuat tabel

KUOTAPINJAMAN. Klik-kanan pada koneksi baru dan pilih Connect.
Ekspansi node jdbc:derby:... DBLatihan dan perhatikan bahwa belum
ada tabel yang ada dibawah node Tabel:
186
Klik-kanan node jdbc:derby:...DBLatihan dan pilih Execute

Command. Perintah SQL akan muncul di window. Ketikkan perintah SQL
untuk membuat tabel dan menyimpan peminjaman :
Agar dapat dilakukan kopi-paste, berikut ini perintah SQL selengkapnya:

create Tabel kuotapinjaman (
recordid INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
jenisPinjaman VARCHAR (20),
jumlah NUMERIC (15,2),
periode INTEGER,
cicilan NUMERIC (15,2));
187
PRIMARY KEY GENERATED ALWAYS AS IDENTITY memungkinkan

Java DB secara otomatis membuat nomor berurutan yang unik untuk kolom
kunci.
Eksekusi perintah SQL dengan melakukan klik ikon Run SQL di bagian
atas window perintah SQL:
Setelah eksekusi SQL Command maka pada window Output akan terilhat
pesan berikut :
Untuk meyakinkan bahwa tabel telah berhasil dibuat, klik pada node
Tabel dan pilih Refresh. Tabel KUOTAPINJAMAN akan tampil di daftar :
Untuk melihat isi tabel, klik-kanan KUOTAPINJAMAN dan pilih View
188
Data. Maka akan terlihat tabel baru yang masih kosong.
Dengan tabel pada Java DB, langkah berikutnya adalah mengenalkan

database tersebut ke server GlassFish. Dalam hal ini diperlukan dua langkah
konfigurasi pada GlassFish Admin Console:
Mendefinisikan JDBC Connection Pools
Membuat JDBC Resources dengan JNDI name yang memanfaatkan
Connection Pools
6.6.2 Mengakses GlassFish Admin Console

Jika GlassFish belum Start,maka perlu di-start dulu sebelum dapat
mengakses Admin Console. Akan dilakukan konfigurasi pada GlassFish
administration console. Untuk menampilkan admin console, pilih opsi View
Admin Console pada panel Services seperti gambar dibawah:
189
Halaman web akan muncul dengan dua text field yang meminta
memasukkan user name dan password. Isikan secara default sebagai berikut:
User Name: admin
Password: adminadmin
Pilih tombol Login untuk melanjutkan. Temukan opsi Connection Pools

pada Resources / JDBC dan klik pada tampilan Connection Pools:
190
Klik tombol New untuk membuat Connection Pools baru. Ketik window
wizard seperti ini:
191
Klik Next. Lakukan scroll ke bawah dan isi data berikut:

User: admin
DatabaseName: DBLatihan
Password: admin
ServerName: localhost
PortNumber: 1527
Klik Finish untuk menyimpan nilai yang diketikkan. Akan terlihat bahwa
MyTutorialPool telah ditambahkan pada daftar Connection Pools. Klik pada
MyTutorialPool dan perhatikan window Edit Connection Pools. Klik pada tab
Additional Properties dan hapus beberapa parameter yang tidak diperlukan.
Ini merupakan langkah penting, jika meninggalkan beberapa default

properties, akan menyebabkan GlassFish tidak dapat melakukan koneksi ke Java
DB. Gunakan check boxes dan tombol Delete Properties untuk menghapus semua
parameter yang tidak diperlukan sehingga daftar property akan tampak seperti
dibawah ini:
Gunakan tombol Save untuk menyimpan perubahan.

192
6.6.3 Testing konektivitas antara GlassFish dan Java DB

Kembali ke tab General dan temukan tombol Ping. Klik pada Ping untuk
menguji kemampuan GlassFish mengkoneksi DBLatihan:
Ping Succeeded menunjukkan bahwa GlassFish Connection Pools dapat

menemukan database DBLatihan database. Jangan pindah sampai ini berjalan.
Jika tidak melihat Ping Succeeded, cek ulang Connection Pools properties,
simpan dan Ping lagi.
Langkah konfigurasi GlassFish yang kedua adalah membuat JDBC
Resources dengan JNDI name yang memetakan DBLatihan. Klik pada node
JDBC Resources seperti gambar dibawah:
193
Klik pada tombol New untuk membuat JDBC Resources baru seperti
gambar dibawah:
194
Klik OK JDBC Resources yang baru telah ditambahkan pada daftar.

GlassFish sekarang telah mengatur semua service untuk mengakses
penyimpanan data ke DBLatihan Java DB melalui JDBC data source dengan
JNDI name adalah jdbc/Latihan. Java Naming and Directory Interface (JNDI)
merupakan API yang menyediakan penamaan dan fungsionalitas direktori untuk
aplikasi Java. Aplikasi menggunakan JNDI untuk melakukan lookup dan
mendapatkan akses ke berbagai komponen seperti JDBC Resources.
6.6.4 Membuat WSDL dari Database BC

Sekarang kembali lagi ke proses BPEL KuotaPinjaman dari proyek3
dan menambahkan kemampuan penyimpanan data ke database. Proses BPEL
bernama ProsesKuotaPinjaman.bpel dan dibawah hirarki Process Files
untuk KuotaPinjaman.
Temukan proses BPEL ProsesKuotaPinjaman pada proyek
KuotaPinjaman dan tampilkan di kanvas pemodelan:
195
Drag invoke baru dari palette ke dalam model di kanan sebelum elemen
ReturnKuotaPinjaman dibagian bawah. Ganti nama elemen invoke menjadi
SimpanKuotaPinjaman.
196
Elemen invoke ini akan memanggil proses BPEL ke database. Diperlukan

Partner Link tetapi belum diketahui titik interaksinya.
Semua Partner Links didasarkan pada WSDL. Sehingga akan dibuat
WSDL yang akan mereferensi ke Database Binding Component.
Untuk membuat WSDL, klik-kanan KuotaPinjaman pada panel Projects,
dan pilih New / WSDL Document. Untuk File Name, ketikkan
WSDLKuotaPinjamanDB. Pada fiels WSDL Type pilih opsi Concrete WSDL
Document.
Untuk Binding, pilih DATABASE dari drop-down list. Pastikan bawha
197
Type telah diset ke Tabel. Pilih Next. Dari URL drop-down list, pilih
DBLatihan [admin on ADMIN] data source dari drop-down list. Klik Next.
Daftar Available Tables menunjuk pada tabel KUOTAPINJAMAN
Pilih KUOTAPINJAMAN kemudian klik tombol Add> untuk

memindahkan tabel ke daftar Selected Tables. Klik Next untuk pindah ke window
berikutnya. Window Operation Specific Attributes akan tampak.
198
PilihNext untuk menerima defaults. Window Enter JNDI Name akan

muncul. Ketikkan JNDI sebagai: jdbc/Latihan. JNDI name harus sesuai dengan
yang telah ditetapkan pada JDBC Resources di GlassFish.
Pilih Finish untuk melengkapi pembuatan WSDL berbasis tabel database.
KUOTAPINJAMANDBWSDL.wsdl tampak pada node KuotaPinjaman dan
isinya tampil pada WSDL editor.
Ekspansi struktur. Klik-kanan node jdbc:input pada bagian Bindings.
Kemudian klik kanan dan pilih Properties:
Ada dua property yang harus diubah. Ubah property paramOrder menjadi
:
199
JENISPINJAMAN,JUMLAH,PERIODE,CICILAN
Ubah sql property menjadi :

insert into KUOTAPINJAMAN (JENISPINJAMAN, JUMLAH,
PERIODE, CICILAN) values (?,?,?,?)
Klik Close untuk mengabaikan window Properties. Simpan dengan klik

Save All. RECORDID tidak dimasukkan pada paramOrder karena tidak
dipassing. Dalam SQL statement, telah ditetapkan nilai DEFAULT. DEFAULT
berkaitan dengan statemen CREATE TABEL yang menetapkan recordid
INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY
6.6.5 Interaksi dengan Database via Database BC

Sekarang telah dibuat dokumen WSDL yang mendefinisikan interface
untuk tabel database KUOTAPINJAMAN. Selanjutnya akan dibuat Partner
Link pada proses BPEL StoreKUOTAPINJAMAN yang akan melakukan
invoke untuk menyimpan data. Database Binding Component akan bertindak
sebagai proxy komunikasi untuk Java DB.
Kembali lagi ke kanvas pemodelan BPEL ProsesKuotaPinjaman.
Drag dokumen WSDLKUOTAPINJAMANDB.wsdl yang baru saja dibuat dari
panel dan drop pada sisi kanan kanvas dibawah
HitungCicilanPinjamanPL:
200
Partner Link yang baru telah ditambahkan Ganti nama menjadi :

DBAksesPL. Untuk ganti nama, klik-double pada nama default (PartnerLink1)
dan ganti.
Hubungkan invoke SimpanKuotaPinjaman yang baru ditambahkan
201
dengan DBAksesPL dengan klik ke elemen invoke SimpanKuotaPinjaman

pada ikon pensil dan lengkapi isian windows seperti dibawah ini:
Klik OK dan akan terlihat invoke StoreLoanData telah dihubungkan

dengan partnerlink:
202
Perhatikan bahwa Partner Link menampilkan lima operasi database. Yang

diperlukan hanya insert saja. Sekarang akan dilakukan pemetaan data dari model
ke dalam input yang diperlukan melalui invoke StoreKuotaPinjaman.
Lakukan drag dan drop elemen assign dari palette dan drop di atas
203
StoreKuotaPinjaman.
Ganti nama elemen assign dari Assign1 menjadi:
PersiapanPenyimpanan. Klik-double elemen
PersiapanPenyimpanan dan lengkapi pemetaan dibawah ini:
Simpan pekerjaan dengan Save. Pindah ke view Source dan pilih ikon
Validate XML untuk mengecek adanya error:
204
Akan terlihat pesan peringatan yang menunjukkan bahwa variabel

InsertOut belum digunakan.
Ini tidak masalah. Diasumsikan bahwa insert database akan lancar,

sehingga tidak perlu melakukan apapun dengan return value yang disediakan oleh
Database BC.
Lakukan build ulang proyek KuotaPinjaman. Build ulang proyek
AplikasiKuotaPinjaman. Deploy ulang AplikasiKuotaPinjaman.
6.6.6 Melakukan Test Case

Sekarang kita lihat pada AplikasiKuotaPinjaman apakah Database
Binding Component sudah digunakan. Untuk menampilkan service assembly
pada CASA, klik-double pada Service Assembly pada node
AplikasiKuotaPinjaman di panel Projects:
205
Untuk menampilkan property, klik-kanan pada WSDL Port dan pilih opsi
Properties dari pop-up menu. Perhatikan bahwa DATABASE WSDL Port telah
ditambahkan ke service assembly. Lihat properties pada Database Binding
Component (sun-database-binding):
206
Klik Close untuk keluar dari window Properties. Sekarang jalankan test
lagi dan lihat apakah ada rekaman yang dituliskan di tabel database. Temukan
TestCasePinjamanRumah pada AplikasiKuotaPinjaman dengan
klik-kanan dan pilih Run:
207
Cek output dari hasil test. Akan tampak sama seperti test sebelumnya:
Kembali ke panel Services untuk menemukan Java DB connection
208
sehingga dapat diihat apakah ada rekaman yang telah disisipkan ke tabel
KUOTAPINJAMAN:
Pilih opsi View Data Untuk melihat adanya baris data yang telah
ditambahkan ke tabel KUOTAPINJAMAN:
209
Invoke baru telah berhasil, yaitu interaksi BPEL engine melalui Partner
Link ke Database Binding Component yang terkoneksi ke Java DB.
Sekarang cek lagi di CASA editor service assembly seperti dibawah ini:
210
Daftar 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
Anonim, 2014, Getting Started with JAX-WS Web Services, diakses dari
https://netbeans.org/kb/docs/websvc/jax-ws.html, tanggal 23
Desember 2014
Barrett, T., 2009, Getting Started with NetBeans, diakses dari http://www.open-
esb.net, tanggal 23 Desember 2014
Barrett, T., 2009, Demonstrating Database Operations with the Database BC (V
1.0), diakses dari http://www.open-esb.net, tanggal 23 Desember
2014
Barrett, T., 2009, A Gentle Introduction to GlassFish ESB, diakses dari
http://www.open-esb.net, tanggal 23 Desember 2014
Binildas, C. A., 2008. Service Oriented Java Business Integration, Birmingham-
Mumbai: Packt Publishing.
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 service, Prentice Hall PTR, Upper Saddle River, New Jersey
07458
Havey, M., 2005, Essential Business Process Modeling, O'Reilly Media, Inc.
1005 Gravenstein Highway North, Sebastopol, CA 95472
Holanda, H.J.A., Herniz, JM., Barroso, GC., and Serra, AB., 2010, Performance
Evaluation of Web service Orchestrated with WS-BPEL4People,
International Journal of Computer Networks & Communications
(IJCNC) Vol.2. No.6, November 2010
211
Josuttis, N.M., 2007, SOA in Practice, OReilly Media, Inc. 1005 Gravenstein
Highway North, Sebastopol, CA 95472
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 service, 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.
Korherr, B., 2008, Business Process Modeling- Languages, Goals and
Variabilities, Ph.D. Thesis, Vienna University of Technology Faculty
of Informatics, Vienna
Krafzig, D., Banke, K., dan Slama, D., 2004, Enterprise SOA: Service-Oriented
Architecture Best Practices, Prentice Hall PTR
Kumar, B.V., Narayan, P., dan Tony Ng, 2010, Implementing SOA Using
Java EE, Pearson Education, Inc, 501 Boylston Street, Suite 900,
Boston, MA 02116
Lee, H. L. ; Whang, S. 2010. E-Business and Supply Chain Integration.
http://www.stanford.edu/group/scforum/Welcome/EB SCI.pdf.
Louridas, P., 2008, Orchestrating Web service with BPEL, IEEE Software,
March/April 2008, Published by the IEEE Computer Society
OASIS. 2003. Business Process Execution Language for Web service
(BPEL4WS) Specification, Version 1.1, 5 May 2003,
http://dev2dev.bea.com/webservices/BPEL4WS.html
Piispanen, T., 2008, Business Process Management: State-of-the-Art
Technologies, Master Thesis, Helsinki University Of Technology,
Faculty of Information and Natural Sciences, Department of Computer
Science and Engineering
212
Rosenauer, G.B., 2008, A Standards-Based Approach to Dynamic Tool

Integration Using Java Business Integration: A Redesign of the toolnet
Framework built on Enterprise Integration Standards, Master Thesis,
ISIS Vienna University of Technology Institute of Software
Technology and Interactive Systems
Roshen, W., 2009, SOA-Based Enterprise Integration: A Step-by-Step Guide to
Services-Based Application Integration, McGraw-Hill Companies,
United States
Schmutz, G, Liebhart, D., Welkenbach. P., 2010, Service-Oriented Architecture:
An Integration Blueprint, Packt Publishing, Birmingham, B27 6PA,
UK.
Vinoski, S., 2005, Java Business Integration, IEEE Internet Computing, July -
August 2005, Published by the IEEE Computer Society
Weske, M., 2007, Business Process Management Concepts, Languages,
Architectures, Springer-Verlag Berlin Heidelberg
213

Buku Ajar Soa WHU

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Buku Ajar Soa WHU

Diunggah oleh

Hak Cipta:

Format Tersedia

Penulis : Wiranto Herry Utomo

Pemrograman Web Services dan SOA dengan

Wiranto Herry Utomo

Buku ini disusun berdasarkan serangkaian kegiatan penelitian yang berkaitan

Salatiga, 12 Maret 2015

4.1.2 Membuat Kelas Java ..................................................... 100

6.4.4 Menambah Partner Link ............................................... 252

1.1 Integrasi Intra-Enterprise dan Inter-Enterprise

Untuk menyelaraskan sistem bisnis dan sistem informasi tersebut

Menurut Juric (2007), ada empat arsitektur integrasi yaitu 1) point-to-

1.2 Evolusi SOA

Soket hanya memungkinkan berbagi data saja. Soket tidak

Gambar 1.3 Remote Procedure Call (Juric et al, 2007)

Setelah RPC, disusul dengan teknologi Object Request Broker (ORB)

Gambar 1.4 Object Request Broker (Juric et al, 2007)

Paralel dengan pengembangan teknologi ORB, Asynchronous Messaging

oleh soket tetapi menyediakan beberapa kelebihan seperti skalabilitas integrasi

Gambar 1.5 Message Oriented Middleware (Juric et al, 2007)

Sinkronisasi pesan dapat disimulasikan menggunakan ID korelasi untuk

Format data XML

Pemisahan komponen dari jaringan

Interface yang netral dari bahasa

Gambar 1.6 Perkembangan teknologi integrasi berbasis SOA (Roshen,

1.3 Konsep SOA

berhubungan, bagaimana service berkomunikasi, bagaimana service didesain,

Gambar 1.7 : Service-Oriented Architecture (Erl, 2005)

Service menyediakan service ke publik, berperan sebagai service

tentang SOA yang masih sangat mendasar dengan menggunakan framework

Gambar 1.8 : Komponen SOA

SOA adalah sebuah bentuk teknologi arsitektur yang mengikuti prinsip-

berhubungan, bagaimana service berkomunikasi, bagaimana service didesain,

SOA terdiri atas sekumpulan service. Namun sekumpulan service tidak

1.4 Arsitektur Integrasi

Gambar 1.9 Arsitektur integrasi point-to-point

Gambar 1.10 Arsitektur integrasi hub-and-spoke

1.4.3 Enterprise Message Bus

Infrastruktur komunikasi ini mencakup message router dan atau saluran

Gambar 1.11 Arsitektur integrasi Enterprise Message Bus

1.4.4 Enterprise Service Bus

Mirip dengan arsitektur hub-and-spoke, dalam arsitektur ESB, aplikasi

Gambar 1.12 Arsitektur integrasi Enterprise Services Bus

Fitur dan fungsionalitas utama yang didukung ESB akan membantu

menyediakan fleksibilitas dalam melakukan bind beberapa kombinasi service

Seperti telah dijelaskan sebelumnya, SOA terdiri atas sekumpulan service.

2.1 Arsitektur Web service

yang jamak digunakan adalah WSCoordination, WSTransaction, Business

Gambar 2.1 Arsitektur Web service (Juric et al, 2007)

Gambar 2.2 Elemen SOAP (Erl et al, 2008)

messages Pesan apa yang dikirim dan

portTypes Fungsi apa yang didukung service?

services Dimana letak service?

Gambar 2.3 Lima elemen WSDL (Erl et al, 2008)

Gambar 2.4 UDDI (Erl, 2005)

UDDI mengorganisasikan pendaftaran dalam enam tipe data (Erl, 2004):

disimpan, termasuk nama, deskripsi, dan unique identifier.

2.2 Integrasi Web service

mendefiniskan skope analisis, 2) mengidentifikasi sistem otomatisasi dan 3)

Dalam implementasi SOA, konsep berorientasi service

Aplication Service Layer

Business Service Layer

1. Task-centric, yaitu sebuah service yang mengenkapsulasi lojik tertentu

Orchestration Service Layer

2.3 Business Process Execution Language (BPEL)

1. Bagian <partnerLinks> mendefinisikan pihak-pihak yang bekerjasama