To allow clients to access a Web service, it must be exposed on a running WSO2 SOA Enablement Server. There are two ways to do this: runtime publishing and persistent deployment. Runtime publishing is for local publication of a service on an embedded server. The lifecycle of the service ends when the embedded server shuts down. Persistently deployed services are deployed remotely on a running server. They are persistent because they are automatically re-published when the server is shut down and then restarted. The persistent deployment mechanism offers you more control over service configuration than the runtime API, especially on serialization settings (see Overview in Java Level Processing, Message Processing).

Runtime publishing is a faster way of developing your Web services, as it only involves compiling and executing the service. Using an IDE, this can usually be done with a single mouse click in the GUI or with a single hotkey. We recommend Runtime Publishing for WSO2 SOA Enablement Server running embedded in an application (as mentioned above) and for rapid development of lightweight applications.

Persistent deployment is mandated when using WSO2 SOA Enablement Server ported to another server or when you need to run WSO2 SOA Enablement Server as a separate server. We also recommend persistent deployment for heavy-duty applications. Lastly, you may use deployment when you prefer a declarative approach.

In most production environments, programmers do not have direct access to the production server. In deployment, the developer or system administrator can access the production server using Deploy and Undeploy and install and configure Web services remotely over the network.

There are two main components of Web services:

In WSO2 SOA Enablement Server, one service instance can handle multiple service endpoints. The service instance includes:

Most of the service properties and settings belong to the service endpoint. This is shown in Figure 1

Figure 1. Service Instances vs. Service Endpoints

In Figure 1, we have four service endpoints (E1, E2, E3, E4) each with its own configuration and its own path inside the server. If the server is located at http://localhost:6060/, the services are accessible at URLs like http://localhost:6060/E1.

One instance can be shared among multiple endpoints. An unlimited number of other invocations of this instance is possible while the client is in call (unless per-client instantiation is being used). Different endpoints for one instance should be on different transports (for example http://mamalas.cz:6060/E1, https://mamalas.cz:8080/E2, etc.).

	Note
	Instances must be properly synchronized to avoid race conditions, deadlocks, etc., as in servlet technology.

Service endpoints E1 and E2 share the same instance I1 that serves the requests coming to the endpoints. Likewise, for endpoints E3 and E4 and instance I2. Service instances carry the state of the service (see Service Instance State Management). Also, because a service instance is usually tied to a single Java object, the two service endpoints share the same data.

A service endpoint is tied to a single WSDL Service. Usually, two service endpoints represent two different WSDL Services, as is the case with the endpoints E3 and E4. This means that E3 and E4 are different Web services but they share the same implementation object (their service instance I2) because they are connected on the implementation level. On the other hand, endpoints E1 and E2 represent the same WSDL Service, providing two different access points for it that can have different properties, usually security properties.

For example, it is possible to set up the endpoint E1 to accept any request from the presumably safe intranet clients (please see the section IP Address Filtering) and the endpoint E2 to only accept authenticated requests (please see the section Per-Service Endpoint) from the whole Internet.

The org.systinet.wasp.webservice.Registry class holds the service endpoints, which in turn hold the service instance. These service endpoints can be looked up, customized and unpublished. The Registry, ServiceEndpoint and ServiceInstance classes contain the relevant methods. They are described in the next sections.

The service instance (see above) can have several states. The service instance states and possible transitions among them are outlined in Figure 2.

Figure 2. Lifecycle of a Service Instance

The initial state of a service instance is offline. This means that the server knows about this service instance but it has not been loaded or initialized yet. A service instance deployed with the preload flag (see Deployment) is initialized at server startup or upon deployment of said service instance. Otherwise, an offline service instance enters initialization when the enable() method is called or the first request for the service comes in.

During initialization, an instance of the service is created. If the service implements the Initializable interface, Initializable.init() is called.

The service instance is now enabled. In the enabled state, the service instance is ready to serve requests but no request is being served at the moment. When a service instance does serve a request, it is active. A service instance moves from active state back to an enabled state when it finishes all requests currently being served.

The service enters the destroying state when the disable() method has been called. This method may be called while a service is either active or enabled. In the destroying state, the service finishes all remaining requests. If the service implements the Initializable interface, Initializable.destroy() is called. In any case, when all remaining requests have been processed, the service instances are destroyed.

When all resources are free, the service goes from the destroying state into the disabled state. This state may also be entered directly, without remaining requests being processed, by calling kill(). The kill() method can be called from any state except offline, and a service can be moved from offline to disabled by calling the disable() method. Thus the disabled state can be entered into from any other state.