Codenvy Proof of Concept for NOAA Fisheries Alaska Region - larrytalley/codenvy GitHub Wiki

Introduction

NOAA Fisheries Alaska Region is considering using Codenvy as a part of our development tooling.

As a proof-of-concept we are building a small project with multiple parts so that we can see a number of Codenvy features in operation.

POC Overview

This proof-of-concept (POC) is a system in miniature with a web user interface provided via Vaadin and a services layer using Google Protocol Buffers and Kerberos and Apache Active MQ.

The POC will demonstrate that multiple component parts can be developed independently and that Codenvy (with Docker and Compose under-the-hood) can orchestrate development/testing at a component level or a complete system level.

Component Parts

Web User Interface

We intend to build a simple web UI using Vaadin to demonstrate user input and invoke service layers. The UI layer will have minimum functionality, just enough to give service layers something to do.

Services

We will expose some services via a service API library and a REST API. The Vaadin UI application will use the services library to make calls to services (but it could call the REST API if there was a reason to do that.) To the extent possible the technical implementations of services and communication mechanisms will be hidden by the service API library.

Google Protocol Buffers

We will wrap objects via Google protocol buffers so that the objects exchanged through our API have structure and meaning. This wrapping will take place in the service library so the consuming application can just deal with the business objects and the service requests and won't need to consider this layer.

Apache ActiveMQ

Communication between service consumer and service supplier and among services will be mediated by Apache ActiveMQ message bus. This mediation will be abstracted via the service library, and, the messages exchanged over the message bus will be Google protocol buffer data exchange objects.

What do Codenvy, Eclipse Che and Docker have to do with this?

This is a simple POC application but there are already a lot of parts for a software developer to manage. Maintaining a software development environment configured for development of components with complex stacks is a challenge, and, having a dozen developers each maintaining these environments seems like wasted effort. The promise of Codenvy/Eclipse Che/Docker is that we can maintain just one development environment, and that any developer assigned tasks on the project can access that environment with a URL and become instantly productive with the single consistent development environment. And of course there has to be some way to build and test products and subsequently deploy built products into a production environment and ideally the developer environment and the build/test environment and the production environment should share configuration specifications so that those runtime configuration specifications are also easily maintained and shared.