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.
Roy Hoobler moderates our Enterprise Developer Forums -- .xJN4aAKSfbb^0@.1dcf7f11!viewtype=&skip=&expand=>Post your question for Roy.
Macromedia JRun 4.0
* Built-in Web Services Support
* Hot Deployment and Hot Modification
* Superior EJB 2.0 Support
* JINI-Based Enterprise-Class Clustering
* JMX Service-Based Architecture
* EJB Development and Deployment Tool
The machine I tested on was a Pentium 500 with 256MB of Ram running the Windows 2000 Server. During the install, there are options to configure JRun to run as a service, and how it should start. The installation process is well thought-out; JRun found my JDK 1.3.1 and set everything up with no problem. I did a full install of the 30-day trial edition. After 30 days, it reverts to a developer edition which Macromedia states will only accept request from the development machine (or localhost). Just to get started, I chose not to setup JRun as a service or to start automatically.
The documentation, especially the "Getting Started" and the "Programmer's Guide PDF" documents, is very good. Not wanting to spend too much time trying to learn JRun by trail-and-error, the instructions and overviews in these two guides were a big help. Other documents cover a variety of J2EE topics, including JMS and EJB. For a few options (such as Deploying an EJB), JRun has implemented helper classes to make things easier but also explains the J2EE "standard" way of doing the same task.
JRun has two basic tools or utilities to configure and control the server: The JRun Launcher and the Management Console. The Launcher is used only to start Web servers and takes up a lot of memory for what it does. I quickly switched to using the command prompt for starting and stopping services. The Management Console is discussed below under "Managing Web applications."
Deploying a Web service
Using Apache Axis (see previous review), JRun has two methods of deploying Web services. The first is by creating a class and renaming the source code from .java to .jws. Once in the Web service directory (WEB-INF/classes), this class will act as a Web service and be able to respond to a SOAP request. One thing to watch out for is making sure this class compiles in the environment. If there is a problem with the class, Axis reports a generic error ('something is wrong with this Web service'). At first I thought something was wrong with JRun, it took me a while to figure out my class was just not compiling.
The second method involves creating a deployment descriptor file for the Web application. To configure your Web service, you need to create a .wsdd file in the WEB-INF directory of your Web application. I started by copying the existing server-config.wsdd file from the /samples/compass/compass-war/WEB-INF directory, then changed the configured Web service to use my classes. Everything worked fine, going this route -- using the syntax host/services/dictionary?wsdl creates the WSDL needed to create the client. I found this difficult with the Axis version, but following the JRun examples, I got it to work the first time with no problem.
The "Getting Started" documentation explains in detail how to setup a Web service, but you still need a good understanding about Web services including WSDL, proxy classes, and possibly SOAP (if you have worked with Apache Axis or .NET it is much more obvious what is going on). Using Web services with JRun is a learning curve but not as much so as working with only the Apache Axis documentation.
The Web services configuration (deployment descriptors and classes) is placed in the WEB-INF directory of the Web application. This approach is good because virtual host and applications can run independently of each other. Web services are matched to the URL path /services/, just as servlets are mapped to /servlet/. So to run a Web service, the URL is something like http://localhost:8200/services/myWebservice. A nice example of a Web service is installed under the "Compass Web" application on the sample server.
In the programmer's guide, under "Web Service Security," is an overview about configuring Web services and Web applications in general. Of course, security is important so find out as much as you can with the documents. Macromedia did a good job giving some guidelines to help those that haven't had a lot of experience in setting up a production server.
Consuming Web services
If your Web application needs to consume Web services, JRun might be a better choice than most. Again, the documentation is well laid out and each step is defined. To start, you will need to obtain a WSDL file published from a service to create a Proxy class (using the WSDL2Java utility). Next, you can use the proxy to connect to the Web service. Several different ways to invoke a Web service are explained. There is a tag library included, as well as the Apache classes. However, it might have been better recommending a more specific approach for certain types of services and explaining to developers that if you are using complex or non-standard types, using the tag library is probably not the best choice (managing all these tags is just as complicated as programming a wrapper class and your own, simpler, tag library).
Managing Web applications
With JRun, Web services fall under a Web application. The Web-based Management Console (Figure 1) is similar to previous versions. The admin Web server must be started before using the Management Console. More features such as Clustering (adding JRun servers to a group to handle more requests), and Registering Remote Servers (to administer another Web server machine from the current Web-based UI), are part of this interface.
From the management console all types of settings can be viewed including Web services, data sources and J2EE components. However, a lot of the settings still require getting into the XML configuration files. Servers can also be started, stopped, and restarted using the Management Console. On my development machine, I changed the default settings to run all servers with only 64MB instead of the default 128MB -- this helped the memory problem but slowed everything down quite a bit.
Connecting to a database with a data source
The Management Console allows an administrator to set up JDBC data sources but I had to really dig through the documentation for an explanation on how to use the JRun data source within a servlet (an example is in the "Programmer's Guide" under 'JRun and XML'). Also, if your Web applications need good database support, JRun includes many JDBC drivers (MS SQL, Oracle, DB2, Sybase, and Informix). JRun's built-in connection pooling could also be a key factor in deciding whether or not to purchase the software. The sample Web sites use data sources and the Java PointBase database server that loads when the sample Web server starts.
Deploying a Web application
To make things easier, I unpacked a .war file from another server to the /default/sample directory. Everything worked well except for a .jsp page that called a Web service. After copying my proxy class in the /lib directory, everything worked fine. Logging back into the Management Console, my new Web application appeared and I could make some minor adjustments from there.
The biggest problem to watch out for is that JRun takes a lot of memory. On one machine with 256MB of RAM, I continuously was running out of memory trying to start the admin and sample Web servers. The specifications state you need 128MB but I'd really recommend using a Pentium 600 machine with 256MB (or better yet 512MB) of memory even for a development server that only has JRun on it.
Overall, JRun would be great for a Java shop to start working with Web services if they are not already using a Web services enabled application server or have clients that need an inexpensive solution. The HTML and PDF versions of the documentation are worth the single CPU license. There are not so many "Wizards" but the documentation makes up for it. The alternative would be to invest in a more expensive application server or start connecting software together (this vendor's application server with that vendor's Web services software). A lot of vendors are promoting their proprietary development products on a per user license. Again, JRun's Server/CPU licensing and use of open standards make sense.
- Definition and Best Web Links and Expert Advice for J2EE
- Definition and Best Web Links and Expert Advice for SOAP
- Definition and Best Web Links and Expert Advice for WSDL
- Definition and Best Web Links and Expert Advice for .NET
- Definition and Best Web Links and Expert Advice for EJB
- Definition and Best Web Links and Expert Advice for JMS
For More Information:
- For insightful opinion and commentary, read our Guest Commentary columns.
- Tired of technospeak? The Web Services Advisor column provides a clear understanding of Web services.
- Looking for shortcuts and helpful developer tips? Visit our Tip Exchange for time-saving XML and .NET tips.
- Visit our huge Best Web Links for Web Services for hand-picked resources by our editors.
- Discuss this article, voice your opinion or talk with your peers in our Discussion Forums.
- Visit Ask the Experts for Web services, SOAP, WSDL, XML, .NET, Java and EAI answers.