I have seen the fibonacci web services example on http://www.onjava.com/lpt/a/1578 and I have some doubts in it. I have parallely gone through upto SOAP, WSDL and just started JAX-RPC in Monson Haefel book.
1. Usually the service provider will have the interface and implementation in their own language like Java (Fibonacci.java and FibonacciImpl.java) or C++. Then he will generate the WSDL (WDL2Java or WSDL2C++) from their language (Java or C++). For generating this WSDL whether he needs both java interface and implementation or java interface alone is enough? And also I have noticed that FibonacciImpl.java is not implementing Fibonacci.java, why?
2. Now we have the WSDL and also it tells where our services runs and other required details fro accessing it. Then why the service provider itself again generating the Java from WSDL (WSDL2Java)? Is't not the job of the client? Since client will get the WSDL and why can't the client generate the rest of the thing?
3. After generating the WSDL2Java, why we are modifying the FibonacciSoapBindingImpl.java?
4. After deploying, our fibonacci service will be running in our tomcat server, so that the client can access it using FibonacciTester.java. 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?
5. I cannot able to see any SOAP request or SOAP response message in this process. How Can I see the SOAP Messages in this example?
6. For what purpose we are using Administer Axis and SOAPMonitor? What type of security risk will it have? Since, I am learning web services from the office desk whether enabling this features will have any security risks?
Of the above 6 steps, the service provider has to do upto the 5th step for exposing his services and the last step(6th) will be performed by the client for accessing the service. Whether it's the step followed in the real time also? or these steps will be differ for different servers.
Whether we can use AXIS with any other application servers like weblogic, websphere?
Whether without AXIS, and only with application servers like weblogic, websphere can we able to expose and access a web service?
[ November 13, 2007: Message edited by: Mike Thomson ]
[ November 13, 2007: Message edited by: Mike Thomson ]
[ November 13, 2007: Message edited by: Mike Thomson ] [ November 13, 2007: Message edited by: Mike Thomson ]
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.
Also note that the JAX-RPC API (which you talked about learning) is deprecated in favor of JAX-WS. From what I understand it may not even be present in the JEE 6 standard. So I wouldn't spend a lot of time learning that.