Actually, there are two levels of container in most Java Web Services (JWS) platforms. In most products, the default scenario is to deploy the JWS runtime in a servlet container. Meanwhile, the JWS runtime supplies its own container that manages the lifecycle of the objects that implement the service.
You're correct that an added layer of indirection adds a small amount of overhead, but it definitely increases the scalability of the environment. It isn't especially necessary if you have one service with a limited number of concurrent clients, but it is necessary if you have lots of services with lots of concurrent clients -- that's why Java application servers effectively replaced CGI and became the predominant Web application environment.
The main reason why JWS products typically get deployed in a servlet container is because it's already there, well-known, and tremendously pervasive. The JWS product needs to do things such as HTTP session handling, thread handling, and clustering. A JWS product vendor could reproduce this functionality, but there's a very well established standard for Java HTTP server processing, called servlets, and there doesn't seem to be very much incentive to create a non-standard alternative to servlets. One of the biggest advantage to using this approach is that you can use standard servlet filters to add extra processing features to the environment. Most Web Services Management products use servlet filters to intercept messages for processing.
There are a few JWS products (Axis, WASP, Glue, Cape Clear) that also support a stand-alone configuration. Most of these products include an embedded copy of Jetty (which provides the HTTP server functionality), although you can also make them work with Apache server or some other HTTP server. They typically use a dedicated mechanism (the server's high-performance invocation mechanism) to pass requests to the JWS runtime. (The HTTP server is dedicated to processing the Web service requests, also.) This type of configuration allows you to embed JWS functionality into an application so that the application doesn't need to be deployed in an app server. (Note that the Axis simple server functionality isn't especially robust, though.)
Anne
At 03:00 AM 4/5/2004, you wrote:
I get the feeling that I'm missing some simple, yet vital, part of the Web Services / SOAP implementation. Essentially, I'm trying to understand why an app container (like Tomcat) is a Good Thing for a SOAP based web service. What is it that the container provides that's so useful? As I'm writing my own small web services to learn more about the protocol, I've been writing them as simple CGI applications.
I guess, my (possibly skewed) perspective is that a web container adds another level of indirection, and since most of them seem to be written in Java, doesn't that slow things down more? I've been writing my programs in C++, but I understand that to do more complex programs I don't want to be parsing the XML myself, and that's where an outside SOAP library comes in handy, but even Axis C++ seems to need the Java interface.
So, to summarize, I'm trying to find the answers for these questions:
1.1) What is the rationale behind deploying SOAP-based services in an app container?
1.2) What does the container provide?
2.1) How does the performance of a container compare with "raw" CGI?
2.2) How would the performance compare to a CGI interface to an already running program that handles the requests (i.e. something that doesn't have to start and stop; the CGI program parses the SOAP and sends the request in some local inter-app communication format, and then bundles up the result and sends it back)? ... maybe that's what the app container is doing?
Thanks,
Mark
~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group
