[EMAIL PROTECTED] writes:
> However, there is one caveat for both DynamicInvoker and WSIF:
> they work, as they are, only with simple java types. If you want to
> use complex types, you have to have a corresponding Java class created
> on the client side - which makes dynamic invocation much less
> dynamic' : if the complex types in the wsdl change, you have to change
> and recompile the corresponding java class.
as an aside, why is this a bad thing?
I've also been giving this (or something like it) some thought. what
I want is to treat WS like RMI: clients are required to already have
access to classes for the various interfaces and beans. it's just
the mechanics of the calls that are hidden from them.
after all, isn't it more useful to have something like:
ServiceInterface if = obtainStub();
MyBean bean = if.getBean("foo", "bar");
than something like:
Call call = ...;
call.addParameter(...);
call.addParameter(...);
...
after all, if the WSDL did change, and you wanted your client to take
advantage of the change, you'd have to recompile the client anyhow.
also, it's not true that you'd have to recompile the java classes if
you made any changes to the types. I think it'd depend largely on
the scope and details of the changes.
as I understand things, as a relative newcomer to web services in
general and axis in particular, is that I can *almost* do what I want
to do. I can do a
ServiceInterface if = Service.getPort(name, ServiceInterface.class);
and get a stubless proxy back. the only problem (I think, anyhow) is
to get axis to register the correct [de]serializers for the beans.
after I think this through a bit more I intend to post a message
about exactly this problem.
--
joe
