Hi Ranjith,
>call.setOperationName(new javax.xml.namespace.QName("urn:eprofile",
>"updateProfile"));
I have experienced that the above line has no effect whatso ever on the
SOAP message (it should not have any effect on the SOAP body, in the
doc\lit services method name is not send on the SOAP message but on the
SOAP action).
But a "NullPointer Exception" will be thrown if you do not set the
operation :-). I know what I say sounds funny, but it is the truth as far
as I know.
Regards,
Dimuthu.
--
Lanka Software Foundation - Proud to be a part of it.
http://www.opensource.lk
> Hi Anne, Dimuthu,
>
> I would like to try this.
> Do you know what method do I need to call at Axis Client to set this
> QName?.
>
>
> My method name is updateProfile and in my server-config.wsdd, I have
> this entry for my service
>
> <operation name="updateProfile" qname="operNS:updateProfile"
> xmlns:operNS="urn:eprofile" returnQName="retNS:updateProfileReturn"
> xmlns:retNS="urn:eprofile" returnType="rtns:Document"
> xmlns:rtns="http://xml.apache.org/xml-soap"; >
> <parameter qname="pns:in0" xmlns:pns="urn:eprofile"
> type="tns:Document" xmlns:tns="http://xml.apache.org/xml-soap"/>
> </operation>
>
> This is my API call at client side.
>
> call.setOperationName(new javax.xml.namespace.QName("urn:eprofile",
> "updateProfile"));
>
> Unfortunately its not dispatching to updateProfile service method. What
> I am doing wrong here?
>
> Any help will be really appreciated.
>
> Thanks,
> Ranjith Pillai.
>
> -----Original Message-----
> From: Dimuthu Leelarathne [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 13, 2003 10:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: How to define document/literal service with multiple
> operations
>
> Hi Mike,
>
> No it's not less sleep, or more coffee, or anything else :-).
>
> Correct me if I am wrong, but I am under the impression that axis does
> not use SOAP action at all when invoking a service.
>
> If someone wants to use doc\literal service to have multiple operations
> he has to explicity map the operation and the doc\literal element in the
> wsdd -at least that's what I heard.
>
> Try writing something like this in the wsdd for each operation.
>
> <operation name="methodName" qname="operNS:ElementName"
> xmlns:operNS="uri" returnQName="returnName" returnType="rtns:returnType"
> xmlns:rtns="uri" >
> </operation>
>
> Can you please let me know if this works ?
>
> Regards,
> Dimuthu.
> --
> Lanka Software Foundation http://www.opensource.lk
>
>> The plot thickens...after poking around in the source, I found where
>> the
>> AxisServlet stores the SOAPAction value:
>>
>> org.apache.axis.transport.http.AxisServlet.java, line 835:
>>
>> soapAction = getSoapAction(req);
>>
>> if (soapAction != null) {
>> msgContext.setUseSOAPAction(true);
>> msgContext.setSOAPActionURI(soapAction);
>> }
>>
>> Here, the MessageContext stores the SOAPAction value, but I don't see
>> it being used for message delivery anywhere. The service operation
>> name is set in org.apache.axis.providers.java.RPCProvider.java, line
>> 194:
>>
>> operation = msgContext.getOperation();
>>
>> if (operation == null) {
>> QName qname = new QName(body.getNamespaceURI(),
>> body.getName());
>> operation =
>> serviceDesc.getOperationByElementQName(qname);
>> }
>>
>> But RPCProvider doesn't call MessageContext.useSOAPAction, and
>> MessageContext.getOperation doesn't check SOAPAction either. It seems
>> like that last bit should be something like this:
>>
>> if (msgContext.useSOAPAction()) {
>> String soapAction = msgContext.getSOAPActionURI();
>> QName qname = new QName(...) // parse soapAction into URI
>> and name operation =
>> serviceDesc.getOperationByElementQName(qname);
>> }
>> else {
>> operation = msgContext.getOperation();
>>
>> if (operation == null) {
>> QName qname = new QName(body.getNamespaceURI(),
>> body.getName());
>> operation =
>> serviceDesc.getOperationByElementQName(qname);
>> }
>> }
>>
>> Bug, or works-as-designed? I'll take a closer look next week when I
>> have more time (or less sleep, or more coffee, or...)
>>
>> Mike
>>
>>
>> Michael Woinoski wrote:
>>
>>> Keith,
>>>
>>>> I agree with all of your points.
>>>>
>>>> I dont understand web services well enough yet so this question may
>>>> be a lame one.
>>>>
>>>> The SOAPAction is in the WSDL. How does that translate to the
>>>> actual SOAP message that is being sent over the wire?
>>>
>>>
>>> The soapAction attribute value in the WSDL is the value the client
>>> should assign to the SOAPAction HTTP header in the request message.
>>> So
>>> it's set by the client, not the service.
>>>
>>>> My uneducated guess is
>>>> that it doesn't. My guess is that the server is suppose to know the
>>>> given "soap action" when it receives a given "message". Is that
>>>> correct or is there something more specific in the SOAP message that
>>>> tells the "soap action"?
>>>> I also thought I read somewhere that soapAction in the WSDL was not
>>>> suppose to be used.
>>>
>>>
>>> I don't remember seeing that SOAPAction shouldn't be used. Basic
>>> Profile says "SOAPAction is purely a hint to processors. All vital
>>> information regarding the intent of a message is carried in
>>> soap:Envelope." Now exactly what "intent" means, I don't know. Does
>>> "intent" include "ultimate destination of message"? Beats me.
>>>
>>>> I may be wrong about that. At this point I have too
>>>> much reading in my small brain to keep it all straight.
>>>
>>>
>>> Ah yes, that bursting skull sensation...
>>>
>>> Mike
>>>
>>>>
>>>> Keith
>>>>
>>>> -----Original Message-----
>>>> From: Michael Woinoski [mailto:[EMAIL PROTECTED]
>>>> Sent: Thursday, November 13, 2003 5:48 PM
>>>> To: [EMAIL PROTECTED]
>>>> Subject: Re: How to define document/literal service with multiple
>>>> operations
>>>>
>>>> Keith,
>>>>
>>>>
>>>>> With document/literal web services you need to define your schema
>>>>> in such a way that the "wrapper" element or root element will lead
>>>>> you to the business function. So you are not just defining the data
>>>>> that
>>>>
>>>>
>>>> needs
>>>>
>>>>> to be sent but also a wrapper element that suggests the operation
>>>>> to
>>>>
>>>>
>>>> be
>>>>
>>>>> performed.
>>>>
>>>>
>>>>
>>>> Well, that may be the way Axis currently routes messages, but I
>>>> prefer to develop my application's schema based on what is
>>>> appropriate for the application, not because of the limitations
>>>> imposed by a
>>>> particular implementation. This is exactly the kind of situation
>>>> that
>>>> SOAPAction is
>>>>
>>>> supposed to address. .NET uses it for routing messages, so I know
>>>> Axis HAS to support it ;-) I suspect it's just a matter of
>>>> configuring HTTPActionHandler correctly.
>>>>
>>>> Also, I'd like to keep my web services portable to different JAX-RPC
>>>> implementations, so I try to avoid Axis-specific features (e.g.,
>>>> Message-style services.)
>>>>
>>>>
>>>>> Read the axis users guide about "service styles"
>>>>> specifically the "message", "document" and "wrapped" service
>>>>> styles.
>>>>
>>>>
>>>>
>>>> I did. I didn't find anything in the user's guide about the details
>>>> of routing document-style services.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Michael Woinoski [mailto:[EMAIL PROTECTED]
>>>>> Sent: Thursday, November 13, 2003 4:47 PM
>>>>> To: Axis User mailing list
>>>>> Subject: How to define document/literal service with multiple
>>>>
>>>>
>>>> operations
>>>>
>>>>> How can I define a document/literal service with multiple
>>>>> operations? Because there's no wrapper element around the input
>>>>> message parts, Axis seems
>>>>
>>>>
>>>> to
>>>>
>>>>> have a problem invoking the correct service method.
>>>>>
>>>>> If I add a value for SOAPAction in the service's binding, the
>>>>> client stubs set SOAPAction in the HTTP request correctly, but Axis
>>>>> doesn't
>>>>> use the
>>>>> SOAPAction value. I found the Axis HTTPActionHandler class and
>>>>> tried
>>>>> adding it to
>>>>> the request flow in the service's deploy.wsdd but it didn't seem to
>>>>> make a
>>>>
>>>>
>>>>
>>>>> difference. Does Axis support this? If so, how do I configure it?
>>>>>
>>>>> Thanks,
>>>>> Mike
>>>>>
>>>>
>>>>
>>>
>>
>> --
>>
>> Mike Woinoski Pine Needle Consulting
>> mailto:[EMAIL PROTECTED]
