Spring + Axis - jak wystawić gotowego springowego beana jako SOAP WebService za pomocą axis'a ?

[sielim]

Taki mam problem: axis jako generator SOAPowych nagłówków i WSDL'a, a
pod spód chcę wstawić springowego bean'a (implementacja usługi).

Typowo wygląda to trochę inaczej: w pliku konfiguracyjnym
axis'a (mowa o axis 1.4, nie axis2), np. axis-server-config.wsdd
definiuję service, a w nim ustawiam atrybut 'className' wskazując
na klasę implementującą usługę. Axis sam zajmuje się utworzeniem
instancji obiektu.

Ja chcę jednak zmusić axisa, żeby nie tworzył własnych instancji, tylko
by skorzystał z beanów zarządzanych przez spring.
Po długich poszukiwaniach znalazłem dwie podpowiedzi:

Pierwsza metoda polega na podmianie RPCProvidera na taki, który się
dogada ze springiem, aczkolwiek jak dla mnie jest to mocno trickowate,
i nieudokumentowane. Nie wszystkie beany chcę generować przez Springa
i nie wiem, jak to się wtedy zachowa:
http://wiki.alfresco.com/wiki/Web_Services_Implementation#Axis_and_Spring
Powyższe rozwiązanie wydaje mi sięmocno zamotane (a może tylko jest
tak opisane ?)

Druga metoda, znacznie łagodniejsza i czysta polega na tym, że tworzymy
własne klasy - delegatów - których instancje tworzy axis, a Ci
delegaci wyciągają ze springa beany docelowej usługi i do niej
przekierowują wywołania.

http://java-x.blogspot.com/2007/01/implementing-web-services-with-spring.html

Jedyna wadą tego drugiego rozwiązania, jaką widzę jest to, że
... powstają kolejne klasy. I nie da się wiec tego rozwiązać
na zasadzie grzebnięcia w samej konfiguracji spring/axis.
Poza tym ja zmieniłbym sposób konstruowana delegatów, nie
w metodzie onInit(), w ogóle bym się nie bawił w ich
zarządzanie przez spring'a.

Jest też trochę info dot. axis2, ale to mnie nie urządza:
http://axis.apache.org/axis2/java/core/docs/spring.html
(mam konfigurację SOAP'a gotową dla axis, migracji
na axis2 nie ćwiczyłem i chyba nie mam już za bardzo czasu
na to)

Mam pytanie: czy ktoś może ćwiczył coś podobnego ?
Na marginesie dodam, że to wszystko jest zapakowane
na serwer mule 3.2.1, ale to mniej ważne. Teoretycznie
powinienem sobie dać spokój z axisem i robić cxf'em,
ale problem leży w kliencie WebService'a, którym jest
stary technologicznie MS Soap Toolkit 3.0 i ten sobie
nie radzi z xcf'em.
Można o tym poczytać tu:
http://shrubbery.mynetgear.net/wiki/Using_JBoss-WS

[sielim]

W dniu 2012-01-27 19:37, sielim pisze:

Problem jakby nieaktyualny. Stwierdziłem, że pchanie
axis'a na mule 3.2 po to, by dogadał się z MS SOAP Toolkit'em 3.0
jest zbyt przekombinowane. Po dokładnemu przyjrzeniu
się wiadomościom SOAPowym wychodzi mi, że MS SOAP Toolkit
nadgorliwie wrzuca namespace'y do parametrów funkcji.

Aby zmusić xcf'a, żeby się dogadał, trzeba skorzystać
z nast. ustawień:
style = Document
use = Literal
parameterStyle = BARE

Ze wzgledu na BARE każda funkcja usługi musi mieć dokładnie jeden
parametr wejsciowy (u mnie akurat już tak było, wiec nie było problemu).
Ponadto, jeśli usługa ma więcej niż jedną funkcję - należy zadbać o to,
by nazwy parametrów były unikalne.
WSDL się zmniejszył, skrócił binding, skróciła struktura XML'a
i w końcu poszło.

Dla formalności, podaję przykład interfejsu z adnotacjami, które
zapewniają wszystko, co powyżej, użyłem też WebResult dla symetrii:

import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.ParameterStyle;
import javax.jws.soap.SOAPBinding.Style;
import javax.jws.soap.SOAPBinding.Use;

@WebService
@SOAPBinding(style = Style.DOCUMENT, use = Use.LITERAL,
parameterStyle = ParameterStyle.BARE)
public interface MyExampleService {
@WebResult(name="firstFunResponse")
String firstServiceFun(
@WebParam(name="firstFunRequest") String someParam);

@WebResult(name="secondFunResponse")
SomeResult secondServiceFun(
@WebParam(name="secondFunRequest") String someParam);

}