BPEL: Komposisi layanan untuk SOA

BPEL (Business Process Execution Language) telah menjadi salah satu teknologi terpenting dari SOA (arsitektur berorientasi layanan) dan memungkinkan komposisi layanan yang mudah dan fleksibel ke dalam proses bisnis. BPEL sangat penting karena ini memperkenalkan konsep baru ke dalam pengembangan aplikasi — pemrograman-dalam-besar. Konsep ini memungkinkan kami untuk mengembangkan proses dengan cepat dengan menentukan urutan layanan yang akan dipanggil. Dengan cara ini, aplikasi (dan sistem informasi) menjadi lebih fleksibel dan dapat beradaptasi lebih baik dengan perubahan dalam proses bisnis.

Proses bisnis biasanya bersifat dinamis. Perusahaan harus memperbaiki dan memodifikasi, bertindak secara gesit, mengoptimalkan, dan menyesuaikan proses untuk meningkatkan daya tanggap seluruh perusahaan. Setiap perubahan dan peningkatan dalam proses bisnis harus tercermin dalam aplikasi yang memberikan dukungan untuk mereka. Meskipun persyaratan ini kedengarannya tidak terlalu sulit untuk dipenuhi, situasi dunia nyata memperlihatkan kepada kita gambaran yang berbeda. Mengubah dan memodifikasi aplikasi seringkali merupakan pekerjaan yang sulit, yang membutuhkan waktu. Oleh karena itu, aplikasi tidak dapat bereaksi secara instan terhadap perubahan dalam proses bisnis — sebaliknya, aplikasi memerlukan waktu untuk mengimplementasikan, menguji, dan menerapkan modifikasi.

Membuat sistem informasi lebih fleksibel dan mudah beradaptasi terhadap perubahan, dan lebih selaras dengan proses bisnis adalah janji utama SOA. Dalam artikel ini, saya menunjukkan mengapa BPEL sangat penting dan mendemonstrasikan bagaimana mengembangkan proses BPEL.

Pendekatan berorientasi layanan

Pendekatan SOA untuk otomatisasi proses bisnis yang efisien memerlukan:

  • Cara standar untuk mengekspos dan mengakses fungsionalitas aplikasi sebagai layanan
  • Infrastruktur bus perusahaan untuk komunikasi dan manajemen layanan, termasuk intersepsi pesan, perutean, transformasi, dll.
  • Bahasa khusus untuk komposisi fungsionalitas aplikasi yang terbuka ke dalam proses bisnis

Persyaratan pertama dipenuhi oleh arsitektur terdistribusi terbaru — layanan Web. Persyaratan kedua dipenuhi oleh ESB (bus layanan perusahaan), yang memberikan dukungan untuk manajemen layanan dan komunikasinya yang terpusat, deklaratif, dan terkoordinasi dengan baik. Persyaratan ketiga, komposisi layanan ke dalam proses, dipenuhi oleh BPEL, bahasa khusus yang diterima secara umum untuk definisi dan pelaksanaan proses bisnis.

Proses bisnis, seperti yang dilihat oleh BPEL, adalah kumpulan permintaan layanan terkoordinasi dan aktivitas terkait yang menghasilkan hasil, baik dalam satu organisasi atau di beberapa. Misalnya, proses bisnis untuk merencanakan perjalanan bisnis akan memerlukan beberapa layanan. Dalam skenario yang terlalu disederhanakan, proses bisnis akan meminta kami untuk menentukan nama karyawan, tujuan, tanggal, dan detail perjalanan lainnya. Kemudian proses tersebut akan memanggil layanan Web untuk memeriksa status karyawan. Berdasarkan status karyawan, akan dipilih kelas perjalanan yang sesuai. Kemudian akan meminta layanan Web dari beberapa perusahaan penerbangan (seperti American Airlines, Delta Airlines, dll.) Untuk memeriksa harga tiket pesawat dan membeli yang paling murah.

Untuk klien, proses BPEL akan menampilkan fungsinya dengan cara yang sama seperti layanan Web lainnya. Dari perspektif klien, ini akan terlihat persis seperti layanan Web lainnya. Ini penting dan berguna, karena memungkinkan kami menyusun layanan menjadi proses sederhana, proses sederhana menjadi proses yang lebih kompleks, dan sebagainya. Ini juga berarti bahwa setiap proses BPEL akan dijelaskan dengan deskripsi WSDL (Bahasa Deskripsi Layanan Web).

Konsep inti

BPEL adalah bahasa berbasis XML. Proses BPEL terdiri dari beberapa langkah. Setiap langkah disebut aktivitas. BPEL mendukung aktivitas primitif dan struktur. Aktivitas primitif merepresentasikan konstruksi dasar dan digunakan untuk tugas umum, seperti yang tercantum di bawah ini:

  • Memanggil layanan Web, menggunakan
  • Menunggu permintaan tersebut, menggunakan
  • Memanipulasi variabel data, menggunakan
  • Menunjukkan kesalahan dan pengecualian, penggunaan , dll.

Kami kemudian dapat menggabungkan aktivitas ini ke dalam algoritme yang lebih kompleks yang menentukan langkah-langkah proses bisnis. Untuk menggabungkan aktivitas primitif, BPEL mendukung beberapa aktivitas struktur. Yang terpenting adalah:

  • Sequence ( ) untuk menentukan sekumpulan aktivitas yang akan dipanggil dalam urutan berurutan
  • Flow ( ) untuk menentukan sekumpulan aktivitas yang akan dipanggil secara paralel
  • Konstruksi case-switch ( ) untuk mengimplementasikan cabang
  • While ( ) untuk menentukan loop, dll.

Seperti yang akan kita lihat, BPEL tidak jauh berbeda dengan bahasa pemrograman, seperti Java. Tetapi kita akan melihat bahwa BPEL berbeda dari Java dan mendukung karakteristik proses bisnis. BPEL juga menyediakan penangan kesalahan dan kompensasi, penangan kejadian, dan set korelasi. Ini menyediakan sarana untuk mengekspresikan aliran paralel yang kompleks. Itu juga membuatnya relatif mudah untuk memanggil operasi asynchronous dan menunggu callback.

Proses BPEL membutuhkan lingkungan runtime — server BPEL, yang memberi kita kendali yang baik atas eksekusinya. Biasanya, server BPEL menyediakan kontrol atas contoh proses yang sedang dijalankan dan yang telah selesai. Mereka mendukung proses yang berjalan lama dan dapat mengeringkan status proses untuk menghemat sumber daya. Beberapa server memberikan kontrol atas aktivitas proses dan memungkinkan pemantauannya. Terakhir, menggunakan server BPEL, semua proses kami diterapkan secara terpusat, yang menyederhanakan pemeliharaan. Semua ini menjadikan server BPEL lingkungan pilihan untuk menjalankan dan mengelola proses.

Namun, memilih server BPEL yang tepat bisa jadi cukup sulit, karena ada beberapa pilihan. Beberapa server BPEL paling populer yang didasarkan pada Java EE (nama baru Sun untuk J2EE) termasuk Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration, dan AquaLogic. Ada juga setidaknya empat server BPEL open source yang tersedia: ActiveBPEL Engine, FiveSight PXE, bexee, dan Apache Agila.

Contoh proses

Sekarang mari kita lihat contoh proses BPEL untuk perjalanan bisnis yang telah kami jelaskan di atas. Kami akan mengembangkan proses asinkron yang akan menggunakan panggilan sinkron untuk memeriksa status perjalanan karyawan dan dua panggilan asinkron untuk mendapatkan harga tiket pesawat. Gambar di bawah ini menunjukkan keseluruhan struktur proses kami. Di sebelah kiri, kita melihat klien yang memanggil proses tersebut. Proses pertama memanggil layanan Web status perjalanan karyawan. Kemudian memanggil layanan Web kedua maskapai secara bersamaan dan tidak sinkron. Ini berarti bahwa proses tersebut harus menerapkan operasi panggilan balik (dan jenis port), di mana maskapai penerbangan akan mengembalikan konfirmasi tiket penerbangan. Akhirnya, proses mengembalikan penawaran tiket pesawat terbaik kepada klien. Dalam contoh ini, untuk menjaga kesederhanaan, kami tidak akan menerapkan penanganan kesalahan apa pun,yang sangat penting dalam skenario dunia nyata.

Sekarang mari kita tulis kode BPEL. Kita mulai dengan deklarasi proses — elemen root, tempat kita mendefinisikan nama proses dan ruang nama:

Selanjutnya, kita harus menentukan tautan mitra. Tautan mitra menentukan berbagai pihak yang berinteraksi dengan proses BPEL. Ini termasuk semua layanan Web yang akan dipanggil dan klien proses. Setiap tautan mitra menentukan hingga dua atribut: myRoleyang menunjukkan peran proses bisnis itu sendiri dan partnerRoleyang menunjukkan peran mitra. Dalam contoh kami, kami mendefinisikan empat tautan mitra:

Untuk menyimpan pesan dan untuk memformat ulang serta mengubahnya, kita membutuhkan variabel. Biasanya kami menggunakan variabel untuk setiap pesan yang dikirim ke layanan Web dan diterima dari mereka. Dalam contoh kita, kita membutuhkan beberapa variabel. Untuk setiap variabel, kita harus menentukan tipenya. Kita bisa menggunakan tipe pesan WSDL, tipe sederhana XML Schema, atau elemen XML Schema. Dalam contoh kami, kami menggunakan jenis pesan WSDL untuk semua variabel:

Sekarang kita siap untuk menulis badan proses utama. Ini hanya berisi satu aktivitas tingkat atas. Biasanya, ini memungkinkan kita untuk menentukan beberapa aktivitas yang akan dilakukan secara berurutan. Dalam urutan tersebut, pertama-tama kita tentukan pesan masukan yang memulai proses bisnis. Kami melakukan ini dengan konstruksi, yang menunggu pesan yang cocok. Dalam kasus kami, inilah TravelRequestpesannya. Di dalam konstruksi, kami tidak menentukan pesan secara langsung. Sebaliknya, kami menetapkan tautan mitra, jenis port, nama operasi, dan, secara opsional, variabel yang menyimpan pesan yang diterima untuk operasi konsekuen. Kami menghubungkan penerimaan pesan dengan mitra klien dan menunggu TravelApprovaloperasi dipanggil pada tipe port TravelApprovalPT. Kami menyimpan pesan yang diterima diTravelRequest variabel:

Selanjutnya, kita perlu menjalankan layanan Web Status Perjalanan Karyawan. Sebelum ini, kita harus menyiapkan masukan untuk layanan Web ini. Kita dapat membuat pesan seperti itu dengan menyalin bagian karyawan dari pesan yang dikirim klien. Sekarang kami dapat menjalankan layanan Web Status Perjalanan Karyawan. Kami membuat pemanggilan sinkron, yang kami gunakan aktivitasnya. Kami menggunakan employeeTravelStatustautan mitra dan menjalankan EmployeeTravelStatusoperasi pada EmployeeTravelStatusPTtipe port. Kami telah menyiapkan pesan masukan dalam EmployeeTravelStatusRequestvariabel. Karena ini adalah pemanggilan sinkron, panggilan menunggu balasan dan menyimpannya dalam EmployeeTravelStatusResponsevariabel:

Langkah selanjutnya adalah mengaktifkan kedua layanan Web maskapai. Sekali lagi, pertama-tama kami menyiapkan pesan masukan yang diperlukan (yang sama untuk kedua layanan Web). Kami akan membuat pemanggilan asinkron secara bersamaan. Untuk mengekspresikan konkurensi, BPEL menyediakan aktivitas. Pemanggilan ke setiap layanan Web akan terdiri dari dua langkah:

  1. The aktivitas digunakan untuk doa asynchronous
  2. The aktivitas digunakan untuk menunggu callback

Kami biasa mengelompokkan kedua aktivitas tersebut. Kedua pemanggilan hanya berbeda pada nama tautan mitra. Kami menggunakan AmericanAirlinesuntuk satu dan DeltaAirlinesuntuk yang lain:

...