Difference between top down and bottom up approach?

In Top Down we can create client program from WSDL even though web service 

provider is not developed.....

Object/XML Mapping issues:-

Fragility

As mentioned earlier, 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 contract and redeploy it, there might be subsequent changes to the 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.

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.

Reusability

Defining your schema in a separate file allows you to reuse that file in different scenarios. If you define an AirportCode in a file called airline.xsd, like so:

<simpleType name="AirportCode">

    <restriction base="string">

        <pattern value="[A-Z][A-Z][A-Z]"/>

    </restriction>

</simpleType>

You can reuse this definition in other schemas, or even WSDL files, using an import statement.

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.

Restrictions:-

It is difficult to enforce restrictions in code and then generate WSDL. For instance, If the WSDL/XSD requires that an object can be nillable, then the developer may need to replace the primitive data types with their wrapper classes and regenerate the WSDL. Some developers use array in their code and when they generate WSDL it defines the datatype as arrayOfStrings. This is strictly discouraged by the WS-I basic profile as it causes interoperability issues. Remember, consumer of a web service can generate client in any language and he should have that freedom. You cannot use features that are not compliant with WS-I basic profile. There are various tools in market that allow you to check if your WSDL is WS-I BP conformant and it is very helpful for any developer who uses contract first approach. Obviously, you may not want to keep changing you code until it generates a WSDL that is WS-I BP conformant.

Documentation

If your project is a typical SOA project then you must be using a service registry/repository to provide SOA governance. As everyone knows a registry stores metadata about the service and is a catalog of services, it should contain a lot of intricate details (version, milestones, creat date, expiration date etc) about any service. The serviceregistry inherits a lot of information from your WSDL which means that the WSDL should be descriptive and should not require administrator to enter details manually in registry or should not require client to access registry for details that can be documented in a WSDL. The documentation element of a WSDL is an important place holder for such information but most of the tools do not generate documetation element inside WSDL.