LAYANAN WEB

DISTRIBUTED SYSTEMS Concept and Design – Fifth Edition
George Coulouris
Cambridge University
Jean Dollimore
formerly of Queen Mary, University of London
Tim Kindberg
matter 2 media
Gordon Blair
Lancaster University

Sebuah layanan web menyediakan antarmuka layanan yang memungkinkan klien untuk berinteraksi dengan server cara yang lebih umum daripada web browser lakukan. Klien mengakses operasi di antarmuka.

layanan web dengan cara permintaan dan balasan diformat dalam XML dan biasanya ditularkan melalui HTTP. layanan web dapat diakses dengan cara yang lebih ad hoc dari berbasis CORBA layanan, memungkinkan mereka untuk lebih mudah digunakan dalam aplikasi Internet-lebar.
Seperti CORBA dan Java, antarmuka layanan web dapat digambarkan dalam IDL.
Tapi untuk layanan web, informasi tambahan, termasuk encoding dan komunikasi
protokol yang digunakan dan lokasi layanan harus disediakan.
Pengguna membutuhkan sarana yang aman untuk menciptakan, menyimpan dan memodifikasi dokumen dan
bertukar mereka melalui Internet. Saluran aman dari Transport Layer Security (TLS,
dijelaskan pada Bab 9) tidak menyediakan semua persyaratan yang diperlukan.

keamanan XML adalah dimaksudkan untuk menjembatani kesenjangan ini.
layanan web yang semakin penting dalam sistem terdistribusi: mereka mendukung
interoperabilitas di Internet global, termasuk area utama bisnis-ke-bisnis
integrasi dan juga muncul 'mashup' budaya memungkinkan pengembang pihak ketiga untuk
software inovatif kreatif di atas dasar layanan yang ada. layanan web juga menyediakan
yang mendasari middleware untuk kedua Grid dan komputasi awan.

Pertumbuhan Web dalam dua dekade terakhir (lihat Gambar 1.6) membuktikan efektivitas
menggunakan protokol sederhana melalui Internet sebagai dasar untuk sejumlah besar wide-area
layanan dan aplikasi. Secara khusus, HTTP request-reply protocol (Bagian 5.2),
memungkinkan klien untuk keperluan umum, yang disebut browser, untuk melihat halaman web dan sumber daya lainnya
dengan mengacu pada Uniform Resource Locator mereka (URL - lihat kotak di bawah untuk catatan
pada URI, URL dan guci).
URI, URL dan URN • The Uniform Resource Identifier (URI) adalah sumber daya umum
identifier, yang nilainya dapat berupa URL atau URN. URL, yang meliputi
informasi lokasi sumber daya seperti nama domain dari server sumberdaya
yang bernama, dikenal untuk semua pengguna web. Uniform Nama Sumber Daya (guci) adalah
lokasi-independen - mereka bergantung pada layanan pencarian untuk memetakan mereka ke URL
sumber. Guci dibahas secara lebih rinci dalam Bagian 13.1.
Namun, penggunaan browser tujuan umum sebagai klien, bahkan dengan
perangkat tambahan yang disediakan oleh applet khusus aplikasi download, membatasi
lingkup potensi aplikasi. Dalam model client-server asli, baik klien dan server
yang fungsional khusus. layanan web kembali ke model ini, di mana sebuah
client khusus aplikasi berinteraksi dengan layanan dengan fungsional khusus
antarmuka melalui Internet.
Dengan demikian, layanan web menyediakan infrastruktur untuk mempertahankan lebih kaya dan lebih
bentuk terstruktur dari interoperabilitas antara klien dan server. Mereka memberikan dasar
dimana program klien dalam satu organisasi dapat berinteraksi dengan server di lain
organisasi tanpa pengawasan manusia. Secara khusus, layanan web memungkinkan kompleks
aplikasi yang akan dikembangkan dengan menyediakan layanan yang mengintegrasikan beberapa layanan lainnya.
Karena keumuman interaksi mereka, layanan web tidak dapat diakses langsung oleh
browser.
Penyediaan layanan web sebagai tambahan ke server web didasarkan pada kemampuan
menggunakan permintaan HTTP menyebabkan pelaksanaan program. Ingatlah bahwa ketika URL di
permintaan HTTP mengacu pada program dieksekusi, misalnya, pencarian, hasilnya adalah
diproduksi oleh program itu dan kembali. Dalam cara yang sama, layanan web merupakan perpanjangan
Web dan dapat disediakan oleh server web. Namun, server mereka tidak perlu menjadi web
server. Istilah 'web server' dan 'layanan web' tidak harus bingung: web server
menyediakan layanan HTTP dasar, sedangkan layanan web menyediakan layanan berdasarkan
operasi didefinisikan dalam interface-nya.
Eksternal representasi data dan marshalling pesan dipertukarkan antara
klien dan layanan web dilakukan dalam XML, yang dijelaskan dalam Bagian 4.3.3. Untuk rekap,
XML merupakan representasi tekstual itu, meskipun lebih besar daripada alternatif
representasi, telah diadopsi untuk pembacaan dan kemudahan akibatnya
debugging.
Protokol SOAP (Bagian 9.2.1) menetapkan aturan untuk menggunakan XML untuk paket
pesan, misalnya untuk mendukung protokol request-reply. Gambar 9.1 meringkas
poin utama tentang arsitektur komunikasi di mana layanan web mengoperasikan: web
layanan diidentifikasi oleh URI dan dapat diakses oleh klien menggunakan pesan diformat

9.1 Web dan komponen infrastruktur layanan
Keamanan
deskripsi layanan (WSDL)
Aplikasi
layanan direktori
Layanan web
XML
Koreografi
SABUN
URI (URL atau guci) HTTP, SMTP atau transportasi lainnya
9.1 PENDAHULUAN
dalam XML. SOAP digunakan untuk merangkum pesan-pesan ini dan mengirimkan mereka melalui HTTP atau
protokol lain, misalnya, TCP atau SMTP. Sebuah layanan layanan web dikerahkan
deskripsi untuk menentukan antarmuka dan aspek lain dari layanan untuk kepentingan
klien potensial.
Lapisan atas gambar menggambarkan berikut:
• layanan Web dan aplikasi dapat dibangun di atas layanan web lainnya.
• Beberapa layanan web tertentu menyediakan fungsionalitas umum yang diperlukan untuk
pengoperasian sejumlah besar layanan web lainnya. Mereka termasuk direktori
layanan, keamanan dan koreografi, yang semuanya dibahas kemudian dalam hal ini
bab.
Sebuah layanan web pada umumnya menyediakan deskripsi layanan, yang meliputi antarmuka
definisi dan informasi lain, seperti URL server. Ini digunakan sebagai dasar untuk
pemahaman bersama antara klien dan server untuk layanan yang ditawarkan. Bagian
9.3 menyajikan Web Services Description Language (WSDL).
kebutuhan lain yang umum di middleware adalah untuk layanan penamaan atau direktori untuk memungkinkan
klien untuk mencari tahu tentang layanan. Klien layanan web memiliki kebutuhan yang sama, tetapi
sering mengelola tanpa layanan direktori. Misalnya, mereka sering mencari tahu tentang
layanan dari informasi pada halaman web (misalnya, sebagai hasil dari pencarian Google).
Namun, beberapa pekerjaan yang telah dilakukan untuk memberikan layanan direktori yang cocok untuk digunakan
dalam organisasi. Hal ini dibahas dalam Bagian 9.4.
keamanan XML diperkenalkan dalam Bagian 9.5. Dalam pendekatan ini untuk keamanan, dokumen
atau bagian dari dokumen dapat ditandatangani atau dienkripsi. Sebuah dokumen yang telah ditandatangani atau
elemen terenkripsi dapat ditransmisikan atau disimpan; Yang kemudian dapat dibuat dan
ini juga dapat ditandatangani atau dienkripsi.
layanan web menyediakan akses ke sumber daya untuk klien remote, tapi mereka tidak
menyediakan sarana untuk mengkoordinasikan operasi mereka dengan satu sama lain. bagian 9.7.3
membahas koreografi layanan web, yang dimaksudkan untuk memungkinkan layanan satu web ke
menggunakan pola yang telah ditetapkan akses dalam menggunakan satu set layanan web lainnya.
Bagian terakhir dari bab ini menganggap aplikasi layanan web, termasuk
dukungan untuk arsitektur berorientasi layanan, Grid dan komputasi awan.



9.2 layanan Web
Sebuah antarmuka layanan web umumnya terdiri dari kumpulan operasi yang dapat digunakan
oleh klien melalui Internet. Operasi dalam layanan web dapat diberikan oleh
berbagai sumber daya yang berbeda, misalnya, program, benda atau database. Sebuah web
layanan dapat dikelola oleh server web bersama dengan halaman web; atau mungkin benar-benar
layanan terpisah.
Karakteristik utama dari layanan web yang paling adalah bahwa mereka dapat memproses XMLformatted
pesan SOAP (lihat Bagian 9.2.1). Sebuah alternatif adalah pendekatan SISA
yang diuraikan di dalam kotak di halaman 386. Setiap layanan web menggunakan layanan sendiri
deskripsi untuk berurusan dengan karakteristik khusus layanan pesan yang diterimanya.
Untuk laporan yang baik dari banyak aspek yang lebih rinci dari layanan web, lihat Newcomer
[2002] atau Alonso et al. [2004].
Banyak terkenal server web komersial termasuk Amazon, Yahoo, Google
dan eBay, menawarkan layanan web antarmuka yang memungkinkan klien untuk memanipulasi web mereka
sumber. Sebagai contoh, layanan web yang ditawarkan oleh Amazon.com menyediakan operasi
untuk mengizinkan klien untuk mendapatkan informasi tentang produk, untuk menambahkan item ke keranjang belanja atau
untuk memeriksa status transaksi. Layanan web Amazon [associates.amazon.com]
dapat diakses baik oleh SOAP atau REST. Hal ini memungkinkan aplikasi pihak ketiga untuk
membangun layanan nilai tambah lebih yang disediakan oleh Amazon.com. Sebagai contoh, sebuah
inventory control dan aplikasi pembelian mungkin memesan persediaan berbagai
komoditas seperti yang diperlukan dari Amazon.com dan secara otomatis melacak
mengubah status setiap pesanan. Lebih dari 50.000 pengembang terdaftar untuk menggunakan web ini
layanan dalam dua tahun pertama setelah mereka diperkenalkan [Greenfield dan Dornan 2004].
Contoh lain yang menarik dari aplikasi yang membutuhkan kehadiran web
layanan adalah salah satu yang mengimplementasikan 'sniping' di lelang eBay - yaitu, menempatkan tawaran selama
beberapa detik terakhir sebelum lelang ditutup. Meskipun manusia dapat melakukan hal yang sama
tindakan oleh interaksi langsung dengan halaman web, mereka tidak dapat melakukannya dengan cepat.
Kombinasi layanan web • Memberikan sebuah antarmuka untuk layanan web memungkinkan nya
operasi yang akan digabung dengan layanan lain untuk menyediakan fungsionalitas baru (lihat
juga Bagian 9.7.1). Aplikasi pembelian disebutkan di atas mungkin menggunakan lainnya
pemasok juga. Sebagai contoh lain dari manfaat menggabungkan beberapa layanan,
mempertimbangkan fakta bahwa banyak orang memesan penerbangan, hotel dan sewa mobil untuk perjalanan secara online
menggunakan berbagai situs web yang berbeda. Jika masing-masing situs web ini adalah untuk memberikan
antarmuka layanan web standar, maka 'wisata layanan agen' bisa menggunakan operasi mereka
untuk menyediakan wisatawan dengan kombinasi layanan ini. Hal ini diilustrasikan dalam
Gambar 9.2.
pola komunikasi • Layanan agen perjalanan menggambarkan kemungkinan penggunaan dua
pola komunikasi alternatif yang tersedia dalam layanan web:
• Pengolahan pemesanan memakan waktu lama untuk menyelesaikan dan bisa jadi
didukung oleh pertukaran asynchronous dokumen, dimulai dengan rincian
tanggal dan tujuan, diikuti dengan kembalinya informasi status dari waktu ke
waktu dan akhirnya rincian penyelesaian. Kinerja tidak menjadi masalah di sini.

Pengecekan rincian kartu kredit dan interaksi dengan klien harus
didukung oleh protokol request-reply.
Secara umum, layanan web baik menggunakan pola request-reply sinkron
komunikasi dengan klien mereka atau berkomunikasi dengan cara pesan asynchronous.
Gaya yang terakhir dari komunikasi dapat digunakan bahkan ketika permintaan memerlukan balasan, di
hal klien mengirimkan permintaan dan kemudian menerima balasan asynchronous.
Pola acara-style juga dapat digunakan: misalnya, klien dari layanan direktori mungkin
mendaftar untuk acara yang menarik dan akan diberitahu setiap kali acara tertentu (seperti
kedatangan atau keberangkatan dari layanan) terjadi.
Untuk memungkinkan berbagai pola komunikasi, protokol SOAP
(Dibahas dalam Bagian 9.2.1) didasarkan pada kemasan tunggal pesan satu arah. Nya
mendukung interaksi permintaan-balasan dengan menggunakan pasang pesan tunggal dan menentukan
bagaimana untuk mewakili operasi, argumen mereka dan hasil mereka.
Lebih umum, layanan web yang dirancang untuk mendukung komputasi terdistribusi di
Internet, di mana banyak bahasa pemrograman yang berbeda dan paradigma hidup berdampingan.
Oleh karena itu, mereka dirancang untuk menjadi independen dari setiap paradigma pemrograman tertentu.
Hal ini berbeda dengan, misalnya, didistribusikan benda yang menganjurkan agak spesifik
paradigma pemrograman untuk pengembang (pembahasan lebih lanjut dari perbedaan antara
layanan web dan objek terdistribusi dapat ditemukan pada Bagian 9.2.2).
kopling longgar • Ada minat yang cukup besar dalam kopling longgar dalam sistem terdistribusi,
khususnya di komunitas layanan web. terminologi sering tidak jelas dan
tidak tepat, meskipun. Dalam konteks layanan web, kopling longgar mengacu meminimalkan
dependensi antara layanan dalam rangka untuk memiliki arsitektur yang mendasari fleksibel
(Mengurangi risiko bahwa perubahan dalam satu layanan akan memiliki knock-on efek pada lainnya
layanan). Hal ini sebagian didukung oleh kemandirian dimaksudkan layanan web dengan
niat berikutnya untuk menghasilkan kombinasi layanan web seperti yang dibahas di atas.
kopling longgar, bagaimanapun, lebih ditingkatkan dengan sejumlah fitur tambahan:
• Programming dengan antarmuka (seperti dibahas dalam Bab 5) memberikan satu tingkat dari
loose coupling dengan memisahkan interface dari implementasinya (dan juga
mendukung bidang-bidang penting dari heterogenitas, - misalnya dalam pilihan
bahasa pemrograman dan platform yang digunakan). Pemrograman dengan interface adalah diadopsi oleh sistem paradigma yang paling didistribusikan termasuk objek terdistribusi dan
komponen (dibahas dalam Bab 8) serta layanan web.
• Ada kecenderungan sederhana, antarmuka generik dalam sistem terdistribusi dan ini
dicontohkan oleh antarmuka minimal yang ditawarkan oleh World Wide Web dan
pendekatan ISTIRAHAT
SISA (Negara Transfer) • SISA [Fielding 2000] adalah sebuah pendekatan dengan
gaya yang sangat dibatasi operasi, di mana klien menggunakan URL dan HTTP
operasi GET, PUT, DELETE dan POST untuk memanipulasi sumber daya yang
direpresentasikan dalam XML. Penekanannya adalah pada manipulasi sumber data yang lebih
dari pada antarmuka. Ketika sumber daya baru dibuat, ia memiliki URL baru yang bisa
diakses atau diperbarui. Klien disediakan dengan seluruh negara bagian sumber daya bukan
menelepon operasi untuk mendapatkan beberapa bagian dari itu. Fielding berpendapat bahwa dalam konteks
Internet, proliferasi antarmuka layanan yang berbeda tidak akan berguna sebagai
seragam minimum sederhana mengatur operasi. Sangat menarik untuk dicatat bahwa, menurut
Greenfield dan Dornan [2004], 80% dari permintaan untuk layanan web di
Amazon.com adalah melalui antarmuka REST, dengan sisanya 20% menggunakan SOAP.
dalam layanan web. Pendekatan ini memberikan kontribusi untuk kehilangan kopling oleh
mengurangi ketergantungan pada nama operasi tertentu (studi kasus Google di
Bab 21 memberikan contoh lebih lanjut dari gaya pemrograman terdistribusi).
Salah satu konsekuensi dari ini adalah bahwa data menjadi lebih penting daripada operasi, dengan
semantik interoperation sering diadakan dalam data (misalnya, terkait
definisi dokumen XML dalam layanan web); tampilan data berorientasi ini dibahas
lebih lanjut dalam konteks ponsel 19.3.2 sistem Seksi.
• Seperti disebutkan di atas, layanan web dapat digunakan dengan berbagai komunikasi
paradigma, termasuk komunikasi request-reply, pesan asynchronous atau
memang paradigma komunikasi tidak langsung (seperti yang ditampilkan dalam Bab 6). Tingkat
kopling secara langsung dipengaruhi oleh pilihan ini. Misalnya, dalam permintaan-balasan
komunikasi, kedua pihak secara intrinsik digabungkan; asynchronous
messaging menawarkan tingkat decoupling (disebut sebagai sinkronisasi
uncoupling dalam Bab 6), sedangkan komunikasi tidak langsung juga menawarkan waktu dan
ruang uncoupling.
Kesimpulannya, ada sejumlah dimensi untuk kopling longgar, dan penting untuk
beruang ini dalam pikiran ketika menggunakan istilah. layanan web intrinsik mendukung tingkat longgar
kopling karena filosofi desain yang diadopsi dan pemrograman dengan interface
Pendekatan yang digunakan. Hal ini dapat lebih ditingkatkan dengan pilihan desain tambahan, termasuk
adopsi pendekatan REST dan penggunaan komunikasi tidak langsung.
Representasi dari pesan • Kedua SOAP dan data yang dibawanya direpresentasikan dalam
XML, tekstual Format diri menggambarkan diperkenalkan dalam Bagian 4.3.3. tekstual
representasi memakan lebih banyak tempat dari yang biner dan parsing yang mereka butuhkan
membutuhkan lebih banyak waktu untuk memproses. Dalam dokumen-gaya interaksi kecepatan tidak menjadi masalah, tetapi
penting dalam interaksi permintaan-balasan. Namun, ia berpendapat bahwa ada keuntungan
dalam format yang dapat dibaca manusia yang memungkinkan untuk mudah pembangunan pesan sederhana dan
untuk debugging lebih yang kompleks.
Setiap item dalam deskripsi XML dijelaskan dengan jenis dan makna
setiap jenis didefinisikan oleh skema direferensikan dalam deskripsi. Hal ini membuat

Format extensible, yang memungkinkan semua jenis data yang akan diangkut. Tidak ada batasan untuk
potensi kekayaan dan kompleksitas dokumen diformat dalam XML, tapi mungkin ada
masalah dalam menafsirkan mereka yang menjadi terlalu kompleks.
referensi layanan • Secara umum, masing-masing layanan web memiliki URI, yang menggunakan klien untuk merujuk
untuk itu. URL adalah bentuk yang paling sering digunakan URI. Karena URL berisi
nama domain dari sebuah komputer, layanan untuk yang merujuk akan selalu diakses pada saat itu
komputer. Namun, titik akses layanan web dengan URN dapat bergantung pada
konteks dan dapat berubah dari waktu ke waktu - URL saat ini dapat diperoleh dari URN
layanan pencarian. referensi layanan ini dikenal sebagai titik akhir dalam layanan web.
Aktivasi layanan • Sebuah layanan web akan diakses melalui komputer yang domain
Nama termasuk dalam URL saat ini. komputer yang dapat menjalankan layanan web itu sendiri atau
dapat berjalan di komputer server lain. Misalnya, layanan dengan puluhan ribu
klien mungkin perlu digunakan pada ratusan komputer. Sebuah layanan web dapat dijalankan
terus menerus, atau mungkin diaktifkan pada permintaan. URL adalah referensi gigih,
yang berarti bahwa itu akan terus merujuk ke layanan selama server URL
menunjuk ke ada.
Transparansi • Tugas utama dari banyak platform middleware adalah untuk melindungi
programmer dari rincian representasi data dan marshalling; lain adalah untuk membuat
doa jarak jauh terlihat seperti orang lokal. Tak satu pun dari hal-hal ini disediakan sebagai bagian dari
infrastruktur atau middleware platform untuk layanan web. Pada tingkat yang paling sederhana, klien
dan server dapat membaca dan menulis pesan mereka secara langsung di SOAP, menggunakan XML.
Tapi untuk kenyamanan, rincian SOAP dan XML umumnya disembunyikan oleh
API lokal dalam bahasa pemrograman seperti Java, Perl, Python atau C ++. Pada kasus ini,
deskripsi layanan dapat digunakan sebagai dasar untuk secara otomatis menghasilkan yang diperlukan
marshalling dan prosedur unmarshalling.
Proxy: Salah satu cara untuk menyembunyikan perbedaan antara panggilan lokal dan jarak jauh adalah dengan memberikan
proxy klien atau satu set prosedur rintisan. Bagian 9.2.3 menjelaskan bagaimana hal ini dilakukan di Jawa.
proxy klien atau bertopik memberikan bentuk statis doa di mana kerangka kerja untuk
setiap panggilan dan prosedur marshalling dihasilkan sebelum doa dilakukan.
doa dinamis: Sebuah alternatif untuk proxy adalah untuk menyediakan klien dengan generik
operasi yang akan digunakan terlepas dari prosedur remote untuk dipanggil, mirip dengan
Prosedur DoOperation didefinisikan dalam Gambar 5.3 (tapi tanpa argumen pertama). Didalam
kasus, klien menentukan nama dari operasi dan argumen dan mereka
dikonversi ke SOAP dan XML dengan cepat. Komunikasi asynchronous tunggal
pesan dapat dicapai dengan cara yang sama dengan menyediakan klien dengan operasi generik
untuk mengirim dan menerima pesan.
9.2.1 SOAP
SOAP dirancang untuk memungkinkan kedua client-server dan interaksi asynchronous atas
Internet. Ini mendefinisikan skema untuk menggunakan XML untuk mewakili isi permintaan dan
membalas pesan (lihat Gambar 5.4) serta skema untuk komunikasi
dokumen. Awalnya SOAP didasarkan hanya pada HTTP, tapi versi saat ini adalah
dirancang untuk menggunakan berbagai protokol transportasi termasuk SMTP, TCP atau UDP.

9.3 SOAPesan dalam amplop
amplop
Header
tubuh
elemen header
elemen body
elemen header
elemen body
Spesifikasi SOAP negara:
• bagaimana XML yang akan digunakan untuk mewakili isi pesan individu;
• bagaimana sepasang pesan tunggal dapat dikombinasikan untuk menghasilkan pola permintaan-balasan;
• aturan bagaimana penerima pesan harus memproses elemen XML
bahwa mereka mengandung;
• bagaimana HTTP dan SMTP harus digunakan untuk mengkomunikasikan pesan SOAP. ini
Diharapkan versi masa depan dari spesifikasi akan menentukan bagaimana menggunakan lainnya
protokol transportasi, misalnya, TCP.
Bagian ini menjelaskan bagaimana SOAP menggunakan XML untuk mewakili pesan dan HTTP untuk
berkomunikasi mereka. Namun, programmer biasanya tidak perlu khawatir
dengan rincian ini, karena API SOAP telah diterapkan di banyak pemrograman
bahasa, termasuk Java, JavaScript, Perl, Python, NET, C, C ++, C # dan Visual Basic.
Untuk mendukung komunikasi client-server, SOAP menentukan bagaimana menggunakan HTTP
Metode POST untuk pesan permintaan dan respon untuk pesan balasan. Itu
dikombinasikan penggunaan XML dan HTTP menyediakan protokol standar untuk client-server
komunikasi melalui Internet.
Hal ini bertujuan agar pesan SOAP dapat ditularkan melalui perantara di jalan
ke komputer yang mengelola sumber daya yang akan diakses dan yang lebih tinggi tingkat
layanan middleware seperti transaksi atau keamanan dapat menggunakan perantara ini untuk
melakukan pengolahan.
pesan SOAP • Sebuah pesan SOAP dilakukan dalam 'amplop'. Di dalam amplop
ada header opsional dan tubuh, seperti yang ditunjukkan pada Gambar 9.3. Header pesan dapat
digunakan untuk membangun konteks yang diperlukan untuk layanan atau untuk menjaga log atau audit
operasi. Perantara dapat menafsirkan dan bertindak atas informasi dalam pesan.



9.4 Contoh permintaan sederhana tanpa header
Dunia nama dalam huruf miring, di sudut kiri atas, diikuti dengan atribut dan isinya
Elemen XML amplop, header dan tubuh, bersama-sama dengan atribut lainnya dan
unsur pesan SOAP, didefinisikan sebagai skema dalam namespace SOAP XML.
Definisi skema ini dapat ditemukan di situs web W3C [www.w3.org IX].
Karena mereka menggunakan pengkodean tekstual, XML skema dapat dilihat dengan 'view source'
pilihan browser. Kedua header dan tubuh mengandung unsur batin.
Bagian sebelumnya menjelaskan bahwa deskripsi layanan berisi informasi yang
adalah untuk digunakan bersama oleh klien dan server. Pesan pengirim menggunakan deskripsi ini untuk menghasilkan
tubuh dan untuk memastikan bahwa itu berisi isi yang benar, dan penerima pesan menggunakan
mereka untuk mengurai dan memeriksa validitas isi.
Sebuah pesan SOAP dapat digunakan baik untuk menyampaikan dokumen atau untuk mendukung client
komunikasi:
• Sebuah dokumen yang akan dikomunikasikan ditempatkan langsung di dalam elemen body
bersama-sama dengan referensi ke sebuah skema XML yang berisi deskripsi layanan -
yang mendefinisikan nama dan jenis yang digunakan dalam dokumen. Ini semacam SOAP
Pesan dapat dikirim baik serentak atau asynchronous.
• Untuk komunikasi client-server, elemen body berisi baik Permintaan atau
Balasan. Kedua kasus diilustrasikan pada Gambar 9.4 dan Gambar 9.5.
Gambar 9.4 menunjukkan contoh pesan permintaan sederhana tanpa header. Tubuh
membungkus elemen yang berisi nama prosedur yang akan dipanggil dan URI
namespace (file yang berisi skema XML) untuk layanan yang relevan
deskripsi, yang dilambangkan dengan m. Unsur-unsur dalam dari pesan permintaan berisi
argumen dari prosedur. pesan permintaan ini menyediakan dua string yang akan dikembalikan
kebalikan urutan dengan prosedur di server. XML namespace dilambangkan dengan env
berisi definisi SOAP untuk amplop. Gambar 9.5 menunjukkan yang sesuai
sukses pesan balasan, yang berisi dua argumen output. Perhatikan bahwa nama
prosedur memiliki 'Respon' ditambahkan ke dalamnya. Jika prosedur memiliki nilai kembali, maka itu mungkin
dinotasikan sebagai rpc elemen yang disebut: hasil. Balasan pesan menggunakan yang sama dua XML.

9.5 Contoh balasan sesuai dengan permintaan pada Gambar 9.4
xmlns amplop:: env env = namespace URI untuk amplop SOAP
m: RES1
env: tubuh
xmlns: m = namespace URI untuk layanan deskripsi
m: res2
Dunia
m: exchangeResponse
Halo
390 BAB 9 LAYANAN WEB
skema sebagai pesan permintaan, yang pertama mendefinisikan amplop SOAP dan yang kedua
prosedur dan argumen nama aplikasi-spesifik.
Sabun kesalahan: Jika permintaan gagal dalam beberapa cara, deskripsi kesalahan disampaikan dalam
body dari pesan balasan dalam elemen kesalahan. Elemen ini berisi informasi tentang
kesalahan, termasuk kode dan string terkait, bersama-sama dengan aplikasi-spesifik
Rincian.
header SOAP • Header pesan yang dimaksudkan untuk digunakan oleh perantara untuk menambah
layanan yang berhubungan dengan pesan yang dibawa dalam tubuh yang sesuai. Namun, dua
aspek penggunaan ini dibiarkan tidak jelas dalam spesifikasi SOAP:
1. Bagaimana header akan digunakan oleh layanan middleware tinggi tertentu. Untuk
Misalnya, header mungkin berisi:
- Pengenal transaksi untuk digunakan dengan layanan transaksi;
- Pengenal pesan untuk berhubungan pesan satu sama lain, misalnya, untuk
melaksanakan pengiriman yang handal;
- Username, tanda tangan digital atau kunci publik.
2. Bagaimana pesan akan dialihkan melalui serangkaian perantara ke ultimate
penerima. Misalnya, pesan diangkut oleh HTTP dapat dialihkan melalui
rantai proxy server, beberapa di antaranya mungkin menganggap peran SOAP.
Namun, spesifikasi tidak menentukan peran dan tugas dari perantara. Sebuah
atribut yang disebut peran dapat menentukan apakah setiap perantara, tidak satupun dari mereka, atau hanya
penerima utama harus memproses elemen [www.w3.org IX]. Tindakan tertentu untuk
dilakukan didefinisikan oleh aplikasi - misalnya, tindakan mungkin untuk log
isi elemen.
Transportasi dari pesan SOAP • Sebuah protokol transport diperlukan untuk mengirim SOAP sebuah
pesan ke tujuan. pesan SOAP independen dari jenis transportasi yang digunakan
- Amplop mereka tidak mengandung referensi ke alamat tujuan. HTTP (atau apa pun
protokol yang digunakan untuk mengangkut pesan SOAP) yang tersisa untuk menentukan alamat tujuan.
Gambar 9.6 menggambarkan bagaimana metode HTTP POST digunakan untuk mengirimkan SOAP sebuah
pesan. Header HTTP dan tubuh yang digunakan sebagai berikut:

9.6 Penggunaan HTTP POST Permintaan dalam SOAP komunikasi client-server
alamat endpoint
tindakan
POST / contoh / stringer
Host: www.cdk4.net
Content-Type: application / sabun + xml
Action: http://www.cdk4.net/examples/stringer#exchange
<Env: xmlns amplop: env = namespace URI untuk amplop SOAP>
<Env: header> </ env: header>
<Env: body> </ env: body>
</ Env: Envelope>
pesan SOAP HTTP header
BAGIAN 9.2 WEB SERVICES 391
• Header HTTP menentukan alamat endpoint (URI penerima akhir)
dan tindakan yang akan dilakukan. Header Aksi ini dimaksudkan untuk mengoptimalkan
pengiriman dengan mengungkapkan nama operasi tanpa perlu menganalisis
pesan SOAP di tubuh pesan HTTP.
• Tubuh HTTP membawa pesan SOAP.
HTTP adalah protokol sinkron, digunakan untuk mengembalikan balasan yang berisi SOAP
menjawab, seperti yang ditunjukkan pada Gambar 9.5. Bagian 5.2 Rincian kode status dan alasan
dikembalikan oleh HTTP untuk permintaan sukses dan gagal.
Jika SOAP Permintaan hanya permintaan untuk informasi yang akan dikembalikan, tidak ada yang memiliki
argumen dan tidak mengubah data di server, maka metode HTTP GET dapat digunakan
untuk melaksanakannya.
Titik di atas tentang header Action dan pengiriman berlaku untuk setiap layanan
yang melakukan berbagai tindakan yang berbeda untuk klien, bahkan jika itu tidak menawarkan operasi
seperti. Misalnya, layanan web mungkin dapat menangani berbagai jenis
dokumen, seperti pesanan pembelian dan pertanyaan, yang ditangani oleh yang berbeda
modul software. Header Action memungkinkan modul yang benar untuk dipilih tanpa
memeriksa pesan SOAP. Header ini dapat digunakan jika jenis konten HTTP adalah
ditetapkan sebagai aplikasi / sabun + xml.
Pemisahan definisi amplop SOAP dari informasi untuk
bagaimana dan di mana ia akan dikirim memungkinkan untuk menggunakan berbagai berbeda mendasari
protokol. Misalnya, spesifikasi SOAP menyatakan bagaimana SMTP dapat digunakan sebagai
cara alternatif transmisi dokumen dikodekan sebagai pesan SOAP.
Namun kekuatan ini juga kelemahan. Ini menyiratkan bahwa pengembang harus terlibat
dalam rincian protokol transport tertentu yang dipilih. Selain itu, membuat sulit
menggunakan protokol yang berbeda untuk bagian yang berbeda dari rute diikuti oleh tertentu
pesan.
WS-Addressing: Kemajuan dalam SOAP dan routing • Dua masalah yang disebutkan
atas:
• bagaimana membuat SOAP independen dari transportasi yang mendasari digunakan;
• bagaimana menentukan rute yang harus diikuti oleh pesan SOAP melalui serangkaian
perantara.

Awal bekerja di daerah ini oleh Nielsen dan Thatte [2001] menunjukkan bahwa alamat endpoint
dan informasi pengiriman harus ditentukan dalam header SOAP. Hal ini secara efektif
memisahkan tujuan pesan dari protokol yang mendasari. mereka menyarankan
menentukan jalur yang harus diikuti dengan memberikan alamat endpoint dan 'berikutnya
melompat'. Masing-masing dari perantara akan memperbarui informasi 'hop berikutnya'.
Karya Box dan Curbera [2004] menunjukkan bahwa memiliki perantara mengubah
header dapat menyebabkan pelanggaran keamanan. Mereka mengusulkan WS-Addressing, yang
memungkinkan header SOAP untuk menentukan pesan routing data, dengan SOAP mendasari
infrastruktur memberikan informasi 'hop berikutnya'. Rekomendasi W3C untuk
WS-Addressing didefinisikan dalam [www.w3.org XXIII]. Bentuk pengalamatan menggunakan
Endpoint Referensi - struktur XML yang berisi alamat tujuan, routing
informasi dan informasi kemungkinan lain tentang layanan. Untuk mendukung lama berjalan
interaksi asynchronous, header SOAP dapat menyediakan alamat pengirim dan pesan
pengidentifikasi mereka sendiri dan pesan terkait.
WS-ReliableMessaging: protokol yang biasa Reliable komunikasi • SOAP, HTTP,
berjalan di atas TCP, yang Model gagal dibahas dalam Bagian 4.2.4. Untuk meringkas: TCP
tidak menjamin untuk menyampaikan pesan dalam menghadapi semua kesulitan, dan ketika kali
sambil menunggu ucapan terima kasih, itu menyatakan bahwa sambungan rusak, di
yang intinya proses berkomunikasi dibiarkan tanpa ide untuk apakah
pesan mereka terkirim baru-baru ini telah diterima atau tidak.
Awal bekerja pada penyediaan komunikasi yang handal dari pesan SOAP dengan
dijamin pengiriman, tidak ada duplikat dan dijamin pesan memesan menyebabkan dua
bersaing spesifikasi oleh Ferris dan Langworthy [2004] dan Evans et al. [2003].
Baru-baru ini, Oasis (sebuah konsorsium global yang bekerja pada pengembangan,
kesepakatan dan adopsi standar e-bisnis dan layanan web) telah membuat
Rekomendasi disebut WS-ReliableMessaging [www.oasis.org]. Hal ini memungkinkan SOAP a
pesan yang akan disampaikan di-setidaknya-sekali, di-paling-sekali atau tepat-sekali, dengan mengikuti
semantik:
At-setidaknya-sekali: Pesan tersebut disampaikan setidaknya sekali, tapi kesalahan dilaporkan jika
tidak dapat disampaikan.
At-paling-sekali: Pesan tersebut disampaikan paling banyak sekali, tetapi tanpa laporan kesalahan jika
tidak dapat disampaikan.
Tepat-sekali: Pesan tersebut disampaikan tepat sekali, tapi kesalahan dilaporkan jika
tidak dapat disampaikan.
Pemesanan pesan juga disediakan dalam kombinasi dengan apapun di atas:
Di-order: Pesan akan dikirimkan ke tujuan dalam urutan di mana mereka
dikirim oleh pengirim tertentu.
Perhatikan bahwa WS-ReliableMessaging prihatin dengan pengiriman pesan tunggal dan
tidak harus bingung dengan semantik RPC panggilan dijelaskan dalam Bagian 5.3.1, yang
mengacu pada jumlah kali server mengeksekusi prosedur remote. pembaca
disebut Latihan 9.16 untuk pertimbangan lebih lanjut dari perbandingan.
Melintasi firewall • layanan Web yang dimaksudkan untuk digunakan oleh klien dalam satu
organisasi untuk mengakses server di organisasi lain melalui Internet. Paling organisasi menggunakan firewall untuk melindungi sumber daya pada jaringan mereka sendiri, dan
protokol transportasi seperti yang digunakan oleh Java RMI atau CORBA biasanya tidak akan dapat
untuk melewati firewall. Namun, firewall yang biasanya memungkinkan kedua HTTP dan SMTP
pesan untuk melewati mereka. Oleh karena itu akan lebih mudah untuk menggunakan salah satu dari protokol ini
untuk mengangkut pesan SOAP.
9.2.2 Perbandingan layanan web dengan model objek terdistribusi
Sebuah layanan web memiliki antarmuka layanan yang dapat menyediakan operasi untuk mengakses dan
memperbarui sumber data yang berhasil. Pada tingkat dangkal, interaksi antara
client dan server sangat mirip dengan RMI, di mana klien menggunakan referensi objek remote untuk
memanggil operasi pada objek remote. Untuk layanan web, klien menggunakan URI untuk memohon
operasi di sumber daya bernama oleh URI. Untuk argumen tentang persamaan dan
Perbedaan antara layanan web dan objek terdistribusi, melihat Birman [2004], Vinoski
[2002] dan Vogels [2003].
Kami akan mencoba untuk menunjukkan bahwa ada batas untuk analogi di atas, dengan menggunakan
contoh papan tulis bersama yang digunakan dalam Bagian 5.5 untuk Java RMI dan Bagian 8.3 untuk
CORBA.
referensi objek remote vs URI • The URI dari layanan web dapat dibandingkan
dengan referensi objek remote dari satu objek. Namun, di objek terdistribusi
Model, objek dapat membuat objek jarak jauh secara dinamis dan kembali referensi remote untuk
mereka. Penerima ini referensi yang dapat menggunakannya untuk memanggil operasi di
benda yang mereka lihat. Dalam contoh papan tulis bersama, sebuah doa dari
metode pabrik newShape menyebabkan contoh baru dari Shape yang akan dibuat dan remote
referensi untuk itu dikembalikan. Tidak ada yang seperti ini dapat dilakukan dengan layanan web, yang tidak bisa
membuat contoh benda terpencil; efektif, layanan web terdiri dari satu remote
objek dan karena itu baik pengumpulan sampah dan objek remote referensi yang
tidak relevan.
Model layanan web • Pengguna Java layanan web toolkit (JAX-RPC)
[Java.sun.com VII] harus memodelkan program layanan web mereka untuk memungkinkan fakta bahwa
mereka tidak menggunakan transparan Java-to-Jawa terpencil doa melainkan menggunakan
model layanan web, di mana benda-benda jauh tidak dapat dipakai. Ini diambil dalam
akun dengan JAX-RPC, yang tidak mengizinkan referensi objek remote akan disahkan sebagai
argumen atau dikembalikan sebagai hasil.
Gambar 9.7 menunjukkan versi dari antarmuka yang diberikan pada Gambar 5.16 yang telah
diubah sebagai berikut untuk menjadi antarmuka layanan web:
• Di asli (objek terdistribusi) versi program, contoh Shape adalah
dibuat dalam server dan referensi remote untuk mereka dikembalikan oleh newShape,
yang dimodifikasi (layanan web) versi ditampilkan sejalan 1. Untuk menghindari
Instansiasi objek jauh dan penggunaan konsekuen referensi objek remote,
antarmuka Shape dihapus dan operasinya (getAllState dan getGOVersion
- Awalnya getVersion) ditambahkan ke antarmuka ShapeList.
• Di asli (objek terdistribusi) versi program, server disimpan a
vektor Shape. Ini akan berubah menjadi vektor GraphicalObject.

(Web service) versi metode newShape mengembalikan integer yang memberikan
offset dari GraphicalObject di vektor itu.
perubahan ini dengan metode newShape berarti bahwa itu tidak lagi metode pabrik - yang
adalah, itu tidak membuat turunan dari objek remote.
Pegawai • Dalam model objek terdistribusi, program server umumnya dimodelkan sebagai
koleksi hamba (objek berpotensi remote). Misalnya, papan tulis bersama
aplikasi yang digunakan salah satu hamba untuk daftar bentuk dan satu hamba untuk setiap grafis
objek yang dibuat. hamba ini diciptakan sebagai contoh dari kelas hamba ShapeList
dan Shape, masing-masing. Ketika server mulai, fungsi utamanya dibuat contoh
dari ShapeList, dan setiap kali klien disebut metode newShape server menciptakan
contoh Shape.
Sebaliknya, layanan web tidak mendukung pegawai. Oleh karena itu layanan web
aplikasi tidak dapat membuat pegawai dan ketika mereka dibutuhkan untuk menangani berbagai
sumber daya server. Untuk menegakkan situasi ini, implementasi layanan web
interface tidak harus memiliki baik konstruktor atau metode utama.
9.2.3 Penggunaan SOAP dengan Java
API Java untuk mengembangkan layanan web dan klien lebih SOAP disebut JAX-RPC.
Hal ini dijelaskan dalam Java layanan web tutorial [java.sun.com VII]. API ini menyembunyikan semua
rincian SOAP dari programer dari kedua klien dan jasa.
JAX-RPC peta beberapa jenis dalam bahasa Jawa untuk definisi dalam XML digunakan
di kedua pesan SOAP dan deskripsi layanan. jenis yang diizinkan meliputi Integer,
String, Tanggal dan Kalender, serta java.net.uri, yang memungkinkan URI akan disahkan sebagai
argumen atau dikembalikan sebagai hasil. Mendukung beberapa jenis koleksi (termasuk
Vektor) serta jenis primitif bahasa dan array.
Selain itu, contoh beberapa kelas dapat disahkan sebagai argumen dan hasil
panggilan jarak jauh, asalkan:
• Setiap variabel instance mereka adalah salah satu jenis yang diizinkan.
• Mereka memiliki konstruktor default publik.
• Mereka tidak mengimplementasikan antarmuka remote.

9,8 implementasi Java dari server ShapeList
       Layanan antarmuka • Antarmuka Java dari layanan web harus sesuai dengan
mengikuti aturan, beberapa di antaranya diilustrasikan pada Gambar 9.7:
• Ini harus memperpanjang antarmuka jauh.
• Tidak harus memiliki deklarasi konstan, seperti static final publik.
• Metode harus membuang java.rmi.RemoteException atau salah satu subclass.
• parameter Metode dan kembali jenis harus diizinkan jenis JAX-RPC.
Program server • Kelas yang mengimplementasikan ShapeList antarmuka ditunjukkan pada
Gambar 9.8. Seperti dijelaskan di atas, tidak ada metode utama, dan pelaksanaan
ShapeList antarmuka tidak memiliki konstruktor. Akibatnya, layanan web adalah satu objek
yang menawarkan satu set prosedur. Sumber program ditunjukkan pada Gambar 9.7, Gambar
9.8 dan Gambar 9.9 tersedia di situs web buku di www.cdk5.net/web.
Antarmuka layanan dan pelaksanaannya disusun seperti biasa. Sepasang alat
disebut wscompile dan wsdeploy dapat digunakan untuk menghasilkan kelas kerangka dan layanan
deskripsi (dalam WSDL, seperti yang dijelaskan dalam Bagian 9.3), menggunakan informasi mengenai
URL dari layanan, nama dan deskripsi diambil dari file konfigurasi ditulis
dalam XML. Nama layanan (dalam hal ini, MyShapeListService) digunakan untuk menghasilkan
nama kelas yang digunakan dalam program klien untuk mengaksesnya - yaitu,
MyShapeListService_Impl.

kontainer servlet • Pelaksanaan layanan dijalankan sebagai servlet dalam servlet
kontainer yang berperan untuk memuat, menginisialisasi dan menjalankan servlet. Servlet container
termasuk operator dan kerangka (lihat Bagian 5.4.2). Ketika permintaan tiba,
operator peta untuk kerangka tertentu, yang diterjemahkan ke dalam Java dan melewati di
meminta untuk metode yang tepat dalam servlet. Metode yang melakukan permintaan dan
menghasilkan balasan, yang kerangka diterjemahkan kembali ke dalam balasan SOAP. URL
Layanan terdiri dari gabungan dari URL dari kontainer servlet dan layanan
kategori dan nama, misalnya, http: // localhost: 8080 / ShapeList-jaxrpc / ShapeList.
Tomcat [jakarta.apache.org] adalah wadah servlet umum digunakan. ketika Tomcat
adalah menjalankan, antarmuka manajemen tersedia di URL untuk melihat dengan browser.
Interface ini menunjukkan nama servlet yang saat ini digunakan dan memberikan
operasi untuk mengelola mereka dan untuk mengakses informasi tentang masing-masing, termasuk
deskripsi layanan. Setelah servlet ditempatkan di Tomcat, klien dapat mengaksesnya dan
efek gabungan dari operasi mereka akan disimpan dalam variabel misalnya nya. dalam kami
Misalnya, daftar GraphicalObjects akan dibangun sebagai masing-masing ditambahkan sebagai hasil dari
permintaan klien untuk operasi newShape. Jika servlet dihentikan oleh Tomcat
antarmuka manajemen, maka nilai-nilai variabel instance-reset ketika
restart.
Tomcat juga menyediakan akses ke deskripsi dari masing-masing layanan yang
berisi, untuk memungkinkan programmer untuk merancang program klien dan untuk memfasilitasi
kompilasi otomatis dari proxy yang dibutuhkan oleh kode klien. Deskripsi layanan
terbaca-manusia karena dinyatakan dalam notasi XML (lebih khusus, di WSDL, sebagai
diperkenalkan dalam Bagian 9.3).
Perhatikan bahwa adalah mungkin untuk mengembangkan layanan web tanpa menggunakan kontainer servlet;
misalnya, Apache Axis menyembunyikan tingkat detail dari programmer.
Program klien • program klien dapat menggunakan proxy statis, proxy dinamis atau
antarmuka doa dinamis. Dalam semua kasus, deskripsi layanan yang relevan dapat digunakan
untuk memperoleh informasi yang diperlukan oleh kode klien. Dalam contoh kita, layanan
deskripsi dapat diperoleh dari Tomcat.
proxy statis: Gambar 9.9 menunjukkan klien ShapeList membuat panggilan melalui proxy - a
objek lokal yang melewati di pesan ke layanan jarak jauh. Kode untuk proxy adalah
dihasilkan oleh wscompile dari deskripsi layanan. Nama kelas untuk proxy adalah
dibentuk dengan menambahkan '_Impl' untuk nama layanan - dalam hal ini, kelas proxy
disebut MyShapeListService_Impl. Nama ini adalah implementasi khusus, karena
spesifikasi SOAP tidak memberikan aturan untuk penamaan kelas proxy.
Pada baris 1, metode createProxy disebut. Metode ini ditampilkan pada baris 5; line 6
menciptakan proxy, menggunakan MyShapeListService_Impl kelas, yang mengembalikan (catatan bahwa
proxy kadang-kadang disebut bertopik, maka nama kelas, Stub). Pada baris 2,
URL dari layanan ini disediakan untuk proxy melalui argumen yang diberikan pada baris perintah.
Pada baris 3, jenis proxy menyempit sesuai jenis antarmuka - ShapeList.
Baris 4 membuat panggilan ke getAllState prosedur remote, meminta layanan untuk mengembalikan
keberatan pada elemen 0 di vektor GraphicalObjects.
Karena proxy dibuat pada waktu kompilasi, hal itu disebut proxy statis. Layanan
deskripsi layanan dari yang dihasilkan akan belum tentu telah
dihasilkan dari antarmuka Jawa, tetapi mungkin telah dibuat oleh salah satu dari berbagai alat

9,9 implementasi Java dari klien ShapeList
Paket staticstub;
impor javax.xml.rpc.Stub;
public class ShapeListClient {
public static void main (String [] args) {/ * lulus URL dari layanan * /
try {
Rintisan Proxy = createProxy (); 1
proxy._setProperty 2
(Javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY, args [0]);
ShapeList aShapeList = (ShapeList) proksi; 3
GraphicalObject g = aShapeList.getAllState (0); 4
} Catch (Exception ex) {ex.printStackTrace (); }
private static Stub createProxy () {5
kembali
(Stub) (MyShapeListService_Impl baru () getShapeListPort ().); 6

terkait dengan berbagai sistem bahasa yang berbeda. Bahkan mungkin telah ditulis
langsung dalam XML.
proxy dinamis: Alih-alih menggunakan proxy statis dikompilasi, klien dapat menggunakan
proxy yang dinamis yang kelas dibuat pada saat runtime dari informasi dalam layanan
deskripsi dan antarmuka layanan. Metode ini menghindari kebutuhan untuk melibatkan
nama implementasi khusus untuk kelas proxy.
antarmuka doa dinamis: ini memungkinkan klien untuk memanggil prosedur remote,

bahkan jika
tanda tangan atau nama layanan ini tidak diketahui sampai runtime. Berbeda dengan di atas
alternatif, klien tidak memerlukan proxy. Sebaliknya, itu harus menggunakan serangkaian
operasi untuk mengatur nama operasi server, nilai kembali dan masing-masing
parameter sebelum membuat panggilan prosedur.
Pelaksanaan SOAP Java • Cara API Java diimplementasikan dapat dijelaskan
dengan mengacu pada Gambar 5.15. Paragraf berikut menjelaskan peran dari berbagai
komponen dalam lingkungan Java / SOAP - interaksi antara komponen
sama seperti sebelumnya. Tidak ada modul remote reference.
modul komunikasi: Tugas modul ini dilakukan oleh sepasang HTTP
modul. Modul HTTP di server memilih operator yang sesuai dengan URL
diberikan di header Aksi untuk permintaan POST.
Proxy klien: Sebuah proxy (atau rintisan) metode tahu URL dari layanan dan marsekal yang
sendiri nama metode dan argumen, bersama-sama dengan mengacu pada skema XML untuk
layanan, ke dalam amplop permintaan SOAP. Unmarshalling jawabannya terdiri dari
menganalisis amplop SOAP untuk mengekstrak hasil, mengembalikan nilai atau kesalahan laporan.
permintaan klien metode panggilan dikirim ke layanan sebagai permintaan HTTP.

Dispatcher dan kerangka: Seperti disebutkan di atas, operator dan kerangka hidup di
kontainer servlet. Dispatcher ekstrak nama operasi dari Aksi
tajuk dalam permintaan HTTP dan memanggil metode yang sesuai dalam yang tepat
kerangka, lewat amplop SOAP untuk itu. Sebuah metode kerangka melakukan berikut
tugas: itu menganalisis amplop SOAP di pesan permintaan dan ekstrak argumen,
memanggil metode yang sesuai dan merakit sebuah SOAP amplop balasan yang berisi
hasil.
Kesalahan, kesalahan dan kebenaran di SOAP / XML: Kesalahan dapat dilaporkan oleh HTTP
modul, operator, kerangka atau layanan itu sendiri. Layanan dapat melaporkan kesalahan yang
melalui nilai kembali atau dengan cara parameter kesalahan ditentukan dalam deskripsi layanan.
Kerangka bertanggung jawab untuk memeriksa bahwa amplop SOAP berisi permintaan dan
bahwa XML yang ada tertulis baik-terbentuk. Setelah menetapkan bahwa XML adalah
well-formed, kerangka akan menggunakan XML namespace di amplop untuk memeriksa bahwa
permintaan sesuai dengan layanan yang ditawarkan dan bahwa operasi dan argumen yang
sesuai. Jika pengecekan permintaan gagal di kedua level ini, maka kesalahan adalah
kembali ke klien. cek serupa yang dibuat oleh proxy ketika menerima SOAP
amplop berisi hasilnya.
9.2.4 Perbandingan layanan web dengan CORBA
Perbedaan utama antara layanan web dan CORBA atau middleware serupa lainnya adalah
penggunaan konteks yang dimaksud. CORBA dirancang untuk digunakan dalam satu organisasi
atau antara sejumlah kecil organisasi berkolaborasi. Hal ini mengakibatkan tertentu
aspek desain yang terlalu terpusat untuk digunakan kolaboratif oleh independen
organisasi atau untuk penggunaan ad hoc tanpa persiapan sebelumnya, seperti sekarang akan dijelaskan.
masalah penamaan • Dalam CORBA, setiap objek jauh direferensikan dengan cara nama yang
dikelola oleh sebuah instance dari Layanan CORBA Penamaan (lihat Bagian 8.3.5). Ini
layanan, seperti DNS, menyediakan pemetaan dari nama ke nilai yang akan digunakan sebagai
alamat (sebuah IOR di CORBA). Tapi tidak seperti DNS, Layanan CORBA Penamaan adalah
dirancang untuk digunakan dalam sebuah organisasi, bukan seluruh Internet.
Dalam CORBA Layanan Penamaan, setiap server mengelola grafik nama dengan
konteks penamaan awal dan awalnya independen dari server lain. Meskipun
organisasi yang terpisah mungkin federasi layanan penamaan mereka, ini tidak otomatis. Sebelum
server dapat federasi dengan yang lain, perlu tahu penamaan awal yang lain server
konteks. Dengan demikian, desain Layanan CORBA Penamaan efektif membatasi
berbagi CORBA objek untuk dalam set kecil organisasi yang memiliki federasi
layanan mereka penamaan.
masalah referensi • Kita sekarang mempertimbangkan apakah CORBA referensi objek remote,
yang disebut IOR (Bagian 8.3.3), dapat digunakan sebagai objek Internet-lebar
referensi dalam cara yang sama seperti URL. Setiap IOR berisi slot yang menentukan jenis
identifier dari interface dari objek itu referensi. Namun, jenis identifier ini
dipahami hanya dengan repositori antarmuka yang menyimpan definisi dari
jenis yang sesuai. Ini memiliki implikasi bahwa klien dan server harus menggunakan
antarmuka repositori yang sama, yang tidak benar-benar praktis pada skala global.

Sebaliknya, dalam model layanan web, layanan diidentifikasi dengan cara URL,
memungkinkan klien mana saja di Internet untuk membuat permintaan untuk layanan yang mungkin milik
untuk setiap organisasi di tempat lain. Artinya, layanan web dapat dibagi oleh klien
seluruh Internet. DNS adalah satu-satunya layanan yang diperlukan untuk akses URL, dan itu adalah
dirancang untuk bekerja secara efektif Internet-lebar.
Pemisahan aktivasi dan lokasi • Tugas mencari dan mengaktifkan layanan web
rapi dipisahkan. Sebaliknya, referensi gigih CORBA mengacu komponen
dari platform (pelaksanaan repositori) yang mengaktifkan objek yang sesuai
pada permintaan pada komputer yang sesuai dan juga bertanggung jawab untuk mencari objek sekali
telah diaktifkan.
Kemudahan penggunaan • The HTTP dan XML infrastruktur untuk layanan web dipahami dengan baik
dan nyaman untuk digunakan dan sudah diinstal pada semua yang paling umum digunakan
sistem operasi, meskipun pengguna tidak memerlukan bahasa pemrograman yang mudah
API untuk SOAP. Sebaliknya, platform CORBA adalah bagian besar dan kompleks perangkat lunak
memerlukan instalasi dan dukungan.
Efisiensi • CORBA telah dirancang untuk menjadi efisien: CORBA CDR (Bagian 4.3.1) adalah
biner, sedangkan XML adalah tekstual. Sebuah studi oleh Olson dan Ogbuji [2002] membandingkan
kinerja CORBA dengan yang SOAP dan XML-RPC. Mereka menemukan SOAP bahwa
pesan permintaan 14 kali lebih besar yang setara dalam CORBA dan bahwa
permintaan SOAP mengambil, rata-rata, 882 kali lebih lama sebagai doa CORBA setara.
Meskipun kinerja relatif tergantung pada bahasa yang digunakan dan juga
implementasi middleware tertentu yang digunakan, contoh ini tidak memberikan
indikasi overhead potensi pendekatan berbasis XML. Untuk banyak aplikasi,
Namun, overhead pesan dan kinerja lebih lambat dari SOAP tidak melihat, dan
efeknya dibuat kurang jelas dengan ketersediaan bandwidth murah, prosesor,
memori dan ruang disk.
W3C dan lain-lain telah menyelidiki kemungkinan memungkinkan biner
data yang akan dimasukkan dalam elemen XML, sehingga dapat meningkatkan efisiensi. Diskusi ini
topik dapat ditemukan di [www.w3.org XXI] dan [www.w3.org XXII]. Perhatikan bahwa XML tidak
sudah menyediakan untuk kedua heksadesimal dan base64 representasi data biner. Itu
representasi base64 digunakan bersama dengan enkripsi XML (lihat Bagian 9.5).
Ada cukup waktu dan ruang kepala ketika data biner dikonversi ke base64
atau heksadesimal, jadi apa yang benar-benar dibutuhkan adalah untuk dapat memasukkan representasi biner
dari urutan diparse item data seperti, misalnya, bahwa diproduksi oleh CORBA
CDR atau gzip. Pendekatan lain yang juga sedang diselidiki adalah untuk mengambil SOAP sebuah
pesan - bersama dengan lampiran, beberapa di antaranya mungkin biner - dan menggunakan multipart a
dokumen MIME untuk mengangkutnya.
Kekuatan dari CORBA • Ketersediaan layanan CORBA untuk transaksi,
kontrol konkurensi, keamanan dan kontrol akses, peristiwa dan objek terus-menerus membuatnya
pilihan yang diinginkan untuk digunakan dalam banyak aplikasi yang dimaksudkan untuk digunakan dalam suatu
organisasi atau kelompok yang terkait organisasi. Secara umum, itu adalah pilihan yang baik bagi mereka
aplikasi yang membutuhkan interaksi yang sangat kompleks. Selain itu, objek terdistribusi
Model merupakan salah satu yang menarik untuk desain aplikasi yang kompleks, dan itu sangat berharga
usaha ekstra belajar yang diperlukan untuk memahami detail dari hubungan antara
Model objek CORBA (Bagian 8.3) dan bahasa pemrograman tertentu digunakan.

9.3 deskripsi Layanan dan IDL untuk layanan web
Gambar 9.10 Unsur-unsur utama dalam deskripsi WSDL
beton abstrak
Bagaimana di mana
definisi
jenis
Target namespace
jasa binding pesan antarmuka
Dokumen-gaya request-reply-gaya
definisi antarmuka yang diperlukan untuk memungkinkan klien untuk berkomunikasi dengan layanan. untuk web
layanan, definisi antarmuka disediakan sebagai bagian dari deskripsi layanan yang lebih umum,
yang menetapkan dua karakteristik tambahan lainnya - bagaimana pesan yang akan
dikomunikasikan (misalnya, dengan SOAP melalui HTTP) dan URI layanan. untuk memenuhi
untuk digunakan dalam lingkungan multi-bahasa, deskripsi layanan yang ditulis dalam XML.
Sebuah deskripsi layanan membentuk dasar kesepakatan antara klien dan
Server untuk layanan yang ditawarkan. Ini merakit semua fakta mengenai layanan yang
relevan dengan klien. deskripsi layanan umumnya digunakan untuk menghasilkan bertopik klien
yang secara otomatis menerapkan perilaku yang benar untuk klien.
Komponen IDL-seperti dari deskripsi layanan lebih fleksibel daripada IDLs lainnya,
bahwa layanan dapat ditentukan baik dalam hal jenis pesan yang akan mengirim
dan menerima atau dalam hal operasi mendukung, untuk memungkinkan kedua dokumen
pertukaran dan request-reply-gaya interaksi.
Berbagai metode yang berbeda dari komunikasi dapat digunakan oleh layanan web dan
klien mereka. Oleh karena itu metode komunikasi yang tersisa akan diputuskan oleh layanan
penyedia dan ditentukan dalam deskripsi layanan, daripada dibangun ke dalam sistem, karena
dalam CORBA, misalnya.
Kemampuan untuk menentukan URI dari layanan sebagai bagian dari deskripsi layanan
menghindari kebutuhan untuk binder atau penamaan layanan terpisah yang digunakan oleh sebagian besar lainnya
middleware. Ini memiliki implikasi bahwa URI tidak dapat diubah setelah layanan
deskripsi telah dibuat tersedia untuk klien potensial, namun skema URN tidak memenuhi
untuk perubahan lokasi dengan memungkinkan untuk tipuan di tingkat referensi.
Sebaliknya, dalam pendekatan pengikat, klien menggunakan nama untuk mencari layanan
referensi pada saat runtime, yang memungkinkan referensi layanan untuk berubah seiring waktu. Pendekatan ini
membutuhkan tipuan dari nama untuk layanan referensi untuk semua layanan, meskipun
banyak dari mereka mungkin selalu tetap di lokasi yang sama.
Dalam konteks layanan web, Web Services Description Language (WSDL) adalah
biasa digunakan untuk deskripsi layanan. Versi saat ini, WSDL 2.0 [www.w3.org
XI], menjadi Rekomendasi W3C pada tahun 2007. Ini mendefinisikan skema XML untuk
mewakili komponen dari deskripsi layanan, yang meliputi, misalnya,
nama elemen definisi, jenis, pesan, antarmuka, binding dan jasa.
WSDL memisahkan bagian abstrak deskripsi layanan dari bagian beton,
seperti yang ditunjukkan pada Gambar 9.10.

Bagian abstrak deskripsi mencakup seperangkat definisi dari jenis yang digunakan
oleh layanan - khususnya, jenis nilai dipertukarkan dalam pesan. Java yang
Contoh dari Bagian 9.2.3, yang antarmuka Java ditunjukkan pada Gambar 9.7, menggunakan Java
jenis int dan GraphicalObject. Mantan (seperti jenis dasar) dapat diterjemahkan
langsung ke setara XML, tapi GraphicalObject didefinisikan di Jawa dalam hal
jenis int, String dan boolean. GraphicalObject direpresentasikan dalam XML, untuk penggunaan umum
oleh klien heterogen, sebagai complexType yang terdiri dari urutan bernama XML
jenis termasuk, misalnya:
<Nama elemen = "isFilled" type = "boolean" />
<Nama elemen = "originx" type = "int" />
Set nama didefinisikan dalam bagian jenis definisi WSDL disebut nya
Target namespace. Bagian pesan bagian abstrak berisi deskripsi dari
set pesan yang dipertukarkan. Untuk gaya dokumen interaksi, pesan-pesan ini akan
digunakan secara langsung. Untuk request-reply gaya interaksi, ada dua pesan untuk
setiap operasi, yang digunakan untuk menggambarkan operasi di bagian antarmuka. Itu
bagian beton menentukan bagaimana dan di mana layanan dapat dihubungi.
Modularitas yang melekat dari definisi WSDL memungkinkan komponen untuk menjadi
dikombinasikan dengan cara yang berbeda - misalnya, antarmuka yang sama dapat digunakan dengan
binding yang berbeda atau lokasi. Jenis dapat didefinisikan dalam elemen jenis atau
mereka dapat didefinisikan dalam dokumen terpisah direferensikan oleh URI dari elemen jenis.
Dalam kasus terakhir, definisi jenis dapat dirujuk dari beberapa WSDL yang berbeda
dokumen.
Pesan atau operasi • Pada layanan web, semua yang klien dan kebutuhan server untuk
memiliki ide umum tentang pesan yang akan ditukar. Untuk layanan berbasis pada
pertukaran sejumlah kecil dari berbagai jenis dokumen, WSDL hanya menggambarkan
jenis pesan yang berbeda untuk ditukar. Ketika klien mengirimkan salah satu dari ini
pesan ke layanan web, yang terakhir memutuskan operasi apa untuk melakukan dan apa jenis
pesan untuk mengirim kembali ke klien atas dasar jenis pesan yang diterima. dalam kami
Java misalnya, dua pesan akan didefinisikan untuk setiap operasi di antarmuka -
satu untuk permintaan dan satu untuk jawabannya. Sebagai contoh, Gambar 9.11 menunjukkan permintaan
dan membalas pesan untuk operasi newShape, yang memiliki argumen masukan tunggal
ketik GraphicalObject dan argumen satu output tipe int.
Untuk layanan yang mendukung beberapa operasi yang berbeda, itu lebih efektif untuk
menentukan pesan dipertukarkan sebagai permintaan untuk operasi dengan argumen dan mereka
sesuai balasan, memungkinkan layanan untuk mengirimkan setiap permintaan untuk yang sesuai operasi. Namun, dalam WSDL operasi adalah membangun untuk berhubungan permintaan dan balasan
pesan, berbeda dengan definisi operasi dalam antarmuka layanan.
Antarmuka • Pengumpulan operasi milik layanan web dikelompokkan
bersama-sama dalam sebuah antarmuka XML elemen bernama (kadang-kadang disebut portType). Setiap
operasi harus menentukan pola pertukaran pesan antara klien dan server. Itu
Pilihan yang tersedia termasuk yang ditunjukkan pada Gambar 9.12
Gambar pola pertukaran 9.12 Pesan untuk operasi WSDL
Nama Pesan yang dikirim oleh
Client Server pesan Pengiriman Sesar
In-Out Permintaan Balas Semoga menggantikan Balas
Di-Hanya Minta Tidak ada pesan kesalahan
Kuat dalam Hanya Permintaan Dijamin Bisa dikirim
Out-In Reply Permintaan Semoga menggantikan Balas
Out-Hanya Minta Tidak ada pesan kesalahan
Kuat Out-Hanya Permintaan Dijamin Bisa kirim kesalahan
. Yang pertama, In-Out, adalah
biasa digunakan formulir permintaan-balasan komunikasi client-server. Dalam pola ini,
membalas pesan dapat digantikan dengan pesan kesalahan. Di-Hanya adalah untuk pesan satu arah
dengan mungkin semantik dan Out-Only adalah untuk pesan oneway dari server ke klien; kesalahan
Pesan tidak dapat dikirim dengan baik. Kuat Di-Hanya dan kuat Out-Only adalah
sesuai pesan dengan pengiriman terjamin; kesalahan pesan dapat ditukar.
Out-In adalah interaksi permintaan-balasan diprakarsai oleh server. WSDL 2.0 juga extensible
dalam organisasi dapat memperkenalkan pola pertukaran pesan mereka sendiri jika
yang telah ditetapkan terbukti tidak memadai.
Kembali ke contoh Java kami, masing-masing dari operasi didefinisikan memiliki In-Out
pola. Operasi newShape ditunjukkan pada Gambar 9.13, menggunakan pesan didefinisikan dalam
Gambar 9.11
Gambar 9.13 WSDL operasi newShape
Nama operasi = "newShape"
pesan input = "TNS: ShapeList_newShape"
Pesan output = "TNS: ShapeList_newShapeResponse"
Pola = In-Out
TNS - Target namespace xsd - skema XML definisi
Nama-nama operasi, pola, input dan output didefinisikan dalam skema XML untuk WSDL
. definisi ini, bersama-sama dengan definisi dari empat operasi lain akan
diapit elemen XML antarmuka. Operasi juga dapat menentukan kesalahan

Jika, misalnya, operasi memiliki dua argumen - mengatakan, integer dan string -
tidak perlu untuk menentukan tipe data baru, karena jenis ini didefinisikan untuk XML
skema. Namun, akan diperlukan untuk menentukan pesan yang memiliki dua bagian ini. Ini
Pesan kemudian dapat digunakan sebagai input atau output dalam definisi untuk operasi.
Warisan: Setiap antarmuka WSDL dapat memperpanjang satu atau lebih interface WSDL lainnya. Ini
adalah bentuk sederhana dari warisan di mana sebuah antarmuka mendukung operasi dari setiap
interface itu meluas di samping mereka itu mendefinisikan dirinya. definisi rekursif
antarmuka tidak diperbolehkan; yaitu, jika antarmuka B meluas antarmuka A, maka antarmuka A
tidak bisa memperpanjang antarmuka B.
Beton bagian • Sisanya (beton) bagian dari dokumen WSDL terdiri dari
mengikat (pilihan protokol) dan layanan (pilihan endpoint atau server
alamat). Keduanya terkait, karena bentuk alamat tergantung pada jenis protokol
digunakan. Sebagai contoh, sebuah endpoint SOAP akan menggunakan URI sedangkan kehendak CORBA endpoint
menggunakan benda pengenal CORBA-spesifik.
Binding: Bagian yang mengikat dalam dokumen WSDL kata yang format pesan dan
bentuk representasi data eksternal yang akan digunakan. Misalnya, web layanan sering
menggunakan SOAP, HTTP dan MIME. Binding mungkin terkait dengan operasi tertentu atau
interface, atau mereka dapat dibiarkan bebas untuk digunakan oleh berbagai layanan web yang berbeda.
Gambar 9.14
Gambar 9.14 SOAP mengikat dan layanan definisi
Sabun: mengikat transportasi = URI
mengikat
style = "rpc"
endpoint
layanan
nama =
mengikat = "TNS: ShapeListBinding"
sabun: Alamat
Lokasi = layanan URI
name = "MyShapeListService"
name = "ShapeListPort"
untuk skema untuk sabun / http
Layanan URI adalah:
operasi
sabun: Operasi
SOAPAction
"ShapeListBinding"
ketik = "TNS: ShapeList"
name = "newShape"
masukan
sabun: tubuh
encoding, namespace
sabun: tubuh
encoding, namespace
keluaran
"Http: // localhost: 8080 / ShapeList-jaxrpc / ShapeList"
menunjukkan contoh dari melampirkan sabun mengikat: mengikat yang menspesifikasikan
URL protokol tertentu untuk transmisi amplop SOAP: HTTP mengikat
untuk SOAP. atribut opsional dari elemen ini juga dapat menentukan berikut:
• pola pertukaran pesan, yang mungkin baik rpc (request-reply) atau
pertukaran dokumen - nilai default adalah dokumen;

skema XML untuk format pesan - default adalah amplop SOAP;
• skema XML untuk representasi data eksternal - default adalah SOAP
encoding dari XML.
Gambar 9.14 juga menunjukkan rincian binding untuk salah satu operasi (newShape),
menetapkan bahwa baik input dan output pesan harus perjalanan dalam sabun: tubuh, menggunakan
gaya pengkodean tertentu, dan bahwa operasi harus ditransmisikan sebagai SOAPAction a.
Layanan: Setiap elemen layanan dalam dokumen WSDL menentukan nama layanan
dan satu atau lebih titik akhir (atau port) di mana sebuah contoh dari layanan dapat dihubungi.
Masing-masing elemen endpoint mengacu pada nama mengikat dalam penggunaan dan, dalam kasus ini
dari SOAP mengikat, menggunakan sabun: elemen alamat untuk menentukan URI layanan
lokasi.
Dokumentasi • Kedua informasi manusia- dan dapat dibaca oleh mesin dapat dimasukkan dalam
Unsur dokumentasi paling poin dalam dokumen WSDL. Informasi ini mungkin
dihapus sebelum WSDL digunakan untuk pemrosesan otomatis, misalnya, dengan stub
compiler.
Penggunaan WSDL • dokumen WSDL lengkap dapat diakses melalui URI mereka dengan klien dan
server, baik secara langsung atau tidak langsung melalui layanan direktori seperti UDDI. alat-alat yang
tersedia untuk menghasilkan definisi WSDL dari informasi yang diberikan melalui grafis a
antarmuka pengguna, menghilangkan kebutuhan bagi pengguna untuk terlibat dalam detail yang rumit dan
Struktur WSDL. Sebagai contoh, Web Services Description Language untuk Java
Toolkit (WSDL4J) memungkinkan penciptaan, representasi dan manipulasi WSDL
dokumen menggambarkan layanan [wsdl4j.sourceforge.org]. definisi WSDL juga bisa
dihasilkan dari definisi antarmuka yang ditulis dalam bahasa lain, seperti Java JAX-RPC,
dibahas dalam Bagian 9.2.1.
9.4 Sebuah layanan direktori untuk digunakan dengan layanan web
Ada banyak cara di mana klien dapat memperoleh deskripsi layanan. Sebagai contoh,
siapa pun yang menyediakan layanan web-tingkat yang lebih tinggi seperti layanan agen perjalanan dibahas di
Bagian 9.1 hampir pasti akan membuat sebuah halaman web iklan layanan dan
klien potensial akan menemukan halaman web ketika mencari jasa yang
mengetik.
Namun, setiap organisasi yang berencana untuk mendasarkan aplikasi pada layanan web akan
menemukan lebih nyaman menggunakan layanan direktori untuk membuat layanan ini tersedia untuk
klien. Ini adalah tujuan dari Universal Description, Discovery dan Integrasi
layanan (UDDI) [Bellwood et al. 2003], yang menyediakan layanan nama dan
layanan direktori (lihat Bagian 13.3). Artinya, deskripsi layanan WSDL dapat tampak
oleh nama (a halaman putih layanan) atau dengan atribut (layanan halaman kuning). Mereka mungkin
juga dapat diakses langsung melalui URL mereka, yang nyaman bagi para pengembang yang
merancang program klien yang menggunakan layanan ini.
Klien dapat menggunakan pendekatan halaman kuning untuk mencari kategori tertentu
layanan, seperti agen perjalanan atau penjual buku, atau mereka mungkin menggunakan halaman putih mendekati ke
mencari layanan dengan mengacu pada organisasi yang menyediakan itu.

struktur data • Struktur data pendukung UDDI dirancang untuk memungkinkan semua
gaya di atas akses dan dapat menggabungkan setiap jumlah informasi yang dapat dibaca manusia.
Data ini disusun dalam hal empat struktur yang ditunjukkan pada Gambar 9.15
TModel
melakukan usaha jasa
TModel
Gambar 9.15 utama struktur UDDI Data
entitas bisnis
informasi
tentang penerbit
TModel
melakukan usaha jasa terbaca-manusia
deskripsi layanan
kunci
URL
URL
URL
melakukan usaha jasa
informasi
tentang sebuah
keluarga layanan
terbaca-manusia
antarmuka layanan
bindingTemplate
bindingTemplate
bindingTemplate
informasi
tentang
kunci
antarmuka layanan
kunci
, Yang masing-masing
dapat diakses secara individual melalui sebuah identifier disebut kunci (terlepas dari TModel,
yang dapat diakses oleh URL):
businessEntity menggambarkan organisasi yang menyediakan layanan web ini, memberikan nya
Nama, alamat dan kegiatan, dll .;
melakukan usaha jasa menyimpan informasi tentang satu set contoh layanan web, seperti
nama dan deskripsi tujuan (misalnya, agen perjalanan atau penjual buku);
bindingTemplate memegang alamat layanan contoh web dan referensi untuk
deskripsi layanan;
TModel memegang deskripsi layanan, biasanya dokumen WSDL, disimpan di luar
database dan diakses dengan cara URL.
Lookup • UDDI menyediakan API untuk mencari layanan berdasarkan pada dua set permintaan
operasi:
• The get_xxx seperangkat operasi termasuk get_BusinessDetail, get_ServiceDetail,
get_bindingDetail dan get_tModelDetail; mereka mengambil suatu entitas sesuai dengan
kunci yang diberikan.
• The find_xxx seperangkat operasi termasuk find_business, find_service, find_binding
dan find_tModel; mereka mengambil set entitas yang cocok dengan set tertentu
kriteria pencarian, menyediakan ringkasan dari nama, deskripsi, kunci dan URL.
Sehingga klien dalam kepemilikan kunci tertentu mungkin menggunakan operasi get_xxx untuk mengambil
sesuai entitas langsung, dan klien lainnya dapat menggunakan penjelajahan untuk membantu pencarian,
dimulai dengan satu set besar hasil dan secara bertahap menyempit ke bawah. Misalnya, mereka
mungkin mulai dengan menggunakan operasi find_business untuk mendapatkan daftar yang berisi ringkasan.

informasi tentang penyedia yang cocok. Dari ringkasan ini, pengguna dapat menggunakan
Operasi find_service untuk mempersempit pencarian dengan cara mencocokkan jenis layanan yang diperlukan. Di
kedua kasus, mereka akan menemukan kunci dari Template mengikat sesuai dan dengan demikian menemukan
URL untuk mengambil dokumen WSDL untuk layanan yang sesuai.
Selain itu, UDDI menyediakan memberitahukan / berlangganan antarmuka dimana klien mendaftar
bunga dalam satu set tertentu dari entitas dalam registry UDDI dan mendapatkan pemberitahuan perubahan,
baik serentak atau asynchronous.
Publikasi • UDDI menyediakan sebuah antarmuka untuk penerbitan dan informasi memperbarui
tentang layanan web. Pertama kali struktur data (lihat Gambar 9.15) diterbitkan di
server UDDI, itu diberikan kunci dalam bentuk URI - misalnya, UDDI: cdk5.net: 213
- Dan server yang menjadi pemiliknya.
Registry • Layanan UDDI didasarkan pada data direplikasi disimpan di pendaftar. Sebuah UDDI
registry terdiri dari satu atau lebih server UDDI, masing-masing memiliki salinan dari set yang sama
data. Data tersebut direplikasi antara anggota registry. Masing-masing dari mereka mungkin
menanggapi pertanyaan dan mempublikasikan informasi. Perubahan struktur data harus
diserahkan kepada pemiliknya - yaitu, server di mana ia pertama kali diterbitkan. Hal ini dimungkinkan
untuk pemilik untuk lulus pada kepemilikan ke server UDDI lain di registri yang sama.
Skema replikasi: Para anggota registry menyebarkan salinan struktur data untuk satu
lain sebagai berikut: server yang telah membuat perubahan memberitahu server lain di
registry, yang kemudian meminta perubahan. Sebuah bentuk vektor timestamp digunakan untuk
menentukan perubahan harus disebarkan dan diterapkan. Skema sederhana
dibandingkan dengan skema replikasi lainnya yang menggunakan cap waktu vektor, seperti Gossip
(Bagian 18.4.1) atau Coda (Bagian 18.4.3) karena dua alasan:
1. Semua perubahan struktur data tertentu yang dibuat pada server yang sama.
2. Pembaruan dari server tertentu diterima berurutan oleh yang lain
anggota, tetapi tidak ada pemesanan tertentu dikenakan antara operasi update dibuat
oleh server yang berbeda.
Interaksi antara server: Seperti dijelaskan di atas, server berinteraksi dengan satu sama lain untuk
melaksanakan skema replikasi. Mereka juga dapat berinteraksi untuk mentransfer kepemilikan
struktur data. Namun, respon terhadap suatu operasi pencarian dilakukan oleh satu server
tanpa interaksi dengan server lain di registri, tidak seperti di direktori X.500
layanan (Bagian 13,5), di mana data dipartisi antara server yang bekerja sama dengan
satu lagi dalam mencari server yang relevan untuk permintaan tertentu.
keamanan 9.5 XML
keamanan XML terdiri dari satu set desain W3C terkait untuk penandatanganan, manajemen, dan
enkripsi. Hal ini dimaksudkan untuk digunakan dalam kerja koperasi melalui Internet yang melibatkan
dokumen yang isinya mungkin perlu dikonfirmasi atau dienkripsi. biasanya
dokumen yang dibuat, dipertukarkan, disimpan dan kemudian ditukar lagi, mungkin setelah
dimodifikasi oleh serangkaian pengguna yang berbeda.

WS-Security [Kaler 2002] adalah pendekatan lain untuk keamanan yang berkaitan dengan
menerapkan integritas pesan, kerahasiaan pesan dan otentikasi pesan tunggal
untuk SOAP.
Sebagai contoh konteks di mana keamanan XML akan berguna, mempertimbangkan
dokumen yang berisi catatan medis pasien. bagian yang berbeda dari dokumen ini
digunakan pada bedah dokter setempat dan di berbagai klinik khusus dan rumah sakit mengunjungi
oleh pasien. Ini akan diperbarui oleh dokter, perawat dan konsultan membuat catatan pada
pasien kondisi dan pengobatan, oleh administrator membuat janji dan oleh
apoteker menyediakan obat-obatan. bagian yang berbeda dari dokumen akan dapat dilihat oleh
peran yang berbeda yang disebutkan di atas, dan mungkin pasien juga. Adalah penting bahwa
bagian-bagian tertentu dari dokumen, misalnya, rekomendasi untuk pengobatan, dapat
dikaitkan dengan orang yang membuat mereka dan dapat dijamin tidak telah diubah.
kebutuhan ini tidak dapat dipenuhi oleh TLS (sebelumnya dikenal sebagai SSL dan dijelaskan dalam
Bagian 11.6.3), yang digunakan untuk membuat saluran aman untuk komunikasi
informasi. Hal ini memungkinkan proses di kedua ujung saluran untuk bernegosiasi mengenai
perlu untuk otentikasi atau enkripsi dan kunci dan algoritma yang akan digunakan, baik ketika
saluran diatur dan selama masa pakai baterai. Misalnya, data tentang transaksi keuangan
mungkin akan ditandatangani dan dikirim dalam jelas sampai informasi sensitif seperti kartu kredit
Rincian harus diberikan, di mana enkripsi titik akan diterapkan.
Untuk memungkinkan untuk jenis baru dari penggunaan diuraikan di atas, keamanan harus ditentukan
dalam dokumen itu sendiri dan diterapkan ke dokumen bukan sebagai milik
channel yang akan menyampaikan dari satu pengguna yang lain.
Hal ini dimungkinkan dalam XML atau format dokumen terstruktur lainnya, di mana metadata
dapat digunakan. tag XML dapat digunakan untuk menentukan sifat dari data dalam dokumen.
Secara khusus, keamanan XML tergantung pada tag baru yang dapat digunakan untuk menunjukkan
awal dan akhir bagian data dienkripsi atau ditandatangani dan tanda tangan. Setelah
keamanan yang diperlukan telah diterapkan dalam dokumen, itu dapat dikirim ke berbagai
pengguna yang berbeda, bahkan dengan cara multicast.
persyaratan dasar • keamanan XML harus menyediakan setidaknya tingkat perlindungan yang sama
sebagai TLS. Itu adalah:
Untuk dapat mengenkripsi baik seluruh dokumen atau hanya beberapa bagian yang dipilih dari itu: Untuk
Sebagai contoh, perhatikan informasi tentang transaksi keuangan, yang mencakup
nama orang, jenis transaksi dan rincian tentang kartu kredit atau kartu debit makhluk
bekas. Dalam satu kasus, hanya rincian kartu bisa disembunyikan, sehingga memungkinkan untuk mengidentifikasi
transaksi sebelum mendekripsi catatan. Dalam kasus lain, jenis transaksi
juga bisa menjadi tersembunyi, sehingga orang luar tidak bisa mengatakan apakah itu, misalnya, perintah
atau pembayaran.
Untuk dapat masuk baik seluruh dokumen atau hanya beberapa bagian yang dipilih dari itu: Ketika
dokumen dimaksudkan untuk digunakan untuk kerja koperasi oleh sekelompok orang, ada
dapat beberapa bagian penting dari dokumen yang harus ditandatangani untuk menjamin
bahwa mereka dibuat oleh orang tertentu atau bahwa mereka belum berubah. Tetapi
juga berguna untuk dapat memiliki bagian-bagian lain yang dapat diubah selama penggunaan
dokumen - ini tidak harus ditandatangani.

persyaratan dasar tambahan • persyaratan lebih lanjut timbul dari kebutuhan untuk menyimpan
dokumen, mungkin untuk mengubah mereka dan kemudian mengirimkannya ke berbagai berbeda
penerima:
Untuk menambahkan ke dokumen yang sudah ditandatangani dan untuk menandatangani hasilnya: Sebagai contoh, Alice
mungkin menandatangani dokumen dan menyebarkannya ke Bob, yang 'saksi tanda tangan' dengan menambahkan
pernyataan untuk efek yang kemudian menandatangani seluruh dokumen. (Bagian 11.1 memperkenalkan
nama-nama, termasuk Alice dan Bob, digunakan untuk protagonis dalam protokol keamanan.)
Untuk mengotorisasi pengguna yang berbeda untuk melihat bagian yang berbeda dari dokumen: Dalam kasus
rekam medis, seorang peneliti dapat melihat beberapa bagian tertentu dari data medis, sebuah
administrator dapat melihat rincian pribadi dan dokter dapat melihat keduanya.
Untuk menambahkan ke dokumen yang sudah berisi bagian dienkripsi dan untuk mengenkripsi bagian dari
versi baru, mungkin termasuk beberapa bagian sudah dienkripsi.
Fleksibilitas dan penataan kemampuan notasi XML memungkinkan melakukan semua
di atas, tanpa penambahan skema berasal dari persyaratan dasar.
Persyaratan mengenai algoritma • dokumen aman XML ditandatangani dan / atau dienkripsi
baik di muka pertimbangan apapun untuk siapa yang akan mengakses mereka. Jika
pencetus tidak lagi terlibat, tidak mungkin untuk bernegosiasi protokol dan apakah
untuk menggunakan otentikasi atau enkripsi. Karena itu:
Standar harus menentukan suite algoritma yang akan diberikan dalam pelaksanaan setiap
keamanan XML: Setidaknya satu enkripsi dan satu algoritma tanda tangan harus
wajib, untuk memungkinkan interoperabilitas seluas mungkin. algoritma opsional lainnya
harus disediakan untuk digunakan dalam kelompok-kelompok kecil.
Algoritma yang digunakan untuk enkripsi dan otentikasi dari dokumen tertentu harus
dipilih dari suite yang dan nama-nama algoritma yang digunakan harus dirujuk
dalam dokumen XML itu sendiri: Jika tempat di mana dokumen akan digunakan tidak bisa
diprediksi, maka salah satu protokol yang diperlukan harus digunakan.
keamanan XML mendefinisikan nama-nama unsur yang dapat digunakan untuk menentukan URI dari
algoritma yang digunakan untuk enkripsi atau penandatanganan. Sehingga dapat memilih berbagai
algoritma dalam dokumen XML yang sama, sebuah elemen yang menentukan sebuah algoritma
umumnya bersarang di dalam elemen yang berisi informasi ditandatangani atau data dienkripsi.
Persyaratan untuk menemukan kunci • Ketika dokumen dibuat dan setiap kali bahwa itu adalah
diperbarui, tombol yang sesuai harus dipilih, tanpa negosiasi dengan pihak-pihak
yang mungkin mengakses dokumen di masa depan. Hal ini menyebabkan persyaratan sebagai berikut:
Untuk membantu para pengguna dokumen aman dengan menemukan tombol yang diperlukan: Misalnya,
dokumen yang mencakup data ditandatangani harus berisi informasi mengenai kunci publik
yang akan digunakan untuk memvalidasi tanda tangan, seperti nama yang dapat digunakan untuk mendapatkan kunci,
atau sertifikat. Unsur KeyInfo dapat digunakan untuk tujuan ini.
Untuk memungkinkan bagi bekerja sama pengguna untuk membantu satu sama lain dengan kunci: Disediakan
bahwa elemen KeyInfo tidak cryptographically terikat pada tanda tangan itu sendiri,
Informasi dapat ditambahkan tanpa melanggar tanda tangan digital. Sebagai contoh,
kira Alice menandatangani dokumen dan mengirimkannya ke Bob dengan elemen KeyInfo yang
hanya menentukan nama kunci. Ketika Bob menerima dokumen dia menyelamatkan
informasi yang diperlukan untuk memvalidasi tanda tangan dan menambahkan ini ke elemen KeyInfo
ketika ia melewati dokumen untuk Carol.

keamanan elemen • XML menentukan elemen KeyInfo untuk menunjukkan kunci
yang akan digunakan untuk memvalidasi tanda tangan atau untuk mendekripsi beberapa data. Ini mungkin berisi, misalnya,
sertifikat, nama-nama kunci atau algoritma kesepakatan kunci. Penggunaannya opsional: yang
signer mungkin tidak ingin mengungkapkan informasi tombol apa saja untuk semua pihak yang mengakses
dokumen, dan dalam beberapa kasus aplikasi menggunakan keamanan XML mungkin sudah memiliki
akses ke tombol digunakan.
Canonical XML • Beberapa aplikasi dapat membuat perubahan yang tidak berpengaruh pada
isi informasi yang sebenarnya dari sebuah dokumen XML. Hal ini muncul karena ada varietas
cara yang berbeda mewakili apa yang logis dokumen XML yang sama. Untuk
Misalnya, atribut mungkin dalam urutan yang berbeda dan berbeda pengkodean karakter mungkin
digunakan, namun isi informasi adalah setara. Canonical XML [www.w3.org X] adalah
dirancang untuk digunakan dengan tanda tangan digital, yang digunakan untuk menjamin bahwa informasi
isi dokumen belum berubah. elemen XML dikanonikal sebelum
ditandatangani dan nama algoritma canonicalization disimpan, bersama-sama dengan
tanda tangan. Hal ini memungkinkan algoritma yang sama untuk digunakan saat tanda tangan divalidasi.
Bentuk kanonik adalah serialisasi standar XML sebagai aliran byte. ia menambahkan
atribut default dan menghapus skema berlebihan, menempatkan atribut dan skema
deklarasi dalam rangka leksikografi di setiap elemen. Ini menggunakan bentuk standar untuk baris
istirahat dan UTF-8 encoding untuk karakter. Setiap dua dokumen XML setara
memiliki bentuk kanonik yang sama.
Ketika bagian dari dokumen XML - mengatakan unsur - adalah dikanonikal, yang
bentuk kanonik meliputi konteks nenek moyang, yaitu, ruang nama dinyatakan dan
nilai-nilai dari atribut. Jadi ketika kanonik XML digunakan dalam hubungannya dengan digital
tanda tangan, tanda tangan dari unsur tidak akan lulus validasi jika unsur yang
ditempatkan dalam konteks yang berbeda.
Sebuah variasi dari algoritma ini, disebut Exclusive Canonical XML, menghilangkan konteks
dari serialisasi. Ini bisa digunakan jika aplikasi bermaksud tertentu ditandatangani,

9.6 Koordinasi layanan web
Infrastruktur SOAP mendukung interaksi permintaan-respon tunggal antara klien
dan layanan web. Namun, banyak aplikasi yang berguna melibatkan beberapa permintaan yang perlu
harus dilakukan dalam urutan tertentu. Sebagai contoh, ketika pemesanan penerbangan, harga dan
informasi ketersediaan dikumpulkan sebelum reservasi telah. Ketika pengguna
berinteraksi dengan halaman web dengan cara browser, misalnya, untuk memesan penerbangan atau untuk membuat
tawaran di lelang, antarmuka yang disediakan oleh browser (yang didasarkan pada
informasi yang diberikan oleh server) mengontrol urutan di mana operasi yang dilakukan.
Namun, jika itu adalah layanan web yang membuat pemesanan, seperti agen perjalanan
Layanan yang ditunjukkan pada Gambar 9.2, bahwa layanan web perlu bekerja dari deskripsi
cara yang tepat untuk melanjutkan saat berinteraksi dengan layanan lain yang digunakan untuk, misalnya, mobil
menyewa dan pemesanan hotel serta pemesanan penerbangan. Contoh ini menggambarkan kebutuhan untuk layanan web sebagai klien yang akan diberikan dengan
deskripsi protokol tertentu untuk mengikuti ketika berinteraksi dengan layanan web lainnya.
Tapi ada juga masalah menjaga konsistensi dalam data server ketika
menerima dan menanggapi permintaan dari beberapa klien. Bab 16 dan 17 mendiskusikan
transaksi, menggambarkan isu-isu dengan cara dari serangkaian transaksi perbankan.

Contoh sederhana, di transfer uang antara dua rekening bank, konsistensi membutuhkan
bahwa kedua deposit di satu account dan penarikan dari yang lain harus
dilakukan. Bab 17 menyajikan dua fase komit protokol yang digunakan oleh
bekerja sama server untuk memastikan konsistensi transaksi.
Dalam beberapa kasus, transaksi atom memenuhi persyaratan aplikasi menggunakan web
layanan. Namun, kegiatan seperti orang-orang dari agen perjalanan membutuhkan waktu lama untuk
menyelesaikan, dan akan tidak praktis untuk menggunakan dua fase komit protokol untuk membawa mereka
out karena melibatkan menjaga sumber daya terkunci untuk jangka waktu yang lama. Sebuah alternatif
adalah dengan menggunakan protokol lebih santai di mana setiap peserta membuat perubahan terus-menerus
negara yang terjadi. Dalam kasus kegagalan, protokol level aplikasi yang digunakan untuk membatalkan
tindakan ini.
Dalam middleware konvensional, infrastruktur menyediakan sederhana request-reply
protokol, meninggalkan layanan lainnya seperti transaksi, ketekunan dan keamanan menjadi
diimplementasikan sebagai layanan tingkat tinggi yang terpisah yang dapat digunakan ketika mereka dibutuhkan.
Hal yang sama berlaku untuk layanan web, di mana W3C dan lain-lain telah menempatkan dalam upaya
terhadap definisi layanan-tingkat yang lebih tinggi.
Pekerjaan yang telah dilakukan pada model umum untuk koordinasi layanan web, yang
mirip dengan model transaksi terdistribusi dijelaskan dalam Bagian 17.2 dalam hal ini memiliki
koordinator dan peserta peran yang mampu bertindak keluar protokol tertentu, untuk
Misalnya, untuk melaksanakan transaksi terdistribusi. Karya ini, yang disebut WSCoordination,
dijelaskan oleh Langworthy [2004]. Kelompok yang sama juga menunjukkan bagaimana
transaksi dapat dilakukan dalam model ini. Untuk studi komprehensif web
layanan koordinasi protokol, melihat Alonso et al. [2004].
Dalam sisa bagian ini, kami menguraikan ide di balik layanan web
koreografi. Mempertimbangkan fakta bahwa itu akan mungkin untuk menggambarkan semua kemungkinan
jalur alternatif yang valid melalui serangkaian interaksi antara pasangan layanan web
bekerja sama dalam tugas bersama seperti skenario agen perjalanan. Jika seperti deskripsi
yang tersedia, dapat digunakan sebagai bantuan untuk koordinasi tugas bersama. Bisa juga
digunakan sebagai spesifikasi yang harus diikuti oleh kasus baru dari layanan, seperti baru
pemesanan layanan penerbangan yang ingin bergabung kolaborasi.
W3C menggunakan koreografi istilah untuk merujuk ke bahasa berdasarkan WSDL untuk
mendefinisikan koordinasi. Misalnya, bahasa mungkin menentukan kendala pada urutan
dan kondisi di mana pesan yang dipertukarkan oleh peserta. Sebuah koreografi adalah
dimaksudkan untuk memberikan gambaran global seperangkat interaksi, menunjukkan perilaku
dari masing-masing anggota satu set peserta, dengan tujuan untuk meningkatkan interoperabilitas.
Persyaratan untuk koreografi • Koreografi ini dimaksudkan untuk mendukung interaksi
antara layanan web yang umumnya dikelola oleh perusahaan dan berbeda
organisasi. Sebuah kolaborasi yang melibatkan layanan web beberapa dan klien harus
dijelaskan dalam hal set interaksi diamati antara pasangan mereka. Misalnya
deskripsi mungkin dilihat sebagai kontrak antara peserta, dan dapat digunakan untuk
tujuan-tujuan berikut:
• untuk menghasilkan kode menguraikan untuk layanan baru yang ingin berpartisipasi;
• sebagai dasar untuk menghasilkan pesan tes untuk layanan baru;
• untuk mempromosikan pemahaman umum dari kerjasama;
• menganalisis kolaborasi, misalnya untuk mengidentifikasi situasi kebuntuan mungkin.

Penggunaan deskripsi koreografi umum oleh satu set berkolaborasi layanan web
harus menghasilkan layanan yang lebih kuat dengan interoperabilitas yang lebih baik. Selain itu, mestinya
akan lebih mudah untuk mengembangkan dan memperkenalkan layanan baru, membuat layanan secara keseluruhan lebih
berguna.
Draft dokumen W3C kerja [www.w3.org XV] menunjukkan bahwa
bahasa koreografi harus mencakup fitur berikut:
• Komposisi hirarkis dan rekursif dari koreografi;
• kemampuan untuk menambahkan kasus baru dari layanan yang ada dan layanan baru;
• jalur bersamaan, jalur alternatif dan kemampuan untuk mengulangi bagian dari
koreografi;
• variabel timeout - misalnya, periode yang berbeda untuk memegang pemesanan;
• pengecualian, misalnya, untuk menangani pesan tiba keluar dari urutan dan user
tindakan seperti pembatalan;
• interaksi asynchronous (callback);
• referensi lewat, misalnya, untuk memungkinkan sebuah perusahaan menyewa mobil untuk berkonsultasi bank untuk
pemeriksaan kredit atas nama pengguna;
• penandaan batas-batas transaksi yang terpisah yang terjadi, untuk
Misalnya, untuk memungkinkan pemulihan;
• kemampuan untuk menyertakan dokumentasi yang dapat dibaca manusia.
Sebuah model yang didasarkan pada persyaratan tersebut dijelaskan dalam lain W3C rancangan kerja
Dokumen [www.w3.org XVI].
Bahasa untuk koreografi • Tujuannya adalah untuk menghasilkan deklaratif, XML berbasis
bahasa untuk mendefinisikan koreografi yang dapat menggunakan definisi WSDL. W3C
telah membuat rekomendasi untuk Layanan Web Koreografi Definition Language
Versi 1 [www.w3.org XVII]. Sebelum ini, kelompok perusahaan diserahkan kepada
W3C spesifikasi untuk layanan web koreografi antarmuka [www.w3.org XVIII].
9.7 Aplikasi layanan web
layanan web sekarang salah satu paradigma dominan untuk pemrograman terdistribusi
sistem. Pada bagian ini, kita membahas sejumlah bidang utama di mana layanan web memiliki
telah digunakan secara luas: dalam mendukung arsitektur berorientasi layanan, Grid dan
belakangan, komputasi awan.
9.7.1 Arsitektur berorientasi layanan
Arsitektur berorientasi layanan (SOA) adalah seperangkat prinsip-prinsip desain dimana didistribusikan
sistem yang dikembangkan menggunakan set layanan longgar ditambah yang bisa dinamis
ditemukan dan kemudian berkomunikasi dengan satu sama lain atau dikoordinasikan melalui
koreografi untuk menyediakan layanan ditingkatkan. arsitektur berorientasi layanan adalah abstrak konsep yang dapat diimplementasikan dengan menggunakan berbagai teknologi termasuk
objek terdistribusi atau pendekatan berbasis komponen dibahas dalam Bab 8. Kepala sekolah
sarana untuk mewujudkan arsitektur berorientasi layanan, bagaimanapun, adalah melalui penggunaan web
layanan, sebagian besar disebabkan oleh kopling longgar melekat dalam pendekatan ini (seperti yang dibahas di
Bagian 9.2).
Gaya arsitektur dapat digunakan dalam bisnis atau organisasi untuk menawarkan
arsitektur perangkat lunak yang fleksibel dan untuk mencapai interoperabilitas antara berbagai
layanan. Perdana digunakan, namun di Internet yang lebih luas, menawarkan pemandangan umum
jasa membuat mereka secara global dapat diakses dan setuju untuk komposisi berikutnya.
Hal ini memungkinkan untuk melampaui tingkat heterogenitas yang melekat di Internet
dan juga untuk menangani masalah organisasi yang berbeda mengadopsi berbeda
produk middleware internal - adalah mungkin bagi satu organisasi untuk menggunakan CORBA
internal dan satu lagi menggunakan NET namun keduanya kemudian untuk mengekspos antarmuka menggunakan layanan web,
dengan demikian mendorong interoperabilitas global. Properti yang dihasilkan dikenal sebagai businessto-
bisnis (B2B) integrasi. Kami sudah melihat salah satu contoh dari kebutuhan untuk B2B
integrasi pada Gambar 9.18 (skenario agen perjalanan), di mana agen perjalanan dapat menangani
dengan berbagai perusahaan yang menawarkan penyewaan mobil penerbangan, dan akomodasi hotel.
Arsitektur berorientasi layanan juga memungkinkan dan mendorong pendekatan mashup untuk
pengembangan perangkat lunak. A mashup adalah layanan baru yang diciptakan oleh pengembang pihak ketiga oleh
menggabungkan dua atau lebih layanan yang tersedia di lingkungan terdistribusi. mashup yang
budaya bergantung pada tersedianya layanan berguna dengan antarmuka yang terdefinisi
ditambah dengan komunitas inovasi terbuka di mana individu atau kelompok terlibat dalam
pengembangan layanan gabungan eksperimental dan membuat mereka tersedia untuk orang lain untuk
pengembangan lebih lanjut. Kedua kondisi sekarang dipenuhi oleh Internet, terutama dengan
Munculnya komputasi awan dan perangkat lunak sebagai layanan (seperti yang diperkenalkan dalam Bagian
7.7.1), di mana pengembang perangkat lunak besar seperti Amazon, Flickr dan eBay membuat
layanan yang tersedia melalui antarmuka dipublikasikan ke pengembang lain. Sebagai contoh, lihat
untuk JBidwatcher [www.jbidwatcher.org], Mashup berbasis Java yang interface ke eBay untuk
mengelola tawaran secara proaktif atas nama klien, misalnya pelacakan lelang dan penawaran
pada menit terakhir untuk memaksimalkan peluang keberhasilan.
9.7.2 The Grid
Nama 'Grid' digunakan untuk merujuk kepada middleware yang dirancang untuk memungkinkan berbagi
sumber daya seperti file, komputer, software, data dan sensor pada skala yang sangat besar. Itu
sumber daya yang dibagi biasanya oleh kelompok pengguna di organisasi yang berbeda yang
berkolaborasi pada solusi dari masalah yang membutuhkan sejumlah besar komputer untuk memecahkan
mereka, baik dengan berbagi data atau berbagi daya komputasi. Ini
sumber daya tentu didukung oleh perangkat keras komputer yang heterogen, operasi
sistem, bahasa pemrograman dan aplikasi. Manajemen diperlukan untuk mengkoordinasikan
penggunaan sumber daya untuk memastikan bahwa klien mendapatkan apa yang mereka butuhkan dan bahwa layanan mampu
untuk memasok. Dalam beberapa kasus, teknik keamanan canggih yang diperlukan untuk memastikan bahwa
penggunaan yang benar terbuat dari sumber daya dalam jenis lingkungan. Untuk contoh dari
Aplikasi Grid, lihat kotak pada halaman 415, yang menampilkan World Wide
Aplikasi teleskop dikembangkan di Microsoft Research.

Sebuah aplikasi Grid
Proyek ini berkaitan dengan mengerahkan sumber daya data bersama dengan
komunitas astronomi. Hal ini dijelaskan dalam karya Szalay dan Gray [2004], Szalay
dan Gray [2001] dan Gray dan Szalay [2002]. Astronomi data terdiri dari arsip
pengamatan, yang masing-masing mencakup periode waktu tertentu, bagian dari
spektrum elektromagnetik (optik, x-ray, radio) dan area tertentu dari langit.
Pengamatan ini dibuat oleh instrumen yang berbeda dikerahkan di berbagai tempat
di seluruh dunia.
Sebuah studi tentang bagaimana para astronom berbagi data berguna untuk menurunkan para
karakteristik aplikasi Grid khas, karena para astronom bebas berbagi mereka
hasil dengan satu sama lain dan masalah keamanan dapat dihilangkan, membuat diskusi ini
sederhana.
Para astronom membuat studi yang perlu menggabungkan data dari langit yang sama
benda tetapi melibatkan beberapa periode waktu yang berbeda dan beberapa bagian dari
spektrum. Kemampuan untuk menggunakan pengamatan independen data penting untuk
penelitian. Visualisasi memungkinkan para astronom untuk melihat data sebagai 2D atau plot pencar 3D.
Tim mengumpulkan data store dalam arsip besar (saat terabyte),
yang dikelola secara lokal oleh masing-masing tim yang mengumpulkan data. Instrumen yang digunakan dalam
pengumpulan data tunduk pada hukum Moore, sehingga jumlah data yang dikumpulkan tumbuh
eksponensial. Seperti yang dikumpulkan, data dianalisis dengan proses pipa dan disimpan
sebagai berasal data untuk digunakan oleh para astronom di seluruh dunia. Tapi sebelum data dapat
digunakan oleh peneliti lain, para ilmuwan yang bekerja dalam bidang tertentu perlu menyepakati
cara yang umum label data mereka.
Szalay dan Gray [2004] menunjukkan bahwa di masa lalu, data penelitian ilmiah adalah
disertakan oleh penulis dalam artikel dan diterbitkan dalam jurnal yang hidup di perpustakaan. Tapi
saat ini, jumlah data terlalu besar untuk dimasukkan dalam publikasi. Ini
berlaku tidak hanya untuk astronomi, tetapi juga untuk bidang fisika partikel dan genom
dan penelitian biologi. Peran penulis sekarang milik kolaborasi, yang
mengambil 5-10 tahun untuk membangun percobaan mereka sebelum memproduksi data yang diterbitkan
ke dunia dalam arsip berbasis web. Dengan demikian, para ilmuwan yang bekerja pada proyek-proyek
menjadi penerbit data dan pustakawan serta penulis.
Peran tambahan ini membutuhkan setiap proyek yang mengelola arsip data untuk membuatnya
diakses peneliti lain. Ini berarti overhead yang cukup di samping
tugas asli dari analisis data. Untuk melakukan sharing seperti mungkin, data mentah
membutuhkan metadata untuk menggambarkan, misalnya, saat itu dikumpulkan, bagian dari
langit dan instrumen yang digunakan. Selain itu, data yang diperoleh harus disertai
oleh metadata yang menjelaskan parameter dari pipa melalui mana itu
diproses.
Perhitungan data yang berasal memerlukan dukungan komputasi berat. sering
telah dihitung ulang sebagai teknik meningkatkan. Semua ini adalah biaya yang cukup untuk
proyek yang memiliki data.
Tujuan dari Telescope World Wide adalah untuk menyatukan astronomi dunia
arsip ke dalam database raksasa yang berisi literatur astronomi, gambar, data mentah,
dataset berasal dan data simulasi.

Persyaratan aplikasi Grid • The World-Wide Telescope khas dari berbagai
aplikasi Grid data-intensif, dimana:
• Data dikumpulkan melalui instrumen ilmiah;
• data disimpan dalam arsip di lokasi terpisah yang lokasi dapat di berbeda
tempat di seluruh dunia;
• Data yang dikelola oleh tim ilmuwan milik organisasi yang terpisah;
• kuantitas besar dan meningkatkan (terabyte atau petabyte) data mentah
yang dihasilkan dari instrumen;
• program komputer yang digunakan untuk menganalisis dan membuat ringkasan dari data mentah, untuk
Misalnya, untuk mengklasifikasikan, mengkalibrasi dan katalog data mentah yang mewakili langit
benda.
Internet membuat semua ini arsip data yang berpotensi tersedia untuk para ilmuwan
di seluruh dunia, memungkinkan mereka untuk mendapatkan data dari instrumen yang berbeda berkumpul di
waktu yang berbeda dan di lokasi yang berbeda. Namun, seorang ilmuwan tertentu menggunakan data ini untuk
penelitian mereka sendiri akan tertarik hanya dalam subset dari objek dalam arsip.
Jumlah besar data dalam arsip membuatnya tidak layak untuk mentransfer ke
lokasi pengguna sebelum memprosesnya untuk mengekstrak obyek yang menarik, karena
pertimbangan seperti waktu transmisi dan ruang disk lokal diperlukan. Oleh karena itu,
tidak tepat untuk menggunakan FTP atau akses web dalam konteks ini. Pengolahan baku
Data harus dilakukan di lokasi di mana dikumpulkan dan disimpan dalam database. Kemudian
ketika seorang ilmuwan membuat pertanyaan tentang obyek tertentu, informasi dalam setiap database
harus dianalisis dan jika perlu, visualisasi diproduksi sebelum kembali hasil
dengan permintaan terpencil.
Kenyataan bahwa data diproses di banyak situs yang berbeda memberikan inbuilt
paralelisme yang secara efektif membagi tugas besar yang dilakukan.
Dari karakteristik di atas, persyaratan berikut diturunkan:
R1: Remote akses ke sumber daya - yaitu, dengan informasi yang diperlukan dalam arsip.
R2: Pengolahan data di situs mana disimpan dan dikelola, baik ketika
berkumpul atau dalam menanggapi permintaan. Sebuah query khas mungkin mengakibatkan
visualisasi berdasarkan data yang dikumpulkan selama satu wilayah langit yang dicatat oleh berbagai
instrumen pada waktu yang berbeda. Ini akan melibatkan memilih sejumlah kecil data
dari masing-masing arsip data besar.
R3: Manajer sumber daya dari arsip data harus mampu membuat contoh layanan
dinamis untuk berurusan dengan bagian tertentu dari data yang dibutuhkan, seperti dalam
didistribusikan model objek, di mana pegawai diciptakan setiap kali mereka dibutuhkan
untuk menangani sumber daya yang berbeda dikelola oleh layanan.
R4: Metadata untuk menggambarkan:
- Karakteristik data dalam arsip - misalnya, untuk astronomi, daerah
dari langit, tanggal dan waktu dikumpulkan dan instrumen yang digunakan;
- Karakteristik layanan pengelolaan data yang - misalnya, biaya, yang
lokasi geografis, penerbit atau beban atau ruang yang tersedia.

Direktori layanan berdasarkan metadata atas: R5.
R6: Software untuk mengelola permintaan, transfer data dan muka pemesanan sumber daya,
memperhitungkan bahwa sumber daya umumnya dikelola oleh proyek-proyek yang
menghasilkan data dan akses kepada mereka mungkin perlu dijatah.
layanan web dapat menangani dua persyaratan pertama dengan menyediakan cara yang nyaman
bagi para ilmuwan untuk mengakses operasi pada data di arsip terpencil. Ini akan mengharuskan setiap
aplikasi tertentu memberikan gambaran layanan yang mencakup seperangkat metode untuk
mengakses data. Grid middleware harus berurusan dengan persyaratan yang tersisa.
Grid juga digunakan untuk aplikasi Grid komputasi intensif seperti
memproses sejumlah besar data yang dihasilkan oleh CMS energi tinggi akselerator partikel
di CERN [www.uscms.org], menguji efek dari molekul obat kandidat
[Taufer et al. 2003, Chien 2004] atau mendukung game massively multiplayer online menggunakan
kapasitas cadangan di komputer klaster [www.butterfly.net]. Di mana komputasi-intensif
aplikasi yang digunakan pada Grid, manajemen sumber daya akan peduli
dengan mengalokasikan sumber daya komputasi dan menyeimbangkan beban.
Akhirnya, keamanan akan dibutuhkan untuk banyak aplikasi Grid. Misalnya, Grid
sedang digunakan untuk penelitian medis dan untuk aplikasi bisnis. Bahkan ketika privasi
Data tidak masalah, itu akan menjadi penting untuk menentukan identitas orang-orang yang
menciptakan data.
Grid middleware • The Open Grid Services Architecture (OGSA) adalah standar untuk
grid berbasis aplikasi [Foster et al. 2001, 2002]. Ini menyediakan kerangka kerja
yang persyaratan di atas dapat dipenuhi, berdasarkan layanan web. sumber daya
dikelola oleh layanan Grid aplikasi-spesifik. Globus Toolkit kemudian mengimplementasikan
arsitektur.
Globus Proyek dimulai pada tahun 1994 dengan tujuan untuk menyediakan perangkat lunak yang
mengintegrasikan dan standarisasi fungsi yang diperlukan oleh keluarga dari aplikasi ilmiah.
Fungsi-fungsi ini termasuk layanan direktori, keamanan dan manajemen sumber daya. Pertama
Globus toolkit muncul pada tahun 1997. OGSA berevolusi dari versi kedua dari
toolkit (disebut GT2), yang digambarkan dalam Foster dan Kesselman [2004]. Ketiga
Versi (GT3), yang muncul pada tahun 2002, didasarkan pada OGSA dan karena itu dibangun di web
layanan. Ini dikembangkan oleh Globus Alliance (www.globus.org) dan dijelaskan dalam
Sandholm dan Gawor [2003]. Sejak itu, dua versi lanjut telah dirilis - yang
Versi terbaru ini disebut sebagai GT5 dan tersedia sebagai perangkat lunak open source
[Www.globus.org]).
Sebuah studi kasus OGSA dan toolkit Globus (hingga GT3) dapat ditemukan pada
pendamping situs web [www.cdk5.net/web].
9.7.3 Cloud computing
Cloud computing diperkenalkan dalam Bab 1 sebagai satu set aplikasi berbasis Internet,
penyimpanan dan komputasi layanan yang cukup untuk mendukung kebutuhan sebagian besar pengguna ', sehingga memungkinkan
mereka untuk sebagian besar atau bahkan mengeluarkan penyimpanan data lokal dan aplikasi perangkat lunak.
Cloud computing juga mempromosikan pandangan dari segala sesuatu sebagai sebuah layanan, dari fisik atau
infrastruktur virtual melalui software, sering dibayar pada basis per-penggunaan daripada
dibeli. Konsep ini secara hakekatnya terkait dengan model bisnis baru bagi

komputasi di mana pemasok awan menawarkan berbagai komputasi, data dan layanan lainnya
kepada pelanggan seperti yang diperlukan untuk penggunaan sehari-hari mereka, misalnya menawarkan penyimpanan yang cukup
kapasitas di Internet untuk bertindak sebagai layanan arsip atau cadangan.
Bab 1 juga komentar dari tumpang tindih antara komputasi awan dan Grid.
Perkembangan Grid yang didahului munculnya komputasi awan dan merupakan
faktor yang signifikan dalam kemunculannya. Mereka berbagi tujuan yang sama memberikan sumber
(Layanan) di luar sana di Internet yang lebih besar. Sedangkan Grid cenderung fokus pada high-end
Data-berat atau komputasi aplikasi mahal, perhitungan awan lebih
umum, menawarkan berbagai layanan untuk pengguna komputer individu hingga high-end
pengguna. Model bisnis yang terkait dengan komputasi awan juga membedakan suatu
ciri. Oleh karena itu adil untuk mengatakan bahwa Grid adalah sebuah contoh awal dari awan
komputasi, tetapi komputasi awan telah berkembang secara signifikan sejak saat itu.
Dengan pandangan dari segala sesuatu sebagai sebuah layanan, layanan web menawarkan alam
pelaksanaan jalan untuk komputasi awan, dan memang banyak vendor turun jalan ini.
Korban paling terkenal di ruang ini adalah Amazon Web Services (AWS)
[Aws.amazon.com], dan kami melihat secara singkat teknologi bawah ini. Kami akan melihat
Pendekatan alternatif untuk komputasi awan dalam Bab 21, ketika kita melihat Google
infrastruktur dan terkait Google App Engine, yang mana kedua fitur lighterweight sebuah,
Pendekatan-kinerja lebih tinggi dari layanan web.
Amazon Web Services adalah seperangkat layanan cloud diimplementasikan pada luas
infrastruktur fisik yang dimiliki oleh Amazon.com. Awalnya dikembangkan untuk intern
tujuan dalam mendukung bisnis ritel elektronik mereka, Amazon sekarang menawarkan banyak
fasilitas untuk pengguna eksternal, yang memungkinkan mereka untuk menjalankan layanan independen pada
infrastruktur. Pelaksanaan AWS mengurus kunci didistribusikan masalah sistem
seperti ketersediaan mengelola layanan, skalabilitas dan kinerja, memungkinkan pengembang
untuk fokus pada penggunaan layanan mereka. Layanan yang dibuat tersedia menggunakan layanan web
standar dijelaskan sebelumnya dalam bab ini. Ini memiliki keuntungan bahwa programmer
akrab dengan layanan web dapat dengan mudah menggunakan AWS dan dapat mengembangkan mashup yang
menggabungkan Amazon Web Services dalam konstruksi mereka. Lebih umum, pendekatan
memungkinkan interoperabilitas di Internet. Amazon juga mengadopsi pendekatan REST, sebagai
dianjurkan oleh Fielding [2000] dan dibahas dalam Bagian 9.2.
Amazon menawarkan serangkaian luas dan extensible layanan, yang paling signifikan yang
tercantum pada Gambar 9.19. Kami memiliki EC2 lebih terinci. EC2 adalah menghitung elastis
layanan, di mana istilah 'elastis' mengacu pada kemampuan untuk menawarkan kapasitas komputasi yang
resizeable dengan kebutuhan pelanggan. Daripada mesin yang sebenarnya, EC2 menawarkan pengguna
mesin virtual, yang disebut sebuah contoh, dengan spesifikasi yang diinginkan. Misalnya, pengguna
dapat meminta contoh dari jenis berikut:
• contoh standar yang dirancang untuk cocok untuk sebagian besar aplikasi;
• contoh-memori tinggi yang menawarkan kapasitas memori tambahan, misalnya untuk
aplikasi yang melibatkan caching;
• contoh CPU tinggi yang dirancang untuk mendukung tugas-tugas komputasi secara intensif;
• contoh klaster menghitung menawarkan cluster prosesor virtual dengan highbandwidth
interkoneksi untuk tugas-tugas komputasi kinerja tinggi.

Beberapa ini dapat lebih disempurnakan - misalnya, untuk contoh standar itu
mungkin untuk meminta contoh kecil, menengah atau besar yang mewakili berbagai
spesifikasi dalam hal kekuatan pemrosesan, memori, penyimpanan disk dan sebagainya.
EC2 dibangun di atas hypervisor Xen, dijelaskan dalam Bagian 7.7.2. Itu
contoh dapat dikonfigurasi untuk menjalankan berbagai sistem operasi termasuk Windows
Server 2008, Linux atau OpenSolaris. Mereka juga dapat dikonfigurasi dengan berbagai
perangkat lunak. Sebagai contoh, adalah mungkin untuk meminta instalasi Apache HTTP untuk
dukungan web hosting.
EC2 mendukung konsep menarik dari alamat IP elastis, yang terlihat seperti
Alamat IP tradisional tetapi dikaitkan dengan akun pengguna, bukan contoh tertentu.
Ini berarti bahwa jika (virtual) mesin gagal, alamat IP dapat diberikan ke sebuah
mesin yang berbeda tanpa memerlukan intervensi dari administrator jaringan.
9.8 Ringkasan
Dalam bab ini kami telah menunjukkan bahwa layanan web telah timbul dari kebutuhan untuk memberikan
infrastruktur untuk mendukung interworking antara organisasi yang berbeda. infrastruktur ini
umumnya menggunakan protokol HTTP banyak digunakan untuk mengangkut pesan antara klien
dan server melalui Internet dan didasarkan pada penggunaan URI untuk merujuk ke sumber daya.
XML, format tekstual, digunakan untuk representasi data dan marshalling.
Dua pengaruh terpisah menyebabkan munculnya layanan web. Salah satunya adalah
penambahan layanan interface untuk server web dengan maksud untuk memungkinkan sumber
di situs yang akan diakses oleh program client selain browser dan menggunakan bentuk yang lebih kaya.

interaksi. Yang lainnya adalah keinginan untuk memberikan sesuatu seperti RPC melalui Internet,
berdasarkan protokol yang ada. layanan web yang dihasilkan menyediakan antarmuka dengan set
operasi yang bisa disebut jarak jauh. Seperti bentuk lain dari layanan, layanan web
dapat menjadi klien dari layanan web lain, sehingga memungkinkan layanan web untuk mengintegrasikan atau
menggabungkan satu set layanan web lainnya.
SOAP adalah protokol komunikasi yang umumnya digunakan oleh layanan web dan
klien mereka. Hal ini dapat digunakan untuk mengirimkan pesan permintaan dan balasan mereka antara klien
dan server, baik dengan pertukaran asynchronous dokumen atau dengan bentuk permintaan balasan
protokol berdasarkan sepasang pertukaran pesan asynchronous. Dalam kedua kasus,
permintaan atau pesan balasan tertutup dalam dokumen berformat XML yang disebut
amplop. Amplop SOAP umumnya ditularkan melalui HTTP sinkron
protokol, meskipun angkutan lainnya dapat digunakan.
XML dan SOAP prosesor yang tersedia untuk semua program secara luas digunakan
bahasa dan sistem operasi. Hal ini memungkinkan layanan web dan klien mereka untuk menjadi
dikerahkan hampir di mana saja. Bentuk interworking diaktifkan oleh fakta bahwa web
jasa tidak terikat dengan bahasa pemrograman tertentu dan tidak mendukung
didistribusikan model objek.
Dalam layanan middleware konvensional, definisi antarmuka menyediakan klien dengan
rincian layanan. Namun, dalam hal layanan web, deskripsi layanan yang digunakan.
Sebuah deskripsi layanan menentukan protokol komunikasi yang akan digunakan (misalnya,
SOAP) dan URI layanan, serta menggambarkan antarmuka. Antarmuka mungkin
digambarkan baik sebagai seperangkat operasi atau sebagai satu set pesan yang akan dipertukarkan antara
client dan server.
keamanan XML dirancang untuk memberikan perlindungan yang diperlukan untuk isi
dari dokumen yang dipertukarkan oleh anggota sekelompok orang, yang memiliki tugas yang berbeda untuk
tampil di dokumen itu. bagian yang berbeda dari dokumen akan tersedia untuk berbeda
orang, beberapa dengan kemampuan untuk menambah atau mengubah isi dan lain-lain hanya untuk membacanya. Untuk
memungkinkan fleksibilitas lengkap dalam penggunaan masa depan, sifat keamanan didefinisikan dalam
dokumen itu sendiri. Hal ini dicapai dengan cara XML, yang merupakan format self-describing.
elemen XML digunakan untuk menentukan bagian dokumen yang dienkripsi atau ditandatangani serta
sebagai rincian dari algoritma yang digunakan dan informasi untuk membantu dengan menemukan kunci.
layanan web telah digunakan untuk berbagai keperluan dalam sistem terdistribusi. Untuk
Misalnya, layanan web menyediakan implementasi alami dari konsep serviceoriented
arsitektur, di mana kopling longgar mereka memungkinkan interoperabilitas di Internetscale
aplikasi - termasuk (B2B) aplikasi bisnis-ke-bisnis. melekat mereka
kopling longgar juga mendukung munculnya pendekatan mashup ke layanan web
konstruksi. layanan web juga mendukung Grid, mendukung kolaborasi antara
ilmuwan atau insinyur dalam organisasi di berbagai belahan dunia. Pekerjaan mereka sangat
sering didasarkan pada penggunaan data mentah yang dikumpulkan oleh instrumen di situs yang berbeda dan kemudian
diproses secara lokal. Globus Toolkit merupakan implementasi dari arsitektur yang memiliki
telah digunakan dalam berbagai aplikasi data-intensif dan komputasi intensif.
Akhirnya, layanan web yang banyak digunakan dalam komputasi awan. Misalnya Amazon
AWS didasarkan sepenuhnya pada standar layanan web ditambah dengan filosofi REST
konstruksi layanan.