Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link

uwe hennig

+ Follow
since Feb 15, 2013
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by uwe hennig

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.

9 years ago

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?

9 years ago
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!
9 years ago