What is the difference between a top-down web service and a bottom-up web service?

Question

In Java, what is the difference between a top-down web service and a bottom-up web service? Also, what is the difference between a SOAP and a REST-ful web service?

Solution 1

Top-down means you start with a WSDL and then create all the necessary scaffolding in Java all the way down.

Bottom-up means you start with a Java method, and generate the WSDL from it.

SOAP means that the URL is the same for all invocations, and only the parameters to the Java method differs. REST means that the URL plus the HTTP method invoked on it reflects the operation to be done.

Solution 2

Contract-first versus Contract-last

Bottom-Up : approach takes a high level definition of the problem and subdivides it into subproblems. i.e. Contract-last.

• Advantages

  • Code first
  • Initial stage very easy to develop.

• Disadvantages:

  • Maintenance is very very hard.
  • Tightly coupled

---

Top-Down : Think of the basic functionality and the parts going to need. i.e. contract-first.

There are the following reasons for preferring a Top-Down development style.

1. Fragility The contract-last development style results in your web service contract (WSDL and your XSD) being generated from your Java contract (usually an interface). If you are using this approach, you will have no guarantee that the contract stays constant over time. Each time you change your Java code and redeploy it, there might be subsequent changes to the web service contract. Aditionally, not all SOAP stacks generate the same web service contract from a Java contract. This means changing your current SOAP stack for a different one (for whatever reason), might also change your web service contract. When a web service contract changes, users of the contract will have to be instructed to obtain the new contract and potentially change their code to accommodate for any changes in the contract. In order for a contract to be useful, it must remain constant for as long as possible. If a contract changes, you will have to contact all of the users of your service, and instruct them to get the new version of the contract.

2. Performance When Java is automatically transformed into XML, there is no way to be sure as to what is sent across the wire. An object might reference another object, which refers to another, etc. In the end, half of the objects on the heap in your virtual machine might be converted into XML, which will result in slow response times. When using contract-first, you explicitly describe what XML is sent where, thus making sure that it is exactly what you want.

3. Reusability Defining your schema in a separate file allows you to reuse that file in different scenarios.

4. Versioning Even though a contract must remain constant for as long as possible, they do need to be changed sometimes. In Java, this typically results in a new Java interface, such as AirlineService2, and a (new) implementation of that interface. Of course, the old service must be kept around, because there might be clients who have not migrated yet. If using contract-first, we can have a looser coupling between contract and implementation. Such a looser coupling allows us to implement both versions of the contract in one class.

Solution 3

@mad_programmer - You mean building Web Services with a Bottom Up or Top Down Approach. In the first, you start programming the classes and business logic as java code and then generate the web service contract (i.e. WSDL) from it. The latter approach means the opposite (generating class stubs from the WSDL).

Solution 4

Supporting the answer of andersen, i would like to add a point. Basically people tend to use Bottom-up approach, because in most of the cases, we would have already started the process of writing the beans, business logic etc, then in the persistence layer, we create the web-services, wsdl's etc. where as in a new project, where you are building something from scratch, we can use top-down approach, where we just write the wsdl and building the skeleton would give you the beans, implementations, interfaces etc. Still, remember computer cannot generate the logic you want. So, still you need to go through the whole project and fill in the gaps.

Solution 5

Adding to the answer when a project is started from scratch usual approach is to create a very basic interface and then create a WSDl from it. This will save you from writing complex WSDl. Then we can add project specific operations in WSDl directly and once WSDl is finalized we can go ahead with top-down approach.

View more solutions

Comments

[Abimaran Kugathasan]

Contract First VS Code First..

[Anthony Accioly]

For the SOAP vs REST, I think your answer is fair considering the amount of effort in research the OP put before asking... But still, here are some articles that may dig a little bit further: en.wikipedia.org/wiki/Representational_State_Transfer and en.wikipedia.org/wiki/SOAP

[matbrgz]

@AnthonyAccioly Wouldn't your comment fit better as part of your own answer?

[Akshay Lokur]

@ThorbjørnRavnAndersen: Some correction: In REST, URL does not reflect "operation" to be done! It is the HTTP method (viz. GET, POST and so on) which reflect "operation" to be done on the resource identified by the URL.

[Yogendra]

I like this answer as this would avoid the manual human error in writing xsd and wsdl files. However, do you think the wsdl file generated will be portable across various JAX-WS implementations?