SOAP-to-REST का उपयोग करके माइग्रेशन और इंटीग्रेशन को सरल बनाना

Jinhua Luo

March 31, 2023

Technology

1. वेब सेवा क्या है?

वेब सेवा को वर्ल्ड वाइड वेब कंसोर्टियम (W3C) द्वारा एक सॉफ्टवेयर सिस्टम के रूप में परिभाषित किया गया है जो नेटवर्क पर इंटरऑपरेबल मशीन-टू-मशीन इंटरैक्शन को सपोर्ट करने के लिए डिज़ाइन किया गया है।

एक वेब सेवा विशिष्ट कार्यों या कार्यों के एक सेट को पूरा करती है और इसे वेब सेवाओं विवरण भाषा (WSDL) नामक एक मानक XML प्रतिनिधित्व द्वारा वर्णित किया जाता है। सेवा विवरण सेवा के साथ इंटरैक्ट करने के लिए सभी आवश्यक विवरण प्रदान करता है, जिसमें संदेश प्रारूप (जो ऑपरेशन्स को विस्तार से वर्णित करते हैं), ट्रांसपोर्ट प्रोटोकॉल और स्थान शामिल हैं।

अन्य सिस्टम SOAP संदेशों का उपयोग करके वेब सेवा के साथ इंटरैक्ट करेंगे, आमतौर पर HTTP के साथ XML सीरियलाइज़ेशन और अन्य वेब-संबंधित मानकों का उपयोग करके।

वेब सेवा का आर्किटेक्चर डायग्राम (ध्यान दें कि सेवा ब्रोकर वैकल्पिक है) है:

वेब सेवाओं का आर्किटेक्चर

*छवि स्रोत (CC 3.0 BY-SA लाइसेंस के तहत): https://en.wikipedia.org/wiki/Web_service

WSDL इंटरफ़ेस सेवा के कार्यान्वयन के बारे में विस्तृत जानकारी को छुपाता है ताकि सेवा का उपयोग उस हार्डवेयर या सॉफ्टवेयर प्लेटफॉर्म से स्वतंत्र हो जो सेवा को कार्यान्वित करता है, साथ ही उस प्रोग्रामिंग भाषा से भी जिसका उपयोग सेवा को लिखने के लिए किया गया है।

वेब सेवाओं पर आधारित एप्लिकेशन ढीले युग्मित, घटक-उन्मुख और क्रॉस-टेक्नोलॉजी कार्यान्वयन हैं। वेब सेवाओं का उपयोग व्यक्तिगत रूप से या अन्य वेब सेवाओं के साथ जटिल समूहीकरण या व्यावसायिक लेनदेन करने के लिए किया जा सकता है।

वेब सेवाएं सर्विस-ओरिएंटेड आर्किटेक्चर (SOA) के कार्यान्वयन इकाइयां हैं, जो मोनोलिथिक सिस्टम को बदलने के लिए उपयोग की जाने वाली एक डिज़ाइन विधि है। एक व्यापक सिस्टम को कई वेब सेवाओं में विभाजित किया जा सकता है, जिन्हें फिर एक बड़े ब्लैक बॉक्स में संयोजित किया जा सकता है ताकि बाहरी रूप से व्यावसायिक तर्क प्रदान किया जा सके। लोकप्रिय कंटेनर-आधारित माइक्रोसर्विसेज, वेब सेवाओं का नवीनतम प्रतिस्थापन हैं। हालांकि, कई पुराने सिस्टम पहले से ही वेब सेवाओं पर आधारित हैं और उन्हें कार्यान्वित और संचालित किया जा रहा है, इसलिए तकनीकी विकास के तेजी से होने के बावजूद इन सिस्टम के साथ संगतता बनाए रखना एक चुनौती बनी हुई है।

WSDL (वेब सेवाओं विवरण भाषा)

WSDL एक XML नोटेशन है जिसका उपयोग वेब सेवाओं को वर्णित करने के लिए किया जाता है। WSDL परिभाषा क्लाइंट्स को यह निर्देश देती है कि वेब सेवा अनुरोध कैसे लिखें और वेब सेवा प्रदाता द्वारा प्रदान किए गए इंटरफ़ेस को परिभाषित करती है।

WSDL परिभाषा को कई भागों में विभाजित किया गया है, जो वेब सेवा के लॉजिकल इंटरफ़ेस और भौतिक विवरण को निर्दिष्ट करते हैं। भौतिक विवरण में एंडपॉइंट जानकारी, जैसे HTTP पोर्ट नंबर, साथ ही बाइंडिंग जानकारी शामिल होती है जो यह निर्दिष्ट करती है कि SOAP संदेश सामग्री को कैसे प्रस्तुत किया जाए और किस ट्रांसपोर्ट विधि का उपयोग किया जाए।

WSDL 1.1 और WSDL 2.0 दस्तावेज़ों द्वारा परिभाषित अवधारणाओं का प्रतिनिधित्व।

छवि स्रोत (CC 3.0 BY-SA लाइसेंस के तहत): https://en.wikipedia.org/wiki/Web_Services_Description_Language

  • एक WSDL फ़ाइल में कई सेवाएं हो सकती हैं।
  • एक सेवा में कई पोर्ट हो सकते हैं।
  • एक पोर्ट एक URL पता परिभाषित करता है (जो प्रत्येक पोर्ट के लिए अलग हो सकता है) और इसमें कई ऑपरेशन हो सकते हैं।
  • प्रत्येक ऑपरेशन में एक इनपुट प्रकार और एक आउटपुट प्रकार शामिल होता है।
  • प्रकार संदेश संरचना को परिभाषित करते हैं, जिसमें यह शामिल होता है कि कौन से फ़ील्ड संदेश को बनाते हैं, प्रत्येक फ़ील्ड का डेटा प्रकार (जो नेस्टेड हो सकता है), और अनुमत फ़ील्ड की संख्या।

1.1 SOAP क्या है

SOAP एक XML संदेश प्रारूप है जिसका उपयोग वेब सेवा इंटरैक्शन में किया जाता है। SOAP संदेश आमतौर पर HTTP या JMS के माध्यम से भेजे जाते हैं, लेकिन अन्य ट्रांसपोर्ट प्रोटोकॉल का भी उपयोग किया जा सकता है। WSDL परिभाषा एक विशिष्ट वेब सेवा में SOAP के उपयोग का वर्णन करती है।

SOAP के दो सामान्य रूप से उपयोग किए जाने वाले संस्करण हैं: SOAP 1.1 और SOAP 1.2।

SOAP संरचना

छवि स्रोत (CC 3.0 BY-SA लाइसेंस के तहत): https://en.wikipedia.org/wiki/SOAP

एक SOAP संदेश में निम्नलिखित भाग होते हैं:

  • हेडर मेटाडेटा, जो आमतौर पर खाली होता है
  • बॉडी
    • WSDL में परिभाषित संदेश प्रकार
    • सफल प्रतिक्रियाओं के अलावा, प्रतिक्रिया प्रकारों के लिए संरचित त्रुटि संदेश भी होते हैं।

उदाहरण के लिए:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header></SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <ns2:getCountryResponse xmlns:ns2="http://spring.io/guides/gs-producing-web-service">
      <ns2:country>
        <ns2:name>Spain</ns2:name>
        <ns2:population>46704314</ns2:population>
        <ns2:capital>Madrid</ns2:capital>
        <ns2:currency>EUR</ns2:currency>
      </ns2:country>
    </ns2:getCountryResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

1.2 REST क्या है

एक वेब सेवा एक अमूर्त अवधारणा है जिसे किसी भी तरीके से कार्यान्वित किया जा सकता है; उदाहरण के लिए, REST एक लोकप्रिय कार्यान्वयन विधि है।

REST, जो रिप्रेजेंटेशनल स्टेट ट्रांसफर के लिए संक्षिप्त है, का शाब्दिक अर्थ है प्रस्तुति परत की स्थिति स्थानांतरण। रॉय थॉमस फील्डिंग ने 2000 में अपने डॉक्टरेट शोध प्रबंध में REST शब्द का प्रस्ताव रखा। उस समय, इंटरनेट का तेजी से विकास हो रहा था, और सॉफ्टवेयर विकास और नेटवर्क के साथ इंटरैक्शन के लिए एक व्यावहारिक परिभाषा की आवश्यकता थी।

लंबे समय तक, सॉफ्टवेयर शोध मुख्य रूप से सॉफ्टवेयर डिज़ाइन के वर्गीकरण और डिज़ाइन विधियों के विकास पर केंद्रित रहा है। यह शायद ही कभी विभिन्न डिज़ाइन विकल्पों के सिस्टम व्यवहार पर प्रभाव का वस्तुनिष्ठ मूल्यांकन करता है। दूसरी ओर, नेटवर्क शोध मुख्य रूप से सिस्टम के बीच संचार व्यवहार के विवरण और विशिष्ट संचार तंत्र के प्रदर्शन को सुधारने पर केंद्रित होता है, अक्सर यह अनदेखा करते हुए कि एप्लिकेशन की इंटरैक्शन शैली को बदलने का समग्र प्रदर्शन पर संचार प्रोटोकॉल को बदलने की तुलना में अधिक प्रभाव होता है। मेरा लेख नेटवर्क-आधारित एप्लिकेशन सॉफ्टवेयर के आर्किटेक्चर डिज़ाइन को समझने और मूल्यांकन करने का उद्देश्य रखता है जो कार्यात्मक है, अच्छा प्रदर्शन करता है और संचार के लिए उपयुक्त है, साथ ही आर्किटेक्चर सिद्धांतों का पालन करता है।

एक वेबसाइट तक पहुंचना क्लाइंट और सर्वर के बीच एक इंटरैक्शन प्रक्रिया का प्रतिनिधित्व करता है। इस प्रक्रिया के दौरान, डेटा और स्थिति में परिवर्तन होना चाहिए। HTTP प्रोटोकॉल स्टेटलेस है, जिसका अर्थ है कि सभी स्थितियां सर्वर साइड पर संग्रहीत होती हैं। इसलिए, यदि क्लाइंट सर्वर को संचालित करना चाहता है, तो उसे सर्वर साइड पर "स्थिति स्थानांतरण" करने के लिए कुछ साधनों का उपयोग करना होगा। चूंकि यह स्थानांतरण प्रस्तुति परत पर बनाया गया है, इसे "प्रस्तुति परत स्थिति स्थानांतरण" कहा जाता है।

REST के चार मूल सिद्धांत हैं:

  1. HTTP क्रियाओं का उपयोग करें: GET, POST, PUT, DELETE;
  2. स्टेटलेस कनेक्शन, सर्वर को बहुत अधिक संदर्भ स्थिति संग्रहीत नहीं करनी चाहिए; यानी, प्रत्येक अनुरोध स्वतंत्र होता है;
  3. प्रत्येक संसाधन के लिए एक URI सेट करें;
  4. डेटा प्रारूप के रूप में x-www-form-urlencoded या JSON का उपयोग करें;

SOAP को REST में बदलने से उपयोगकर्ताओं को पारंपरिक वेब सेवाओं को RESTful तरीके से एक्सेस करने में सुविधा होती है, जिससे SOAP क्लाइंट के विकास लागत कम होती है। इसके अलावा, यदि यह किसी भी वेब सेवा के लिए डायनामिक रूप से अनुकूल हो सकता है और शून्य-कोड विकास के साथ, यह और भी बेहतर होगा।

REST का सबसे बड़ा लाभ यह है कि इसमें कोई स्कीमा नहीं है, जिससे विकास करना सुविधाजनक होता है, और JSON में उच्च पठनीयता और कम अतिरिक्तता होती है।

2. SOAP-to-REST प्रॉक्सी के पारंपरिक कार्यान्वयन

2.1 मैनुअल टेम्पलेट रूपांतरण

इस दृष्टिकोण के लिए वेब सेवा के प्रत्येक ऑपरेशन के लिए अनुरोध और प्रतिक्रिया के लिए रूपांतरण टेम्पलेट प्रदान करने की आवश्यकता होती है, जो कई अन्य गेटवे उत्पादों द्वारा भी उपयोग किया जाता है।

हम APISIX बॉडी ट्रांसफॉर्मर प्लगइन का उपयोग करके एक सरल SOAP-to-REST प्रॉक्सी बना सकते हैं और इस दृष्टिकोण को आज़मा सकते हैं।

उदाहरण के लिए, हम WSDL फ़ाइल में CountriesPortService के getCountry ऑपरेशन के लिए प्रकार परिभाषा के आधार पर एक XML प्रारूपित अनुरोध टेम्पलेट बनाते हैं।

यहां, हम JSON में नाम फ़ील्ड को getCountryRequest में नाम फ़ील्ड में भरते हैं।

req_template=$(cat <<EOF | awk '{gsub(/"/,"\\\"");};1' | awk '{$1=$1};1' | tr -d '\r\n'
<?xml version="1.0"?>
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
 <soap-env:Body>
  <ns0:getCountryRequest xmlns:ns0="http://spring.io/guides/gs-producing-web-service">
   <ns0:name>{{_escape_xml(name)}}</ns0:name>
  </ns0:getCountryRequest>
 </soap-env:Body>
</soap-env:Envelope>
EOF
)

प्रतिक्रिया के लिए एक XML-to-JSON टेम्पलेट प्रदान करने की आवश्यकता होती है, जो थोड़ा अधिक जटिल हो सकता है (विशेषकर यदि SOAP संस्करण अंतरों को ध्यान में रखना हो)। ऐसा इसलिए है क्योंकि यह निर्धारित करना होगा कि प्रतिक्रिया सफल थी या नहीं:

  • सफल प्रतिक्रिया के लिए, फ़ील्ड्स को सीधे JSON में मैप किया जा सकता है।
  • विफल प्रतिक्रिया (यानी, एक फॉल्ट) के लिए, एक अलग JSON संरचना की आवश्यकता होती है, और यह निर्धारित करना होगा कि विशिष्ट वैकल्पिक फ़ील्ड्स मौजूद हैं या नहीं।
rsp_template=$(cat <<EOF | awk '{gsub(/"/,"\\\"");};1' | awk '{$1=$1};1' | tr -d '\r\n'
{% if Envelope.Body.Fault == nil then %}
{
   "currency":"{{Envelope.Body.getCountryResponse.country.currency}}",
   "population":{{Envelope.Body.getCountryResponse.country.population}},
   "capital":"{{Envelope.Body.getCountryResponse.country.capital}}",
   "name":"{{Envelope.Body.getCountryResponse.country.name}}"
}
{% else %}
{
   "message":{*_escape_json(Envelope.Body.Fault.faultstring[1])*},
   "code":"{{Envelope.Body.Fault.faultcode}}"
   {% if Envelope.Body.Fault.faultactor ~= nil then %}
   , "actor":"{{Envelope.Body.Fault.faultactor}}"
   {% end %}
}
{% end %}
EOF
)

APISIX रूटिंग कॉन्फ़िगर करें और परीक्षण करें:

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
    -H 'X-API-KEY: xxx' -X PUT -d '
{
    "methods": ["POST"],
    "uri": "/ws/getCountry",
    "plugins": {
        "body-transformer": {
            "request": {
                "template": "'"$req_template"'"
            },
            "response": {
                "template": "'"$rsp_template"'"
            }
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "localhost:8080": 1
        }
    }
}'
curl -s http://127.0.0.1:9080/ws/getCountry \
    -H 'content-type: application/json' \
    -X POST -d '{"name": "Spain"}' | jq
{
  "currency": "EUR",
  "population": 46704314,
  "capital": "Madrid",
  "name": "Spain"
}
# फॉल्ट प्रतिक्रिया
{
  "message": "Your name is required.",
  "code": "SOAP-ENV:Server"
}

जैसा कि हम देख सकते हैं, इस विधि के लिए WSDL फ़ाइल में प्रत्येक ऑपरेशन की परिभाषा और प्रत्येक ऑपरेशन के लिए संबंधित वेब सेवा पते को मैन्युअल रूप से समझने की आवश्यकता होती है। यदि WSDL फ़ाइल बड़ी है, इसमें बड़ी संख्या में ऑपरेशन हैं, और जटिल नेस्टेड प्रकार परिभाषाएं हैं, तो यह दृष्टिकोण बहुत कठिन, डीबग करने में मुश्किल और त्रुटि-प्रवण हो सकता है।

2.2 Apache Camel

https://camel.apache.org/

Camel एक प्रसिद्ध Java इंटीग्रेशन फ्रेमवर्क है जिसका उपयोग विभिन्न प्रोटोकॉल और व्यावसायिक तर्क को परिवर्तित करने वाले रूटिंग पाइपलाइन को कार्यान्वित करने के लिए किया जाता है, और SOAP-to-REST इसके उपयोग के मामलों में से एक है।

Camel का उपयोग करने के लिए WSDL फ़ाइल को डाउनलोड और आयात करने, SOAP क्लाइंट के लिए स्टब कोड जेनरेट करने और Java कोड लिखने की आवश्यकता होती है:

  • REST एंडपॉइंट्स को परिभाषित करना
  • प्रोटोकॉल रूपांतरण रूट्स को परिभाषित करना, जैसे कि JSON फ़ील्ड्स को SOAP फ़ील्ड्स में कैसे मैप किया जाए

एक उदाहरण के रूप में, आइए तापमान इकाई रूपांतरण के लिए एक वेब सेवा पर विचार करें:

https://apps.learnwebservices.com/services/tempconverter?wsdl

  1. Maven का उपयोग करके WSDL फ़ाइल के आधार पर SOAP क्लाइंट कोड जेनरेट करें।

cxf-codegen-plugin हमारे लिए SOAP क्लाइंट एंडपॉइंट्स जेनरेट करेगा ताकि हम वेब सेवा तक पहुंच सकें।

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.cxf</groupId>
      <artifactId>cxf-codegen-plugin</artifactId>
      <executions>
        <execution>
          <id>generate-sources</id>
          <phase>generate-sources</phase>
          <configuration>
            <wsdlOptions>
              <wsdlOption>
                <wsdl>src/main/resources/TempConverter.wsdl</wsdl>
              </wsdlOption>
            </wsdlOptions>
          </configuration>
          <goals>
            <goal>wsdl2java</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>
  1. SOAP क्लाइंट बीन लिखें।

ध्यान दें कि हम बीन का नाम cxfConvertTemp रखते हैं, जिसका उपयोग बाद में Camel रूट्स को परिभाषित करते समय किया जाएगा।

import com.learnwebservices.services.tempconverter.TempConverterEndpoint;
@Configuration
public class CxfBeans {
    @Value("${endpoint.wsdl}")
    private String SOAP_URL;
    @Bean(name = "cxfConvertTemp")
    public CxfEndpoint buildCxfEndpoint() {
        CxfEndpoint cxf = new CxfEndpoint();
        cxf.setAddress(SOAP_URL);
        cxf.setServiceClass(TempConverterEndpoint.class);
        return cxf;
    }
}
  1. पहले डाउनस्ट्रीम REST रूट लिखें।

इस रूट से, हम देख सकते हैं कि यह RESTFul-शैली के URL और उनके पैरामीटर परिभाषाओं को परिभाषित करता है और प्रत्येक URL के लिए अगले हॉप रूट को परिभाषित करता है। उदाहरण के लिए, /convert/celsius/to/fahrenheit/{num} URL के अंतिम भाग को एक पैरामीटर (डबल प्रकार) के रूप में लेता है और इसे अगले हॉप रूट direct:celsius-to-fahrenheit को प्रदान करता है।

rest("/convert")
    .get("/celsius/to/fahrenheit/{num}")
    .consumes("text/plain").produces("text/plain")
    .description("Convert a temperature in Celsius to Fahrenheit")
    .param().name("num").type(RestParamType.path).description("Temperature in Celsius").dataType("int").endParam()
    .to("direct:celsius-to-fahrenheit");
  1. अंत में, अपस्ट्रीम SOAP रूट और अपस्ट्रीम और डाउनस्ट्रीम के बीच रूपांतरण लिखें।
from("direct:celsius-to-fahrenheit")
    .removeHeaders("CamelHttp*")
    .process(new Processor() {
        @Override
        public void process(Exchange exchange) throws Exception {
            // SOAP अनुरोध को इनिशियलाइज़ करें
            // डाउनस्ट्रीम पैरामीटर num को बॉडी में भरें, जो एक सरल डबल प्रकार है।
            CelsiusToFahrenheitRequest c = new CelsiusToFahrenheitRequest();
            c.setTemperatureInCelsius(Double.valueOf(exchange.getIn().getHeader("num").toString()));
            exchange.getIn().setBody(c);
        }
    })
    // SOAP ऑपरेशन और नेमस्पेस निर्दिष्ट करें
    // application.properties फ़ाइल में परिभाषित
    .setHeader(CxfConstants.OPERATION_NAME, constant("{{endpoint.operation.celsius.to.fahrenheit}}"))
    .setHeader(CxfConstants.OPERATION_NAMESPACE, constant("{{endpoint.namespace}}"))
    // WSDL द्वारा जेनरेट किए गए SOAP क्लाइंट बीन का उपयोग करके पैकेज भेजें।
    .to("cxf:bean:cxfConvertTemp")
    .process(new Processor() {
        @Override
        public void process(Exchange exchange) throws Exception {
            // SOAP प्रतिक्रिया को संभालें
            // बॉडी, जो एक डबल प्रकार का मान है, को स्ट्रिंग में भरें
            // स्ट्रिंग को डाउनस्ट्रीम को वापस करें
            MessageContentsList response = (MessageContentsList) exchange.getIn().getBody();
            CelsiusToFahrenheitResponse r = (CelsiusToFahrenheitResponse) response.get(0);
            exchange.getIn().setBody("Temp in Farenheit: " + r.getTemperatureInFahrenheit());
        }
    })
    .to("mock:output");
  1. परीक्षण
curl localhost:9090/convert/celsius/to/fahrenheit/50
Temp in Farenheit: 122.0

जैसा कि हम देख सकते हैं, Camel का उपयोग करके SOAP-to-REST के लिए सभी ऑपरेशन्स के लिए रूट्स और रूपांतरण तर्क को Java कोड में परिभाषित करने की आवश्यकता होती है, जिससे विकास लागत आती है।

इसी तरह, यदि WSDL में कई सेवाएं और ऑपरेशन हैं, तो Camel का उपयोग करके प्रॉक्सी करना भी कठिन हो सकता है।

2.3 निष्कर्ष

आइए पारंपरिक विधियों के नुकसानों को संक्षेप में प्रस्तुत करें।

मॉड्यूलCamel
WSDLमैन्युअल पार्सिंगMaven द्वारा कोड जेनरेशन
अपस्ट्रीममैन्युअल पार्सिंगस्वचालित रूपांतरण
बॉडी को परिभाषित करेंनिर्णय और रूपांतरण के लिए टेम्पलेट प्रदान करेंरूपांतरण कोड लिखें
पैरामीटर प्राप्त करेंNginx वेरिएबल्सकोड में परिभाषित करें या SOAP क्लाइंट इंटरफ़ेस को कॉल करके प्राप्त करें

इन दोनों दृष्टिकोणों में विकास लागत होती है, और हर नई वेब सेवा के लिए, इस विकास लागत को दोहराना होगा।

विकास लागत वेब सेवा की जटिलता के समानुपाती होती है।

3. APISIX का SOAP-to-REST प्रॉक्सी

पारंपरिक प्रॉक्सी दृष्टिकोण या तो रूपांतरण टेम्पलेट प्रदान करने या रूपांतरण कोड लिखने की आवश्यकता होती है, दोनों ही उपयोगकर्ताओं को WSDL फ़ाइलों का गहराई से विश्लेषण करने और महत्वपूर्ण विकास लागत लगाने की आवश्यकता होती है।

APISIX एक स्वचालित दृष्टिकोण प्रदान करता है जो स्वचालित रूप से WSDL फ़ाइलों का विश्लेषण करता है और प्रत्येक ऑपरेशन के लिए रूपांतरण तर्क प्रदान करता है, जिससे उपयोगकर्ताओं के लिए विकास लागत समाप्त हो जाती है।

यह एक एंटरप्राइज़ प्लगइन है, हमसे संपर्क करें अधिक जानकारी के लिए।

APISIX SOAP-to-REST प्रॉक्सी

3.1 कोडलेस स्वचालित रूपांतरण

APISIX SOAP प्रॉक्सी का उपयोग करके:

  • WSDL फ़ाइलों को मैन्युअल रूप से पार्स या आयात करने की आवश्यकता नहीं है
  • रूपांतरण टेम्पलेट्स को परिभाषित करने की आवश्यकता नहीं है
  • किसी भी रूपांतरण या युग्मन कोड को लिखने की आवश्यकता नहीं है।

उपयोगकर्ताओं को केवल WSDL का URL कॉन्फ़िगर करने की आवश्यकता होती है, और APISIX स्वचालित रूप से रूपांतरण करेगा। यह किसी भी वेब सेवा के लिए उपयुक्त है, एक सामान्य प्रोग्राम है, और विशिष्ट आवश्यकताओं के लिए द्वितीयक विकास की आवश्यकता नहीं है।

3.2 डायनामिक कॉन्फ़िगरेशन

  • WSDL URL को किसी भी रूट से बाइंड किया जा सकता है और, अन
Tags:
APISIX Basics
SOAP-to-REST
Proxy