Note: Besides the fact that I’m a alpha user of River and have seen the various slides about In-Memory technology in Boston, I don’t have any further details about the future planned architecture or details about the use of this new In-Memory technology in River.
I already Aggregation Patterns in OnDemand Edge Platforms: River vs. StreamWorkabout the difference between the consumption patterns of River and StreamWork . This blog continues along these lines of analysis.
Thanks also to Dennis Howlett who showed me a sketch of a River architecture including In-Memory technology during our session with Sam Yen in Boston. This blog is an elaboration of his sketch.
For the developer using River, the data layer that is the foundation of applications is hidden. Via the WYSIWYG User Interface of River, the developer creates forms / views and the underlying data structure / queries are created automatically via a Data Services layer. You need not know whether the database is based on Oracle, MySQL or DB2. This is dealt with in River’s Collection / Record implementation.
River – remember, raising the level of abstraction – has made a lot of the choices for you. You don’t program against a database abstraction API, you just define what you want to persist. River will take care of it. In the last two years we have actually replaced the database technology three times (with the next change already happening), without any impact to the applications. [SAP “Project River” – how does it compare to xyz?]
What are the implications of this change?
In-Memory Technology for the Masses
The use of In-Memory technology in River as a PAAS, however, should allow this technology to be available to the ‘Masses’ . On River, I could develop a game or a shopping application or an application dealing with social networks – I can focus on the consumer market rather than the business user.
In some ways, the distinction between River and the other environments is similar to the difference between Apple / Android and their respective philosophies regarding the rights / openness of the ecosystem.
Now some may be asking why I would want to create a River application with a non-business focus. River has a variety of other advantages over other OnDemand development platforms. One of the most intriguing will be the ability to pull in data (purchasing history, travel history, etc) from back-end environments (for example, via Gateway). This data then could be stored using In-Memory technology and the user could then use the potential of In-Memory technology to examine various simulations. Of course, this information might be enhanced when the user is accessing the data via mobile client and his/her current location is pulled into the equation.
Other potential use cases might exploit this In-Memory technology to perform semantic analysis of data originating from social media / commercial sites and linking this data to other information.
As described above, the River implementation hides all the deep / complicated database-related code. The switch to In-Memory in River should allow developers to manipulate In-Memory data sources without having to write any additional code. Currently, HANA supports accessing the data via SQL and MDX and other means. With River, developers can now access such data sources without having to use these query languages – they can work graphically.
I have no idea what administrative tools (create datasource, change data structure, etc) will be available for the In-Memory technology but in River, the developer will never need to see such tools.
Access In-Memory Data via REST APIs
Of course, modern tools / code generators can create all the code necessary for REST APIs but the River developer doesn’t have to worry about generating new stubs every time he changes his UI – this is done automatically.
Will direct access to the In-Memory Business Logic Layer be necessary in River?
As was discussed in the Influencer Keynote in Boston, there will be a number of built-in functions (with typical database functions – rounding, etc – as well as other functions with a more specific business focus) in the In-Memory core. Developers can also add functionality / logic to this core via “stored procedures” that are close to the data storage and are perfectly suited for the high performance needs demanded by the In-Memory technology.
As mentioned above, River developers usually won’t have to deal with the In-Memory functionality. How can River applications take advantage of these built-in in functions? In all likelihood, the Data Services Layer in River will have to be adjusted to deal with the potential of these built-in libraries. This layer might use standard SQL to access In-Memory-based data but this probably isn’t the best choice to exploit the potential of this technology.
In River, developers have the ability to write their own code – via the CodeBox- if they want functionality that can’t be generated automatically. What happens if a developer has functionality / business logic that should optimally be an In-Memory stored procedure – for example, to assure the highest performance. My suggestion would be additional CodeBox functions / syntax that are then stored in In-Memory.
Is In-Memory technology even needed in OnDemand Edge products?
Some might thinking – “Great that In-Memory technology is present in OnDemand Edge products. Are the business requirements there to necessitate its usage? I really don’t think you will have a River application with 3 TB of information.”
First of all, the SAP OnDemand Edge Product line includes BIOnDemand and StreamWork as well. These environments (especially BIOnDemand) are an excellent fit for the analytic functionality made possible by this technology. There are possible use cases (for example, simulation) which would also be possible.
It is always been known that River isn’t the ideal platform for complicated applications that use Core business functionality. For Edge applications, however, River is perfect. The fact that developers will be able to exploit In-Memory technology just increases its attraction for such scenarios.