2. Configuration for Java EE and the Cloud
Dmitry Kornilov
@m0mus
September 21, 2016

3. I am sure you've seen it already and know what it means
I am sure you've seen it already and know what it means. In case you forgot I'll remind you. This is a legal stuff. And it says that what I will talk about may change in future and may be not included in the final product.

4. Program Agenda 1
Introduction Problem Definition JSR Proposal & Features Sample Use Case Q & A 2
Here is the agenda. I will start with a short introduction and continue with the problem description. I will talk about configuration related use cases which users are facing. After that, I will go to the actual proposal, features and roadmap. I will explain and describe all proposed features in details. I also prepared a small sample to help you better understand the proposed features. And at the end a short Q&A session is planned. If we have time. So please keep your questions to the end. 3 4 5

5. Introduction
Let’s start with a little bit of history.

6. History & Introduction
2003 – Apache Commons Configuration
2009 – Spring 3.0
2011 – Apache DeltaSpike
2013 – Mike Keith on JavaOne
2014 – Java EE 8 Survey
2014 – Netflix Archaius
2015 – Attempt to submit a JSR
2015 – Apache Tamaya
My list starts at 2003 but it should’ve been started from the first Java release back in 96. That time Properties class was introduced. The first and the only standard way for working with configuration in Java.

7. History & Introduction
2003 – Apache Commons Configuration
2009 – Spring 3.0
2011 – Apache DeltaSpike
2013 – Mike Keith on JavaOne
2014 – Java EE 8 Survey
2014 – Netflix Archaius
2015 – Attempt to submit a JSR
2015 – Apache Tamaya
The first attempt to implement a functionality we would like to standardize was done in 2003 in Apache Commons Configuration project. It supports typed access to configuration parameters and can read configuration from different sources.

8. History & Introduction
2003 – Apache Commons Configuration
2009 – Spring 3.0
2011 – Apache DeltaSpike
2013 – Mike Keith on JavaOne
2014 – Java EE 8 Survey
2014 – Netflix Archaius
2015 – Attempt to submit a JSR
2015 – Apache Tamaya
Another key date is 2009 when Spring 3.0 was released. This release introduced configuration in code approach where configuration is coded by special annotations and can be injected to other classes using Spring dependency injection.

9. History & Introduction
2003 – Apache Commons Configuration
2009 – Spring 3.0
2011 – Apache DeltaSpike
2013 – Mike Keith on JavaOne
2014 – Java EE 8 Survey
2014 – Netflix Archaius
2015 – Attempt to submit a JSR
2015 – Apache Tamaya
In 2011 the first version of DeltaSpike was released. It has a configuration module where the ideas of externalized configuration and multiple configuration sources were implemented. It also has a nice SPI based mechanism of attaching new configuration sources.

10. History & Introduction
2003 – Apache Commons Configuration
2009 – Spring 3.0
2011 – Apache DeltaSpike
2013 – Mike Keith on JavaOne
2014 – Java EE 8 Survey
2014 – Netflix Archaius
2015 – Attempt to submit a JSR
2015 – Apache Tamaya
These days started some attempts of making Java EE Configuration standard. In 2013 Mike Keith presented his proposal on JavaOne. He collected many user requests and came out with ideas about what should be included in the standard.

11. History & Introduction
2003 – Apache Commons Configuration
2009 – Spring 3.0
2011 – Apache DeltaSpike
2013 – Mike Keith on JavaOne
2014 – Java EE 8 Survey
2014 – Netflix Archaius
2015 – Attempt to submit a JSR
2015 – Apache Tamaya
In 2014, Oracle introduced a survey where were questions about what technologies users want to see in Java EE 8. You see the results on screen, Java EE Configuration collected many votes. It was not the first one, first was JSONB, but the third place out of 6 shows that users think that it’s important.

12. History & Introduction
2003 – Apache Commons Configuration
2009 – Spring 3.0
2011 – Apache DeltaSpike
2013 – Mike Keith on JavaOne
2014 – Java EE 8 Survey
2014 – Netflix Archaius
2015 – Attempt to submit a JSR
2015 – Apache Tamaya
The same year Netflix Archaius was introduced. It’s a configuration framework for the cloud. It has dynamic configuration feature allowing application to work with mutable configuration without restarting the instances. It’s also integrated with Apache Commons Configuration. Netflix successfully uses it in their products.

13. History & Introduction
2003 – Apache Commons Configuration
2009 – Spring 3.0
2011 – Apache DeltaSpike
2013 – Mike Keith on JavaOne
2014 – Java EE 8 Survey
2014 – Netflix Archaius
2015 – Attempt to submit a JSR
2015 – Apache Tamaya
In 2015 Anatole Tresch and Laird Nelson were working on a previous JSR proposal. It was rejected for some reason.

14. History & Introduction
2003 – Apache Commons Configuration
2009 – Spring 3.0
2011 – Apache DeltaSpike
2013 – Mike Keith at JavaOne
2014 – Java EE 8 Survey
2014 – Netflix Archaius
2015 – Attempt to submit a JSR
2015 – Apache Tamaya
But it gave a birth to Apache Tamaya – modern and feature rich configuration framework. It’s one of the inspirations for my proposal.
Of course there were and are many other frameworks trying to solve or simplify configuration. I mentioned only these because later in my talk I'll be referencing them. Saying something like: "This feature is inspired by Tamaya, or Spring Framework."

15. DZone and Java EE Guardians Survey Results
Now some fresh statistics. I was talking about the Java EE 8 survey from 2014, but there was another Java EE survey, joint efforts of DZone and Java EE Guardians. The results were published last week, so it's very fresh. There was a question: "How important is it to enable dynamic configuration in Java EE applications?". The results are here. 31.7% of users think that it's very important. And only 10.4% think that it's not important at all. It indicates that people still think that configuration is an important task.

16. Problem Definition
Now lets talk about what kind of configuration related problems users are facing.

17. What is Configuration? Application server setup? Runtime parameters?
I was talking to many people and found out that there is no common understanding what configuration is.
One understanding of application configuration is a server setup for a given environment in means of virtualization, installation, clustering and so on.
Some set of people understand configuration as runtime parameters such as VM memory and locale.
Another understanding is deployment descriptors. Makes sense.
Parameters of used frameworks: JPA persistence.xml or CDI beans or other frameworks configurations.
Resources, such as data sources and message queues. It also makes sense.
And sometimes people think that configuration is a set of scripts used to deploy the application. Sort of a scripting facility.
I am not saying that we are sticking with these definitions. This is what people think. I will give a definition for what we think configuration is later on when I talk about the JSR proposal.
Deployment scripts?
Used resources?
Deployment descriptors?
Parameters of used frameworks?

18. Problems Lack of standard configuration API
Configuring multiple instances
Deploying on different environments
Change configuration without redeployment
Configuration of decoupled microservices
Now let’s talk about configuration related problems people are facing now.
First of all, there are some frameworks around which help solving the configuration use cases. For example, Spring Configuration, Apache DeltaSpike or Tamaya. I mentioned them before. The point is that all of these frameworks are using different API to achieve the same goals. So there are technologies to standardize. And the first problem is the lack of standard API.

19. Problems Lack of standard configuration API
Configuring multiple instances
Deploying on different environments
Change configuration without redeployment
Configuration of decoupled microservices
Another problem is configuring many instances of the same application in one go. It’s a very common use case now that application has many instances in the cloud. There can be some configurable properties such as logging level or timeouts which we need to set for all the instances. Current model with configuration files inside the application package doesn’t work here.

20. Problems Lack of standard configuration API
Configuring multiple instances
Deploying on different environments
Change configuration without redeployment
Configuration of decoupled microservices
Third problem (maybe the most requested use case) is deploying application on different environments: dev to test, test to prod. Currently the application package has to be changed in order to do it. Configuration for different environments has to be embedded there. Users want to avoid doing it.

21. Problems Lack of standard configuration API
Configuring multiple instances
Deploying on different environments
Change configuration without redeployment
Configuration of decoupled microservices
This is a dynamic configuration use case. Currently, to change configuration we need to update application package and redeploy the application. For some properties it makes sense for some it doesn’t. Application can handle the config property change itself if it’s designed the right way and a proper framework is used.

22. Problems Lack of standard configuration API
Configuring multiple instances
Deploying on different environments
Change configuration without redeployment
Configuration of decoupled microservices
The last problem is configuring a bunch of microservices. Nowadays, applications are not monoliths, but a set of microservices. Often there are properties related to a whole application or to a group of microservices serving one business need. Cracking into each instance package and change configuration there is inconvenient.

23. JSR Proposal
So here it comes the proposal which will include solutions for all these use cases

24. Configuration Definition
Application centric
Not modifiable by application
Consists of key/value pairs
Keys and values are strings
Flat structure
Now it’s time to define what we mean on configuration.
First of all, we are talking about application configuration. Not about runtime configuration, not about a server or cluster, not about deployment descriptors or scripts. Configuration of the application including resources.
This configuration is not modifiable by the application. It can be modified by the environment through, but the application can only read it.
Configuration is a set of key/value pairs. The map. Keys and values are strings.
Configuration structure is flat. It means not a tree.

25. Java EE Configuration Unified API Externalized configuration
Support of multiple configuration sources
Properties, xml and json formats support out of the box
Layering and overrides
Optional configuration descriptor
Dynamic configuration
Integration with other Java EE frameworks
A standard we are proposing is called Java EE Configuration. It includes the following features:
Unified Java API. I don’t think I need to describe what is it. It’s clear.   
Externalized configuration. It means decoupling application configuration and application code, moving config out of the application package. This feature solves the most of use cases I was talking before. Application doesn’t care where its configuration stored, it just reads it using Config API. This is optional. If someone wants to use the classic model, it won’t be restricted.
Support of multiple configuration sources means that config can be combined, merged from different hmmm … sources. Part of it can be read from the properties file, another from the web server, another from the cloud service.
We also need to standardize formats and types of configuration files. We are thinking of supporting properties format, xml and json by default out of the box.
These sources are ordered. Higher layer sources override values of the lower layer sources. This is a concept of layering and overrides.
Configuration descriptor is a way to define what is configurable in the application and specify properties metadata.
Dynamic configuration is an ability to react on configuration changes. This feature is big. It includes a polling sources framework, providers, expressions and contexts. I’ll explain what it all means later.
And the last feature is integration with other Java EE frameworks in a way that they also read their configuration using this config framework.

26. Java EE Configuration Unified API Externalized configuration
Support of multiple configuration sources
Properties, xml and json formats support out of the box
Layering and overrides
Java EE 8
We are proposing this JSR to be included in Java EE 8. We are proposing it late. Java EE 8 release is next year. We don’t have time to include all proposed features to the first release. So we selected the core features such as API, externalized configuration and multiple configuration sources with layering and overrides for inclusion to Java EE 8. And other extended features, which are more related to cloud, to the next Java EE release.
Optional configuration descriptor
Dynamic configuration
Integration with other Java EE frameworks
Java EE Next

27. Roadmap Submit JSR Early Draft Proposed Final Draft Sep 2016 Oct 2016
Here is a detailed roadmap. We are planning to submit a JSR request after JavaOne in October, come out with an early draft in Jan 2017, public review in April and final release in August. You see, it’s pretty tough.
Sep
2016
Oct
2016
Nov
2016
Dec
2016
Jan
2017
Feb
2017
Mar
2017
Apr
2017
May
2017
June
2017
July
2017
Aug
2017
Sep
2017
Review JSR
Expert Group Formation
Public Draft
Final Release

28. JSR Features (Java EE 8)
Now let’s go through all JSR features in details.

29. API
Config config = ConfigProvider.getConfig(); // Returns "JavaOne" String foo = config.getProperty("a"); // Returns string "9" String fooBar = config.getProperty("b"); // Returns null String notExists = config.getProperty("not.exist"); // Returns string "default" String notExistsDefault = config.getProperty("not.exist","default"); // Returns number 2016 Long fooBarBaz = config.getProperty("c", Long.class);
a=JavaOne
b=9
c=2016
And we will start with API. Let’s use example first approach. Imagine that we have a property file as it shown in the top-right corner. It defined 3 properties: a, b and c.
To read properties we need to create an instance of our configuration engine. It’s done using ConfigProvider. It has getConfig method which returns a default configuration engine.
Now let’s read the first property by calling getProperty method. The string “JavaOne” is returned.
If we read “b” property this way, the string “9” is returned. Not a number 9, but a string “9”.
If we try to read property which doesn’t exist, exception is not thrown, null is returned. Alternatively, the framework can return an optional value.
Next sample shows reading the same not existing property with provided default. In this case default is returned.
And the last sample is type safe property reading. In this case we are providing a type of the property and string will be automatically converted to this type.
Let’s take a look on this mechanism in details.

30. Converters Type safe access to values Built-in converters for:
Primitive Wrappers
BigDecimal, BigInteger, URL, URI
Date, Calendar
java.time.*
public interface Converter<Target> { Target convert(String value); }
public class FooConverter
implements Converter<Foo> {
public Foo convert(String value) { } }
Config cfg = ConfigProvider.builder() withConverters(new FooConverter()) build();
Foo foo = cfg.getProperty("foo", Foo.class);
The idea is to pack the framework with a set of default converters for primitive wrappers, date, java.time classes, big and url classes. And give an ability to register custom converters, which can be created by implementing a converter interface as it shown here. The similar concept is used in JSONB. Most of the frameworks I mentioned have this feature.

31. Configuration Sources
Multiple configuration sources
Supported configuration sources:
System properties
Runtime parameters
File (Properties, xml, json)
Resource on a web server
Pluggable architecture
Custom sources (like DB)
Configuration sources are ordered
Application DB
Configuration sources. I touched it a little bit before. Look at the picture. Application reads configuration from Config framework. It doesn’t care and doesn’t know where physically data is stored. And it can be stored in different locations in files with different formats. Config framework knows how to read it and merges it using rules defined in this standard. The architecture is pluggable. It is possible to create a custom configuration source and change configuration sources at runtime. You see, the database here, it’s not supported by default, by a custom source can be created to read properties from the database.
Configuration sources are ordered. The order is defined by a number (ordinal) which is assigned to each source. Sources with higher ordinal are more important and override values set in sources with lower ordinal.
web
Java EE Config
XML
prop
JSON

32. Layering and Overrides
This picture describes a mechanism of overrides. Imagine that we have 4 sources shown here. The number in front of the source name is its ordinal. Here are 4 properties. If property is defined in the source, the ball is in the corresponding cell. Green ball shows the actual returned value. For example, p1 is defined in 3 sources. The returned value is taken from the source with the highest ordinal. From this one. The same is with other properties.

33. Default Configuration Sources
System properties (ordinal=400)
Environment properties (ordinal=300)
/META-INF/config.properties (ordinal=100)
/META-INF/config.xml (ordinal=100)
/META-INF/config.json (ordinal=100)
Java EE Config
By default, if nothing is configured, Config framework uses these sources to read properties. The orange arrow shows the direction. It tries to read config from files in META-INF directory, after that environment variables and the last is system variables. This is by default. And as you see the configuration is not externalized by default.

34. Defining Configuration Sources
Using config.sources runtime parameter
Using API
Using config-sources.xml file
But everything is customizable. There are 3 ways to customize the sources: runtime parameter, API and config-sources.xml file.

35. Customizing Configuration Sources
Using config.sources runtime parameter
# Single file source with default ordinal (200)
java –jar my.jar –Dconfig.source=/conf/myconfig.properties
# Web source with default ordinal (200)
java –jar my.jar –Dconfig.source=
# Two sources. Ordinals are 200 and 199
java –jar my.jar –Dconfig.source=
The first method is using config.source runtime parameter. You can specify a location of the file as it shown in the first sample. It can be a web resource as it shown in the second sample. The Config framework recognizes it automatically. The third sample is a list of sources. The ordinals are taken from 200 and below. So the first source in the list has a higher priority.

36. Customizing Configuration Sources
Using API
Config config = ConfigProvider.builder() addSource(new EnvSource(), 300) addSource(new FileSource("/cfg/config.properties"), 200) addSource(new WebSource(" 100) addSource(new MyCustomSource()) build();
The second approach is using API. Instead of the default configuration we are using builder pattern here to build custom configuration. Sources can be added as it shown here. These numbers are ordinals. The disadvantage of this approach is that the sources are hardcoded in the application and not externalized.

37. config-sources.xml
File with defined schema using to define configuration sources and their metadata
Default location /META-INF/config-sources.xml
Can be placed outside of the application package
Define using runtime parameter
Define using API
Config-sources.xml file. It’s the third option and the most flexible one. I’ll explain why. Config-sources.xml is an xml file with defined format which is used to define configuration sources and their parameters. When starts, Config framework looks for this file in META-INF directory. The location is customizable it can be supplied using config.sources runtime parameter or using API as it shown here. Placing this file outside of the application package is an advantage for externalized configuration.
java –jar my.jar –Dconfig.sources=
Config c = ConfigProvider.builder() withSources("/cfg/config-sources.xml") build();

38. Sample config-sources.xml
Simple
<config-sources> <source> <source>/cfg/myconf.json</source> </config-sources>
Here are 2 samples. First just defines 2 sources: one is a web source another is a file source. The second defines the same sources with custom ordinals. Another advantage of this approach is that you see all the sources in one file. It’s easy to understand from where application is reading configuration.
With ordinals
<config-sources> <source ordinal="500"> <source ordinal="450">/cfg/myconf.json</source> </config-sources>

39. Sample config-sources.xml
Custom
<config-sources> <source> <source type="com.oracle.config.CloudConfig"> <user>user</user> <password>secret</password> </source> </config-sources>
Third sample. Here we have a custom, third party config source which reads configuration from a cloud service. We define a class implementing ConfigSource interface. It must be on class path. And we define some parameters which is passed to the class constructor.

40. JSR Features (Java EE Next)
I finished with features planed for Java EE 8. Now I will talk about features planed for the next Java EE release.

41. Integration With Other Java EE Frameworks
Read configuration from Java EE Config
Store configuration as part of whole application configuration
Use standard API
Application
Integration with other Java EE frameworks. The idea is to integrate Config framework with other standard Java EE frameworks like JPA or Servlet or JAX-RS the way that they read configuration from the same source as the application and use the advantage of externalized configuration. So web.xml is stored somewhere outside the package or persistence.xml in the cloud storage.
Java EE Config
Application Configuration
JPA Configuration
JAX-RS Configuration

42. Configuration Descriptor
File with defined format
Defines all configurable properties and metadata
Optional
It’s not XML-Schema!
<config-descriptor> <property name="a"/> <property name="b" default=”valueB"/> <property name="c" mutable="false"/> <property name="d"/> </config-descriptor>
Another proposed feature is configuration descriptor. Did you have a situation when you are working with some library and you know that some its features are configurable, but you don’t know how. This feature can help in this situation.
Configuration descriptor is a file with defined format, which describes how application is configured. It contains a list of all properties their metadata and defaults.
Take a look at the sample. There are 4 properties defined. “b” has a default value, “c” is immutable. If this application is passed to ops to deploy on another environment, the engineers will know how to configure it just looking at this file. The descriptor is optional. Everything works without it. And it’s not an XML schema, I want to highlight it.

43. Immutability Mutable Immutable
I mentioned immutable property on the previous slide. You may ask what is it. And I have the answer. Immutable property is read only once. After that it’s value is cached and not changed even if it’s changed in the source it’s defined or in overrides.
Take a look at the sample. Here are again matrixes and balls. Here are 2 pictures describing changing of one property over time. Left picture shows mutable property and right picture immutable.
Here are configuration sources. Sorted by ordinal for easiness. The bottom one has a highest ordinal. The sources are changing over time. Some of them are removed and some of them are added. Green ball indicates a source from which the property is returned.
Take a look at the mutable use case. At every single moment of time the property from the source with higher ordinal is returned.
Lets compare it with immutable use case. You see, the property is evaluated only once. After that it's not changing.

44. Dynamic Configuration
Polling framework
Expressions
Property Resolvers
Configuration Context
Dynamic configuration. This is actually 4 features. The idea is that configuration can change and application needs to handle this change. Configuration can change because someone changed the config file or it may depend on other property values or even on some values passed by the application.
Important to say here is that changes are not initiated by the application. They are coming from the outside. Application cannot change the config, it can only read it.
The first feature is a polling framework. This is similar to what Archaius has - the ability to automatically reread config sources.
The second feature is an ability to use expressions in property values.
Property resolvers is an ability to call a Java method in expressions.
And contexts is a way to pass some data from the application to the Config framework and use this data in expressions. It will allow us to use conditional sources.
It sounds complicated. Let me demonstrate all of this. We will start with polling.

45. Polling // Defining polling using API
Config cfg = ConfigProvider.builder() .withSource(new FileSource("/cfg/config.xml"), 200, Duration.ofSeconds(30)) .withSource(new WebSource(" 100, Duration.ofMinutes(1)) .build();
The idea is that each config source can by polled for changes. The polling interval is specified when config source is plugged in to the framework.

46. Polling Location Ordinal Refresh Interval
// Defining polling using API
Config cfg = ConfigProvider.builder() .withSource(new FileSource("/cfg/config.xml"), 200, Duration.ofSeconds(30)) .withSource(new WebSource(" 100, Duration.ofMinutes(1)) .build();
It can be done using API as it shown here. Refresh rate, is an additional parameter in withSource method. It has java.time.Duration type.
Location
Ordinal
Refresh Interval

47. Polling <config-sources refresh-rate="300000">
<source ordinal="200" refresh-rate="30000">/cfg/config.xml</source>
<source ordinal="100" refresh-rate="60000">
</config-sources>
Another option is to specify polling interval in config-sources.xml file as it shown here.

48. Polling Sources list refresh interval (5 min)
<config-sources refresh-rate="300000">
<source ordinal="200" refresh-rate="30000">/cfg/config.xml</source>
<source ordinal="100" refresh-rate="60000">
</config-sources>
There is a special attribute called refresh-rate. There is also refresh-rate attribute on the sources itself. So config-sources file itself can be polled for updates.
Source 1 refresh interval (30 sec)
Source 2 refresh interval (1 min)

49. Expressions
EL like expressions evaluated at runtime to a property value
Property substitution
Conditional configuration sources
foo=${some.other.value}
bar=${foo + 10}
baz=${foo * bar}
Another useful feature is using EL-like expressions in property values. Tamaya has a similar feature. Take a look at the sample. Property “foo” has an expression in value. This expression means “Read value from some.other.property”. It can be used if we need to configure, for example, a logging level for a group of microservices. We create a group configuration and put a property with desired logging level there. But each of microservices can have different name for logging property. This is where property substitution can be used.
2 samples below show formulas.
Expressions also can be used to activate config sources. Look at the sample. Cust_ios.properties source is enabled only if a value of app property is “ios”.
<config-sources>
<source>//cfg/config.properties</source>
<source enabled=”${app==‘ios’}”>
//cfg/cust_ios.properties
</source> </config-sources>

50. Property Resolvers
Flexible mechanism allowing executing user code in configuration expressions
Can be used to inject cloud resources
<config-sources> <resolvers> <resolver name=”cloud”> <class>com.example.CloudResolver</class> <username>user</username> <password>secret</password> </resolver> </resolvers>
<! > </config-sources>
Property resolvers allow to use custom code in expressions. The use case is injecting resources from the cloud. We define a resolver which connects to user’s account, get a resource by name and returns its value. It can be a connection string or an URL of some cloud service.
To create a property resolver user needs to create a class implementing PropertyResolver interface and register it in the framework in config-sources.xml or using API.
The sample shows reading url of rating service from Eureka.
The sample below demonstrates reading a database connection string from the “cloud” property resolver defined in config-sources/xml above.
rating.service.url=${eureka:rating.url}
cust.db=${cloud:cust.db}

51. Configuration Context
Allows application setting variables which can be used in configuration expressions
Example: geographical zone, application type, etc.
<config-sources>
<source>//cfg/config.properties</source>
<source enabled=”${app==‘ios’}”>
//cfg/cust_ios.properties
</source> </config-sources>
And the last feature – configuration context. Archaious has a similar feature. Sometimes configuration depends on some variables such as application type, geographical zone or profile. These variables are defined in the application. This feature allows passing variables from the application to the config framework and use them in expressions. These variables are part of a special class called configuration context. Here is a sample with “app” variable from the previous slide. The code below shows how to get a property value which depends on the context. There is a special method getPropertyWithContext used for this purpose.
Config config = ConfigProvider.getConfig();
ConfigContext context = ConfigContext.builder().addProperty("app", "ios").build(); Long prop = config.getPropertyWithContext("prop", context);

52. Sample Use Case
I prepared a small sample to demonstrate the configuration framework features.

53. Client Rating https://github.com/psplinakis/ClientRating
Blacklist Service
Financial Records Service
Public Registry DB
Blacklist Service
Financial Records Service
Public Registry DB DB
Customer Service
Rating Service
It’s based on ClientRating application we made to demonstrate how microservices can be used on WebLogic. It can be found on GitHib, link is here. This is a small application which consists of 4 microservices: Customer Service, Rating Service, Blacklist Service and Financial Records Service. It’s from the banking area. The purpose is to return a list of customers with their rating. Customers are taken from the database and rating is calculated using Rating Service. Which checks if the customer is not blacklisted using Blacklist Service and requests customer financial data from Financial Data Service. Which gets data from some public registry. After that some business logic is used to calculate a rating. To simplify the use case, I will use only Customer and Rating service to demonstrate configuration. For the other 2 it’s similar.
Consists of 4 microservices communicating to each other using RESTful API
Each microservice is developed by different team which define its configuration and responsible for its deployment
Confidential – Oracle Internal/Restricted/Highly Restricted

54. Client Rating GET http://custhost/custservice/web/getCustomers
Customer Service
Rating Service DB
GET
This slide shows the request. See there is a profile or application type in the URL. The use case is that we return 30 records if application is ios and 100 records in all other cases. The returned data looks like this. As I said for each record rating service is called like this. 1 is a customer id. [
{cust_id: 1, rating: 9},
{cust_id: 2, rating: 5} ]
GET
rating: 9
Confidential – Oracle Internal/Restricted/Highly Restricted

55. Client Rating cust-db blacklist-url rating-url findata-url
Customer Service
Rating Service DB
Let’s define what configuration is used by these 2 microservices. It’s database connection string, URL of rating service, number of records to return and a logging level. There can be some more. I use only these for simplicity. You can argue that rating service URL should be read from a service discovery. It can be. I just added it here to make it simple.
Rating service config is similar. It has URLs of 2 services it calls to get data for rating calculation and logging level.
cust-db
rating-url
records-count
log-level
blacklist-url
findata-url
log-level
Confidential – Oracle Internal/Restricted/Highly Restricted

56. Client Rating Customer Service Rating Service DB
This slide shows how configuration descriptors for these 2 services look like. Cust_db is immutable. Logging level is defaulted to INFO and Records_count is defaulted to 100. But remember, we need to return 30 if application is ios? So here is a context property called “app”.
<config-descriptor>
<context-property name=”app”/> <property name=”cust-db” mutable="false"/> <property name=”rating-url"/> <property name=”records-count" default=”100"/>
<property name=”log-level" default=”INFO"/> </config-descriptor>
<config-descriptor> <property name=”blacklist-url”/> <property name=”findata-url"/> <property name=”log-level" default=”INFO"/> </config-descriptor>
Confidential – Oracle Internal/Restricted/Highly Restricted

57. Client Rating Global configuration (global.properties)
<config-descriptor>
<context-property name=”app”/> <property name=”cust-db” mutable="false"/> <property name=”rating-url"/> <property name=”records-count" default=”100"/>
<property name=”log-level" default=”INFO"/> </config-descriptor>
<config-descriptor> <property name=”blacklist-url”/> <property name=”findata-url"/> <property name=”log-level" default=”INFO"/> </config-descriptor>
This slide shows how configuration files look like. First of all, we would like to set logging level globally in the application, so we make a global.properties file with only one property and connect it to both microservices. There are configuration files for each of the microservices here. And there is an override for records_count if ios application is used.
Global configuration (global.properties)
log-level=WARN
Microservice configuration (cust_svc.properties)
Microservice configuration (rating_svc.properties)
cust-db=mysql://dbhost:3306/cust_db
rating-url=
blacklist-url=
findata-url=
log-level=INFO
Override only for iOS application (cust_ios.properties)
records-count=30
Confidential – Oracle Internal/Restricted/Highly Restricted

58. Client Rating Customer Service Rating Service DB
<config-sources>
<source refresh-rate=”6000”>
</source>
<source>
//cfg/cust_svc.properties
<source refresh-rate=”6000” enabled=”${app==‘ios’}”>
//cfg/cust_ios.properties
</source> </config-sources>
<config-sources>
<source refresh-rate=”6000”>
</source>
<source>
//cfg/rating_svc.properties
</config-sources>
And this is how config-sources file looks like. Global source is polled to allow microservices react on logging level changes without restarting. Ios source is a conditional one. The condition is here. It’s used only if context variable I added on the previous slide has “ios” value.
Confidential – Oracle Internal/Restricted/Highly Restricted

59. rating_svc.properties
Client Rating
Customer Service
Rating Service DB
I used a model where configuration is stored in shared file system and on a web server. But it can be done different way. There is a lot of flexibility in defining a configuration infrastructure. This is good from one point of view, from another it’s a hustle and can become a nightmare for environment administrators.
cust_ios.properties
cust_svc.properties
global.properties
rating_svc.properties
Confidential – Oracle Internal/Restricted/Highly Restricted

60. Cloud Configuration Service Idea
Customer Service
Rating Service
It can be simplified if cloud vendors introduce a cloud service responsible for storing and managing configurations. It will eliminate a problem of defining and managing a config infrastructure. It can be plugged in as a configuration source to the config framework. DB
Confidential – Oracle Internal/Restricted/Highly Restricted

61. Cloud Configuration Service
Customer Service
Rating Service
Service in the cloud
Distributed and high-available configuration storage
Pluggable to Java EE Config
Integration with other cloud services
REST and web API
Versioning, history, security
Here are some more ideas. It can be high-available and automatically scalable. It can be integrated with other cloud services, such as security service. It can have a nice UI and REST APi and some additional features like versioning, history and security.
There is a server (not a service) with similar functionality. It’s Spring Config Server.
But as I said, vendors can come out with a true cloud solutions. DB

62. Next Steps Take the survey Send technical comments to
Give us your feedback
Take the survey
Send technical comments to
Join the JCP – come to Hackergarden in Java Hub
Join or track the JSRs as they progress
Adopt-a-JSR

63. Where to Learn More at JavaOne
Session Number
Session Title
Day / Time
CON7977
Java EE Next – HTTP/2 and REST
Wednesday 1:00 p.m.
CON6077
The Illusion of Statelessness
Wednesday 4:30 p.m.
CON 7981
JSF 2.3
Thursday 11:30 a.m.
This slide has a list of JavaEE related sessions. Not a big list. Most of the sessions were done on the previous days.

64. Q & A
This slide can also be used as a Q and A slide