Work in progress. Trying to formulate and capture the essence of what the project tries to achieve.
One aspect of building a successful business is the ability change rapidly. But change is also related to difficulties, risks, and costs. Clearly more so in dynamic and elastic Cloud Computing environments where scale, diversity and complexity can be become painfully obvious trying to change and adapt applications.
Good architectures allow deferring design decisions but at some point a implementation specific decisions would need to be taken. Deciding on a persistence layer is an important decision that involves a great deal of planning and many people of different roles to get right. The choices to make are many and non-trivial.
-
Data model.
Relational or object database, NoSQL, LDAP, XML etc.
-
Vendor
Microsoft, Oracle, MySQL, Postegresql, MongoDB, Neo4j etc.
-
Persistence framework
JPA, Hibernate, JDBC, Spring DAO, MongoDB, JDO etc.
After a decision have been taken a great deal of persistence specific code needs to be written. A need for second persistence layer may surface along the way for speeding up testing.
Introducing new entities to the persistence layer throughout application lifecycle usually requires a signification deal of additional planning efforts. It is indeed a challenging task to get schema, queries, caching, tests and runtime integration right.
Projects usually devote a great deal of thought for developing a strategy for switching persistence layer in case business demands it, meaning not coupling the domain too tightly to specific persistence details. But even if the plan seems solid hypothetically, replacing the persistence layer is no quick or easy task.
The mission of the project is to support long-running enterprise Java applications with a framework for handling configuration changes without restarting themselves.
The framework also aid developing applications that are decoupled from knowing how and where to store, retrieve and validate configuration.
The aim is liberate applications to use configuration seamlessly on the terms of their particular environment without constraining them to Java SE, EE, OSGi, Spring, CDI or any other programming model or framework.
To fill a relevant need in the Java community and support building highly-available applications we believe that the following goals should be pursued.
-
Productivity and Simplicity
Using configuration must be intuitive and non-intrusive; managed in a unified way to support developer productivity. Configuration is published and discovered automatically when it become available and is also reusable in different contexts without burdening applications with portability issues.
Predictability and Clarity
Configuration is strongly-typed and give the capability to declaratively express the intents and rules under which circumstances the application can promise correct behaviour. Violations are handled reliably and does not disturb application behaviour. Valid changes are applied and exposed to applications in a consistent way.-
Extendability and Portability
As applications are developed in different shapes and sizes; configuration should enable, not limit, a diversity of platforms and technologies. Applications are supported with the flexibility to extend and customize a variety aspects locally and still be able to manage configuration in a central and unified way.
-
Performance and Scalability
Configuration should not be a limiting factor to application performance. It is quickly accessible to be able to meet service-level agreements in environments of scale.
Configuration is a general term that may have different meanings in different contexts. There is little meaning trying to categorize any ambiguity between, for example, traditional configuration and provisioning data.
It is however useful to agree on a set of principles and constraints in order to put the data which we broadly call configuration into application perspective.
-
Configuration is considered read-mostly to human application operators/administrators in the organization. This perspective is referred to as the admin context.
-
Configuration is considered read-only to application developers. This perspective is referred to as the runtime context.
-
Configuration never change from events triggered by machine-to-machine communication or direct end-users/customers interaction with the application.
