Skip to main content
Skip table of contents

Cantara Network Architecture Options

Cantara supports a variety of network architectures for installation for both the cloud and on-premise versions. This document explores some of the common approaches and the considerations of each.

Cloud Installation Options

With the cloud deployment of the Cantara Integration Platform, the only consideration that must be made is how and where the Cantara Agent will be deployed. The Cantara Agent provides the following functions within the Cantara Integration Platform:

  • Secure connectivity between the Cantara Integration Platform Cloud and the customer data centre
  • Access to the customer's Oracle JD Edwards EnterpriseOne enterprise servers
  • Access to the customer's network printers if required
  • Access to the customer's IMAP mail service if required
  • Access to the customer's SMTP mail service if required
  • Access to the other third party systems hosted within the customer's network
The agent supports deployment either as a standalone daemon service or as a WAR deployed on an Java Application Server that supports Servlet specification 3.0 or higher.

Cantara Cloud Architecture - Option 1 (Preferred)

CANTARA CLOUD ARCHITECTURE - OPTION 1.pdf

The above architecture has the following features:

  • The SSL communications end point is located at the edge of the corporate network DMZ. This provides optimal performance without compromising security.
  • For high availability deployments, the agent should be access through load balancers rather than a simple reverse proxy. The load balancers should be configured for sticky web sessions using cookies to minimise traffic and authentication overhead.
  • The agent should be placed as close to the JDE Enterprise servers as possible within the network. The latency between the agent and the JDE enterprise servers is a critical metric with regards to system performance and should be minimised.

Load balancers can be replaced with simple reverse proxies to provide the necessary SSL end point. This does mean that only a single Cantara Agent can be deployed per end point so HA functionality is reduced.


Cantara Cloud Architecture - Option 2

CANTARA CLOUD ARCHITECTURE - OPTION 2.pdf

The Cantara Agent can be deployed within the DMZ if required. However, access to the JDE Enterprise servers through the firewall is required. If other services such as media object file storage or network printing are utilised then these services must also be accessible.

On-Premise Installation Options

The Cantara Integration Platform is deployed as one or more farms. A farm if effectively a platform environment, for example production vs non-production and will contain the following components:

Cantara Worker Application

This is a java web application and is the primary component in general operation of the Cantara Integration Platform. The worker application instances will require a common database to be deployed which will store service definitions, client authentication tokens and scheduled jobs. The worker can access the JDE Enterprise Servers directly or alternatively can utilise the Cantara Agent in the same method as a cloud deployment. Multiple worker instances can be deployed within a farm to provide high availability.

Cantara Assur Application

This is a java web application and provides command control functions for all worker instances deployed within a farm. The assur application instances will require a common database to be deployed which will store the farm definition, service definitions and user management information. Multiple assur instances can be deployed within a farm to provide high availability. The assur instances must be able to communicate with the each worker instance directly as well as through the load balancer if this is being utilised.

Cantara Console Application

This is a java web application and provides administration access to one or more farms. The enable the console to execute it must be able to communicate with the assur instances directly. Multiple console instances can be deployed to provide high availability.

Cantara Agent

This is an optional component which can be utilised to communicate with internal services, such as the JDE Enterprise servers, where locating the worker instances within the corporate network is not preferred.

Cantara On-Premise Architecture - Option 1

CANTARA ON PREMISE ARCHITECTURE - OPTION 1.pdf

The above architecture has the following features:

  • The SSL communications end point is located at the edge of the corporate network DMZ. This provides optimal performance without compromising security.
  • For high availability deployments, the worker instances should be access through load balancers rather than a simple reverse proxy. The load balancers should be configured for sticky web sessions using cookies to minimise traffic and authentication overhead.
  • The workers should be placed as close to the JDE Enterprise servers as possible within the network. The latency between the agent and the JDE enterprise servers is a critical metric with regards to system performance and should be minimised.

Cantara On-Premise Architecture - Option 2

CANTARA ON PREMISE ARCHITECTURE - OPTION 2.pdf

You can choose to deploy the Cantara Agent for an on-premise installation of the Cantara Integration Platform. This allows the worker instances to be moved to the DMZ for added external intrusion protection.

On This Page

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.