Bagikan melalui

BizTalk Server 2006 atau WF? Memilih Alat Alur Kerja yang Tepat untuk Proyek Anda

Kent Brown

twentysix New York (www.26ny.com)

November 2007

Direvisi Februari 2008

Berlaku untuk:

   Microsoft BizTalk Server 2006

   Windows Workflow Foundation

ringkasan : Artikel ini akan memberikan panduan untuk memilih antara Microsoft BizTalk Server 2006 dan Windows Workflow Foundation dalam berbagai skenario alur kerja Aplikasi dan Integrasi Perusahaan. (16 halaman cetak)

Isi

Perkenalan

Proses untuk Memilih Alat Alur Kerja yang Tepat

Skenario Alur Kerja Umum

Ini Semua di Host

Rekomendasi Workflow-Technology

Future-Proofing

Kesimpulan

Tambahan

Pengakuan

Informasi Selengkapnya

Perkenalan

Alur kerja bersifat pervasif dalam proses bisnis sehari-hari, sehingga kebutuhan umum adalah menemukan alat pemrograman yang secara langsung mendukung membangun solusi alur kerja. Microsoft BizTalk Server 2006 dan Windows Workflow Foundation (WF) adalah dua alat utama dari Microsoft untuk solusi alur kerja pemrograman. Namun, karena tumpang tindih yang jelas di antara mereka, banyak arsitek dan pengembang mengalami kesulitan memutuskan teknologi alur kerja mana yang masuk akal untuk tujuan mereka.

Ini terutama benar mengingat fakta bahwa WF telah diidentifikasi dengan jelas sebagai teknologi alur kerja pilihan ke depannya, sementara BizTalk Server 2006 masih merupakan produk server premium untuk integrasi perusahaan. Sampai orkestrasi BizTalk Server sepenuhnya mendukung WF, arsitek, dan pengembang harus memilih dengan hati-hati di mana teknologi untuk berinvestasi.

Salah satu tantangan dalam memilih teknologi yang tepat untuk menerapkan alur kerja adalah alur kerja dapat berarti banyak hal—di antaranya:

  • Alur layar UI tempat pengguna berinteraksi untuk menyelesaikan tugas.
  • Alur logika bisnis dalam aplikasi atau layanan.
  • Interaksi beberapa manusia untuk menyelesaikan proses bisnis.
  • Koordinasi beberapa pertukaran pesan antar sistem untuk memproses transaksi bisnis.
  • Koordinasi langkah-langkah untuk mengekstrak, mengubah, dan memuat data (ETL) ke dalam database.

Meskipun spektrum skenario alur kerja luas, sangat membantu untuk mengelompokkannya ke dalam empat kategori luas: Alur Kerja Manusia, alur kerja aplikasi , Alur Kerja Integrasi Perusahaan, dan Alur Kerja Integrasi Data .

Dari empat kategori alur kerja utama, Alur Kerja Aplikasi dan Alur Kerja Integrasi Perusahaan adalah dua area di mana orang merasa paling sulit untuk memilih teknologi. Skenario Alur Kerja Manusia dan Alur Kerja Integrasi Data cukup mudah, dari perspektif pemilihan alat. Alur kerja manusia memerlukan antarmuka pengguna dan sering kali ber sentris dokumen, sehingga Microsoft Office SharePoint Server 2007 adalah platform yang direkomendasikan untuk membangun solusi Alur Kerja Manusia. Microsoft SQL Server Integration Services (SSIS) adalah alat yang direkomendasikan untuk skenario Integrasi Data.

Artikel ini akan memberikan panduan untuk memilih antara BizTalk Server 2006 dan WF dalam alur kerja aplikasi dan skenario Alur Kerja Integrasi Perusahaan.

Mesin Orkestrasi BizTalk Server

Mesin orkestrasi BizTalk Server selalu menjadi salah satu fitur menarik BizTalk Server. Ketika diperkenalkan, ini adalah alat terbaik yang tersedia dari Microsoft untuk melakukan pemrograman yang ber sentris alur kerja. Orkestrasi BizTalk Server menyediakan lingkungan pemrograman visual untuk mengembangkan komponen untuk mengontrol alur pesan multistep yang kompleks untuk menyelesaikan transaksi bisnis tertentu.

Artefak kode orkestrasi BizTalk Server sangat menyerupai diagram aktivitas diagram bagan alur atau Unified Modeling Language (UML) yang mungkin dihasilkan analis bisnis untuk mendokumenkan proses bisnis. Artefak ini kemudian dapat dikompilasi dan dijalankan dalam runtime mesin orkestrasi, yang menyediakan layanan seperti transaksi dan kompensasi jangka panjang, durabilitas, toleransi kesalahan, dan pemulihan bencana, yang sangat penting untuk membangun sistem yang mengotomatiskan transaksi bisnis misi penting.

Fondasi Alur Kerja untuk Masa Depan

Meskipun ada kategori skenario alur kerja yang berbeda, ada cukup kesamaan antara skenario, dari perspektif pemrograman, untuk membuatnya bermanfaat untuk mencoba membuat kerangka kerja umum untuk pengembangan alur kerja. Mesin orkestrasi di BizTalk Server sangat kuat, tetapi tidak pernah dirancang untuk digunakan di luar BizTalk Server; jadi, tidak mungkin untuk menggunakan kembali orkestrasi BizTalk Server secara efektif untuk kategori alur kerja lainnya.

WF, yang dirilis di Microsoft .NET Framework 3.0, memperkenalkan model pemrograman visual yang berpusat pada alur kerja ke .NET Framework yang dirancang agar cukup umum dan dapat diperluas untuk digunakan dalam semua skenario terkait alur kerja pada platform Windows ke depannya. Tim yang memproduksi WF mampu mengambil konsep terbaik dari mesin orkestrasi BizTalk Server, mempertimbangkan persyaratan untuk ranah skenario alur kerja yang lebih luas, dan merancang kerangka kerja yang cukup fleksibel untuk mendukung semuanya.

Sebagai bukti fleksibilitas WF, Microsoft Office SharePoint Server 2007 menggunakannya untuk menerapkan solusi Alur Kerja Manusia. Tujuannya adalah untuk vendor BPM pihak ketiga juga untuk membangun solusi mereka di atas WF, alih-alih membangun mesin alur kerja milik mereka sendiri; beberapa vendor telah melakukannya. Pengembang individu juga dapat menggunakan WF untuk menerapkan Alur Kerja Aplikasi kustom di aplikasi .NET Framework. Rencananya juga untuk versi BizTalk Server di masa mendatang untuk mengimplementasikan mesin orkestrasi pada WF untuk menerapkan solusi Alur Kerja Integrasi Perusahaan.

Gambar 1. Menggunakan alat alur kerja yang tepat: BizTalk Server 2006 vs. WF

Proses untuk Memilih Alat Alur Kerja yang Tepat

Metode kami untuk memberikan panduan untuk membantu Anda memutuskan alat alur kerja mana yang sesuai dengan proyek Anda untuk menguraikan skenario alur kerja yang paling umum, sehingga Anda dapat menentukan skenario atau kombinasi skenario yang paling sesuai dengan proyek Anda. Kemudian, kami akan memberikan panduan khusus untuk setiap skenario tentang alat mana—BizTalk Server 2006 atau WF—adalah yang paling cocok, dan mengapa. Selain itu, kami akan menggunakan Model Pengoptimalan Infrastruktur Platform Aplikasi (APIO) —model untuk menilai kematangan platform aplikasi organisasi dan kemampuan pengembangan—untuk memberikan panduan khusus organisasi dalam skenario di mana salah satu alat dapat digunakan secara efektif. Terakhir, kita akan melihat peta jalan untuk BizTalk Server 2006 dan WF, sehingga Anda dapat membuat keputusan terbaik untuk pemeriksa masa depan aplikasi yang Anda bangun hari ini.

Skenario Alur Kerja Umum

Bahkan setelah membatasi cakupan kami ke kategori alur kerja Integrasi Aplikasi dan Perusahaan, masih ada berbagai skenario alur kerja yang perlu dipertimbangkan. Seperti yang ditunjukkan Gambar 2, di satu sisi spektrum adalah skenario di mana WF jelas adalah pilihan yang tepat. Contohnya adalah kemampuan alur kerja dalam produk vendor perangkat lunak independen (ISV), di mana biaya lisensi dan kompleksitas penyebaran BizTalk Server 2006 akan dilarang. Dalam skenario ini, sebagai ISV, Anda berada dalam bisnis pembuatan perangkat lunak komersial, dan upaya pemrograman ekstra yang diperlukan untuk menghosting WF bebas royalti adalah investasi yang wajar.

Gambar 2. Integrasi dan kontinum alur kerja

Di sisi lain spektrum adalah solusi Integrasi Perusahaan yang dibangun dalam departemen IT perusahaan, di mana jelas BizTalk Server 2006 adalah pilihan yang tepat. Dalam skenario ini, Anda ingin fokus pada produksi nilai bisnis, alih-alih berinvestasi dalam membangun "pipa" untuk membuat solusi Anda dapat diskalakan, dapat diandalkan, dan dikelola; jadi, biaya lisensi BizTalk Server 2006 sangat sepadan, karena apa yang disediakannya.

Sebagian besar proyek jatuh di antara kedua ujung spektrum ini. Berikut ini adalah beberapa skenario umum di mana persyaratan menentukan solusi alur kerja:

  • Pengontrol Halaman UI —Persyaratan umum dalam aplikasi kompleks adalah menerapkan navigasi layar UI sesuai dengan aturan bisnis kasus penggunaan spesifik yang sedang diterapkan. Contoh paling sederhana adalah wizard yang memanah pengguna melalui serangkaian layar yang ditentukan untuk menyelesaikan tugas. Seringkali, ini adalah grafik yang lebih kompleks dari kemungkinan navigasi layar yang didasarkan pada tindakan pengguna dan status data.
    Pola Model-view-controller (MVC) adalah teknik klasik untuk menarik logika navigasi ini keluar dari bentuk itu sendiri, sehingga lebih sederhana dan lebih dapat digunakan kembali di berbagai kasus penggunaan. Pengontrol dalam pola MVC benar-benar alur kerja, atau mesin status; jadi, wajar untuk mencari alat alur kerja dalam mengimplementasikan jenis aplikasi ini.
  • Logika Bisnis Jangka Panjang—Ketika banyak langkah yang diperlukan untuk menyelesaikan transaksi bisnis, pengguna mungkin harus berhenti di tengah proses atau menunggu tindakan dari pengguna atau sistem lain sebelum melanjutkan. Kemampuan untuk menjeda sementara (atau "hibernasi") proses lalu memulai ulang, berdasarkan peristiwa eksternal, adalah pusat gagasan alur kerja. Tanpa mesin alur kerja, pengembang dipaksa untuk merancang dan mengodekan secara manual mekanisme untuk menyimpan status proses yang tidak lengkap dan menarik kembali status tersebut ketika proses dilanjutkan. Dengan mesin alur kerja yang dirancang dengan baik, kemampuan ini didukung secara asli tanpa pekerjaan tambahan untuk pengembang.
  • Alur Proses yang Dapat Diperbarui Secara Dinamis—Meskipun pada awalnya mungkin untuk mengkodifikasi proses bisnis menjadi langkah-langkah berurutan yang terdefinisi dengan baik, manusia sering kali harus memodifikasi aliran di tengah aliran untuk memperhitungkan situasi kehidupan nyata. Dalam proses persetujuan pengeluaran, manajer karyawan yang mengirimkan laporan pengeluaran mungkin merupakan pemberi persetujuan default. Namun, manajer mungkin memutuskan untuk mendelegasikan tugas kepada sekretaris (misalnya, karena manajer akan keluar untuk bermain golf) atau meningkatkan persetujuan ke atasan (misalnya, karena manajer tidak yakin dengan kebijakan untuk pengeluaran tertentu). Memungkinkan pengguna memperbarui alur sering kali lebih sederhana daripada mencoba mengantisipasi setiap kemungkinan permutasi alur sebelumnya.
  • Abstraksi Aturan dariLogika Bisnis —Dalam skenario ini, tujuan Anda adalah memisahkan aturan bisnis dari logika bisnis lainnya. Contoh yang baik adalah aturan validasi formulir. Dalam program Aplikasi KPR, formulir Aplikasi Pinjaman mungkin memiliki satu set aturan validasi bidang sebelum pengguna dapat menekan tombol Kirim untuk mengirimkan aplikasi pinjaman. Jika bentuk yang sama digunakan oleh petugas pinjaman untuk meninjau dan menyetujui pinjaman, diperlukan aturan validasi tambahan, karena berada pada tahap yang berbeda dalam prosesnya.
    Menerapkan aturan validasi secara terpisah dari formulir memudahkan formulir digunakan kembali dalam skenario yang berbeda dan untuk menerapkan aturan validasi yang sesuai hanya dengan mengevaluasi seperangkat aturan yang sesuai untuk skenario tersebut.
  • Agregator Layanan Web —Aplikasi sering kali harus menggabungkan data dari beberapa layanan Web yang berbeda. Dalam banyak situasi, logika agregasi itu sendiri dapat dan harus diekstraksi dari aplikasi, dan diekspos sebagai layanan dengan haknya sendiri yang dapat digunakan kembali dari aplikasi lain. Layanan ini sering disebut layanan Web komposit, dan merupakan elemen penting dari arsitektur berorientasi layanan yang matang. Skenario Agregator Layanan Web biasanya sinkron dan berjalan singkat.
  • proses bisnis jangka panjang—Skenario Proses Bisnis Jangka Panjang digunakan dalam artikel ini untuk menunjuk proses berbasis server yang mengintegrasikan beberapa aplikasi bersama-sama, sedangkan logika bisnis digunakan untuk logika dalam satu aplikasi. Persyaratan untuk Proses Bisnis Jangka Panjang berbasis server ini untuk multithreading, perilaku asinkron, persistensi status proses, korelasi pesan untuk memproses instans, skalabilitas, keandalan, integritas transaksional, dan sebagainya, jauh lebih tinggi daripada untuk logika bisnis dalam aplikasi.
  • Proses Bisnis ke Bisnis (B2B)—Skenario Proses B2B pada dasarnya sama dengan skenario Proses Bisnis Jangka Panjang, kecuali bahwa yang pertama berada di antara organisasi selain aplikasi internal. Oleh karena itu, persyaratan keamanan sangat penting. Selain itu, Anda bahkan memiliki kontrol yang lebih sedikit atas format data dan protokol transportasi tertentu, karena ini mungkin ditentukan oleh mitra bisnis Anda; jadi, Anda memerlukan kemampuan untuk mendukung berbagai format dan protokol dan mendukung konfigurasi pertukaran tertentu untuk sejumlah besar mitra.
  • Abstraksi Aturan dari Proses Bisnis—Mirip dengan Abstraksi Aturan dari skenario Logika Bisnis, skenario ini berlaku ketika Anda ingin memisahkan aturan bisnis dari kode utama dalam skenario Proses Bisnis yang Berjalan Lama dan skenario Proses B2B. Skenario ini membutuhkan tingkat performa dan skalabilitas yang lebih tinggi. Selain itu, kemungkinan akan memerlukan alat untuk memungkinkan nonprogrammer melihat dan mengedit aturan.
  • Repositori Aturan Perusahaan—Dalam skenario ini, tujuannya adalah untuk membangun repositori aturan bersama pusat yang dapat dipanggil dari semua aplikasi di perusahaan. Ini memberikan konsistensi di semua aplikasi dalam organisasi untuk menerapkan aturan bisnis penting. Demikian pula dengan skenario Abstraksi Aturan dari Proses Bisnis, skenario ini memerlukan skalabilitas dan alat yang tinggi untuk memungkinkan nonprogrammer melihat dan mengedit aturan. Selain itu, skenario ini mengharuskan repositori aturan mampu berada sebagai entitasnya sendiri di perusahaan, dengan mekanisme hostingnya sendiri yang terpisah dari mesin alur kerja, dan dengan komponen atau API untuk menjalankan aturan dari berbagai aplikasi.
  • Enterprise Service Bus (ESB)/Message Broker—Banyak organisasi menginginkan infrastruktur komunikasi standar untuk semua layanan. Dua topologi paling umum untuk infrastruktur ini adalah ESB dan Message Broker. Menerbitkan/berlangganan olahpesan dan perutean basis topik adalah fitur yang umumnya diharapkan dari infrastruktur ini.

Model Pengoptimalan Infrastruktur Platform Aplikasi

Dalam beberapa skenario alur kerja, bizTalk Server 2006 dan WF memenuhi persyaratan teknis. Untuk skenario ini, membuat pilihan teknologi alur kerja yang tepat memerlukan pencocokan solusi dengan kebutuhan organisasi tertentu. Untuk tujuan membuat rekomendasi yang berlaku untuk organisasi tertentu Anda, kami akan menggunakan model Application Platform Infrastructure Optimization (APIO), seperti yang ditunjukkan pada Gambar 3.

Gambar 3. Model Pengoptimalan Infrastruktur Platform Aplikasi (APIO)

Model APIO adalah teknik untuk membuat profil kematangan organisasi sehubungan dengan infrastruktur aplikasi, arsitektur, dan praktik pengembangannya. Tujuan dari model ini adalah untuk memberi organisasi peta jalan untuk mengoptimalkan kelincahan mereka dalam menyediakan solusi IT untuk memenuhi kebutuhan bisnis.

Model APIO menggunakan empat profil kematangan organisasi berikut:

  • Dasar —Organisasi memperlakukan perangkat lunak sebagai biaya. Mereka sebagian besar memiliki aplikasi yang di-siloed dengan sedikit integrasi atau penggunaan kembali. Aplikasi yang mereka miliki mungkin ada di berbagai platform. Mereka tidak memiliki standar yang konsisten untuk infrastruktur atau teknik pengembangan; mereka tidak memiliki visi arsitektur yang konsisten.
  • standar —Organisasi masih memperlakukan perangkat lunak sebagai biaya, tetapi mereka telah mengambil langkah-langkah untuk meningkatkan efisiensi. Mereka memiliki visi arsitektur dan mencoba mempertimbangkan peluang untuk digunakan kembali. Mereka telah mulai mengintegrasikan beberapa aplikasi, tetapi sebagian besar merupakan integrasi point-to-point.
  • Tingkat Lanjut —Organisasi memperlakukan perangkat lunak sebagai pengaktif bisnis. Mereka memiliki arsitek khusus dan visi arsitektur yang jelas. Mereka memiliki banyak layanan dan mencapai penggunaan kembali tingkat tinggi. Semua proses bisnis inti diotomatisasi dan dipantau. Mereka menggunakan platform integrasi terpusat dan dimas.
  • Dynamic—Organisasi memperlakukan perangkat lunak sebagai aset strategis. Mereka memiliki SOA yang sangat matang dalam visi dan implementasi. Mereka memiliki proses yang jelas untuk layanan penerapan versi dan penyebaran ulang secara dinamis. Dapat dengan cepat beradaptasi dengan perubahan persyaratan bisnis, dan dapat dengan cepat berintegrasi dengan mitra bisnis baru.

Ini Bukan Hanya Di Mana Anda Berada, tetapi Di mana Anda Akan Pergi

Agak implisit dalam model APIO adalah gagasan bahwa setiap organisasi akan bercita-cita untuk bergerak menuju profil Dinamis. Pada kenyataannya, itu tergantung pada sifat bisnis dan filosofi manajemen mengenai teknologi. Beberapa bisnis mungkin benar-benar puas untuk tetap berada di profil Dasar atau Standar.

Anda harus mempertimbangkan profil saat ini, serta tujuan jangka dekat dan jangka panjang, dengan tujuan jangka dekat menjadi yang paling penting. Organisasi di profil Dasar, dengan keinginan untuk berada di profil Dinamis pada akhirnya, dapat memilih dengan bijaksana untuk fokus pada awalnya pada masuk ke profil Standar; jadi, keputusan teknologinya sebagian besar harus konsisten dengan profil Standar.

Secara umum, BizTalk Server 2006 akan menjadi lebih cocok dalam organisasi yang—atau memiliki tujuan jangka pendek—di profil Tingkat Lanjut atau Dinamis. Organisasi di profil Dasar yang relatif terpenuhi dalam profil ini mungkin tidak memiliki motivasi strategis untuk mengadopsi BizTalk Server 2006 atau kemampuan untuk memanfaatkannya secara efektif; jadi, mereka tidak mungkin ingin melakukan investasi. Namun, jika organisasi di profil Dasar telah membuat keputusan untuk bergerak menuju profil Tingkat Lanjut secara agresif, mengadopsi BizTalk Server 2006 mungkin merupakan langkah strategis ke arah tersebut.

Inti dari memperkenalkan model APIO ke dalam diskusi adalah bahwa memiliki ide yang baik tentang profil APIO organisasi saat ini dan yang ditargetkan akan membantu dalam memutuskan antara WF dan BizTalk Server 2006, ketika skenario teknis dapat didukung dengan baik oleh salah satu teknologi. Dua organisasi yang berbeda mungkin membuat pilihan yang berbeda—masing-masing membuat pilihan yang tepat untuk profil organisasinya.

Ini Semua di Host

Salah satu aspek terpenting yang perlu dipertimbangkan saat memilih antara BizTalk Server 2006 dan WF adalah persyaratan hosting untuk alur kerja Anda. Tidak seperti BizTalk Server 2006, WF tidak menyediakan hosting "out-of-the-box"; Anda harus menerapkan host yang menetapkan proses Windows dan memulai mesin runtime alur kerja tempat alur kerja Anda akan dijalankan.

Untuk membangun kerangka kerja yang dapat mendukung spektrum penuh skenario alur kerja secara realistis, WF mengabstraksi perilaku inti yang disediakan lingkungan seperti BizTalk Server 2006, sehingga berbagai host dapat memberikan perilaku spesifik yang diinginkan untuk layanan ini.

Layanan inti yang disediakan host alur kerja WF adalah sebagai berikut:

  • Layanan penjadwalan—Membuat dan mengelola utas yang digunakan oleh mesin runtime untuk menjalankan instans alur kerja.
  • layanan Commit Work Batch—Mengelola transaksi yang digunakan oleh mesin runtime untuk operasi database.
  • layanan Persistensi —Menangani persistensi instans alur kerja ketika diarahkan untuk melakukannya oleh mesin runtime. Layanan ini bersifat opsional. Jika tidak disediakan, instans alur kerja tidak akan dipertahankan, dan instans tersebut harus berjalan dalam memori selama masa pakainya.
  • layanan Pelacakan—Menyediakan kemampuan untuk merekam peristiwa pelacakan dalam alur kerja. Layanan ini bersifat opsional.

Apa yang Diperlukan untuk Membangun Host Alur Kerja

Bergantung pada skenario alur kerja Anda dan layanan yang harus Anda berikan ke alur kerja Anda, membangun host WF mungkin sepele atau melarang. Untuk skenario di mana alur kerja berada dalam konteks aplikasi, hosting WF cukup mudah. Aplikasi itu sendiri bertindak sebagai host proses, dan ada implementasi standar dari layanan inti yang dapat dikonfigurasi dengan upaya minimal.

Namun, kecanggihan host yang diperlukan melompat secara dramatis ketika Anda masuk ke skenario berbasis server yang sangat dapat diskalakan. Tabel 1 memperlihatkan daftar binatu layanan host yang mungkin diperlukan—sebagian besar disediakan di BizTalk Server 2006.

Tabel 1. Layanan host

  • Konfigurasi peluasan skala
  • Penyeimbangan beban
  • Fail-over
  • Throttling
  • Manajemen utas
  • Manajemen memori
  • Isolasi layanan
  • Konfigurasi pengecualian
  • Manajemen pesan gagal
  • Pelacakan pesan
  • Pengarsipan dan pembersihan
  • Identitas dan peniruan identitas
  • Model penyebaran multi-lingkungan
  • Pemantauan kesehatan
  • Pemanfaatan/Pelacakan performa
  • Manajemen status proses komposit
  • Scripting
  • Pemulihan bencana
  • Kepatuhan terhadap peraturan
  • Manajemen konfigurasi

Apa bisnis Anda di, sih?

Jika Anda ditugaskan untuk membangun aplikasi tertentu dengan tenggat waktu yang ketat, Anda mungkin tidak ingin tim Anda terganggu dengan harus membangun host yang kompleks ketika mereka harus fokus pada penerapan logika bisnis yang diperlukan. Dalam hal ini, BizTalk Server 2006 sangat sepadan dengan investasi yang harus dibeli—alih-alih mencoba membangun—host alur kerja yang kuat. Jika Anda adalah bagian dari tim arsitektur pusat dari perusahaan besar, Anda mungkin memilih untuk berinvestasi dalam membangun host yang dapat digunakan di seluruh organisasi. Meskipun demikian, upaya ini tidak boleh dianggap enteng.

Rekomendasi Workflow-Technology

Untuk Skenario Dalam Aplikasi: WF

Untuk semua skenario yang terkandung dalam aplikasi—termasuk Pengontrol Halaman UI, Logika Bisnis yang Berjalan Lama, Alur Proses yang Dapat Diperbarui Secara Dinamis, Komposisi Layanan Web, dan Abstraksi Aturan dari Logika Bisnis—WF adalah pilihan teknologi alur kerja yang tepat.

Dalam sebagian besar skenario yang berpusat pada aplikasi, pola penggunaan memerlukan interaksi latensi rendah yang sinkron antara aplikasi dan alur kerja, yang bukan kekuatan BizTalk Server 2006. BizTalk Server 2006 tidak akan cocok untuk skenario ini, karena alasan performa; Orkestrasi BizTalk Server berjalan pada Server BizTalk khusus, dan memanggilnya dari aplikasi klien memerlukan perjalanan pulang pergi di seluruh jaringan. Selain itu, desain BizTalk Server 2006 mempertahankan setiap pesan ke database MessageBox untuk durabilitas memperkenalkan latensi tambahan, yang mungkin tidak dapat diterima dalam konteks UI interaktif, jika alur kerja harus dipanggil secara sinkron.

WF lebih cocok untuk skenario ini; ini memenuhi persyaratan alur kerja, dan lebih sederhana dan lebih murah daripada BizTalk Server 2006. Kemampuan olahpesan BizTalk Server 2006—misalnya, Pemetaan dan Adaptor—tidak diperlukan dalam skenario ini. Persyaratan untuk layanan hosting sederhana, sehingga menghosting runtime WF di dalam aplikasi tidak memerlukan jumlah pekerjaan yang dilarang.

Untuk Skenario paling Business-Process: BizTalk Server 2006

Untuk sebagian besar skenario yang melibatkan proses bisnis berbasis server, BizTalk Server 2006 adalah pilihan yang tepat. Ini termasuk Proses B2B, Abstraksi Aturan dari Proses Bisnis, Repositori Aturan Perusahaan, dan Enterprise Service Bus (ESB)/Broker Pesan.

Skenario ini memerlukan skalabilitas tinggi. Selain itu, mereka memerlukan kemampuan untuk melihat proses yang sedang berjalan, dan untuk menghentikan dan menghidupkannya kembali. Akhirnya, mereka memerlukan dukungan untuk penskalaan ke beberapa server. Dalam skenario ini, fitur hosting lanjutan BizTalk Server 2006 diperlukan dan sepadan dengan investasi.

Dasar Standar Maju Dinamis

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Gambar 4. Skenario Proses Bisnis yang Berjalan Lama

BizTalk Server 2006 umumnya akan menjadi platform terbaik untuk skenario Proses Bisnis Jangka Panjang. Proses ini cenderung asinkron, berjalan lama, dan stateful. Proses ini sering kali sangat penting bagi organisasi; oleh karena itu, mereka membutuhkan ketersediaan tinggi, visibilitas, keamanan, dan pengelolaan. Topologi Grup atau "Farm" BizTalk Server 2006 memungkinkan Anda mengelola array server untuk memberikan skalabilitas dan redundansi.

Mekanisme persistensi BizTalk Server 2006 untuk menyimpan status proses memiliki keamanan yang kuat bawaan untuk melindungi privasi status yang bertahan, yang mungkin penting karena alasan peraturan. Pemantauan Aktivitas Bisnis (BAM) BizTalk Server 2006 memberikan visibilitas tingkat bisnis yang sesuai ke dalam proses yang berjalan dengan cara yang aman. Akhirnya, skenario ini sering memerlukan dukungan untuk format pesan heterogen dan protokol transportasi, termasuk sistem warisan.

Untuk alasan ini, BizTalk Server 2006 biasanya akan menjadi pilihan terbaik untuk organisasi yang menargetkan profil Standar, Tingkat Lanjut, dan Dinamis. Organisasi-organisasi ini biasanya menganggap skenario Proses Bisnis Jangka Panjang sangat penting untuk bisnis dan sangat umum dalam perusahaan; jadi, mereka membeli BizTalk Server 2006 secara khusus untuk membangun platform standar untuk mereka.

Namun, WF mungkin menjadi pilihan yang lebih baik untuk organisasi yang berada di profil APIO Dasar. Organisasi-organisasi ini umumnya tidak ingin berinvestasi dalam membangun platform aplikasi standar. Sebaliknya, mereka ingin meminimalkan biaya, dan biaya lisensi dan perangkat keras BizTalk Server 2006 mungkin dilarang. Pengecualian untuk panduan ini adalah ketika ada persyaratan untuk skalabilitas tinggi, pemantauan, dan dukungan untuk berbagai format pesan dan protokol transportasi. Dalam hal ini, meskipun organisasi enggan berinvestasi di platform aplikasi mereka, biaya membangun fitur hosting dan olahpesan dari awal kemungkinan akan melebihi biaya BizTalk Server 2006.

Dasar Standar Maju Dinamis

WF

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Gambar 5. Skenario Agregator Layanan Web

Baik orkestrasi BizTalk Server dan alur kerja WF memiliki dukungan yang kuat untuk layanan Web yang menggunakan eksternal dari alur kerja, dan untuk mengekspos alur kerja sebagai layanan Web. Oleh karena itu, untuk membangun solusi Agregator Layanan Web, sama seperti untuk solusi Proses Bisnis Jangka Panjang, pilihan ditentukan oleh profil organisasi dan persyaratan hosting.

Jika layanan Web agregat hanya untuk menggabungkan layanan Web lainnya, kemampuan BizTalk Server 2006 untuk mendukung format pesan heterogen dan protokol transportasi menambah sedikit nilai. Namun, jika layanan juga harus menggabungkan data dari lingkungan warisan yang tidak diekspos sebagai layanan Web, BizTalk Server 2006 akan menambah nilai.

Karena pola penggunaan cepat, panggilan permintaan/respons sinkron, durabilitas pesan yang disediakan oleh BizTalk Server 2006 biasanya tidak penting. Bahkan, latensi yang diperkenalkan oleh kegigihan ke MessageBox sebenarnya adalah kewajiban. Nilai utama yang disediakan BizTalk Server 2006 untuk skenario ini adalah kemampuan untuk mengelola penyebaran di banyak server dan untuk memantau instans yang sedang berjalan. Kemampuan BAM BizTalk Server 2006 juga mungkin berguna untuk memantau bahwa perjanjian tingkat layanan (SLA) terpenuhi.

Untuk alasan ini, WF adalah pilihan yang sangat baik untuk menerapkan Agregator Layanan Web, terutama dalam organisasi di profil Dasar dan Standar. Contoh di mana BizTalk Server 2006 mungkin menguntungkan adalah salah satu tempat Anda harus mengelola sejumlah besar titik akhir untuk organisasi klien yang berbeda. Konfigurasi Receive Port dan Receive Location BizTalk Server 2006 secara khusus menangani ini. Dalam hal ini, sertifikat mungkin juga penting, dan dukungan BizTalk Server 2006 untuk mengonfigurasi dan mengelola sertifikat dan menerapkannya ke enkripsi/dekripsi mungkin berguna.

Future-Proofing

Anda ingin memastikan bahwa investasi Anda dalam biaya lisensi perangkat lunak, dalam mempelajari teknologi alur kerja, dan dalam membangun komponen alur kerja tertentu, akan memberi Anda nilai yang paling mungkin di masa depan. Selain memilih alur kerja yang tepat untuk skenario dan organisasi alur kerja tertentu, Anda juga harus memperhitungkan peta jalan produk untuk BizTalk Server 2006 dan WF. Tidak ada jawaban sederhana untuk ini. Komentar yang mengikuti tidak membuat argumen yang kuat untuk memilih salah satu teknologi; sebaliknya mereka adalah poin data untuk membantu dalam keputusan Anda.

Apa yang Ditambahkan BizTalk Server 2006 R2

BizTalk Server 2006 R2 menambahkan dua fitur yang mungkin memengaruhi pilihan platform alur kerja Anda: Adaptor WCF, dan pencegat BAM untuk WCF dan WF.

Adaptor WCF

Jika tim Anda telah mengadopsi Windows Communication Foundation (WCF) sebagai teknologi standar untuk menerapkan layanan dalam membangun SOA Anda, fakta bahwa BizTalk Server 2006 tidak memiliki dukungan WCF mungkin telah mendiskualifikasikannya sebagai platform untuk membangun dan menghosting layanan Web komposit. Ini mungkin telah mendorong Anda ke WF, bahkan jika BizTalk Server 2006 adalah kecocokan yang bagus untuk skenario dan profil APIO Anda.

Untungnya, dengan diperkenalkannya integrasi WCF yang hebat di BizTalk Server 2006 R2, ini tidak lagi menjadi perhatian. BizTalk Server 2006 sekarang memiliki integrasi yang kuat dengan WCF, dan ini adalah platform yang sangat baik untuk membangun layanan komposit dari layanan yang lebih terperinci dan mengekspos layanan komposit ini sebagai layanan WCF.

Pencegat BAM untuk WF

Fitur BizTalk Server 2006 R2 yang relevan kedua adalah pengenalan pencegat BAM untuk WF. Jika pemantauan aktivitas bisnis adalah fitur penting dari solusi Anda, Anda mungkin telah didorong untuk menggunakan BizTalk Server 2006—hanya untuk memanfaatkan BAM—ketika WF lebih cocok untuk skenario Anda. Dengan pencegat BAM untuk WF, Anda dapat memilih WF jika itu adalah teknologi alur kerja yang tepat untuk proyek Anda dan masih memanfaatkan BAM sebagai solusi pemantauan aktivitas bisnis perusahaan.

BAM adalah fitur BizTalk Server 2006 yang menyediakan kerangka kerja untuk menangkap peristiwa dan data dari orkestrasi dan alur pesan BizTalk Server, dan menyajikan data tersebut di portal untuk memberi pengguna bisnis visibilitas menyeluruh ke dalam proses bisnis. Aspek yang kuat dari cara BAM bekerja untuk aplikasi BizTalk Server 2006 adalah bahwa pemantauan BAM dapat dikonfigurasi (atau "diinstrumentasikan") setelah aplikasi BizTalk Server 2006 disebarkan, tanpa memerlukan modifikasi pada artefak kode BizTalk Server 2006.

BAM dirancang sebagai solusi pemantauan aktivitas bisnis di seluruh perusahaan; oleh karena itu, dimungkinkan bagi aplikasi non-BizTalk Server 2006 untuk memasukkan peristiwa dan data ke BAM. Namun, API untuk melakukannya memerlukan sedikit kode untuk ditulis dalam aplikasi eksternal. Pencegat BAM WF di BizTalk Server 2006 R2 menyediakan kemampuan untuk melengkapi alur kerja WF untuk BAM lebih sederhana dan tanpa memerlukan modifikasi kode. Dengan menggunakan pencegat BAM, Anda dapat melacak proses bisnis Anda tanpa mengkompilasi ulang solusi WF atau WCF Anda; integrasi dilakukan melalui file konfigurasi.

Ekstensi BizTalk Server 2006 untuk WF SDK

Ekstensi BizTalk Server 2006 untuk WF SDK diumumkan dan didemosikan di TechEd 2007. SDK ini menyediakan mekanisme sederhana untuk menghosting alur kerja WF di BizTalk Server 2006. Alat ini ditujukan untuk digunakan oleh pengembang .NET yang membangun alur kerja WF saat ini dan mencari cara mudah untuk mencapai hosting alur kerja yang kuat dan dapat diskalakan.

SDK menyediakan dua Aktivitas WF kustom—aktivitas btsReceive dan aktivitas btsSend—yang dapat digunakan dalam alur kerja WF untuk menerima dan mengirim pesan melalui BizTalk Server 2006. Sebagai pengembang, Anda menentukan DataContracts WCF untuk pesan masuk dan keluar, dan ServiceContract untuk menentukan pola pertukaran pesan. Dalam alur kerja WF, aktivitas btsReceive dan btsSend dikonfigurasi untuk menggunakan ServiceContract yang ditentukan, seperti yang ditunjukkan pada Gambar 6.

Gambar 6. aktivitas btsReceive dan btsSend untuk digunakan dalam ServiceContract yang ditentukan

Setelah alur kerja WF selesai dan dikompilasi, Anda mengklik kanan proyek alur kerja dan memilih Menghasilkan orkestrasi untuk menghasilkan orkestrasi pembungkus secara otomatis (lihat Gambar 7) yang akan memulai alur kerja WF dan merutekan pesan BizTalk Server 2006 baik ke dan dari sana.

Orkestrasi pembungkus yang dihasilkan secara otomatis berisi skema untuk pesan yang ditentukan dalam ServiceContract. Ini juga berisi bentuk dan kode orkestrasi BizTalk Server untuk menerima pesan BizTalk Server 2006, membuat dan memulai instans alur kerja, meneruskan pesan masuk ke instans alur kerja, menerima pesan keluar, dan meneruskannya kembali ke mesin olahpesan BizTalk Server 2006. Untuk menyelesaikan hosting alur kerja WF Anda, Anda hanya perlu mengkompilasi dan menyebarkan orkestrasi pembungkus, dan mengikatnya dengan menggunakan mekanisme BizTalk Server 2006 normal.

Gambar 7. Menghasilkan orkestrasi pembungkus secara otomatis

Selain memanfaatkan mekanisme hosting BizTalk Server 2006 yang kuat dan dapat diskalakan untuk alur kerja WF, Ekstensi BizTalk Server 2006 untuk WF SDK memungkinkan Anda memanfaatkan infrastruktur olahpesan BizTalk Server 2006. Dengan demikian, Anda dapat memanfaatkan banyak Adapter yang tersedia untuk mendapatkan pesan masuk dan keluar dari BizTalk Server 2006, serta pemrosesan alur, termasuk kemampuan Pemetaan.

Sekuat apa adanya, Ekstensi BizTalk Server 2006 untuk WF SDK harus digunakan sebagai alat untuk memungkinkan pengembang WF menyebarkan alur kerja mereka di atas BizTalk Server 2006—bukan sebagai pengganti orkestrasi dalam skenario di mana kami telah mengidentifikasi BizTalk Server 2006 sebagai alat yang tepat. Ada beberapa bentuk WF yang tidak berfungsi ketika dibungkus dalam orkestrasi. Ini karena menghosting alur kerja WF Anda di dalam BizTalk Server 2006 dengan menggunakan Ekstensi BizTalk Server 2006 untuk WF SDK tidak akan memberikan perilaku hosting yang sama dengan orkestrasi asli. SDK memiliki daftar FAQ (disertakan dalam Panduan Mulai Cepat) yang menguraikan perbedaan ini.

Kesimpulan

BizTalk Server 2006 dan Windows Workflow Foundation adalah alat utama dari Microsoft untuk menerapkan solusi alur kerja dalam kategori Alur Kerja Integrasi Aplikasi dan Perusahaan. Untuk memilih mana yang tepat untuk proyek Anda, Anda harus mengidentifikasi skenario alur kerja mana yang Anda targetkan.

Selanjutnya, gunakan tabel di Gambar 8 untuk melihat teknologi alur kerja yang direkomendasikan untuk skenario Anda. Untuk alur kerja dalam aplikasi, kami merekomendasikan WF. Untuk sebagian besar proses bisnis berbasis server dan skenario B2B, kami merekomendasikan BizTalk Server 2006.

Gambar 8. Teknologi alur kerja khusus skenario

Untuk skenario Proses Bisnis Jangka Panjang dan Agregator Layanan Web, salah satu teknologi dapat diterapkan secara afektif. Untuk skenario ini, Anda harus menilai profil APIO target saat ini dan mendekati jangka waktu organisasi Anda. Organisasi yang berada di atau bergerak menuju profil Tingkat Lanjut atau Dinamis harus menggunakan BizTalk Server 2006 untuk skenario ini. Organisasi di profil Dasar dan Standar dapat menggunakan WF secara efektif untuk skenario ini.

Terakhir, Anda harus mempertimbangkan tanggal rilis dan masa pakai solusi yang diinginkan, relatif terhadap peta jalan produk untuk BizTalk Server 2006 dan WF. Dengan menggunakan kerangka kerja ini dan panduan dalam artikel ini, Anda harus dapat memilih alur kerja yang tepat untuk proyek Anda.

Tambahan

Menghilangkan Kesalahpahaman Tentang BizTalk Server 2006 vs. WF

Berikut ini adalah beberapa kesalahpahaman umum mengenai WF dan BizTalk Server 2006, dan argumen klarifikasi yang kami gunakan untuk menghilangkannya:

  • WF adalah pengganti BizTalk Server 2006.No. Karena WF adalah penawaran "terbaru dan terbesar" dari Microsoft untuk alur kerja pemrograman, banyak yang tidak terbiasa dengan BizTalk Server 2006 awalnya mengasumsikan bahwa itu telah dibuat usang dengan rilis WF. Jawaban sederhana untuk memperbaiki kesan ini adalah bahwa WF adalah kerangka kerja pengembang tingkat rendah untuk membangun semua jenis alur kerja, sementara BizTalk Server 2006 adalah produk server lengkap dengan fitur canggih untuk kategori skenario alur kerja tertentu: Integrasi Perusahaan. (Lihat Gambar 1.)
    WF hanya menyediakan subset kecil dari fungsionalitas ini: Alur Kerja dan Aturan Bisnis. Meskipun WF mungkin solusi yang lebih sederhana dan lebih hemat biaya untuk skenario yang tidak memerlukan semua fitur lain yang disediakan BizTalk Server 2006, sama sekali tidak mendukung BizTalk Server 2006 untuk skenario Integrasi Perusahaan inti yang dirancang untuk didukung BizTalk Server 2006.
  • BizTalk Server akan hilang.No. Kesalahpahaman serupa adalah kesan bahwa karena WF dirilis sebagai alat alur kerja di masa depan, dan BizTalk Server belum ditulis ulang untuk menggunakan WF, Microsoft tidak lagi berinvestasi di BizTalk Server dan akhirnya akan menggantinya dengan produk berbasis WF baru. Ini bukan masalahnya; BizTalk Server telah menjadi produk yang sangat sukses, dan area Integrasi Perusahaan yang ditargetkannya terus menjadi area yang berkomitmen untuk didukung Microsoft.
  • Anda harus memilih BizTalk Server 2006 melalui .NET Framework.No. Mungkin menggoda bagi pengembang .NET yang tidak terbiasa dengan BizTalk Server 2006 untuk memilih WF daripada BizTalk Server 2006, hanya berdasarkan bahwa mereka lebih suka "murni" .NET. Namun, ini benar-benar bukan kriteria yang berguna; BizTalk Server 2006 sendiri dibangun di atas .NET Framework.
    Bahkan, BizTalk Server 2006 mewakili lebih dari 2 juta baris kode .NET yang dapat diterapkan ke solusi Anda—menghemat waktu, masalah, dan biaya pengembangan fungsionalitasnya dari awal. Selain itu, pemrograman BizTalk Server 2006 itu sendiri dilakukan di dalam Microsoft Visual Studio .NET, dan komponen dikompilasi dan disebarkan sebagai rakitan .NET. Selain itu, proyek BizTalk Server 2006 yang paling signifikan menggabungkan komponen BizTalk Server 2006 dengan komponen .NET kustom; jadi, pengembangan BizTalk Server 2006 harus dianggap sebagai pengembangan .NET khusus, alih-alih sesuatu yang asing atau berbeda.
    Pertanyaan sebenarnya adalah apakah fitur BizTalk Server 2006 memberikan nilai yang cukup untuk skenario alur kerja tertentu Anda untuk membenarkan biaya lisensi. Anda tidak ingin menggunakan palu untuk menggantung gambar; Anda juga tidak ingin menggunakan palu tukang kayu untuk menghancurkan batu besar.
  • Fitur terbanyak menang.Pilihan yang buruk. Kami dapat memasang matriks fitur yang membandingkan fitur terperinci WF dengan yang ada di BizTalk Server 2006. Namun, perbandingan ini tidak akan sangat membantu; BizTalk Server 2006 memiliki sejumlah besar fitur yang ditargetkan khusus di ruang Integrasi Perusahaan. Jika itu bukan skenario target Anda, perbandingan fitur tidak akan berarti. BizTalk Server 2006 mungkin akan menang, dalam hal jumlah kotak centang fitur; namun, ini adalah perbandingan apel-ke-jeruk, jika fitur-fitur tersebut tidak terkait dengan skenario alur kerja yang Anda targetkan.

Pengakuan

Saya ingin berterima kasih kepada Paul Andrew dan Kris Horrocks, dan semua orang yang meninjau artikel ini.

Informasi Selengkapnya

Tentang penulis

Kent Brown adalah direktur dan arsitek senior Dari Praktik Integrasi Perusahaan di dua puluhsix New York, mitra konsultasi Bersertifikat Microsoft Gold di New York City. Dia telah bersemangat tentang BizTalk Server sejak awalnya pada tahun 2000, dan telah memainkan peran penginjil di sekitar produk selama tujuh tahun terakhir. Kent adalah anggota Tim Spesialis Teknis Virtual Microsoft BizTalk, serta Microsoft Connected Systems Developer MVP. Dia adalah pendiri dan pemimpin Grup Pengguna Sistem Terhubung NYC (http://www.NYCCSUG.org).