Client applications frequently make use of services provided by Symbian servers. This section introduces the role of servers and the use of active objects to send requests to servers asynchronously.
Most system services, such as the file server, are implemented using the client server framework. Servers run continually in the background providing access to shared system resources. The communication channel for passing messages between the client and server is known as a session. Clients must create a session before sending requests to the server. The session hides the details of message passing and data packaging from application code.
Servers run in a different thread to their clients, and in practice they almost always run in a different process. Since the process boundary is the point where platform security checks can be enforced, a server running in its own process is able to implement a security policy controlling access to the server resources.
Clients can send both synchronous
and asynchronous requests to the server. An asynchronous request includes
a TRequestStatus parameter, which the server will
complete when the operation has finished. Typically, the client will
use an active object to handle completion of the request. When the
server completes the outstanding request, the client-side active object’s RunL() is called. See Introduction to active
objects for further details on asynchronous requests and active
objects.
Dynamic link libraries (DLLs) consist of a library of compiled C++ code that may be loaded into a running process in the context of an existing thread. In Symbian C++, there are two main types of DLL: shared library (static interface) DLLs and polymorphic interface (plug-in) DLLs.
A shared library DLL
implements library code that may be used by multiple components of
any type, that is, other libraries or EXEs. The filename extension
of a shared library is .dll.
A shared library
exports API functions according to a module definition (.def) file. It may have any number of exported functions, each of which
is an entry point into the DLL. A shared library releases a header
file (.h) for other components to compile against,
and an import library (.lib or .dso) to link against, in order to resolve the exported functions.
The second type of DLL, a polymorphic interface DLL, implements
an abstract interface that is usually defined separately, for example
by a framework. It may have a .dll filename extension,
but it can use a different extension to identify the nature of the
DLL further, for example, .fsy for a file system
plug-in, or .prt for a protocol module plug-in.
Polymorphic DLLs have a single entry-point or 'factory' function, which instantiates the concrete class that implements the interface. Polymorphic interface DLLs are often used to provide a range of different implementations of a single consistent interface. They are loaded dynamically, typically by a framework.