1. Pendahuluan
Saat ini, setiap perusahaan mencari cara untuk meningkatkan efisiensi produksinya, dan mereka juga secara aktif menjajaki reorganisasi aset TI. Organisasi TI telah mencapai beberapa kemajuan dalam mengatasi masalah ini dengan bantuan teknologi arsitektur berorientasi layanan (SOA), namun dalam banyak kasus hanya sebagian kecil dari keseluruhan portofolio layanan TI yang diimplementasikan. Saat ini, sebagian besar upaya di bidang ini hanyalah mencapai tingkat adopsi SOA yang "cukup"—meningkatkan kemampuan untuk membangun aplikasi dan mengintegrasikannya ke pasar dengan lebih cepat, lebih baik, dan lebih murah. Dan seperti yang telah kita pelajari, mencapai tujuan ini lebih mudah diucapkan daripada dilakukan.
2. Aplikasi komposit berbasis middleware tradisional
Fakta yang ada adalah bahwa SOA adalah sejenis middleware - dan dalam kasus tradisional, middleware sering kali mengandalkan lebih banyak middleware untuk menerjemahkan data ke dalam keadaan ramah konsumen. Ketika Anda akhirnya mengetahui bahwa membangun aplikasi komposit yang menggabungkan teknologi SOA tidak hanya memerlukan penggunaan portal (middleware) tetapi mungkin juga memerlukan penggunaan mesin BPEL (atau bahkan middleware) untuk mengaturnya, hal ini tentu saja membuat Anda bingung. sangat kecewa. Lebih buruk lagi, Anda mungkin bekerja di organisasi yang menerbitkan registrasi UDDI dan mendaftarkan berbagai layanan web. Sayangnya, dalam banyak kasus, hanya ada sedikit aplikasi yang benar-benar menggunakan layanan ini. Bagaimana hal ini bisa terjadi?
Apakah ketidakmampuan untuk membangun aplikasi yang menggunakan layanan SOA ini membuat kita menyimpulkan bahwa ada sesuatu yang salah? Apakah karena terlalu sulit bagi pengembang konten bisnis untuk membangun aplikasi yang secara langsung menggunakan layanan SOA? mengandalkan organisasi TI lain untuk membuat aplikasi seperti itu bagi kita? Apakah kurangnya struktur tata kelola SOA menghambat kita? Dan ada alasan yang sangat menonjol: terlalu sulit bagi pengembang bisnis untuk mengkonsumsi dan memanfaatkan layanan SOA yang diekspos oleh organisasi TI! Faktanya, masalah sebenarnya adalah kurangnya cara mudah untuk menambahkan antarmuka SOA - dan inilah keuntungan menggabungkan teknologi AJAX dengan SOA.
Biasanya, layanan SOA diimplementasikan sebagai layanan Web yang digabungkan secara longgar yang merangkum dan memaparkan fungsionalitas bisnis. Hal ini mungkin terdengar sangat mudah, namun sangat rumit dan sulit untuk diterapkan. Pengembang sering memperdebatkan perincian pengembangan layanan SOA; namun, sebagian besar pengembang sekarang setuju bahwa perincian pengembangan "tingkat bisnis" adalah yang paling tepat. Namun, hal ini masih memerlukan sejumlah besar pakar domain yang relevan untuk bergabung dan bekerja dengan konten bisnis guna menyelesaikan ukuran layanan ini.
3. Kebangkitan SOA
Untungnya, akhir-akhir ini banyak orang yang sangat tertarik dengan SOA. Mungkin bisnis akhirnya menyadari bahwa SOA sebenarnya dapat sangat membantu mereka. Mungkin hal ini disebabkan oleh alat pengembangan dan layanan web yang lebih baik yang dipromosikan oleh Amazon, Yahoo dan eBay. Mungkin itu AJAX? Ya—itulah sebabnya saya menulis artikel ini. Serius, menurut saya AJAX telah menjadi kekuatan pendorong penting dalam memperbarui pemahaman masyarakat tentang SOA, terutama di bidang aplikasi hybrid saat ini dari berbagai teknologi baru. Namun, bagaimana kedua teknologi yang sangat berbeda ini digabungkan dan dihubungkan bersama untuk menghasilkan kekuatan yang lebih besar? Mari kita lihat definisi Wikipedia tentang teknologi AJAX saat ini. Halaman web terlibat, tetapi SOA tidak disebutkan sama sekali. Deskripsinya adalah:
"AJAX, yang merupakan singkatan dari 'Asynchronous JavaScript+XML', adalah teknologi pengembangan web untuk membuat aplikasi web interaktif. Tujuannya adalah untuk membuat halaman web front-end lebih mudah dengan bertukar sejumlah kecil data dengan server di latar belakang. Terasa lebih responsif; oleh karena itu, setiap kali pengguna melakukan perubahan, seluruh halaman Web tidak perlu dimuat ulang. Tujuan utamanya adalah untuk lebih meningkatkan interaktivitas, daya tanggap, dan kegunaan halaman Web.
SOA tidak disebutkan dalam definisi ini. Tidak mengherankan, karena aplikasi AJAX awal berfokus pada peningkatan fungsionalitas dan kegunaan halaman. Hal ini telah dibuktikan di berbagai aplikasi seperti Google Maps, Flickr dan Yahoo Mail. Namun, bukan aplikasi yang berhubungan dengan konsumen inilah yang membuat saya tertarik dengan potensi AJAX, melainkan aplikasi bisnis yang berjalan di belakang firewall perusahaan yang benar-benar memanfaatkan keunggulan AJAX, karena ini menunjukkan kepada kita dua karakteristik utama: Yang pertama adalah klien Model pemrograman sisi-sisi dan yang lainnya adalah implementasi yang mudah dari panggilan asinkron ke server. Dua kemampuan utama ini—kemampuan untuk menerapkan logika pada klien (browser) dan kemampuan untuk mengakses data server tanpa mengganggu halaman Web—membuka pintu untuk membangun aplikasi perusahaan Web 2.0 yang baru dan lebih kaya. Begitu banyak kemungkinan area aplikasi program .
Sebelumnya, saya menyebutkan bahwa SOA tidak memiliki antarmuka. Di sinilah AJAX masuk - ia menambahkan tampilan yang layak untuk SOA. Di sini, izinkan saya menjelaskan sedikit lebih banyak. Kita mungkin juga memikirkan apa yang akan terjadi jika layanan SOA muncul secara online? Layanan seperti itu biasanya perlu didaftarkan di registri atau gudang (jika kita beruntung) dan kemudian dapat digunakan untuk konsumsi. Misalnya, mari kita lihat apa yang tersedia di situs web StrikeIron ( www.StrikeIron.com ). StrikeIron telah berhasil menciptakan "pasar layanan Web" untuk masyarakat umum. Sekilas, mekanisme direktori di StrikeIron terlihat sangat mirip dengan daftar yang disediakan dalam aplikasi bisnis kecil. Namun nanti, Anda akan menyadari bahwa ini bukan hanya aplikasi—mereka sebenarnya adalah layanan Web. Konsep satu perusahaan yang menyediakan layanan Web WSDL/REST kepada banyak konsumen mempunyai banyak implikasi. Namun untuk saat ini, mari kita lihat apa yang dijual perusahaan ini. Menurut informasi yang diberikan oleh StrikeIron (yang menyediakan akses ke layanan ini), layanan web paling populer yang disediakannya meliputi:
· Verifikasi alamat AS
· Layanan SMS global
· Pajak penjualan dan penggunaan
· Verifikasi email
· Pencarian telepon terbalik
Tidak Ada Tidak diragukan lagi, semuanya layanan Web ini cukup berguna dan dapat digunakan di berbagai bidang. Tetapi pada saat yang sama, mereka terlalu "komoditas". Dengan kata lain, saya mungkin tidak peduli siapa yang menyediakan layanan tersebut, tetapi hanya ingin mendapatkan informasi yang saya inginkan. Di sisi lain, apakah saya akan menggunakan layanan web apa pun untuk mentransfer uang tunai dari rekening saya saat ini ke rekening tabungan saya? Pertama-tama saya perlu membangun kepercayaan terhadap layanan ini, jadi saya harus menjalin hubungan tertentu dengan vendor yang menyediakannya. "Lingkaran kepercayaan" yang terjalin antara saya (konsumen) dan penyedia layanan juga mewakili hubungan dalam perusahaan dan mitranya.
4. Menggabungkan teknologi AJAX + SOA
Metode yang sama di atas juga dapat diadopsi oleh perusahaan untuk menyediakan layanan Web mereka ke basis pengguna yang lebih luas. Melalui pasar layanan Web, perusahaan dapat mendaftarkan berbagai layanan Web—dan layanan Web ini biasanya hanya tersedia di dalam perusahaan atau mitra. Vendor pasar jelas menginginkan hal ini terjadi, namun yang lebih penting, kami melihat peluang untuk menerapkan teknologi AJAX+SOA untuk menggerakkan aplikasi bisnis Web 2.0 kelas baru.
Untuk pertama kalinya, orang-orang mulai merasakan bahwa pengembangan aplikasi dan SOA akhirnya bersatu. Kami memiliki fungsi bisnis yang dijelaskan dalam bentuk yang dapat digunakan kembali - layanan SOA. Kita memiliki konektivitas di mana-mana—Web. Kami memiliki browser yang terbukti menjadi wadah aplikasi baru. Kami memiliki model pemrograman dalam wadah aplikasi/browser jenis ini - JavaScript. Dan semuanya menggunakan standar terbuka! Apa lagi yang kita minta?
Saya khususnya ingin melihat cara yang lebih cepat untuk mengembangkan aplikasi berdasarkan semua teknologi di atas - cara untuk membangun aplikasi tanpa harus bergantung pada middleware yang terintegrasi dengan layanan SOA. Inilah yang saya inginkan dari aplikasi web - "koneksi langsung ke SOA". "Koneksi langsung ke SOA" ini harus mampu melewati hambatan portal tradisional dan mesin proses kelas berat untuk secara langsung (setidaknya secara konseptual; kita akan mempelajarinya lebih lanjut nanti) mengakses layanan SOA. Yang saya maksud dengan ini bukan hanya layanan web, bisa juga layanan orkestrasi BPEL, layanan POJO kasar, RSS feed, atau apa pun yang dapat diekspos sebagai "layanan". Tentu saja, antarmuka harus diekspos menggunakan standar terbuka.
Model pengembangan dan runtime baru ini menciptakan cara baru untuk membangun aplikasi komposit berbasis aplikasi. Ia memiliki daya tarik tipe klien/server tanpa beban berat seperti klien/server kelas berat tradisional. Ini berjalan di sisi browser dan dapat diimplementasikan sesuai dengan kebutuhan spesifik.
5. Aplikasi Komposit Berbasis Pengguna
Selama beberapa tahun terakhir, kita semua telah mendengar konsep "aplikasi komposit". Namun, sebagian besar vendor telah membicarakan tentang "layanan komposit" - sebagai cara untuk merestrukturisasi layanan host mereka menjadi layanan atau aplikasi portal lain yang lebih berguna. Izinkan saya membuat analogi untuk menjelaskan lebih lanjut.
AcmeGrid, vendor komputasi grid fiksi kami dalam artikel ini, menyediakan layanan—komputasi grid—yang memungkinkan aplikasi Anda berjalan sebagai layanan. Pelanggan perusahaan mengatakan bahwa mereka menginginkan cara untuk menggabungkan banyak layanan menjadi layanan yang lebih sederhana. Jadi, tentu saja, AcmeGrid merilis AcmeGrid Composite Application Builder (CAB) berbasis Eclipse. Menariknya, CAB terlihat sangat mirip dengan perancang BPEL, namun lebih terintegrasi dengan layanan yang diterbitkan oleh AcmeGrid. Meskipun sangat indah, namun ini bukanlah aplikasi nyata, paling-paling ini hanyalah sebuah layanan. Intinya, CAB lebih seperti pembuat layanan. Namun siapa yang membutuhkan pembuat layanan saat kita mencoba membangun aplikasi? Segera, vendor fiktif lainnya, sebut saja AcmePortal, mengumumkan Portal Composite Application Builder (PCAB). Program ini juga dilengkapi dengan desainer berbasis Eclipse; meskipun terlihat dan terasa seperti desainer BPEL, program ini "tahu" cara membangun portal. Dalam banyak kasus, portal berfungsi sama baiknya dengan aplikasi. Namun, jika Anda bersikeras mengubah portal menjadi aplikasi, itu akan sia-sia.
Sebenarnya, saya sangat ingin mengimplementasikan aplikasi komposit berbasis pengguna daripada aplikasi komposit berbasis middleware. Untuk melakukan ini, saya memerlukan platform pengembangan dan runtime yang tidak hanya dapat menggunakan AJAX dan SOA, tetapi juga mengelola keduanya. Beberapa vendor telah mengambil konsep aplikasi AJAX satu langkah lebih jauh - memanggil layanan Web berbasis WSDL langsung dari browser, yang pada dasarnya adalah panggilan SOAP. Pendekatan ini bahkan memiliki nama - "Klien/SOA". Ini mungkin baik untuk aplikasi sederhana non-perusahaan atau konsumen, namun tidak untuk program perusahaan sebenarnya. Mengapa? Karena ketika Anda memanggil layanan Web langsung dari browser, fungsi pengawasan setara dengan diserahkan ke browser - yang berarti tidak ada masalah pengawasan sama sekali. Gambar 1 menunjukkan diagram blok konsumsi layanan Web tanpa pengawasan. Saya belum pernah bertemu perusahaan yang tidak mengawasi layanannya, dan saya tidak yakin perusahaan akan membiarkan hal ini terjadi hanya karena kami secara teknis sangat efisien dalam hal itu. Jika Anda tidak mempercayai saya, ingatlah bahwa perusahaan tidak pernah membuka firewall mereka untuk aplikasi selain HTTP dan SSL. Tidak peduli seberapa besar kami meyakinkan administrator sistem, mereka tidak akan membuka port lain.
6. Kita memerlukan platform jenis baru.
Seperti terlihat di atas, yang kita bahas bukan hanya tentang teknologi AJAX dan SOA. Faktanya, yang benar-benar kita butuhkan adalah sebuah platform yang dapat memberikan kemampuan pengawasan yang diperlukan agar AJAX dan SOA dapat hidup berdampingan di perusahaan. Platform ini juga menyediakan kemampuan untuk menggunakan layanan SOA dari sudut pandang klien, dan juga dapat memantau konsumsi layanan. Gambar 2 menunjukkan bagaimana layanan Web dapat dikelola melalui gateway layanan. Service gateway sebenarnya adalah abstraksi sisi server yang memantau dan mengatur akses layanan atas nama klien, yang dalam kasus yang baru saja kita bahas adalah aplikasi AJAX berbasis browser. Keuntungan menggunakan gateway layanan adalah Anda tidak dibatasi hanya untuk mengakses layanan yang berjalan di dalam perusahaan. Gateway layanan ini dapat mengawasi layanan apa pun yang terdaftar dalam perusahaan. Dalam layanan Web berbasis WSDL, perusahaan akan mendaftarkan WSDL, dan WSDL menyediakan pengikatan ke layanan pada saat runtime. Ini mungkin merupakan layanan yang berjalan di pusat data perusahaan, namun bisa juga merupakan layanan yang berjalan di pusat data kemitraan. Jika suatu perusahaan mengizinkan (melalui regulasi) aplikasi untuk mengakses layanan, tidak masalah di mana layanan tersebut berjalan.
7. Kesimpulan
Setelah membaca artikel ini, saya harap Anda mulai menghargai kekuatan menyatukan AJAX dan SOA—terutama bagaimana keduanya dapat hidup berdampingan dan memungkinkan aplikasi berbasis Web jenis baru dengan kemampuan regulasi yang dibutuhkan oleh aplikasi Layanan perusahaan . Saya sangat yakin bahwa kita sedang memasuki era baru dengan peluang luar biasa. Di era Web 2.0, jejaring sosial, berbagi gambar, dan berbagai teknologi anotasi semuanya hebat, namun yang benar-benar berpengaruh adalah respons Web 2.0 terhadap perusahaan.