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.


Reply via email to