Because of your topic title I now have a silly tune in my head going "ass up face down, let me see your tootsie roll". I don't like songs like that so please don't do that again
Just kidding, top down seems to be the preferred method, even when the code already exists.
Top-Down, Bottom-Up, Middle-Out, Outside-In are general development styles that don't adequately express the concern that you are trying to address.
When was the last time that you saw a usable and competent (human-accessible) UI being generated by a tool that simply looks at the object-oriented model that implements your application? Why is it then that everybody thinks that the same can be accomplished for an interface that is entirely expressed in terms of request and response messages rendered as semi-structured XML data - an interface which is totally ignorant about objects and Java (idioms)? Doesn't it make sense that you need to have a goal (the contract as seen by the web service's client) before you can start implementing away?
Definitely contract first. I don't care how you approach the service implementation in Java as long as the implementation doesn't dictate the contract which is what Bottom-Up implies. The stubs generated from the contract by a code generator are probably not a good start to your service's internal object model either - they are merely a place to put your "glue code" to connect to your implementing object model - so the approach can't be entirely Top-Down either. You are "crossing the chasm" between structured Objects and semi-structured XML request/response messages.
And don't indulge in the fantasy that you can impose your object model onto the client - it simply is none of your business. It is entirely up to the client to marshal their data to their requests and unmarshal the data from your responses. All you have control over is the format of the requests and responses. Even if you control the client, sharing the object model may not be appropriate because the client may require a different view of the world from the one that the service has. Often a client's view is much more simplistic or simply requires different complexities than the world view of the service. This may fly in the face of the "reuse" objective - but if you try to unify an object model over too many boundaries you run the risk of ending up with an overly complex object model that is too painful to use, with heavy-weight objects that no application fully utilizes.
We conclude by discussing what is required of both systems-level and application-level programmers and designers if one is to take distribution seriously.
[ November 19, 2008: Message edited by: Peer Reynders ]
Post by:autobot
If you are using a rototiller, you are doing it wrong. Even on this tiny ad:
a bit of art, as a gift, that will fit in a stocking