One of the most important enhancements in the HANA Cloud Platform (HCP) last year was the ability to use the HANA XS engine to create applications – an ever-increasing number of threads in the HCP developer forum on HANA XS usage reflects the popularity of this feature. Yet this functionality is still largely segregated from the existing platform and its JVM focus. The relative isolation of the two fundamental feature-sets means that developers really can’t optimally use the platform. This problem is especially true for HANA XS developers in that they can’t exploit the framework services already present in the JVM-based environment. It is as if such applications were ice cream cones with two flavors (not scoops!) that exist side-by-side – touching but not really blended.
This isn’t something I made up – there are developers out there working on such hybrid apps and they are struggling with the architectural complexity involved in the creation of such applications.
Note: I know that “hybrid” usually has a different meaning in the SAP Cloudsphere (OnPremise vs. OnDemand, PrivateCloud vs. PublicCloud, etc) but in this blog it will have a different meaning.
I’d like to explore the existing integration possibilities between these two flavors.
Note: In this blog, I’ll focus on JAVA-based components when I talk about JVM-focused components but applications from any programming language which can run in the HCP JVM face the same issues.
In this scenario, the HANA XS components are using the HCP infrastructure as an IaaS and no integration with JVM-based components is present. Many of the existing threads on this topic in the HCP discussion forum on SCN concern this scenario.
Using HANA as a data source in JVM components via JPA
In this scenario, the JVM-based components use Java Persistence API (JPA) to access HANA data in the database. These components could also use JDBC to access the data – or stored procedures.
Note: What I don’t think works at the present time is the ability to call a function in a HANA XS JavaScript server-side library file from a JVM-based application. Indeed, the HCP documentation specifically states that the Persistence Service can’t be used with HANA XS.
In this scenario, JVM-based components use REST calls to access OData interfaces that have been created by HANA-XS based code. There are a variety of frameworks available for JVM-based components to easily access OData interfaces including Apache Olingo.
In this scenario (which I must admit I have to yet to see being used and thus might be regarded as theoretical), the use of the $.net.http.Client class in HANA XS would allow applications in this environment to access JVM-based applications that present such interfaces. The use of other JavaScript-based libraries (like JSON processing) would improve the efficiency of such integration and would allow better access to existing Framework Services provided by HCP. For example, the Connectivity Service provides access to OnPremise Assets while the Document Service provides a CMIS-based interface to its functionality.
Some difficulties here include the fact that destination administration for the HANA XS necessary for Outbound Connectivity is distinct from the Destination administration necessary to use the Connectivity Service in the HCP – this increases the complexity of the administrative work.
As this final scenario depicts, there is the potential for HANA XS apps to access JVM-based applications based on HTTP. Yet, this is access is relatively primitive and is based on JVM-based applications provide a HTTP interface. Existing JAVA frameworks that might provide useful functionality but which don’t have HTTP-based interfaces, however, won’t be available to HANA XS based applications.
River is a new development language for HANA. My assumption is that sometime in the future that it will also be available in the HCP environment.
River has the ability to call HANA-DB based objects (SQLScripts, XS JavaScript Functions, etc) and the ability to use web services through the utility function sap.hana.repository.sap.hana.rdl.ws.utils.toWSInput (although this functionality is based on HANA-based destinations for HTTP).
Note: Yes – I know that River is just a design-time and not a run-time tool. My assumption is that it generates code to deal with such integrated-related tasks.
Note: River-designed HANA XS components could also support OData integrations as mentioned above.
River’s additional ability to use SOAP out-of-the-box, however, doesn’t bring us a fundamental integration shift that might be possible.
A recent blog about the design principles for River provides some interesting areas to consider:
In today’s technology landscape, applications are rarely built using one technology. While most developers like to “start fresh” when coding an application, the reality is that there are considerably large, well established, code bases out there with years of work put into them. Even new applications will most likely be built on top of these.
Additionally, it is very likely that a developer would encounter the need to leverage some technology-specific runtime capability that isn’t easily expressed in River or supported by the River compiler.
To this end, we adopt an openness principle: River allows the consumption of components created using other technologies, or “breaking out” from River code to other technologies. The challenge is of course to allow this consumption without compromising other aspects mentioned above, namely simplicity and coherency, but also River’s ability to optimize the running code – invoking a runtime-specific code binds the execution to that runtime container.
These are a very intriguing statements and a recent picture seen on Twitter shows which languages might be relevant for such “break-outs”
What is unclear is exactly how the break-out functionality might be integrated in River. Would you develop in RDL and the framework would create JAVA code (reminds me of Spring Roo)? Or would you embed JAVA code directly into your RDL code?
In our model of HCP integration patterns, this evolution results in an interesting diagram.
To be truthful, I don’t know if this would bring the two HCP flavors closer together. Under the covers, the only existing integration path is still HTTP / OData. JVM-based components without a HTTP interface still have to be wrapped with such functionality to allow access.
In this blog, I’ve focused on the architectural considerations when blending the two development flavors. There are a variety of other related topics that are interesting to examine.
Each scoop of ice cream with multiple flavors is unique and has different amounts of the used flavors - resulting in different swirls. This visual individuality combined with the merged taste is why we love ice cream. Hybrid applications in HCP are similar – there may be general patterns but each application is unique.
When I look at the integration scenarios described above, I get the feeling that the HANA XS and JVM-based flavors in the HCP will largely remain separate. Although a tighter integration is desirable, the question is whether a deeper integration is even possible. The two environments run in two separate runtime containers – JVM vs HANA database – so a tighter integration is difficult. The challenge is to optimally use each environment to create innovative applications. As more developers work in this platform and publicly describe their experiences, working “recipes” will be help guide developers to exploit the platform's potential.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
36 | |
7 | |
5 | |
5 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 |