Get current deegree release versions on docker from docker hub:

  • 3.3.18 - docker pull tfr42/deegree:3.3.18
  • 3.3.19 - docker pull tfr42/deegree:3.3.19
  • 3.4-RC1 - docker pull tfr42/deegree:3.4-RC1
  • 3.4-RC2 - docker pull tfr42/deegree:3.4-RC2

docker pull tfr42/deegree:latest will pull the latest image which is currently 3.4-RC2!

Dockerfile is available at https://github.com/tfr42/deegree-docker.

Comment (898) Hits: 18800

deegree 3.3.17 has been released and is available now from repo.deegree.org.

This maintenance release includes a number of fixes and is recommended for anyone still on the 3.3.x line.

Comment (841) Hits: 46330

deegree 3.3.17 has been released and is available now from repo.deegree.org.

This maintenance release includes a number of fixes and is recommended for anyone still on the 3.3.x line.

Comment (91) Hits: 11738

deegree 3.3.16 has been released and is available now from repo.deegree.org.

This maintenance release includes a number of fixes and is recommended for anyone still on the 3.3.x line.

Comment (35) Hits: 7316

This blog post is meant to be the starting point for a series of posts about the usage of docker as a platform to build comprehensive geospatial webservices based on deegree. The first step to get started with docker and deegree is to think about deegree's system requirements. Well, that question has a very short answer: java and a servlet container. So I began to search for possible solutions to have a docker image fulfilling these prerequisities. I found the official tomcat container image on docker hub (http://hub.docker.com). This acts as blueprint for my new deegree docker container. My two favorite things about docker are: there are tons of docker images to be used as blueprints to setup your own containers and it is really easy to use. Using the tomcat image leads into the following dockerfile:

FROM tomcat

MAINTAINER Sebastian Goerke <This email address is being protected from spambots. You need JavaScript enabled to view it.>

# set deegree version

ENV DEEGREE_VERSION 3.3.14

# download deegree

RUN wget http://repo.deegree.org/content/repositories/public/org/deegree/deegree-webservices/${DEEGREE_VERSION}/deegree-webservices-${DEEGREE_VERSION}.war -O /usr/local/tomcat/webapps/deegree-webservices.war

CMD ["catalina.sh", "run"]

With only these few lines it is possible to build and run a blank stable deegree webservices 3.3.14 on docker. But for a more advanced environment I want to add a PostGIS database to use it as a datasource. There is a nice image on the web which is built upon the official Postgres docker container (https://registry.hub.docker.com/u/mdillon/postgis/). Okay, now we have the dockerfile for the deegree container and we've got an image for running a PostGIS container. What I did next, to make things easier for users, was to add an image built from the dockerfile above to the docker hub. Now it is pretty easy to get that image using:

docker pull segoerke/deegree

For the postgis image you can do exactly the same:

docker pull mdillon/postgis

Now, it is pretty easy to startup a nice environment with a database server container and a web application container:

docker run -p 5432:5432 --name db -d mdillon/postgis

docker run --name deegree --link db:db -p 8080:8080 -d segoerke/deegree

 

I already added port forwarding to the containers to be able to connect to them from my own server machine through these. So I am able to work on the database through localhost:5432 and I can access the tomcat through localhost:8080 on my local machine to work with the docker apps. Now it is possible to configure the deegree webservices and fill the database with data to be published with deegree webservices. I hope this short introduction is helpful to get started with deegree on docker. My idea is to have some more blog posts regarding a full INSPIRE setup with docker and orchestrated deegree containers.

Comment (140) Hits: 7545

deegree 3.3.15 has been released and is available now from repo.deegree.org.

This maintenance release includes a number of fixes and is recommended for anyone still on the 3.3.x line.

Comment (157) Hits: 25614

deegree 3.3.14 has been released and is available now from repo.deegree.org.

This maintenance release includes a number of fixes and is recommended for anyone still on the 3.3.x line.

Comment (80) Hits: 17949

And why we still stick with Java

deegree has proven in productive environments to comply to the OGC standards for geospatial web services as well as to tackle even the complex INSPIRE regulations. Including the performance requirements specified in the INSPIRE Technical Guidance for network services. Saying this also implies to have a closer look how this relates to the technology stack chosen for deegree web services and how to benefit from it when we think about the future development of deegree.

From the beginning of the open source project deegree was designed to run on the Java Virtual Machine (JVM) the most used runtime environment for business critical applications. Using Java as a programming language has for sure one big advantage in using an object-oriented programming language to design internal domain models such as the one for GML and to leverage the rich API’s provided by Java SE and EE. But the main advantage for developing full-fledged SDI solutions is to have a mature runtime environment which also supports multiple languages out of the box. Today with Java SE 8 you can write your code in Java, but also use other languages such as Scala, Groovy, Clojure or JRuby and Jython. The JVM makes that happen. You can even develop extensions in JavaScript using modern frameworks such as node.js where projects like nodyn come into place. When developing extensions for deegree you have the choice which language to use. And the deegree community will be pleased to guide you through the steps to incorporate extensions written in other languages than Java.

Microservices are another approach which got a lot of attention recently when discussing the development of cross-language applications - which means mixing different programming languages together. Main characteristics of a microservice architecture are decentralized governance and data management and most important design for failure. Synchronous calls are considered harmful and microservices take into account that a service call could fail due to unavailability of the remote service provider and the consuming client has to respond to this as tolerant as possible. The decentralized governance opens the door to use the right tool for the job. Regardless if you want to use node.js or C++, to build for example a fast and reliable map projection service, a tool such as RabbitMQ provides the lightweight infrastructure to plug it into deegree. Or you use RESTish protocols to incorporate smart endpoints with a more coarse-grained communication structure compared to chatty RCP or SOAP calls. To transform the monolithic approach of deegree into a more microservice architectural style is a very challenging task and contributions from the community are welcome.

And finally we don’t have to forget that deegree web services are running on every Java EE 5 or higher compliant application server such as JBoss Wildfly, Oracle WebLogic Server and still on the Apache Tomcat servlet container. Within the IT the Java Enterprise Edition (Java EE) platform has been adopted by millions of developers and companies providing business services in large-scale environments. As a geodata provider you can setup a technical infrastructure running multiple Tomcat or WebLogicServer instances within a cluster to meet demanding performance requirements. Our goal is to get deegree ready for the enterprise and that it will meet the needs of data center provider and DevOps. And operations in the area of cloud computing is quite crucial. Support for cloud computing in Java EE was planned for version 7 but has been moved to Java EE 8 where we can expect the JCP experts group will publish the final draft for JSR 366 by the end of 2015. There are early implementations available such as a deegree tilestore to use storage back-ends such as Apache Cassandra to provide access to tiles stored in the cloud which can be served by deegree’s OGC WMTS implementation. We are quite curious how and when this will be adopted by users and developers. We are looking forward to discuss further at one of the next user meetings or on our mailing list.

Comment (124) Hits: 15673
feed-image Feed Entries