Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Solusi berorientasi layanan menyajikan aplikasi pelaporan saldo kredit yang dirancang sebagai layanan. Aplikasi ini, pada gilirannya, menggunakan tiga aplikasi backend, yang diekspos sebagai layanan itu sendiri, untuk mendapatkan informasi yang diperlukan untuk saldo kredit.
Service Oriented Architecture (SOA) adalah pendekatan yang sebagian tumpang tindih dalam membangun sistem terdistribusi. Pendekatan berorientasi layanan memiliki beberapa karakteristik:
Digabungkan secara longgar. Logika bisnis aplikasi terpisah dari logika penanganan layanan.
Dapat Ditemukan Harus ada mekanisme bagi aplikasi untuk menemukan layanan.
Kontrak. Antarmuka ke layanan mengimplementasikan kontrak antara pengguna dan layanan.
Meskipun literatur sering memperlakukan pendekatan berorientasi layanan sebagai identik dengan layanan web, mereka belum tentu sinonim. Layanan web menyajikan cara menarik untuk menerapkan solusi berorientasi layanan, tetapi Anda dapat menggunakan teknologi lain, seperti .NET remoting, untuk membuat layanan.
Panduan Pembaca
Dokumentasi untuk solusi ini mengasumsikan bahwa Anda terbiasa dengan BizTalk Server dan Microsoft Visual Studio. Ini juga mengasumsikan bahwa Anda memahami konsep dasar tentang integrasi aplikasi perusahaan dan layanan web.
Selain itu, untuk membaca dan mengikuti dokumentasi pengembang, Anda harus terbiasa dengan cara membangun aplikasi dengan menggunakan Visual Studio dan dengan melakukan tugas-tugas berikut: membuat proyek, mengatur referensi, dan men-debug dan menguji solusi BizTalk.
Pelaporan Kartu Kredit di Woodgrove Bank
Solusi arsitektur berorientasi layanan adalah layanan pelaporan saldo kartu kredit untuk Woodgrove Bank. Meskipun bank bersifat fiktif, skenarionya tidak; skenario ini didasarkan pada aplikasi pelanggan aktual yang sudah disebarkan.
Dalam skenario, permintaan saldo kartu kredit berasal dari dua sumber:
Aplikasi Interactive Voice Response (IVR).
Klien interaktif seperti halaman web atau aplikasi klien kustom.
Solusi ini menerima permintaan dari aplikasi IVR melalui MQSeries. Ini menangani permintaan dari klien interaktif melalui layanan web menggunakan HTTP dan SOAP.
Aplikasi arsitektur berorientasi layanan baru sering kali perlu bekerja dengan aplikasi warisan yang menggunakan teknologi lama, serta berfungsi dengan aplikasi modern seperti situs web yang menggunakan layanan web. Skenario ini memodelkan persyaratan dunia nyata ini—aplikasi IVR mewakili aplikasi warisan, sementara aplikasi klien layanan pelanggan, adalah yang modern.
Aplikasi Woodgrove Bank menggunakan data dari tiga backend, sistem warisan untuk menanggapi permintaan:
Aplikasi yang menyediakan batas kredit keseluruhan. Ini adalah sistem SAP pada komputer mainframe.
Sistem transaksi tertunda yang melaporkan jumlah total transaksi yang tertunda terhadap akun. Sistem ini adalah mainframe atau sistem AS/400. Solusi ini menggunakan layanan web dan Microsoft Host Integration Server (HIS) untuk berkomunikasi dengan mainframe atau sistem AS/400.
Sistem pelacakan pembayaran yang memberikan pembayaran terakhir yang dilakukan ke sistem. Sistem pelacakan pembayaran dapat dicapai menggunakan MQSeries.
Setelah mengumpulkan dan mengkompilasi informasi dari sistem warisan, solusi mengirimkan respons kembali ke aplikasi asal dan, dengan demikian, kepada pelanggan.
Persyaratan Bisnis
Karena aplikasi pelaporan kredit merespons secara real time permintaan pelanggan, aplikasi harus memiliki latensi rendah untuk menangani permintaan dengan cepat. Selain itu, juga harus dapat menangani jumlah permintaan simultan yang tinggi. Solusi ini menggunakan informasi sensitif dan antarmuka publik sehingga keamanan menjadi perhatian yang signifikan. Akhirnya, layanan harus dapat diandalkan.
Untuk informasi tentang bagaimana solusi memenuhi persyaratan ini, lihat Mengembangkan Solusi Berorientasi Layanan.
Karakteristik Performa
Untuk memenuhi persyaratan bisnis, skenario memiliki karakteristik performa berikut:
Throughput berkelanjutan dari 40 permintaan masuk per detik.
Kapasitas throughput maksimum 100 permintaan masuk per detik.
90 persen dari permintaan untuk dilayankan (masuk dan keluar dari BizTalk Server) dalam waktu di bawah 1000 milidetik.
95 persen dari permintaan untuk dilayankan (masuk dan keluar dari BizTalk Server) dalam waktu di bawah 2000 milidetik.
100 persen dari permintaan untuk dilayankan (masuk dan keluar dari BizTalk Server) dalam waktu di bawah 5000 milidetik.
Nota
Waktu yang disebutkan tidak termasuk waktu latensi sistem back-end.
Tiga Versi Solusi
Ada tiga versi solusi:
Versi stub menggantikan semua sistem backend dengan stub perangkat lunak. Stub mensimulasikan sistem backend. Versi ini menyediakan cara cepat untuk menyebarkan dan menjalankan solusi pada satu komputer.
Versi adaptor menggunakan adaptor BizTalk untuk terhubung ke sistem backend. Versi ini adalah bagaimana seseorang mungkin pertama kali berpikir untuk mengimplementasikan solusi. Namun, mengirim pesan ke sistem backend menggunakan adaptor memperkenalkan latensi yang signifikan dalam mendapatkan respons kembali. Meskipun adaptor sendiri dapat menawarkan latensi yang sangat rendah, arsitektur Terdistribusi BizTalk Server memerlukan adaptor untuk berkomunikasi dengan instans host orkestrasi menggunakan kotak pesan. Ini memperkenalkan akses bolak-balik ke database dan memengaruhi waktu tunda.
Versi sebaris menggantikan adaptor dengan kode sebaris yang berkomunikasi langsung dengan sistem backend. Versi sebaris solusi memiliki latensi terendah dan throughput tertinggi.
Panduan penyebaran menyediakan arah untuk membangun dan menyebarkan ketiga versi solusi, serta menyediakan cara, di setiap versi, untuk mensimulasikan koneksi melalui HIS ke sistem transaksi yang tertunda. Untuk informasi tentang membangun dan menyebarkan solusi, lihat Menyebarkan Solusi Berorientasi Layanan.