On Sun, 2003-02-02 at 13:52, Anne Thomas Manes wrote: > 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.
W/r/t Orion Server, this is completely false. Orion server is a full J2EE solution WITH an EJB container (and a pretty good one at that). > 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 > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > -- ======================================= Jess Sightler Senior Developer Exim Technologies 131 Falls Street Greenville SC 29601 Phone: 864-679-4651 =======================================
