Article

From:
To:
Jean-Marie Babet
Subject:
Re: WSDL - Cannot Unwrap issues
Newsgroup:
embarcadero.public.delphi.webservices
URL:
Shortcut to this article

Re: WSDL - Cannot Unwrap issues

> {quote:title=Jean-Marie Babet wrote:}{quote}
> Hello Dann,
> 
> This warning is perfectly safe and has to do more with how WebServices 
> standards have changed. Initially WebServices were rpc-oriented. So an 
> operation and it parts mapped exactly to a method and parameters. And even 
> though the format was XML the encoding use was not XML encoding: SOAP had 
> it's own encoding rules that used XML format but the XML conventions.
> 
> Then there was a push to shift to XML encoding. That model was not 
> rpc-oriented; rather the Service expected a type [described] by a schema and 
> it returned another type equally described by XML schema. In order to bridge 
> the document/xml schema style to the previous rpc-oriented model the 
> *wrapped* document|literal convention was established. In that model if a 
> Service exposed an 'Add' operation, say:
> 
> {code}
>        function Add(I1, I2: Integer): Integer;
> {code}
> 
> The XML schema types would actually say that the Add operation takes a type, 
> named Add, that contains two integers. Something along the lines of:
> 
> {code}
>   Add = class  private
>   published
>     property I1: Integer;
>     property I2: Integer;
>   end;
> 
>   AddResponse = class(TRemotable)
>   published
>     property AddResult: Integer:
>   end;
> 
>   function  Add(const parameters: Add): AddResponse;
> {code}
> 
> 
> Of course, no one wanted to deal with that extra layer. You just want to 
> pass two integers and get one back - not construct a type with two integers 
> and receive back another type that contains the result. So it became 
> customary for WSDL importers to *unwrap*.
> 
> A set of conventions were adopted on how the service would expose the 
> wrappers such that someone looking at the WSDL would be able to tell: "Ah, 
> this Service is wrapped... when I write a client for it I can remove that 
> extra layer and get a more rpc-centric view of the Service". You can read 
> about the conventions here: 
> http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
> 
> But then Services started to worry less about exposing an rpc-friend view 
> and several of them are simply not using the wrapped conventions. (It's a 
> rather heated debate sometimes; you can search online for 'wrapped' vs. 
> 'bare' and see the opinions for and against each:)
> 
> The messages that you saw were added to the WSDL importer because there was 
> a time when most document|literal services were wrapped and if the Delphi 
> importer failed to unwrap them (some) users would not be that happy. So, we 
> added code to clearly say that we could not unwrap and then we spell out the 
> reasons (they usually are because of the conventions mentioned in the link 
> above was not adhered to).
> 
> Now that there's just as many wrapped and bare services out there it 
> probably makes no sense to generate these messages anymore. Just a small 
> line to mention that this is not a wrapped service would probably be 
> sufficient. I'm making a note to do that.
> 
> Please let us know if you need more information or run into problems using 
> this Service. You can configure to no unwrap and therefore it won't generate 
> the messages because it won't even try.
> 
> Cheers,
> 
> Bruneau

Thank you for the detailed reply.  

I am still having problems though. If I try call any of the declared functions, I receieve errors like this. <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/fault</a:Action></s:Header><s:Body><s:Fault><s:Code><s:Value>s:Sender</s:Value><s:Subcode><s:Value>a:ActionMismatch</s:Value></s:Subcode></s:Code><s:Reason><s:Text xml:lang="en-US">The SOAP action specified on the message, '', does not match the HTTP SOAP Action, 'http://www.fastenterprises.com/MFET/SubmissionListBySubmis sionId'. </s:Text></s:Reason><s:Detail><a:ProblemHeaderQName>a:Action</a:ProblemHeaderQName></s:Detail></s:Fault></s:Body></s:Envelope>

Her eis the function I am calling
SubmissionWS.GetMFET(false,'',httprio2);SubmissionListBySubmissionId('100') ;
The problem is that the SubmissionListBySubmissionId('100') function should have 2 parameters, a Header and the SubmissionID. The '100' that I have coded in there is the SubmissionID. It appears the the WSDL import is not properly creating the function.

Here is the declaration:
  MFET = interface(IInvokable)
  ['{5959790D-89C4-E195-0CF9-C4FC82ADE863}']

    // Cannot unwrap:     // - Input message has more than one part     // - The output part is not a complex type
function NewSubmission(const SubmissionType: SubmissionType2; const ReferenceId: ReferenceId; const File_: File_): SubmissionId; stdcall;

    // Cannot unwrap: 
    //     - Input message has more than one part
function SubmissionListByDate(const DateFrom: DateFrom; const DateTo: DateTo): SubmissionList; stdcall;

    // Cannot unwrap: 
    //     - Input element wrapper name does not match operation's name
function SubmissionListByReferenceId(const ReferenceId: ReferenceId): SubmissionList; stdcall;

    // Cannot unwrap: 
    //     - Input element wrapper name does not match operation's name
function SubmissionListBySubmissionId(const SubmissionId: SubmissionId): SubmissionList; stdcall;
  end;


So what should I try? DAN
FYI: Phrase searches are enclosed in either single or double quotes
 
 
 
24-Jul 11:00 utc Operating system upgrade in process, expect some down time.
Originally created by
[Tamarack]
Mon, 21 Oct 2019 03:43:10 UTC
Copyright © 2009-2019
HREF Tools Corp.