A servlet container is a container within an application server that can host Java servlets and JavaServer Pages (JSPs). All J2EE application services include a servlet container. They also include an EJB container. There are a number of application servers that provide a servlet container, but not an EJB container. These app servers are generally referred to as a servlet engine. Examples include Apache Tomcat, Jetty Server, Caucho Resin, and Orion Server. Tomcat and Jetty are open source. Resin and Orion are very low cost by comparison to J2EE app servers. A servlet engine is a lightweight app server that offers a bunch of resource optimization features that support the 80/20 rule. Most people find that a servlet engine meets their scalability requirements. An EJB container uses a different set of optimization strategies that impose a lot more overhead, but turn out to be extremely valuable when dealing with very high scalability requirements and transaction and security management. (Note that the performance and scalability features of an application server -- whether it's just a servlet engine or a J2EE server -- varies dramatically by implementation. I really like Jetty for its lean and mean performance. Orion is one of the best scaling servlet engines. In my opinion, WebLogic offers the best scalability for both servlets and EJBs.)
There's no doubt that a C++ environment will offer higher performance than a Java environment. Ask Systinet. WASP for C++ is a *lot* faster than WASP for Java. The two environments use basically the same architecture, but C is just faster than Java. Even so I suspect that it would be easier to make WASP for Java support massive scalability than WASP for C++. All you have to do is deploy it in WebLogic. There isn't an app server comparable to WebLogic for the C++ world. (well -- there's Tuxedo -- but I don't know of anyone who's developed a SOAP platform for Tuxedo yet). But since C++ is so much faster than Java, the threshold at which you need a really high-end app server is quite a bit higher. The first decision you need to make is whether you'd like to develop in Java or C++. C++ offers better performance. Java offers huge productivity gains. Anne > -----Original Message----- > From: Chuck Musser [mailto:[EMAIL PROTECTED]] > Sent: Sunday, February 02, 2003 11:37 AM > To: [EMAIL PROTECTED] > Subject: Re: standalone vs. servlet > > > Anne, > > Thanks for your response. As you probably suspected, when I said > "native", I meant something written in C, C++ or some other language > that gets compiled to machine code. Things of that nature are obviously > faster, so I guess my question really boiled down to: what are the > advantages of an application server such as Apache and Axis (lots of > built-in functionality, scalability) and what are the disadvantages > (complexity, possibly lower raw performance). > > Based on what you've said, I'm leaning more toward the server-based > solution. I'd not taken that into consideration until you mentioned it, > but my application would probably need multiple services. It looks like > a simple standalone solution won't support that, at least not elegantly. > I still don't know whether a given server is "fast enough", but that's > something I'll have to mock up and test myself. > > A final question: is a servlet container the same thing as a J2EE server? > > Thanks, > > Chuck > > Anne Thomas Manes wrote: > > >I'm not sure that I understand what you mean by "native" versus > Java. A SOAP > >implementation provides language bindings for SOAP. Axis supports Java. > >gSOAP supports C or C++. If your application is written in Java, then you > >need a SOAP implementation that supports Java. If your application is > >written in C or C++, then you need a SOAP implementation that > supports C or > >C++. If your application is written in Perl, then you need a SOAP > >implementation that support Perl. If you use multiple progamming > languages, > >then you need multiple SOAP implementations. > > > >Assuming that your SOAP service communicates using HTTP, then > you must have > >an HTTP server associated with the SOAP service. Most SOAP > implementations > >take the easy route and rely on an existing HTTP server. > > > >The main component of a SOAP implementation is a SOAP message > processor. The > >SOAP message processor processes SOAP messages, identifies what > to do with > >the message (i.e. identify what application to invoke to process the > >message), transforms the SOAP message body into native language > objects, and > >load/invoke the appropriate application. If the SOAP engine needs to load > >the program, it generally uses an application server/container > to host and > >manage the applications. > > > >There are three basic configurations: embedded, standalone, server-based. > >1 - The embedded option allows you to embed an HTTP server and the SOAP > >message processor within your application. > >2 - The standalone option essentially creates a dedicated > application server > >to load/manage your services. > >3 - The server-based option allows you to run the environment in > and rely on > >the application management facilities of an existing application server. > > > >In general, if you have only one service, the embedded option is the most > >efficient. Options 2 and 3 allow you to share resources, which > is important > >when you're dealing with multiple services and multiple clients. > A high-end > >application server often provides a number of features (clustering, > >multithreading, resources pooling, etc.) that you need for high > scalability. > >So in general, you'll achieve your best raw performance (highest > throughput > >for one user) when using option #1 or #2. You achieve your best > scalability > >(highest throughput for many users) when using option #3 with a highly > >scalable app server. > > > >C++ is faster than Java, so C++ SOAP is faster than Java SOAP -- > in terms of > >raw performance. > > > >I believe that gSOAP only supports the first option. If you have only one > >service, it's a simple and easy way to implement a service. If > you have lots > >of services, it's not the most efficient use of system resources. One > >caution about gSOAP is that it only supports RPC/encoded, which > might cause > >interoperability issues. Your other C++ options include Systinet WASP for > >C++ and RogueWave LEIF. WASP supports all three options. For > option #3, it > >can be deployed within Apache Web Server, IIS, and Netscape Web > Server. LEIF > >only supports option #3 using RogueWave's C++ servlet-like engine. > > > >Axis doesn't provide a built-in HTTP server or application server, so it > >assumes that you will use a servlet engine to host the > environment. You can > >create a dedicated server (#2) or you can deploy it in pretty > much any J2EE > >application server (#3). You have more than 20 Java SOAP > implementations to > >choose from. Most implementations assume that you will deploy using a > >servlet engine or J2EE application server. Systinet WASP for Java and The > >Mind Electric GLUE both support all three options. Killdara > Vitiris supports > >only the embedded option. > > > >As far as performance testing tools, I can recommend Mindreef SOAPscope. > >It's really a diagnostic tool rather than a performance testing > tool, but it > >can measure throughput. > > > >Regards, > >Anne > > > > > > > >>-----Original Message----- > >>From: Chuck Musser [mailto:[EMAIL PROTECTED]] > >>Sent: Saturday, February 01, 2003 12:26 AM > >>To: [EMAIL PROTECTED] > >>Subject: standalone vs. servlet > >> > >> > >>I'm evaluating SOAP servers with an eye toward performance and ease of > >>deployment. My instinct is to prefer a native SOAP implementation over a > >>Java implementation and to prefer a standalone implementation over one > >>that lives inside a servlet container. But I'm new to this stuff, so I > >>really don't know. I do realize that Java has lots of built in > >>networking and database connectivity that native implementations don't > >>have. Has anyone evaluated these issues: > >> > >>1.) Are there advantages to deploying Axis inside a servlet container > >>rather than using the standalone server? > >>2.) How does the performance compare for servlet vs. standalone? > >>3.) How does the throughput of Axis compare to a "native" > >>implementation, like gSOAP. > >>4.) What sort of testing tools are available for evaluating the > >>throughput of various SOAP servers. > >> > >>Thanks, > >> > >>Chuck > >> > >> > >> > >> > > > > > > > > >
