Home > Blog > Blog > 2012 > November > 15
Currently Being Moderated

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:

  1. Readability is key: expressive and simple language constructs that enable higher level concepts to be easily specified.
  2. Declarative nature: focusing the developer on capturing the application’s intent, rather than its execution mechanisms. Conceptually, it is similar to the idea of standard SQL, only applied to a broader (and more complex) domain.
  3. Coherency: different aspects of the applications are specified in a manner that allows interoperability. RDL conveniently leverages the underlying HANA data definition and query languages to interoperate with additional syntax specifying further semantics like business logic, validation and access control.
  4. Flexible modularization: support for different development working modes and scenarios – from small focused teams working rapidly on well-defined applications, to large scale applications with numerous developers working iteratively to prototype and refine the application’s definition.This includes separation of concerns in the application’s code, as
    well as iterative application specification.
  5. Openness: allow seamless interoperability  with existing assets, e.g. legacy code and existing database tables. Also allow for integration of services and libraries developed using other languages/technologies.

 

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.

 

Of course, some scenarios require very technology-specific coding or knowledge. RDL enables that as well – allowing the developer to “break out” into the underlying technology and applying optimizations or useful techniques in a specific technology. It’s important to note that RDL does not constitute a complete stack of its own. RDL is purely a design time “creature”, which is compiled to underlying runtime containers – Javascript in HANA XS and SQLScript in the HANA context. There is no independent RDL “runtime” or virtual machine of any kind. There’s no artificial layering or abstractions introduced into the application’s runtime. This allows us to avoid unnecessary translation and data conversion that is usually introduced as a result of abstractions created in different stacks.

 

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.

 

RDL and RDE are fully integrated with the recently released HANA Extended Application Services platform and compliment the JavaScript and SQL Script development experiences that are available with HANA. In fact, RDL compiles down to JS and SQLScript and provides substantial benefits on top of these approaches. With regards to SQLScript, RDL lowers the barrier of entry for development of HANA native apps, and does not require that a programmer have extensive database development
experience.  JavaScript on the other hand is an excellent language for general application development but lacks certain features that make enterprise application development easier, such as access control and embedded query and business semantics. That said, RDL can elegantly consume pre-existing JS and SQLScript artifacts.

 

To summarize, developing an application using RDL has several key benefits over traditional technologies and development models:

 

  1. Easier and faster development and maintenance:
    1. Declarative, focusing on application intent
    2. Expressive language constructs
    3. Flexible code specification, enabling easier separation of concerns and iterative refinement of application code.
    4. Smaller bill of materials – coherency across different layers and components of the application.
  2. Easily leveraging HANA’s power, while remaining agnostic to underlying technology containers (XS, SQLScript).
    1. Can leverage any underlying supported runtime container, without compromising on running time optimization.
    2. Application execution improves together with the underlying technology, transparently; taking advantage of new
      capabilities.
  3. Open to legacy and extension code, in all supported containers.

 

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



Comments

News Archive

SAP HANA News Archive

Filter Blog

By author:
By date:
By tag:

Contact Us

SAP Experts are here to help.

Ask SAP HANA

Our website has a rich support section designed to help you get the highest quality answers quickly and easily. Please take a look at the options below to get you answers from the SAP experts.

If you have technical questions:

If you're looking for training materials or have training questions:

If you have certification questions:

Χ