wood burning stoves 2.0*
The moose likes Web Services and the fly likes apache axis, inheritance and overloading Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "apache axis, inheritance and overloading" Watch "apache axis, inheritance and overloading" New topic
Author

apache axis, inheritance and overloading

paulm rhoades
Greenhorn

Joined: Nov 08, 2005
Posts: 6
i want to pass events from a client to a server via a web service interface such as:

public void accept(Event e);

now Event is actually an interface (or abstract class) with specialisations defined for each concrete event type (e.g. AddUserEvent, UpdateUserEvent, etc..). So, how do i do it. Does SOAP handle inheritance, or if not can i overload the service:

public void accept(AddUserEvent e);
public void accept(UpdateUserEvent e);#

or is there a.n.other approach?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42264
    
  64
I'm speculating here, but I think that it shouldn't matter to SOAP, because what you're transferring is a black box to it anyway. You will need to sort out the details in your serializer/deserializer (you need that because SOAP does not know anything about your parameter types).


Ping & DNS - my free Android networking tools app
uwe hennig
Greenhorn

Joined: Feb 15, 2013
Posts: 3
Hi, I have the same problem.
The web service interface should handle many different client objects of type Event. All modules within the server can have their own events derived from class Event, which belongs to a corresponding client event.
But I think it is a stupid design, if the web service interface has to know all inherited events.

A web service should not behave like a postman, who say " I can't deliver the letter, because I do not know the content of the letter".

My Event class is abstract, so the server has not idea how to create an object. Is there a way to implement this idea?

I'm interested in any solutions and design ideas on that!
Thanks.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42264
    
  64
Why would the WS interface have to know all possible events? Assuming that you're building a WS using the JAX-WS API, you'd use JAXB for the Java<-->XML binding, and the rest happens automatically. (Obviously, you can't transfer Event subclasses from one side to the other for which the class file isn't present on both sides, in case that's what you're asking.)
Hikari Shidou
Ranch Hand

Joined: Jan 22, 2013
Posts: 88
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
uwe hennig
Greenhorn

Joined: Feb 15, 2013
Posts: 3
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


Well, the problem is, that the server has to create an object of type Event on the server side, but he only knows the abstract class or interface.
My problem is, that I have many different modules with its Event- classes. The web service should delegate all requests to the modules.
A specific client can create specific Event objects, so that a module can check if he can handle the event. In some sense the client and server have the same classes, but why should the web service know all implementations of type Event?
How can I crate an web service method with an abstract parameter? Is this possible?

Hikari Shidou
Ranch Hand

Joined: Jan 22, 2013
Posts: 88
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.
uwe hennig
Greenhorn

Joined: Feb 15, 2013
Posts: 3
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.



Thanks for your answer. I'm really thinking about architecture.
But let me give the complete example:

I have different shares. You can buy, sell, borrow or lend these shares.
Each share has different data, depending on its type. For example you can have bond issues, stock, coupon and so on..

The modules are for example are "share portfolio", "balance system" and many others.

An event can be "Buy a coupon".
So I have many events - all combinations between share types and event types.

In this case the portfolio module will add a new coupon and the balancing system will calculate new values for "profit and loss".

I think an easy web service method is like this
public void register (Event event);

So the client knows exactly what to do to create a specific event "buy a coupon" and each server module can do specific processes on that.
The web method should not know these specific details.

The event can have a method like "getType()", which will return "BUY, SELL,.." or "getIsin()", which will return the share identifier.
On the other hand I can add another attribute to the web service method.

public void register(Event event, Share share);

But - here you have same problems, because you have many share types and "Share" is a an abstract definition of shares.



You are right by saying "not loosed coupled", but the client system and the server must speak the same language and both systems are in different environments ( client PC and Server).
I would like to have transparency and universality.


FatEvent: Maybe an answer, but I don't like it. Shares can have too many different (sometimes distinct) attributes.
PropertyList as Parameter: Well, stupid idea, but it can be the solution.















 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: apache axis, inheritance and overloading