The PTV xServer is web application server offering one or several web services over HTTP(S). Work load is distributed to separate worker processes which can be scaled depending on usage requirements and available computing resources.
The following terms occur frequently in PTV xServer technical documentation as well as in configuration files. Understanding these terms in the context of PTV xServer is important for the understanding of the system architecture.
The diagram below depicts the primary components of PTV xServer:
A unit of work in the business domain of the service. Most transactions represent a use case and are relevant for billing.
Technically, there are two forms of transactions: firstly, a HTTP message exchange with a single request and a response where the client waits for response, and secondly, a so-called job, a series of HTTP messages following an asynchronous protocol where the client does not have to actively wait for the result.
The wrapper is a process that starts the actual server process and handles integration into the operating system as well as server restarts.
Technically, PTV xServer uses the Java Service Wrapper from Tanuki Software.
A PTV xServer is a web (application) server that offers one or more web services.
The primary function of the server itself is to deserialise request messages, serialise response messages, and logging.
Technically, the server is an Apache Tomcat running one or more servlets.
The services of PTV xServer are web services that offer functionality for a group of similar use cases such as routing (xRoute),
visualisation (xMap) or geocoding (xLocate).
Each service has a well-defined API and entry points for messages in different formats. PTV xServer supports SOAP and, as of 1.16 and newer, JSON messages as well. Transport protocol for messages is HTTP, or HTTPS.
Technically, each service (end point) is implemented as a (pair of) Java servlets.
Each service / module has one or more worker processes that perform the actual computations. These worker are mostly independent from the server process.
Technically, workers are Java virtual machines.
There can be more than one worker process per service, forming a worker pool. Workers from the pool will handle requests in parallel.
The size of that pool is one of the most important configuration parameters to scale PTV xServer; for more about this topic, please refer to the dedicated guide.
Technically, the worker pool is a series of Java virtual machines as independent processes under the supervision of the web server process.
The scheduler manages transactions and supervises the worker pool.
Technically, the scheduler starts threads that act as agents for worker processes. These agents fetch transactions from the queue and communicate with the worker processes. This design generates a low management overhead, especially important for CPUs with many cores.
The request queue is a temporary store for incoming requests that cannot be processed immediately. This queueing mechanism buffers allows to process temporary spikes that would otherwise overload the system.
Technically, the queue is implemented as a highly efficient FIFO data structure.
The modules of PTV xServer are software components that provide the algorithms and data queries for a given service.
Technically, modules are Java applications wrapping and augmenting native code engines. They also have watchdog functions and take care of database management and communication with the servlets over RMI.
The engines of PTV xServer are (usually C++) algorithms that access map data and extra content.
Technically, engines communicate with their module with JNI.
The PTV xServer architecture focuses on reliability, usability, efficiency, and maintainability quality characteristics:
PTV xServer ships with all components needed for deployment including a web application server and third party libraries. Only a Java installation has to be provided. There are options to replace databases, though this is not required.
PTV xServer only contains third party software that is either free for commercial use, or explicitly licensed for PTV xServer. You can find more about the actual third party software bundles and their licenses in the Purchaser's Guide.
A PTV xServer has a typical life cycle with several phases:
Worker processes are child processes of the server process which in turn is a child process of the wrapper process. Concerning the life cycle of processes, there are automatic mechanisms from either the operating system or the architecture:
All restarts are logged for further examination. This interaction of processes provides PTV xServer with a solid fault tolerance and recoverability.
The server process opens sockets on configured ports. You can change the default configuration.
shutdown command using this port. The default configuration disables the use of this port from external hosts.A typical PTV xServer installation would only require external access to the HTTP or HTTPs port.
A productive PTV xServer environment will in general contain a cluster of servers. To distribute requests a load balancer is required, a common feature of web proxies. Web proxies also can be used for access control, SSL termination, or URL redirection, among other things.
The diagram below illustrates a typical deployment:
Alternative structures are possible. For instance, client applications will often not access PTV xServer directly, but use a middleware with extra business logic that acts as a facade to the PTV xServer. Where this middleware is best deployed depends on the circumstances - security and latency concerns are among the most important motives.
The diagram assumes a software proxy on a dedicated machine; the proxy could also run with the database, or as a dedicated proxy hardware.
Simple transactions consist of a single HTTP message exchange involving a request and a response message. While the response is computed on the server, the client has to wait with an open connection for the response. The server will temporarily store requests that cannot be worked on yet in the request queue.
The optional asynchronous protocol supports jobs for operations that may take a long time to complete. A job also represents a business transaction, but with the important distinction that the client may but does not have to actively wait for the result. Job information is kept persistent in a central job database until the result has been fetched.
The following sequence diagram illustrates a typical HTTP message transaction complete with all types of delays that make up the overall response time.
Copyright © 2024 PTV Logistics GmbH All rights reserved. | Imprint
