Diagram Konteks Template Template ini menunjukkan Diagram Konteks. Ini dibuat dalam diagram ConceptDraw PRO dan perangkat lunak gambar vektor menggunakan Block Diagram Solution dari area Diagram of ConceptDraw Solution Park. Diagram konteks secara grafis mengidentifikasi sistem. Faktor eksternal, dan hubungan di antara mereka. Its tingkat tinggi melihat sistem. Diagram konteks banyak digunakan dalam rekayasa perangkat lunak dan rekayasa sistem untuk merancang sistem yang memproses informasi. Gunakan solusi Data Flow Diagram dari area Pengembangan Perangkat Lunak ConceptDraw Solution Park untuk menggambar DFD tingkat konteks Anda sendiri dengan menggunakan perangkat lunak diagram dan gambar vektor ConceptDraw PRO. Data Flow Diagram secara grafis mewakili transfer informasi dan langkah-langkah proses suatu sistem. Mereka secara visual menggambarkan bagaimana data diproses oleh sebuah sistem dalam hal input dan output, bagaimana terjadi input dalam suatu sistem, bagaimana data mengalir melalui sistem informasi dan dimana mereka disimpan, dan bagaimana terjadi keluaran dari sistem. DFD memberikan gambaran umum tentang sistem dan memodelkan aspek proses, mereka dipelihara dengan metode analisis sistem terstruktur lainnya. Tujuan utama DFD adalah tercapainya pemahaman antara pengembang dan pengguna. Untuk konstruksi mereka digunakan dua notasi - Gane-Sarson dan Yourdon, masing-masing menggunakan seperangkat simbolnya sendiri. Aliran Data Diagram solusi dari area Pengembangan Perangkat Lunak memperluas perangkat lunak ConceptDraw PRO dengan template, sampel, dan perpustakaan yang telah ditentukan sebelumnya dari simbol diagram alir data untuk kedua notasi tersebut, sehingga memudahkan Anda merancang model berorientasi proses dan berorientasi data, menggambar Diagram Aliran Data, Data Flowchart, Diagram Proses Data, Diagram Aliran Informasi, Diagram Analisis Terstruktur, dan lain-lain. Aliran Data Diagram (DFD) menggambarkan aliran data melalui sistem informasi, memvisualisasikan bagaimana informasi ditangani dalam hal input dan output, bagaimana data Masuk ke sistem dan tinggalkan. Hal ini efektif untuk menggunakan Data Flow Diagram untuk pembuatan ikhtisar sistem, untuk menunjukkan cakupan dan batasan sistem. Ada dua jenis notasi berbeda untuk DFD: Yourdon-Coad dan Gane-Sarson, yang berbeda dalam representasi visual untuk proses, arus data, penyimpanan data, entitas eksternal, dll. Jadi, misalnya, proses digambarkan sebagai lingkaran di Yourdon - Coad notasi dan sebagai kotak bulat dalam notasi Gane-Sarson. Notasi Gane-Sarson biasanya digunakan untuk sistem informasi visualisasi dan Yourdon-Coad - untuk analisis dan disain sistem. Solusi Data Flow Diagram yang disertakan pada area Pengembangan Perangkat Lunak ConceptDraw Solution Park menawarkan banyak template DFD, contoh dan contoh, perpustakaan stensil vektor untuk konstruksi tanpa usaha DFD sesuai dengan notasi Gane-Sarson dan Yourdon-Coad. Data Flow Diagram (DFD) adalah jenis bagan khusus yang memungkinkan secara grafis menggambarkan arus data melalui suatu sistem informasi. Jadi Data Flow Diagram dapat berhasil digunakan untuk visualisasi pengolahan data atau desain terstruktur, untuk membuat gambaran umum sistem, untuk pemodelan proses bisnis, untuk mengeksplorasi perancangan tingkat tinggi dalam hal arus data dan mendokumentasikan arus data utama. Penyertaan solusi Data Flow Diagram yang hebat ke area Pengembangan Perangkat Lunak ConceptDraw Solution Park menjadikan ConceptDraw PRO sebagai perangkat data flow diagram yang bermanfaat dan menyediakannya dengan banyak koleksi template cepat mulai, sampel yang dirancang oleh profesional, dan berbagai pilihan siap pakai untuk - Menggunakan objek vektor yang terdiri dari Data Flow Diagram, Gane-Sarson Notation, dan Yourdon and Coad Notation libraries. Gunakan aplikasi ConceptDraw PRO untuk merancang Diagram Aliran Data yang mudah dan cepat termasuk penyimpanan data, arus data, entitas eksternal, transformasi fungsional, transformasi dan sinyal kontrol. Data Flow Diagram (DFD) adalah metodologi analisis struktur grafis dan perancangan sistem informasi, yang menggambarkan sumber eksternal berkenaan dengan sistem, penerima data, fungsi logika, arus data dan data store yang diakses. DFD memungkinkan untuk mengidentifikasi hubungan antara berbagai komponen sistem dan digunakan secara efektif dalam analisis bisnis dan analisis sistem informasi. Mereka berguna untuk pemodelan tingkat tinggi sistem, untuk menunjukkan bagaimana data masukan ditransformasikan ke hasil keluaran melalui urutan transformasi fungsional. Untuk deskripsi diagram DFD menggunakan dua notasi Yourdon dan Gane-Sarson, yang berbeda dalam sintaksnya. Contoh DFD Store Online menggambarkan Diagram Alir Data untuk toko online, interaksi antara Pelanggan, Pengunjung, Penjual, menggambarkan basis data Pengguna dan arus Informasi Situs Web. ConceptDraw PRO yang disempurnakan dengan solusi Data Flow Diagram memungkinkan Anda untuk menggambar contoh DFD yang jelas dan sederhana untuk Toko Online dengan menggunakan perpustakaan khusus dari simbol DFD yang telah ditentukan. Metode Analisis dan Desain Sistem Terstruktur (abbr. SSADM) adalah metode yang dikembangkan di Inggris Raya dan diterima pada tahun 1993 sebagai standar nasional untuk pengembangan dan analisis sistem informasi. SSADM didasarkan pada Data Flow Diagram dan ditandai dengan adanya urutan langkah yang jelas dalam memproyeksikan, menganalisa, dan mendokumentasikan sistem informasi. Ini melibatkan 6 tahap utama: analisis sistem yang ada atau estimasi kepraktisan, definisi persyaratan, penentuan persyaratan teknis dan biaya peralatan, pengembangan model data logis, memproyeksikan persyaratan logis dan spesifikasi mereka, proyeksi fisik. Masing-masing juga terbagi dalam beberapa tahap yang menentukan tugas yang harus dipenuhi pada tahap tertentu. Unsur-unsur SSADM yang paling penting adalah pemodelan arus dengan bantuan DFD, pemodelan logika data dengan bantuan LDS (Struktur Data Logis) dan deskripsi perilaku entitas. Penerapan SSADM mudah dengan perangkat lunak ConceptDraw PRO diagram dan vektor gambar dan solusi Flow Diagram Data. Data Flow Diagram (DFD) merupakan bagian dari Structured Systems Analysis and Design Methodology (SSADM), yang ditujukan untuk proyeksi dan analisis sistem informasi. Data Flow Diagram memungkinkan secara grafis mewakili arus data dalam sistem informasi dan menganalisa pengolahan data selama proyeksi struktural. Diagram jenis ini memungkinkan secara visual menampilkan sebuah karya sistem informasi dan hasil dari karya ini, sering digunakan dalam kaitannya dengan proses manusia dan dapat ditampilkan sebagai diagram Workflow. Data Flow Diagram memvisualisasikan proses dan fungsi, entitas eksternal, penyimpanan data, dan arus data yang menghubungkan elemen-elemen ini dan menunjukkan arah dan karakter data. Masing-masing elemen yang digunakan untuk DFD memiliki notasi grafis tersendiri. Ada dua notasi untuk menggambar DFD - Yourdon Coad dan Gane Sarson. ConceptDraw PRO diperluas dengan solusi Data Flow Diagram (DFD) dari area Software Developmant yang ideal untuk merancang DFD profesional, yang kemudian dapat dengan mudah diekspor dalam berbagai format. GET MY CONCEPTDRAW SOFTWARE Data Flow Diagram (DFD) adalah teknik analisis struktur grafis, yang menggambarkan sumber-sumber di luar sistem, penerima data, juga fungsi logis, arus data dan penyimpanan data yang diakses. Tujuan DFD adalah untuk menunjukkan bagaimana setiap proses mengubah inputnya menjadi output dan untuk mengidentifikasi hubungan antara proses ini, pada saat ini membuat deskripsi sistem menjadi jelas dan mudah dipahami pada setiap tingkat detail. Secara historis terjadi bahwa untuk menggambarkan Data Flow Diagram digunakan dua notasi - Yourdon dan Gane-Sarson yang berbeda satu sama lain dengan representasi simbol grafis. Model DFD, seperti kebanyakan model struktural lainnya adalah model hirarkis. Setiap proses dapat dikenai dekomposisi pada komponen struktural, hubungan antara notasi yang sama dapat ditunjukkan pada diagram terpisah. Biasanya, beberapa model DFD dibangun saat memodelkan sistem. Perangkat lunak ConceptDraw PRO ditingkatkan dengan solusi Flow Data Flow yang ideal sesuai untuk pembuatan model DFD dan gambar profesional Diagram Alir Data. Diagram alir data adalah satu dari tiga perspektif penting dari metode dan metode perancangan sistem terstruktur SSADM. Sponsor proyek dan pengguna akhir perlu diberi pengarahan dan konsultasi sepanjang semua tahap evolusi sistem. Dengan diagram alir data, pengguna dapat memvisualisasikan bagaimana sistem akan beroperasi, apa yang akan dilakukan sistem, dan bagaimana sistem akan diimplementasikan. Diagram alir sistem data lama dapat disusun dan dibandingkan dengan diagram alir data sistem baru untuk menarik perbandingan untuk menerapkan sistem yang lebih efisien. Diagram alir data dapat digunakan untuk memberi pengguna akhir gagasan fisik tentang di mana data yang mereka masukan pada akhirnya berpengaruh pada struktur keseluruhan sistem agar tidak dikirim ke laporan. Bagaimana sistem yang dikembangkan dapat ditentukan melalui model diagram alir data. Dalam rangka mengembangkan satu set diagram alir data yang diratakan, para analisdesigner dipaksa untuk membahas bagaimana sistem dapat didekomposisi menjadi komponen sub-sistem, dan untuk mengidentifikasi data transaksi dalam model data. Diagram alir data dapat digunakan baik dalam tahap Analisis dan Desain SDLC. Ada notasi yang berbeda untuk menggambar diagram alir data (Yourdon Coad dan Gane Sarson), menentukan representasi visual yang berbeda untuk proses, penyimpanan data, arus data, dan entitas eksternal. Diagram alir data Wikipedia DFD (Yourdon and Coad notation) Contoh Proses piutang dibuat dengan menggunakan diagram ConceptDraw PRO dan perangkat lunak gambar vektor yang diperluas dengan solusi Data Flow Diagram dari area Pengembangan Perangkat Lunak ConceptDraw Solution Park. Data Flow DiagramConceptDraw Sampel Proses bisnis Diagram alir Sampel Proses Bisnis Diagram Alur Fungsional Cross Diagram Alur Fungsional Diagram alur proses bisnis (diagram alur audit dan peluang, diagram proses lajur) dibuat dengan diagram ConceptDraw PRO dan perangkat lunak gambar vektor yang disempurnakan dengan solusi Proses Bisnis dari ConceptDraw Taman solusi ConceptDraw PRO menyediakan dokumen ekspor multipage vektor ke dalam beberapa format file: grafis vektor (SVG, EMF, EPS), grafis bitmap (PNG, JPEG, GIF, BMP, TIFF), dokumen web (HTML, PDF), presentasi PowerPoint (PPT ), Adobe Flash (SWF). Tutorial dan Solusi: Contoh 1: Flowchart Cross-Fungsional Menyediakan Layanan Telecom Sampel Sampul Cross-Fungsional: Menyediakan layanan telekomunikasi. Diagram ini dibuat di ConceptDraw PRO menggunakan perpustakaan Cross-Functional Flowchart dari solusi Cross-Functional Flowchart dari ConceptDraw Solution Park. Contoh 2: Cross-Functional Flowchart Proses Persetujuan Kredit Sampel alir Cross-Fungsional: Proses persetujuan kredit. Diagram ini dibuat di ConceptDraw PRO menggunakan perpustakaan Cross-Functional Flowchart dari solusi Cross-Functional Flowchart dari ConceptDraw Solution Park. Contoh 3: Diagram Alir Penerapan Deployment Diagram Proses Perdagangan Deployment Flowchart sample: Diagram proses perdagangan. Diagram ini dibuat di ConceptDraw PRO menggunakan perpustakaan Cross-Functional Flowchart dari solusi Cross-Functional Flowchart dari ConceptDraw Solution Park. Contoh 4: Peluang flowchart Order Processing Opportunity Flowchart sample: Order processing. Diagram ini dibuat di ConceptDraw PRO menggunakan perpustakaan Cross-Functional Flowchart dari solusi Cross-Functional Flowchart dari ConceptDraw Solution Park. Contoh 5: Diagram Proses Pemetaan Jalan Swim Proses Penggajian Diagram Diagram Proses Perabotan Jalan Diagram: Proses penggajian. Diagram ini dibuat di ConceptDraw PRO menggunakan perpustakaan Cross-Functional Flowchart dari solusi Cross-Functional Flowchart dari ConceptDraw Solution Park. Contoh 6: Flow Flow Flow Cross-Fungsional Flow Flow Diagram Cross-Functional Flowchart: Document flow. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 7: Flow Chart Website Login dan Registration Process Flow Chart contoh: Login website dan proses registrasi. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 8: Bagan Alur Peluang Mengganti Sampel Peluang Aliran Minyak Engine Flow: Mengganti oli mesin. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 9: Alur Proses Manajemen Proyek Diagram Karakter Flowchart Lintas-Fungsional: Flowchart Proses Manajemen Proyek. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 10: Menyediakan layanan telekomunikasi Sampel alir Cross-Fungsional: Menyediakan layanan telekomunikasi. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 11: Flowchart Diagram Alir Fungsional Cross-Fungsional: Diagram Alur Proses Audit. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 12: Diagram Alir Proses Persetujuan Sampel Flowchart Cross-Fungsional: Diagram alir proses persetujuan. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 13: Mengemudi ke Sampel Flowchart Cross-Fungsional Sasaran: Mengemudi ke sasaran. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 14: Flow Flow Flow Flow Flow Flow-Fungsional: Aliran proses. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 15: bagan alir diagram alir fungsional lintas fungsional: diagram alir teknis. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 16: Flowchart Online Cross-Functional Flowchart sample: Diagram alir online. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 17: Sampel Pass Class 10 Cross-Functional Flowchart sample: Pass class 10 examination. Contoh ini dibuat dengan menggunakan perangkat lunak ConceptDraw PRO diagram yang disempurnakan dengan solusi Flowchart Lintas-Fungsional dari ConceptDraw Solution Park. Contoh 18: Persetujuan Sampel Alur Cross-Fungsional: Persetujuan. Diagram ini dibuat di ConceptDraw PRO menggunakan perpustakaan Cross-Functional Flowchart dari solusi Cross-Functional Flowchart dari ConceptDraw Solution Park. Contoh 19: Identifikasi Insiden dan Pembacaan Sampel Flowchart Cross-Fungsional: Identifikasi Insiden dan Pembalakan. Diagram ini dibuat di ConceptDraw PRO menggunakan perpustakaan Cross-Functional Flowchart dari solusi Cross-Functional Flowchart dari ConceptDraw Solution Park. Contoh 20: Alur Tindakan Insureksi Flowchart Sampel Diagram Cross-Fungsional: Bagan Arus Tindakan Pemberian. Diagram ini dibuat di ConceptDraw PRO menggunakan perpustakaan Cross-Functional Flowchart dari solusi Cross-Functional Flowchart dari ConceptDraw Solution Park. Contoh 21: Proses Pengelolaan Investasi Sampel Alur Karakter Fungsional Lintas: Proses Manajemen Investasi. Diagram ini dibuat di ConceptDraw PRO menggunakan perpustakaan Cross-Functional Flowchart dari solusi Cross-Functional Flowchart dari ConceptDraw Solution Park. Contoh 22: Flowchart Sistem Stockbridge Cross-Functional Flowchart sampel: Stockbridge System Flowchart. Diagram ini dibuat di ConceptDraw PRO menggunakan perpustakaan Cross-Functional Flowchart dari solusi Cross-Functional Flowchart dari ConceptDraw Solution Park. Semua sampel adalah hak cipta CS Odessas. Penggunaannya dicakup oleh Lisensi Atribusi Non Komersial Tanpa Derivatif Creative Commons. Aplikasi yang tidak biasa jarang diisolasi. Apakah aplikasi penjualan Anda harus terhubung dengan aplikasi inventaris Anda, aplikasi pengadaan Anda harus terhubung ke situs lelang atau PDA PIM Anda harus disinkronkan dengan server kalender perusahaan, sepertinya aplikasi apa pun dapat dibuat lebih baik dengan mengintegrasikannya dengan aplikasi lain. Semua solusi integrasi harus menghadapi beberapa tantangan mendasar: Jaringan tidak dapat diandalkan. Solusi integrasi harus mengangkut data dari satu komputer ke komputer lain melalui jaringan. Dibandingkan dengan sebuah proses yang berjalan pada satu komputer, komputasi terdistribusi harus dipersiapkan untuk mengatasi masalah kemungkinan yang jauh lebih besar. Sering kali, dua sistem yang akan diintegrasikan dipisahkan oleh benua dan data di antara keduanya harus melalui jalur telepon, segmen LAN, router, switch, jaringan publik, dan tautan satelit. Masing-masing langkah ini dapat menyebabkan penundaan atau interupsi. Jaringan lambat. Mengirimkan data melalui jaringan adalah beberapa urutan yang lebih lambat daripada membuat pemanggilan metode lokal. Merancang solusi terdistribusi secara luas dengan cara yang sama seperti pendekatan tunggal bisa menimbulkan implikasi kinerja yang buruk. Dua aplikasi berbeda. Solusi integrasi perlu mengirimkan informasi antar sistem yang menggunakan bahasa pemrograman, platform operasi, dan format data yang berbeda. Solusi integrasi harus dapat berinteraksi dengan semua teknologi yang berbeda ini. Perubahan tak terelakkan. Aplikasi berubah dari waktu ke waktu. Solusi integrasi harus mengikuti perubahan dalam aplikasi yang terhubung. Solusi integrasi dapat dengan mudah terjebak dalam efek longsor perubahan jika satu sistem berubah, semua sistem lain mungkin terpengaruh. Solusi integrasi perlu meminimalkan ketergantungan dari satu sistem ke sistem lainnya dengan menggunakan kopling longgar antar aplikasi. Seiring waktu, pengembang telah mengatasi tantangan ini dengan empat pendekatan utama: File Transfer Salah satu aplikasi menulis file yang lain kemudian dibaca. Aplikasi harus menyetujui nama file dan lokasi, format file, waktu kapan akan ditulis dan dibaca, dan siapa yang akan menghapus file tersebut. Shared Database Beberapa aplikasi berbagi skema database yang sama, terletak di database fisik tunggal. Karena tidak ada penyimpanan data duplikat, tidak ada data yang harus ditransfer dari satu aplikasi ke aplikasi lainnya. Remote Procedure Invocation Satu aplikasi memaparkan beberapa fungsinya sehingga bisa diakses dari jarak jauh oleh aplikasi lain sebagai prosedur jarak jauh. Komunikasi terjadi secara real-time dan serentak. Olahpesan Satu aplikasi menerbitkan pesan ke saluran pesan umum. Aplikasi lain bisa membaca pesan dari saluran di lain waktu. Aplikasi harus menyetujui saluran dan juga format pesannya. Komunikasi itu asinkron. Sementara keempat pendekatan pada dasarnya memecahkan masalah yang sama, masing-masing gaya memiliki kelebihan dan kekurangan yang berbeda. Sebenarnya, aplikasi bisa diintegrasikan dengan menggunakan beberapa gaya sehingga masing-masing titik integrasi memanfaatkan gaya yang paling sesuai untuknya. Apa itu Pesan Buku ini adalah tentang bagaimana menggunakan pesan untuk mengintegrasikan aplikasi. Cara mudah untuk memahami pesan yang dilakukan adalah dengan mempertimbangkan sistem telepon. Panggilan telepon adalah bentuk komunikasi sinkron. Saya hanya bisa berkomunikasi dengan pihak lain jika pihak lain tersedia saat saya melakukan panggilan. Pesan suara di sisi lain, memungkinkan komunikasi asinkron. Dengan voice mail, saat penerima tidak menjawab, si penelepon bisa meninggalkan pesan kepadanya nanti si penerima (pada kenyamanannya) bisa mendengarkan pesan antri di kotak posnya. Pesan suara memungkinkan pemanggil untuk meninggalkan pesan sekarang sehingga penerima dapat mendengarkannya nanti, yang jauh lebih mudah daripada mencoba memanggil dan menelepon di telepon secara bersamaan. Bungkusan surat suara (setidaknya sebagian) panggilan telepon ke sebuah pesan dan mengantri untuk konsumsi nanti, pada dasarnya, bagaimana pesan bekerja. Messaging adalah teknologi yang memungkinkan komunikasi program-ke-program berkecepatan tinggi, asinkron dengan pengiriman yang andal. Program berkomunikasi dengan mengirimkan paket data yang disebut message s ke satu sama lain. Channel s, juga dikenal sebagai antrian, adalah jalur logis yang menghubungkan program dan menyampaikan pesan. Saluran bertindak seperti koleksi atau rangkaian pesan, namun ada yang digabungkan secara ajaib di beberapa komputer dan dapat digunakan bersamaan dengan beberapa aplikasi. Pengirim atau produser adalah program yang mengirim pesan dengan menulis pesan ke saluran. Penerima atau konsumen adalah program yang menerima pesan dengan membaca (dan menghapusnya) dari saluran. Pesan itu sendiri hanyalah semacam struktur data seperti string, array byte, catatan, atau objek. Hal itu bisa diartikan hanya sebagai data, seperti deskripsi perintah yang akan dipanggil pada receiver, atau sebagai deskripsi dari suatu peristiwa yang terjadi pada pengirim. Sebuah pesan sebenarnya berisi dua bagian, sebuah header dan sebuah badan. Header berisi meta-informasi tentang messagewho yang mengirimnya, kemana arahnya, dan sebagainya. Informasi ini digunakan oleh sistem pesan dan sebagian besar (tapi tidak selalu) diabaikan oleh aplikasi yang menggunakan pesan. Tubuh berisi data yang sedang dikirim dan diabaikan oleh sistem pesan. Dalam percakapan, saat pengembang aplikasi yang menggunakan pesan berbicara tentang sebuah pesan, hes biasanya mengacu pada data di badan pesan. Asynchronous messaging architectures sangat kuat, namun mengharuskan kita untuk memikirkan kembali pendekatan pembangunan kita. Dibandingkan dengan tiga pendekatan integrasi lainnya, relatif sedikit pengembang yang memiliki keterpaparan pada sistem pesan dan pesan. Akibatnya, pengembang aplikasi pada umumnya tidak begitu mengenal idiom dan kekhasan dari platform komunikasi ini. Apa itu kemampuan Messaging System Messaging yang biasanya disediakan oleh sistem perangkat lunak terpisah yang disebut sistem pesan atau middleware berorientasi pesan (MOM). Sistem pesan mengatur perpesanan dengan cara sistem basis data mengelola persistensi data. Sama seperti administrator harus mengisi database dengan skema untuk data aplikasi, administrator harus mengkonfigurasi sistem pesan dengan saluran yang menentukan jalur komunikasi antara aplikasi. Sistem pesan kemudian mengkoordinasikan dan mengelola pengiriman dan penerimaan pesan. Tujuan utama database adalah untuk memastikan setiap record data bertahan dengan aman, dan juga tugas utama sistem pesan adalah memindahkan pesan dari komputer pengirim ke komputer penerima dengan cara yang dapat diandalkan. Alasan sistem pesan diperlukan untuk memindahkan pesan dari satu komputer ke komputer lainnya adalah komputer dan jaringan yang menghubungkannya secara inheren tidak dapat diandalkan. Hanya karena satu aplikasi yang siap mengirimkan komunikasi tidak berarti aplikasi lain sudah siap untuk menerimanya. Bahkan jika kedua aplikasi sudah siap, jaringan mungkin tidak berfungsi, atau mungkin gagal mengirimkan data dengan benar. Sistem pesan mengatasi keterbatasan ini dengan berulang kali mencoba mengirimkan pesan sampai berhasil. Dalam keadaan ideal, pesan ditransmisikan dengan sukses pada percobaan pertama, namun keadaan seringkali tidak ideal. Intinya, sebuah pesan ditransmisikan dalam lima langkah: Buat Pengirim membuat pesan dan mempopulasikannya dengan data. Kirim Pengirim menambahkan pesan ke saluran. Mengirimkan Sistem pesan memindahkan pesan dari komputer pengirim ke komputer penerima, sehingga tersedia ke penerima. Menerima penerima membaca pesan dari saluran. Proses Penerima mengekstrak data dari pesan. Diagram ini mengilustrasikan kelima langkah transmisi ini, komputer mana yang melakukan masing-masing, dan langkah mana yang melibatkan sistem pesan: Transmisi Pesan Langkah demi Langkah Diagram ini juga menggambarkan dua konsep perpesanan penting: Kirim dan lupakan Pada langkah 2, aplikasi pengiriman mengirimkan pesan Ke saluran pesan Setelah pengiriman selesai, pengirim dapat melanjutkan ke pekerjaan lain sementara sistem pesan mentransmisikan pesan di latar belakang. Pengirim dapat yakin bahwa penerima pada akhirnya akan menerima pesan dan tidak harus menunggu sampai hal itu terjadi. Menyimpan dan meneruskan Pada langkah 2, saat aplikasi pengiriman mengirim pesan ke saluran pesan, sistem pesan menyimpan pesan di komputer pengirim, baik dalam memori maupun disk. Pada langkah 3, sistem pesan mengirim pesan dengan meneruskannya dari komputer pengirim ke komputer penerima, dan kemudian menyimpan pesan sekali lagi di komputer penerima. Proses store-and-forward ini dapat diulang berkali-kali, karena pesan dipindahkan dari satu komputer ke komputer lain, sampai komputer penerima masuk. Langkah membuat, mengirim, menerima, dan memproses mungkin tampak seperti overhead yang tidak perlu. Mengapa tidak hanya mengantarkan data ke penerima Dengan membungkus data sebagai pesan dan menyimpannya dalam sistem pesan, aplikasi tersebut mendelegasikan ke sistem pesan tanggung jawab untuk menyampaikan data. Karena data dibungkus sebagai pesan atomik, pengiriman bisa dicoba ulang sampai berhasil dan receiver dapat diyakinkan dengan andal menerima satu salinan data secara tepat. Mengapa Menggunakan Pesan Sekarang kita tahu pesan apa itu, kita harus bertanya: Mengapa menggunakan pesan Seperti solusi yang rumit lainnya, tidak ada jawaban sederhana. Jawaban cepatnya adalah pesan lebih cepat daripada Transfer File. Lebih baik dienkapsulasi dari pada Shared Database. Dan lebih dapat diandalkan daripada Remote Procedure Invocation. Namun, itulah awal dari keuntungan yang bisa didapat dengan menggunakan messaging. Manfaat pesan khusus meliputi: Komunikasi Jarak Jauh. Pesan memungkinkan aplikasi terpisah untuk berkomunikasi dan mentransfer data. Dua objek yang berada dalam proses yang sama hanya bisa berbagi data yang sama di memori. Mengirim data ke komputer lain jauh lebih rumit dan membutuhkan data untuk disalin dari satu komputer ke komputer lain. Ini berarti bahwa objek harus serializable, yaitu mereka dapat diubah menjadi aliran byte sederhana yang dapat dikirim melalui jaringan. Jika komunikasi jarak jauh tidak diperlukan, perpesanan tidak diperlukan solusi sederhana seperti koleksi bersamaan atau memori bersama sudah cukup. Integrasi PlatformLanguage. Saat menghubungkan beberapa sistem komputer melalui komunikasi jarak jauh, sistem ini kemungkinan menggunakan bahasa, teknologi dan platform yang berbeda, mungkin karena dikembangkan dari waktu ke waktu oleh tim independen. Mengintegrasikan aplikasi yang berbeda tersebut dapat memerlukan zona demiliterisasi middleware untuk bernegosiasi di antara aplikasi, sering menggunakan denominator umum terendah seperti file data datar dengan format yang tidak jelas. Dalam keadaan seperti ini, sistem pesan bisa menjadi penerjemah universal antara aplikasi yang bekerja dengan bahasa dan platform masing-masing dengan caranya sendiri, namun memungkinkan mereka untuk berkomunikasi melalui paradigma pesan umum. Konektivitas universal ini adalah jantung dari pola Message Bus. Komunikasi Asinkron. Pesan memungkinkan mengirim dan melupakan pendekatan terhadap komunikasi. Pengirim tidak harus menunggu penerima menerima dan memproses pesan sehingga tidak perlu menunggu sistem pesan untuk menyampaikan pesan. Pengirim hanya perlu menunggu pesan dikirim, mis. Agar pesan berhasil disimpan di saluran oleh sistem pesan. Begitu pesan disimpan, pengirim kemudian bebas melakukan pekerjaan lain saat pesan ditransmisikan di latar belakang. Penerima mungkin ingin mengirim pengakuan atau hasil kembali ke pengirim, yang memerlukan pesan lain, yang pengirimannya perlu dideteksi oleh mekanisme panggilan balik pada pengirim. Waktu Variabel Dengan komunikasi sinkron, penelpon harus menunggu penerima menyelesaikan pemrosesan panggilan sebelum pemanggil dapat menerima hasilnya dan melanjutkan. Dengan cara ini, pemanggil hanya bisa melakukan panggilan secepat receiver bisa melakukannya. Di sisi lain, komunikasi asinkron memungkinkan pengirim melakukan permintaan batch ke penerima dengan kecepatannya sendiri, dan agar penerima dapat mengkonsumsi permintaan dengan kecepatan berbeda sendiri. Hal ini memungkinkan kedua aplikasi berjalan pada throughput maksimal dan tidak membuang waktu menunggu satu sama lain (setidaknya sampai receiver kehabisan pesan untuk diproses). Throttling. Masalah dengan panggilan prosedur jarak jauh adalah terlalu banyak dari mereka pada satu penerima sekaligus dapat membebani receiver. Hal ini dapat menyebabkan penurunan kinerja dan bahkan menyebabkan receiver macet. Komunikasi asinkron memungkinkan penerima untuk mengendalikan tingkat di mana ia mengkonsumsi permintaan, agar tidak terlalu banyak dipenuhi oleh permintaan simultan. Efek buruk pada penelepon yang disebabkan oleh throttling ini diminimalkan karena komunikasi bersifat asinkron, sehingga penelepon tidak terhalang menunggu di receiver. Komunikasi yang Handal. Pesan menyediakan pengiriman yang andal sehingga panggilan prosedur jarak jauh (RPC) tidak dapat dilakukan. Alasan olahpesan lebih dapat diandalkan daripada RPC adalah perpesanan menggunakan pendekatan store dan forward untuk mentransmisikan pesan. Data dikemas sebagai pesan, yaitu atom, unit independen. Saat pengirim mengirim pesan, sistem pesan menyimpan pesan. Kemudian mengirimkan pesan tersebut dengan meneruskannya ke komputer receiver, tempat penyimpanannya kembali. Menyimpan pesan di komputer pengirim dan komputer penerima dianggap bisa diandalkan. (Agar lebih dapat dipercaya lagi, pesan dapat disimpan ke disk, bukan memori lihat Guaranteed Delivery). Yang tidak dapat diandalkan meneruskan (memindahkan) pesan dari komputer pengirim ke komputer penerima, karena penerima atau jaringan mungkin tidak Berjalan dengan baik Sistem pesan mengatasi hal ini dengan mengirim ulang pesan sampai berhasil. Percobaan otomatis ini memungkinkan sistem pesan untuk mengatasi masalah dengan jaringan sehingga pengirim dan penerima tidak perlu khawatir dengan rincian ini. Operasi yang Terputus. Beberapa aplikasi secara khusus dirancang untuk berjalan terputus dari jaringan, namun untuk melakukan sinkronisasi dengan server saat koneksi jaringan tersedia. Aplikasi semacam itu digunakan pada platform seperti komputer laptop, PDA, dan dasbor mobil. Pesan sangat ideal untuk memungkinkan aplikasi ini disinkronkan agar disinkronisasi bisa antri saat dibuat, menunggu sampai aplikasi terhubung kembali ke jaringan. Mediasi. Sistem pesan bertindak sebagai mediator dalam pola Mediator GoF antara semua program yang dapat mengirim dan menerima pesan. Aplikasi dapat menggunakannya sebagai direktori aplikasi atau layanan lain yang tersedia untuk diintegrasikan. Jika sebuah aplikasi diputuskan dari yang lain, hanya perlu menyambung kembali ke sistem pesan, bukan ke semua aplikasi perpesanan lainnya. Sistem pesan dapat digunakan untuk menyediakan sejumlah besar koneksi terdistribusi ke sumber daya bersama, seperti database. Sistem pesan dapat menggunakan sumber daya yang berlebihan untuk menyediakan ketersediaan tinggi, beban keseimbangan, mengubah rute sekitar koneksi jaringan yang gagal, dan menyempurnakan kinerja dan kualitas layanan. Manajemen thread Komunikasi asinkron berarti bahwa satu aplikasi tidak harus memblokir sambil menunggu aplikasi lain melakukan tugas, kecuali jika menginginkannya. Alih-alih menghalangi menunggu jawaban, pemanggil bisa menggunakan callback yang akan mengingatkan si pemanggil saat jawabannya tiba. (Lihat pola Permintaan-Balas.) Sejumlah besar benang yang diblokir, atau benang yang diblokir untuk waktu yang lama, dapat menjadi masalah. Terlalu banyak benang yang diblokir dapat meninggalkan aplikasi dengan benang yang tersedia terlalu sedikit untuk melakukan pekerjaan nyata. Jika sebuah aplikasi dengan beberapa nomor dinamis dari thread yang diblokir mogok, saat aplikasi memulai ulang dan memulihkan keadaan semula, membangun kembali benang tersebut akan sulit dilakukan. Dengan callback, satu-satunya benang yang menghalangi adalah sejumlah kecil pendengar yang menunggu balasan. Ini membuat sebagian besar benang tersedia untuk pekerjaan lain dan menentukan sejumlah benang pendengar yang diketahui dapat dengan mudah dipasang kembali setelah terjadi benturan. Jadi, ada sejumlah alasan yang berbeda mengapa aplikasi atau perusahaan dapat memanfaatkan pesan. Beberapa di antaranya adalah rincian teknis yang paling sering dikaitkan dengan pengembang aplikasi, sedangkan keputusan strategis lainnya adalah yang paling sesuai dengan arsitek perusahaan. Manakah dari alasan ini yang paling penting tergantung pada persyaratan aplikasi khusus Anda saat ini. Mereka memiliki semua alasan bagus untuk menggunakan pesan, jadi manfaatlah alasan mana pun yang paling menguntungkan Anda. Tantangan Asynchronous Messaging Pesan asinkron bukanlah obat mujarab integrasi. Ini menyelesaikan banyak tantangan dalam mengintegrasikan sistem yang berbeda dengan cara yang elegan namun juga mengenalkan tantangan baru. Beberapa tantangan ini melekat pada model asinkron sementara tantangan lainnya berbeda dengan implementasi spesifik sistem pesan. Model pemrograman yang kompleks. Pesan asinkron mengharuskan pengembang untuk bekerja dengan model pemrograman berbasis event. Logika aplikasi tidak bisa lagi dikodekan dalam satu metode yang memanggil metode lain, namun logika sekarang terbagi menjadi sejumlah event handler yang merespons pesan masuk. Sistem seperti ini lebih kompleks dan sulit dikembangkan dan debug. Misalnya, pemanggilan metode sederhana dapat meminta pesan permintaan dan saluran permintaan, pesan balasan dan saluran balasan, pengenal korelasi dan antrian pesan yang tidak valid (seperti yang dijelaskan dalam Request-Reply). Urutan masalah. Saluran pesan menjamin pengiriman pesan, namun tidak menjamin kapan pesan akan terkirim. Hal ini dapat menyebabkan pesan yang dikirim secara berurutan untuk keluar dari urutan. Dalam situasi dimana pesan bergantung satu sama lain, perawatan khusus harus dilakukan untuk membangun kembali urutan pesan. Skenario sinkron. Tidak semua aplikasi bisa beroperasi dalam mode send and forget. Jika pengguna mencari tiket penerbangan, dia pasti ingin segera melihat harga tiketnya, bukan setelah beberapa waktu yang belum ditentukan. Oleh karena itu, banyak sistem pesan perlu menjembatani kesenjangan antara solusi sinkron dan asinkron. (Lihat pola Permintaan-Balas.) Kinerja. Sistem pesan menambahkan beberapa overhead ke komunikasi. Dibutuhkan usaha untuk membuat data menjadi pesan dan mengirimkannya, dan untuk menerima pesan dan mengolahnya. Jika Anda harus mengangkut sebagian besar data, membaginya menjadi potongan kecil yang kecil mungkin bukan ide yang cerdas. Misalnya, jika solusi integrasi perlu menyinkronkan informasi antara dua sistem yang ada, langkah pertama biasanya mereplikasi semua informasi yang relevan dari satu sistem ke sistem lainnya. Untuk langkah replikasi data massal seperti itu, alat ETL (ekstrak, transformasi, dan beban) jauh lebih efisien daripada pesan. Pesan paling sesuai untuk menjaga sistem tetap sinkron setelah replikasi data awal. Dukungan platform terbatas. Banyak sistem pesan eksklusif tidak tersedia di semua platform. Sering kali lebih mudah untuk FTP file ke platform lain daripada mengaksesnya melalui sistem pesan. Vendor lock-in Banyak implementasi sistem pesan bergantung pada protokol proprietary. Bahkan spesifikasi pesan umum seperti JMS tidak mengendalikan pelaksanaan solusi secara fisik. Akibatnya, sistem pesan yang berbeda biasanya tidak terhubung satu sama lain. Ini bisa membuat Anda mendapat tantangan integrasi yang baru: mengintegrasikan beberapa solusi integrasi (lihat pola Messaging Bridge). Pesan asinkron tidak memecahkan semua masalah, dan bahkan bisa membuat beberapa masalah baru. Ingat konsekuensi ini saat menentukan masalah yang harus dipecahkan dengan menggunakan pesan. Berpikir Asynchronously Messaging adalah teknologi asinkron, yang memungkinkan pengiriman dicoba ulang sampai berhasil. Sebaliknya, sebagian besar aplikasi menggunakan fungsi serentak memanggil misalnya: prosedur yang memanggil sub prosedur, satu metode yang memanggil metode lain, atau satu prosedur yang memanggil yang lain dari jarak jauh melalui panggilan prosedur jarak jauh (RPC) (seperti CORBA dan DCOM). Panggilan sinkron menyiratkan bahwa proses pemanggilan dihentikan sementara sub-proses menjalankan fungsi. Bahkan dalam skenario RPC, di mana prosedur sub-prosedur yang disebut dijalankan dalam proses yang berbeda, penelepon memblokir sampai sub-procedure mengembalikan kontrol (dan hasilnya) ke pemanggil. Saat menggunakan pesan asinkron, pemanggil menggunakan pendekatan kirim dan lupakan yang memungkinkannya terus mengeksekusi setelah mengirimkan pesan. Akibatnya, prosedur panggilan terus berjalan sementara sub prosedur sedang dipanggil. Semantik Panggilan Synchronous dan Asynchronous Asynchronous communication memiliki sejumlah implikasi. Pertama, kita tidak lagi memiliki satu thread eksekusi. Beberapa thread memungkinkan sub-prosedur berjalan bersamaan, yang dapat meningkatkan kinerja dan membantu memastikan beberapa sub-proses mengalami kemajuan bahkan sementara sub-proses lainnya mungkin menunggu hasil eksternal. Namun, benang bersamaan juga bisa membuat debugging jauh lebih sulit. Kedua, hasil (jika ada) tiba via callback. Hal ini memungkinkan pemanggil untuk melakukan tugas lain dan diberi tahu saat hasilnya tersedia, yang dapat meningkatkan kinerja. Namun, pemanggil harus bisa memproses hasilnya bahkan saat berada di tengah tugas lain, dan harus bisa menggunakan hasilnya untuk mengingat konteks di mana telepon dibuat. Ketiga, sub-proses asinkron dapat dijalankan dengan urutan apapun. Sekali lagi, ini memungkinkan satu sub-prosedur membuat kemajuan bahkan sementara yang lain tidak dapat melakukannya. Tapi itu juga berarti bahwa subproses harus dapat berjalan secara independen dalam urutan apapun, dan pemanggil harus dapat menentukan hasil mana yang berasal dari sub-proses dan menggabungkan hasilnya. Jadi komunikasi asinkron memiliki beberapa keunggulan namun memerlukan pemikiran ulang bagaimana sebuah prosedur menggunakan sub-prosedurnya. Aplikasi Terdistribusi vs Integrasi Buku ini membahas tentang integrasi perusahaan untuk mengintegrasikan aplikasi independen sehingga mereka dapat bekerja sama. Aplikasi enterprise sering menggabungkan arsitektur n-tier (versi yang lebih canggih dari arsitektur clienterver) yang memungkinkannya didistribusikan ke beberapa komputer. Meskipun ini menghasilkan proses pada mesin yang berbeda berkomunikasi satu sama lain, ini adalah distribusi aplikasi, bukan integrasi aplikasi. Mengapa arsitektur n-tier mempertimbangkan distribusi aplikasi dan bukan integrasi aplikasi Pertama, bagian komunikasi digabungkan erat dan saling bergantung satu sama lain, sehingga satu tingkat tidak dapat berfungsi tanpa yang lain. Kedua, komunikasi antar tingkatan cenderung sinkron. Ketiga, aplikasi (n-tier atau atomic) cenderung memiliki pengguna manusia yang hanya akan menerima respon sistem yang cepat. Sebaliknya, aplikasi terintegrasi adalah aplikasi independen yang masing-masing dapat dijalankan dengan sendirinya, namun berkoordinasi satu sama lain dengan cara yang digabungkan secara longgar. Hal ini memungkinkan setiap aplikasi untuk fokus pada satu perangkat fungsionalitas yang komprehensif namun juga mendelegasikan ke aplikasi lain untuk fungsionalitas terkait. Aplikasi terpadu yang berkomunikasi secara asinkron tidak harus menunggu respons yang bisa mereka lakukan tanpa respon atau melakukan tugas lainnya secara bersamaan sampai respon tersedia. Aplikasi terpadu cenderung memiliki batasan waktu yang luas, sehingga bisa bekerja pada tugas lain sampai hasilnya tersedia, dan karena itu lebih sabar daripada kebanyakan pengguna manusia yang menunggu waktu nyata untuk sebuah hasil. Sistem Pesan Komersial Manfaat nyata untuk mengintegrasikan sistem menggunakan solusi perpesanan asinkron telah membuka pasar yang signifikan bagi vendor perangkat lunak yang menciptakan middleware pesan dan alat yang terkait. Kami kira-kira bisa mengelompokkan produk vendor messaging ke dalam empat kategori berikut: Sistem Operasi. Pesan telah menjadi kebutuhan umum sehingga vendor mulai mengintegrasikan infrastruktur perangkat lunak yang diperlukan ke dalam sistem operasi atau platform basis data. Misalnya, sistem operasi Microsoft Windows 2000 dan Windows XP mencakup perangkat lunak layanan Microsoft Message Queuing (MSMQ). Layanan ini dapat diakses melalui sejumlah API, termasuk komponen COM dan namespace System. Messaging, bagian dari platform Microsoft. Similarly, Oracle offers Oracle AQ as part of its database platform. Application Servers. Sun Microsystems first incorporated the Java Messaging Service (JMS) into version 1.2 of the J2EE specification. Since then, virtually all J2EE application servers (such as IBM WebSphere, BEA WebLogic, etc.) provide an implementation for this specification. Also, Sun delivers a JMS reference implementation with the J2EE JDK. EAI Suites. Products from these vendors offer proprietarybut functionally richsuites that encompass messaging, business process automation, workflow, portals, and other functions. Key players in this marketplace are IBM WebSphere MQ, Microsoft BizTalk, TIBCO, WebMethods, SeeBeyond, Vitria, CrossWorlds, and others. Many of these products include JMS as one of the many client APIs they support, while other vendorssuch as SonicSoftware and Fioranofocus primarily on implementing JMS-compliant messaging infrastructures. Web Services Toolkits. Web services have garnered a lot of interest in the enterprise integration communities. Standards bodies and consortia are actively working on standardizing reliable message delivery over web services (i. e. WS-Reliability, WS-ReliableMessaging, and ebMS). A growing number of vendors offer tools that implement routing, transformation, and management of web services-based solutions. The patterns in this book are vendor-independent and apply to most messaging solutions. Unfortunately, each vendor tends to define their own terminology when describing messaging solutions. In this book we have striven to choose pattern names that are technology - and product-neutral, yet descriptive and easy to use conversationally. Many messaging vendors have incorporated some of this books patterns as features of their products, which simplifies applying the patterns and accelerates solution development. Readers who are familiar with a particular vendors terminology will most likely recognize many of the concepts in this book. To help these readers map the pattern language to the vendor-specific terminology, the following tables map the most common pattern names to their corresponding product feature names in some of the most widely-used messaging products. Enterprise Integration Patterns Java Message Service (JMS) Pattern Form This book is structured as a set of patterns organized into a pattern language. Books such as Design Patterns . Pattern Oriented Software Architecture . Core J2EE Patterns . and Patterns of Enterprise Application Architecture have popularized the concept of using patterns to document computer-programming techniques. Christopher Alexander pioneered the concept of patterns and pattern languages in his books A Pattern Language and A Timeless Way of Building . Each pattern represents a decision that the reader must make and the considerations that go into that decision. A pattern language is a web of related patterns where each pattern leads to others, guiding the reader through the decision making process. This approach is a powerful technique for documenting an experts knowledge so that it can be readily understood and applied by non-experts. A pattern language teaches the reader how to solve a limitless variety of problems within a bounded problem space. Because the overall problem that is being solved is different every time, the path through the patterns and how theyre applied is also unique. In this way, this book was written for anyone using any messaging tools for any application, but can be applied specifically for you and the specific application of messaging that you are facing. Just using the pattern form does not guarantee that a book contains a wealth of knowledge. It is not just enough to simply say, When you face this problem, apply this solution. For a reader to truly learn from a pattern, it has to document why the problem is difficult to solve, consider possible solutions that in fact dont work well, and explain why the solution offered is the best available. Likewise, the patterns need to connect to each other so as to walk the reader from one problem to the next. In this way, the pattern form can be used to teach the reader not just what solutions to apply, but how to solve problems the author could not have predicted. These are goals we strive to accomplish in this book. Patterns should be prescriptive, meaning that they should tell you what to do. They dont just describe a problem, and they dont just describe how to solve it, they tell you what to do to solve it. Each pattern represents a decision the reader must make: Should I use Messaging Would a Reply Message help me here The point of the patterns and the pattern language is to help the reader make decisions that lead to a good solution for his specific problem, even if the authors didnt have that specific problem in mind, and even if the reader doesnt have the knowledge and experience to develop that solution on his own. There is no one universal pattern form different books use various structures. We used a style that is fairly close to the Alexandrian form, which was first popularized for computer programming in Smalltalk Best Practice Patterns by Kent Beck. We like the Alexandrian form because it results in patterns that are more prose-like. As a result, even though each pattern follows an identical, well-defined structure, the format avoids headings for each individual sub-section, which disrupt the flow of the discussion. To improve navigability, the format uses style elements such as bolding, indentation, and pictures to help the reader identify important sections even at a quick glance. This pattern language uses the following pattern structure: Name This is an identifier for the pattern that indicates what the pattern does. We chose names that can easily be used in a sentence that describes applying the pattern so that it is easy to reference the patterns concept in a conversation between designers. Icon Many patterns are associated with an icon in addition to the pattern name. Because many architects are used to communicating visually by using diagrams, we wanted to provide a visual language in addition to the verbal language. This visual language underlines the composability of the patterns as multiple pattern icons can be combined to describe the solution of a larger, more complex pattern. Context This explains what you might be working on that would make you likely to run into the problem that this pattern solves. The context sets the stage for the problem and often refers to other patterns you may have already applied. Problem This explains the difficulty you are facing, expressed as a question youre asking yourself, which this pattern solves. You should be able to read the problem statement and quickly determine if this pattern is relevant to your work. Weve formatted the problem to be one sentence, bold and indented. Forces The forces explore the constraints that make the problem difficult to solve. If it were easy, you wouldnt need a pattern. They often consider alternative solutions that seem promising but dont pan out, which helps show the value of the real solution. Solution This is a template that explains what you should do to solve the problem. It is not specific to your particular circumstances, but describes what to do in the variety of circumstances represented by the problem. If you understand a patterns problem and solution, you understand the pattern and dont necessarily need to read the other sections. Weve formatted the solution to be one sentence, bold and indented. Sketch One of the most appealing properties of the Alexandrian form is that each pattern contains a sketch that illustrates the solution. In many cases, just by looking at the pattern name and the sketch you can understand the essence of the pattern. We tried to maintain this style by inserting a solution picture, or sketch, after the solution statement of each pattern. Results This part expands upon the solution to explain the details of how to apply the solution and how it resolves the forces. It also addresses new challenges that may arise as a result of applying this pattern. Next This section lists other patterns to be considered after applying the current one. Patterns dont live in isolation the application of one pattern usually leads you to new problems that are solved by other patterns. This is what makes the collection a pattern language and not just a pattern catalog. Sidebars These sections discuss more detailed technical issues or variations of the pattern. We set these sections visually apart from the remainder of the text so you can easily skip them if they are not be relevant to your particular application of the pattern. Examples A pattern usually includes one or more examples of the pattern being applied or having been applied. An example may be as simple as naming a known use or as detailed as a large segment of sample code. Given the large number of available messaging technologies, we do not expect readers to be familiar with each technology used to implement an example. Therefore, we designed the patterns so that you can safely skip the example without loosing any critical content of the pattern. The beauty in describing solutions as patterns is that it not only teaches the reader how to solve the specific problems discussed, but also how to create designs that solve problems the authors were not even aware of. As a result, these patterns for messaging describe not only messaging systems that exist today, but may also apply to new ones created well after this book is published. Diagram Notation Integration solutions consist of many different piecesapplications, databases, endpoints, channels, messages, routers, etc. If we want to describe an integration solution, we need to define a notation that accommodates all these different components. To our knowledge, there is no widely used, comprehensive notation that is geared towards the description of all aspects of an integration solution. The Unified Modeling Language (UML) does a fine job of describing object-oriented systems with class and interaction diagrams, but it does not contain semantics to describe messaging solutions. The UML Profile for EAI UMLEAI enriches the semantics of collaboration diagrams to describe message flows between components. This notation is very useful as a precise visual description of a system that can serve as the basis for code generation as part of a model-driven architecture (MDA). We decided not to adopt this notation for two reasons. First, the UML Profile does not capture all the patterns described in our pattern language. Second, we were not looking to create a precise visual specification, but images that have a certain sketch quality to them. We wanted pictures that are able to convey the essence of a pattern to the reader at a quick glancevery much like Alexanders sketch . Thats why we decided to create our own notation. Luckily, unlike the more formal notation, ours does not require you to read a large manual. A simple picture should suffice: Visual Notation for Messaging Solutions This simple picture shows a message being sent to a component over a channel. We use the word component very loosely hereit can indicate an application that is being integrated, an intermediary that transforms or routes the message between applications, or a specific part of an application. Sometimes, we also depict a channel as a three-dimensional pipe if we want to highlight the channel itself. Often times we are more interested in the components and draw the channels as simple lines with arrow heads. The two notations are equivalent. We depict the message as a small tree with a round root and nested, square elements. The tree elements can be shaded or colored to highlight their usage in a particular pattern. Many messaging systems allow messages to contain tree-like data structures, for example XML documents. Also, depicting messages in this way allows us to provide a quick visual description of transformation patternsit will be easy to show a pattern that adds, re-arranges or removes fields from the message. When we describe application designsfor example, messaging endpoints or examples written in C or Javawe do use standard UML class and sequence diagrams to depict the class hierarchy and the interaction between objects. The UML notation is widely accepted as the standard way of describing these types of solutions (if you need a refresher on UML, have a look at UML ). Examples and Interludes We have tried to underline the broad applicability of the patterns by including implementation examples using a variety of integration technologies. The potential downside of this approach is that you may not be familiar with each technology that is being used in an example. Thats why we made sure that reading the examples is strictly optional all relevant points are discussed in the pattern description. Therefore, you can safely skip the examples without risk of losing out on important detail. Also, where possible, we provided more than one implementation example using different technologies. When presenting example code we focused on readability over runnability. A code segment can help remove any potential ambiguity left by the solution description and many application developers and architects prefer looking at 30 lines of code as opposed to reading many paragraphs of text. To support this intent we often only show the most relevant methods or classes of a potentially larger solution. We also omitted most forms of error checking to highlight the core function implemented by the code. Most code snippets do not contain in-line comments as the code is explained in the paragraphs before and after the code segment. Providing a meaningful example for a single integration pattern is challenging. Enterprise integration solutions typically consist of a number of heterogeneous components, spread across multiple systems. Likewise, most integration patterns do not operate in isolation but rely on other patterns to form a meaningful solution. To highlight the collaboration between multiple patterns we included more comprehensive examples as interludes at the end of the major sections of the book. These solutions illustrate many of the trade-offs involved in designing a more comprehensive messaging solution. All code samples should be treated as illustrative tools only and not as a starting point for development of an integration solution. For example, almost all examples lack any form of error checking or concern for robustness, security, or scalability. We tried as much as possible to base the examples on software platforms that are available free of charge or as a trial version. In some cases, we used commercial platforms (such as TIBCO ActiveEnterprise or Microsoft BizTalk) to illustrate the difference between developing a solution from scratch and using a commercial tool. We presented those example in such a way that they are educational even if you do not have access to the required run-time platform. For many examples, we use relatively bare-bones messaging frameworks such as JMS or MSMQ. This allows us to be more explicit in the example and focus on the problem at hand instead of distracting from it with all the features a more complex middleware toolset may provide. The Java examples in this book are based on the JMS 1.1 specification, which is part of the J2EE 1.4 specification. By the time this book is published, most messaging and application server vendors will support JMS 1.1. You can download Suns reference implementation of the JMS specification from Suns Web site: java. sunj2ee . The Microsoft examples are based on Version 1.1 of the Framework and are written in C. You can download the Framework SDK from Microsofts Web site: msdn. microsoftnet . Organization of this Book The pattern language in this book, as with any pattern language, is a web of patterns referring to each other. At the same time, some patterns are more fundamental than others, forming a hierarchy of big-concept patterns that lead to finer-detailed patterns. The big-concept patterns form the load-baring members of the pattern language. They are the main ones, what we term root patterns . that provide the foundation of the language and support the other patterns. This book groups patterns into chapters by level-of-abstraction and by topic area. The following diagram shows the root patterns and their relationship to the chapters of the book. Relationship of Root Patterns and Chapters The most fundamental pattern is Messaging thats what this whole book is about. It leads to the six root patternswhich are in the Messaging Systems chapternamely Message Channel . Message . Pipes and Filters . Message Router . Message Translator . and Message Endpoint . In turn, each of these root patterns leads to its own chapter in the book (except Pipes and Filters . which is not specific to messaging but is the basis of the routing and transformation patterns). The pattern language is divided into eight chapters, which follow the hierarchy described above: Chapter 1: Integration Styles This chapter reviews the different approaches available for integrating applications, including Messaging . Chapter 2: Messaging Systems This chapter reviews the six root messaging patterns, giving an overview of the entire pattern language. Chapter 3: Messaging Channels Applications communicate via channels. Channels define the logical pathways a message can follow. This chapter shows how to determine what channels your applications need. Chapter 4: Message Construction Once you have message channels, you need messages to send on them. This chapter explains the different ways messages can be used and how to take advantage of their special properties. Chapter 5: Message Routing As a messaging topography becomes more complex, senders know less and less about who should receive their messages. Rather, they send the messages to intermediate applications that send them to others until the messages finally find their way to their final destination. This chapter teaches you the responsibilities of these routing applications. Chapter 6: Message Transformation Independently developed applications often dont agree on messages formats, on the form and meaning of supposedly unique identifiers, and even the character encoding to be used. Therefore, intermediate components are needed to convert messages from the form one application produced to that which other applications will consume. This chapter shows how to design these transformer applications. Chapter 7: Messaging Endpoints Many applications were not designed to participate in a messaging solution. As a result, they must be explicitly connected to the messaging system. This section describes a messaging layer in the applications that is responsible for sending and receiving the messages, making your application an endpoint for messages. Chapter 8: System Management Once we have a messaging system in place to integrate our applications, how do we make sure that its running correctly and doing what we want This chapter explores how to test and monitor a running messaging system. These eight chapters go together to teach you what you need to know about connecting applications using messaging. Getting Started With any book that has a lot to teach, its hard to know where to start, both for the authors and the readers. Reading all of the pages straight through assures covering the entire subject area, but isnt the quickest way to get to the issues that are of the most help. Starting with a pattern in the middle of the language can be like starting to watch a movie thats half over you see whats happening but dont understand what it means. Luckily, the pattern language is formed around root patterns (as described earlier). These root patterns collectively provide an overview of the pattern language, and individually provide starting points for delving deep into the details of messaging. To get an overall survey of the language without reviewing all of the patterns, start with reviewing the root patterns. To jump into the middle of the language, jump in at a root pattern, a place where the language has finished discussing one major topic and is now starting another. Chapter 1: Integration Styles provides an overview of the four main application integration techniques and settles on Messaging as being the best overall for many integration opportunities. Read this chapter if you are unfamiliar with issues involved in application integration and the pros and cons of the various approaches that are available. If you just want to know whats so great about messaging, go straight to that pattern. If youre already convinced that messaging is the way to go and want to get started with how to use messaging, you can skip the first chapter completely. Chapter 2: Messaging Systems contains all of this pattern languages root patterns (except Messaging . which is in the first chapter). For an overview of the pattern language, read (or at least skim) all of the patterns in this chapter. To dive deep on a particular topic, read its root pattern, then go to the patterns mentioned in its next section at the end of the pattern those next patterns will all be in a chapter named after the root pattern. The root patterns in this language are: Messaging This is the 1 root pattern for the entire book: What is messaging, what problem does it solve, and how does it solve it Message Channel What is the structure in a messaging system that conveys messages from the sender to the receiver How do you know which ones your applications need Message How does information get communicated from a sender to a receiver Pipes and Filters How can intermediate steps be performed after a message is sent but before it is received Message Router If the sender does not know ultimately where the message should go, how can the messaging system get it there Message Translator If the sender and receiver do not agree on the message format, how can they communicate Message Endpoint How do the applications that send and receive messages connect to the messaging system After the first two chapters, different types of messaging developers may be most interested in different chapters, based on the specifics of how each group uses messaging to perform integration: System Administrators may be most interested in Chapter 3: Messaging Channels . the guidelines for what channels to create, and Chapter 8: System Management . guidance on how to maintain a running messaging system. Application Developers should look at Chapter 7: Messaging Endpoints to learn how integrate an application with a messaging system, and Chapter 4: Message Construction to learn what messages to send when. System Integrators will gain the most from Chapter 5: Message Routing how to direct messages to the proper receiversand Chapter 6: Message Transformation how to convert messages from the senders format to the receivers. Keep in mind that when reading a pattern, if youre in a hurry, start by just reading the problem and solution (the two sentences in bold). This will give you enough information to determine if the pattern is of interest to you right now, and if you already know the pattern. If you do not know the pattern and it sounds interesting, go ahead and read the other parts. Also remember that this is a pattern language, so the patterns are not necessarily meant to be read in the order theyre presented in the book. The books order teaches you about messaging by considering all of the relevant topics in turn and discussing related issues together. To use the patterns to solve a particular problem, start with an appropriate root pattern. Its context explains what patterns need to be applied before this one, even if theyre not the ones immediately preceding this one in the book. Likewise, the next section (the last paragraph of the pattern) describes what patterns to consider applying after this one, even if theyre not the ones immediately following this one in the book. Use the web of interconnected patterns, not the linear list of book pages, to guide you through the material. Supporting Web Site Please look for companion information to this book plus related information on enterprise integration at our Web site: enterpriseintegrationpatterns. You can also e-mail your comments, suggestions and feedback to us at authorsenterpriseintegrationpatterns. You should now have a good understanding of the following concepts which are fundamental to the material in this book: What messaging is What a messaging system is Why to use messaging How asynchronous programming is different How application integration is different from application distribution What types of commercial products contain messaging systems You should also have a feel for how this book is going to teach you how to use messaging: The role patterns have in structuring the material The meaning of the custom notation used in the diagrams The purpose and scope of the examples The organization of the material How to get started learning the material Now that you understand the basic concepts and how the material will be presented, you are now ready to start learning how to integrate applications using messaging. Ingin tetap up-to-date Ikuti My Blog. Ingin membaca lebih dalam secara mendalam Check out My Articles. Ingin melihat saya tinggal Lihat dimana saya berbicara selanjutnya. Temukan deskripsi lengkap dari pola ini: Pola Integrasi Enterprise Gregor Hohpe dan Bobby Woolf ISBN 0321200683 650 halaman Addison-Wesley Dari Integrasi Enterprise ke Transformasi Enterprise: Buku baru saya menjelaskan bagaimana arsitek dapat memainkan peran penting dalam transformasi TI dengan menerapkan teknik, Komunikasi, dan kemampuan organisasi dengan 37 episode dari perusahaan IT skala besar. Bagian dari halaman ini tersedia dengan lisensi Creative Commons Attribution. Anda dapat menggunakan kembali ikon pola, nama pola, pernyataan masalah dan solusi (dalam huruf tebal), dan sketsa di bawah lisensi ini. Bagian lain dari teks, seperti teks atau teks pola lengkap, dilindungi oleh hak cipta.
No comments:
Post a Comment