4. Why RRE - History
• Heterogeneous servers, OS, DB
• Heterogeneous application servers
with different versions
• Various different components
• People intensive deployment process
• Clear technical structure and
architectural blue prints, as well as
fully adherence to J2EE standards
• Release concept provides rules and
guidelines for updates
5. Why RRE - History
• Source management and
automated builds
• Further automation
requires further
standardization
• Interoperability
• Developer support
6. Why RRE
Reference Runtime Environment should enable us to
verify the technological implementation of solutions and
ensure standardization and JavaEE compliance.
Reference Runtime Environment could standardize the
runtime stack and processes, automate some key
activities and provides rich services.
Reference Runtime Environment could automate and
optimize infrastructure work that is common for a variety
of applications.
Application developers would benefit from cost-efficient
and fast development and standardized environment
8. What is RRE
• Reference runtime environment
is aimed at verifying the
technological implementation of
applications that are installed on
a central server infrastructure.
• It is an early development phase
of the projects, which ensures
the technological independence
and compliance with the Java EE
specifications
9. Central e-government infrastructure
Central (horizontal) functions and
Uvod
building blocks
Manual for project managers and
developers (ABC - development for
egovernment)
Open specifications and
standards“reusability”
Referential laboratories
Interoperability frame – publication of
common building blocks, politicks,
methodologies
Solution lifecycle management
> Common central building blocks
> Reusable modules
> Sample solutions
> Reference models
> Sample frames
> Central infrastructure services
10. What is RRE
• A set of integrated
technical components and
processes for the
development and
operation of applications
12. Reference Runtime
Enviroment
• Part of the consolidation of
the server and application
infrastructure
• Part of Action Plan for • Mostly open source
eGovernment Development • Mostly Java EE 6
• Architecture blueprints, Compatible
and guidelines
• Central RRE governance
• Centralized Platform
Management
14. Where to next?
• Fully open source
• Fully Java EE 6
• savings in maintenance costs
Compatible per app
• Fully interoperable • savings for functionality
delivery per app
• reduction in time tender-to-
delivery
• Open Standards
• WRITE AN APPLICATION
• Open Development ONCE, RUN IT EVERYWHERE
• Open Community
15. Where to next?
Short term goals
• Technical components sustainability
• Architecture, Guidelines &
Documentation
• Developer Support thorough
community
16. Where to next?
Long term goals
• Community building workshops
• Automated, integrated Tool-chain
• Automated provisioning
• Community driven inovation
