Fitur dan Keunggulan Bus Layanan Perusahaan

E-Jasa – Enterprise Service Bus (ESB) adalah infrastruktur konektivitas fleksibel untuk mengintegrasikan aplikasi dan layanan.

Enterprise Service Bus (ESB) dapat membantu Anda mencapai tujuan SOA. Ini adalah infrastruktur konektivitas fleksibel untuk mengintegrasikan aplikasi dan layanan. Ini adalah inti dari SOA yang memberdayakannya dengan mengurangi jumlah, ukuran, dan kompleksitas antarmuka.

ESB memberdayakan SOA Anda dengan mengurangi ukuran, jumlah, dan kompleksitas antarmuka.

ESB akan melakukan hal-hal berikut antara pemohon dan layanan

1) ROUTING pesan antar layanan
2) MENGUBAH protokol transport antara pemohon dan layanan
3) TRANSFORMASI format pesan antara pemohon dan layanan
4) MENANGANI acara bisnis dari sumber yang berbeda

Bus Layanan Perusahaan memungkinkan kami fokus pada bisnis inti kami.

Keuntungan berikut

1) Tambahkan layanan baru lebih cepat
2) Ubah layanan dengan dampak minimal ke layanan yang ada

Dua persyaratan berikut untuk Enterprise Service BUS

a) Jika semua aplikasi Anda mengonfirmasi standar Layanan Web, maka yang Anda perlukan hanyalah ESB yang berfokus pada integrasi layanan berbasis standar.
b) Jika tidak semua aplikasi Anda sesuai dengan standar layanan web maka Anda mungkin memerlukan ESB yang lebih canggih yang berfokus pada integrasi layanan dengan aset non-layanan yang ada.

Empat poin yang ingin saya soroti pada produk

1) Menyediakan konektivitas layanan Web, JMS Messaging, dan integrasi berorientasi layanan, Bus Layanan WebSphere Enterprise memberikan integrasi cerdas untuk menghubungkan aset Anda melalui antarmuka berorientasi layanan.
2) Kemudahan penggunaan. Alat ini mudah digunakan dan membutuhkan keterampilan pemrograman minimal. Anda tidak perlu mengetahui Java untuk menggunakan alat ini, alat ini terintegrasi, interaktif dan memberikan pengalaman pengembangan visual. Mediasi hanyalah istilah yang digunakan untuk menggambarkan pemrosesan informasi dalam penerbangan. Mudah untuk mengembangkan, membangun, menguji, menyebarkan, dan mengelola komponen layanan. Sampel yang mudah dipahami juga disertakan.
3) Meningkatkan waktu untuk menilai. Solusi hemat biaya ini memiliki dukungan untuk lebih dari ratusan solusi ISV seperti SAP, Siebel, peopleoft, JD Edwards, dan Oracle. Hemat waktu dan biaya pengembangan dengan memanfaatkan mediasi bawaan seperti transformasi XML, perutean berbasis konten, dan logging pesan.
4) Integrasi yang mulus dengan platform Websphere – tidak seperti beberapa pesaing kami, kami memiliki kemampuan untuk dengan mudah naik tumpukan untuk memecahkan masalah bisnis yang lebih kompleks dengan server proses, yang dibangun di WebSphere ESB. Jadi, Anda dapat dengan mudah memperluas untuk memanfaatkan Server Proses WebSphere sesuai kebutuhan. Bus Layanan WebSphere Enterprise dibangun di atas Server Aplikasi WebSphere; Yayasan J2EE kelas dunia yang menyediakan tingkat ketersediaan, skalabilitas, dan kinerja terdepan di industri.

Menyediakan konektivitas Layanan Web, perpesanan dan integrasi berorientasi layanan

– Meningkatkan fleksibilitas melalui adaptasi antarmuka berorientasi layanan
– Dapatkan dukungan untuk berbagai protokol perpesanan termasuk JMS 1.1 untuk mengeksploitasi berbagai transportasi dan beroperasi dengan keluarga WebSphere
– Memanfaatkan berbagai model interaksi untuk memenuhi kebutuhan Anda
– Memanfaatkan dukungan layanan Web canggih untuk menggabungkan kemampuan terdepan
– Manfaatkan paket klien yang komprehensif untuk memperluas lingkungan Anda
– Memanfaatkan UDDI 3.0 untuk deskripsi dan deskripsi yang aman serta penemuan layanan web dengan cara berbasis standar terbuka.
– kurangi berbagi dengan menggunakan WebSphere ESB untuk menangani logika integrasi
– Perutean yang disesuaikan Perutean khusus transportasi / protokol dan perutean berbasis konten
– Percakapan protokol antara berbagai protokol: HTTP, IIOP, JMS
– Format transformasi antar standar: XML, SOAP, pesan JMS dan bila digunakan dengan adaptor, banyak lagi
– Disediakan fungsi mediasi untuk interaksi database
– Izinkan aliran acara bisnis dan tambahkan kecerdasan yang diperlukan ke aliran itu
– Memanfaatkan Adaptor WebSphere untuk menangkap dan menyebarkan acara bisnis

Menghadirkan Bus Layanan Perusahaan yang mudah digunakan
Pengembang Integrasi Websphere menyediakan lingkungan pengembangan yang terintegrasi, interaktif dan visual untuk pengembangan logika integrasi yang cepat, sederhana untuk mengembangkan, membangun, menguji, menyebarkan dan mengelola komponen layanan. Bangun dan jalankan dengan cepat dengan dokumentasi yang komprehensif, sampel yang mudah dipahami. Memberikan pengalaman pengembangan visual dan disederhanakan untuk artefak berbasis standar seperti skema XML, WSDL, XSLT, dll. Mendukung deklarasi layanan dan konektivitas melalui model komposisi visual. Memungkinkan orkestrasi fungsi mediasi yang mudah dengan dukungan kelas satu untuk perutean pesan yang cerdas, pengayaan, dan transformasi. Menawarkan pendekatan perkakas terintegrasi yang mulus untuk menghubungkan antara layanan berorientasi layanan dan layanan berorientasi pesan. Dukungan berbasis peran yang sebenarnya memberikan pengalaman administrasi yang disederhanakan.

WebSphere ESB dirancang agar mudah digunakan

se dari alat dan perspektif runtime. Pengembang Integrasi Websphere, alat yang bekerja dengan WebSphere ESB, dibangun untuk pengembang integrasi – seseorang yang memahami sistem dan arsitektur TI tetapi bukan pengembang Java.

Baik WESB dan WID dirancang untuk membantu pelanggan bangun dan bekerja dengan cepat dan mudah, dengan dokumentasi lengkap dan lingkungan pengembangan visual yang disederhanakan. Model komposisi visual memungkinkan orkestrasi fungsi mediasi dengan mudah. Fakta bahwa alat ini berbasis peran membuat administrasi lebih mudah.

WebSphere ESB Meningkatkan waktu menjadi nilai.

Dapatkan solusi hemat biaya untuk integrasi layanan. Manfaatkan investasi TI SOA Anda dengan membangun infrastruktur integrasi yang fleksibel secara cepat untuk memperluas nilai investasi yang ada, terlepas dari vendornya. Pendekatan modular mendukung kemampuan untuk memulai dari yang kecil dan tumbuh secepat yang dibutuhkan bisnis. Standar bisnis dan TI yang luas mendukung fasilitas interoperabilitas & portabilitas yang lebih besar. Memanfaatkan dukungan kelas satu untuk ratusan solusi ISV. Dukungan Adaptor WebSphere yang luas, termasuk adaptor berbasis JCA baru. Dukungan untuk banyak ISV dalam ekosistem mitra Platform WebSphere.

Hemat waktu dan biaya pengembangan dengan memanfaatkan fungsi mediasi yang telah dibuat sebelumnya. Mediasi beroperasi dalam pesan / peristiwa saat diteruskan antara pemohon layanan dan penyedia layanan. Beroperasi pada interaksi Satu Arah dan Permintaan-Respon. Fungsi mediasi yang dibuat sebelumnya memungkinkan mediasi disusun secara visual dan mencakup transformasi XML, pencatatan pesan, perutean pesan, dan pencarian database, Pelanggan dapat menambah fungsi yang disediakan oleh primitif yang disediakan dengan memprogram ‘primitif khusus’ mereka sendiri. Konfigurasi ulang secara dinamis untuk memenuhi kebutuhan bisnis yang berubah. Runtime WebSphere ESB memberi administrator kemampuan untuk mengkonfigurasi ulang interaksi layanan. Hindari waktu henti sistem dengan menambahkan atau mengganti logika integrasi secara dinamis.

WebSphere ESB Integrasi yang mulus dengan platform WebSphere

Memanfaatkan kualitas layanan WebSphere. Mewarisi runtime WebSphere untuk skalabilitas, pengelompokan, dan fail-over kelas dunia. Memanfaatkan Konsol Administratif WebSphere umum untuk mengaktifkan manajemen sistem di seluruh Server Aplikasi WebSphere. WebSphere ESB, dan WebSphere Process Server. Mengatasi persyaratan keamanan ujung ke ujung pada otentikasi, kontrol akses sumber daya, integritas data, kerahasiaan, privasi, dan interoperabilitas yang aman.

Mudah diperluas untuk memanfaatkan Platform WebSphere sesuai kebutuhan. Pelanggan dengan keterampilan yang tepat dapat memanfaatkan sepenuhnya kemampuan yang mendasari Penyebaran Jaringan Server Aplikasi WebSphere. Perluas fondasi perpesanan MQ WebSphere Anda yang ada untuk mengintegrasikan lingkungan baru dengan cara terbuka dan berbasis standar. Perkakas dan administrasi umum berarti perpindahan dari WebSphere ESB ke WebSphere Process Server tidak menimbulkan rasa sakit.

Terintegrasi dengan keamanan, direktori, dan penawaran manajemen sistem IBM Tivoli. Termasuk Tivoli Access Manager, untuk penggunaan opsional, untuk memberikan pengalaman yang aman, terpadu, dan dipersonalisasi yang akan membantu mengelola pertumbuhan dan kompleksitas. Terintegrasi dengan IBM Tivoli Composite Application Manager untuk SOA untuk kemampuan pemantauan dan manajemen tambahan

Arsitektur Berorientasi Layanan: Triangle of Truth

Segitiga kebenaran adalah cara sederhana untuk melihat konstruksi arsitektur penting yang membentuk arsitektur berorientasi layanan. Ketika Anda mulai memikirkan tentang apa yang dibutuhkan untuk membangun arsitektur berorientasi layanan, tiga serangkai yang membentuk segitiga kebenaran dengan cepat muncul. Secara khusus, perlu ada cara untuk merepresentasikan data yang dipertukarkan antar layanan, harus ada mekanisme pemanggilan layanan, dan harus ada cara untuk menyusun layanan menjadi aplikasi bisnis terintegrasi yang lebih besar.

Saat ini ada banyak model pemrograman yang berbeda untuk mendukung setiap konstruksi dalam segitiga kebenaran. Situasi ini menghadirkan tantangan bagi pengembang untuk tidak hanya perlu memecahkan masalah bisnis tertentu, tetapi mereka juga dihadapkan pada pemilihan dan pemahaman teknologi implementasi yang tepat. Salah satu tujuan penting dari solusi SOA WebSphere Process Server v6 adalah untuk mengurangi kompleksitas ini dengan menggabungkan berbagai model pemrograman yang digunakan untuk mengimplementasikan aplikasi bisnis berorientasi layanan ke dalam model pemrograman yang disederhanakan.

Presentasi ini berfokus secara khusus pada Arsitektur Komponen Layanan (SCA) yang diperkenalkan di WebSphere Process Server v6 sebagai model komponen berorientasi layanan untuk mendefinisikan dan menjalankan layanan bisnis. Selain peran penting SCA dalam menyediakan model permintaan untuk solusi SOA di WebSphere Process Server v6, Anda juga akan belajar dalam presentasi ini bahwa ia juga berperan dalam menyusun layanan bisnis ke dalam aplikasi bisnis gabungan.

Dasar-dasar SCA:

Kapan pun Anda mulai mempelajari teknologi baru atau model pemrograman, sering kali

berguna untuk melihat bagian-bagian yang menyusun arsitektur keseluruhan dari teknologi itu. Slide ini mencantumkan beberapa fitur penting SCA yang harus Anda ketahui saat Anda mulai mempelajari tentang SCA.

Pertama, Service Component Definition Language (SCDL) menyediakan dasar SCA. SCDL adalah bahasa definisi berbasis XML, dan digunakan untuk menentukan semua artefak SCA dalam sebuah proyek. Alat bantu WebSphere Integration Developer V6.0 yang mendukung SCA menangani pembuatan definisi SCDL yang sesuai saat membangun aplikasi berbasis SCA, namun pemahaman dasar dengan SCDL pasti dapat membantu memahami arsitektur keseluruhan dan aplikasi debugging.

Bagian penting berikutnya dari SCA untuk dipahami adalah perbedaan jenis artefak yang dapat didefinisikan menggunakan SCDL. Berbagai jenis artefak yang ada di SCA dirancang untuk mendukung beberapa persyaratan dasar arsitektur berorientasi layanan ini. Untuk memulai, blok penyusun paling dasar dalam SCA adalah definisi komponen layanan. Setelah komponen layanan ditentukan, penting untuk memiliki mekanisme agar layanan tersebut tersedia untuk klien di dalam dan di luar arus.

Gambaran Umum Komponen Layanan:

Ini adalah konsep umum yang akan familiar bagi mereka yang berlatar belakang WPS. SCA pertama kali diperkenalkan dalam konsep WPS V6 sebagai arsitektur dan implementasi untuk mendukung pemberdayaan pendekatan Arsitektur Berorientasi Layanan untuk proses Integrasi. SCA mendukung model pemrograman di WPS dan juga fundamental bagi WESB. Semuanya adalah Layanan Dan Komponen Dan memiliki antarmuka yang menjelaskannya.

SCA memisahkan antarmuka komponen dari implementasinya. Implementasi komponen SCA dapat berubah tanpa mempengaruhi antarmuka. Misalnya, mungkin untuk mengganti implementasi komponen, katakanlah dengan pemanggilan Layanan Web daripada pemanggilan melalui adaptor. Kami memanggil komponen, sehingga SCA dapat dianggap sebagai model pemanggilan sebanyak apapun.

Situasi ini diwakili pada foil berikutnya – kita dapat melihat bahwa Komponen Layanan menyediakan Mesin Virtual Layanan yang dapat dipanggil. Untuk menyediakannya, itu harus memiliki properti Implementasi, Antarmuka, dan Konfigurasi. Poin penting di sini adalah bahwa Implementasi dapat berupa konstruksi pemrograman apa pun yang kami sediakan di WPS. Jadi bisa BSM, Proses BPEL, Peta, Adaptor, POJO.

Antarmuka dapat terdiri dari dua jenis-Antarmuka yang diekspos modul ini untuk dikonsumsi oleh orang lain, dan Antarmuka yang diekspos oleh modul lain yang ingin kita konsumsi. Jenis konsumsi antarmuka yang terakhir ini disebut referensi. Kami juga harus mencatat bahwa antarmuka dapat dijelaskan menggunakan antarmuka Java atau WSDL. Tetapi jika ada beberapa antarmuka yang ditentukan maka Anda tidak dapat mencampur WSDL dengan Java. Untuk tipe referensi, Anda tidak memiliki batasan itu.

Modul Layanan: Gambaran Umum

Di sini kami mendapatkan Service Module kami, yang kami tahu adalah unit pengemasan dan penerapan SCA. Kita dapat melihat bahwa Modul khusus ini berisi 2 Komponen Layanan – masing-masing berisi implementasi, Antarmuka dan referensi jika sesuai. Komponen Layanan kedua ini tidak berisi referensi karena tidak memanggil Layanan eksternal apa pun.

Sekarang di Service Module kita dapat melihat bahwa kita memiliki sejumlah hal tambahan, yang berhubungan dengan Antarmuka masuk dan keluar di Tingkat Modul. Ingatlah bahwa Antarmuka dan referensi menjelaskan antarmuka masuk dan keluar di tingkat Komponen Layanan. Kami memiliki notasi serupa di tingkat Modul Layanan, yang disebut sebagai impor, Ekspor, dan referensi Standalone.

Ekspor adalah cara Service Module memaparkan antarmukanya ke dunia luar untuk dikonsumsi oleh Komponen Layanan lain dalam Service Module yang berbeda. Referensi Standalone adalah bagaimana Service Module mengekspos antarmukanya untuk dikonsumsi menggunakan mekanisme permintaan klien non-SCA. Klien yang menggunakan mode pemanggilan ini adalah komponen SCA lain dalam modul SCA yang sama, atau klien non SCA seperti JSP. Impor adalah bagaimana Komponen Layanan memanggil Layanan eksternal. Hubungan atau jalur pemanggilan potensial antara artefak ini diwakili oleh kabel.

Dasar-dasar dan terminologi SCA

SCA adalah runtime yang memfasilitasi abstraksi implementasi komponen
SCA memisahkan infrastruktur dari Business Logic
Berikan model pemrograman untuk pemanggilan
Mendukung berbagai model doa
Menyediakan infrastruktur runtime yang sesuai untuk konsumsi aplikasi

Model universal untuk Layanan Bisnis, Menerbitkan atau mengoperasikan data bisnis. Service Data Objects (SDO) menyediakan model universal untuk “data bisnis”. Komponen dijalankan pada run-time berkemampuan SCA, antarmuka Java (tipe-j), tipe port WSDL tipe9w). Argumen dan pengembalian dijelaskan menggunakan SDO, kelas Java, atau tipe Java sederhana. SCA fokus pada tujuan bisnis.

Objek data layanan dan Objek Bisnis
Seperti yang sudah diperkenalkan di segitiga kebenaran, bu

objek siness memainkan peran penting dalam solusi SOA WebSphere Process Server v6 sebagai abstraksi data. Ini memang merupakan tujuan penting dari kerangka objek bisnis, tetapi selain itu, kerangka objek bisnis juga menyediakan beberapa fungsi penting lainnya. Secara khusus, kerangka objek bisnis dikembangkan untuk memberikan kemampuan fungsional yang mirip dengan konstruksi objek bisnis yang ditemukan di WebSphere Interchange Server (ICS). Serangkaian kemampuan yang telah diadopsi untuk mendukung fungsi objek bisnis gaya ICS, diperlukan untuk menyediakan cara untuk membantu pengembang mengurangi kerumitan yang terkait dengan pengembangan aplikasi yang bekerja dengan data bisnis federasi dan berbeda seperti yang umumnya terjadi pada aplikasi perusahaan yang terintegrasi.

SCA memberikan kemampuan untuk layanan yang akan dipanggil secara sinkron atau asinkron.
Model pemanggilan asinkron juga disediakan dengan semantik berikut
One Way -Fire and Forget
Tanggapan Tertunda-Dalam model ini klien membuat permintaan, tetapi tidak memblokir, tetapi di beberapa waktu kemudian kembali dan meminta tanggapan. Dalam bentuk pemanggilan ini mengambil parameter kedua yang menentukan apakah pemanggilan berperilaku ketika respons tidak segera tersedia. (invoke Async () mengembalikan tiket yang mengidentifikasi pemanggilan. invokeResponse () meneruskan tiket yang digunakan untuk mendapatkan respons yang sesuai dengan pemanggilan yang diidentifikasi oleh tiket)

Semantik pemanggilan sinkron vs asinkron berbeda seperti yang dirangkum di sini. Jadi pemanggilan sinkron adalah pass-by-reference, sedangkan pemanggilan asynchronous adalah pass-by-value. Perhatikan juga bahwa jika Anda menginginkan keamanan tipe, Anda harus menggunakan definisi antarmuka Java. Namun ada perkakas untuk memungkinkan Anda menghasilkan antarmuka Java dari definisi WSDL. Panggilan sinkron di luar JVM adalah pemanggilan nilai demi nilai. Kita bisa menggunakan kolom tambahan di bagan ini.

Arsitektur referensi bus layanan perusahaan
Kami akan memperkenalkan semua elemen ini nanti dalam presentasi. Mari kita lihat cakupan WSEB dan semua hal yang didapatkan pelanggan di dalam kotak. Produk ini bernama ESB bukan Enterprise Service Bus. Penamaan tersebut mencerminkan pola pikir industri. Hal ini memungkinkan ESB untuk dibangun yang permintaan dan tanggapan layanan broker. Ini terutama merupakan platform berfokus Layanan Web khusus untuk mendukung interaksi layanan yang berlangsung dalam SOA. ESB dibangun di atas AS (ND) dan oleh karena itu pada dasarnya adalah platform J2EE. Ini memanfaatkan dan berbagi teknologi yang diperkenalkan dengan WAS V6 dan WPS. Penggunaan produk dan kemampuan tambahan yang ditampilkan (misalnya, TAM) bersifat opsional.

Memperkenalkan konsep “mediasi” sebagai istilah untuk pemrosesan pesan (perantara). Permintaan layanan adalah pesan Layanan dalam ESB. Versi baru WID dirilis yang mendukung pengembangan aliran mediasi. ESB mendukung aliran mediasi dan primitif yang digunakan untuk membangun pemrosesan mediasi. Dukungan untuk pemrosesan ESB dasar disediakan. WESB memanfaatkan dukungan perpesanan yang dikirimkan dalam WAS V6 (SIB) menggunakan penyedia JMS 1.1 dan MQLink untuk beroperasi dengan MQ QM. Dukungan WS sekali lagi memanfaatkan dukungan AS basis SOAP / HTTP dan SOAP / JMS sebagai protokol dan berbagai kemampuan WS- *. SCA (define) adalah model pemrograman yang merupakan teknologi yang pertama kali muncul, dan dibagikan dengan WPS. Ini adalah fondasi untuk komposisi mediasi dan logika proses. SDO (define) memungkinkan representasi logis dari data bisnis. SMO (definisikan) adalah perpanjangan dari pesan SDO yang merupakan pesan layanan yang mengalir melalui ESB. Klien XMS (C ++ dan .Net). Permintaan klien JAX / RPC didukung melalui klien WS C / C ++. Konektivitas ke titik akhir lain dicapai dengan menggunakan Adaptor WBI (baik adaptor asli atau varian yang mendukung JCA 1.5).

Dalam arsitektur SOA yang digabungkan secara longgar, pemohon dan penyedia Layanan terhubung satu sama lain melalui Bus Layanan Perusahaan. Layanan yang digabungkan secara longgar memberikan lebih banyak fleksibilitas dan kemampuan untuk memperkenalkan mediasi dan QOS yang kemudian dapat diterapkan secara seragam ke layanan yang terhubung melalui bus. Layanan mediasi mencegat dan mengubah pesan yang diteruskan antara layanan yang ada (penyedia) dan klien (pemohon) yang ingin menggunakan layanan tersebut. Layanan mediasi diimplementasikan menggunakan modul mediasi yang berisi aliran mediasi. WebSphere ESB dan Process Server menyediakan kemampuan ESB melalui penggunaan Modul Mediasi yang ditempatkan di server. Modul Mediasi menggunakan arsitektur komponen Layanan (SCA) yang sama yang diperkenalkan di WebSphere Integration Developer V6.0.0 dan WebSphere Process Server V6.0.0

Konsep ESB: Modul Medisi

WebSphere ESB dan Process Server memperkenalkan jenis modul baru, yang disebut Modul Mediasi, yang mencegat dan mengubah pesan antara pemohon layanan dan penyedia layanan. Modul mediasi menyediakan fungsi ESB untuk mengubah protokol, perutean, transformasi, dan kustom lainnya

memproses pesan. Modul Mediasi adalah unit penerapan dan berjalan dalam WebSphere ESB atau Process Server. Interaksi dengan penyedia dan pemohon layanan eksternal yang ditentukan oleh impor dan ekspor, yang antarmukanya ditentukan menggunakan WSDL.

Jenis modul baru diperkenalkan di WebSphere ESB dan Server Proses, yang disebut Modul Mediasi, menyediakan fungsionalitas ESB dengan memungkinkan pemrosesan pesan antara pemohon layanan dan penyedia. Hal ini memungkinkan konektivitas dan layanan mediasi yang digabungkan secara longgar antara pemohon layanan yang berbeda dan menyediakan koneksi melalui bus. Modul Mediasi memungkinkan konversi protokol, perutean, transformasi, dan pemrosesan kustom lainnya pada pesan, yang biasanya dibutuhkan dalam lingkungan ESB. WebSphere Process Server mendukung modul bisnis yang digunakan untuk pemrosesan bisnis dan modul mediasi baru, sedangkan WebSphere ESB mendukung modul mediasi. Pemohon layanan berinteraksi dengan modul mediasi di bus melalui ekspor modul, dan modul berinteraksi dengan penyedia layanan melalui impor modul. Antarmuka ekspor dan impor ini ditentukan menggunakan WSDL.

Modul Mediasi: Impor dan Ekspor binding

Jenis interaksi pemohon dan penyedia yang berbeda tersedia melalui binding yang berbeda untuk impor dan ekspor. WebSphere ESB menyediakan dukungan untuk JMS binding- JMS 1.1 yang disediakan oleh platform WebSphere. Messaging dapat memanfaatkan berbagai transport TCP / IP, SSL, HTTP (S). Memungkinkan interaksi dengan keluarga WebSphere WAS, WebSphere MQ, WebSphere Message Broker. Layanan Web mengikat SOAP / HTTP, SOAP / JMS, WSDL 1.1, Registry Layanan -UDDI 3.0, WS-Security, WS-Automatic Transactions. Adaptor WebSphere mengikat Adaptor JCA -SAP, PeopleSoft, Sibel, Files, JDBC, WBI Adapters untuk yang lainnya. Pengikatan SCA (Default) bawaan Digunakan untuk komunikasi modul ke modul-mendukung komunikasi sinkron dan asinkron. WebSphere ESB mendukung pembaruan pengikatan ini melalui konsol admin yang memungkinkan konektivitas modul ke modul diubah.

Interaksi dengan penyedia dan pemohon layanan eksternal ditentukan oleh impor dan ekspor. Antarmuka impor / ekspor ditentukan menggunakan Web Services Description Language (WSDL), yang mungkin berisi beberapa operasi layanan. Jenis pemohon dan penyedia yang berbeda tersedia melalui binding yang berbeda untuk impor dan ekspor. WebSphere ESB dan Process Server v6.0.1 mendukung pengikatan JMS, pengikatan WebServices, pengikatan Adaptor WebSphere dan pengikatan SCA bawaan bawaan. Binding berbeda ini memungkinkan fleksibilitas maksimum bagi pemohon dan penyedia untuk menggunakan protokol pilihan mereka. Penggunaan binding yang berbeda memungkinkan transformasi protokol yang mudah antara pemohon layanan dan penyedia. Binding impor dan Ekspor sama seperti yang digunakan untuk modul Bisnis di WebSphere Process Server.

Komponen aliran mediasi dan interaksi Permintaan-Respon

Modul mediasi berisi komponen SCA tipe baru, yang disebut Komponen Alur Mediasi. Mediation Flow Components bertindak sebagai ‘perantara layanan’ untuk meneruskan permintaan 9 yang berpotensi diubah) dari pemohon layanan ke penyedia layanan, meneruskan respons (yang berpotensi diubah) dari penyedia layanan ke pemohon layanan. Pemrosesan permintaan dipisahkan dari pemrosesan tanggapan dalam komponen aliran mediasi. Pemrosesan permintaan dalam komponen aliran mediasi dapat mengirim respons kembali ke pemohon tanpa perlu menghubungi penyedia layanan.

Modul Mediasi berisi komponen SCA baru yang disebut komponen aliran Mediasi yang bertindak sebagai perantara layanan untuk pemrosesan pesan. Komponen aliran Mediasi menyediakan cara standar untuk memproses pesan secara independen dari protokol pengikatan yang digunakan oleh penyedia atau pemohon layanan. Ini mendukung model satu arah di mana tidak ada respons yang diharapkan atau model permintaan dan respons 2 arah. Ini mendukung model pemanggilan sinkron atau asinkron, mirip dengan komponen SCA lainnya. Dalam komponen aliran Mediasi, pemrosesan pesan permintaan dilakukan secara terpisah dari pesan respons. Hal ini memungkinkan pemrosesan pesan permintaan yang berbeda dilakukan secara terpisah dari pesan respons. Hal ini memungkinkan pemrosesan yang berbeda terjadi pada sisi permintaan dan respons dengan memiliki primitif mediasi yang berbeda pada aliran permintaan dan respons.

Pengembang aplikasi mediasi dapat memilih untuk membuat dan menangani respons dalam komponen aliran mediasi tanpa benar-benar memanggil penyedia layanan. Pengembang Modul Mediasi perlu membuat pesan tanggapan berdasarkan definisi antarmuka dari ekspor modul.

Modul Mediasi: Isi
Modul Mediasi dapat memiliki yang berikut: Ekspor, ditentukan menggunakan WSDL yang mengekspos modul mediasi ke pemohon layanan eksternal. Impor, ditentukan menggunakan WSDL, yang mengidentifikasi penyedia layanan eksternal dan antarmukanya. Jenis baru dari komponen SCA disebut, Med

komponen aliran iation- ini menyediakan fungsi mediasi pada pesan antara pemohon layanan dan penyedia ini. Dalam kasus di mana satu-satunya kebutuhan adalah mengubah pesan dari satu protokol interaksi ke yang lain, mungkin tidak diperlukan komponen aliran mediasi dalam modul. Komponen Java SCA opsional-ini digunakan sehubungan dengan mediasi khusus primitif atau ketika ada kebutuhan untuk menggunakan antarmuka Java.

Modul mediasi berisi ekspor, impor, jenis komponen SCA baru yang disebut komponen aliran Mediasi dan secara opsional komponen jenis SCA lainnya. Impor Mediasi seperti impor SCA normal dengan semua binding yang didukung, yaitu, SCA Default, JMS, Layanan Web. Impor adalah titik masuk ke dalam Bus. Demikian pula, Mediation Exports seperti ekspor SCA normal dengan semua binding yang didukung, yaitu Default SCA, JMS, Web Services. Ekspor adalah titik keluar dari Bus. Jenis baru dari komponen SCA, disebut komponen Mediation Flow, berisi logika bagaimana pesan diproses antara input dan output aliran. Fungsi seperti perutean pesan, transformasi, augmentasi, logging, atau pemrosesan kustom lainnya dilakukan pada pesan dalam komponen Alur Mediasi. Terakhir, modul secara opsional dapat berisi komponen Java SCA, yang digunakan untuk mengimplementasikan primitif mediasi kustom. Lebih lanjut tentang ini nanti di presentasi.

Mediation Flow editior digunakan untuk menyediakan implementasi komponen mediasi yang digunakan untuk memproses aliran pesan saat mengalir dari pemohon layanan ke penyedia melalui bus Enterprise Service. Editor berisi 3 bagian. Yang teratas adalah bagian Mediasi Operasi yang digunakan untuk menentukan pemetaan operasi input sumber ke satu atau beberapa operasi output target. Peta dibuat dengan menghubungkan operasi input secara visual ke operasi target keluar yang sesuai. Setelah koneksi dibuat antara operasi sumber dan target, bagian tengah yang disebut bagian Alur Mediasi digunakan untuk membuat aliran pemrosesan pesan. Mediasi Primitif ditambahkan di sini dan disambungkan untuk membuat aliran pesan antara operasi input dan output. Bagian paling bawah dari editor adalah bagian properti mediasi untuk melihat atau mengubah properti koneksi, primitif yang disorot di bagian aliran mediasi.

Metodologi desain komponen aliran mediasi.
Dua jenis metodologi desain

Desain dari atas ke bawah
Pengembang membuat dengan komponen Aliran Mediasi dengan antarmuka dan referensi yang diperlukan. Pengembang membuat implementasi (kosong) untuk komponen Flow. Ini akan membuka editor komponen Mediation Flow. Menggunakan Editor Alur Mediasi, pengembang membuat pemetaan dari operasi sumber ke satu atau beberapa operasi target.

Desain bottom-up
Pengguna memulai dengan implementasi aktual dari komponen aliran belum memiliki komponen Alur Mediasi. Komponen aliran mediasi kemudian digunakan untuk merakit modul. Pendekatan ini dapat digunakan untuk memodifikasi desain yang ada dan kemudian menggabungkan implementasi komponen aliran.

WebSphere ESB menyediakan beberapa primitif mediasi built-in dan memungkinkan kemampuan untuk menambahkan mediasi kustom Anda sendiri untuk kasus-kasus yang dicatat oleh primitif mediasi built-in. Mengikuti primitif mediasi built-in disediakan.

1. Message Logger digunakan untuk mencatat / menyimpan informasi pesan ke database.

2. Filter Pesan untuk memfilter pesan yang secara selektif meneruskannya ke terminal keluaran, berdasarkan ekspresi kondisi sederhana.

3. Pencarian database untuk mengakses informasi dalam database dan memasukkannya ke dalam pesan. Primitif mediasi dilengkapi dengan id kunci untuk dicari dan di mana dalam pesannya terdapat nilai kunci. Dengan menggunakan dua informasi tersebut, nilai kolom yang ditentukan untuk kunci yang cocok dimasukkan ke lokasi yang ditentukan dalam pesan.

4. XSL Transformasi mediasi primitif digunakan untuk mengubah pesan menggunakan transformasi XSL. Ini terutama digunakan ketika penyedia target memiliki antarmuka yang berbeda dari antarmuka pesan masuk. Menggunakan pemetaan dalam XSLT, seseorang dapat memetakan nilai input ke bidang output yang sesuai.

5. Hentikan mediasi primitif yang digunakan untuk menghentikan aliran eksekusi.

6. Gagal mediasi primitif digunakan untuk kondisi kesalahan, di mana eksekusi aliran dihentikan dan pengecualian dibuat.

Primitif mediasi kustom digunakan untuk melakukan pemrosesan pesan yang tidak tercakup oleh primitif ediasi lain dengan menjalankan logika kustom. Custom Mediation Primitive memanggil komponen Java SCA yang Anda buat atau sediakan. Komponen Java SCA harus berada dalam modul Mediasi yang sama.