Mark Slater wrote:
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.1.1: You wanna write the HTTP connection management layer yourself?
1.1.2: Folks are "used to" dealing with composable architectures based around the javax.servlet engine.
1.1.3: Servlets are standardized so a servlet based solution can run on a wide variety of platforms and can interact with existing application architectures.
1.2) What does the container provide?
Lots of stuff:
1.2.1: Security: authentication/authorization/etc at the transport layer. Makes it easy to slap on a server cert, use HTTP basic auth over https to secure a point to point web service.
1.2.2: Application/component model environemnt. Many web services are built into existing applications that are already a web site based on servlets/JSP/Velocity. The Web Service is often for programmatic access of the same features available to "wet clients" via HTML.
2.1) How does the performance of a container compare with "raw" CGI?
2.1.1: In my experience, all things being equal, its the front end connection management piece that is the real bottleneck for perf. Servicing a hello world cgi page and a hello world java servlet would have substantially the same perf and scalability characteristics. CGI may infact be slower depending on how the thread/process dispatch is implemented.
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?
2.2.1: Not sure what you mean by start and stop. Not knowing anything else I'd put my money on the perf bottleneck being at inter-app communication. In a servlet container (esp. Tomcat) things can run inprocess. So there is not extra parameter marshaling that has to happeen. Just gather the XML from the front end socket, parse it and dispatch to a java method to start generating a response. No process boundaries to cross, no other synchronization necessary.
Basically app servers are good at taking HTTP requests and providing you with options on how to dispatch it to your own code somewhere. This is a great boon to service developers that aren't interested in writing the front end.
That being said Microsoft's Indigo will has a very interesting usage model. All the HTTP work happens in Kernel mode and you can register handlers for your requests. This "bakes" in support for HTTP in every application so the app server (IIS) becomes an even tighter part of the OS. This might be a bad thing for secutity and what not but boy it sure makes sendign and receiving SOAP requests a breeze cause you can assume the same level of abstraction that an app server provides is available in any .NET managed application you write. So, thats a data point for embracing app server-like functionality. :-)
Hope that helps,
Jim Murphy Mindreef, Inc.
