Collapse all Symbian^3 Product Developer Library

Views of a Server Application System

Process view

Client objects, in the client, talk to server objects, in the server application. The client and the server are in different processes.

Service view

The diagram below shows the point of view of services which operate over the server application system. Services are things such as "printing", "send-as" and "contacts selection", which offer useful functionality to applications.

The server application framework provides generic service support over a client/server link, upon which real services can be created. A service will typically provide a client-side interface that clients can use directly, and a server-side interface that server applications have to implement.

Symbian platform component view

The diagram below shows the Symbian platform components involved in the server application support system.

The core of the server application framework support is in Apparc, built on the client/server system provided by Base. Apparc is responsible for:

supporting multiple service types over the client server link
establishing client/server connections to already running server applications
monitoring the lifetime of the server for the client.

The server application framework is specialised by Uikon to allow the launching of new server application instances for the client to connect to.

The server application framework may be specialised by System GUIs, for instance, to add policy regarding the relationships between window groups in client and server applications.

Services may be provided by Symbian or Licensees. These depend on the server application framework, either as implemented in Apparc or Uikon. Only services based on Uikon's implementation of the server application framework can be used to start new application instances. Those based on Apparc's implementation must connect to a server application which is already started.

Applications will use the server application framework appropriate for their platform. They may use whatever services are available on that platform, subject to security restrictions.

Client-server view

The diagram below shows Apparc's implementation of the server application system from the client/server point of view. These are the points to note about this system:

The basic client server link is between RApaAppServiceBase and CApaAppServiceBase. The protocol used on this link is for monitoring the lifetime of client and server.
Services are implemented in sub-classes of RApaAppServiceBase and CApaAppServiceBase. The sub-class type for each particular service is identified by a UID. The protocol added between the client and server-side of a service protocol is specific to that service.
Clients may monitor the lifetime of server applications using the CApaServerAppExitMonitor active object and the MApaServerAppExitObserver interface. The active object can be used to monitor any RApaAppServiceBase derived object.
A server application has to derive a server class from CApaAppServer. This class should implement a function, CApaAppServer::CreateServiceL() which takes a UID identifying the type of service that the session should implement.
The service specific sessions on client and server-side marshal parameters across the client server link. Typically, the server-side will introduce a number of virtual functions to handle the client requests, which the server application must override and implement.

Security view

This section discusses security aspects of the server application support. Essentially, both client and server need to protect themselves against malicious versions of their counterpart that they may connect to.

RApaAppServiceBase protects the client from malicious servers in three ways: Firstly, it can monitor the lifetime of the server by holding open a request for server exit status; secondly, it has a time-out on the connection to the server so that the server cannot lock the client by not responding; thirdly, it can make this time-out mechanism available to derived classes.
CApaAppServiceBase protects the server from malicious clients by allowing a security policy to be set for client requests. Note that the client/server framework provides support for unexpected client exit. There are two functions that server applications can override for security checking: CApaAppServer::CreateServiceSecurityCheckL() allows a capability check on connect and CApaAppServiceBase::SecurityCheckL() allows a security check on each message.
Service specific sub sessions on the client-side should protect the client by checking the validity of parameters received from the server. They should not assume that they are talking to their equivalent class on the server-side.
Service specific sub sessions on the server-side should protect the server by checking the validity of parameters received from the client. They should not assume that they are talking to their equivalent class on the client-side.

Sequence views

The following sections show sequence diagrams illustrating various dynamic relationships between client and server application.

Server application start

When a client wishes to establish a connection with a new server application, it connects an REikAppServiceBase derived object by calling its REikAppServiceBase::ConnectNewAppL() function. This starts a new instance of the server application, and passes information about the server name to the server. The server application creates a server with the appropriate name. REikAppServiceBase then connects to the server and tells the server what session type it requires.

Note: REikAppServiceBase (implemented in Uikon) has to be used to start new server applications. RApaAppServiceBase (implemented in Apparc) cannot start new server applications, but it can connect to existing server applications, either by server name, or with the help of another connected RApaAppServiceBase instance.

It would not be safe for the client to dictate the full name of the server to the server application. If this were possible, the client may be able to make server applications impersonate system servers. Instead, the client application tells the server a random number to use in the server name. The server name is then generated from this random number and the UID of the server application. Since both numbers are known to both parties, the combination can be checked for uniqueness and they can't be used to impersonate system servers. This name agreement system is therefore safe.

Service creation

Continuing from the previous diagram, this diagram shows the creation and use of a service specific sub-session between the client and server application.

To use a service, the client must first create a service specific session. This happens during the call to the Connect…() functions in RApaAppServiceBase and REikAppServiceBase. These functions connect the appropriate session sub-type by sending the UID for the session type to the server in the connect message. Because there are no spare slots in the connect message, this UID is passed in the version field. The server application's override of the CreateServiceL() function is called passing in the UID of the requested service. The server application can now instantiate it's implementation of the server-side objects for the service.

Service use

The diagram below shows the use of a service specific session between the client and server application.

To use a service, the client-side implementation of the service sends service specific messages to the server, which are passed to the service's interface in the server. This decodes the messages and calls virtual functions in the server application's implementation of the service, to actually carry out the service.

Server application lifetime monitoring

If the client application requires monitoring of the server application's lifetime, which it often will, it should implement the MApaServerAppExitObserver interface and create a CApaServerAppExitMonitor to monitor a RApaAppServiceBase derived connection to the server application. CApaServerAppExitMonitor opens a request for notification of exit to the server. When the server exits, this notification will be completed. The CApaServerAppExitMonitor then runs and tells its observer that the server application has exited.