Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 39
Текст из файла (страница 39)
We first give consideration to general points about object location,communication types and styles in this pattern. We then consider otherqualities: functionality, security, extensibility and configurability, usability, and performance.Relative Server LocationThe server, as an active object, realistically needs its own thread ofexecution. On most operating systems, the fundamental unit of logicalmemory isolation is the process. So for maximum protection for itsmanaged resource, it is usually the case that the server runs in its ownprocess.
Doing this also allows it the maximum autonomy for sharing itsresources with all other client processes. It is only in this configurationthat this pattern is able to provide a secure service by ensuring its memoryis isolated from any interference by clients.Of course where a single application deploys a server for exclusive useof its own client modules then there is no security threat to protect againstand hence the server can be hosted in the same process as the application.After all, no other process needs that service. A common reason to host aserver in the same process as its client is that it provides one of the easiestmechanisms in Symbian OS to coordinate multithreading within a singleprocess.CLIENT–SERVER205The types of partitioning we have described so far are examples ofsingle-seat client–server architectures which are realized on the samecomputer.
This is the main concern of this exposition. Nevertheless, itis worth saying a word about client–server architectures in the world ofenterprise computing. Here it often means ultimate separation of clientand server on physically different computers on a network – whetherPAN, LAN or WAN. This environment is epitomized by the web with itsweb servers and browser clients. In this environment, there are two-tierarchitectures, involving a client and a server, and multi-tier architectureswhere a server is a client to another server.
It goes without saying, though,that multi-tiered architectures can also be realized on a single mobiledevice.Server LifetimeMost servers are usually created to serve the needs of one or more clients.So these servers typically run until the last of their sessions with a clientcloses. These servers are often described as transient servers and are anexample of using Lazy De-allocation (see page 73).Then there are Permanent (‘Daemon’) servers that, once created, continue running to perform system services, even when there are no clientsconnected, until shut down by the system. A server may also be madeto run permanently if responsiveness is a key requirement.
Both of thesecases are an example of applying Immortal (see page 53) to this pattern.Types of Request and Communication StylesIn a client–server relationship, the client always initiates a dialog bymaking a request. The request can be one of the following:• peek (get) some server object’s state, or observe its change• poke (post) some server object’s data, or request some action on it.Each of the request types may be best served synchronously, if communication bandwidth and server response times permit it, or asynchronouslyotherwise.Server state change may be observed in two ways:• Information Subscription: the server responds with the new information.
This is a hot communication relationship. In some implementations, this may require that the client set aside adequate space toreceive the information.• Change Notice Subscription: the server is only obliged to respond witha simple ‘state has changed’ notice but without the actual information.This is a warm communication relationship. It gives clients controlover when they get the new information but at the cost of makinganother round-trip communication.206PROVIDING SERVICESServer state observation, such as in the Observer Pattern [Gammaet al., 1994], poses real performance engineering difficulties to serverdesigners.
What does one do when there are a large number of clientsto be notified about a lot of changes? We’ll consider strategies forhandling some of these problems in the performance variants and extensions.FunctionalityPublish and Subscribe (see page 114) supports server state observationby unconnected clients. It provides the solution to clients who do nothave a need to use a server except to observe changes in its state. Theserver developer determines which data items have such an appeal andpublishes them.
For example, tzserver.exe publishes the time zonein this way because it affects the local time and a number of unconnectedclients need to adjust their behavior accordingly. This pattern is nota substitute for connected clients observing server state changes. Itis better to provide connected clients with specific server observationmethods.SecurityConcepts such as Capability Management and Data Caging [Heath,2006] as well as the memory isolation offered by processes in SymbianOS enable a server to secure its sensitive data and other resources.
Inaddition, the client–server framework provides the CPolicyServerclass to allow a consistent policy of security checks to be applied to clientrequests.Extensibility and ConfigurabilityCookies and Trusted Extension Components allow for the configurationof client-specific, server-side behavior. Sometimes the basic functionalityoffered inside a server needs to be configured with a behavior that isunique to a specific client or client type. It may also be that under thesecircumstances it is unacceptable, if not impossible, to transfer the data tothe client to carry out the operation.A Trusted Extension Component is a plug-in which is loaded serverside at run time using a secure plug-in pattern such as Buckle (see page252).
It can be used to provide the configuration needed in the server.The use of Extension Components and any other client-specific serverconfiguration can be managed using a cookie. A cookie is a unique pieceof token information that the server gives to the client as an identity.Whenever the client connects and provides this token, the server recallsand configures the client session with any previously stored informationunder the token.CLIENT–SERVER207Usability• APIs for Making Blocking (Synchronous) Calls on the ServerThis simplifies the design of the client code at the expense of denyingother services in the client thread from running.
In this pattern, all callson the server are decoupled from their execution using a messagequeue. So from the server’s perspective all requests are asynchronousand a TRequestStatus must be provided to be completed at theend of the operation. These asynchronous calls can be made toappear synchronous from a client’s perspective if an intermediaryblocks and waits on the TRequestStatus until it is completed.Such a requirement will be common to all clients and it makes senseif the blocking behavior is provided as a standard behavior of theclient session.• Indicating Failure during an Asynchronous CallThere must be only one way for a client to receive the response to anasynchronous call and that is through the TRequestStatus passedin by the client.
Failure to do so either in the client session or onthe server side can lead to stray events. The client–server frameworkhelps with this by ensuring that default Leaves which occur server-sideare used to complete the client’s request.• Extending Client Sessions with Server BehaviorSometimes a non-local server’s behavior needs to be augmentedwith client-side behavior to meet some architectural quality goal.
Wemention a few of these, such as transaction batching and data caching,under the performance variants and extensions. These require nontrivial proxies that do more than just marshal calls to servers. At othertimes, the behavior realized by the collaboration of server-side objectsneeds to be replicated client-side. This is especially useful in situationswhere the server models an application domain of interacting realworld entities and it is good for the service API to explicitly modelthese relationships. Examples of such substantive and thick proxiesinclude the interface to the Calendar server and the Window server.Performance• Sub-sessionsIf a client wishes to have multiple simultaneous uses of a server thena server should provide sub-sessions.
This allows a client to have onesession with the server that each of its sub-sessions use to provide thecommunication channel to the server. This is more efficient than eachof the sub-sessions having their own separate channel. An exampleof this is the File Server, where each opened file is handled through aseparate sub-session.208PROVIDING SERVICES• Shared MemoryInter-process communication involves copying messages from oneaddress space to another. This consumes valuable memory, evenif only temporarily, as well as execution time. These costs can besubstantial for large messages so, in such cases, the use of sharedmemory chunks is recommended to avoid copying data unnecessarily.The Symbian OS Font Bitmap Server uses this technique to provideinformation to the Window Server and clients.• Bulk Transaction APIThis is where the server interface, and hence the client session, isdesigned to allow clients to make requests for information for anumber of server objects with a single message.
The Contacts ServerSynchronization APIs provide the ability to fetch details about anumber of contacts in a single transaction. The same approach canbe used for requesting actions on a number of objects all at once.• Transaction BatchingIn this variant, a client session is designed to batch a number ofrequests made by a client before sending it to the server as a singletransaction.
It depends on and extends the Bulk Transaction APIvariant. The delimiting factors are the batching buffer size and atimeout over which the batching can be done without noticeable userexperience degradation. The Symbian OS Window Server uses thistechnique.The same technique can be applied to batching a number of serverchange notices together and notifying the client in a single reply. TheCalendaring Server (agnserver.exe) uses this technique to notifyclients of calendar events that have changed. Since it is the client whoinitiates all calls, the server has to deal with the client not calling backquick enough to retrieve the full buffer after being notified.
If we needto add to the buffer before the client has re-posted their request thenwe can replace the content with a single ‘all- change’ notice and stopadding any more until it is fetched.• Data CachingThis is where either the client or the client session is designed to cachea copy of the server’s data. The tzserver.exe client session holdssuch a cache containing both a single compressed time zone ruleand the latest set of actualized local time changes produced from it.Client requests for time conversions between universal co-ordinatedtime and the current local time zone are met, when possible, by theclient session using its cache.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
