This week's book giveaway is in the Jython/Python forum.
We're giving away four copies of Murach's Python Programming and have Michael Urban and Joel Murach on-line!
See this thread for details.
Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Bottom-up or Top-down  RSS feed

 
Arjun Reddy
Ranch Hand
Posts: 629
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How can we tell what approach is better for us?/

Thanks.
 
Taariq San
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Relational/Object/XML (ROX) impedance mismatch.
Item 43: Recognize the object-hierarchical impedance mismatch (PDF)

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.

Other related topics:
Starting Out
Webservice - WSDL or Java Class
JAX-RPC to JAX-WS (Client impact)


Aside:

But Java2WSDL is so convenient.
IEEE Internet Computing July/August 2008; Vol. 12, No. 4: Convenience Over Correctness (PDF)

Why remote access shouldn't look and feel anything like local access in your code:
Sun TR-94-29 November 1994: A Note on Distributed Computing
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 Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!