soap ट्यूटोरियल
साबुन से शुरुआत करना
खोज…
टिप्पणियों
इस अनुभाग में यह बताया गया है कि साबुन क्या है और एक डेवलपर इसका उपयोग क्यों करना चाहता है।
इसमें साबुन के भीतर किसी बड़े विषय का भी उल्लेख होना चाहिए, और संबंधित विषयों के लिए लिंक होना चाहिए। चूंकि साबुन के लिए दस्तावेज़ीकरण नया है, इसलिए आपको उन संबंधित विषयों के प्रारंभिक संस्करण बनाने की आवश्यकता हो सकती है।
संस्करण
संस्करण | रिलीज़ की तारीख |
---|---|
1.1 | 2000/05/08 |
1.2 | 2003/06/24 |
सामान्य जानकारी
SOAP सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल के लिए एक संक्षिप्त नाम है जो एक प्रोटोकॉल को परिभाषित करता है जो कि अन्य SOAP सेवाओं या क्लाइंट के साथ रिमोट प्रक्रिया कॉल (RPC) के माध्यम से डेटा का आदान-प्रदान करने के लिए उपयोग किया जाता है। यह दो संस्करण में उपलब्ध है:
एसओएपी 1.2 का उपयोग एसओएपी 1.1 करता है इसलिए यदि संभव हो तो एसओएपी 1.2 का उपयोग करने की सिफारिश की जाती है।
यह अक्सर HTTP / S के शीर्ष पर निर्मित होता है और शायद ही कभी SMTP या FTP पर होता है, हालांकि यह प्रोटोकॉल के अनुसार इसका समर्थन करेगा। यद्यपि HTTP को अक्सर अंतर्निहित परिवहन प्रोटोकॉल के रूप में उपयोग किया जाता है, सोप केवल इसका एक सीमित उपसमूह का उपयोग करता है। अनुरोध भेजने के लिए यह HTTP के POST
ऑपरेशन पर लगभग पूरी तरह निर्भर करता है। GET
इनवोकेशन सैद्धांतिक रूप से 1.2 के बाद से संभव है, हालांकि दस्तावेज़ को URI पैरामीटर के रूप में पारित किया जाना है और इस तरह लगभग 3000 वर्ण सीमा से अधिक हो सकता है जिसे अधिकांश रूपरेखाओं द्वारा अस्वीकार कर दिया गया है। इसके अलावा, सुरक्षा संबंधी सेटिंग्स को आमतौर पर एक विशेष SOAP हेडर के भीतर परिभाषित किया जाता है।
हालाँकि SOAP और REST को वेब-सर्विसेज कहा जाता है, लेकिन वे स्वभाव से बहुत अलग हैं। कुछ चौखटे WS (SOAP आधारित सेवाओं के लिए) और RS (REST आधारित सेवाओं के लिए) के बीच अंतर करते हैं।
निम्न तालिका दोनों वेब सेवा प्रकारों के बीच अंतर पर एक संक्षिप्त अवलोकन देती है।
पहलू | साबुन | आराम |
---|---|---|
मानक | एसओएपी , डब्ल्यूएसडीएल | कोई मानक नहीं, सिर्फ एक वास्तुशिल्प शैली |
संसाधन को संबोधित करते हुए | SOAP संचालन के माध्यम से अप्रत्यक्ष | अद्वितीय संसाधन पहचानकर्ताओं (URI) के माध्यम से |
गलती संभालना | SOAP गलती संदेश | HTTP त्रुटि प्रतिक्रिया कोड और वैकल्पिक रूप से प्रतिक्रिया निकाय |
डेटा प्रतिनिधित्व | एक्सएमएल | HTTP में सभी उपलब्ध एनकोडिंग |
HTTP का उपयोग | परिवहन प्रोटोकॉल के रूप में | HTTP विधियों (GET, POST, PUT, DELETE, ...) पर संसाधनों (CRUD) पर कार्रवाई |
लेन-देन का समर्थन | SOAP हेडर के माध्यम से | एक संसाधन के रूप में लेनदेन को मॉडलिंग करके |
राज्य | स्टेटफुल (SOAP कार्रवाई अनुप्रयोग का हिस्सा है) | स्टेटलेस (स्व-अनुरोधित) |
सेवा खोज | UDDI / WSDL | वास्तव में कोई नहीं; एपीआई के स्टार्ट-यूआरआई को हालांकि उप एपीआई की सूची वापस करनी चाहिए |
तरीका | SOAP बॉडी के अंदर | HTTP विधि |
विधि तर्क | WSDL में XML स्कीमा द्वारा परिभाषित | या तो HTTP शीर्ष लेख या पथ / क्वेरी या मैट्रिक्स पैरामीटर URI के भीतर |
अवस्था संक्रमण | यह निर्धारित करना मुश्किल है कि डेटा के आधार पर सीधे नहीं | अगला यूआरआई मंगलाचरण |
कैशिंग समर्थन | अक्सर वांछित नहीं कैशिंग, | HTTP द्वारा परिभाषित सरल |
साबुन
SOAP अनुरोधों में एक SOAP आवरण होता है जिसमें एक शरीर तत्व शामिल होता है और इसमें एक वैकल्पिक हेडर तत्व हो सकता है। हेडर तत्व का उपयोग सेवा में कुछ कॉन्फ़िगरेशन को पास करने के लिए किया जाता है जैसे कि WS-Security परिभाषित कर सकता है कि संदेश एन्क्रिप्ट किया गया है या WS-Coordination / WS-Transaction परिभाषित कर सकता है कि संदेश को लेनदेन के भीतर निष्पादित किया जाना है।
HTTP के माध्यम से एक साधारण SOAP 1.2 अनुरोध जो दो मान जोड़ता है, इस तरह दिखाई दे सकता है:
POST /calculator HTTP/1.1
Host: http://example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 224
<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<m:AddValues xmlns:m="http://example.org/calculator">
<m:FirstValue>1</m:FirstValue>
<m:SecondValue>2</m:SecondValue>
</m:AddValues>
</env:Body>
</env:Envelope>
उपरोक्त नमूना अनुरोध की प्रतिक्रिया इस तरह दिख सकती है
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 329
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/calculator">
<m:AddValuesResponse>
<m:Result>3</m:Result>
</m:AddValuesResponse>
</soap:Body>
</soap:Envelope>
उदाहरण के लिए एक अनुरोध जो लागू परिभाषित ऊपर AddValues
दो तर्क, साथ विधि FirstValue
सेट करने के लिए 1
और SecondValue
को सेट 2
। इस अनुरोध के परिणामस्वरूप रिमोट SOAP सर्वर पर इस पद्धति का निष्पादन हुआ, जिसने 3
मान की गणना की, जो एक अलग प्रतिक्रिया तत्व में एनकैप्सुलेटेड है, जो कि सम्मेलन द्वारा अक्सर लागू विधि का नाम और अनुगामी Response
स्ट्रिंग है, जो कोई भी हो प्रतिक्रिया का निरीक्षण करने से यह निष्कर्ष AddValue
सकता है कि यह पिछले AddValue
पद्धति के आह्वान की प्रतिक्रिया है।
एसओएपी 1.1 और 1.2 के बीच अंतर
एसओएपी 1.2 अन्य परिवहन प्रोटोकॉल के लिए अनुमति देता है तब तक एचटीटीपी जब तक बाध्यकारी रूपरेखा प्रोटोकॉल द्वारा समर्थित है।
SOAP 1.1 XML 1.0 पर आधारित है, जबकि 1.2 XML Infoset पर आधारित है जो SOAP संदेशों को अन्य धारावाहिकों के साथ क्रमबद्ध करने की अनुमति देता है, फिर डिफ़ॉल्ट XML 1.0 धारावाहिक SOAP 1.1 द्वारा उपयोग किया जाता है। यह बाइनरी संदेशों के रूप में संदेशों को अनुक्रमित करने की अनुमति देता है और इसलिए संदेश की XML प्रकृति के कुछ ओवरहेड को रोकता है। इसके अलावा, उपयोग किए गए अंतर्निहित प्रोटोकॉल के क्रमांकन तंत्र को डेटा बाइंडिंग के माध्यम से निर्धारित किया जा सकता है।
एक और अधिक विशिष्ट प्रसंस्करण मॉडल को परिभाषित करके SOAP 1.2 के साथ इंटरऑपरेबिलिटी पहलू को भी बढ़ावा दिया गया था, फिर इसके पूर्ववर्ती ने व्याख्या के लिए कई संभावनाओं को समाप्त कर दिया। SOAP अटैचमेंट एपीआई (SAAJ), जो SOAP 1.1 और 1.2 संदेशों पर काम करने की अनुमति देता है, ने कई फ्रेमवर्क कार्यान्वयनकर्ताओं को संदेशों को संसाधित करने और बनाने में मदद की।
W3C ने SOAP 1.1 और 1.2 के बीच मुख्य बदलावों पर एक संक्षिप्त अवलोकन जारी किया है
वेब सेवा अंतर
वेब सर्विस इंटरऑपरेबिलिटी (जिसे डब्ल्यूएस-आई के नाम से भी जाना जाता है) कुछ नामी उद्यमों जैसे आईबीएम, माइक्रोसॉफ्ट, ओरेकल और एचपी द्वारा संचालित एक इंटरऑपरेबिलिटी गाइडलाइन है जिसका नाम कुछ ही है। दूसरों के बीच ये दिशानिर्देश SOAP निकाय के भीतर केवल एक ही मूल तत्व का उपयोग करने की सलाह देते हैं, भले ही SOAP शरीर के भीतर कई तत्वों को शामिल करने की अनुमति देता है।
WS- I में शामिल हैं
- डब्ल्यूएस-आई बेसिक प्रोफाइल उर्फ डब्ल्यूएसआई-बीपी
- WS-I मूल सुरक्षा प्रोफ़ाइल
- सिंपल सोप बाइंडिंग प्रोफाइल
WSI-BP 4 अलग-अलग संस्करणों में उपलब्ध है v1.0 (2004) , v1.1 (2006) , v1.2 (2010) , v2.0 (2010) और SOAP, WSDL जैसे मुख्य वेब सेवा विनिर्देशों के लिए अंतर-दिशा-निर्देशों को परिभाषित करता है। और UDDI। वेब सेवा विवरण भाषा (डब्लूएसडीएल) के उपयोग के माध्यम से, एसओएपी सेवाएं उनके समर्थित संचालन और विधियों का वर्णन अन्य समापन बिंदुओं के लिए एक सामंजस्यपूर्ण सेट के भीतर कर सकती हैं। डब्ल्यूएसआई-बीपी एक संकीर्ण सेट को परिभाषित करने के लिए डब्ल्यूएसडीएल का उपयोग करता है तो पूर्ण डब्ल्यूएसडीएल या एसओएपी स्कीमा परिभाषित करेगा और इस प्रकार विनिर्देश के भीतर कुछ अस्पष्टता को समाप्त करता है और इस तरह समापन बिंदु के बीच अंतर को बेहतर बनाता है।
डबल्यूएसडीएल
उपलब्ध एसओएपी परिचालनों, उनके मापदंडों के साथ-साथ ग्राहकों को आह्वान करने के लिए संबंधित समापन बिंदुओं को विज्ञापित करने के लिए, एक और XML आधारित दस्तावेज़ का उपयोग किया जाता है जिसे लघु के लिए Web Services Description Language
या डब्ल्यूएसडीएल कहा जाता है।
डब्ल्यूएसडीएल सेवा समापन बिंदु, एसओएपी संदेशों को संचालन के लिए बाध्य करने, संचालन के इंटरफेस के साथ-साथ ग्राहकों को उनके प्रकारों का वर्णन करता है। WSDL, SOAP की तरह, 2 संस्करणों में उपलब्ध है, जो उनके सिंटैक्स में थोड़ा भिन्न होता है, हालांकि क्लाइंट के लगभग समान शब्दार्थ को व्यक्त करता है।
डब्लूएसडीएल १.१
एक WSDL 1.1 विवरण में एक service
, एक binding
, एक portType
और एक message
अनुभाग शामिल है। यह WSDL फ़ाइल के भीतर स्कीमा को आगे आयात या परिभाषित कर सकता है जैसा कि एक नमूना WSDL फ़ाइल से देखा जा सकता है जो ऊपर दिखाए गए कैलकुलेटर के नमूने से मेल खाती है:
<wsdl:definitions xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:calc="http://example.org/calculator"
xmlns:tns="http://example.org/calculatorService"
targetNamespace="http://example.org/calculatorService">
<!--
Abstract type definitions
-->
<wsdl:types>
<!--
<xs:schema>
<xs:import namespace="http://example.org/calculator" schemaLocation="calc/calculator.xsd" />
</xs:schema>
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://example.org/calculator"
targetNamespace="http://example.org/calculator"
elementFormDefault="qualified"
attributeFormDefault="qualified">
<xs:element name="AddValuesRequest" type="tns:AddValuesType" />
<xs:element name="AddValuesResponse" type="tns:AddValuesResponseType" />
<xs:complexType name="AddValuesType">
<xs:sequence>
<xs:element name="FirstValue" type="xs:int" minOccurs="1" maxOccurs="1" />
<xs:element name="SecondValue" type="xs:int" minOccurs="1" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="AddValuesResponseType">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="Result" type="xs:int" />
</xs:sequence>
</xs:complexType>
<xs:attribute name="Timestamp" type="xs:dateTime" />
<xs:element name="CalculationFailure">
<xs:complexType>
<xs:sequence>
<xs:element name="ErrorCode" type="xs:int" />
<xs:element name="Reason" type="xs:string" />
</xs:sequence>
<xs:attribute ref="tns:Timestamp" use="required" />
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
<!--
Abstract message definitions
-->
<wsdl:message name="AddValuesRequest">
<wsdl:part name="in" element="calc:AddValuesRequest" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
<wsdl:part name="out" element="calc:AddValuesResponse" />
</wsdl:message>
<wsdl:message name="CalculationFault">
<wsdl:part name="fault" element="calc:CalculationFailure" />
</wsdl:message>
<!--
Abstract portType / interface definition
-->
<wsdl:portType name="CalculatorEndpoint">
<wsdl:operation name="AddValues">
<wsdl:documentation>Adds up passed values and returns the result</wsdl:documentation>
<wsdl:input message="tns:AddValuesRequest" />
<wsdl:output message="tns:AddValuesResponse" />
<wsdl:fault name="CalculationFault" message="tns:CalculationFault" />
</wsdl:operation>
</wsdl:portType>
<!--
Concrete binding definition
-->
<wsdl:binding name="CalculatorBinding" type="tns:CalculatorEndpoint">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="AddValues">
<soap:operation soapAction="http://example.org/calculator/AddValuesMessage" />
<wsdl:input>
<soap:body parts="in" use="literal" />
</wsdl:input>
<wsdl:output>
<soap:body parts="out" use="literal" />
</wsdl:output>
<wsdl:fault name="CalculationFault">
<soap:fault name="CalculationFault" use="literal" />
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<!--
Concrete service definition
-->
<wsdl:service name="CalculatorService">
<wsdl:port name="CalculatorServicePort" binding="tns:CalculatorBinding">
<soap:address location="http://localhost:8080/services/calculator" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
एक service
अनुभाग कंक्रीट के समापन बिंदु को परिभाषित करता है जो सेवा आने वाले अनुरोधों के लिए सुनेगी। binding
सेक्शन एक ठोस शैली के लिए एक ऑपरेशन को बांधता है और परिभाषित करता है कि सर्वर कौन सा संदेश प्रारूप की उम्मीद करता है या ग्राहक उम्मीद कर सकता है।
अमूर्त खंड एक portType
ब्लॉक से बना है जो सेवा द्वारा दिए गए संचालन को परिभाषित करता है और किन संदेशों का आदान-प्रदान होता है। संदेशों को उनके ब्लॉक में निर्दिष्ट किया गया है और स्कीमा से जुड़ा हुआ है तर्कों और रिटर्न मान के उदाहरण हैं। संदेश पैरामीटर या वापसी मान घोषणा कर सकते हैं होने के लिए in
, out
या inout
। जबकि पहले दो संदर्भों द्वारा पारित तर्कों के व्यवहार की नकल करने के लिए काफी सरल हैं। जैसा कि कुछ भाषाओं में पास-बाय-रेफ का समर्थन नहीं किया जाता है, यह प्रभाव कुछ हैंडलर के माध्यम से अक्सर अनुकरण किया जाता है।
डब्लूएसडीएल २.०
एक ही कैलकुलेटर को इस तरह से WSDL 2.0 में वर्णित किया जा सकता है:
<?xml version="1.0" encoding="utf-8" ?>
<wsdl:description xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://www.w3.org/ns/wsdl"
xmlns:soap="http://www.w3.org/ns/wsdl/soap"
xmlns:calc="http://example.org/calculator"
xmlns:tns="http://example.org/calculatorService"
targetNamespace="http://example.org/calculatorService">
<!--
Abstract type definitions
-->
<wsdl:types>
<!--
<xs:schema>
<xs:import namespace="http://example.org/calculator" schemaLocation="calc/calculator.xsd" />
</xs:schema>
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://example.org/calculator"
targetNamespace="http://example.org/calculator"
elementFormDefault="qualified"
attributeFormDefault="qualified">
<xs:element name="AddValuesRequest" type="tns:AddValuesType" />
<xs:element name="AddValuesResponse" type="tns:AddValuesResponseType" />
<xs:complexType name="AddValuesType">
<xs:sequence>
<xs:element name="FirstValue" type="xs:int" minOccurs="1" maxOccurs="1" />
<xs:element name="SecondValue" type="xs:int" minOccurs="1" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="AddValuesResponseType">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="Result" type="xs:int" />
</xs:sequence>
</xs:complexType>
<xs:attribute name="Timestamp" type="xs:dateTime" />
<xs:element name="CalculationFault">
<xs:complexType>
<xs:sequence>
<xs:element name="ErrorCode" type="xs:int" />
<xs:element name="Reason" type="xs:string" />
</xs:sequence>
<xs:attribute ref="tns:Timestamp" use="required" />
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
<!--
Abstract interface
-->
<wsdl:interface name="CalculatorInterface">
<wsdl:fault name="fault" element="calc:CalculationFault" />
<wsdl:operation name="AddValues" pattern="http://www.w3.org/ns/wsdl/in-out" style="http://www.w3.org/ns/wsdl/style/iri" wsdl:safe="true">
<wsdl:documentation>Adds up passed values and returns the result</wsdl:documentation>
<wsdl:input messageLabel="in" element="calc:AddValuesRequest" />
<wsdl:output messageLabel="out" element="calc:AddValuesResponse" />
<wsdl:outfault messageLabel="fault" ref="tns:fault" />
</wsdl:operation>
</wsdl:interface>
<!--
Concrete binding definition
-->
<wsdl:binding name="CalculatorBinding" interface="tns:CalculatorInterface" type="http://www.w3.org/ns/wsdl/soap" soap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
<wsdl:operation ref="tns:AddValues" soap:mep="http://www.w3.org/2003/05/soap/mep/soap-response" />
<wsdl:fault ref="tns:fault" soap:code="soap:Sender" />
</wsdl:binding>
<!--
Concrete service definition
-->
<wsdl:service name="CalculatorService" interface="tns:CalculatorInterface">
<wsdl:endpoint name="CalculatorEndpoint" binding="tns:CalculatorBinding" address="http://localhost:8080/services/calculator" />
</wsdl:service>
</wsdl:description>
WSDL 1.1 और 2.0 के बीच अंतर
दोनों संस्करणों के बीच के अंतर पर एक चित्रमय अवलोकन नीचे दी गई तस्वीर में देखा जा सकता है।
( स्रोत )
जैसा कि छवि से देखा जा सकता है कि message
अनुभाग हटा दिया गया है जो अब interface
अनुभाग में निहित है। इसके अलावा, कुछ तत्वों का नाम बदल दिया गया है, अन्य में एक अलग वाक्यविन्यास है लेकिन सामान्य तौर पर दोनों WSDL संस्करण मूल रूप से संस्करण 2.0 के साथ एक ही है जो 1.1 की तुलना में थोड़ा कम ओवरहेड लिखने की आवश्यकता है।
WSDL 2.0 के माध्यम से SOAP आधारित सेवाओं को परिभाषित करने पर छोटे पदचिह्न के अलावा, नया संस्करण REST सेवाओं को परिभाषित करने की क्षमता भी प्रदान करता है, हालांकि WSDL 2.0 या WADL को RESTful सेवाओं के लिए अनुशंसित नहीं किया जाता है क्योंकि वे इसके पीछे वास्तविक विचार का विरोध करते हैं।
किस स्टाइल को पसंद करें
WSDL बाइंडिंग अनुभाग बताता है कि सेवा SOAP मैसेजिंग प्रोटोकॉल के लिए कैसे बाध्य है। ऊपर दिए गए document
में बाध्यकारी शैली के रूप में उपयोग किए गए document
, जो SOAP शरीर को उस तरह से संरचना करने की अनुमति देता है जिस तरह से हम चाहते हैं कि परिणामस्वरूप आउटपुट एक वैध XML उदाहरण है। यह डिफ़ॉल्ट बाइंडिंग शैली है और अक्सर Message-Oriented style
रूप में संदर्भित की जाती Message-Oriented style
।
document
शैली के विपरीत, RPC
शैली अनुरोध निकायों में ऑपरेशन नाम और विधि पैरामीटर दोनों सेट होते हैं। XML उदाहरण की संरचना इसलिए पूर्वनिर्धारित है और इसे बदला नहीं जा सकता है।
बाइंडिंग स्टाइल के अलावा बाइंडिंग सेक्शन literal
या encoded
के नाम पर SOAP संदेशों को बाइंडिंग के लिए एक अनुवाद मॉडल भी परिभाषित करता है। दोनों के बीच का अंतर यह है कि literal
मॉडल को उपयोगकर्ता द्वारा परिभाषित एक्सएसडी संरचना के अनुरूप होना चाहिए, जिसका उपयोग अनुरोधों और प्रतिक्रियाओं को मान्य करने के लिए किया जा सकता है, जबकि encoded
मॉडल में एक्सएसडी जैसे xs:integer
डेटाटिप्स का उपयोग करना होता है xs:integer
या xs:string
लेकिन बदले में इसलिए किसी भी उपयोगकर्ता परिभाषित स्कीमा के अनुरूप नहीं है। हालाँकि यह संदेश बॉडी को सत्यापित करने या XSLT के माध्यम से संदेश को अन्य प्रारूप में बदलने के लिए कठिन बनाता है।
उपयोग-मॉडल के साथ बाध्यकारी शैली का संयोजन वास्तव में 4 विभिन्न संदेश परिणामों के लिए अनुमति देता है। 5 वीं प्रविष्टि को उस सूची में जोड़ा जाता है जो आमतौर पर उपयोग की जाती है (हालांकि वास्तव में मानक का हिस्सा नहीं है)।
- RPC / एन्कोडेड
- आरपीसी / शाब्दिक
- दस्तावेज़ / एन्कोडेड
- दस्तावेज़ / शाब्दिक
- दस्तावेज़ / शाब्दिक (लिपटे)
मैसेजिंग के दस्तावेज़ / शाब्दिक शैली में, एक पैटर्न मौजूद है जिसे लिपटे-दस्तावेज़ / शाब्दिक के रूप में जाना जाता है। यह सिर्फ एक पैटर्न है, और डब्ल्यूएसडीएल विनिर्देश का हिस्सा नहीं है। इस पैटर्न में JSR 224 (JAX-WS: Java API for XML आधारित वेब सेवाओं) का उल्लेख है। ( स्रोत )
नीचे खंड डब्ल्यूएसडीएल या स्कीमा घोषणा के बारे में मतभेदों पर एक सिंहावलोकन देता है और परिणामस्वरूप एसओएपी संदेश प्रारूप पर उनके प्रभाव को या तो बाध्यकारी शैली को बदलते हैं या मॉडल परिभाषाओं का उपयोग करते हैं।
RPC / एन्कोडेड
डबल्यूएसडीएल:
...
<wsdl:message name="AddValues">
<wsdl:part name="FirstValue" type="xsd:int" />
<wsdl:part name="SecondValue" type="xsd:int" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
<wsdl:part name="Result" type="xsd:int" />
</wsdl:message>
<wsdl:portType name="CalculatorEndpoint">
<wsdl:operation="AddValues">
<wsdl:input message="AddValues" />
<wsdl:output message="AddValuesResponse" />
</wsdl:operation>
</wsdl:portType>
<!-- binding style set to 'RPC' and use to 'encoded' -->
...
SOAP अनुरोध
<soap:envelope>
<soap:body>
<AddValues>
<FirstValue xsi:type="xsd:int">1</FirstValue>
<SecondValue xsi:type="xsd:int">2</SecondValue>
</AddValues>
</soap:body>
</soap:envelope>
SOAP प्रतिक्रिया
<soap:envelope>
<soap:body>
<AddValuesResponse>
<Result xsi:type="xsd:int">3</Result>
</AddValuesResponse>
</soap:body>
</soap:envelope>
पेशेवरों
- सीधे डब्ल्यूएसडीएल
- अनुरोध और प्रतिक्रिया में उपलब्ध संचालन और तत्वों का नाम
विपक्ष
- XSI प्रकारों की स्पष्ट घोषणा
- मान्य करना कठिन है
- डब्ल्यूएस-आई का अनुपालन नहीं
आरपीसी / शाब्दिक
डबल्यूएसडीएल:
...
<wsdl:message name="AddValues">
<wsdl:part name="FirstValue" type="xsd:int" />
<wsdl:part name="SecondValue" type="xsd:int" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
<wsdl:part name="Result" type="xsd:int" />
</wsdl:message>
<wsdl:portType name="CalculatorEndpoint">
<wsdl:operation="AddValues">
<wsdl:input message="AddValues" />
<wsdl:output message="AddValuesResponse" />
</wsdl:operation>
</wsdl:portType>
<!-- binding style set to 'RPC' and use to 'literal' -->
...
SOAP अनुरोध
<soap:envelope>
<soap:body>
<AddValues>
<FirstValue>1</FirstValue>
<SecondValue>2</SecondValue>
</AddValues>
</soap:body>
</soap:envelope>
SOAP प्रतिक्रिया
<soap:envelope>
<soap:body>
<AddValuesResult>
<Result>3</Result>
</AddValuesResult>
</soap:body>
</soap:envelope>
पेशेवरों
- सीधे डब्ल्यूएसडीएल
- अनुरोध और प्रतिक्रिया में उपलब्ध संचालन और तत्वों का नाम
- कोई XSI प्रकार विनिर्देश की आवश्यकता नहीं है
- WS-I अनुपालन करता है
विपक्ष
- मान्य करना कठिन है
दस्तावेज़ / एन्कोडेड
इसलिए कोई मतलब नहीं है।
दस्तावेज़ / शाब्दिक
डबल्यूएसडीएल:
...
<types>
<schema>
<element name="FirstValueElement" type="xsd:int" />
<element name="SecondValueElement" type="xsd:int" />
<element name="ResultValueElement" type="xsd:int" />
</schema>
</types>
<wsdl:message name="AddValues">
<wsdl:part name="FirstValue" element="FirstValueElement" />
<wsdl:part name="SecondValue" element="SecondValueElement" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
<wsdl:part name="Result" element="ResultValueElement" />
</wsdl:message>
<wsdl:portType name="CalculatorEndpoint">
<wsdl:operation="AddValues">
<wsdl:input message="AddValues" />
<wsdl:output message="AddValuesResponse" />
</wsdl:operation>
</wsdl:portType>
<!-- binding style set to 'Document' and use to 'literal' -->
...
SOAP अनुरोध
<soap:envelope>
<soap:body>
<FirstValueElement>1</FirstValueElement>
<SecondValueElement>2</SecondValueElement>
</soap:body>
</soap:envelope>
SOAP प्रतिक्रिया
<soap:envelope>
<soap:body>
<ResultElement>3</ResultElement>
</soap:body>
</soap:envelope>
पेशेवरों
- कोई XSI प्रकार एन्कोडिंग नहीं
- शरीर को मान्य करने में सक्षम
- WS-I प्रतिबंधों का अनुपालन करता है
विपक्ष
- अतिरिक्त XSD परिभाषा के कारण WSDL अधिक जटिल है
- ऑपरेशन नाम खो गया है
- WS-I केवल SOAP बॉडी में एक बच्चे की अनुमति देता है
दस्तावेज़ / शाब्दिक (लिपटे)
डबल्यूएसडीएल:
...
<types>
<schema>
<element name="AddValues">
<complexType>
<sequence>
<element name="FirstValue" type="xsd:int" />
<element name="SecondValue" type="xsd:int" />
</sequence>
</complexType>
</element>
<element name="AddValuesResponse">
<complexType>
<sequence>
<element name="ResultValue" type="xsd:int" />
</sequence>
</complexType>
</element>
</schema>
</types>
<wsdl:message name="AddValues">
<wsdl:part name="in" element="AddValues" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
<wsdl:part name="out" element="AddValuesResponse" />
</wsdl:message>
<wsdl:portType name="CalculatorEndpoint">
<wsdl:operation="AddValues">
<wsdl:input message="AddValues" />
<wsdl:output message="AddValuesResponse" />
</wsdl:operation>
</wsdl:portType>
<!-- binding style set to 'Document' and use to 'literal' -->
...
SOAP अनुरोध
<soap:envelope>
<soap:body>
<AddValues>
<FirstValue>1</FirstValue>
<SecondValue>2</SecondValue>
</AddValues>
</soap:body>
</soap:envelope>
SOAP प्रतिक्रिया
<soap:envelope>
<soap:body>
<AddValuesResponse>
<Result>3</Result>
</AddValuesResponse>
</soap:body>
</soap:envelope>
पेशेवरों
- कोई XSI प्रकार एन्कोडिंग नहीं
- शरीर को मान्य करने में सक्षम
- अनुरोध और प्रतिक्रिया में उपलब्ध संचालन और तत्वों का नाम
- WS-I अनुपालन करता है
विपक्ष
- अतिरिक्त XSD परिभाषा के कारण WSDL अधिक जटिल है
UDDI
Universal Description, Discovery and Integration (UDDI)
2000 में एक खुली उद्योग पहल है जो वेब सेवाओं के लिए XML आधारित पीले-पन्नों की रजिस्ट्री के रूप में कार्य करती है जो विशिष्ट कार्यों को हल करने वाली सेवाओं को खोजने में मदद करती है। एक उपयुक्त सेवा खोजने के लिए, एक सेवा को पहले एक वेब सेवा रजिस्ट्री जैसे कि UDDI के साथ पंजीकृत होना चाहिए।
UDDI SOAP संदेश विनिमय पर काम करता है और WSDL दस्तावेजों तक पहुंच प्रदान करता है, जिसका उपयोग वास्तविक वेब सेवा को लागू करने के लिए किया जा सकता है।
UDDI लुकअप मानदंड प्रदान करता है जैसे
- व्यापार पहचानकर्ता
- व्यवास्यक नाम
- व्यवसाय का स्थान
- व्यापार वर्ग
- नाम से सेवा प्रकार
- खोज यूआरएल
हालांकि, वर्तमान यूडीडीआई का एक बड़ा नुकसान यह है कि यह केवल खोज विवरण के भीतर एक एकल मानदंड का उपयोग करने की अनुमति देता है। इसलिए कुछ कार्यान्वयनकर्ताओं ने अपने UDDI कार्यान्वयनों को एक साथ कई UDDI के प्रश्न पूछने की अनुमति देने के लिए संशोधित किया और फिर लौटे परिणामों को एकत्रित किया।
हालांकि, अक्सर यूडीडीआई का उपयोग नहीं किया जाता है। कुछ तो यहां तक कह रहे हैं कि UDDI आईबीएम के बाद से मृत है, Microsoft और SAP ने 2005 में अपनी UDDI सेवाओं को बंद कर दिया ।
आगे के नोट:
SOAP / WSDL टूलिंग समर्थन की एक विस्तृत श्रृंखला प्रदान करता है और क्लाइंट और सर्वर दोनों के लिए स्टब-क्लास को गतिशील रूप से उत्पन्न करने की भी अनुमति देता है क्योंकि संदेशों और डेटा के आदान-प्रदान के प्रकार को एम्बेडेड या लिंक किए गए XSD स्कीमाटा के माध्यम से अच्छी तरह से परिभाषित किया गया है।
हालांकि WSDL 2.0 में वेब सेवाओं को परिभाषित करने की क्षमता कम है, कुछ भाषाओं ने अभी भी नए मानक को नहीं अपनाया है। जावा में लोकप्रिय उपकरण जैसे wsimport
(Oracle / Sun से) या wsdl2java
(Apache CXF से) WSDL 2.0 विवरण को ठीक से संभालने में सक्षम नहीं हैं। इसलिए, संगतता कारणों से यह अभी भी WSDL 1.1 का उपयोग करने के लिए अनुशंसित है। यदि आपको जावा में WSDL 2.0 आधारित SOAP सेवा विकसित करने की आवश्यकता है, तो Apache Axis2 परियोजना से wsdl2java
पर एक नज़र डालें।
आजकल अधिक लोकप्रिय, हालांकि, या तो HTTP आधारित एपीआई सेवाएं हैं, जो अपने काम को पूरा करने के लिए प्रोटोकॉल के लिए HTTP मानव-चालित यूआरआई और कुछ कस्टमाइज़ेशन के साथ HTTP ऑपरेशन इनवोकेशन का मिश्रण करती हैं, REST आधारित सेवाएं, जो वास्तविक सिफारिशों का पूरी तरह से पालन करती हैं। या स्वयं बाइट स्तर के प्रोटोकॉल, जैसे कि OFTP2 ।
SOAP आजकल भी उपयोगी है यदि आप अपने कार्य को सीधे संसाधनों पर मैप नहीं कर सकते हैं, जैसे HTTP / REST आधार सेवाएँ करते हैं, जैसा कि कार्य को पूरा करना स्वाभाविक रूप से एक क्रिया को दर्शाता है या कुछ लेनदेन शब्दार्थों को परिभाषित करना है। इसके अलावा, यदि आपके पास अपने स्वयं के प्रोटोकॉल को परिभाषित या कार्यान्वित करने के लिए संसाधन नहीं हैं, तो आप शायद SOAP का उपयोग करने से बेहतर हैं SOD विशेष रूप से उपयोगी है यदि आपको ऑर्केस्ट्रेशन से निपटना है क्योंकि UDDI के साथ संयोजन में WSDL विवरण को गतिशील रूप से संयोजित करने की अनुमति देता है।
मौसम सेवा के लिए जावा क्लाइंट http://www.webserviceX.NET पर उपलब्ध वेबसर्विस उपलब्ध है
package com.test.ws.example;
import javax.xml.soap.MessageFactory;
import javax.xml.soap.MimeHeaders;
import javax.xml.soap.SOAPBody;
import javax.xml.soap.SOAPConnection;
import javax.xml.soap.SOAPConnectionFactory;
import javax.xml.soap.SOAPElement;
import javax.xml.soap.SOAPEnvelope;
import javax.xml.soap.SOAPMessage;
import javax.xml.soap.SOAPPart;
import javax.xml.transform.Source;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.stream.StreamResult;
/*
* WSDL url : http://www.webservicex.com/globalweather.asmx?WSDL
* Endpoint URL: http://www.webservicex.com/globalweather.asmx */
public class WSClient {
public static void main(String args[]) {
try {
SOAPConnectionFactory soapConnectionFactory = SOAPConnectionFactory.newInstance();
SOAPConnection soapConnection = soapConnectionFactory.createConnection();
// Generate SOAP request XML
MessageFactory messageFactory = MessageFactory.newInstance();
SOAPMessage soapMessage = messageFactory.createMessage();
MimeHeaders header = soapMessage.getMimeHeaders();
header.setHeader("SOAPAction", "http://www.webserviceX.NET/GetCitiesByCountry");
SOAPPart soapPart = soapMessage.getSOAPPart();
SOAPEnvelope envelope = soapPart.getEnvelope();
envelope.addNamespaceDeclaration("web", "http://www.webserviceX.NET");
SOAPBody soapBody = envelope.getBody();
SOAPElement soapBodyElem = soapBody.addChildElement("GetCitiesByCountry", "web");
SOAPElement soapBodyElem1 = soapBodyElem.addChildElement("CountryName", "web");
soapBodyElem1.addTextNode("INDIA");
soapMessage.saveChanges();
soapMessage.writeTo(System.out);
// Call webservice endpint
String url = "http://www.webservicex.com/globalweather.asmx";
SOAPMessage soapResponse = soapConnection.call(soapMessage, url);
Source sourceContent = soapResponse.getSOAPPart().getContent();
// Print SOAP response
TransformerFactory transformerFactory = TransformerFactory.newInstance();
Transformer transformer = transformerFactory.newTransformer();
System.out.println("Response SOAP Message \n");
StreamResult result = new StreamResult(System.out);
transformer.transform(sourceContent, result);
soapConnection.close();
} catch (Exception e) {
e.printStackTrace();
}
}
}
JAX-WS (दस्तावेज़ / शाब्दिक) के साथ एक साधारण वेब सेवा और ग्राहक बनाना
यह प्रोजेक्ट डायरेक्टरी है।
- एक सेवा समापन बिंदु इंटरफ़ेस
पहले हम एक सेवा समापन बिंदु इंटरफ़ेस बनाएंगे। Javax.jws.WebService @WebService
एनोटेशन एक वेब सेवा समापन बिंदु के रूप में वर्ग को परिभाषित करता है।
import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
import javax.jws.soap.SOAPBinding.Use;
// Service Interface with customize targetNamespace
@WebService(targetNamespace = "http://hello-soap/ws")
@SOAPBinding(style = Style.DOCUMENT, use=Use.LITERAL) //optional
public interface HelloSoap {
@WebMethod String getHelloSoap(String name);
}
- सेवा समापन बिंदु कार्यान्वयन (SEI)
आगे हम सर्विस एंडपॉइंट कार्यान्वयन बनाएंगे। हम कार्यान्वयन कक्षा में @WebService
एनोटेशन के लिए endpointInterface
तत्व जोड़कर एक स्पष्ट इंटरफ़ेस @WebService
। यहाँ कुछ नियम 28.1.1 JAX-WS समापन बिंदु की आवश्यकता है जो JAX-WS समापन बिंदुओं का पालन करना चाहिए। GetHelloSoap विधि क्लाइंट को उस नाम को पास करने के लिए शुभकामना देता है।
import javax.jws.WebService;
// Customized Service Implementation (portName,serviceName,targetNamespace are optional)
@WebService(portName = "HelloSoapPort", serviceName = "HelloSoapService",
endpointInterface = "com.wonderland.hellosoap.HelloSoap", targetNamespace = "http://hello-soap/ws")
public class HelloSoapImpl implements HelloSoap {
@Override
public String getHelloSoap(String name) {
return "[JAX-WS] Hello : " + name;
}
}
- वेब सेवा समापन बिंदु प्रकाशक
import javax.xml.ws.Endpoint;
public class HelloSoapPublisher {
public static void main(String[] args) {
// creating web service endpoint publisher
Endpoint.publish("http://localhost:9000/ws/hello-soap", new HelloSoapImpl());
}
}
- अगले चरण में, हम
HelloSoapPublisher.java
को java एप्लिकेशन के रूप मेंHelloSoapPublisher.java
। तब हम एक वेब ब्राउज़र में URLhttp://localhost:9000/ws/hello-soap?wsdl
का अनुरोध करके WSDL फ़ाइल देखेंगे।
http: // localhost: 9000 / ws / हैलो-साबुन wsdl
यदि वेब ब्राउज़र पर XML डेटा फॉर्मेट प्रदर्शित होता है, तो हम अगले चरण पर जाने के लिए तैयार हैं।
ध्यान दें:
यदि आपको किसी प्रकार का त्रुटि संदेश मिलता है, तो शायद आपको आवश्यक JAX-WS पोर्टेबल कलाकृतियों को उत्पन्न करने के लिएwsgen
टूल का उपयोग करना होगा। हम यहांwsgen
टूल के बारे में नहीं जानते हैं।
- वेब सेवा क्लाइंट
अंतिम चरण, हम एक ग्राहक बनाएंगे जो हमारी प्रकाशित सेवा तक पहुंच बनाएगा।
import java.net.URL;
import javax.xml.namespace.QName;
import javax.xml.ws.Service;
public class HelloSoapClient {
public static void main(String[] args) throws Exception {
// create wsdl url
URL wsdlDocumentUrl = new URL("http://localhost:8000/ws/hello-soap?wsdl");
QName helloSoapService = new QName("http://hello-soap/ws", "HelloSoapService");
// create web service
Service service = Service.create(wsdlDocumentUrl, helloSoapService);
// get object of pointed service port
HelloSoap helloSoap = service.getPort(HelloSoap.class);
// testing request
System.out.println(helloSoap.getHelloSoap("Soap "));
}
}
आउटपुट: [JAX-WS] Hello : Soap
नोट: हमारे वेब सेवा क्लाइंट में पोर्ट संख्या 8000
में बदल गई। इसका कारण यह है, मैंने संदेशों को ट्रेस करने के लिए ग्रहण आईडीई, बिल्ड-इन TCP/IP monitor
टूल का उपयोग किया (अधिक जानकारी: ग्रहण आईडीई में SOAP संदेश कैसे ट्रेस करें )। कार्यात्मक परीक्षण उद्देश्य के लिए SoapUI प्रयास करें | SOAP और REST API के लिए कार्यात्मक परीक्षण ।