Dengan artikel ini saya ingin membuka siri khusus untuk IBM WebSphere ESB(selepas ini dirujuk sebagai ESB) dalam konteks pembangunan untuk produk ini. Dan, pertama sekali, anda perlu menjadi lebih biasa dengan teknologi seperti ini.
Bas perkhidmatan perusahaan (enterprise service bus) ialah perisian tengah yang menyediakan pemesejan dipacu peristiwa terpusat dan bersatu antara pelbagai sistem maklumat berdasarkan prinsip seni bina berorientasikan perkhidmatan.
Sudah tentu, anda boleh membina sistem korporat berdasarkan pendekatan ini tanpa perisian khas (anda mungkin masih perlu membangunkan sesuatu yang umum) dan memanggil produk yang dihasilkan sebagai bas perkhidmatan. Tetapi produk daripada IBM bukan sahaja mempunyai alat siap sedia untuk pemesejan terpusat dan kawalan proses ini, tetapi juga set penuh keupayaan untuk membangunkan aplikasi berorientasikan perkhidmatan yang fleksibel khusus untuk ESB. Akibatnya, kemungkinan berikut boleh dikenal pasti: kelebihan IBM WebSphere ESB:

• Susunan dan keseragaman sambungan seni bina
• Pengurusan berpusat
• Konfigurasi aplikasi sisi pelayan
• Pelaksanaan teknologi Seni Bina Komponen Perkhidmatan (SCA) dalam semangat prinsip seni bina berorientasikan perkhidmatan
• Kebebasan protokol bagi kod program yang dibangunkan
• Pilihan konfigurasi bas dan aplikasi yang luas

Pada masa yang sama, ESB menyediakan kawalan transaksi, penukaran data, keselamatan dan penghantaran mesej yang terjamin. Akses kepada semua orang jabatan perkhidmatan melalui satu titik membolehkan anda mengkonfigurasi komunikasi perkhidmatan secara berpusat. Anda juga boleh mengurus peristiwa kegagalan secara berpusat untuk pengendalian ralat pukal.
Topologi pemasangan ESB klasik ialah kluster yang menyediakan kebolehskalaan mendatar dan toleransi kesalahan. Menurut cadangan rasmi, menambah bilangan ahli kluster meningkatkan prestasi dengan lebih berkesan daripada meningkatkan kuasa pelayan dalam topologi yang berdiri sendiri. Di samping itu, kluster boleh dibut semula (atau sebahagian daripadanya boleh gagal) tanpa menghentikan perkhidmatan.
Lazimnya, ESB digunakan sebagai lapisan perkhidmatan dalam IBM BPM, tetapi ia mungkin memainkan peranan utama dalam membina model interaksi antara sistem korporat sebagai peranti penyepaduan yang berkuasa (bermaksud ESB sebagai tambahan kepada Pelayan Aplikasi IBM WebSphere) .
Ini, sebenarnya, diperlukan daripada ESB, kerana ia adalah "titik pengumpulan perkhidmatan" - jika anda memerlukan perkhidmatan yang akan berfungsi dengan perkhidmatan lain (mungkin luaran), maka tempat yang paling logik untuk melakukan penyepaduan antara perkhidmatan ini adalah dihidupkan. ESB. Untuk perkhidmatan luaran atau heterogen, anda boleh membungkusnya dengan perkhidmatan ESB. Marilah kita menggambarkan secara ringkas kemudahan menggunakan "perumahan tunggal" untuk perkhidmatan:

Pesanan
Lebih besar sistem, lebih penting susunan dan keseragaman. Jika kita bercakap tentang kompleks sistem perusahaan besar, maka ia pasti boleh dipanggil sistem bersaiz besar. Sudah tentu, anda sentiasa boleh mencari pentadbir yang mempunyai dalam kepalanya gambar rajah interaksi ratusan pelayan, atau sekumpulan jumlah dokumentasi yang tidak berkaitan untuk setiap modul perisian, yang menerangkan perkara dan cara ia berinteraksi.


Tetapi lebih mudah untuk mempunyai perkhidmatan (ESB) yang membolehkan semua interaksi berlaku melalui dirinya sendiri. Dengan pendekatan ini, sebahagian daripada seni bina interaksi dalam mana-mana subsistem sudah jelas - tidak ada kekacauan dalam sambungan antara sistem, pelayan dan aplikasi: semuanya disambungkan ke ESB dan ESB disambungkan kepada segala-galanya.

Pengurusan berpusat
Ia sentiasa lebih mudah untuk mengkonfigurasi sistem secara berpusat - sama ada konfigurasi, penyesuaian kepada pelayan yang bergerak, memastikan toleransi kesalahan, pengagihan beban, pengendalian ralat atau pemantauan dan analitik.


Sebagai contoh, apabila memindahkan pelayan pangkalan data, anda tidak perlu pergi ke konfigurasi semua pelayan aplikasi sedia ada, dan ke dalam tetapan aplikasi tertentu khususnya - cukup untuk mempunyai satu pembolehubah persekitaran dalam ESB, yang menentukan pangkalan data alamat, dan kemudian perubahan perlu dibuat pada satu titik sahaja.
Atau jika salah satu daripada sistem luaran tidak tersedia untuk masa yang lama, dan tidak ada satu permintaan pun yang akan hilang - anda boleh menggunakan perkhidmatan untuk memproses acara yang gagal untuk "membuang" mesej yang tidak dihantar apabila ia sesuai.
Jika anda perlu mengawal bilangan permintaan serentak kepada mana-mana sistem, atau memantau permintaan ini, menganalisis beban, mencari kesesakan, anda perlu pergi ke pusat kawalan pemesejan - ke konsol pelayan ESB.

Konfigurasi sisi pelayan
"Rumah tunggal" untuk perkhidmatan, dari perspektif konfigurasi, mencapai beberapa matlamat berguna. Yang pertama ialah penggunaan semula konfigurasi (serupa dengan penggunaan semula kod dan modul yang sangat berguna dalam SOA), kerana modul yang berbeza dan aplikasi boleh menggunakan parameter sambungan pangkalan data yang sama, sumber, parameter pengesahan, Pembolehubah Persekitaran Dan sebagainya.


Kedua, apabila mengkonfigurasi pada bahagian pelayan, persekitaran operasi aplikasi yang boleh mempengaruhi sebahagian besarnya, yang membolehkan anda memindahkan aplikasi antara litar yang berbeza (ujian dan pengeluaran), menala dan juga membetulkan pepijat tanpa membuat perubahan pada aplikasi.

Dengan memanfaatkan semua faedah ini, aplikasi menjadi seperti bunglon—ia sangat fleksibel sehingga menjadi sebahagian daripada persekitaran di mana ia beroperasi, sambil tetap menyampaikan fungsi penting.

Tetapi fleksibiliti aplikasi yang berjalan pada IBM WebSphere ESB tidak terhad kepada persekitaran di mana ia dijalankan. Keupayaan pembangunan memberi sumbangan besar kepada ini. Memandangkan sistem bukan sahaja perlu tersedia, tempat untuk dijalankan, tetapi juga perlu dibangunkan dan diperhalusi, perkara-perkara menarik ini tidak boleh dilepaskan:

SCA
Seni bina ini adalah berdasarkan prinsip bahawa komponen menyediakan fungsinya sebagai perkhidmatan yang tersedia untuk komponen lain. Dalam satu modul, komponen adalah blok perisian (kod java) yang melaksanakan sepenuhnya fungsi tertentu yang diterangkan oleh antara muka yang sepadan. Logik pelaksanaan komponen dilaksanakan dengan menghubungkannya ke dalam struktur berdasarkan antara muka dan rujukan (Rujukan Rakan Kongsi).

Struktur modul ini sangat mudah untuk dibangunkan, diuji, dibangunkan, diubah dan diselenggara. Keatoman fungsi yang dilaksanakan dalam komponen membolehkan anda mengendalikan komponen secara keseluruhan tanpa turun ke tahap kod. Sebaliknya, ia secara logiknya perlu kerana pelaksanaan komponen dalam konteks transaksi.
Setiap komponen mempunyai antara muka (s) yang pelaksanaannya disediakan. Oleh itu, apabila menyambungkan komponen bersama-sama, tidak perlu mengetahui ciri dalaman mereka - sudah cukup bahawa mereka melaksanakan antara muka yang diperlukan.
Menggunakan seni bina ini, ia juga mungkin untuk menyelesaikan semua masalah yang memerlukan kerja selari, tanpa kawalan benang "manual" (contohnya, anda boleh membuat panggilan tak segerak ke beberapa komponen dengan respons tertunda).
Komponen bukan java, contohnya, jenis Eksport dan Import, membolehkan anda menyediakan perkhidmatan untuk kegunaan luaran atau menggunakan perkhidmatan luaran, masing-masing; Komponen Aliran Pengantaraan menyediakan akses peringkat rendah kepada mesej yang ditukar antara komponen lain dan membenarkan pelbagai transformasi apabila bekerja dengan antara muka heterogen.
Selain antara muka, rangka kerja objek perniagaan IBM menyediakan keupayaan yang sangat berguna. Objek perniagaan (BO), diwakili oleh gambar rajah xsd, digunakan sebagai objek untuk memindahkan data dalam antara muka, kedua-dua antara komponen dan untuk komunikasi antara modul. Mereka disepadukan secara langsung, sebagai contoh, ke dalam skema wsdl untuk menerangkan perkhidmatan web. Iaitu, sebagai contoh, jika modul "A" menyediakan fungsinya dalam bentuk perkhidmatan web, untuk menggunakannya, modul "B" hanya perlu menyambungkan antara muka dan BO yang sudah siap, dan ia akan dapat berfungsi sepenuhnya. dengan perkhidmatan sedemikian tanpa mencipta sebarang java -objek tambahan untuk penghantaran data. BO juga mudah digunakan semasa menukar data dengan pangkalan data, jika data ini digunakan oleh komponen lain (ini, sudah tentu, bertentangan dengan corak "DAO", tetapi menghapuskan objek java yang tidak perlu dan operasi menulis semula data "bolak-balik" ).

Protokol-kebebasan kod program
Seperti yang anda lihat, kebebasan protokol bagi kod dicapai dengan menggunakan komponen Eksport dan Import. Oleh kerana komunikasi dengan komponen ini berlaku melalui antara muka dan rujukan, kod program adalah bebas sepenuhnya daripada protokol yang digunakan untuk interaksi. Fungsi yang sama boleh disediakan dengan mudah melalui sebarang bilangan protokol yang disokong dan pada mana-mana antara muka yang diperlukan. Angka berikut menunjukkan penambahan eksport dengan pengikatan SCA kepada komponen yang sudah mendedahkan antara mukanya sebagai perkhidmatan HTTP, JMS dan Web.


Kelebihannya adalah jelas - fleksibiliti, serba boleh, penggunaan semula kod, kelajuan pembangunan dan pengubahsuaian.
Dengan cara ini, pengikatan SCA menggunakan protokol khas dan bertujuan untuk komunikasi antara modul dalam pelayan/kluster yang sama. Komunikasi melalui pengikatan ini kurang intensif sumber dan lebih cepat daripada protokol lain.

Konfigurasi
Konfigurasi pelayan dan aplikasi dijalankan melalui konsol IBM pelayan.
ESB, seperti IBM WebSphere secara amnya, mempunyai banyak keupayaan dan artifak khusus. Sebagai contoh, apabila menggunakan import dan eksport yang sama, anda boleh mengkonfigurasi titik akhir perkhidmatan yang sepadan "dengan cepat". Untuk panggilan perkhidmatan, anda boleh mengkonfigurasi set dasar dengan pelbagai peraturan (contohnya, anda boleh memasang sokongan untuk mekanisme WS-AT, yang membolehkan anda memanggil perkhidmatan web dalam transaksi yang sama di mana pelanggan sedang berjalan; tetapi transaksi adalah satu topik untuk artikel penuh), tetapkan parameter pengesahan, sambungkan sijil, dsb.
Melalui konfigurasi, anda boleh mengkonfigurasi beberapa mekanisme untuk bertindak balas secara automatik kepada situasi luar biasa (contohnya, secara automatik mengulangi pelaksanaan komponen sekiranya berlaku ralat). Anda boleh mengkonfigurasi pengesanan komponen atau menukar tahap pembalakan dengan cepat. Perkhidmatan pengurusan acara kegagalan juga tersedia, yang boleh digunakan secara sengaja untuk pengendalian ralat pukal.
Dan, sudah tentu, anda boleh mengkonfigurasi banyak perkara lain mengikut spesifikasi Java2EE, yang kadang-kadang agak ketat, dilaksanakan dalam Pelayan Aplikasi IBM.

Semua perkara di atas menetapkan ESB sebagai peranti penyepaduan yang mudah, berkuasa dan fleksibel, walaupun tidak selalu mudah dipelajari. Pada masa hadapan, anda hanya perlu belajar cara menggunakannya.

Imej berikut digunakan dalam artikel:

Apabila menyepadukan sistem korporat, tugas mengurus data rujukan timbul. Untuk menyelesaikan masalah ini, Master Data Management (MDM) sering digunakan. MDM ialah repositori yang mengandungi data rujukan "rujukan", yang dipanggil "rekod emas". Direktori dalam MDM mengandungi data yang bersih, lengkap dan konsisten.

MDM sering digunakan sebagai platform untuk pengurusan direktori berpusat. Data rujukan dimasukkan dan disahkan dalam MDM, dan dari situ ia direplikasi kepada sistem IT. Pendekatan ini mempunyai beberapa masalah

• Mewujudkan model data rujukan yang sesuai dengan semua sistem bukanlah mudah.
• Data rujukan menjadi terputus sambungan daripada aplikasi.
• Meniru data daripada MDM selalunya memerlukan pengubahsuaian sistem yang besar. Untuk sistem di luar kotak, pengubahsuaian sedemikian boleh menjadi sangat mahal.

Pendekatan lain ialah setiap sistem perniagaan menyimpan direktori secara tempatan dan mengatur kemasukan data. Apabila bertukar-tukar mesej antara sistem, bas integrasi menjalankan transformasi daripada format satu sistem kepada format yang lain. Pada masa yang sama, transformasi data rujukan berlaku.

Transformasi pada bas integrasi.

Kami menggunakan pendekatan kedua. Semua interaksi antara sistem perniagaan berlaku melalui bas integrasi. Bas (dalam kes kami, Oracle Service Bus) mengubah mesej yang sistem Pembekal hantar kepada mesej yang difahami oleh sistem Pengguna. Transformasi ini termasuk pemetaan nilai direktori.

Data tentang cara direktori dipetakan antara sistem disimpan dalam pangkalan data hubungan, dalam kes kami Oracle. Jadual akan merekodkan cara mendapatkan nilai dalam sistem lain daripada nilai direktori dalam satu sistem. Iaitu, beberapa jenis struktur:

(sistem_sumber, nilai_sumber, sah_daripada, sah_kepada, sistem_sasaran, nilai_sasaran)

Data dalam direktori berubah sangat jarang, tetapi digunakan sangat kerap. Untuk tidak mengakses pangkalan data setiap kali, direktori dicache pada bas, dan dalam format yang boleh digunakan oleh bas dengan segera.

Untuk caching kami menggunakan . Ini adalah produk yang sangat berbayar. Walau bagaimanapun, dalam dalam kes ini Semua ciri meganya tidak digunakan, jadi ia boleh diganti dengan mudah dengan penyelesaian percuma (contohnya, hazelcast). Anda boleh membaca lebih lanjut mengenai koherensi. Juga, lesen untuk koheren disertakan dalam pelbagai Suite Oracle.

Menggunakan cache mempunyai kelebihan yang jelas:

• data disimpan dalam ingatan
• data disimpan dalam bentuk bersiri
• data boleh diindeks
• penyegerakan dengan pangkalan data boleh dijalankan secara tak segerak

Cache diedarkan dan penyegerakan antara nod dilakukan oleh Coherence itu sendiri. Apabila pelayan ditambah atau dialih keluar, kluster mengimbangi semula data antara nod.

Skema Peta Cache Teragih digunakan untuk data rujukan. Apabila Oracle Service Bus bermula, cache dicipta di dalam JVM yang menyimpan data dalam ingatan. Pada setiap pelayan fizikal Terdapat pelayan koheren yang menyimpan direktori (dalam memori dan pada cakera) dan disegerakkan dengan pangkalan data.

Semasa transformasi, aliran kerja osb mengakses koheren melalui petak bual Java. Juga boleh diakses melalui panggilan Enterprise Java Bean.

Ciri Bas Perkhidmatan Perusahaan

Penyepaduan moden sistem maklumat ialah pelaksanaan Seni Bina Berorientasikan Perkhidmatan (SOA) menggunakan teknologi perkhidmatan Web; Terdapat banyak penerangan yang sangat baik tentang faedah dan kaedah melakukan ini (lihat bahagian ). Baru-baru ini, bas perkhidmatan perusahaan telah dianggap sebagai komponen utama infrastruktur SOA. Bas Perkhidmatan Perusahaan(ESB) (lihat bahagian). Walau bagaimanapun, adalah penting untuk mengetahui dengan tepat apa itu ESB - produk, teknologi, standard atau apa-apa lagi. Secara khusus, adakah mungkin untuk membina ESB hari ini, dan jika ya, bagaimana sebenarnya?

Artikel ini menerangkan ESB sebagai satu set fungsi infrastruktur yang dilaksanakan menggunakan teknologi perisian tengah yang menyokong SOA. ESB menyokong interaksi menggunakan perkhidmatan, mesej dan peristiwa dalam persekitaran yang heterogen, dengan tahap perkhidmatan dan kebolehkawalan yang sesuai. Dalam artikel ini kami telah mengumpulkan dan mengelaskan paling banyak pelbagai fungsi. Walau bagaimanapun, tidak perlu menggunakan semua ciri ini dalam semua situasi ESB.

Artikel itu mentakrifkan set minimum fungsi yang memastikan bahawa kebanyakan keperluan untuk ESB dipenuhi mengikut prinsip SOA. Dengan mentakrifkan set ciri minimum, kita boleh memahami teknologi mana yang tersedia boleh digunakan untuk melaksanakan ESB yang menyokong SOA. Dengan memahami fungsi tambahan yang ditentukan oleh keperluan situasi tertentu, anda boleh memilih teknologi pelaksanaan yang paling sesuai untuk situasi ini.

Artikel berikut akan menerangkan satu set senario ESB pada titik permulaan SOA biasa untuk melaksanakan ESB atau SOA. Sebaliknya, templat penyelesaian membantu memilih teknologi yang sesuai untuk pelaksanaan.

Apabila situasi di mana penyelesaian ESB digunakan berkembang, kefungsian yang diperlukan untuk ESB berkembang dengan sewajarnya. Fungsi dan ciri produk yang menggunakan ESB secara eksplisit akan berkembang sama. Oleh itu, dalam artikel akhir siri ini, kita akan melihat rangka kerja pelaksanaan SOA dan ESB untuk memberikan panduan pada peringkat pertama menggunakan ciri dan teknologi ESB dan menunjukkan kemungkinan pelaksanaan secara beransur-ansur.

Peranan ESB dalam reka bentuk SOA

Walaupun kami tidak akan mempertimbangkan takrif SOA secara terperinci (lihat bahagian), ia masih berguna untuk mengumpulkan di sini semua prinsip yang kebanyakan pengarang definisi SOA bersetuju dengan:

• Menggunakan antara muka bebas pelaksanaan secara eksplisit untuk menentukan perkhidmatan;
• Penggunaan protokol komunikasi yang meningkatkan ketelusan dan kesalingoperasian lokasi;
• Tentukan perkhidmatan yang merangkumi fungsi perniagaan boleh guna semula.

Sudah tentu, teknologi yang berbeza akan mempunyai had yang berbeza pada penggunaan fizikal templat yang mereka sokong - sesetengahnya mungkin sesuai untuk sokongan pengedaran dan penyepaduan yang sangat besar merentas kawasan geografi yang besar, manakala yang lain lebih sesuai untuk penggunaan dalam kelompok setempat dan menyokong penyelesaian yang sangat tersedia. dan kebolehskalaan. Pemetaan keperluan pengedaran fizikal bagi teknologi yang akan digunakan adalah aspek penting dalam reka bentuk ESB. Di samping itu, adalah sangat penting untuk memastikan bahawa sistem yang digunakan awal boleh dikembangkan secara berperingkat untuk mencerminkan keperluan yang berkembang, integrasi sistem tambahan atau memperluaskan ketersediaan geografi infrastruktur.

Rajah 2. Pengurusan berpusat bagi infrastruktur ESB teragih

Di samping itu, ESB harus diletakkan dalam hubungan dengan komponen infrastruktur SOA yang lain, khususnya Direktori Perkhidmatan, Koreografi Perkhidmatan Perniagaan dan komponen Gerbang Perniagaan-ke-Perniagaan (B2B). Memandangkan prinsip SOA yang disenaraikan di atas tidak memerlukan komponen ini hadir, mari kita pertimbangkan ia komponen pilihan. Infrastruktur SOA ditunjukkan menunjukkan hubungan komponen ini dengan ESB.

Rajah 3: Peranan ESB dalam reka bentuk SOA

Untuk menghalakan permintaan perkhidmatan ESB, istimewa direktori penghalaan perkhidmatan. Walau bagaimanapun, SOA mungkin juga mempunyai yang berasingan katalog perkhidmatan perniagaan, yang, dalam bentuk yang paling mudah, boleh menjadi direktori sementara (digunakan semasa pembangunan projek) yang digunakan untuk membolehkan penggunaan semula perkhidmatan oleh pembangun organisasi. Dalam paparan perkhidmatan Web, peranan direktori perkhidmatan perniagaan dan direktori penghalaan perkhidmatan diperuntukkan kepada direktori UDDI, dengan itu memastikan penemuan dinamik dan penggunaan perkhidmatan. Direktori sedemikian boleh dianggap sebagai sebahagian daripada ESB, tetapi sehingga penyelesaian sedemikian meluas, adalah lebih baik untuk memastikan direktori perkhidmatan perniagaan berasingan daripada ESB.

Fungsi komponen Koreografer Perkhidmatan Perniagaan adalah untuk susun atur proses perniagaan daripada beberapa perkhidmatan perniagaan; oleh itu, komponen ini memanggil perkhidmatan melalui ESB dan kemudian menawarkan proses perniagaan kepada pelanggan sebagai perkhidmatan lain, juga melalui ESB. Walau bagaimanapun, peranan komponen Koreografer Perkhidmatan Perniagaan, teknologi proses pembuatan, dalam menyelaraskan operasi proses dan perkhidmatan perniagaan mengenal pasti komponen ini bukan sebahagian daripada ESB, teknologi infrastruktur.

Akhir sekali, fungsi komponen B2B Gateway adalah untuk menjadikan perkhidmatan setiap dua atau lebih organisasi tersedia kepada semua organisasi lain dengan cara yang terkawal dan selamat. Adalah berguna untuk memikirkan komponen tersebut sebagai disambungkan kepada ESB, tetapi bukan sebahagian daripadanya. Walaupun terdapat pintu masuk teknologi, menyediakan fungsi yang diperlukan untuk melaksanakan kedua-dua Gerbang B2B dan komponen ESB, itu sendiri pelantikan Komponen B2B Gateway memisahkannya daripada ESB. Sesungguhnya, komponen ini mungkin memerlukan alat tambahan untuk melaksanakan fungsinya, seperti alatan pengurusan perkongsian yang bukan sebahagian daripada ESB dan tidak semestinya disokong oleh teknologi ESB.

Model Prestasi ESB

Meringkaskan dan mengklasifikasikan beberapa fungsi ESB yang diterangkan dalam literatur sedia ada (lihat bahagian ). Sesetengah ciri ini mudah, manakala yang lain, seperti autonomi dan kecerdasan, mewakili langkah penting ke arah persekitaran operasi Atas Permintaan. Adalah penting untuk memahami bahawa untuk kebanyakan kes penggunaan ESB sedia ada, hanya beberapa ciri ini daripada beberapa kategori yang diperlukan. TENTANG minimum Kami akan membincangkan set fungsi yang diperlukan untuk melaksanakan ESB dalam bahagian tersebut Set Ciri ESB minimum untuk SOA.

Jadual 1. Fungsi ESB diterangkan dalam kesusasteraan khusus

Sambungan	Interaksi perkhidmatan
Penghalaan; Menangani; Teknologi komunikasi, protokol dan piawaian (seperti IBM® WebSphere® MQ, HTTP dan HTTPS) Terbitkan/langgan; Balas/permintaan; peristiwa kebakaran-dan-lupakan; Pemesejan segerak dan tak segerak.	Definisi antara muka perkhidmatan (contohnya, bahasa WSDL (Bahasa Penerangan Perkhidmatan Web); Sokongan untuk keupayaan untuk menggantikan pelaksanaan perkhidmatan; Model organisasi perkhidmatan pemesejan yang diperlukan untuk komunikasi dan penyepaduan (contohnya, SOAP atau model perisian tengah penyepaduan aplikasi perusahaan (EAI)); Direktori perkhidmatan dan penemuan perkhidmatan.
Integrasi	Kualiti sesuatu servis
Pangkalan data; Pengagregatan perkhidmatan; Penyesuai untuk sistem dan aplikasi sedia ada; Menyediakan sambungan kepada perisian tengah EAI; Paparan perkhidmatan; Penukaran protokol; Persekitaran pelayan aplikasi (seperti J2EE dan .NET); Antara muka bahasa pengaturcaraan aplikasi untuk memanggil perkhidmatan (contohnya, Java dan C/C++/C#).	Transaksi (urus niaga tidak boleh dibahagikan, Pampasan, urus niaga WS); Pelbagai paradigma penghantaran terjamin (cth WS-ReliableMessaging atau sokongan middleware EAI).
Keselamatan	Tahap servis
Pengesahan; Kebenaran; Kemustahilan melepaskan kepengarangan; Kerahsiaan; Piawaian keselamatan (contohnya, Kerberos dan WS-Security).	Prestasi; Lebar jalur; Ketersediaan; Langkah berterusan lain yang mungkin menjadi asas kepada kontrak atau perjanjian.
Pemprosesan mesej	Kawalan dan autonomi
Logik berkod; Logik berasaskan kandungan; Transformasi mesej dan data; Semakan kesahihan; Perantara; Paparan objek yang sama; Pengayaan data.	Permulaan dan pendaftaran perkhidmatan; Pembalakan, pengukuran, pemantauan; Pengesanan; Penyepaduan dengan alat pengurusan dan pentadbiran sistem; Pemerhatian kendiri dan pengurusan diri.
Permodelan	Ciri-ciri Infrastruktur Pintar
Pemodelan objek; Model am objek perniagaan; Perpustakaan format data; Model terbuka atau tertutup untuk penyepaduan B2B; Alat pembangunan dan penggunaan.	Peraturan perniagaan; Tingkah laku didorong dasar, terutamanya untuk ciri tahap perkhidmatan, keselamatan dan kualiti perkhidmatan (cth, Polisi WS); Pengecaman corak.

Banyak fungsi ini boleh dilaksanakan menggunakan teknologi yang sesuai atau menggunakan piawaian terbuka. Tetapi teknologi yang layak untuk digunakan dalam pelaksanaan ESB boleh berbeza secara meluas dari segi prestasi, kebolehskalaan dan ketersediaan, serta ciri ESB dan piawaian terbuka yang mereka sokong. Atas sebab-sebab ini dan disebabkan oleh fakta bahawa beberapa piawaian yang bermakna telah dibangunkan baru-baru ini atau masih dalam pembangunan, banyak yang kritikal keputusan penting Pelaksanaan ESB pada masa ini melibatkan pertukaran antara menyokong teknologi matang, mantap dan standard terbuka yang kurang matang.

Saya tidak akan menerangkan secara terperinci tentang setiap kategori ciri ini dalam siri artikel ini. Sebaliknya, kami akan memberi tumpuan kepada perkara yang berkaitan dengan keputusan mengenai pilihan pendekatan untuk melaksanakan atau melaksanakan ESB. Khususnya, dalam bahagian seterusnya kita akan melihat set minimum ciri yang diperlukan untuk pelaksanaan ESB untuk menyokong SOA.

Set Ciri ESB minimum untuk SOA

Jika untuk kebanyakan senario SOA hanya subset daripada ciri yang disenaraikan sebelum ini yang berkaitan, kita boleh bertanya soalan berikut: apakah ciri yang disertakan? minimum set fungsi yang diperlukan untuk melaksanakan ESB? Untuk menjawab soalan ini, kita akan melihat elemen yang paling biasa dalam definisi ESB, yang mana terdapat sedikit perselisihan:

• ESB ialah komponen logik seni bina yang menyediakan infrastruktur penyepaduan selaras dengan prinsip SOA;
• Prinsip SOA memerlukan penggunaan antara muka bebas pelaksanaan, protokol komunikasi yang meningkatkan ketelusan susun atur dan kebolehoperasian, dan definisi perkhidmatan yang secara relatifnya terperinci dan merangkumi fungsi boleh guna semula;
• ESB boleh dilaksanakan sebagai infrastruktur heterogen yang diedarkan;
• ESB menyediakan alatan untuk mengurus infrastruktur perkhidmatan anda dan membolehkan anda beroperasi dalam persekitaran yang tersebar dan heterogen hari ini.

Berikut ialah set minimum fungsi ESB yang dipilih dengan mengambil kira prinsip ini.

Jadual 2. Set minimum fungsi ESB

Sambungan	Integrasi
Perkhidmatan penghalaan dan pengalamatan untuk memastikan ketelusan penempatan; Fungsi pentadbiran untuk mengurus pengalamatan dan penamaan perkhidmatan; Sekurang-kurangnya satu bentuk paradigma pemesejan (cth., permintaan/tindak balas, terbitkan/langgan, dsb.); Sokongan untuk sekurang-kurangnya satu protokol pengangkutan yang tersedia atau mungkin tersedia secara umum.	Menyokong berbilang penyepaduan dengan pembekal perkhidmatan, seperti penyambung Java 2, perkhidmatan Web, pemesejan tak segerak, penyesuai, dsb.
Interaksi perkhidmatan
Model pemesejan dan organisasi antara muka yang terbuka dan bebas pelaksanaan, yang harus mengasingkan kod aplikasi daripada syarat khusus penghalaan perkhidmatan dan protokol pengangkutan, serta memastikan kemungkinan menggantikan pelaksanaan perkhidmatan

Sila ambil perhatian bahawa set minimum fungsi tidak memerlukan penggunaan mana-mana teknologi tertentu cth EAI middleware, perkhidmatan Web, J2EE atau XML. Berkemungkinan teknologi sedemikian akan digunakan kerana ia memenuhi keperluan, tetapi ini tidak wajib. Sebaliknya, set fungsi minimum hampir, jika tidak sepenuhnya, disediakan mudah untuk digunakan SOAP/HTTP dan WSDL.

• pengalamatan URL dan infrastruktur sedia ada HTTP dan DNS menyediakan infrastruktur "bas" yang menyediakan penghalaan perkhidmatan dan ketelusan penempatan;
• SOAP/HTTP menyokong paradigma pemesejan permintaan-tindak balas;
• Pengangkutan protokol HTTP tersedia secara meluas;
• SOAP dan WSDL menyediakan model terbuka, bebas pelaksanaan untuk mengatur antara muka dan pemesejan perkhidmatan.

Walau bagaimanapun, menggunakan SOAP/HTTP dan WSDL dalam bentuk yang paling mudah benar-benar hanya menyediakan penyepaduan titik ke titik dan tidak menyediakan perkara berikut fungsi utama diperlukan untuk ESB:

• tidak hadir fungsi pentadbiran untuk mengawal pengalamatan dan penamaan perkhidmatan Nama perkhidmatan dikawal secara individu oleh setiap penyesuai, jadi kawalan penghalaan perkhidmatan diedarkan antara alamat yang dipanggil oleh pelanggan perkhidmatan, infrastruktur HTTP dan nama perkhidmatan yang diberikan kepada penyesuai;
• Walaupun pendekatan ini bergantung pada butiran pelaksanaan, ia tidak menyumbang kepada penyediaan pelaksanaan perkhidmatan gantian; Kod peminta perkhidmatan (mungkin dijana oleh alat pembangunan) selalunya akan dikaitkan secara langsung dengan pelaksanaan khusus pembekal perkhidmatan melalui protokol khusus pada alamat tertentu. Menggantikan pelaksanaan perkhidmatan dengan pelaksanaan lain akan memerlukan perubahan pada kod aplikasi dan penempatan semula.

Sudah tentu, banyak atau bahkan kebanyakan senario memerlukan ciri tambahan yang akan menjadi lebih biasa dari semasa ke semasa. khususnya, jenis berikut keperluan mungkin akan membawa kepada penggunaan teknologi yang lebih canggih, sekarang atau pada masa hadapan:

• Berfungsi untuk memastikan kualiti perkhidmatan dan tahap perkhidmatan;
• Konsep SOA lebih banyak tahap tinggi- koreografi perkhidmatan, katalog, transformasi, dsb.;
• Keperluan persekitaran operasi Atas Permintaan seperti autonomi dan ciri pengurusan, serta kecerdasan infrastruktur;
• Operasi yang benar-benar heterogen merentas berbilang rangkaian, berbilang protokol dan berbilang domain dengan model yang berbeza harta benda.

Isu keselamatan yang berkaitan dengan ESB

Artikel ini tidak bertujuan untuk menangani keperluan keselamatan itu sendiri, tetapi ia mungkin penting apabila memilih teknologi ESB. Sebagai contoh, jika tidak ada keperluan untuk mengesahkan dan membenarkan permintaan kepada pelayan, maka pilihan teknologi boleh menjadi sangat luas. Jika tahap keselamatan tertentu diperlukan, seperti yang lebih mungkin, maka adalah penting untuk menilai gaya keselamatan yang boleh diterima. Sebagai contoh:

1. Adakah tahap keselamatan infrastruktur komunikasi boleh diterima apabila menggunakan pengesahan bersama EAI Lapisan Soket Selamat antara pelayan perisian tengah EAI atau apabila menggunakan HTTPS?
2. Adakah keselamatan individu, titik ke titik antara sistem yang mengambil bahagian mencukupi, atau adakah model keselamatan hujung ke hujung diperlukan? Sebagai contoh, adakah terdapat keperluan untuk mengedarkan maklumat pengenalan pelanggan melalui sistem perantaraan seperti broker kepada penyedia akhir atau pelaksanaan perkhidmatan?
3. Adakah keselamatan boleh diterima pada peringkat permohonan, sebagai contoh, bolehkah kod klien dilaksanakan pengesahan asas HTTP melalui id pengguna dan kata laluan, atau adakah ia boleh menghantar maklumat ini kepada perkhidmatan sebagai data aplikasi?
4. Adakah mekanisme keselamatan perlu mematuhi piawaian keselamatan seperti Kerberos atau WS-Security?

Walaupun semua pendekatan keselamatan ini boleh dilakukan, kami mengesyorkan menggunakan ciri keselamatan yang mematuhi piawaian (seperti WS-Security) yang disokong oleh infrastruktur dan perisian tengah. Walau bagaimanapun, piawaian ini agak baharu, dan sokongan untuknya dalam produk perisian masih dalam fasa pembangunan, terutamanya dalam kes yang berkaitan dengan memastikan kesaling kendalian. Oleh itu, salah satu keutamaan seni bina ESB adalah untuk mewujudkan keperluan keselamatan awal dalam fasa pembangunan supaya ia boleh diambil kira semasa memilih teknologi pelaksanaan.

Kesimpulan

Artikel ini membincangkan prinsip paling umum SOA dan sambungannya dengan teknologi perkhidmatan Web. Berdasarkan prinsip tersebut, penulis berpendapat bahawa komponen infrastruktur yang menyediakan fungsi routing mesti memastikan interaksi perkhidmatan antara satu sama lain, serta sokongan untuk menggantikan satu pelaksanaan perkhidmatan dengan pelaksanaan yang lain. Fungsi ini, antara lain, dilaksanakan melalui ESB.

ESB menyediakan infrastruktur teragih dan fungsi pengurusan berpusat, yang memerlukan direktori penghalaan perkhidmatan dan, sebagai tambahan, mungkin direktori perkhidmatan perniagaan. Komponen Koreografer Perkhidmatan Perniagaan memanggil perkhidmatan daripada ESB dan kemudian mendedahkan proses sebagai perkhidmatan baharu melalui ESB.

Antara banyak ciri yang disediakan oleh ESB adalah seperti berikut:

• Komunikasi;
• Interaksi perkhidmatan;
• Integrasi;
• Memastikan kualiti perkhidmatan;
• Keselamatan;
• Memastikan tahap perkhidmatan;
• Pemprosesan mesej;
• Pengurusan perkhidmatan dan autonomi;
• pemodelan;
• Fungsi infrastruktur pintar.

Dalam artikel seterusnya dalam siri ini, kita akan melihat senario biasa, corak penyelesaian yang sesuai untuk senario dan membincangkan masalah paling biasa yang berkaitan dengan senario ini.

Ucapan terima kasih

Artikel ini tidak akan diterbitkan jika pengarang tidak membincangkan ideanya dengan orang berikut: Beth Hutchison, Rachel Reinitz, Olaf Zimmerman, Helen Wylie, Kyle Brown (Kyle Brown, Mark Colan, Jonathan Adams, Paul Fremantle, Keith Jones, Paul Verschueren, Daniel Sturman, Scott Cosby Cosby), Dave Clarke, Ben Mann, Louisa Gillies, Eric Herness, Bill Hassell, Guru Vasudeva, Kareem Yusuf ), Ken Wilson, Mark Endrei, Norbert Bieberstein, Chris Nott, Alan Hopkins dan Yaroslav Dunchych .

Penyepaduan aplikasi ialah isu yang lambat laun akan dihadapi oleh jabatan IT bagi mana-mana organisasi yang mempunyai lebih daripada satu aplikasi ini. Jauh sekali senarai penuh tugas yang sesuai dengan konsep "integrasi":

• keperluan untuk mengekalkan direktori am (contohnya, direktori pelanggan atau pekerja);
• melancarkan aktiviti dalam satu sistem maklumat apabila peristiwa berlaku dalam satu lagi;
• proses perniagaan (urutan tersusun tindakan yang dilakukan oleh kedua-dua orang dan sistem maklumat) yang berlaku dalam beberapa aplikasi;
• interaksi maklumat dengan rakan kongsi perniagaan (contohnya, permintaan automatik harga komponen daripada pembekal);
• penyatuan pertukaran maklumat dan proses perniagaan di cawangan syarikat.

Jika tindakan seperti ini jarang berlaku dalam perusahaan (contohnya, sekali sehari), maka tindakan ini boleh diatur secara sementara - contohnya, dengan memuat naik data secara manual daripada satu aplikasi ke Format Excel dan memuatkannya ke dalam aplikasi lain atau bahkan menggunakan input pendua maklumat ke dalam dua sistem sekaligus. Namun, jika perlu interaksi maklumat permohonan timbul berkali-kali sehari, persoalan timbul tentang penggunaan sumber manusia yang tidak berkesan dan, akibatnya, terdapat keperluan untuk mengautomasikan prosedur ini.

Penyepaduan titik ke titik

Tugas penyepaduan titik ke titik agak mudah. Adalah perlu untuk memahami bagaimana setiap satu daripada dua sistem yang berinteraksi bersedia untuk menghantar dan menerima data, mencipta penyelesaian teknikal yang sesuai untuk mengakses antara muka ini, dan juga melaksanakan mekanisme untuk menukar data daripada format sistem sumber kepada format sistem destinasi. Dalam kes terbaik, sistem maklumat menyediakan antara muka pengaturcaraan khas (API) untuk penyepaduan, dan dalam kes yang paling teruk, maklumat mesti dibaca dan ditulis terus ke dalam pangkalan data aplikasi. Akibatnya, penyelesaian penyepaduan tempatan timbul - modul perisian berasingan pembangunan kami sendiri dengan semua keperluan berikutnya untuk penyelenggaraan dan mengekalkan kaitannya.

Penyepaduan titik ke titik

Ini tidak berjumlah masalah besar selagi terdapat sedikit penyepaduan titik ke titik - satu atau dua. Walau bagaimanapun, amalan menunjukkan bahawa bilangan penyepaduan titik ke titik cenderung meningkat, dan kualiti pengurusan penyepaduan ini, sebaliknya, menurun dengan cepat. Terdapat banyak sebab untuk ini: bilangan modul integrasi semakin meningkat, pembangun yang membuat satu atau satu lagi modul meninggalkan organisasi, format data dalam sistem bersepadu berubah, dsb. Hasil yang menyedihkan daripada perkembangan evolusi penyepaduan titik ke titik adalah "daging cincang" interaksi penyepaduan yang paling kompleks antara aplikasi perusahaan, sikap terhadap pekerja jabatan IT yang paling mudah dapat dinyatakan dalam beberapa perkataan: "Selagi ia berfungsi, lebih baik jangan sentuhnya.” Walau bagaimanapun, keadaan ini tidak sesuai sama ada jabatan IT itu sendiri atau pelanggan perniagaan.

Penyepaduan pemadat

Bas perkhidmatan tunggal

Selepas mengalami beberapa generasi pendekatan berbeza untuk penyepaduan aplikasi, industri perisian global telah mencapai konsep satu Bas Perkhidmatan Perusahaan (ESB). Dari sudut pandangan seni bina, ESB adalah penyelesaian perisian, memastikan interaksi semua aplikasi bersepadu melalui satu titik, secara seragam, menyediakan pembangun dan pentadbir cara yang bersatu dan berpusat untuk membangun, menguji dan memantau kemajuan semua senario penyepaduan.

Komponen utama yang membentuk bas perkhidmatan moden ialah:

• broker mesej ialah tulang belakang berprestasi tinggi untuk bertukar-tukar mesej dalam format bersatu antara aplikasi dalam masa nyata;
• penyesuai - penyesuai teknologi dan penyesuai kepada sistem perniagaan menyediakan interaksi dengan aplikasi dalam format yang boleh diterima oleh mereka, menyampaikan maklumat daripada mesej ini dalam format bersatu yang dilihat oleh broker - lebih banyak penyesuai berbeza yang disediakan oleh platform penyepaduan tertentu, lebih besar peluang bahawa pelaksanaannya dalam organisasi anda tidak memerlukan kerja tambahan untuk mencipta penyesuai khusus untuk sistem anda;
• persekitaran untuk membangunkan senario penyepaduan - semakin mudah dan pantas pembangunan senario penyepaduan, semakin kurang pelaburan dalam pembangunan ini, dan oleh itu semakin cepat pulangan pelaburan. Bas penyepaduan moden menyediakan pembangun dengan alat visual untuk membina senario penyepaduan, yang dalam kebanyakan kes memungkinkan untuk dilakukan tanpa pengekodan peringkat rendah;
• Alat SOA - pematuhan kepada prinsip seni bina berorientasikan perkhidmatan ialah piawaian tanpa syarat untuk semua penyelesaian penyepaduan jenis "bas perkhidmatan tunggal" (seperti yang jelas dari namanya). Sistem maklumat dianggap di sini sebagai penyedia dan pengguna perkhidmatan; semua perkhidmatan yang diterbitkan dalam bas diletakkan di daftar tunggal dengan keupayaan untuk menggunakan semula dan mengurus dasar yang berkaitan dengan perkhidmatan;
• pelbagai instrumen kawalan dan pengurusan (audit, pembalakan, pemantauan berpusat, pemantauan pematuhan dengan perjanjian tahap perkhidmatan, dsb.).

Kelebihan menggunakan bas perkhidmatan tunggal termasuk:

• penskalaan - keupayaan untuk membina penyelesaian dari sebarang saiz dan beban;
• fleksibiliti - keupayaan untuk melaksanakan dan mengubah senario integrasi tanpa penglibatan ketara pembangun;
• keselamatan - alat pengesahan dan kebenaran terbina dalam menyediakan kawalan akses kepada perkhidmatan di peringkat bas itu sendiri, melegakan pembangun senario penyepaduan daripada tugas melaksanakan mekanisme ini;
• penggunaan piawaian terbuka - membolehkan anda mengurangkan penglibatan pakar mahal dalam teknologi proprietari;
• pemusatan alat kawalan dan pentadbiran - membolehkan anda mengelakkan "mengaburkan" titik tanggungjawab untuk senario penyepaduan, memastikan pemantauan operasi dan amaran awal sekiranya berlaku kegagalan.

Satu lagi keperluan penting untuk kefungsian persekitaran ESB ialah keupayaan untuk melaksanakan penyepaduan dengan organisasi luar- rakan kongsi perniagaan, pembekal, pelanggan korporat, cawangan terpencil. Ciri-ciri penyepaduan sedemikian ialah kualiti saluran yang tidak dapat diramalkan, kekurangan jaminan penyampaian maklumat dan kesediaan yang lemah untuk penyepaduan seperti itu - sebagai peraturan, organisasi rakan kongsi menyediakan pelbagai format pertukaran data yang sangat terhad. Dalam kes ini, bas integrasi mesti mengandungi alat untuk membina interaksi B2B yang membolehkan pertukaran maklumat mengikut terbuka, termasuk piawaian industri, memastikan penghantaran terjamin, mempunyai cara untuk mengkonfigurasi pertukaran maklumat dalam konteks rakan kongsi perniagaan tertentu dan, daripada Sudah tentu, bekerja mengikut sepenuhnya prinsip platform integrasi itu sendiri, mengasingkan pembangun senario integrasi daripada butiran teknikal interaksi dengan rakan kongsi.

Bas Perkhidmatan Perusahaan

Pengurusan proses perniagaan

Sebilangan besar senario penyepaduan membayangkan bahawa pertukaran maklumat melibatkan bukan sahaja aplikasi yang bertindak sebagai sumber atau penerima maklumat, tetapi juga orang - pekerja organisasi yang melaksanakan pelbagai tugas atau membuat keputusan. Dalam kes ini, kita boleh bercakap tentang melangkaui penyepaduan "tulen" dan kemunculan entiti baharu dalam tumpuan perhatian kita - proses perniagaan, dan dalam keperluan untuk platform penyepaduan - fungsi baharu untuk pengurusan proses perniagaan (Pengurusan Proses Perniagaan , BPM). Jika terdapat keperluan BPM, platform integrasi mesti menyediakan pembangun dengan:

• alat untuk reka bentuk visual proses perniagaan - adalah optimum bahawa alat ini boleh digunakan oleh orang yang jauh dari IT, contohnya, penganalisis perniagaan atau ahli metodologi. Di samping itu, keupayaan untuk memindahkan model proses perniagaan daripada alat pemodelan khusus kepada persekitaran pembangunan amat berguna. Alat yang sama harus memungkinkan untuk mereka bentuk borang tugas untuk peserta proses, melindungi pembangun sebanyak mungkin daripada pengaturcaraan;
• persekitaran pelaksanaan proses perniagaan - enjin khas yang menyediakan pemprosesan peraturan perniagaan, pemindahan tugas antara pengguna dan sistem maklumat mengikut model proses perniagaan yang dibangunkan, serta pemprosesan situasi yang luar biasa(contohnya, pelaku melebihi masa yang diperuntukkan untuk menyelesaikan tugas);
• portal peserta proses perniagaan - portal khusus yang membolehkan pengguna melancarkan proses, mengambil bahagian di dalamnya dan memantau kemajuan menjalankan proses dan menjalankan tindakan pentadbiran mengikut hak yang ditetapkan untuk mereka;
• alat pemantauan dan kawalan. Keupayaan untuk menganalisis aliran proses perniagaan dengan cepat dan retrospektif adalah bahagian penting dalam mana-mana platform BPM.

Banyak vendor perisian kini bergerak untuk menggabungkan rangka kerja BPM dan bas penyepaduan ke dalam platform perisian tengah tunggal, menghapuskan pemisahan ketat antara sistem BPM dan alat penyepaduan aplikasi yang telah wujud selama beberapa tahun. Pendekatan ini sangat progresif. Sesetengah vendor pergi lebih jauh dan menambah alat pemodelan proses perniagaan profesional pada platform. Software AG merintis perkara ini dengan penyelesaian yang menggabungkan alat pemodelan Platform ARIS yang terkenal dan persekitaran integrasi/BPM webMethods.

Penggunaan komprehensif platform integrasi

Tawaran di pasaran

hidup masa ini Terdapat tiga kumpulan tawaran perisian untuk membina ESB. Kumpulan ini berbeza dari segi harga dan kefungsian yang ditawarkan.

Kumpulan pertama ialah cadangan daripada syarikat yang produknya adalah peneraju dalam penyelidikan oleh agensi analisis dalam semua kategori yang dinyatakan dalam artikel (ESB, Tadbir Urus SOA, BPM, B2B). Kumpulan ini termasuk:

• IBM dengan barisan produk WebSpherenya;
• Perisian AG dengan platform penyepaduan webMethods;
• Oracle dengan keseluruhan siri cadangan;
• Tibco dengan barisan Integrasi Perniagaan.

Pada dasarnya, mereka yang tidak suka kompromi boleh memilih mana-mana pengeluar ini - semua syarikat tersenarai menawarkan barisan produk penuh (namun, dalam kes Oracle tidak selalu jelas produk mana yang kita bicarakan, kerana selepas membeli nombor syarikat Oracle menawarkan beberapa produk sekali gus, tidak semestinya cukup bersepadu antara satu sama lain). Tibco berdiri sedikit berbeza, memandangkan saiz syarikat ini jauh lebih kecil daripada saiz ahli lain dari empat ini, yang mungkin menimbulkan keraguan tentang kestabilannya. Software AG - belum begitu terkenal pada pasaran Rusia pengeluar, tetapi platform webMethods, yang merupakan tawaran teras syarikat hari ini, mempunyai potensi yang besar. IBM dan produknya sudah diketahui dan digunakan oleh banyak perusahaan, tetapi sesetengah daripada mereka mempunyai aduan tentang kos melaksanakan dan menyelenggara sistem.

Kumpulan cadangan kedua ialah syarikat yang memberi tumpuan terutamanya pada fungsi ESB "tulen" dan telah mencapai kejayaan di sini. Kumpulan ini termasuk: Sun (Glassfish), Progress (Sonic) dan Fujitsu.

Tawaran daripada syarikat ini adalah baik jika anda tidak berhasrat untuk mengembangkan skop platform anda ke arah BPM dan/atau B2B. Jika tidak, anda berisiko ditinggalkan dengan fungsi yang kurang dibangunkan dan meningkatkan kos anda dengan ketara untuk memperbaikinya untuk memenuhi keperluan anda.

Kumpulan ketiga adalah yang paling banyak dan termasuk semua cadangan yang tidak termasuk dalam dua kumpulan sebelumnya. Menyenaraikan semua cadangan mengenai topik ESB dalam artikel ini adalah sia-sia; anda boleh mendapatkan senarai sedemikian dalam mana-mana enjin carian. Jika belanjawan anda untuk penyepaduan adalah terhad, dan anda cenderung untuk mencuba, anda boleh mencuba nasib anda dengan mana-mana daripadanya. Walau bagaimanapun, risiko yang berkaitan dengan kefungsian yang tidak dibangunkan dengan mencukupi dan kemungkinan masalah kebolehpercayaan sokongan teknikal dan prospek pembangunan produk, anda andaikan.

Kesimpulan

Kesimpulannya, saya ingin memberikan sedikit kepada pembaca tips mudah dengan pilihan bas integrasi:

• fikirkan tentang membina penyelesaian penyepaduan tanpa menunggu isu kesalingoperasian aplikasi untuk menolak anda ke dinding. Semakin besar runtuhan, semakin sukar untuk membersihkannya;
• Pilih platform anda dengan berhati-hati. Cari vendor yang memuaskan hati anda dalam semua aspek, kerana kini terdapat banyak pilihan. Anda harus berminat dengan kedua-dua parameter teknologi platform dan aspek metodologi pelaksanaan;
• berfikir tentang masa depan. Keperluan fungsian yang anda sedari sekarang mungkin berubah dengan ketara dalam setahun, dan jika platform tidak memenuhinya, maka anda perlu "berpindah" ke yang lain. Dan satu gerakan, seperti yang anda tahu, adalah sama dengan dua kebakaran.

Dalam evolusi pesat teknologi komputer, kemungkinan baru untuk idea lama kadang-kadang didedahkan sepenuhnya tanpa diduga. Sebagai contoh, seperti, ia akan kelihatan lama dahulu ingatan yang terlupa pada teras ferit. Walaupun semua kekurangannya, kualiti positifnya ialah keupayaan untuk mengingat dan menyimpan data selama-lamanya tanpa mengecas semula - tidak seperti modul RAM semikonduktor moden. Dan kini, secara literal di hadapan mata kita, ia sedang dihidupkan semula dalam bentuk teknologi MRAM yang menjanjikan, yang juga menggunakan gelung histeresis magnet dua kedudukan. Akibatnya, ia akan mengekalkan keadaannya tanpa pemakanan. Dengan kebangkitan semula ingatan magnetik, prosedur yang biasa untuk but komputer akan menjadi perkara yang lepas.

Sesuatu yang serupa berlaku dengan lebuh raya pertukaran data yang dibina berdasarkan prinsip " bas biasa" Sekarang sukar untuk menghargai sifat revolusioner idea bas biasa, tetapi pada satu masa ia adalah revolusi sebenar. Bas Unibus biasa, yang dicadangkan tiga dekad lalu oleh jurutera di Digital Equipment Corporation sebagai asas seni bina untuk komputer mini PDP-11, ternyata menjadi cara yang sangat berkesan (dan yang paling penting, murah) untuk mengintegrasikan pelbagai jenis peranti. Selepas itu, banyak komputer dibina berdasarkan prinsip bas, termasuk semua PC moden. Sebenarnya, pasaran mula terbentuk daripada bas biasa peranti persisian. Walau bagaimanapun, dari masa ke masa, bas, yang digunakan sebagai elemen seni bina pusat komputer, mula memberi laluan kepada suis yang lebih pantas, sambil kekal sebagai salah satu pilihan utama untuk menyambungkan peranti persisian. Hari ini tayar, yang dipanggil Bas Perkhidmatan Perusahaan (ESB), boleh memainkan peranan yang lebih kurang sama seperti Unibus, dengan semua kelebihan, tetapi pada tahap yang lebih tinggi.

Acara memang berkembang pesat. Hanya setahun yang lalu, salah seorang penganalisis terkemuka Kumpulan Gartner, Efim Natis, mencadangkan perkara berikut: "Salah satu pendekatan utama untuk mencipta infrastruktur aplikasi perusahaan dibina menggunakan proses tak segerak yang digandingkan secara longgar." Dan dalam artikel InfoWorld Oktober 2002 oleh John Udell, seseorang boleh membaca: "Sekarang kita semua bersetuju bahawa perkhidmatan Web harus berkomunikasi dalam cara tidak segerak, telah menjadi jelas bahawa perisian tengah berorientasikan mesej (perisian tengah berorientasikan mesej, MOM) menjadi kritikal. ."

Seperti yang anda lihat, dalam masa setahun sahaja, andaian itu bertukar menjadi kenyataan. Perisian Sonic, yang dibentuk oleh beberapa alumni BEA Systems dan hari ini diiktiraf sebagai salah satu peneraju dalam pembangunan perisian tengah, memainkan peranan penting dalam menjayakan perkara ini. Kerja yang sangat menarik telah dilakukan dalam beberapa yang lain syarikat kecil(contohnya, Collaxa), walau bagaimanapun, Sonic adalah salah satu yang pertama menawarkan pelaksanaan proses tak segerak yang digandingkan secara longgar. Walaupun semua kebaharuan, dalam produk perisian SonicXQ ESB syarikat itu, sebenarnya, melaksanakan idea lama bas biasa, yang dipinjam daripada komputer mini, tetapi pada masa yang sama menjelmakannya dalam bentuk baharu.

Dalam kes ini, ESB adalah generik dalam erti kata ia menghubungkan semua aplikasi dalam perusahaan. ESB, dilaksanakan menggunakan SOA (Seni Bina Berorientasikan Perkhidmatan), direka bentuk untuk disepadukan aplikasi perusahaan berdasarkan perkhidmatan Web tak segerak berpaksikan dokumen dan J2EE Connector Architecture (JCA). Kedua-dua teknologi ini menyediakan penghalaan mesej berasaskan kandungan dan membolehkan anda mengatur interaksi antara aplikasi dan menyepadukan pengurusan proses perniagaan dengan cara yang boleh dilakukan tanpa broker yang mahal.

Keaslian pembangunan SonicXQ menarik perhatian ramai. Dari segi sejarah, broker integrasi (kadangkala dipanggil pelayan integrasi) adalah yang pertama muncul. Penyelesaian yang dibina berdasarkan broker integrasi boleh diwakili dalam bentuk suis. Dengan bantuan mereka, metakomputer hipotesis tertentu terbentuk, di mana semua kawalan dibina berdasarkan prinsip terpusat. Hasilnya adalah seperti kerangka utama hiper. Sonic melakukan perkara yang sama seperti DEC, yang menawarkan komputer mini bas sebagai alternatif kos rendah kepada kerangka utama tiga dekad yang lalu; Penyelesaian Sonic membolehkan anda membina sejenis metakomputer untuk keseluruhan perusahaan, tetapi pada kos yang lebih rendah. Hasilnya ialah analog mini-metakomputer: bukannya suis mahal, Bas Perkhidmatan Perusahaan ditawarkan.

Teknologi SonicXQ tidak muncul secara tiba-tiba. Dia mempunyai dua sumber yang cukup terkenal. Yang pertama ialah perisian tengah berasaskan mesej. Kit alatan perisian jenis ini mengalami penjelmaan semula yang sebenar, terutamanya berkaitan dengan kemunculan Java Message Service daripada Sun Microsystems. Anda boleh membaca tentang apa yang berlaku di hadapan ini, dan dengan lebih terperinci tentang SonicMQ, pendahulu segera SonicXQ, dalam. Kedua-dua penerbitan ini kekal relevan, tetapi landskap perisian perusahaan telah berubah dengan ketara sepanjang tahun lalu, terutamanya dengan kesan perkhidmatan Web. Hanya setahun yang lalu, apabila penerbitan ini sedang disediakan, idea tentang perkhidmatan Web dan apakah kepentingannya agak samar-samar. Dari masa ke masa, keadaan telah pulih dengan ketara, dan perkhidmatan Web harus dinamakan sebagai sumber kedua SonicXQ.

Bas Perkhidmatan Perusahaan

Di antara peristiwa tahun lalu, perlu diperhatikan bahawa sesuatu yang baru dan luar biasa muncul dalam istilah profesional. Sesetengah daripada kem Microsft/IBM memanggilnya "orkestrasi" perkhidmatan Web; yang lain dari kem Sun/BEA memanggilnya "koreografi." Pertempuran terkini dalam perang piawaian semakin hangat mengenai cara terbaik untuk menjadikan aplikasi perusahaan berfungsi secara konsisten menggunakan perkhidmatan Web. Sebab aktiviti baharu itu akhirnya menjadi jelas kepada semua orang: dalam keadaan semasa, keupayaan aplikasi berganding rapat telah habis, kerumitan sistem menjadi terlalu hebat. Walau bagaimanapun, skim asal untuk mengedarkan perkhidmatan Web menggunakan repositori yang dibina mengikut piawaian UDDI ternyata tidak banyak digunakan untuk tujuan korporat. Pada masa yang sama, perkhidmatan Web, dan terutamanya versi berorientasikan dokumen tak segerak mereka, menawarkan jalan keluar sebenar daripada kebuntuan kerumitan. Dari perspektif teknikal, cabaran membina infrastruktur aplikasi perusahaan menggunakan proses tak segerak yang digandingkan secara longgar mempunyai beberapa penyelesaian alternatif.

Bas Perkhidmatan Perusahaan, dibina di atas SonicXQ, adalah salah satu daripadanya. Dengan bantuan tulang belakang korporat yang dibentuk oleh SonicXQ, seni bina yang diedarkan berorientasikan perkhidmatan. ESB membolehkan anda mencipta bekas untuk mengehoskan perkhidmatan. Perkhidmatan mudah dipasang dan diatur kerana perkhidmatan yang disimpan dalam bekas dan sebahagian daripada ESB terdedah kepada bahagian lain ESB. Lebih-lebih lagi, keseluruhan struktur adalah maya; rangkaian fizikal sebenar di mana ia "hidup" boleh tertakluk kepada perubahan tanpa kehilangan fungsi.

Semasa operasi ESB, satu atau lebih perkhidmatan berkaitan terletak di dalam bekas khas (bekas perkhidmatan). Bekas adalah satu cara untuk memindahkan perkhidmatan melalui proses yang diedarkan mengikut laluan mesej. Prosedur untuk menghantar mesej adalah seperti berikut. Mesej dihantar ke input bas ESB. Di sini laluan ditambahkan padanya, yang membolehkan anda mengatur promosi dipacu kandungan melalui proses yang diedarkan; proses ini mempunyai kawalan terdesentralisasi. Sebagai sebahagian daripada proses ini, mesej bergerak melalui beberapa perkhidmatan untuk mencapai titik akhir di mana ia diambil daripada bekas.

Nama logik dan bukannya nama fizikal boleh digunakan untuk menentukan titik akhir. Mewujudkan surat-menyurat antara nama fizikal dan logik (pemetaan) dijalankan oleh mekanisme khas yang termasuk dalam ESB. Oleh itu, keupayaan untuk virtualisasi sememangnya dibina ke dalam seni bina; sistem boleh berubah tanpa mengubah suai kod atau memusnahkan proses perniagaan sedia ada. Konfigurasi membenarkan berbilang tahap Kualiti Perkhidmatan (QoS) untuk memastikan laluan mesej yang boleh dipercayai antara aplikasi. Secara umum, apabila mesej telah melengkapkan keseluruhan laluannya, ia meninggalkan titik akhir penerima dan mesej yang mengesahkan penerimaan dihantar kepada pengirim. Kelebihan proses penghantaran mesej berasaskan ESB yang diedarkan ialah logiknya sangat dekat dengan komunikasi dunia sebenar.

Asas: JCA dan Perkhidmatan Web

Penyepaduan aplikasi yang ditawarkan dalam ESB dimungkinkan dengan kemunculan seni bina sambung JCA Sun Microsystems dan SOAP, protokol standard untuk perkhidmatan Web. JCA, yang direka khusus untuk mengatasi kerumitan yang berkaitan dengan penyepaduan aplikasi, menyediakan kaedah piawai untuk menyelesaikan tugas ini. Korporat Sistem informasi, dibina berdasarkan prinsip JCA, menggunakan antara muka JDBC untuk mengakses aplikasi. Hari ini pendekatan ini agak popular; Kebanyakan pelayan aplikasi moden, termasuk BEA WebLogic dan IBM WebSphere, menyokong penyesuai JCA. Di samping itu, banyak penyedia penyelesaian pakej berhasrat untuk menyokong JCA dalam versi masa hadapan produk mereka.

Keaslian penggunaan perkhidmatan Web oleh SonicXQ terletak pada cara proses "orkestrasi" (atau "koreografi") disusun. Ia berdasarkan protokol SOAP, tetapi dilapisi dengan format mesej yang mudah dan berskala. Pada masa yang sama, SonicXQ Enterprise Service Bus menyediakan keserasian dengan kedua-dua model dokumen SOAP tak segerak (model tak segerak dokumen) dan model SOAP segerak, dibina berdasarkan prinsip panggilan prosedur jauh (RPC). Dalam SonicXQ, perkhidmatan diterangkan di bahasa WSDL, tetapi WSDL disepadukan secara langsung oleh Rangka Kerja Pemprosesan Teragih. Akibatnya, perkhidmatan mungkin atau mungkin tidak didaftarkan dalam direktori UDDI luaran jika tidak perlu.

Tanpa sebarang keterlaluan, teknologi SonicXQ boleh dipanggil melampau: ia menggabungkan beberapa trend moden dalam pengkomputeran korporat. Tetapi mungkin perkara yang paling menarik ialah ia memberi anda pemahaman yang lebih baik tentang perkhidmatan Web. Dan bukan dengan kata-kata, tetapi dalam perbuatan.

kesusasteraan

1. Leonid Chernyak. IOM, kelahiran semula //

2. Valery Kor zhov. Posmen untuk permohonan //

3. Stuart J. Johnston, Peperangan Perkhidmatan Web Mengambil Giliran Artistik. Koreografi atau orkestra? Majalah XML, 2002, No. 10/11