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