The significant advantages of the Java-to-WSDL approach are:
It is a quick way to expose legacy implementations as Web services.
It requires little or no knowledge of WSDL or XML because the WSDL document is generated by the tools.
It provides better and easier support for exposing overloaded operationsThe disadvantages of the bottom-up approach are:
The generated schema defining the data types in the WSDL document derives only from the Java classes from the provider's environment and not from any standards-based schema.
The provider-side data types may not be simple DTOs, in that they include additional business logic. Such logic can't be reconstructed on the requester side.
The generated schema is embedded in the WSDL, which makes reuse of the schema, perhaps in the definition of other Web services, more difficult. It is possible, of course, to extract the schema from the original WSDL document.
The development of the server-side Web service implementation and the client-side Web service requester can't proceed in parallel. The server-side skeleton and DTOs have to be developed before a WSDL can be generated that can be used to generate the client-side stubs and DTOs.
Incremental changes to the interface are more difficult to manage. For example, if the interface of the class that implements the service is changed and the WSDL is regenerated, more significant changes could occur in the WSDL, thus causing interoperability with existing clients to fail. The basic problem is that, on the server-side, the class implementing the service is deemed the master interface and, on the client-side, the WSDL provided by the server-side is the master interface. These two different masters can cause the interfaces to become out of sync and difficult to debug and fix.
The namespaces of the embedded schema types are typically generated from the Java package names of the server-side JavaBeans. Therefore, if the package names are changed, the namespace will be changed, which means the types are no longer compatible. Most of the tools allow a package to namespace mapping, but this must be explicitly set during the execution of the tool.