On the Apprenda Platform, all Java Web Application components are required to be packaged as Java Web Archives (WARs).
When a deployment of a Java components is initiated, there are two steps, described in greater detail below, that occur when a Java Web App is deployed or otherwise managed on the Platform.
The specifics of this routing and how Apprenda chooses the initial server for deployment are discussed in the next few sections.
Before discussing what happens when Apprenda deploys your Java application, we’ll cover how the URLs used to access the Java Web App of your application are constructed. Apprenda bases your application’s URL on your application’s alias. This alias, coupled with the application version alias and Apprenda Root URI, is used to direct all incoming requests to your Apprenda application.
Please Note: an application’s version alias is only used in URLs of applications in the Sandbox stage in order to differentiate different versions of the same application that may be accessible in the testing Sandbox at the same time; there can be only one Published version of an application at a time, though, so the app’s alias is not used in URLs for accessing the Published application version.
Apprenda supports two patterns for accessing your user interface:
The pattern must be selected prior to deployment of the application by the Development Team that publishes the application. The default pattern can be specified for new applications by the Platform Operator. In the patterns above, items in square brackets denote optional items. In the case of http[s] this denotes an SSL connection. Apprenda will automatically redirect non-SSL traffic to SSL if SSL connections are enforced by the Platform Operator. In the case of the [–$versionAlias], traffic will route to the Published version of the application if the specific version is not defined in the URL. Note that this moniker permits multiple versions of an application to be in the Sandbox stage at the same time.
Suppose one wishes to access Version 2 of an Apprenda application called Northwind, which was deployed to an Apprenda instance available at contososoftware.com; they would use the following URLs:
If and only if Version 2 is in the Published stage, they could access Version 2 of the application with the following URLs:
Apprenda can configure your application to respond at the URL of your choice (configured in the Developer Portal). When a custom URL is specified, the appropriate bindings are configured on the websites so that they resolve the URL. No other intervention is needed, although the Network Administrator must point this URL to your Apprenda instance so that it can properly resolve DNS for the custom URL.
For example, assume that Contoso wishes to make the Northwind application available online at northwindonline.com. When configuring the application, their Development Team would specify the custom URL as “northwindonline.com”; the URL used to access the application would then be:
Deployment of your Web Application Archive can be triggered by any of the following events:
The following tasks must complete in order to deploy the application onto the instance (some will occur concurrently):
The remainder of this section covers the latter four steps in more detail.
Once a server has been selected to host the Java Web Application, Apprenda will:
During the Java Web Application bootstrapping process, a private application server instance is installed to the target machine to handle hosting duties for the Java Web App instance; no additional configuration is needed. Any necessary configuration is set according to previously-selected settings defined in an application’s Deployment Manifest, through its configuration in the Developer Portal, or through Platform Operator-defined settings in the System Operations Center (SOC).
DNS or HOST file entries result in all inbound traffic being routed to the Load Manager. Apprenda creates the necessary ARR URL re-write rules to break down the requested URL for the application and forwards it to the appropriate Linux server chosen above that is now hosting the application. Custom URLs, if specified, are re-written here as well.
So that the Load Manager may also host Apprenda applications, Apprenda uses internal ports when the request is forwarded from the Load Manager to the web server hosting the application (which may or may not be the same server). By default, the primary web server’s processing of URLs occurs on Port 80 and the internal port used for forwarding the request is Port 8080. Stated differently, all Java Web Apps deployed by Apprenda respond to Port 8080.
To secure actions involving sensitive data such as login and application usage in general, Apprenda supports SSL natively and seamlessly with no further action needed by the application Developer. Apprenda will automatically configure a wildcard security certificate on all Linux servers participating on your Apprenda instance. Whereas ports 80 (and 8080 internally) are used for your http connection by default, ports 443 will be used for your https connection by default. To ensure better performance, Apprenda terminates external SSL connections at the Load Manager server using the ARR module and uses http connections internally. This strategy of SSL traffic management is known as SSL Offloading and is a common technique to route HTTP traffic among servers that inherently trust one another.
Java Web Applications on Apprenda are not considered durable resources. In other words, a server may go offline either in a planned or unplanned scenario. To provide high availability for Java Web Apps (and assist with performance under high load), Apprenda natively supports the replication of the Java Web App on multiple servers. If the deployment request is to replicate the Java Web App, Apprenda will create a web farm in IIS on the Load Manager server, and route requests through the web farm. This web farm is updated when one subsequently removes, relocates, or again replicates the Java Web App in a future action.
Note: This section applies only to applications requiring authentication.
Once the User provides authentication information, this creates an active session on the entire Apprenda system (this session is omnipresent and has nothing to do with HTTP) and creates an encrypted, tamper-proof cookie that is used as a trust token for future requests. A screenshot of the cookie (as per Chrome Developer tools) can be seen in the illustration below:
When the User logs in and an Apprenda session is created, Apprenda also establishes an inactivity window (configurable by the Tenant’s Company Administrator); if the User is inactive for some period of time beyond the established inactivity window, the session is expired. The cookie is subservient to the Apprenda session, so even if future requests have a valid Apprenda authorization cookie, the request will be rejected and the User will be required to log in.
In Apprenda, web farms are created when a new Java Web Application partition is deployed to a new Linux server, effectively creating another copy of the Java Web App. When a Developer or Platform Operator sends a request for a new Java Web App deployment, Apprenda does the following:
Diagram of the Java Web Application Tier with a Web Farm
The following steps represent the path taken by the request across the Java Web App tier of the Apprenda instance when a web farm is in place:
Thus far you’ve learned general details about how Apprenda deploys Java Web Applications, but with a multi-tenant deployment there are additional considerations to be aware of.
Like .NET services, user interfaces, and databases, Java Web Applications should be designed as though one and only one Tenant is using the Java Web App at any particular time (as though it were deployed on-the-premises). Apprenda will deploy your Java Web Apps in a multi-tenant fashion at deployment time as specified by the Commingled sharing model, where one Java Web App serves the web requests of multiple Tenants, and many Tenants share the same memory and process.
Each process that hosts your Java Web App instance is a partition, so each partition corresponds to the process.
For Commingled Java Web Apps, this is no different than single-tenant applications.
For Commingled Java Web Apps, this is no different than single-tenant applications.