Apa perbedaan antara Gaya dokumen dan komunikasi gaya RPC?


94

Adakah yang bisa menjelaskan kepada saya perbedaan antara layanan web gaya Dokumen dan RPC? Selain JAX-RPC, versi berikutnya adalah JAX-WS, yang mendukung gaya Dokumen dan RPC. Saya juga memahami layanan web gaya dokumen dimaksudkan untuk komunikasi asinkron di mana klien tidak akan memblokir hingga respons diterima.

Either way, menggunakan JAX-WS Saya saat ini membuat anotasi layanan dengan @Webservice , menghasilkan WSDL dan dari WSDL itu saya membuat artefak sisi klien.

Setelah artefak diterima, dalam kedua gaya, saya memanggil metode di porta. Sekarang, ini tidak berbeda dalam gaya RPC dan gaya Dokumen. Jadi apa perbedaannya dan di manakah perbedaan itu terlihat?

Demikian pula, dalam hal apa SOAP melalui HTTP berbeda dari XML melalui HTTP? Setelah semua SOAP juga dokumen XML dengan namespace SOAP.


Jawaban:


99

Dapatkah beberapa badan menjelaskan kepada saya perbedaan antara gaya Dokumen dan layanan web gaya RPC?

Ada dua model gaya komunikasi yang digunakan untuk menerjemahkan WSDL yang mengikat ke badan pesan SOAP. Mereka adalah: Dokumen & RPC

The Keuntungan menggunakan model gaya Dokumen adalah bahwa Anda dapat struktur tubuh SOAP cara apapun yang Anda inginkan selama isi badan pesan SOAP adalah setiap contoh XML sewenang-wenang. Gaya Dokumen juga disebut sebagai gaya Berorientasi Pesan .

Namun, dengan model gaya RPC , struktur badan permintaan SOAP harus berisi nama operasi dan set parameter metode. Model gaya RPC mengasumsikan struktur khusus untuk contoh XML yang terdapat dalam badan pesan.

Selain itu, ada dua model penggunaan pengkodean yang digunakan untuk menerjemahkan WSDL yang mengikat ke pesan SOAP. Mereka adalah: literal, dan dikodekan

Saat menggunakan model penggunaan literal , konten isi harus sesuai dengan struktur XML-schema (XSD) yang ditentukan pengguna . Keuntungannya dua kali lipat. Pertama, Anda dapat memvalidasi badan pesan dengan skema XML yang ditentukan pengguna, selain itu, Anda juga dapat mengubah pesan menggunakan bahasa transformasi seperti XSLT.

Dengan model penggunaan yang dienkode (SOAP) , pesan harus menggunakan tipe data XSD, tetapi struktur pesan tidak perlu mengikuti skema XML yang ditentukan pengguna. Hal ini menyulitkan untuk memvalidasi badan pesan atau menggunakan transformasi berbasis XSLT pada badan pesan.

Kombinasi gaya dan model penggunaan yang berbeda memberi kita empat cara berbeda untuk menerjemahkan pengikatan WSDL ke pesan SOAP.

Document/literal
Document/encoded
RPC/literal
RPC/encoded

Saya akan merekomendasikan agar Anda membaca artikel ini yang berjudul Gaya WSDL manakah yang harus saya gunakan? oleh Russell Butek yang memiliki diskusi bagus tentang gaya yang berbeda dan menggunakan model untuk menerjemahkan WSDL yang mengikat ke pesan SOAP, dan kekuatan dan kelemahan relatifnya.

Setelah artefak diterima, dalam kedua gaya komunikasi, saya memanggil metode di pelabuhan. Sekarang, ini tidak berbeda dalam gaya RPC dan gaya Dokumen. Jadi apa perbedaannya dan di manakah perbedaan itu terlihat?

Tempat di mana Anda dapat menemukan perbedaannya adalah "RESPONS"!

Gaya RPC:

package com.sample;

import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style=Style.RPC)
public interface StockPrice { 

    public String getStockPrice(String stockName); 

    public ArrayList getStockPriceList(ArrayList stockNameList); 
}

Pesan SOAP untuk operasi kedua akan memiliki keluaran kosong dan akan terlihat seperti:

Respons Gaya RPC:

<ns2:getStockPriceListResponse 
       xmlns:ns2="http://sample.com/">
    <return/>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>

Gaya Dokumen:

package com.sample;

import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style=Style.DOCUMENT)
public interface StockPrice {

    public String getStockPrice(String stockName);

    public ArrayList getStockPriceList(ArrayList stockNameList);
}

Jika kita menjalankan klien untuk SEI di atas, hasilnya adalah:

123 [123, 456]

Output ini menunjukkan bahwa elemen ArrayList dipertukarkan antara layanan web dan klien. Perubahan ini telah dilakukan hanya dengan mengubah atribut gaya anotasi SOAPBinding. Pesan SOAP untuk metode kedua dengan tipe data yang lebih kaya ditunjukkan di bawah ini sebagai referensi:

Tanggapan Gaya Dokumen:

<ns2:getStockPriceListResponse 
       xmlns:ns2="http://sample.com/">
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xsi:type="xs:string">123</return>
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xsi:type="xs:string">456</return>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>

Kesimpulan

  • Seperti yang Anda perhatikan dalam dua pesan respons SOAP yang memungkinkan untuk memvalidasi pesan respons SOAP dalam kasus gaya DOKUMEN tetapi tidak dalam layanan web gaya RPC.
  • Kerugian dasar menggunakan gaya RPC adalah tidak mendukung tipe data yang lebih kaya dan gaya Dokumen membawa beberapa kompleksitas dalam bentuk XSD untuk mendefinisikan tipe data yang lebih kaya.
  • Pilihan untuk menggunakan salah satu dari ini tergantung pada persyaratan operasi / metode dan klien yang diharapkan.

Demikian pula, dalam hal apa SOAP melalui HTTP berbeda dengan XML melalui HTTP? Setelah semua SOAP juga dokumen XML dengan namespace SOAP. Jadi apa bedanya disini?

Mengapa kita membutuhkan standar seperti SOAP? Dengan menukar dokumen XML melalui HTTP, dua program dapat bertukar informasi yang kaya dan terstruktur tanpa pengenalan standar tambahan seperti SOAP untuk menjelaskan secara eksplisit format amplop pesan dan cara untuk menyandikan konten terstruktur.

SOAP menyediakan standar sehingga pengembang tidak perlu membuat format pesan XML kustom untuk setiap layanan yang ingin mereka sediakan. Mengingat tanda tangan metode layanan yang akan dipanggil, spesifikasi SOAP menetapkan format pesan XML yang tidak ambigu. Setiap pengembang yang akrab dengan spesifikasi SOAP, yang bekerja dalam bahasa pemrograman apa pun, dapat merumuskan permintaan SOAP XML yang benar untuk layanan tertentu dan memahami respons dari layanan dengan mendapatkan detail layanan berikut.

  • Nama layanan
  • Nama metode yang diterapkan oleh layanan
  • Tanda tangan metode dari setiap metode
  • Alamat implementasi layanan (dinyatakan sebagai URI)

Menggunakan SOAP mempersingkat proses untuk mengekspos komponen perangkat lunak yang ada sebagai layanan Web karena tanda tangan metode layanan mengidentifikasi struktur dokumen XML yang digunakan untuk permintaan dan respons.


Terima kasih khusus untuk "Jenis WSDL apa yang harus saya gunakan?" tautan artikel.
Boolean_Type


20

Dalam definisi WSDL, binding berisi operasi, inilah gaya untuk setiap operasi.

Dokumen: Dalam file WSDL, ini menentukan detail tipe baik yang memiliki inline Atau mengimpor dokumen XSD, yang menjelaskan struktur (yaitu skema) dari tipe data kompleks yang dipertukarkan oleh metode layanan yang membuat digabungkan secara longgar. Gaya dokumen adalah default.

  • Keuntungan :
    • Dengan menggunakan gaya Dokumen ini, kita dapat memvalidasi pesan SOAP terhadap skema yang telah ditentukan sebelumnya. Ini mendukung tipe data dan pola xml.
    • Hubungan renggang.
  • Kekurangan : Agak sulit untuk dimengerti.

Dalam jenis elemen WSDL terlihat sebagai berikut:

<types>
 <xsd:schema>
  <xsd:import schemaLocation="http://localhost:9999/ws/hello?xsd=1" namespace="http://ws.peter.com/"/>
 </xsd:schema>
</types>

Skema sedang diimpor dari referensi eksternal.

RPC : Dalam file WSDL, ia tidak membuat skema tipe, di dalam elemen pesan ia mendefinisikan atribut nama dan tipe yang membuatnya terikat erat.

<types/>  
<message name="getHelloWorldAsString">  
<part name="arg0" type="xsd:string"/>  
</message>  
<message name="getHelloWorldAsStringResponse">  
<part name="return" type="xsd:string"/>  
</message>  
  • Keuntungan : Mudah dimengerti.
  • Kerugian :
    • kami tidak dapat memvalidasi pesan SOAP.
    • berpasangan erat

RPC: Tidak ada tipe dalam
Dokumen WSDL : Bagian tipe akan tersedia di WSDL


Ulangi saja apa yang ada di referensinya. Penjelasan ini tidak membantu saya dalam memahami perbedaannya.
kinunt

1
ini pasti bukan dari referensi atau dokumentasi - ini penuh dengan kesalahan tata bahasa
spesialis

7

Skenario utama di mana JAX-WS RPC dan gaya Dokumen digunakan sebagai berikut:

  • Pola Remote Procedure Call (RPC) digunakan saat konsumen melihat layanan web sebagai aplikasi atau komponen logis tunggal dengan data yang dienkapsulasi. Pesan permintaan dan respons dipetakan langsung ke parameter input dan output dari panggilan prosedur.

    Contoh dari jenis pola RPC ini mungkin termasuk layanan pembayaran atau layanan penawaran harga saham.

  • The Pola berdasarkan dokumen- digunakan dalam situasi di mana konsumen memandang layanan web sebagai proses bisnis lagi berjalan di mana dokumen permintaan merupakan unit lengkap informasi. Jenis layanan web ini dapat melibatkan interaksi manusia misalnya dengan dokumen permintaan pengajuan kredit dengan dokumen tanggapan yang berisi tawaran dari lembaga pemberi pinjaman. Karena proses bisnis yang berjalan lebih lama mungkin tidak dapat segera mengembalikan dokumen yang diminta, pola berbasis dokumen lebih umum ditemukan dalam arsitektur komunikasi asinkron. Variasi Dokumen / literal SOAP digunakan untuk mengimplementasikan pola layanan web berbasis dokumen.


3

Saya pikir apa yang Anda tanyakan adalah perbedaan antara layanan web RPC Literal, Document Literal dan Document Wrapped SOAP.

Perhatikan bahwa layanan web Dokumen digambarkan menjadi literal dan dibungkus juga dan mereka berbeda - salah satu perbedaan utama adalah bahwa yang terakhir sesuai dengan BP 1.1 dan yang pertama tidak.

Juga, dalam Literal Dokumen, operasi yang akan dipanggil tidak ditentukan dalam istilah namanya sedangkan di Dibungkus, itu. Ini, menurut saya, adalah perbedaan yang signifikan dalam hal dengan mudah mengetahui nama operasi untuk permintaan tersebut.

Dalam hal literal RPC versus Document Wrapped, permintaan Document Wrapped dapat dengan mudah diperiksa / divalidasi terhadap skema di WSDL - satu keuntungan besar.

Saya akan menyarankan menggunakan Document Wrapped sebagai jenis layanan web pilihan karena kelebihannya.

SOAP pada HTTP adalah protokol SOAP yang terikat pada HTTP sebagai pembawa. SOAP bisa di atas SMTP atau XXX juga. SOAP menyediakan cara interaksi antara entitas (klien dan server, misalnya) dan kedua entitas dapat mengatur argumen operasi / mengembalikan nilai sesuai semantik protokol.

Jika Anda menggunakan XML melalui HTTP (dan Anda bisa), itu hanya dipahami sebagai muatan XML pada permintaan / respons HTTP. Anda perlu menyediakan kerangka kerja untuk marshal / unmarshal, penanganan kesalahan, dan sebagainya.

Tutorial rinci dengan contoh WSDL dan kode dengan penekanan pada Java: SOAP dan JAX-WS, RPC versus Layanan Web Dokumen


2

Dokumen
Pesan gaya dokumen dapat divalidasi dengan skema yang telah ditentukan sebelumnya. Dalam gaya dokumen, pesan SOAP dikirim sebagai dokumen tunggal. Contoh skema:

  <types>  
   <xsd:schema> <xsd:import namespace="http://example.com/" 
    schemaLocation="http://localhost:8080/ws/hello?xsd=1"/>  
   </xsd:schema>  
  </types>

Contoh pesan badan sabun gaya dokumen

  <message name="getHelloWorldAsString">   
     <part name="parameters" element="tns:getHelloWorldAsString"/>   
  </message> 
  <message name="getHelloWorldAsStringResponse">  
     <part name="parameters"> element="tns:getHelloWorldAsStringResponse"/>   
  </message>

Pesan gaya dokumen digabungkan secara longgar.

Pesan gaya RPC RPC menggunakan nama metode dan parameter untuk menghasilkan struktur XML. pesan sulit untuk divalidasi dengan skema. Dalam gaya RPC, pesan SOAP dikirim sebanyak elemen.

  <message name="getHelloWorldAsString">
    <part name="arg0"> type="xsd:string"/>   
   </message> 
  <message name="getHelloWorldAsStringResponse">   
    <part name="return"
   > type="xsd:string"/>   
  </message>

Di sini setiap parameter ditentukan secara terpisah, pesan gaya RPC digabungkan dengan erat, biasanya statis, memerlukan perubahan pada klien ketika tanda tangan metode berubah Gaya rpc dibatasi untuk jenis XSD yang sangat sederhana seperti String dan Integer, dan WSDL yang dihasilkan tidak akan bahkan memiliki bagian tipe untuk mendefinisikan dan membatasi parameter

Literal Dengan gaya default. Data diserialkan menurut skema, tipe data tidak ditentukan dalam pesan tetapi referensi ke skema (namespace) digunakan untuk membuat pesan sabun.

   <soap:body>
     <myMethod>
        <x>5</x>
        <y>5.0</y>
     </myMethod>
   </soap:body>

Jenis data yang dikodekan ditentukan di setiap parameter

   <soap:body>
     <myMethod>
         <x xsi:type="xsd:int">5</x>
         <y xsi:type="xsd:float">5.0</y>
     </myMethod>
   </soap:body>

Skema gratis

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.