อะไรคือความแตกต่างระหว่างสไตล์เอกสารและการสื่อสารสไตล์ RPC?

ใครช่วยอธิบายความแตกต่างระหว่างบริการเว็บสไตล์เอกสารและ RPC ให้ฉันฟังได้ไหม นอกเหนือจาก JAX-RPC เวอร์ชันถัดไปคือ JAX-WS ซึ่งรองรับทั้งสไตล์เอกสารและ RPC ฉันยังเข้าใจว่าบริการเว็บสไตล์เอกสารมีไว้สำหรับการสื่อสารแบบอะซิงโครนัสโดยที่ไคลเอนต์จะไม่บล็อกจนกว่าจะได้รับการตอบกลับ

ไม่ว่าจะด้วยวิธีใดก็ตามโดยใช้ JAX-WS ในปัจจุบันฉันใส่คำอธิบายประกอบบริการด้วย@Webserviceสร้าง WSDL และจาก WSDL นั้นฉันสร้างอาร์ติแฟกต์ฝั่งไคลเอ็นต์

เมื่อได้รับอาร์ติแฟกต์แล้วในทั้งสองสไตล์ฉันจะเรียกใช้เมธอดบนพอร์ต ตอนนี้สิ่งนี้ไม่แตกต่างกันในสไตล์ RPC และสไตล์เอกสาร อะไรคือความแตกต่างและความแตกต่างนั้นมองเห็นได้ที่ไหน?

ในทำนองเดียวกัน SOAP ผ่าน HTTP แตกต่างจาก XML ผ่าน HTTP อย่างไร หลังจาก SOAP ทั้งหมดยังเป็นเอกสาร XML ที่มี SOAP namespace

เนื้อหาบางส่วนสามารถอธิบายความแตกต่างระหว่างสไตล์เอกสารและบริการเว็บสไตล์ RPC ได้หรือไม่

มีโมเดลรูปแบบการสื่อสารสองแบบที่ใช้ในการแปลการเชื่อมโยง WSDL กับเนื้อหาข้อความ SOAP พวกเขาคือ เอกสารและ RPC

ประโยชน์ของการใช้รูปแบบรูปแบบเอกสารคือการที่คุณสามารถโครงสร้างร่างกาย SOAP วิธีที่คุณต้องการตราบใด ๆ ที่เป็นเนื้อหาของร่างกายข้อความ SOAP เป็นเช่น XML ใด ๆ โดยพลการ รูปแบบเอกสารยังจะเรียกว่าเป็นรูปแบบข้อความเชิง

อย่างไรก็ตามด้วยโมเดลสไตล์ RPCโครงสร้างของเนื้อความคำร้องขอ SOAP ต้องมีทั้งชื่อการดำเนินการและชุดของพารามิเตอร์วิธีการ รูปแบบสไตล์ RPC จะถือว่าโครงสร้างเฉพาะของอินสแตนซ์ XMLอยู่ในเนื้อหาของข้อความ

นอกจากนี้ยังมีโมเดลการใช้การเข้ารหัสสองแบบที่ใช้ในการแปลการผูก WSDL กับข้อความ SOAP พวกเขาคือ: ตามตัวอักษรและเข้ารหัส

เมื่อมีการใช้รูปแบบการใช้งานที่แท้จริงเนื้อหาร่างกายควรเป็นไปตามที่ผู้ใช้กำหนดXML-สคี (XSD) โครงสร้าง ข้อดีคือสองเท่า ประการแรกคุณสามารถตรวจสอบความถูกต้องของเนื้อหาข้อความด้วย XML-schema ที่ผู้ใช้กำหนดนอกจากนี้คุณยังสามารถแปลงข้อความโดยใช้ภาษาการแปลงเช่น XSLT

ด้วยรูปแบบการใช้งานที่เข้ารหัส (SOAP) ข้อความจะต้องใช้ประเภทข้อมูล XSD แต่โครงสร้างของข้อความไม่จำเป็นต้องเป็นไปตาม XML schema ที่ผู้ใช้กำหนด ทำให้ยากต่อการตรวจสอบความถูกต้องของเนื้อหาข้อความหรือใช้การแปลงตาม XSLT บนเนื้อหาข้อความ

การผสมผสานรูปแบบและรูปแบบการใช้งานที่แตกต่างกันทำให้เรามีสี่วิธีในการแปลการผูก WSDL เป็นข้อความ SOAP

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

ฉันอยากจะแนะนำให้คุณอ่านบทความนี้ที่ชื่อว่าฉันควรใช้ WSDL รูปแบบใด? โดย Russell Butek ซึ่งมีการอภิปรายที่ดีเกี่ยวกับรูปแบบที่แตกต่างกันและใช้แบบจำลองเพื่อแปล WSDL ที่เชื่อมโยงกับข้อความ SOAP และจุดแข็งและจุดอ่อนที่เกี่ยวข้อง

เมื่อได้รับสิ่งประดิษฐ์ในรูปแบบการสื่อสารทั้งสองรูปแบบฉันจะเรียกใช้เมธอดบนพอร์ต ตอนนี้สิ่งนี้ไม่แตกต่างกันในสไตล์ RPC และสไตล์เอกสาร อะไรคือความแตกต่างและความแตกต่างนั้นมองเห็นได้ที่ไหน?

สถานที่ที่คุณจะพบความแตกต่างคือ "การตอบสนอง"!

สไตล์ 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); 
}

ข้อความ SOAP สำหรับการดำเนินการที่สองจะมีเอาต์พุตว่างเปล่าและจะมีลักษณะดังนี้:

การตอบสนองสไตล์ RPC:

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

รูปแบบเอกสาร:

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);
}

หากเราเรียกใช้ไคลเอนต์สำหรับ SEI ข้างต้นผลลัพธ์คือ:

123 [123, 456]

ผลลัพธ์นี้แสดงให้เห็นว่าองค์ประกอบ ArrayList กำลังแลกเปลี่ยนระหว่างบริการเว็บและไคลเอนต์ การเปลี่ยนแปลงนี้ทำได้โดยการเปลี่ยนแอตทริบิวต์ style ของคำอธิบายประกอบ SOAPBinding เท่านั้น ข้อความ SOAP สำหรับวิธีที่สองที่มีชนิดข้อมูลที่สมบูรณ์กว่าแสดงไว้ด้านล่างสำหรับการอ้างอิง:

การตอบสนองรูปแบบเอกสาร:

<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>

สรุป

• ดังที่คุณจะสังเกตเห็นในข้อความตอบกลับ SOAP สองข้อความว่าเป็นไปได้ที่จะตรวจสอบความถูกต้องของข้อความตอบกลับ SOAP ในกรณีของรูปแบบ DOCUMENT แต่ไม่ใช่ในบริการเว็บสไตล์ RPC
• ข้อเสียพื้นฐานของการใช้สไตล์ RPCคือไม่รองรับประเภทข้อมูลที่สมบูรณ์ยิ่งขึ้นและการใช้สไตล์เอกสารคือทำให้เกิดความซับซ้อนบางอย่างในรูปแบบของ XSD เพื่อกำหนดประเภทข้อมูลที่สมบูรณ์ยิ่งขึ้น
• การเลือกใช้สิ่งเหล่านี้ขึ้นอยู่กับข้อกำหนดการดำเนินการ / วิธีการและลูกค้าที่คาดหวัง

ในทำนองเดียวกัน SOAP บน HTTP แตกต่างจาก XML ผ่าน HTTP อย่างไร หลังจาก SOAP ทั้งหมดยังเป็นเอกสาร XML ที่มี SOAP namespace แล้วความแตกต่างที่นี่คืออะไร?

ทำไมเราต้องมีมาตรฐานเช่น SOAP? ด้วยการแลกเปลี่ยนเอกสาร XML ผ่าน HTTP โปรแกรมสองโปรแกรมสามารถแลกเปลี่ยนข้อมูลที่มีโครงสร้างที่หลากหลายโดยไม่ต้องใช้มาตรฐานเพิ่มเติมเช่น SOAP เพื่ออธิบายรูปแบบซองข้อความอย่างชัดเจนและวิธีการเข้ารหัสเนื้อหาที่มีโครงสร้าง

SOAP จัดเตรียมมาตรฐานเพื่อให้นักพัฒนาไม่ต้องคิดค้นรูปแบบข้อความ XML ที่กำหนดเองสำหรับทุกบริการที่ต้องการให้พร้อมใช้งาน ด้วยลายเซ็นของวิธีการบริการที่จะเรียกใช้ข้อกำหนด SOAP จะกำหนดรูปแบบข้อความ XML ที่ไม่คลุมเครือ นักพัฒนาที่คุ้นเคยกับข้อกำหนด SOAP ซึ่งทำงานในภาษาโปรแกรมใด ๆ สามารถกำหนดคำขอ SOAP XML ที่ถูกต้องสำหรับบริการเฉพาะและเข้าใจการตอบสนองจากบริการโดยรับรายละเอียดบริการต่อไปนี้

• ชื่อบริการ
• ชื่อวิธีการดำเนินการโดยบริการ
• ลายเซ็นของแต่ละวิธี
• ที่อยู่ของการใช้บริการ (แสดงเป็น URI)

การใช้ SOAP ช่วยเพิ่มความคล่องตัวในการเปิดเผยส่วนประกอบซอฟต์แวร์ที่มีอยู่เป็นบริการบนเว็บเนื่องจากลายเซ็นวิธีการของบริการระบุโครงสร้างเอกสาร XML ที่ใช้สำหรับทั้งคำขอและการตอบกลับ

บริการเว็บสไตล์ RPC ใช้ชื่อของเมธอดและพารามิเตอร์เพื่อสร้างโครงสร้าง XML ที่แสดงถึง call stack ของเมธอด ลักษณะเอกสารระบุว่าเนื้อความ SOAP มีเอกสาร XML ซึ่งสามารถตรวจสอบความถูกต้องกับเอกสาร XML schema ที่กำหนดไว้ล่วงหน้า

จุดเริ่มต้นที่ดี: SOAP Binding: ความแตกต่างระหว่าง Document และ RPC Style Web Services

ในคำจำกัดความ WSDL การเชื่อมโยงประกอบด้วยการดำเนินการนี่คือสไตล์สำหรับแต่ละการดำเนินการ

เอกสาร:ในไฟล์ WSDL จะระบุรายละเอียดประเภทไม่ว่าจะเป็นแบบอินไลน์หรือนำเข้าเอกสาร XSD ซึ่งอธิบายโครงสร้าง (เช่นสคีมา) ของชนิดข้อมูลที่ซับซ้อนที่แลกเปลี่ยนโดยวิธีการบริการเหล่านั้นซึ่งทำให้คู่กันอย่างหลวม ๆ รูปแบบเอกสารเป็นค่าเริ่มต้น

• ประโยชน์ :
  • การใช้รูปแบบเอกสารนี้เราสามารถตรวจสอบข้อความ SOAP กับสคีมาที่กำหนดไว้ล่วงหน้า รองรับประเภทข้อมูลและรูปแบบ xml
  • คู่กันอย่างหลวม ๆ
• ข้อเสีย : ยากที่จะทำความเข้าใจ

ในองค์ประกอบประเภท WSDL มีลักษณะดังนี้:

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

สคีมากำลังนำเข้าจากการอ้างอิงภายนอก

RPC : ในไฟล์ WSDL จะไม่สร้างสคีมาประเภทภายในองค์ประกอบข้อความจะกำหนดแอตทริบิวต์ชื่อและประเภทซึ่งทำให้คู่กันอย่างแน่นหนา

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

• ข้อดี : เข้าใจง่าย
• เสียเปรียบ :
  • เราไม่สามารถตรวจสอบข้อความ SOAP ได้
  • คู่กันอย่างแน่นหนา

RPC:ไม่มีประเภทใน
เอกสาร WSDL :ส่วนประเภทจะพร้อมใช้งานใน WSDL

สถานการณ์หลักที่ใช้ JAX-WS RPCและสไตล์เอกสารเป็นดังนี้:

• รูปแบบRemote Procedure Call (RPC)ถูกใช้เมื่อผู้ใช้บริการดูเว็บเซอร์วิสเป็นแอปพลิเคชันเชิงตรรกะเดียวหรือส่วนประกอบที่มีข้อมูลที่ห่อหุ้ม ข้อความการร้องขอและการตอบกลับจะแมปโดยตรงกับพารามิเตอร์อินพุตและเอาต์พุตของการเรียกโพรซีเดอร์

  ตัวอย่างรูปแบบ RPC ประเภทนี้อาจรวมถึงบริการชำระเงินหรือบริการเสนอราคาหุ้น

• รูปแบบเอกสารที่ใช้จะใช้ในสถานการณ์ที่ผู้บริโภคมองบริการเว็บเป็นกระบวนการทางธุรกิจที่ทำงานอีกต่อไปที่เอกสารคำขอหมายถึงหน่วยที่สมบูรณ์ของข้อมูล บริการเว็บประเภทนี้อาจเกี่ยวข้องกับการโต้ตอบของมนุษย์เช่นเดียวกับเอกสารขอสินเชื่อพร้อมเอกสารตอบกลับที่มีการเสนอราคาจากสถาบันให้กู้ยืม เนื่องจากกระบวนการทางธุรกิจที่ทำงานนานขึ้นอาจไม่สามารถส่งคืนเอกสารที่ร้องขอได้ในทันทีรูปแบบเอกสารจึงมักพบในสถาปัตยกรรมการสื่อสารแบบอะซิงโครนัส รูปแบบเอกสาร / ตัวอักษรของ SOAP ถูกใช้เพื่อใช้รูปแบบบริการบนเว็บตามเอกสาร

ฉันคิดว่าสิ่งที่คุณถามคือความแตกต่างระหว่างบริการเว็บ RPC Literal, Document Literal และ Document Wrapped SOAP

โปรดทราบว่าบริการเว็บเอกสารถูกแบ่งออกเป็นตามตัวอักษรและรวมไว้ด้วยและแตกต่างกัน - ความแตกต่างหลักประการหนึ่งคือบริการหลังเป็นไปตามมาตรฐาน BP 1.1 และเดิมไม่ได้

นอกจากนี้ใน Document Literal การดำเนินการที่จะเรียกไม่ได้ระบุไว้ในรูปของชื่อในขณะที่ Wrapped นั้นคือ ฉันคิดว่านี่เป็นความแตกต่างอย่างมีนัยสำคัญในแง่ของการหาชื่อการดำเนินการที่ร้องขอได้อย่างง่ายดาย

ในแง่ของ RPC literal กับ Document Wrapped คำร้องขอ Document Wrapped สามารถตรวจสอบ / ตรวจสอบความถูกต้องเทียบเคียงกับ schema ใน WSDL ได้อย่างง่ายดายซึ่งเป็นข้อดีอย่างหนึ่ง

ฉันขอแนะนำให้ใช้ Document Wrapped เป็นตัวเลือกประเภทบริการเว็บเนื่องจากข้อดี

SOAP บน HTTP คือโปรโตคอล SOAP ที่ผูกไว้กับ HTTP เป็นตัวพา SOAP อาจอยู่บน SMTP หรือ XXX ได้เช่นกัน SOAP จัดเตรียมวิธีการโต้ตอบระหว่างเอนทิตี (ไคลเอนต์และเซิร์ฟเวอร์เป็นต้น) และเอนทิตีทั้งสองสามารถจัดอาร์กิวเมนต์การดำเนินการ / ส่งคืนค่าตามความหมายของโปรโตคอล

หากคุณใช้ XML ผ่าน HTTP (และทำได้) เป็นที่เข้าใจง่ายว่าเป็นเพย์โหลด XML ตามคำขอ / การตอบกลับ HTTP คุณจะต้องจัดเตรียมเฟรมเวิร์กให้กับ marshal / unmarshal การจัดการข้อผิดพลาดและอื่น ๆ

บทช่วยสอนโดยละเอียดพร้อมตัวอย่าง WSDL และโค้ดโดยเน้น Java: SOAP และ JAX-WS, RPC เทียบกับ Document Web Services

เอกสาร
ข้อความรูปแบบเอกสารที่สามารถตรวจสอบกับสคีที่กำหนดไว้ล่วงหน้า ในรูปแบบเอกสารข้อความ SOAP จะถูกส่งเป็นเอกสารเดียว ตัวอย่างสคีมา:

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

ตัวอย่างข้อความเนื้อสบู่สไตล์เอกสาร

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

ข้อความรูปแบบเอกสารอยู่คู่กันอย่างหลวม ๆ

RPC ข้อความสไตล์ RPC ใช้ชื่อวิธีการและพารามิเตอร์ในการสร้างโครงสร้าง XML ข้อความนั้นยากที่จะตรวจสอบกับสคีมา ในรูปแบบ RPC ข้อความ SOAP จะถูกส่งเป็นองค์ประกอบต่างๆ

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

ที่นี่มีการระบุพารามิเตอร์แต่ละรายการอย่างไม่ชัดเจนข้อความสไตล์ RPC จะอยู่คู่กันอย่างแน่นหนาโดยทั่วไปจะเป็นแบบคงที่ซึ่งต้องมีการเปลี่ยนแปลงกับไคลเอนต์เมื่อลายเซ็นของวิธีการเปลี่ยนแปลงสไตล์ rpc ถูก จำกัด ไว้ที่ประเภท XSD ที่เรียบง่ายมากเช่น String และ Integer และ WSDL ที่เป็นผลลัพธ์จะไม่ ยังมีส่วนประเภทเพื่อกำหนดและ จำกัด พารามิเตอร์

ตัวอักษร ตามสไตล์เริ่มต้น ข้อมูลถูกทำให้เป็นอนุกรมตามสคีมาประเภทข้อมูลไม่ได้ระบุไว้ในข้อความ แต่ใช้การอ้างอิงถึงสคีมา (เนมสเปซ) เพื่อสร้างข้อความสบู่

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

ประเภท ข้อมูลเข้ารหัสที่ระบุในแต่ละพารามิเตอร์

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

สคีมาฟรี