Why use a container?

[Mark Slater <ma...@analogsoftware.com>]

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

SOAP message processing model / performance [Re: Why use a container?]

[Aleksander Slominski <as...@cs.indiana.edu>]

Jim Murphy wrote:

> 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.

hi,

i would like to clarify here one point that may be confusing about 
"dispatch to a java method to start generating a response":
* when receiving SOAP 1.1/1.2 it is possible to overlap socket reading, 
parsing, and processing (dispatching) as data can be pulled out when 
needed and processing CAN be started with incomplete data (under 
condition that you extra careful to have two phase processing: first 
SOAP headers then SOAP body)
* when sending SOAP 1.1/1.2 message it is NOT possible to overlap 
producing content of SOAP:Body and sending UNLESS you can guarantee that 
no fault will happen because SOAP:Fault must be first immediate child of 
SOAP:Body so if you have put any content in SOAP:Body (partial response) 
that prohibits you from sending fault ...

let me know if i missed something?

thanks,

alek

ps. i believe the solution to it would be similar to any protocols i.e. 
to have SOAP:Footer alas it is too late for it (or as a hack to allow 
SOAP:Fault to be immediate child of SOAP:Body but on any position ...)

-- 
The best way to predict the future is to invent it - Alan Kay

Re: Why use a container?

[Jim Murphy <jm...@mindreef.com>]

Here's what comes to mind...I'm sure there's more:


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.

Newbie question re attachments sample WSDL

[p2...@garethwestern.com]

Hi,
I've seen this question posted a few times, but I don't recall seeing an
answer... does anyone know why, when one tries to view the echoattachment
sample wsdl, provided with Axis, the following error is returned:

Fault - ; nested exception is: 
WSDLException: faultCode=OTHER_ERROR: Can't find prefix for
'urn:EchoAttachmentsService'. Namespace prefixes must be set on the Definition
object using the addNamespace(...) method.: 


AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode: 
 faultString: WSDLException: faultCode=OTHER_ERROR: Can't find prefix for
'urn:EchoAttachmentsService'. Namespace prefixes must be set on the Definition
object using the addNamespace(...) method.: 
 faultActor: 
 faultNode: 
 faultDetail: 

Thanks for your time :)

Re: Why use a container?

[Anne Thomas Manes <an...@manes.net>]

Mark,

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