In-System Programming for Cloud Dirigible Cloud Toolkit Nedelcho Delchev SAP SE

In-System Programming for Cloud
Dirigible Cloud Toolkit
Nedelcho Delchev
SAP SE
Who is Nedelcho
●
Development Architect at SAP Labs Bulgaria
●
Development Experience and Research
●
Lead of Eclipse Dirigible project
What is Dirigible?
Dirigible is an Integrated Development
Environment as a Service (IDEaaS) for
dynamic applications. It provides both
development tools and runtime environment.
Who cares?
●
●
From the end user's perspective (developer),
Dirigible runs directly in the browser, therefore
does not require any downloads or
installations.
From the service provider's perspective
(PaaS/SaaS), Dirigible packs all required
components in a self-contained software
bundle that can be deployed in any Javabased web server, such as Tomcat, Jetty,
JBoss.
How it relates to Cloud
Development Platform TLP?
●
●
●
Dirigible is part of the Eclipse Cloud
Development Platfrom
It provides an alternative to the standard
development models for cloud environment
Contribute to- and re-use the building blocks
foundation from the other projects Orion, Flux
and Che.
What can I do with it?
●
●
●
Database modeling and management;
RESTful services authoring using various
dynamic languages;
User interface – pattern-based generation as
well as custom forms and reports;
●
Role based security;
●
External services integration;
●
Extensions management;
●
Testing, Debugging, Operations & Monitoring;
What is Dynamic Application?
„A dynamic application represents a software system that embodies a
business process and is built for change, adaptable to business context,
and information rich“
from Wikipedia
http://www.dirigible.io/help/dynamic_applications.html
Live demo please!
Demo
What is the architecture?
Why vertical scenarios? ... with
horizontal scaling?
●
●
●
Covering end-to-end scenarios including all
the application layers from architecture
perspective as well as all the development
process phases from project management
perspective
All or nothing – partial doesn't count
Equal runtime instances based on a single
content package
Why content-centric with centralized
repository?
●
All artifacts in a single repository
●
Operational repository vs SCM repository
●
Simple life-cycle management and transport
●
Workspace, Sandbox, Public Registry
What is the content?
●
Database artifacts as domain model objects
●
Scripts sources as executable artifacts
●
HTML5 user interfaces
●
No explicit compilaton, packaging and deploy
●
No MDA – one-time generation only
Why “In-System Programming”?
●
●
●
Avoid the side-effects of a simulated (local)
environment by working on a live system
Access to the live data via the same channel
which will be used in production
All the dependencies and integrations are on
place as they will be in production
●
Shortest development turn-around time*
●
Short life-cycle management process*
What kind of multi-container
runtime? Docker or what?
●
Dynamic languages containers
●
Rhino for JavaScript
●
Groovy for Groovy
●
JRuby for Ruby
●
Apache Camel for Routes
●
JSON for domain model, security, etc.
Why dynamic languages? Not Java?
●
●
●
Perfect match to Dynamic Applications
„Can interpret (rather than compile) the
execution of tasks“
Existing smooth integration within the web
servers
●
No restart required
●
Java is also supported (javax.tools.*)
Injected objects?
●
Available out-of-the-box for developers –
request, response, datasource, http, storage,
wiki, indexer, repository, user, etc.
●
Standartized API for cloud development
●
Different language's implementations
●
Different provider's implementations
Integration services as part of the
core?
●
Cloud applications as extensions to packaged
software
●
Re-use of 3-thd party services
●
Replication use-cases
●
Scheduled jobs
●
Semantical separation of integration and
orchestration services from the other general
purpose services
Why is the extensibility important and
for whom?
●
●
●
●
Software vendor's code vs customer's specific
extension's code
Update and Upgrade issues
Business agility depends on the process
change -ability
Bilateral extension-points and extensions
descriptors
Why RAP for the Web IDE?
●
Single sourcing – reuse from existing tools
●
Standard APIs – SWT, JFaces
●
Standard modularization – OSGi, plugins
●
Single development language (core) – Java
●
●
Easy integration of external (non-RAP)
modules via the browser component
Mature and reliable
Why it looks like Eclipse in a web
browser? I like webby style more.
●
●
Lower barrier for Eclipse developers
Overall experience comfortable for developers
proven for years from on-premise tools
●
Using of Workbench API and concepts
●
Alternatives available for the „webby“ guys
Why it looks like Eclipse in a web
browser? I like webby style more.
●
●
●
●
Lower barrier for Eclipse developers
Overall experience comfortable for developers
proven for years from on-premise tools
Using of Workbench API and concepts
Alternatives available for the „webby“ guys, it
is time to prove this approach as well
Can I test, debug, operate and monitor
the whole thing?
●
Yes.
Questions?
Q&A
Resources
●
http://www.dirigible.io
●
https://projects.eclipse.org/proposals/dirigible
●
https://github.com/SAP/cloud-dirigible
●
http://dirigible-logbook.blogspot.com/
●
https://twitter.com/dirigible_io
●
https://www.youtube.com/channel/
●
http://scn.sap.com/docs/DOC-33139 IDEaaS