RE: SOAP:Header question

[Tysnes Are Thobias]

Title: Message

 

I don't know if I should laugh or cry.. but yes.. it looks like this works without warnings..

 

Thanks alot Anne! :o)

 

Cheers,

Are T. Tysnes

-----Original Message-----
From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
Sent: 26. oktober 2005 15:04
To: axis-user@ws.apache.org
Subject: Re: SOAP:Header question

Try specifying the body parts before the header parts -- both in the messages and in the binding. That should get rid of the warnings.

Anne

On 10/26/05, Tysnes Are Thobias <[EMAIL PROTECTED]> wrote:

Hello Anne! Thanks for your reply :o)

 

When I describe headers like you suggests, wsdl.exe in .NET gives me the warning

I mentioned (R2210)

 

And if I have several operations (example below) declared in the WSDL both wsdl.exe

in .NET and SoapScope Analyzer gives me this warning:

 

"Duplicate Wire Signature

Wsdl:Operation myOperation1 with wsdl:part MyHeader has same wire signature as

wsdl:operation myOperation2 with wsdl:part MyHeader. W013"

 

The code generated in .NET and Axis looks ok, but I don't like the warnings.. ;o)

 

Cheers,

Are T. Tysnes

 

<wsdl:message name="MyOperation1Req">

<wsdl:part name="MyHeader" element="aaa:Header"/>

<wsdl:part name="parameters" element="bbb:MyOperation1"/>

</wsdl:message>

<wsdl:message name="MyOperation1Resp">

<wsdl:part name="parameters" element="bbb:MyOperation1Response"/>

</wsdl:message>

<wsdl:message name="MyOperation2Req">

<wsdl:part name="MyHeader" element="aaa:Header"/>

<wsdl:part name="parameters" element="bbb:MyOperation2"/>

</wsdl:message>

<wsdl:message name="MyOperation2Resp">

<wsdl:part name="parameters" element="bbb:MyOperation2Response"/>

</wsdl:message>

 

....

 

<wsdl:binding name="xxxWSSOAPBinding" type="tns:xxxWSInterface">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="MyOperation1">

<soap:operation soapAction="MyOperation1" style="document"/>

<wsdl:input>

<soap:header message="tns:MyOperation1Req" part="MyHeader" use="literal"/>

<soap:body parts="parameters" use="literal"/>

</wsdl:input>

<wsdl:output>

<soap:body use="literal"/>

</wsdl:output>

</wsdl:operation>

<wsdl:operation name="MyOperation2">

<soap:operation soapAction="MuOperation2" style="document"/>

<wsdl:input>

<soap:header message="tns:MyOperation2Req" part="MyHeader" use="literal"/>

<soap:body parts="parameters" use="literal"/>

</wsdl:input>

<wsdl:output>

<soap:body use="literal"/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

-----Original Message-----
From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]]
Sent: 25. oktober 2005 21:43
To: axis-user@ws.apache.org
Subject: Re: SOAP:Header question

Did you specify a parts attribute in the <soapbind:body> description?

Here's an example of how your should describe headers:

<message name="SubscribeToQuotes">
  <part name="body" element="tns:SubscribeToQuotes"/>
  <part name="subscribeheader" element="tns:subscribeHeader"/>


</message>
...
<binding name="StockQuoteSoap" type="tns:StockQuotePortType">
  <soapbind:binding style="document" 
                transport="

http://schemas.xmlsoap.org/soap/http"/>
    <operation name="SubscribeToQuotes">
      <input message="tns:SubscribeToQuotes">
        <soapbind:body parts="body" use="literal"/>


        <soapbind:header message="tns:SubscribeToQuotes"
             		part="subscribeheader" use="literal"/>
     </input>
   </operation>
</binding>

Anne

On 10/25/05, Tysnes Are Thobias <[EMAIL PROTECTED]> wrote:

Hello!

I have som issues with SOAP:Header.

The solution with multiple parts in a message raise a warning
in .NET:

"Warning: This web reference does not conform to WS-I Basic Profile
v1.1 .
R2210: If a document-literal binding in a DESCRIPTION does not specify
the parts attribute on a soapbind:body element, the corresponding
abstract wsdl:message MUST define zero or one wsdl:parts.
  -  Operation 'SLSCreateCase' on binding 'SLSCreateCaseSOAPBinding'
from namespace 'http://www.edb.com/sls/webservices/
createcase/wsdl'."

When i split the parts in two messages:

        <wsdl:message name="MyHeader">
                <wsdl:part name="SoapHeader"
element="myheader:AutHeader"/>
        </wsdl:message>
        <wsdl:message name="inputMessage">
                <wsdl:part name="parameters"
element="s0:QuerySomething"/>
        </wsdl:message>


everything is fine in .NET, but AXIS 1.3 (WSDL2Java) refuses to generate
this header for me.

Any reason for this !?

Cheers;
Are T. Tysnes

-----Original Message-----
From: Hans Planting (CWEU-USERS/CWNL)
[mailto:[EMAIL PROTECTED]]
Sent: 20. oktober 2005 17:15
To: axis-user@ws.apache.org
Subject: Re: SOAP:Header question


It should look like:

<message name="inputMessage">
    <part name="parameters" element="s0:???"/>
    *<part name="Authorization" element="s0:AuthorizationElement"/>*
</message>
...
<portType name="portType">
  <operation name="GetFinancialDetail">
      <input *message="s0:inputMessage"*>
        <soap:body use="literal" />
      </input>
...
<binding name="binding" type="s0:portType">
  <soap:binding ...>
    <operation name="GetFinancialDetail">
      <soap:operation
soapAction="http://xxx/webservices/GetFinancialDetail " style="document"
/>
      <input>
        <soap:body ...>
        <soap:header message=*"s0:inputMessage"* part="Authorization"
use="literal" /> ...



When running wsdl2java you should get something like
'getFinancialData(String clientid, Authorization auth)' as the
webservices endpoint method. The clientid will be sent in the soap:body,
the auth in the soap:header of the envelope. The Axis java source
distribution contains a good example of this in
[axishome]/test/wsdl/header

Hans




>You got the idea: have the endpoint method (getFinancialData) handle
>this data - and obviously, it requires extra parameters to do that. The

>question is how to transfer this authentication data from the header to

>this parameter. Or do I misunderstand?
>
>Just for clearence:
>I got a WSDL from which I created the JAVA sources using WSDL2Java
>--server-side, that gave me (amongst others) OrgWebservice.java and
>OrgWebServiceImpl.java. The last one is the one that implements the
>actual services, amongst the GetFinancialDetails (java.lang.String
>clientid). Is that what you call the "endpoint method"?
>
>Obviously, that one nedds to get the authentication data, and I don't
>care if that would be in the form of an object: Object class
>Authentication
>   java.lang.String region ;
>   java.lang.String department ;
>   java.lang.String desk ;
>   java.lang.String username ;
>
>or whatever, or as separate arguments. Lets assume the first.
>
>So the service - now generated as:
>
>FinDetails class getFinancialDetails (java.lang.String clientid)
>
>would need to be:
>
>FinDetails class getFinancialDetails (java.lang.String clientid,
>Authetication authentication)
>
>so I could use the data - directly or by a getter.
>
>Would this be the idea of WSDL:
>...
>      <s:element name="Authorization" type="s0:Authorization" />
>      <s:complexType name="Authorization">
>        <s:complexContent mixed="false">
>          <s:extension base="s0:LogObjectBase">
>            <s:sequence>
>              <s:element minOccurs="0" maxOccurs="1" name="Region"
>type="s:string" />
>              <s:element minOccurs="0" maxOccurs="1" name="Department"
>type="s:string" />
>              <s:element minOccurs="0" maxOccurs="1" name="Username"
>type="s:string" />
>              <s:element minOccurs="0" maxOccurs="1" name="Desk"
>type="s:string" />
>            </s:sequence>
>          </s:extension>
>        </s:complexContent>
>      </s:complexType>
>      <s:complexType name="LogObjectBase" abstract="true" /> ...
>  <message name="GetFinancialDetailAuthorizations">
>    <part name="Authorization" element="s0:Authorization" />
>  </message>
>...
>    <operation name="GetFinancialDetail">
>      <soap:operation
soapAction="http://xxx/webservices/GetFinancialDetail "
>style="document" />
>      <input>
>        <soap:body use="literal" />
>        <soap:header message="s0:getFinancialDetailAuthorization"
>part="Authorization" use="literal" />
>      </input>
>      <output>
>        <soap:body use="literal" />
>      </output>
>    </operation>
>...
>
>This is in the WSDL already, but the header data is not included in the

>generated JAVA code:
>
>public interface OrgWebServiceSoap extends java.rmi.Remote { ...
>    public xxx.FinDetails getFinancialDetail(java.lang.String clientid)
;
>...
>}
>
>and I don't find any refererence to the haeder data either when
>searching all java files.
>
>So HOW to change the WSDL to get this information included in the
>interface? Or should I just add it and create a WSDL from the java
>code? Quite a nasty job since so much needs to be coded. By that: the
>nasty part, at the moment, is that the WSDL is _delivered_ to me -
>there is already a webservice (on another platform) that works with it.

>The good side is that we're in the stage of preparing a new version so
>changes can be incoprorated. If only I had some idea.
>
>Willem
>
>PS. Original names in code adapted for display, because of policy.
>
>-----Oorspronkelijk bericht-----
>Van: Hans Planting (CWEU-USERS/CWNL)
>[mailto: [EMAIL PROTECTED]]
>Verzonden: donderdag 20 oktober 2005 11:29
>Aan: axis-user@ws.apache.org
>Onderwerp: Re: SOAP:Header question
>
>
>Hi Willem,
>
>It sounds to me that you need to use explicit service context: the
>signature of the webservices endpoint method is extended with the parts

>of the soap:header.
>This way the getFinancialDetails method will have an additional
>parameter for the authentication data - however the authentication data

>in the soap envelope is transported in the header. So you don't create
a
>separate handler to deal with the header but instead deal with it in
the
>endpoint method. Make sure that in the wsdl the soapheader element
>refers to a part in the request message.
>
>Regards,
>Hans
>
>
>
>>Hi,
>>Some help is rquired with the following problem:
>>
>>I have an application on a OpenVMS system that is used by different
>>
>>
>regional
>
>
>>offices, where all use the same executables, but the data is
>>completely separated. If a person logs in, the OS will know which
>>scripts to execute
>>
>>
>to
>
>
>>setup the right paths to the data, and the application will then be
>>able to check the authorisations of that user. If the user uses the
>>application, he will only have access - by this setup - to the data of

>>his regional office.
>>
>>It happens that a .NET application will access the data by a
>>SOAP-based webservice. This application is used by the same regional
>>offices that use the OpenVMS application, and will access only the
>>data of that office. Only users of the .NET application that are
>>authorized will be allowed access - be it anyone within a deparetment,

>>or a specific user. In some cases, data can just be accessed if
>>requested from a certain desk only. This authorization is set within
>>the dataset on the VMS machine and maintained on that system only (for

>>security reasons).
>>
>>That means that the webservice needs to be able to set the right
>>access paths to the data, in order to check access by that user, on a
>>request-by-request basis, because, IIRC, SOAP:Header can contain
>>authentication information, and this can be specified in some
>>structure. So my idea is to use a structure in the SOAP:header, since
>>it is required for each and every request.
>>
>>An example:
>>I'm working at the ICT department, and logged in on PC at the infodesk

>>of region 9999. I need to get information on the financial details of
>>client with code 123456. The ,NET application will build up a SOAP
>>message containing my login information (in the header) and  the
>>requested information in the body:
>>
>><SOAP:header>
>>   <authentication>
>>       <region>9999</region>
>>       <department>ITC</department>
>>       <desk>infodesk</desk>
>>       <username>Grooters</username>
>>   </authentication>
>></SOAP:Header>
>><SOAP:Body>
>>      <clientid>123456</clientid>
>></SOAP:Body>
>>
>>and sends it to tehet webservice, method "getFinancialDetails"
>>
>>The method would normally get the clientid from AXIS, but it needs the

>>header information as well, to be able to: 1 Set the right access
>>paths to the data (<region>) 2 Authorize the request (against the data

>>of region 9999) (<department>, <desk> and <username>
>>3 If authorized, access the data of the client (<clientid>)
>>
>>The problem is that it seems that I have no access to the header
>>
>>
>information
>
>
>>when I need it: in the service itself. How can this be solved - with
>>this info in the SOAP Header - not moved to the body (I'm stuck to
>>this
>>structure)
>>
>>
>>
>>
>>Disclaimer:
>>The information contained in this E-mail and its attachments is
>>
>>
>confidential
>
>
>>and may be legally privileged. It is intended solely for the use of
>>the individual or entity to whom it is addressed and others authorized

>>to receive it. If you are not the intended recipient you are hereby
>>notified that any disclosure, copying, distribution or taking any
>>action in reliance of the contents of this E-mail and any attachments
>>is strictly prohibited and may be unlawful. The CIP or ISC is neither
>>liable for the proper and complete transmission of the information
>>contained in this E-mail and any attachments nor for any delay in its
>>receipt. If received in error, please contact The CIP or ISC on
>>+31(0)522 722222 quoting the name of the sender and the addressee and
>>then delete it from your system. Please note that
>>
>>
>the
>
>
>>The CIP or ISC does not accept any responsibility for viruses and it
>>is
>>
>>
>your
>
>
>>responsibility to scan the E-mail and attachments (if any). No
>>contracts
>>
>>
>may
>
>
>>be concluded on behalf of The CIP or ISC by means of E-mail
>>communications.
>>
>>
>>
>>
>>
>
>
>Disclaimer:
>The information contained in this E-mail and its attachments is
confidential
>and may be legally privileged. It is intended solely for the use of the
>individual or entity to whom it is addressed and others authorized to
>receive it. If you are not the intended recipient you are hereby
notified
>that any disclosure, copying, distribution or taking any action in
reliance
>of the contents of this E-mail and any attachments is strictly
prohibited
>and may be unlawful. The CIP or ISC is neither liable for the proper
and
>complete transmission of the information contained in this E-mail and
any
>attachments nor for any delay in its receipt. If received in error,
please
>contact The CIP or ISC on +31(0)522 722222 quoting the name of the
sender
>and the addressee and then delete it from your system. Please note that
the
>The CIP or ISC does not accept any responsibility for viruses and it is
your
>responsibility to scan the E-mail and attachments (if any). No
contracts may
>be concluded on behalf of The CIP or ISC by means of E-mail
communications.
>
>
>