Amila Suriarachchi ha scritto:
hi,
I think this is a confusion lot of people made.
when developing web services there are two mehtods.
1. contract first approach.
here you start with the wsdl file (contract ) and use the
wsdl2java to generte the code. so it generates a
custom message receiver for you.
2. code first approach.
here you start with code and axis2 generates a wsdl for you.
here you must use the RPCMessageReceiver.
when developing a service you have to choose one. and you can not use
RPCMessageReceiver with the generated code.
thanks,
Amila.
Hi Amila,
yes, this is clear. But suppose that I follow a mixed approach:
1) I (manually) write the WSDL
2) I (manually) write the Java code that implements the service on the
server, as a POJO, respecting the interface defined in the WSDL (so: a
method for each operation, with the same name; method signatures
coherent with the messages defined in the WSDL for each operation and so on)
3) I (manually) write a services.xml that declares my Java code as the
service class and that states to use RPCMessageReceiver
This should work, shouldn't it?
The benefits of this approach I can think of are:
- I do not have to care about WSDL2Java problems like the missing
unwrapping of elements corresponding to empty types
- I do not have to manage any (useless?) custom message receivers
- I should have total control over both the WSDL and the Java code,
while keeping the implementation simple and straightforward
The only drawback I can think of is that it could become quite hard to
manage services that exchange complex types (e.g.: Java beans) by using
this approach. In that case, using a custom message receiver may be
compulsory...
Do I have understood it correctly? Or do you think I'm missing something
else?
Thanks in advance!
--
Mauro Molinari
Software Developer
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]