Setting the message receiver to RawXMLMessageReceiver still appears to require <actionMapping> to determine which method to invoke. In axis1, the specified method would receive all messages for that service. Equivalent behavior should be available in axis2 regardless of the value of the wsa:Action header.
To further clarrify, the service I'm writing bridges between webservices and a non-Java object invocation mechanism. It dynamically determines what operations are allowed. This services does not know at deployment time what operations are possible. I therefore don't know all the wsa:Action header values that it might be included in request messages. Therefore I cannot declare <actionMapping> values in the service deployment descriptor. In case you're wondering, this service also dynamically generates WSDL to describe the discovered supported operations.
Is there a way to wildcard <actionMapping> to say that any action maps to a method? Or to avoid the requirement for specifying an actionMapping if RawXMLMessageReceiver is used.
Are there other approaches that could be used?
| "Anne Thomas Manes"
<[EMAIL PROTECTED]>
07/25/2006 02:06 PM
|
|
Use the RawXMLMessageReceiver.
On 7/25/06, David Melgar <[EMAIL PROTECTED]> wrote:
>
> I need to implement a message style web service in Axis2. In Axis1 wsdd,
> this would be a web service declared with
> <service name=xxx style="message">
>
> How do I declare the equivalent web service in Axis2? In addition, I will
> expect that WS-Addressing headers will be sent and received. From reading
> the Axis2 documentation, it looks like the <actionMapping> element is used
> to map an action header value to an operation name. In my case I want Axis2
> to always send me the body of the message. I do not want Axis2 to try and
> determine which operation is being invoked, I want it to send the message to
> a specific method all the time, as a message style service did in Axis1.
>
> I'm doing this because my service is mapping web service invocations of
> operations to another form of invocation on non-Java objects.
>
> Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
