Komponen Messaging and Integration (Perpesanan dan Integrasi)
1. Antrean (Queue)
Mengantre adalah ide sederhana: Satu aplikasi menempatkan pesan dalam antrian, dan pesan itu akhirnya dibaca oleh aplikasi lain. Jika aplikasi Anda hanya membutuhkan layanan sederhana ini, Antrean Azure mungkin menjadi pilihan terbaik.
Karena cara Azure tumbuh dari waktu ke waktu, Antrean Penyimpanan Azure dan Antrian Bus Layanan menyediakan layanan antrian serupa. Alasan mengapa Anda ingin menggunakan salah satu dari yang lain dibahas dalam makalah yang cukup teknis. Dalam banyak skenario, baik akan berhasil.
Skenario Antrian (Queue Scenarios)
Salah satu penggunaan antrian yang umum saat ini adalah membiarkan instance peran web berkomunikasi dengan instance peran pekerja dalam aplikasi Layanan Cloud yang sama.
Misalnya, Anda membuat aplikasi Azure untuk berbagi video. Aplikasi ini terdiri dari kode PHP yang berjalan di peran web yang memungkinkan pengguna mengunggah dan menonton video, bersama dengan peran pekerja yang diimplementasikan dalam C # yang menerjemahkan video yang diunggah ke dalam berbagai format.
Ketika contoh peran web mendapatkan video baru dari pengguna, itu dapat menyimpan video dalam Blob, lalu mengirim pesan ke peran pekerja melalui antrean yang memberitahukan di mana untuk menemukan video baru ini. Contoh peran pekerja tidak masalah mana yang kemudian akan membaca pesan dari antrean dan melakukan terjemahan video yang diperlukan di latar belakang.
Menata aplikasi dengan cara ini memungkinkan pemrosesan asinkron, dan itu juga membuat aplikasi lebih mudah untuk skala, karena jumlah instance peran web dan contoh peran pekerja dapat bervariasi secara independen. Anda juga dapat menggunakan ukuran antrian sebagai pemicu untuk menskalakan jumlah peran pekerja ke atas dan ke bawah. Terlalu tinggi, dan Anda menambahkan lebih banyak peran. Ketika semakin rendah, Anda dapat mengurangi jumlah menjalankan peran untuk menghemat uang.
Anda dapat menggunakan pola yang sama ini di antara berbagai bagian aplikasi Anda meskipun mereka tidak menggunakan peran web dan pekerja. Hal ini memungkinkan Anda untuk menskalakan bagian-bagian di kedua sisi antrean naik dan turun sesuai permintaan dan waktu pemrosesan.
2. Bus Layanan (Sevice Bus)
Apakah mereka berjalan di cloud, di pusat data Anda, di perangkat seluler, atau di tempat lain, aplikasi perlu berinteraksi. Tujuan dari Azure Service Bus adalah membiarkan aplikasi berjalan cukup banyak di mana saja bertukar data.
Relay Bus Layanan (Service Bus Relay)
Bus Servis memungkinkan komunikasi langsung melalui layanan relai, menyediakan cara aman untuk berinteraksi melalui firewall. Relai Bus Layanan memungkinkan aplikasi untuk berkomunikasi dengan bertukar pesan melalui titik akhir yang dihosting di cloud, bukan secara lokal.
Skenario Relay Bus Layanan (Service Bus Relay Scenarios)
Aplikasi yang berkomunikasi melalui Service Bus mungkin aplikasi atau perangkat lunak Azure yang berjalan di beberapa platform cloud lainnya. Mereka juga bisa menjadi aplikasi yang berjalan di luar cloud. Misalnya, pikirkan maskapai penerbangan yang mengimplementasikan layanan reservasi di komputer di dalam Datacenternya sendiri. Maskapai penerbangan perlu mengekspos layanan ini kepada banyak klien, termasuk kios check-in di bandara, terminal agen pemesanan, dan bahkan telepon pelanggan. Mungkin menggunakan Bus Layanan untuk melakukan ini, menciptakan interaksi yang digabungkan secara longgar di antara berbagai aplikasi.
Topik dan Langganan Bus Layanan (Service Bus Topic and Subscriptions)
Service Bus menyediakan mekanisme Publish-and-subscribe yang disebut Topik dan Langganan. Dengan mempublikasikan-berlangganan, aplikasi dapat mengirim pesan ke suatu topik, sementara aplikasi lain dapat membuat langganan ke topik ini. Ini memungkinkan komunikasi satu-ke-banyak di antara sekumpulan aplikasi, membiarkan pesan yang sama dibaca oleh banyak penerima.
Skenario Topik dan Langganan Bus Layanan
Kapanpun Anda sedang mengatur di mana ada banyak pesan yang semuanya penting, tetapi berbagai sistem hilir hanya perlu mendengarkan sub-bagian yang berbeda dari komunikasi tersebut, Topik Bus Layanan dan Langganan adalah opsi yang baik.
3. Layanan BizTalk (Service BizTalk)
Terkadang Anda perlu menghubungkan sistem yang berkomunikasi menggunakan berbagai format perpesanan. Sudah umum bagi bisnis untuk memiliki skema basis data dan format perpesanan XML yang berbeda, bahkan ketika standar umum tersedia. Daripada menulis banyak kode khusus, Anda dapat menggunakan BizTalk Server di tempat untuk mengintegrasikan berbagai sistem. Layanan Azure BizTalk menyediakan jenis layanan yang sama tetapi di cloud. Anda hanya dapat membayar apa yang Anda gunakan dan tidak khawatir tentang skala seperti yang Anda lakukan di tempat.
Skenario Layanan BizTalk (BizTalk Services Scenarios)
Interaksi Business-to-Business (B2B) umumnya membutuhkan jenis terjemahan ini. Misalnya, perusahaan yang membangun pesawat perlu memesan komponen dari berbagai pemasok komponennya. Ini akan memiliki banyak pemasok komponen. Pesanan tersebut harus otomatis untuk langsung dari sistem pembangun pesawat ke sistem pemasok. Baik bisnis tidak ingin mengubah sistem inti dan format pesan mereka, dan sangat tidak mungkin format tersebut sama. Layanan BizTalk dapat mengambil pesan dan menerjemahkan antara format baru dua arah. Baik pemasok pesawat dapat melakukan pekerjaan untuk menerjemahkan atau berbagai pemasok dapat, tergantung pada siapa yang ingin lebih banyak kontrol dan jumlah terjemahan yang dibutuhkan.
Mengantre adalah ide sederhana: Satu aplikasi menempatkan pesan dalam antrian, dan pesan itu akhirnya dibaca oleh aplikasi lain. Jika aplikasi Anda hanya membutuhkan layanan sederhana ini, Antrean Azure mungkin menjadi pilihan terbaik.
Karena cara Azure tumbuh dari waktu ke waktu, Antrean Penyimpanan Azure dan Antrian Bus Layanan menyediakan layanan antrian serupa. Alasan mengapa Anda ingin menggunakan salah satu dari yang lain dibahas dalam makalah yang cukup teknis. Dalam banyak skenario, baik akan berhasil.
Skenario Antrian (Queue Scenarios)
Salah satu penggunaan antrian yang umum saat ini adalah membiarkan instance peran web berkomunikasi dengan instance peran pekerja dalam aplikasi Layanan Cloud yang sama.
Misalnya, Anda membuat aplikasi Azure untuk berbagi video. Aplikasi ini terdiri dari kode PHP yang berjalan di peran web yang memungkinkan pengguna mengunggah dan menonton video, bersama dengan peran pekerja yang diimplementasikan dalam C # yang menerjemahkan video yang diunggah ke dalam berbagai format.
Ketika contoh peran web mendapatkan video baru dari pengguna, itu dapat menyimpan video dalam Blob, lalu mengirim pesan ke peran pekerja melalui antrean yang memberitahukan di mana untuk menemukan video baru ini. Contoh peran pekerja tidak masalah mana yang kemudian akan membaca pesan dari antrean dan melakukan terjemahan video yang diperlukan di latar belakang.
Menata aplikasi dengan cara ini memungkinkan pemrosesan asinkron, dan itu juga membuat aplikasi lebih mudah untuk skala, karena jumlah instance peran web dan contoh peran pekerja dapat bervariasi secara independen. Anda juga dapat menggunakan ukuran antrian sebagai pemicu untuk menskalakan jumlah peran pekerja ke atas dan ke bawah. Terlalu tinggi, dan Anda menambahkan lebih banyak peran. Ketika semakin rendah, Anda dapat mengurangi jumlah menjalankan peran untuk menghemat uang.
Anda dapat menggunakan pola yang sama ini di antara berbagai bagian aplikasi Anda meskipun mereka tidak menggunakan peran web dan pekerja. Hal ini memungkinkan Anda untuk menskalakan bagian-bagian di kedua sisi antrean naik dan turun sesuai permintaan dan waktu pemrosesan.
2. Bus Layanan (Sevice Bus)
Apakah mereka berjalan di cloud, di pusat data Anda, di perangkat seluler, atau di tempat lain, aplikasi perlu berinteraksi. Tujuan dari Azure Service Bus adalah membiarkan aplikasi berjalan cukup banyak di mana saja bertukar data.
Relay Bus Layanan (Service Bus Relay)
Bus Servis memungkinkan komunikasi langsung melalui layanan relai, menyediakan cara aman untuk berinteraksi melalui firewall. Relai Bus Layanan memungkinkan aplikasi untuk berkomunikasi dengan bertukar pesan melalui titik akhir yang dihosting di cloud, bukan secara lokal.
Skenario Relay Bus Layanan (Service Bus Relay Scenarios)
Aplikasi yang berkomunikasi melalui Service Bus mungkin aplikasi atau perangkat lunak Azure yang berjalan di beberapa platform cloud lainnya. Mereka juga bisa menjadi aplikasi yang berjalan di luar cloud. Misalnya, pikirkan maskapai penerbangan yang mengimplementasikan layanan reservasi di komputer di dalam Datacenternya sendiri. Maskapai penerbangan perlu mengekspos layanan ini kepada banyak klien, termasuk kios check-in di bandara, terminal agen pemesanan, dan bahkan telepon pelanggan. Mungkin menggunakan Bus Layanan untuk melakukan ini, menciptakan interaksi yang digabungkan secara longgar di antara berbagai aplikasi.
Topik dan Langganan Bus Layanan (Service Bus Topic and Subscriptions)
Service Bus menyediakan mekanisme Publish-and-subscribe yang disebut Topik dan Langganan. Dengan mempublikasikan-berlangganan, aplikasi dapat mengirim pesan ke suatu topik, sementara aplikasi lain dapat membuat langganan ke topik ini. Ini memungkinkan komunikasi satu-ke-banyak di antara sekumpulan aplikasi, membiarkan pesan yang sama dibaca oleh banyak penerima.
Skenario Topik dan Langganan Bus Layanan
Kapanpun Anda sedang mengatur di mana ada banyak pesan yang semuanya penting, tetapi berbagai sistem hilir hanya perlu mendengarkan sub-bagian yang berbeda dari komunikasi tersebut, Topik Bus Layanan dan Langganan adalah opsi yang baik.
3. Layanan BizTalk (Service BizTalk)
Terkadang Anda perlu menghubungkan sistem yang berkomunikasi menggunakan berbagai format perpesanan. Sudah umum bagi bisnis untuk memiliki skema basis data dan format perpesanan XML yang berbeda, bahkan ketika standar umum tersedia. Daripada menulis banyak kode khusus, Anda dapat menggunakan BizTalk Server di tempat untuk mengintegrasikan berbagai sistem. Layanan Azure BizTalk menyediakan jenis layanan yang sama tetapi di cloud. Anda hanya dapat membayar apa yang Anda gunakan dan tidak khawatir tentang skala seperti yang Anda lakukan di tempat.
Skenario Layanan BizTalk (BizTalk Services Scenarios)
Interaksi Business-to-Business (B2B) umumnya membutuhkan jenis terjemahan ini. Misalnya, perusahaan yang membangun pesawat perlu memesan komponen dari berbagai pemasok komponennya. Ini akan memiliki banyak pemasok komponen. Pesanan tersebut harus otomatis untuk langsung dari sistem pembangun pesawat ke sistem pemasok. Baik bisnis tidak ingin mengubah sistem inti dan format pesan mereka, dan sangat tidak mungkin format tersebut sama. Layanan BizTalk dapat mengambil pesan dan menerjemahkan antara format baru dua arah. Baik pemasok pesawat dapat melakukan pekerjaan untuk menerjemahkan atau berbagai pemasok dapat, tergantung pada siapa yang ingin lebih banyak kontrol dan jumlah terjemahan yang dibutuhkan.