[转]解决Delphi7调用VS.NET 2005编写的WebService问题

xujh

今天测试.net 2.0的WebService，发现了一个大问题。就是无法获取参数，参数永远是null。当然了使用.net调用没有任何问题，web测试页也正常。不论是Delphi7还是java调用的结果的都是一样的，难道是.net 2.0的Bug？

测试结果发现：值类型参数全部为缺省值，引用类型全部为null

WebService的代码如下:



    [WebMethod]
    public string EchoString(string args)
    {
        return args;
    }

    [WebMethod]
    public string EchoInt(int args)
    {
        return args.ToString();
    }



delphi调用的代码


procedure TForm1.Button3Click(Sender: TObject);
var
  ss:ServiceSoap;
  hello:WideString;
begin
  try
    HTTPRIO1.WSDLLocation := edtAddress.Text;
    HTTPRIO1.Service := edit3.Text;
    HTTPRIO1.Port := edit4.Text;

    ss := (HTTPRIO1 as ServiceSoap);
    hello:= 'hello';
    Memo1.Lines.Add(ss.EchoInt(234));
  except
    on e : exception do
          showmessage(e.Message);
  end;
end;


--------------------------------------------------------------------------------------------------------------------------------------------------

在不断尝试中发现vs2003生成的web Services，delphi调用的时候不会有任何问题，即使是delphi2006也无法正常调用.net 2.0的Web Service.

最后经过不懈努力，终于找到方法那就是在delphi生成webservices声明单元中加入以行
InvRegistry.RegisterInvokeOptions(TypeInfo(ServiceSoap), ioDocument);

如：


unit Service;

interface

uses InvokeRegistry, SOAPHTTPClient, Types, XSBuiltIns;

type
  ServiceSoap = interface(IInvokable)
  ['{77573149-9C57-FA51-F11F-EFD527C91BD9}']
    function  HelloWorld(const asdf: WideString): WideString; stdcall;
  end;

implementation

type

  ServiceSoapImpl = class(TInvokableClass, ServiceSoap)
  public
    { ServiceSoap }
    function  HelloWorld(const asdf: WideString): WideString; stdcall;
  end;

function ServiceSoapImpl.HelloWorld(const asdf: WideString): WideString;
begin
  { TODO - Implement method HelloWorld }
end;

initialization
  InvRegistry.RegisterInterface(TypeInfo(ServiceSoap), 'http://tempuri.org/', 'utf-8');
  InvRegistry.RegisterInvokableClass(ServiceSoapImpl);
  InvRegistry.RegisterDefaultSOAPAction(TypeInfo(ServiceSoap), 'http://tempuri.org/HelloWorld');
  InvRegistry.RegisterInvokeOptions(TypeInfo(ServiceSoap), ioDocument);//就是这一行
end.
至此问题搞定了。


以下是Borland的网站上的说明：
---------------------------------------------------------------------------------------------------------------------------------
http://www.community.borland.com ... 132/paper/4132.html

RPC|Encoded vs. Document|Literal

The biggest problem in interoperability is the fact that some servers use Document|Literal encoding, which most others use RPC|Encoded. Delphi servers only understand RPC|Encoded packages, but Delphi Clients can talk to both RPC|Encoded and Document|Literal servers.

To communicate with a Doc|Lit server (Most .NET web services are doc|lit) you must set HTTPRio1.Converter.Options.soLiteralParams to true. This ensures that parameters encoded with "literal" are not unwound, which is necessary in doc|lit cases where a parameter name might be encapsulated under a sub tag under the XML element representing the function.

In Delphi 7, Document encoding is supported in one way - you can make Delphi 7 client applications (consumers) for Document based webservices. What you cannot do is write Document based servers. If you're writing a client for a document based server, you can import the WSDL and Delphi's WSDL Importer will recognize that this is a document based server and generate necessary code for the conversion. FOr instance it will add the following call to the initialization section of your imported .pas file:


InvRegistry.RegisterInvokeOptions(TypeInfo(DataServiceSoap), ioDocument);

This ensures that an Invoke call that uses the interface DataServiceSoap will be formatted using Document rules (not RPC). You can also use ioLiteral for doc-lit services. Using ioLiteral also ensures that your input and output types won't be "unwound" - this needs some explanation. In RPC encoding, each method call is preceded by a method node in the XML datapacket. In Literal encoding, the method name is skipped and the parameters are unwound into XML. This and many small differences are actually handled directly by the Delphi SOAP runtime itself, so you don't have to worry about them individually. But, use a proxy server to actually find out what's happening behind the scenes in case there's a problem