Shulou(Shulou.com)06/02 Report--

Today, I'm going to talk to you about how to discuss the interoperability of webservice in C++, C# and JAVA. Many people may not know much about it. In order to make you understand better, the editor summarized the following. I hope you can get something from this article.

First of all, introduce C++, C# and JAVA respectively.

C++ uses gsoap. For more information on creating a webservice client server using gsoap, please see my previous essay:

>

JAVA uses axis, using axis to create webservice client and server problems, you can google some, a lot of this introduction.

C # uses the system.webserive class library.

Our goal is to require the webservice between C++, C# and JAVA to communicate normally, that is, to receive a string sent by the client, and the server returns a string to the client.

To ensure normal communication with each other, we must first make clear the SOAP protocol adopted by webservice.

According to the information on the Internet:

The style attribute can be divided into rpc document,rpc document and the differences are as follows:

* RPC style

The RPC style specifies that the element contains the name of a web method that will be called (wrapper element (wrapper element)). This element records each parameter of the method and the return value in turn.

* Document style

If it is the document style, there is no wrapper element like in the RPC style. Instead, the message fragment appears directly in the

Under the element There is no SOAP formatting rule that specifies what can be contained under an element; it contains an XML document that both the sender and receiver agree on.

'The Use' property. This is related to how the various types are displayed in XML, which specifies whether to encode the message fragment using some coding rule or to define the fragment using the specific schema of the message. Here are two options:

* encoded

If the value of use is "encoded", each message fragment uses the type attribute to refer to the abstract type. These abstract types can be used to generate concrete messages by applying the encoding style specified by the encodingStyle property. The most commonly used SOAP encoding style is a set of serialization rules defined in SOAP1.1 that describes how objects, structures, arrays, and graphical objects should be serialized. In general, the use of SOAP encoding in an application focuses on remote process calls and the RPC message style is suitable for later use.

* Literal

If the value of use is "Literal", each fragment uses the element attribute (for simple fragments) or the type attribute (for composite fragments) to refer to a specific schema, for example, data is serialized according to the specified schema, which is usually represented by the W3C XML schema.

I have found a lot of information about this, but it is still very difficult to understand. It is very simple to take it literally, but when it comes to the actual operation, it is difficult to understand the similarities and differences according to the wsdl generated in various ways. Because soap messages that follow document format look a lot like rpc format. And for simple objects such as int string, there seems to be no obvious similarities and differences, so in my testing process, it has been relatively vague. I also use the comview,iris packet capture tool to capture the packets sent between them, which is helpful to the problem analysis.

I test with gsoap as the main line, so after the test is completed, I have doubts about my test results. I feel that I don't have a thorough understanding of the differences between gsoap's rpc docment encoded literal. This is how I define it:

Document/literal mode:

/ / gsoap ns service name: EASReceive / / gsoap ns service location: http://services.xmethods.net/soap / / gsoap ns service namespace: http://tempuri.org/ gsoap ns service style: document / / gsoap ns service encoding: literal / / gsoap ns service method-action: EASReceive "typedef char * xsd__string; int ns__EASReceive (xsd__string strSubmitData, xsd__string * strPxFormData)

Rpc/encoded mode:

/ / content of "OAMethod.h": / / gsoap ns service name: EASReceive / / gsoap ns service location: http://services.xmethods.net/soap / / gsoap ns service namespace: http://tempuri.org/ gsoap ns service style: rpc / / gsoap ns service encoding: encoded / / gsoap ns service method-action: EASReceive "" int ns__EASReceive (char* strSubmitData, char** strPxFormData)

But I found that there was no difference in the generated wsdl except that the value of the style use attribute was different, and by the way, I added the soap2cpp.exe-e option in encoded (with or without both tested).

The client of C # has been tested in many ways, and only using

[System.Web.Services.Protocols.SoapRpcMethodAttribute ("http://tempuri.org/EASReceive", RequestNamespace =" http://tempuri.org/", Resp, Use = System.Web.Services.Description.SoapBindingUse.Literal)]

Or

[System.Web.Services.Protocols.SoapRpcMethodAttribute ("http://tempuri.org/EASReceive", RequestNamespace =" http://tempuri.org/", Resp, Use = System.Web.Services.Description.SoapBindingUse.encoded)]

I can get through.

However, there is only one way for the server of C# to communicate:

[WebMethod] [SoapRpcMethod (Action = "http://tempuri.org/EASReceive", RequestNamespace =" http://tempuri.org/", Resp, Use = System.Web.Services.Description.SoapBindingUse.Literal)] / / encoded is not allowed [return: XmlElement ("strPxFormData", IsNullable = false)]

Also tested with the wsdl automatic generation tool of C#, according to the wsdl file generated by gsoap, the automatically generated code can not communicate with gsoap normally. I always do not understand, according to reason, as long as the coding mode is consistent, you can communicate. I wonder if there is a problem with my c # side code? When searching the information on the C # side on the Internet, it is found that the C # side is very flexible to the custom xml file scheme in webservice, and the xml node for transmission can be customized at will, so the key problem is that the format must be consistent with each other, so that after receiving the soap message, both sides can correctly parse the xml. After repeated debugging, it is finally turned on, all in the way of rpc/literal. However, there is no problem with the communication between JAVA and gsoap. As long as the coding is unified, we can communicate with each other. Therefore, based on the "limitations" of C# found in the test, we are unified into rpc/literal.

JAVA client code:

String endpoint = "http://192.168.8.94/csharp_demo/Service1.asmx"; Service service = new Service (); Call call = (Call) service.createCall (); call.setTargetEndpointAddress (new java.net.URL (endpoint)); call.setUseSOAPAction (true); String soapActi; call.setSOAPActionURI (soapActionURI); call.setOperationStyle (org.apache.axis.constants.Style.RPC) Call.setOperationUse (org.apache.axis.constants.Use.LITERAL); String strSubmitData = new String ("yes or noisy premises?"); call.setOperationName ("http://tempuri.org/","EASReceive")); call.addParameter (" strSubmitData ", org.apache.axis.encoding.XMLType.XSD_STRING,javax.xml.rpc.ParameterMode.IN)) / / call.addParameter (new QName ("http://tempuri.org/","strSubmitData"), org.apache.axis.encoding.XMLType.XSD_STRING, javax.xml.rpc.ParameterMode.IN); call.setReturnType (XMLType.XSD_STRING); / / oper.setElementQName (new QName (" http://tempuri.org/","EASReceive")); / / call.setOperation (oper)) String ret = (String) call.invoke (new Object [] {strSubmitData}); System.out.println ("Get result:" + ret)

JAVA server code: brief

Welcome to discuss together. I feel that there are still many problems. Although the communication is normal now, in fact, my mind is still confused, hehe!

There are two solutions to the problem that soapAction must be required on the C # side:

1. The following code is added to the C# server, but the test found that it does not work after being deployed to IIS, and the specific reason is unknown.

[SoapRpcService (RoutingStyle = SoapServiceRoutingStyle.RequestElement)] / / setting does not need to assign soapAction but does not work when deployed to iis / / [SoapDocumentService (RoutingStyle = SoapServiceRoutingStyle.RequestElement)]

2. Add soapAction,gsoap client to the client and pass soapAction into it.

There is also a thorny problem, that is, the problem of garbled codes in Chinese. Oh, it is tricky because if it is not clear, it is really tricky, in fact, it is also very simple to solve, that is, to ensure the consistency of communication codes. The same communication code here has two meanings:

1. The transmission code between webservice is guaranteed to add soap_set_mode (s.soap, SOAP_C_UTFSTRING) to UTF8,gsoap. The java,c# side is transmitted with utf8 by default.

2. Character coding of parameters before transmission

After reading the above, do you have any further understanding of how to discuss webservice interoperability in C++, C# and JAVA? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.