Hikari Shidou wrote:My guess is that your class is using Event children in it, and that's messing SOAP tool's automated generator.
Indeed, WebService should know only about Event interface, and long as server-client talk remains on that interface and its children sticks to it.
A suggestion would be port Event from Interface or abstract class to an adapter class. Methods can be blank, all WebService generator needs is their signatures.
I use Axis2 and like it, even though it has some annoying limitations.
Posting the actual "I can't deliver the letter, because I do not know the content of the letter" error message would help :P
Hikari Shidou wrote:In your case, WebService is about content. It doesn't matter its methods (you can/should use annotation to not implement these methods in WSDL).
As I can understand, you have an Event Interface, that has the methods but doesn't define its properties, and its implementations add different properties to it. If that's the case, then yes, your WebSerivce and its WSDL will need to know each and all classes that implement that interface!
That's really troubling, because (as long as I know) SOAP doesn't support inheritance. If we're not careful, we freely use inheritance in our software, then when we must add WebService inside it we'll be stuck in SOAP requiring more simplicity than a full OOP language.
Your modules seem too much coupled, you should enhance your software architecture (I'm not saying it will be easy after it's already implemented :p ) to make each component/module less coupled (google "loose coupling"). You're facing a situation where your broker depends on all your components' internal implementation, and exposes it! It seems you have created an Event Interface and let it be freely extended by any component, in a way that these extends are being needed outside of them.
If you cannot make Event evt = new SomeEvent() and handle everything from Event interface (including pass Event evt object to some code that isn't coupled with SomeEvent), then that interface loses its use and everything that uses SomeEvent will be dependant of the component that defines it. If some complexity isn't properly encapsulated, everything that consumes it will need to be aware of it!
A solution to reduce coupling would be to have a component by itself that defines all available Event's, and couple all components only to it.
I know it's trouble. An easier solution would be create a FatEvent POJO/JavaBean class, that stores *all* possible properties (I think that behavior methods aren't needed) from all Event's. It will also have an Enum property, where you store which Event type it is.
If that works, when preparing a WebService message, you convert your actual Event into a FatEvent object, and send it. On the other side you verify its Enum property to know which Event it sould be, and convert it back.
Surfs up space ponies, I'm making gravy without this lumpy, tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|