C++,C#,JAVA之间webservice互操作问题探讨

2024-01-23 06:18

本文主要是介绍C++,C#,JAVA之间webservice互操作问题探讨,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

http://www.cppblog.com/qiujian5628/archive/2008/09/16/61945.html

 

首先声明:我只是一个C++程序员,对C#,JAVA都是一知半解,因此整篇文章我是以gsoap的webservice为主线,如果有不对之处,还请大家指正,互相探讨!

c++用的是gsoap,关于使用gsoap创建webservice的客户端服务端问题,可以参见我以前的随笔:<<gsoap使用心得>>
JAVA用的是axis,用axis创建webservice的客户端和服务端的问题,可以google一番,很多这方面的介绍。
C#用的是system.webserive这个类库。

我们的目标是要求这三者之间的webservice互相通讯正常,即能收到客户端发过来的一串字符串,服务器端返回给客户端一段字符串。
要保证互相通讯正常,则必须首先明确webservice的采用的SOAP协议。
根据网上的资料:

style属性可分为rpc document,rpc document之间的区别为:

    * RPC 样式

RPC样式指定 元素包含一个将被调用的web方法的名称的元素(wrapper element(封装元素))。这个元素依次为该方法的每个参数还有返回值作了记录。

    * Document 样式

如果是document 样式,就没有像在RPC样式中的wrapper元素。转而代之的是消息片断直接出现在< SPAN>> 元素之下。没有任何SOAP格式化规则规定元素下能包含什么;它包含的是一个发送者和接收者都达成一致的XML文档。


‘Use’ 属性。这与各种类型如何在XML中显示有关,它指定使用某种编码规则对消息片段进行编码,还是使用消息的具体架构来定义片段。如下就是提供的两种选择:

    * encoded

如果use的值是”encoded”, 则每个消息片段将使用类型属性来引用抽象类型。通过应用由 encodingStyle 属性所指定的编码样式,可使用这些抽象类型生成具体的消息。最常用到的SOAP编码样式是在SOAP1.1中定义的一组序列化规则,它说明了对象、结构、数组和图形对象应该如何序列化。通常,在应用程序中使用SOAP编码着重于远程进程调用和以后适合使用RPC消息样式。

    * Literal

如果use 的值是”Literal”, 则每个片段使用 element 属性(对于简单片段)或 type 属性(对于复合片段)来引用具体架构,例如,数据根据指定的架构来序列化,这架构通常使用W3C XML架构来表述。

我找了很多这方面的资料,但是具体理解起来还是很困难。单从字面取理解其实很简单,但是联系到实际操作中,根据各种方式生成的wsdl来看,却很难理解其中的异同。因为遵循document格式的soap消息看上去很像rpc格式。而且对于简单对象如int string等类型来说,好像并未有十分明显的异同,因此在我测试过程中,一直都是比较模糊的。我也采用了comview,iris抓包工具,抓获它们之间发送的数据包,对问题分析还是有所帮助的。

我是以gsoap为主线进行测试的,因此在测试完成后,对自己的测试结果持有怀疑,我感觉是自己对gsoap的rpc docment encoded literal之间的差异并没有理解透彻,我是这么定义的:
document/literal方式:
//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方式:
//"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); 

可我发现生成的wsdl中除了style use属性值不一样外,并没有其它什么区别,对了在encoded中我还加了soap2cpp.exe -e选项(加与不加都测试过)。

C#的客户端多种方式都测试过,经测试只有采用
    [System.Web.Services.Protocols.SoapRpcMethodAttribute(
        "http://tempuri.org/EASReceive",
        RequestNamespace = "http://tempuri.org/",
        ResponseNamespace = "http://tempuri.org/",
        Use = System.Web.Services.Description.SoapBindingUse.Literal)]

    [System.Web.Services.Protocols.SoapRpcMethodAttribute(
        "http://tempuri.org/EASReceive",
        RequestNamespace = "http://tempuri.org/",
        ResponseNamespace = "http://tempuri.org/",
        Use = System.Web.Services.Description.SoapBindingUse.encoded)]
可以调通。

C#的服务端却只有一种方式可以调通:
        [WebMethod]
        [SoapRpcMethod(
            Action = "http://tempuri.org/EASReceive",
            RequestNamespace = "http://tempuri.org/",
            ResponseNamespace = "http://tempuri.org/",
            Use = System.Web.Services.Description.SoapBindingUse.Literal)] //encoded不行
        [return: XmlElement("strPxFormData", IsNullable = false)]

也用C#的wsdl自动生成工具测试过,根据gsoap生成的wsdl文件,自动生成的代码也不能和gsoap完成通讯正常。我一直理解不明白,按道理说只要将编码方式一致即可通讯,不知是否我c#端代码编写有问题?在网上搜索C#端的资料时,发现C#端对webservice中自定义xml文件方案是十分灵活的,可以随意定制传输的xml节点,因此其实关键问题还是格式必须保证互相一致,这样在收到soap消息后,双方都可以对xml进行正确的解析。经过反复调试,最终还是调通了,都采用rpc/literal方式即可。JAVA端和gsoap通讯倒是没有问题,采用何种编码只要统一即可通讯,因此基于测试发现的C#的"局限性",我们统一成rpc/literal。



JAVA客户端代码:
  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 soapActionURI = "http://tempuri.org/EASReceive"; 
  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 no!???");
  call.setOperationName(new QName("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服务端代码:略

最后,欢迎大家一起探讨,感觉问题还是很多,现在虽然保证了通讯正常,但实际上我头脑还是浆糊着呢,呵呵!
令关于C#端必须要求soapAction的问题,有两种解决方案:
1、C#服务端加入以下代码,但测试发现,部署到IIS后,并不起作用,具体原因不知道。
[SoapRpcService(RoutingStyle = SoapServiceRoutingStyle.RequestElement)]  //设置无需指派soapAction 但部署到iis 上时并未起作用
//[SoapDocumentService(RoutingStyle = SoapServiceRoutingStyle.RequestElement)]
2、在客户端加上soapAction,gsoap客户端传入soapAction即可。

还有一个棘手的问题,就是中文乱码问题,呵,说棘手是因为如果不清楚的确很棘手,其实解决起来也很简单,就是保证通讯编码一致。这里的通讯编码一致有两层意思:
1、webservice间传输编码,都保证为UTF8,gsoap加入soap_set_mode(s.soap, SOAP_C_UTFSTRING)即可。java,c#端都是默认以utf8传输的。
2、传输前参数的字符编码,也保证为utf8即可,发送前如果字符不是utf8,则首先转换成utf8再发送,接收到后当成utf8处理即可。

这篇关于C++,C#,JAVA之间webservice互操作问题探讨的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/635470

相关文章

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权,允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true (Spring security默认会带有ROLE_前缀),去

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程,特意画了如下的类图,包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口,接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类,它们之间的依赖,构建起了整个框架。想要理解整个架构,最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文(security context)的信息。当前操作的用户是谁,该用户是否已经被认证,他拥有哪些角色权限…这些都被保

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物

Java进阶13讲__第12讲_1/2

多线程、线程池 1.  线程概念 1.1  什么是线程 1.2  线程的好处 2.   创建线程的三种方式 注意事项 2.1  继承Thread类 2.1.1 认识  2.1.2  编码实现  package cn.hdc.oop10.Thread;import org.slf4j.Logger;import org.slf4j.LoggerFactory

好题——hdu2522(小数问题:求1/n的第一个循环节)

好喜欢这题,第一次做小数问题,一开始真心没思路,然后参考了网上的一些资料。 知识点***********************************无限不循环小数即无理数,不能写作两整数之比*****************************(一开始没想到,小学没学好) 此题1/n肯定是一个有限循环小数,了解这些后就能做此题了。 按照除法的机制,用一个函数表示出来就可以了,代码如下

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu