WURFL Microservice for Docker

Using WURFL Microservice for Docker will allow you to run your own WURFL-based device detection service in your hosting infrastructure by deploying familiar Docker images as containers through a ScientiaMobile Docker repository. If you are not familiar with Docker and the possibilities of Docker containers, here is a good place to get started.

WURFL Microservice Client API (WM Client)

Given an HTTP Request and a device capability name, the WURFL Client API will return the corresponding property value.

You can integrate the WURFL Microservice for Docker with major programming languages, including: You can integrate the WURFL Microservice Standard, Basic or Pro Edition with major programming languages, including:

WURFL Microservice Architecture

WURFL Microservice Server (WM Server) is a service that exposes its functions to the WURFL Microservice Client API (WM Client). The Client API depends on the availability of the WM server to work.

The following diagram explains the overall architecture of WURFL Microservice as deployed through the ScientiaMobile Docker Private Registry. The Image will start an instance of the WURFL Microservice Server as a container. In addition to supporting the REST interface for API clients, the service will periodically query ScientiaMobile for updates to the WURFL Device Description Repository in order to include the profiles of newly released devices.

Note 1: While the WM Client feels like a "standalone API" for most practical purposes, under the hood it requires interaction with the WURFL Microservice HTTP server which introduces some latency (hugely mitigated by a built-in caching layer in the WM Client). For this reason, ScientiaMobile does not refer to the WURFL Microservice Client API (WM Client) as a "WURFL API" (that name is reserved for the WURFL OnSite APIs).

Note 2: communication between the WM Client API and the WM Server happens through a REST API, but this is totally transparent to users of WURFL Microservice and ScientiaMobile acknowledges this aspect of the WURFL Microservice product for sake of transparency. Unless you have a very specific use-case(s), we strongly discourage you from utilizing the REST Interface directly. Not only does the WM Client provide a caching layer (which delivers much greater performance), but ScientiaMobile reserves the right to modify the internal REST API or even to switch to different non-REST protocols in future versions of the product without notice.

Deploying the Docker Container and Setting up the WM Client APIs

1. (Only for first-time WURFL Microservice users) Obtain a license for the Product from ScientiaMobile.

This will let you use your ScientiaMobile credentials to login into the ScientiaMobile private registry and enable deployment of the product.

2. Login to the ScientiaMobile Docker Registry.

docker login docker.scientiamobile.com -u <username>

Details on the Docker login command can be found here.

Docker Images are currently available based on the set of Capabilities (Device Properties) and API Programming Language licensed from ScientiaMobile.

3. Use Docker to download, deploy, and start the WURFL Microservice HTTP server in an environment which makes sense for you (i.e. development, test, production, etc).

docker run --name wm-server --rm -p 8080:80 \
  -v /tmp/wm-server-logs:/var/log/wm-server \
  -e WM_CACHE_SIZE="200000" \
  -e WM_MAX_CORES=7 \
  -e WM_ERROR_LOG_TO_FILE=true docker.scientiamobile.com/<license_id>/wurfl-microservice.server
  • WM_ACCESS_LOG_TO_FILE=true will log HTTP access /var/log/wm-server/access.log
  • WM_ERROR_LOG_TO_FILE=true will log errors in /var/log/wm-server/error.log
  • Use WM_MAX_CORES to limit the number of threads used by the server (with no option server will use all necessary threads to keep serving requests).
  • To reduce server load it is suggested to use a big server side cache: WM_CACHE_SIZE="200000" will do for a medium server, "300000" for a large one.

Important Note for Users of the Old DOUBLE LRU Cache Provider (pre for backwards compatibility, older configurations are still supported and will not generate errors or warnings, but internally the new SINGLE LRU Cache is adopted for better performance.

4. Verify that the HTTP Server is running:

Copy the IP address of the web server, open a browser and visit the http://<instance-ip>/v2/status/json URL address. You should see a small JSON object that vouches for the health of your installation.

Alternatively, you can use curl from a shell terminal: assuming your IP is, the following command will confirm that the Docker Image has been deployed successfully and that the WM Server is up and running.

$ curl
    "lookup_request": 0,
    "lookup_useragent": 0,
    "lookup_device_id": 0,
    "make_model_requests": 0,
    "server_info_requests": 8,
    "v1_capabilities_requests": 0,
    "not_found_404": 0,
    "server_uptime": 23171

if your instance responds with something like this, everything looks good. Your WURFL Microservice server is up and running!

The WM Client API now has a WM server to talk to.

The WM Client API now has a WM server to talk to. More about Client APIs later.

5. (Only for first-time WURFL Microservice users) Install the WM Client API package and import the API in your project to start using it in your application.

WM Client APIs are available for the following supported languages (regardless of the capability set/tier): Go (golang), Java, .NET, Node.js and PHP.

WM Client APIs for the respective languages are provided on the ScientiaMobile public github repository:

You can find the documentation for each WM Client API here:

  1. Golang (GO Language)

  2. Java

  3. Microsoft .NET

  4. PHP

  5. Node.js

  6. Python

  7. Rust

Maven Central, Nuget and NPM also carry the WM Client API libraries for Java, .NET and Node.js respectively.

© 2024 ScientiaMobile Inc.
All Rights Reserved.

NOTICE: All information contained herein is, and remains the property of ScientiaMobile Incorporated and its suppliers, if any. The intellectual and technical concepts contained herein are proprietary to ScientiaMobile Incorporated and its suppliers and may be covered by U.S. and Foreign Patents, patents in process, and are protected by trade secret or copyright law. Dissemination of this information or reproduction of this material is strictly forbidden unless prior written permission is obtained from ScientiaMobile Incorporated.