Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

XS Advanced for (Not So) Dummies: Multi-Target Apps

DZone's Guide to

XS Advanced for (Not So) Dummies: Multi-Target Apps

Explore SAP's XS Advanced architecture to see how it focuses on and incorporates microservices into a multi-cloud approach.

· Cloud Zone ·
Free Resource

See why enterprise app developers love Cloud Foundry. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity.

In an earlier post, I touched on some basics of Cloud Foundry and how SAP approaches its use.

But did SAP just grab Cloud Foundry and put its logo on it? Of course not. We have a very powerful database called HANA and a whole set of tools that were already in place and being used by devs out there. This was about combining existing capabilities and porting what was already powerful onto the more scalable and multi-cloudable solution. Some of Cloud Foundry's characteristics were not adopted and proper SAP adaptations were performed.

Let’s drop the buzzwords and understand this mashup.

Multi Target Applications

This sounds like one of the (many) cases of fancy names for something simple. You’ll tell me if this applies later…

Typically, an enterprise application will access the database and have code to add business logic to the data (or share data to another system, or nag a user for action, or insert more data, etc). This application is normally defined by somebody, coded and unit tested by someone (else), validated as a part of a bigger picture, and finally moved to a production environment. We call this the lifecycle, right?

More technically, we have a user interface, we have some logic and then we have the database.

The some logic part is not as innocent as it might seem: A full stack coder friend of mine used to talk about “the backend of the frontend” and “the backend at the back”. In other words, you could even have business logic in two different places: the code feeding the UI and the logic embedded in the database modelling. Different components (layers), same lifecycle:

In our new architecture, each of these layers can be mapped to a different box in the XS Advanced architecture diagram (presentation layer at UI5, backend logic to Node.js or Java, and the modelling and database at the base).

I’ll let you add the arrows mentally for this one:

First, let's respond to the original question. A multi-target application is an application whose runtimes are provided by the different boxes or components but only serves a business purpose if those components are held together through its lifecycle.

(I hope you can produce your own definition and tell me if the name is just fancy.)

For example, you could develop a piece in UI5, another piece in Node.js, and a CDS view that taps the database. Each of these could even be created by different developers or executed separately, but they would make no sense unless they are treated as a single business application on its way to the production environment.

Let’s Go Deeper Into the Technical Level…

In the XS Classic approach, each of these “boxes” would have run all of the different applications in copies of the same (JavaScript) virtual machine, against a connection to a schema in the database administered by the applications. That is, a single operating system process eventually catered for all of the runtime needs of each of our different coding masterpieces. You could sometimes see the XS Engine process sweating…

The monolithic process serving all VMs

In the new approach, for the logic piece in Java or Node.js, a “copy” of the box (call its runtime) is created and bound to a specific application. Even the database binds a dedicated instance of itself to a single application in the shape of a container (note that I am not using the word “copy” for the database… that would be huge).

This way, our business application will get its own piece of the Node.js runtime with everything it needs to execute its code as a separate operating system process. Something more like this:

Those copies of the runtime are microservices. That name is not as fancy, but microservices are a bit tricky. With that in mind, we will take a deeper look into this architecture and its implementation in the next blog post (coming soon)!

Cloud Foundry saves app developers $100K and 10 weeks on average per development cycle. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity. Find out what people love about the industry standard cloud application platform.

Topics:
sap ,cloud ,microservices ,cloud architecture

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}