| 79 | | [[Image(image2.jpg)]] |
| 80 | | |
| 81 | | TBD |
| | 83 | ||[[Image(image2.jpg)]]|| |
| | 84 | ||Figure ? - Server Components|| |
| | 85 | |
| | 86 | TBD |
| | 87 | |
| | 88 | === Server Framework === |
| | 89 | At the high level the server framework looks like the following:[[BR]][[BR]] |
| | 90 | ||[[Image(image12.jpg)]]|| |
| | 91 | ||Figure 4 - Internal server framework|| |
| | 92 | |
| | 93 | The server framework essentially shows that “Operations” coming from either a web application server or another !MapGuide server will be received by the server on a specified port. The server will then dispatch the incoming operation to an “Operation” queue for processing. The server dispatcher is based on the ACE reactor model. |
| | 94 | The “Operation” queue is a FIFO design which is connected to a thread pool of worker threads. Operations on the queue are removed by a worker thread from the thread pool for processing. The ACE framework thread manager handles the determination of which worker thread gets to process the queued operation. The worker thread will then process the operation and when the operation processing is complete the worker thread will rejoin the thread pool ready to process another operation. |
| | 95 | |
| | 96 | === Thread Management === |
| | 97 | The !MapGuide server is a multithreaded in design. This allows for improved processing and response to operations. The server will consist of the following types of threads: |
| | 98 | * Main process thread |
| | 99 | * Worker threads |
| | 100 | |
| | 101 | ||[[Image(image13.jpg)]]|| |
| | 102 | ||Figure 5 - Thread identification|| |
| | 103 | |
| | 104 | ==== Main Process Thread ==== |
| | 105 | This is the main executable thread of the server. The main purpose of this thread is to dispatch incoming operations to the queue for processing by the worker threads. This thread will also be responsible for initializing the server which includes initializing the coordinate system library, opening the repository, creating the worker thread pools, etc… |
| | 106 | |
| | 107 | ==== Worker Thread ==== |
| | 108 | This is a thread that is used to process an operation. Essentially, this is a thread that does all the work. The main process thread of the server will be responsible for creating thread pools consisting of these worker threads based on the configuration settings of the server. |
| | 109 | |
| | 110 | === Memory Management === |
| | 111 | The server and any components used by the server must be conscious of their memory use and reclamation of used resources when no longer needed. |
| | 112 | |
| | 113 | ==== Smart Pointers ==== |
| | 114 | Wherever possible in the server and any of its components smart pointers are used. |
| | 115 | |
| | 116 | ==== Caching ==== |
| | 117 | In order to improve performance the server caches several types of resources. The following lists some of what the server caches: |
| | 118 | * FDO connections (when specified in the server configuration) |
| | 119 | * FDO Schema Definitions (Object and XML representation) |
| | 120 | * FDO Class Definitions (Object and XML representation) |
| | 121 | * FDO Property Definitions (Object and XML representation) |
| | 122 | * Coordinate Systems |
| | 123 | |
| | 124 | ==== Windows ==== |
| | 125 | The default memory management library is used. |
| | 126 | |
| | 127 | ==== Linux ==== |
| | 128 | The default memory management library is used. |
| | 129 | |
| | 130 | === Operation Processing === |
| | 131 | The server supports the processing of 3 types of operations: |
| | 132 | * Client operations |
| | 133 | * Admin operations |
| | 134 | * Site operations |
| | 135 | |
| | 136 | ==== Client Operations ==== |
| | 137 | The majority of operations processed by the server will be of the “Client” type. Essentially, these are the operations that come from !MapGuide clients. |
| | 138 | |
| | 139 | ==== Admin Operations ==== |
| | 140 | The “Admin” operations will be specific to managing and administering a !MapGuide server using the !MapAdmin. |
| | 141 | |
| | 142 | ==== Site Operations ==== |
| | 143 | The “Site” operations will be specific to managing session/repository replication in a future release. |
| | 144 | |
| | 145 | ==== Operation Processing Sequence ==== |
| | 146 | The diagram below shows the sequence for processing either a “Client” or “Admin” operation. |
| | 147 | ||[[Image(image14.jpg)]]|| |
| | 148 | ||Figure 6 - Operation sequence|| |
| | 149 | |
| | 150 | ==== Internal Operation Processing Interaction Model ==== |
| | 151 | |
| | 152 | ===== Operation Objects ===== |
| | 153 | All server requests and their associated responses are represented internally by Operation objects. A simplified object diagram is shown in figure 7. |
| | 154 | ||[[Image(image15.jpg)]]|| |
| | 155 | ||Figure 7 - Simplified operation object|| |
| | 156 | |
| | 157 | ====== Operation Object Base Class ====== |
| | 158 | The Operation class is an abstract class that provides the base level of functionality. This functionality includes methods to serialize and deserialize the Operation from the data packets sent to the server. It also maintains a reference back to the object that handles its transmission back to the client. |
| | 159 | |
| | 160 | ====== !OperationRequest Base Class ====== |
| | 161 | This class represents the operation request or other action that the server can execute. It has an Execute method that the server will call to fulfill the request. This class is abstract, so !OperationRequest classes must be implemented for every operation that the server can perform. The Execute method will return an !OperationResponse object. |
| | 162 | |
| | 163 | ====== !OperationResponse ====== |
| | 164 | This class encapsulates the result of an executed !OperationRequest. It is serialized and sent back to the web tier or other server. |
| | 165 | |
| | 166 | ===== Operation Processing Details ===== |
| | 167 | A more detailed sequence diagram showing the creation and processing of operations is shown in figure 8. |
| | 168 | ||[[Image(image16.jpg)]]|| |
| | 169 | ||Figure 8 - Operation processing sequence|| |
| | 170 | |
| | 171 | The following describes the “Operation Processing” seqeunce: |
| | 172 | * The Web Tier connects to a socket on the server. A !ClientAcceptor object server-side is listening on the port, accepts the connection, and creates a !ClientService object to handle the the connection. The !ClientAcceptor object will create a separate !ClientService object for each connection. |
| | 173 | * The !ClientService object handler creates Operation objects from the raw request stream sent from the web tier. It reads the input stream from the socket, deserializes the packets from the stream, and then creates the specific Operation objects as determined by the deserialized objects. It then places the object in the servers !OperationQueue to be processed by a worker thread in the server’s thread pool. The handler then returns to allow other !ClientService objects to process their data. |
| | 174 | * It will periodically check to see if it has obtained a !OperationResponse object to return to the Web Tier client. |
| | 175 | * Once in the queue, the Operation object sits until an !OperationHandler can process it. A !OperationHandler processes the object by calling its Execute() method. The handler then takes the reponse and gives it back to the !ClientService. |
| | 176 | * The !ClientService will eventually realize that it has obtained a response. It will then pack the response up and sent it back to the Web Tier or other client. The object will remain to process additional client requests or be destroyed if the client closes the connection. |
| | 177 | |
| | 178 | === Session Management === |
| | 179 | |
| | 180 | ==== Overview ==== |
| | 181 | Session management will be used to enhance request/response performance in connections between the server and the web-tier as well as to track information about the connection for logging output. Session management will be handled through the use of a session object, which will be present in every server connection. |
| | 182 | |
| | 183 | ==== Session Object ==== |
| | 184 | A session object is created when a connection between the web-tier and server is established. A connection is authenticated throughout its lifetime. The session is closed when the connection is closed. The session object is used to store state information about a particular connection that can be written to a log. Such information includes connection ID, connection start time, total number of operations received, total number of operations successfully processed and information on any data (FDO) connections established during a session. |
| | 185 | |
| | 186 | When a data connection (or FDO connection) is established during a session, operations to that data connection can be made until the data connection is explicitly closed or until the session is closed. Data connections opened during the session will be maintained in a dynamic collection that will grow as data connections are added to it. |
| | 187 | |
| | 188 | The session object will hold references to any established data connections, but will not manage them. It will be the caller’s responsibility to allocate memory and to open data connections. Once a data connection has been established, it should be added to the session’s collection set. Similarly, the caller will be responsible for closing data connections and performing memory de-allocation. |
| | 189 | |
| | 190 | ==== Properties ==== |
| | 191 | The following table describes the session object properties that will be associated with each connection. |
