Roy Hoobler has been involved with Internet programming from 1995 and developing Web businesses and "niche" market sites since 1996. In 1997, he completed his MCSD certification and worked for a large consulting firm primarily focusing on Intranet and Extranet applications for fortune 1000 companies. In early 1998, seeing the potential of how business would be conducted on the Internet, Roy joined Net@Work Inc. (www.netatwork.com) where he designs (and still codes) business and cutting-edge e-commerce applications using a wide range of technologies, including XML.
Post your questions to Roy Hoobler in our --> .xJN4aAKSfbb^0@.1dcf7f11!viewtype=&skip=&expand=>Enterprise Developer Forum
Apache has been developing Apache SOAP for well over a year. The latest version (now called Axis) is a major improvement and works great. The utilities to work with SOAP and WSDL are much more mature and Web services can be created by dropping a Java file into the SOAP/Servlet container. As contributors to the Axis project, IBM has been touting their Web service technology, labeling these Java SOAP classes and a few others as their 'Web service toolkit'; Apache.org states it more properly as SOAP classes. Five or Six .jar files need to be appended to the CLASSPATH and a few include utility classes that can be used from the command line. I eventually setup a project with Forte (from Sun) which made things easier.
As with most Apache Java projects, the implementation and source code can be downloaded from the Apache.org Web site. Zip files are available for Windows platforms and .jar files are available for Linux and other platforms. I have installed many of the projects on Windows and Linux platforms and they always work fine. There is usually nothing to install, just extract the files to a directory on your system and start including the .jar files in your CLASSPATH. With a development environment like Forte, it is easy to add .jar files to your project, replacing the need of adding them to your CLASSPATH.
You will need a servlet container or a Java Web server installed. For development and testing, I recommend using Tomcat from Apache (it is located under the Jakarta project) because it is small and easy to configure. The next step is to copy the /webapp/axis directory from the Axis installation directory to the webapp directory on your Web server (Tomcat, iPlanet, JRun, WebSphere, etc.) and restart the service.
Running the examples:
About eight examples are included with the Axis project. The Calculator example runs a simple add/subtract Web service and is well put together. The Stock Quote example may not work since it relies on an external XML download. This external XML file was not available when I tried and caused the demo to fail, so start with the Calculator example. If you haven't worked with Java or Web services very much, study through all the examples before trying something on your own. Developers don't need to worry about how the SOAP messages are actually constructed or sent, but should get familiar with a few classes including the CALL class.
Wow! Apache Axis implements "drag and drop" Web services. First, rename a Java source code file with a .jws extension. After renaming the file with the .jws extension, drop it into your webapp/axis directory and you are done. No more steps. Axis compiles and publishes this .jws class as Web service. That is easy! Now there is a Web service running at "http://myhost.com:8080/axis/myclass.jws". You don't need a framework: register a bean serializer, or run a special application to do this. The documentation states most beans and standard types can be used in a JWS class but some types might not work (or other non-Java classes). My test used String and Integer classes with no problems. Calling a method that took more than one parameter didn't work as I thought it should, but after looking at the Calculator example, I fixed my code and the Web service worked fine.
WSDL utility classes:
WSDL support seems to be more on par with Microsoft .NET. This is important for interoperability between the two platforms. Just to see what would happen, I took a WSDL file of a Microsoft Web service that accepted two objects which contained a total of 15 'get' and 'set' methods for Integers, Strings, and one String Array and ran the WSDL2Java utility. Axis had only one minor problem creating the stub (or proxy) Java classes needed to create a client. With the old Apache SOAP classes, it took a day of trying to fix the WSDL file and it still never worked. The only thing I had to change in the Microsoft WSDL file was a HTTPS URL to HTTP. My system may not support HTTPS because I don't have JSSE installed and configured. I also didn't try actually using the client since this is a live Web service. Just being able to create a valid proxy client is a big step and a good start.
Another Axis utility class (Java2WSDL) creates a WSDL file based on a Java class. WSDL files are used to create clients for Web services. It took several tries to get the parameters correct to get this to work. Remember to specify a valid URL where your Web service will be located. From scratch, I made a new Java class with a couple of public methods, which called a public class in a English - Korean dictionary application. Next, I saved this file and then used the Java2WSDL utility to create a WSDL file. Finally, I renamed the source file with a .jws extension and put it in the /webapps/axis directory. With my Web service copied into the right directory, I used the WSDL file to create a client application on another machine and invoked the Web service to retrieve the result.
Web services can also be deployed by creating a .wsdd (Web Service Deployment Descriptor) file and registering the class with Axis. I found the .jws files easier to work with, but depending on your environment, using .wsdd may be a better practice. More about this is explained below.
After a few hours, not only had I gotten two of the samples to work, but actually deployed my own Web service to my server. The English to Korean dictionary is simple, but I may post it to xmethods Web site soon so others can find and use it.
Things to look out for:
There is no user interface, or even a 'generic script' you can run to create your own classes. In a way, it is better for programmers to learn how this works before playing around with the technology. However, a tool that automates any of this would be great. Having a development environment might be too much to ask, but a utility with a GUI where you can save your CLASSPATH and create WSDL files by selecting a Java class could be included. There are .bat files and .sh files to run the examples, these are a good place to start developing some automation tools. Even having a quick overview about setting up a Forte project would be nice, especially for beginners.
The tutorials do not address the options needed when using utility classes such as Wsdl2Java and Java2WSDL. Most of the time a URL and/or Namespace is required. When a required parameter is missing, these utilities also do not tell you what is required, rather list all the options available. More information about these utility classes are in the API documentation, a reference to the API from the users guide would be nice.
A service can also be deployed manually by creating and registering a .wsdd file. Again, watch for options and parameters. If you deploy a service this way, a WSDL file can be created on-the-fly from a Web browser using the syntax "http://www.mysite.axis/services/class?WSDL". Allowing .jws files this same functionality would be helpful. After creating a service via copying a .jws file, a WSDL file cannot be created as above.
These are not complaints - just things to watch out for when using Axis. A few of the above issues may just be a learning curve or getting familiar with using the technology. For complaints or suggestions, mailing lists are available to join the community at the Apache.org Web site. For more information or corrections, refer to the documentation. Spend some time going through the API documentation; I'm sure there is a lot of good information in the API docs and you'll also get a better understanding of the architecture.
If you continue with the Axis technology, take a look at the IBM Web Services Toolkit, which also includes some UDDI functionality. The IBM WebSphere Studio Toolkit is a tool (with an actual user interface I hope) to easily create and manage Web services, not just relying on command line utilities.
The drag-and-drop approach of publishing Web services is a great idea, better (at least easier) than Microsoft's .NET. I am impressed with Microsoft Visual Studio .NET but it is a much bigger system. The implementation of Axis is far better than previous versions making the idea of using Axis for development and production environments more likely. It is going to be a tough call deciding which technology to use (Java or .NET?).
Having a plan:
Reading the documentation, you might be tempted to start using your current classes for Web services. In general, this isn't a good idea. Your current classes probably contain too many public methods, or don't have the proper functions to be used in such a broad environment. An approach I have used is to create another class within a package that contains methods needed to deploy a Web service for the package. If the package is called "com.package.customer.util", I might add a "com.package.customer.util.customerWebService" class and, based upon the requirements, I might implement public methods such as: getCustomer, getPhoneList, getFindCustomerByName which return objects, HTML, or XML. These methods won't have much code since they only need to call methods of other classes in the package.
After this Web service class is tested, it can be deployed as a Web service. This means configuring the web.xml file for the application (mapping the class as a servlet) and/or deploying the class using a .wsdd file. The entire package is then compressed into a .jar file and placed in the appropriate /lib directory.
Using the drag and drop method, take the above Web service class out of the package, save it as a 'stand alone' class, and drop the file into the /axis directory and finally, rename it as a .jws file. Either way, the Web service class wraps around functionality already found within the package without modifying existing classes.
Setting up a server with Linux, Apache Tomcat, and Axis creates a robust and 'fun' environment for testing and deploying Web services in an open source environment. The only piece missing is a way to configure the environment with a GUI tool. After learning the syntax of using the included utility classes and how Tomcat and Axis work together, maintaining the server is fairly straight forward. I'm using Axis (Alpha 3), the Xerces 1.4 (from the Xalan 2.2 distribution), Jakarta 4.0, and JDK 1.3.
FOR MORE INFORMATION:
Post your questions to Roy Hoobler in our Enterprise Developer Forum