A session-managed AppObject establishes a connection with a single AppServer dedicated to a single client application. This AppServer services all requests for operations invoked on that AppObject until the AppObject is released. The Web service's SubAppObjects and ProcObjects share the same connection. The connection is not freed until all the Web service objects have been released. In effect, the WSA creates copies (server instances) of these objects for each client application that accesses the same session-managed Web service, and maintains a unique object ID for each instance.
A session-free AppObject establishes no connection to an AppServer. Instead, the WSA maintains a pool of AppServer TCP/IP connections (connection pool) that it uses to send requests from all clients to any available AppServer. Requests from operations of all client applications invoked on a session-free AppObject are executed as the WSA receives them and resources are available to handle them. In effect, all clients of a session-free Web service share the same server instance of the AppObject. Requests sent to session-free SubAppObjects use any available AppServer connection in the Web service connection pool, but the WSA maintains a separate server instance of the SubAppObject for each client that accesses it using its own unique object ID until the client releases it. The WSA also maintains a separate server instance of any ProcObject accessed by a client for a session-free Web service, and each such ProcObject reserves a single AppServer connection from the connection pool dedicated for the sole use of its client until the client releases the ProcObject.
Thus, for session-managed Web service objects, the AppServer can maintain session context between requests, enabling the possibility of fine-grained, multi-request transactions on a server-side database. For session-free Web service AppObjects and SubAppObjects, there is no single AppServer to maintain session context, and any transactions on a server-side database must be coarse-grained so that they begin and end for each request before the AppServer returns the response to the client.
Note: SubAppObjects provide no additional functionality for a session-free Web service that is not already provided by the AppObject, except to organize Web service operations into developer-defined categories, much like using folders to organize files. The increased complexity of the client application required to manage the object IDs likely overwhelms any advantage of using SubAppObjects.
A ProcObject of a session-free Web service does maintain context on a single AppServer that can be used to manage finer-grained, multiple-request database transactions. But because a ProcObject reserves its AppServer connection until the object is released, that resource is not available for other requests on objects of the session-free Web service.
Note: Progress Software Corporation recommends that you avoid defining ProcObjects for session-free Web services. Each instantiated ProcObject degrades the performance of a session-free Web Service by taking AppServer connections out of the connection pool that might otherwise be used by all other requests to the Web service.
