From a client perspective, you're trying to invoke a remote service by sending it a SOAP message. When you build your client, you use a SOAP toolkit to generate the code that converts a request into a SOAP message and converts the response into something your application can understand. This code, called a client proxy (or client stub) is normally generated from the WSDL description. You want to use a SOAP toolkit that supports your client application's native language, e.g., Java or Visual Basic.
From the service perspective, a Web service is an application that responds to requests sent via a SOAP message. Most SOAP messages are sent over HTTP, so you need an HTTP server (also called a Web server) to process the HTTP messages. In a Java environment, the SOAP runtime server is usually deployed as a servlet, so you also need a servlet engine (part of an application server). You don't need an EJB container unless you are building your Web service with EJB components, and it's entirely up to you as to how you persist your data.
When you build a Web service, you use a SOAP toolkit to generate the code that converts the SOAP message into something your application understands (data or objects in the application's native language). This code is called a SOAP interface. The SOAP interface and the code that implements the application generally get deployed in a Web server or an application server. SOAP doesn't dictate how you implement the application code. The specific deployment platform depends on how you've built the application and which SOAP implementation you use. If the application is a set of EJB components, then you need to deploy the service in an EJB container. If it's a set of Java objects, you'll probably deploy it in a servlet engine. If it's a VB application, you'll have to deploy it on Windows (the .NET framework is the application server). Some SOAP implementations are tied to a specific platform. For example, Web services built with BEA Workshop (aka Cajun) must be deployed in WebLogic. Other implementations support cross platform deployments. For example, Web services build with Systinet WASP can be deployed in WebLogic, WebSphere, Oracle9i, iPlanet, Borland, Orion, JBoss, Tomcat, or Jetty.
This was first published in April 2002