Mengapa Layanan Web?

Gambaran
Pemrograman berbasis komponen menjadi lebih populer dari sebelumnya. Hampir tidak ada aplikasi yang dibangun saat ini yang tidak melibatkan peningkatan komponen dalam beberapa bentuk, biasanya dari vendor yang berbeda. Karena aplikasi tumbuh lebih canggih, kebutuhan untuk memanfaatkan komponen yang didistribusikan pada mesin jarak jauh juga tumbuh.

Contoh aplikasi berbasis komponen adalah solusi e-niaga ujung ke ujung. Aplikasi e-commerce yang berada di Web farm perlu mengirimkan pesanan ke aplikasi Enterprise Resource Planning (ERP) back-end. Dalam banyak kasus, aplikasi ERP berada pada perangkat keras yang berbeda dan mungkin berjalan pada sistem operasi yang berbeda.

Microsoft Distributed Component Object Model (DCOM), infrastruktur objek terdistribusi yang memungkinkan aplikasi untuk memanggil komponen Component Object Model (COM) yang diinstal di server lain, telah di-porting ke sejumlah platform non-Windows. Tetapi DCOM tidak pernah diterima secara luas pada platform ini, sehingga jarang digunakan untuk memfasilitasi komunikasi antara komputer Windows dan non-Windows. Vendor perangkat lunak ERP sering membuat komponen untuk platform Windows yang berkomunikasi dengan sistem back-end melalui protokol berpemilik.

Beberapa layanan yang dimanfaatkan oleh aplikasi e-niaga mungkin tidak berada di dalam pusat data sama sekali. Misalnya, jika aplikasi e-niaga menerima pembayaran kartu kredit untuk barang yang dibeli oleh pelanggan, aplikasi tersebut harus meminta layanan bank pedagang untuk memproses informasi kartu kredit pelanggan. Tetapi untuk semua tujuan praktis, DCOM dan teknologi terkait seperti CORBA dan Java RMI terbatas pada aplikasi dan komponen yang dipasang di dalam pusat data perusahaan. Dua alasan utama untuk ini adalah bahwa secara default teknologi ini memanfaatkan protokol berpemilik dan protokol ini secara inheren berorientasi pada koneksi.

Klien yang berkomunikasi dengan server melalui Internet menghadapi banyak hambatan potensial untuk berkomunikasi dengan server. Administrator jaringan yang sadar keamanan di seluruh dunia telah menerapkan router dan firewall perusahaan untuk melarang hampir semua jenis komunikasi melalui Internet. Seringkali dibutuhkan tindakan Tuhan untuk membuat administrator jaringan membuka port melebihi batas minimum.

Jika Anda cukup beruntung mendapatkan administrator jaringan untuk membuka port yang sesuai untuk mendukung layanan Anda, kemungkinan besar klien Anda tidak seberuntung itu. Akibatnya, protokol berpemilik seperti yang digunakan oleh DCOM, CORBA, dan Java RMI tidak praktis untuk skenario Internet.

Masalah lain, seperti yang saya katakan, dengan teknologi ini adalah bahwa mereka secara inheren berorientasi pada koneksi dan karena itu tidak dapat menangani gangguan jaringan dengan baik. Karena Internet tidak berada di bawah kendali langsung Anda, Anda tidak dapat membuat asumsi apa pun tentang kualitas atau keandalan sambungan. Jika terjadi gangguan jaringan, panggilan berikutnya yang dilakukan klien ke server mungkin gagal.

Sifat berorientasi koneksi dari teknologi ini juga menyulitkan untuk membangun infrastruktur dengan beban seimbang yang diperlukan untuk mencapai skalabilitas tinggi. Setelah koneksi antara klien dan server terputus, Anda tidak bisa begitu saja merutekan permintaan berikutnya ke server lain.

Pengembang telah mencoba mengatasi batasan ini dengan memanfaatkan model yang disebut pemrograman tanpa negara, tetapi keberhasilan mereka terbatas karena teknologinya cukup berat dan membuatnya mahal untuk membangun kembali koneksi dengan objek jarak jauh.

Karena pemrosesan kartu kredit pelanggan dilakukan oleh server jarak jauh di Internet, DCOM tidak ideal untuk memfasilitasi komunikasi antara klien e-niaga dan server pemrosesan kartu kredit. Seperti dalam solusi ERP, komponen pihak ketiga sering kali dipasang di dalam pusat data klien (dalam hal ini, oleh penyedia solusi pemrosesan kartu kredit). Komponen ini berfungsi sebagai proxy yang memfasilitasi komunikasi antara perangkat lunak e-commerce dan bank pedagang melalui protokol berpemilik.

Apakah Anda melihat pola di sini? Karena keterbatasan teknologi yang ada dalam memfasilitasi komunikasi antar sistem komputer, vendor perangkat lunak sering kali terpaksa membangun infrastruktur mereka sendiri. Ini berarti sumber daya yang dapat digunakan untuk menambahkan fungsionalitas yang lebih baik ke sistem ERP atau sistem pemrosesan kartu kredit telah dikhususkan untuk menulis protokol jaringan berpemilik.

Dalam upaya untuk mendukung skenario Internet tersebut dengan lebih baik, Microsoft awalnya mengadopsi strategi untuk menambah teknologi yang ada, termasuk COM Internet Services (CIS), yang memungkinkan Anda untuk membuat sambungan DCOM antara klien dan komponen jarak jauh melalui port 80. Untuk berbagai alasannya, CIS tidak diterima secara luas.

Jelas bahwa diperlukan pendekatan baru. Jadi Microsoft memutuskan untuk mengatasi masalah tersebut dari bawah ke atas. Mari kita lihat beberapa persyaratan yang harus dipenuhi oleh solusi tersebut agar berhasil.

Interoperabilitas Remo

Layanan ini harus dapat dikonsumsi oleh klien di platform lain.

Keramahan Internet Solusi harus bekerja dengan baik untuk mendukung klien yang mengakses layanan jarak jauh dari Internet.

Antarmuka yang diketik dengan kuat Seharusnya tidak ada ambiguitas tentang jenis data yang dikirim dan diterima dari layanan jarak jauh. Selain itu, tipe data yang ditentukan oleh layanan jarak jauh harus dipetakan dengan baik ke tipe data yang ditentukan oleh sebagian besar bahasa pemrograman prosedural.

Kemampuan untuk memanfaatkan standar Internet yang ada Implementasi layanan jarak jauh harus memanfaatkan standar Internet yang ada sebanyak mungkin dan menghindari penemuan kembali solusi untuk masalah yang telah diselesaikan. Solusi yang dibangun di atas standar Internet yang diadopsi secara luas dapat memanfaatkan perangkat dan produk yang ada yang dibuat untuk teknologi tersebut.

Dukungan untuk bahasa apa pun Solusinya tidak boleh digabungkan dengan bahasa pemrograman tertentu. Java RMI, misalnya, terkait erat dengan bahasa Java. Akan sulit untuk menjalankan fungsionalitas pada objek Java jarak jauh dari Visual Basic atau Perl. Klien harus dapat menerapkan layanan Web baru atau menggunakan layanan Web yang sudah ada terlepas dari bahasa pemrograman yang digunakan untuk menulis klien.

Dukungan untuk infrastruktur komponen terdistribusi. Solusi tidak boleh digabungkan dengan infrastruktur komponen tertentu. Faktanya, Anda tidak perlu membeli, menginstal, atau memelihara infrastruktur objek terdistribusi hanya untuk membangun layanan jarak jauh baru atau menggunakan layanan yang sudah ada. Protokol yang mendasari harus memfasilitasi komunikasi tingkat dasar antara infrastruktur objek terdistribusi yang ada seperti DCOM dan CORBA.
Mengingat judul buku ini, tidak mengherankan bahwa solusi yang dibuat Microsoft dikenal sebagai layanan Web. Layanan Web memperlihatkan antarmuka untuk menjalankan aktivitas tertentu atas nama klien. Seorang klien dapat mengakses layanan Web melalui penggunaan standar Internet.

Blok Bangunan Layanan Web
Grafik berikut menunjukkan blok penyusun inti yang diperlukan untuk memfasilitasi komunikasi jarak jauh antara dua aplikasi.

Mari kita bahas tujuan dari masing-masing blok penyusun ini. Karena banyak pembaca yang akrab dengan DCOM, saya juga akan menyebutkan padanan DCOM untuk setiap blok penyusun.

Penemuan Aplikasi klien yang memerlukan akses ke fungsionalitas yang diekspos oleh layanan Web memerlukan cara untuk menyelesaikan lokasi layanan jarak jauh. Ini dicapai melalui proses yang umumnya disebut penemuan. Penemuan dapat difasilitasi melalui direktori terpusat serta dengan lebih banyak metode ad hoc. Di DCOM, Service Control Manager (SCM) menyediakan layanan penemuan.

Deskripsi Setelah titik akhir untuk layanan Web tertentu telah diselesaikan, klien memerlukan informasi yang memadai untuk berinteraksi dengannya. Deskripsi layanan Web mencakup metadata terstruktur tentang antarmuka yang dimaksudkan untuk digunakan oleh aplikasi klien serta dokumentasi tertulis tentang layanan Web termasuk contoh penggunaan. Komponen DCOM memperlihatkan metadata terstruktur tentang antarmukanya melalui pustaka tipe (typelib). Metadata dalam typelib komponen disimpan dalam format biner berpemilik dan diakses melalui antarmuka pemrograman aplikasi (API) berpemilik.

Format pesan Untuk bertukar data, klien dan server harus menyetujui cara umum untuk menyandikan dan memformat pesan. Cara standar pengkodean data memastikan bahwa data yang dikodekan oleh klien akan diinterpretasikan dengan benar oleh server. Di DCOM, pesan yang dikirim antara klien dan server diformat seperti yang ditentukan oleh protokol DCOM Object RPC (ORPC).
Tanpa cara standar untuk memformat pesan, mengembangkan perangkat untuk mengabstraksi pengembang dari protokol yang mendasarinya hampir mustahil. Membuat lapisan abstraksi antara pengembang dan protokol yang mendasari memungkinkan pengembang untuk lebih fokus pada masalah bisnis yang dihadapi dan lebih sedikit pada infrastruktur yang diperlukan untuk mengimplementasikan solusi.

Pengkodean Data yang dikirim antara klien dan server perlu dikodekan ke dalam tubuh pesan. DCOM menggunakan skema pengkodean biner untuk membuat serial data yang terkandung oleh parameter yang dipertukarkan antara klien dan server.

Pengangkutan Setelah pesan diformat dan data telah diserialkan ke dalam tubuh pesan, pesan harus ditransfer antara klien dan server melalui beberapa protokol pengangkutan. DCOM mendukung sejumlah protokol berpemilik yang terikat ke sejumlah protokol jaringan seperti TCP, SPX, NetBEUI, dan NetBIOS melalui IPX.
Keputusan Desain Layanan Web

Mari kita bahas beberapa keputusan desain di balik blok bangunan ini untuk layanan Web.

Memilih Protokol Transportasi

Langkah pertama adalah menentukan bagaimana klien dan server akan berkomunikasi satu sama lain. Klien dan server dapat berada di LAN yang sama, tetapi klien mungkin berpotensi berkomunikasi dengan se

menjelajahi Internet. Oleh karena itu, protokol transport harus sama-sama cocok untuk lingkungan LAN dan Internet.

Seperti yang saya sebutkan sebelumnya, teknologi seperti DCOM, CORBA, dan Java RMI tidak cocok untuk mendukung komunikasi antara klien dan server melalui Internet. Protokol seperti Hypertext Transfer Protocol (HTTP) dan Simple Mail Transfer Protocol (SMTP) adalah protokol Internet yang terbukti. HTTP mendefinisikan pola pesan permintaan / tanggapan untuk mengirimkan permintaan dan mendapatkan tanggapan terkait. SMTP mendefinisikan protokol perpesanan yang dapat dirutekan untuk komunikasi asinkron. Mari kita periksa mengapa HTTP dan SMTP sangat cocok untuk Internet.

Aplikasi Web berbasis HTTP pada dasarnya tidak memiliki kewarganegaraan. Mereka tidak bergantung pada koneksi berkelanjutan antara klien dan server. Ini menjadikan HTTP protokol yang ideal untuk konfigurasi ketersediaan tinggi seperti firewall. Jika server yang menangani permintaan asli klien menjadi tidak tersedia, permintaan selanjutnya dapat secara otomatis diarahkan ke server lain tanpa sepengetahuan atau perhatian klien.

Hampir semua perusahaan memiliki infrastruktur yang mendukung SMTP. SMTP sangat cocok untuk komunikasi asynchronous. Jika layanan terganggu, infrastruktur email secara otomatis menangani percobaan ulang. Tidak seperti HTTP, Anda dapat meneruskan pesan SMTP ke server email lokal yang akan mencoba mengirimkan pesan email atas nama Anda.

Keuntungan signifikan lainnya dari HTTP dan SMTP adalah kemudahannya. Karyawan mulai mengandalkan email dan browser Web mereka, dan administrator jaringan memiliki tingkat kenyamanan yang tinggi untuk mendukung layanan ini. Teknologi seperti terjemahan alamat jaringan (NAT) dan server proxy menyediakan cara untuk mengakses Internet melalui HTTP dari dalam LAN perusahaan yang terisolasi. Administrator akan sering mengekspos server SMTP yang berada di dalam firewall. Pesan yang dikirim ke server ini kemudian akan dialihkan ke tujuan akhirnya melalui Internet.

Dalam kasus perangkat lunak pemrosesan kartu kredit, diperlukan tanggapan segera dari bank pedagang untuk menentukan apakah pesanan harus diserahkan ke sistem ERP. HTTP, dengan pola pesan permintaan / tanggapannya, sangat cocok untuk tugas ini.

Sebagian besar paket perangkat lunak ERP tidak mampu menangani pesanan dalam jumlah besar yang berpotensi didorong dari aplikasi e-niaga. Selain itu, pesanan tidak harus dikirim ke sistem ERP secara real time. Oleh karena itu, SMTP dapat dimanfaatkan untuk mengantri pesanan sehingga dapat diproses secara serial oleh sistem ERP.

Jika sistem ERP mendukung transaksi terdistribusi, opsi lainnya adalah memanfaatkan Microsoft Message Queue Server (MSMQ). Selama aplikasi e-commerce dan sistem ERP berada dalam LAN yang sama, konektivitas melalui protokol non-Internet tidak terlalu menjadi masalah. Keunggulan MSMQ dibandingkan SMTP adalah bahwa pesan dapat ditempatkan dan dihapus dari antrian dalam lingkup transaksi. Jika upaya untuk memproses pesan yang ditarik dari antrian gagal, pesan tersebut secara otomatis akan ditempatkan kembali dalam antrian saat transaksi dibatalkan.

Memilih Skema Pengkodean

HTTP dan SMTP menyediakan sarana pengiriman data antara klien dan server. Namun, tidak ada yang menentukan bagaimana data di dalam tubuh pesan harus dienkode. Microsoft memerlukan cara standar platform-netral untuk menyandikan data yang dipertukarkan antara klien dan server.

Karena tujuannya adalah untuk memanfaatkan protokol berbasis Internet, Extensible Markup Language (XML) adalah pilihan yang wajar. XML menawarkan banyak keuntungan, termasuk dukungan lintas platform, sistem tipe umum, dan dukungan untuk rangkaian karakter standar industri.

Skema pengkodean biner seperti yang digunakan oleh DCOM, CORBA, dan Java RMI harus mengatasi masalah kompatibilitas antara platform perangkat keras yang berbeda. Misalnya, platform perangkat keras yang berbeda memiliki representasi biner internal yang berbeda dari bilangan multi-byte. Platform Intel memesan byte dari bilangan multi-byte menggunakan konvensi little endian; banyak prosesor RISC memesan byte dari bilangan multi-byte menggunakan konvensi big endian.

XML menghindari masalah pengkodean biner karena menggunakan skema pengkodean berbasis teks yang memanfaatkan kumpulan karakter standar. Selain itu, beberapa protokol transport, seperti SMTP, hanya dapat berisi pesan berbasis teks.

Metode pengkodean biner, seperti yang digunakan oleh DCOM dan CORBA, rumit dan membutuhkan infrastruktur pendukung untuk mengabstraksi pengembang dari detailnya. XML jauh lebih ringan dan lebih mudah ditangani karena dapat dibuat dan digunakan menggunakan teknik penguraian teks standar.

Selain itu, berbagai parser XML tersedia untuk lebih menyederhanakan pembuatan dan konsumsi dokumen XML pada hampir setiap platform modern. XML ringan dan memiliki dukungan alat yang sangat baik, jadi pengkodean XML memungkinkan jangkauan yang luar biasa karena hampir semua klien di platform apa pun dapat berkomunikasi dengan layanan Web Anda.

Memilih Konvensi Pemformatan

Seringkali perlu menyertakan metadata tambahan dengan badan pesan. Misalnya, Anda mungkin ingin memasukkan informasi tentang jenis layanan yang perlu disediakan layanan Web untuk memenuhi permintaan Anda, seperti mendaftar dalam transaksi atau informasi perutean. XML tidak menyediakan mekanisme untuk membedakan badan pesan dari data yang terkait.

Protokol transport seperti HTTP menyediakan mekanisme yang dapat diperluas untuk data header, tetapi beberapa data yang terkait dengan pesan mungkin tidak spesifik untuk protokol transport. Misalnya, klien mungkin mengirim pesan yang perlu dirutekan ke beberapa tujuan, kemungkinan melalui protokol transport yang berbeda. Jika informasi perutean ditempatkan ke dalam header HTTP, itu harus diterjemahkan sebelum dikirim ke perantara berikutnya melalui protokol transport lain, seperti SMTP. Karena informasi perutean khusus untuk pesan dan bukan protokol transport, itu harus menjadi bagian dari pesan.

Simple Object Access Protocol (SOAP) menyediakan sarana protokol-agnostik untuk menghubungkan informasi header dengan isi pesan. Setiap pesan SOAP harus menentukan amplop. Amplop memiliki badan yang berisi payload pesan dan header yang bisa berisi metadata yang terkait dengan pesan tersebut.

SOAP tidak memberlakukan batasan tentang bagaimana badan pesan dapat diformat. Ini adalah masalah potensial karena tanpa cara yang konsisten untuk menyandikan data, sulit untuk mengembangkan perangkat yang memisahkan Anda dari protokol yang mendasarinya. Anda mungkin harus menghabiskan cukup banyak waktu untuk mempercepat antarmuka layanan Web alih-alih memecahkan masalah bisnis yang dihadapi.

Apa yang dibutuhkan adalah cara standar untuk memformat pesan remote procedure call (RPC) dan mengkodekan daftar parameternya. Ini persis seperti yang disediakan Bagian 7 dari spesifikasi SOAP. Ini menjelaskan konvensi penamaan standar dan gaya pengkodean untuk pesan berorientasi prosedur.

Karena SOAP menyediakan format standar untuk membuat serialisasi data menjadi pesan XML, platform seperti ASP.NET dan Remoting dapat mengabstraksi detail untuk Anda.

Memilih Mekanisme Deskripsi

SOAP menyediakan cara standar untuk memformat pesan yang dipertukarkan antara layanan Web dan klien. Namun, klien membutuhkan informasi tambahan untuk membuat serialisasi permintaan dengan benar dan menafsirkan respons. XML Schema menyediakan sarana untuk membuat skema yang dapat digunakan untuk mendeskripsikan konten pesan.

XML Schema menyediakan satu set inti tipe data bawaan yang dapat digunakan untuk mendeskripsikan konten pesan. Anda juga dapat membuat tipe data Anda sendiri. Misalnya, bank pedagang dapat membuat jenis data yang kompleks untuk mendeskripsikan konten dan struktur badan pesan yang digunakan untuk mengirimkan permintaan pembayaran kartu kredit.

Skema berisi sekumpulan definisi tipe data dan elemen. Layanan Web menggunakan skema tidak hanya untuk mengkomunikasikan tipe data yang diharapkan ada di dalam pesan tetapi juga untuk memvalidasi pesan masuk dan keluar.

Namun, skema saja tidak memberikan informasi yang cukup untuk menjelaskan layanan Web secara efektif. Skema tidak menjelaskan pola pesan antara klien dan server. Misalnya, klien perlu mengetahui apakah akan menerima respons saat pesanan diposting ke sistem ERP. Klien juga perlu mengetahui protokol transport apa yang diharapkan layanan Web untuk menerima permintaan. Terakhir, klien perlu mengetahui alamat di mana layanan Web dapat dihubungi.

Informasi ini disediakan oleh dokumen Web Services Description Language (WSDL). WSDL adalah dokumen XML yang sepenuhnya menjelaskan layanan Web tertentu. Alat seperti ASP.NET WSDL.exe dan Remoting SOAPSUDS.exe dapat menggunakan WSDL dan secara otomatis membuat proxy untuk pengembang.

Seperti halnya komponen apa pun yang digunakan untuk membangun perangkat lunak, layanan Web juga harus disertai dengan dokumentasi tertulis untuk pengembang yang membuat program melawan layanan Web. Dokumentasi harus menjelaskan apa yang dilakukan layanan Web, antarmuka yang diekspos, dan beberapa contoh bagaimana menggunakannya. Dokumentasi yang baik sangat penting jika layanan Web diekspos ke klien melalui Internet.

Memilih Mekanisme Penemuan

Setelah Anda mengembangkan dan mendokumentasikan layanan Web, bagaimana klien potensial dapat menemukannya? Jika layanan Web dirancang untuk digunakan oleh anggota tim pengembangan Anda, pendekatan Anda bisa sangat informal, seperti berbagi URL dokumen WSDL dengan rekan Anda beberapa bilik ke bawah. Tetapi ketika klien potensial berada di Internet, mengiklankan layanan Web Anda secara efektif adalah cerita yang sama sekali berbeda.

Yang dibutuhkan adalah cara umum untuk mengiklankan layanan Web. Deskripsi Universal, Penemuan, dan Integrasi (UDDI) menyediakan mekanisme seperti itu. UDDI adalah layanan direktori terpusat standar industri yang dapat digunakan untuk mengiklankan dan menemukan layanan Web. UDDI memungkinkan pengguna untuk mencari layanan Web menggunakan sejumlah pencarian

kriteria, termasuk nama perusahaan, kategori, dan jenis layanan Web.

Layanan Web juga dapat diiklankan melalui DISCO, format dokumen XML milik Microsoft yang memungkinkan situs Web untuk mengiklankan layanan yang mereka tampilkan. DISCO mendefinisikan protokol sederhana untuk memfasilitasi gaya hyperlink untuk menemukan sumber daya. Konsumen utama DISCO adalah Microsoft Visual Studio.NET. Pengembang dapat menargetkan server Web tertentu dan menavigasi melalui berbagai layanan Web yang diekspos oleh server.

Apa yang Hilang dari Layanan Web?

E-Jasa – Anda mungkin telah memperhatikan bahwa beberapa item kunci yang ditemukan dalam infrastruktur komponen terdistribusi tidak ditentukan oleh layanan Web. Dua dari kelalaian yang lebih terlihat adalah API yang didefinisikan dengan baik untuk membuat dan menggunakan layanan Web dan satu set layanan komponen, seperti dukungan untuk transaksi terdistribusi. Mari kita bahas setiap bagian yang hilang ini.

API khusus layanan web Sebagian besar infrastruktur komponen terdistribusi mendefinisikan API untuk melakukan tugas-tugas seperti menginisialisasi runtime, membuat instance komponen, dan mencerminkan metadata yang digunakan untuk mendeskripsikan komponen. Karena sebagian besar bahasa pemrograman tingkat tinggi menyediakan beberapa tingkat interoperabilitas dengan C, API biasanya diekspos sebagai satu set datar tanda tangan metode C. RMI melangkah lebih jauh dengan memasangkan API-nya dengan satu bahasa tingkat tinggi, Java.
Dalam upaya untuk memastikan bahwa layanan Web adalah bahasa pemrograman-agnostik, Microsoft telah menyerahkan kepada vendor perangkat lunak individu untuk mengikat dukungan untuk layanan Web ke platform tertentu. Saya akan membahas dua implementasi layanan Web untuk platform.NET, ASP.NET dan Remoting, nanti di buku ini.

Layanan komponen Platform layanan Web tidak menyediakan banyak layanan yang biasa ditemukan dalam infrastruktur komponen terdistribusi, seperti manajemen seumur hidup objek jarak jauh, penyatuan objek, dan dukungan untuk transaksi terdistribusi. Layanan ini diserahkan kepada infrastruktur komponen terdistribusi untuk diterapkan.
Beberapa layanan, seperti dukungan untuk transaksi terdistribusi, dapat diperkenalkan nanti saat teknologinya matang. Lainnya, seperti penggabungan objek dan mungkin manajemen seumur hidup objek, dapat dianggap sebagai detail implementasi platform. Misalnya, Remoting mendefinisikan ekstensi untuk memberikan dukungan untuk manajemen seumur hidup objek, dan Layanan Komponen Microsoft menyediakan dukungan untuk penggabungan objek.

Ringkasan

Pemrograman berbasis komponen telah terbukti bermanfaat bagi produktivitas pengembang, tetapi beberapa layanan tidak dapat dikemas oleh komponen yang berada dalam pusat data klien. Teknologi lama seperti DCOM, CORBA, dan Java RMI tidak cocok untuk memungkinkan klien mengakses layanan melalui Internet, sehingga Microsoft merasa perlu untuk memulai dari bawah dan membangun cara standar industri untuk mengakses layanan jarak jauh.

Layanan web adalah istilah umum yang menggambarkan kumpulan protokol dan layanan standar industri yang digunakan untuk memfasilitasi tingkat interoperabilitas antar aplikasi. Dukungan industri yang telah diterima layanan Web belum pernah terjadi sebelumnya. Belum pernah begitu banyak perusahaan teknologi terkemuka melangkah untuk mendukung standar yang memfasilitasi interoperabilitas antar aplikasi, terlepas dari platform tempat mereka dijalankan.

Salah satu faktor pendukung keberhasilan layanan Web adalah bahwa mereka dibangun di atas standar Internet yang ada seperti XML dan HTTP. Hasilnya, sistem apa pun yang mampu mengurai teks dan berkomunikasi melalui protokol transport Internet standar dapat berkomunikasi dengan layanan Web. Perusahaan juga dapat memanfaatkan investasi yang telah mereka buat dalam teknologi ini.