ENTERPRISE SERVICE BUS (ESB) DAN BUSINESS PROCESS

EXECUTION LANGUAGE (BPEL)

Oleh :

ARIES SYAMSUDDIN

Blogs.itb.ac.id/aiceware

Twitter: ariessyamsuddin

2

I. Enterprise Service Bus (ESB)

ESB adalah alat yang digunakan untuk membangung sebuah sistem yang menggunakan

konsep SOA. ESB merupakan sebuah model aplikasi arsitektur perangkat lunak yang digunakan untuk

mendesain dan melakukan implementasi interaksi dan komunikasi antar aplikasi yang saling

berinteraksi dalam SOA. Penggunaan utamanya adalah dalam Integrasi Aplikasi Enterprise yang

heterogen dan kompleks. Konsep ini dikembangkan dari bus analog yang ada pada arsitektur

hardware perangkat komputer.

Gambar 1. ESB

Tugas utama dari ESB adalah:

• Monitor dan kontrol routing pertukaran pesan antara layanan

• Menyelesaikan pertentangan antar komponen layanan berkomunikasi

• Pengendalian development dan versi dari layanan

• Pengawasan untuk redundant layanan

ESB dianggap sebagai wadah arsitektur untuk mediasi melakukan peran penyedia layanan,

seperti yang ditunjukkan pada Gambar 2. Hal ini menunjukkan bahwa ESB sendiri terdiri satu atau

lebih wadah operasional yang melayani penyedia jasa (provider) yang digunakan untuk organisasi,

dan memungkinkan dalam pembangunan, konfigurasi yang mudah, dan administrasi untuk mediasi.

Wadah ini sering dalam bentuk produk.

3

Gambar 2. Topology SOA

Kata "bus" mencerminkan analogi perangkat keras Bus pada komputer yang umum dalam

desain arsitektur komputer saat ini. Seperti dalam bus komputer yaitu konsep dasar untuk

memungkinkan aplikasi untuk dapat dengan mudah terpasang di dalam dan keluar (dijalankan dan

dimatikan) dari jaringan tanpa dampak pada komponen lain dan tanpa perlu restart sistem atau

bahkan menghentikan aplikasi yang sedang berjalan. Dalam sebuah arsitektur enterprise yang

membuat penggunaan ESB, aplikasi akan berkomunikasi melalui bus, yang bertindak sebagai

turntable pesan tunggal antara aplikasi. Pendekatan itu mengurangi jumlah point-to-point koneksi

antara aplikasi untuk berkomunikasi. Hal ini, pada gilirannya, membuat analisis dampak perubahan

software menjadi lebih sederhana dan lebih mudah. Dengan mengurangi jumlah kontak dari dan ke

aplikasi tertentu, lebih mudah untuk memantau kegagalan dan perilaku dalam sistem yang sangat

kompleks dan memungkinkan lebih mudah berubah untuk komponen.

Ini adalah konsep desain penting dari ESB bahwa setiap klien mengarahkan semua permintaan

melalui ESB bukan lewat langsung ke server. Hal ini memungkinkan ESB untuk memantau dan

mencatat lalu lintas layanan. ESB kemudian dapat berperan secara langsung dalam pertukaran pesan

dan membuat aturan standar untuk pelaksanaan pelayanan.

Kemungkinan penggunaannya adalah:

Buffer dan menunda pesan di daerah stage dan secara otomatis mengirimkannya bila

penerima sudah siap.

Memonitor pesan dan layanan agar berprilaku baik.

Menjaga proses dinamis dan kebijakan keamanan.

Pelaksanaan pelayanan berdasarkan aturan yang dinamis.

Memprioritaskan, menunda, dan menjadwal ulang pengiriman pesan dan pelaksanaan

pelayanan.

Menulis log dan meningkatkan peringatan untuk pengecualian.

ESB merupakan bagian dari perangkat lunak yang hidup antara aplikasi bisnis dan

memungkinkan komunikasi di antara mereka. Idealnya, ESB harus mampu mengganti semua kontak

4

langsung dengan aplikasi di bus, sehingga semua komunikasi terjadi melalui ESB. Untuk mencapai

tujuan ini, ESB harus merangkum fungsi yang ditawarkan oleh komponen aplikasi. Hal ini biasanya

terjadi melalui penggunaan enterprise message model. Model pesan mendefinisikan satu set standar

pesan bahwa ESB akan siap mengirim dan menerima. Ketika ESB menerima pesan, ini merupakan rute

pesan ke aplikasi yang sesuai. Seringkali, karena aplikasi yang berkembang tanpa model pesan yang

sama, ESB akan harus mengubah pesan ke format yang aplikasi dapat menafsirkannya. Sebuah

perangkat lunak adaptor melakukan tugas untuk melakukan transformasi ini.

II. Business Process Execution Language (BPEL)

Interaksi layanan Web dapat digambarkan dalam dua cara: proses bisnis executable dan

proses bisnis abstrak. Proses Bisnis Executable merupakan perilaku model yang sebenarnya dari

peserta dalam interaksi bisnis. Proses bisnis abstrak adalah proses abstrak sebagian ditentukan yang

tidak dimaksudkan untuk dieksekusi. Sebuah Proses Abstrak dapat menyembunyikan beberapa

rincian yang dibutuhkan operasional konkret. Proses abstrak melayani peran deskriptif, dengan lebih

dari satu kasus penggunaan yang mungkin, termasuk perilaku yang dapat diamati atau template

proses. WS-BPEL dimaksudkan untuk digunakan untuk memodelkan perilaku baik executable dan

Proses Abstrak.

Gambar 3. BPEL

WS-BPEL menyediakan bahasa untuk spesifikasi proses bisnis executable dan Abstrak. Dengan

demikian, merupakan model Web Services interaksi dan memungkinkan untuk mendukung transaksi

bisnis. WS-BPEL mendefinisikan model integrasi interoperable yang harus memfasilitasi perluasan

integrasi proses otomatis baik di dalam dan di antara perusahaan.

Ada sepuluh tujuan terkait dengan BPEL:

1. Mendefinisikan proses bisnis yang berinteraksi dengan entitas eksternal melalui layanan web operasi didefinisikan dengan menggunakan WSDL 1.1, dan menampakkan diri sebagai layanan

5

Web 1.1 didefinisikan dengan menggunakan WSDL. Interaksi yang "abstrak" dalam arti bahwa ketergantungan pada definisi portType, bukan pada definisi port.

2. Mendefinisikan proses bisnis menggunakan bahasa berbasis XML. 3. Mendefinisikan satu set orkestrasi Web konsep layanan yang dimaksudkan untuk digunakan

oleh kedua (executable) pandangan eksternal (abstrak) dan internal dari suatu proses bisnis.. 4. Menyediakan baik secara hirarkis dan grafik untuk pemodelan proses 5. Menyediakan fungsi manipulasi data untuk manipulasi data yang diperlukan, untuk

mendefinisikan data proses dan kontrol aliran. 6. Mendukung mekanisme identifikasi untuk proses yang memungkinkan. 7. Mendukung terciptanya implisit dan penghentian kasus proses sebagai mekanisme siklus

hidup dasar. 8. Menentukan model yang berjalan pada transaksi yang didasarkan pada teknik yang telah

terbukti seperti tindakan kompensasi dan scoping untuk mendukung pemulihan kegagalan untuk bagian proses bisnis.

9. Menggunakan Layanan Web sebagai model untuk proses dekomposisi dan perakitan. 10. Membangun pada standar layanan Web (disetujui dan diusulkan) sebanyak mungkin dengan

cara composable dan modular.

Bisnis Proses Eksekusi Bahasa untuk Web Services (BPEL) adalah bahasa berbasis XML untuk standardisasi usaha deskripsi proses serta standardisasi interaksi antara proses bisnis dalam lingkungan terdistribusi. BPEL memperluas model layanan Web interaksi dan tergantung pada Bahasa Deskripsi Layanan Web (WSDL) untuk menentukan pesan keluar dan masuk. BPEL membuat gagasan proses abstrak untuk menggambarkan perilaku terlihat secara eksternal serta proses eksekusi yang dapat dijalankan baik oleh beberapa interpreter atau dengan menyusun mereka ke beberapa bentuk executable. Service-oriented architectures (SOA) telah mendapatkan banyak perhatian sebagai teknik arsitektur pemersatu yang dapat diwujudkan secara nyata dengan teknologi layanan Web. Sebuah aspek kunci dari inkarnasi layanan Web SOA adalah bahwa layanan Web dipandang sebagai sebuah blok bangunan fundamental dari sebuah aplikasi berbasis SOA.

BPEL adalah bahasa orkestrasi, bukan bahasa koreografi. Perbedaan utama antara orkestrasi dan koreografi adalah executability dan kontrol. Sebuah Orkestrasi menentukan proses eksekusi yang melibatkan pertukaran pesan dengan sistem lain, sehingga urutan pertukaran pesan yang dikendalikan oleh desainer orkestrasi. Sebuah koreografi menetapkan protokol untuk peer-to-peer interaksi, mendefinisikan, misalnya, urutan rule pesan yang dipertukarkan dengan tujuan menjamin interoperabilitas. Seperti protokol tidak langsung dieksekusi, karena memungkinkan realisasi berbagai proses yang sesuai dengan itu. Sebuah koreografi dapat diwujudkan dengan menulis sebuah orkestrasi (misalnya, dalam bentuk sebuah proses BPEL) untuk setiap rekan yang terlibat di dalamnya. Orkestrasi dan koreografi perbedaan didasarkan pada analogi: orkestrasi mengacu pada pusat kontrol (dengan konduktor) dari perilaku dari sistem terdistribusi (orkestra yang terdiri dari banyak pemain), sedangkan koreografi mengacu pada sistem terdistribusi beroperasi sesuai dengan aturan (koreografi) tetapi tanpa kontrol terpusat. Selain menyediakan fasilitas yang memungkinkan mengirim dan menerima pesan, bahasa pemrograman BPEL juga mendukung:

Sebuah properti-pesan berbasis korelasi mekanisme Variabel XML dan WSDL Sebuah bahasa extensible plug-in model untuk memungkinkan menulis ekspresi dan

permintaan dalam berbagai bahasa: BPEL mendukung XPath 1.0 secara default Konstruksi pemrograman terstruktur termasuk if-then-elseif,dan lain-lain Sebuah scoping sistem untuk mengizinkan enkapsulasi logika dengan variabel lokal , callback ,

kompensasi-handler dan event-handler

6

Untuk mengontrol akses bersamaan ke variabel

Contoh: Jasa Travel

Dalam rangka untuk menggambarkan apa masalah alamat BPEL dan bagaimana kaitannya dengan SOA, berikut contoh dari industri perjalanan. Pertimbangkan sebuah perusahaan yang menawarkan jasa perjalanan melalui Web. Operasi mungkin termasuk:

getAvailableHotels: Masukan dari kode bandara dan mengembalikan daftar hotel dekat bandara itu.

getDescription: Masukan dari kode hotel dan mengembalikan deskripsi. getRate: Masukan kode hotel dan jenis dan jumlah kamar dan tanggal dan menghasilkan

kutipan untuk rating. makeReservations: Masukan dari identitas hotel dan tanggal. cancelReservation: Memasukkan nomor konfirmasi dan membatalkan reservasi.

Ketika membuat reservasi hotel, semua operasi ini dapat dipanggil dalam proses membuat reservasi. Pesan dimanfaatkan oleh layanan ini mungkin didasarkan pada definisi industri, seperti yang disediakan oleh OpenTravel Alliance (OTA). Sebagai contoh, perusahaan perjalanan dapat menulis WSDLs mereka sendiri yang sesuai skema OTA. Untuk mempermudah, dapat diasumsikan bahwa setiap operasi dimodelkan sebagai layanan terpisah.

Perhatikan apa yang terjadi ketika ingin membuat layanan dapat digunakan kembali yang mewakili beberapa skenario umum, seperti berbelanja untuk sebuah hotel. Kami akan memanggil beberapa layanan. Beberapa layanan akan perlu dipanggil serial. Sebagai contoh, kita perlu untuk mendapatkan daftar hotel yang dekat bandara diberikan dalam rangka untuk meminta deskripsi rinci dan tarif untuk hotel. Layanan lain dapat dipanggil secara paralel. Sebagai contoh, setelah memiliki daftar hotel, mungkin ingin meminta penjelasan dan harga untuk mereka semua, bukan satu per satu. Beberapa potongan mungkin memerlukan interaksi pengguna, seperti meninjau daftar pilihan dan memutuskan mana hotel untuk membuat reservasi.

Kita bisa membayangkan proses ini sebagai flowchart terdiri dari kegiatan dasar dan kegiatan struktural. Contoh kegiatan dasar termasuk menerima pesan, layanan eksternal memohon dan nilai-nilai menugaskan dari satu pesan yang lain. Kegiatan Struktural mungkin termasuk urutan yang melakukan kegiatan bersarang di urutan dan aliran yang melakukan kegiatan bersarang secara paralel. Ternyata bahwa gagasan kegiatan adalah apa BPEL sediakan. Di BPEL, kegiatan tersebut terdiri menerima, memanggil, menetapkan, urutan dan aliran. Ada lima belas kegiatan seperti didefinisikan dalam BPEL bersama dengan non-aktivitas elemen seperti proses, mitra link, variabel dan korelasi.

Koleksi terstruktur dari kegiatan seperti ini dapat digunakan untuk menentukan proses BPEL, yang pada gilirannya berupa sebagai layanan Web. Tentu saja, hal ini juga bisa dilakukan dalam bahasa pemrograman tradisional. Sejauh ini, manfaat utama yang telah dilihat di BPEL adalah bahwa gagasan berinteraksi dengan layanan Web yang dibangun ke dalam bahasa. Jika fokusnya adalah hampir secara eksklusif pada layanan Web orkestrasi, itu adalah dalam arti tertentu lebih alami untuk menggunakan bahasa yang memiliki konsep-konsep ini dibangun dari bahasa tujuan umum pemrograman. Namun demikian, hal ini dengan sendirinya tidak terlalu menarik karena ada banyak library yang menyederhanakan tugas mengirim dan menerima pesan dengan protokol seperti SOAP. Hal ini akan mengekspos lebih banyak alasan kuat untuk memilih BPEL dalam skenario tersebut.

7

Sejumlah properti umum untuk aplikasi proses bisnis, termasuk lama berjalan sebuah proses, kebutuhan untuk diandalkan, komunikasi asynchronous, penggunaan dari teknologi layanan Web, manajemen endpoint dan kemampuan untuk mengelola kedua transaksi serta sebagai transaksi bisnis. Meskipun salah satu sifat dapat dicapai dengan menulis kode dalam bahasa pemrograman umum, manfaat utama menggunakan BPEL adalah bahwa BPEL menyediakan abstraksi dan infrastruktur yang sangat cocok untuk kelas aplikasi.

Pandangan tentang bagaimana BPEL berasal manfaatnya dapat dibandingkan dengan penggambaran yang kadang-kadang ditemukan di media, yaitu gagasan bahwa manfaat dari BPEL adalah bahwa ia menyediakan seperti tingkat tinggi abstraksi yang analis bisnis dapat menyusun dan menjalankan proses bisnis executable dengan menunjuk dan mengklik di lingkungan pemodelan. Bahwa BPEL abstraksi menyediakan kemungkinan para development untuk menerapkan solusi yang fleksibel dan lebih efektif.

Bagi perusahaan untuk memaksimalkan manfaat dari layanan Web, dan akhirnya SOA, mereka membutuhkan cara untuk menggunakan layanan ini dalam proses bisnis otomatis yang meniru proses yang sebenarnya bisnis mereka. BPEL dirancang untuk mendefinisikan dan mengotomatisasi jenis layanan Web untuk proses bisnis. Hal ini memungkinkan otomatisasi proses tanpa coding tradisional dan pemrograman, sebagai akibatnya, proses otomatis dapat cepat dibuat prototype-nya, dikembangkan dan dimodifikasi bahkan oleh individu dengan pengalaman development yang terbatas. Oleh karena itu, menggunakan BPEL untuk mengarahkan dan mengatur layanan Web memainkan peran penting dalam SOA dengan menyediakan sarana yang kuat dimana logika bisnis dapat diartikulasikan dan dilaksanakan pada tingkat abstraksi yang dirancang untuk menyediakan layanan yang dibutuhkan untuk tugas-tugas integrasi.

Contoh helloword.bpel

<process name="HelloWorld" targetNamespace="http://jbpm.org/examples/hello" xmlns:tns="http://jbpm.org/examples/hello" xmlns:bpel="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"> <partnerLinks> <!-- establishes the relationship with the caller agent --> <partnerLink name="caller" partnerLinkType="tns:Greeter-Caller" myRole="Greeter" /> </partnerLinks> <variables> <!-- holds the incoming message --> <variable name="request" messageType="tns:nameMessage" /> <!-- holds the outgoing message --> <variable name="response" messageType="tns:greetingMessage" /> </variables> <sequence name="MainSeq"> <!-- receive the name of a person --> <receive name="ReceiveName" operation="sayHello" partnerLink="caller" portType="tns:Greeter" variable="request" createInstance="yes" /> <!-- compose a greeting phrase --> <assign name="ComposeGreeting"> <copy> <from expression="concat('Hello, ', bpel:getVariableData('request', 'name'), '!')" /> <to variable="response" part="greeting" /> </copy>

8

</assign> <!-- send greeting back to caller --> <reply name="SendGreeting" operation="sayHello" partnerLink="caller" portType="tns:Greeter" variable="response" /> </sequence> </process>

III. Contoh Implementasi Webservice Untuk Mengetahui Perkiraan Cuaca Di Kota Bandung

Dengan memanfaatkan layanan webservice kita dapat mengetahui perkiraan cuaca di kota Bandung.

Berikut source code yang ditulis dalam bahasa javascript yang lantinya disisipkan pada bahasa HTML :

<script language="javascript"

src="http://tools.tititudorancea.com/weather_forecast.js?place=bandung&s=2&days=7&utf8=no&col

umns=7"> </script>

Ketika aplikasi dijalankan akan menghasilkan informasi sebagai berikut :

Sumber :

1. David Chappell, "Enterprise Service Bus" (O’Reilly: June 2004, ISBN 0-596-00675-6)

2. http://www.information-management.com

3. http://www.ibm.com/developerworks/websphere/techjournal/1105_flurry/1105_flurry.html

4. http://docs.jboss.com/jbpm/bpel/v1.1/userguide/tutorial.hello.html

5. SOA for the Business Developer: Concepts, BPEL, and SCA, ISBN 978-1-58347-065-7