Originally posted by Mike Thomson:
1. Usually the service provider will have the interface and implementation in their own language like Java (Fibonacci.java and FibonacciImpl.java) or C++.
In my opinion incorrect. This is certainly the view that the vendors have been pandering to with their
web service magic pixie dust and that is popular with application developers because they hope that they can avoid learning
yet another stupid technology and seek
shelter in the comfortable environment and paradigm of RPC and their host language.
However a true service provider
is primarily concerned with the client. Without the client there is no need for the service! And when it comes to SOAP web services what does the client see? HTTP resquest/responses, SOAP envelopes and XML payloads. And how is all that described to the client? Through the WSDL. So a true service provider would provide the client with a WSDL that is clear and simple (WSDL generated by Code-to-WSDL is usually neither simple nor clear).
The service host language interface is irrelevant to the client - the interface that matters is the interface described by the WSDL. The client itself may be implemented in Java, C++, C#/J#/VB.NET, Perl, Python, Ruby, etc., i.e. any language that can deal with HTTP connections, XML and XML schema (there is no requirement for object-orientation, for example).
The goal isn't to push the overly elaborate, complicated, and detailed object model used inside the service implementation over the wire but instead to
exchange the simplest possible
representations between the service and the client in order to complete the business process; representations that most clients won't have any trouble dealing with.
So there are good reasons to write your web service
contract-first (WSDL-first) and then have a WSDL-to-Code generator create the service interface and skeleton for you.
Java BluePrints: Patterns, Guidelines, Conventions, and Code: Designing Web Services with the J2EETM 1.4 Platform: 3.4.1 Designing the Interface
On the other hand, the WSDL-to-Java approach gives you a powerful way to expose a stable service interface that you can evolve with relative ease. Not only does it give you greater design flexibility, the WSDL-to-Java approach also provides an ideal way for you to finalize all service details--from method call types and fault types to the schemas representing exchanged business documents--before you even start a service or client implementation. Although a good knowledge of WSDL and the WS-I Basic Profile is required to properly describe these Web services details, using available tools helps address these issues.
Also note the order of the chapters in RMH:
Chapter 2: XML Basics Chapter 3: The W3C XML Schema Language Chapter 4: SOAP Chapter 5: WSDL Java doesn't make an appearance until Chapter 9: JAX-RPC Overview. (page 271) simply because the Java APIs are
simply an implementation concern.
The article "Creating Web Services with Apache Axis" starts with Java2WSDL because it simply does not have (the 150 pages of) space to teach you the basics of XML, XML Schema, SOAP, and WSDL for writing your own WSDL from scratch. Java2WSDL is a great learning tool but I wouldn't want to use it in a production environment because it gives you very little control over what your client-facing WSDL will look like.
Then why the service provider itself again generating the Java from WSDL (WSDL2Java)?
Because often in a production environment the WSDL is your primary web service interface artifact. You would change the WSDL to the new specifications and then use a WSDL-to-Code tool to generate the new service interface and skeleton. At the same time it illustrates that the same WSDL-to-Code tool can generate the client stubs which in this case you are using to
test your web service.
After generating the WSDL2Java, why we are modifying the FibonacciSoapBindingImpl.java
That is part of the service skeleton. The WSDL simply describes the web service interface - there is no information about service
behavior. So WSDL2Java cannot write the entire service for you. You must modify FibonacciSoapBindingImpl to invoke the actual service implementation (the FibonacciImpl class).
The client can get the details like service and other details from the WSDL, but how knows the package structure like fibonacci.ws.FibonacciService. In wsdl the service name is given as FibonacciService, but the below coding is using complete package..how it is possible?
Well it doesn't. When running WSDL2Java you specified to place the generated classed in fibonacci.ws with the "-p fibonacci.ws" option. The name FibonacciService results from the "service" element in the WSDL:
Because you generated the service skeleton and the client stubs at the same time they both share the same package structure. That package structure is preserved for the service inside the jar that you created and copied to Axis. The package structure also exists in the directory structure of the development directory that you run the client from.
What this URL is meant for?
As you have suspected that is the URL at which the web service endpoint is deployed.
How Can I see the SOAP Messages in this example?
Use
TCPMon (
Tutorial). It�s included with Axis.
Axis is only one possible way of implementing web services. BEA WebLogic, IBM WebSphere, Oracle Application Server all have their own flavors.
If you want to try out the RMH stuff check out:
Which is the most suitable application server to prepare for SCDJWS?