The introduction of the SAP HANA Extended Application Services alongside the SAP HANA data base has presented a unique opportunity to provide customers with a solution that leverages the proximity of the database and application server, greatly simplifying the technical system landscape. HANA now represents a complete application platform.
This combination provides an opportunity to explore how in-memory technology can be used to not only transform enterprise applications, but also how they are developed.
Over the last 12 months we have spent extensive time at customers and partners understanding this. It turns out that the number one barrier to business satisfaction and developer productivity is the impedance that exists between the various roles and layers that are involved in the application development process. For example, at one of our large partners there are 9 distinct, specialized roles between the definition of business intent and the deployment of an application.
Much of this complexity is due to the fact that traditional application run-times are performance bound. In order to achieve optimal execution, the application’s code undergoes careful optimizations – data load and transfers, query optimizations, etc. – to work with the underlying engine. Such optimizations do not add business value as they have nothing to do with the realization of business requirements in code. We have completely rethought this process based on the new capabilities enabled by HANA. The result is a simplification of the development process because we can now eliminate such optimizations from appearing in the code.
In short, it is now possible to cleanly separate intent from optimization, meaning that we can now develop high performing, native in-memory applications with tools that are incredibly simple and easy to work with. The speed of HANA also enables developers to see the impact of their code as they write it, and share the results with end users immediately. Tasks and activities that have traditionally required handovers across roles or domains can now be consolidated in one hand.
We also realize that business applications live beyond the technology and its progression. We want to allow developers to build an application in such a way that will allow them to transparently leverage technology improvements. The corollary is that an application developer should worry less about the technical application setup and its optimization, and more on the application’s intent.
So how do we decouple optimization from intent?
Enter RDL – the River Definition Language.
RDL is an executable specification language that allows development teams to collaborate and specify what applications do, while staying away from how the application’s requirements are realized; all this, without compromising on application performance and robustness, on top of HANA.
RDL is what stands at the heart of the River Development Experience – a next generation development experience targeting various development scenarios and needs in HANA. RDL aims to provide a comprehensive solution for specifying a complete business application, covering almost all essential core aspects: data model definition, business logic, access control, validation, error handling, etc. It is constructed as a coherent set of DSLs that work together to provide an easy to use textual specification of the language; all this while being automatically compile-able into the HANA execution runtimes, namely the HANA XS and the HANA Calculation Engine. So on top of being readable and easy to consume, the technology easily lends itself towards allowing a low learning curve for HANA.
In order to achieve this, we adopt several principles that manifest themselves in the language design:
Having a language that adheres to these principles, allows the application specification to be more succinct and readable, resulting in a considerably smaller bill of materials. This in turn results in easier maintenance and simpler lifecycle management of application code. Being declarative allows the application’s execution (its “runtime”) to improve transparently with the underlying technology. The declarative nature of RDL “shields” the developer from technology changes, essentially distilling the application’s real assets: its data model with its associated behavior and related business scenario specific information.
For example, think of an application using ODBC/JDBC when reading data from a data base and the amount of data conversion/translation carried out only to deliver the data from a DB server to an application server. Having the application’s RDL specification compiling into the necessary containers makes this translation redundant.
Additionally, given that the entire application is coded in a language that encompasses various aspects of the application, the RDL compiler can more easily optimize across these aspects. A feat that is considerably harder when we have, for example, distinct languages to express control logic and data queries and when interoperation occurs only at runtime.
To summarize, developing an application using RDL has several key benefits over traditional technologies and development models:
RDL, combined with the River Development Experience (RDE), results in a superior application construction experience when compared to traditional application development technologies. A combination that leads to lower development and maintenance
costs, without compromising on optimal execution.
Lior Schejter, Jake Klein