VegaWeb - L'infrastruttura

This is the vegaweb application structure, either in mobile-app or website version

The components included in the "Customer network" rectangle are usually che customer machines (on-premise or cloud). The communication between the "Customer network" and the other servers is always through an ipsec tunnel or another "secure" media (some of the protocols can not be encrypted, depending on the enabled functions or the software releases in use on the VEGA machines).

The icons in the graph do represent "roles" and not "machines". In some cases 2 or more roles could be running on a single machine (physical or virtual).

Here is a detail of the roles:

VEGA database

This is the Oracle server with the customer VEGA database. It doesn't require any change else some configuration for the connection to the vegaweb database.

Vegaweb2

This is one of the VEGA client applications. Its main roles are the syncronization-services monitor and the order-confirmation emails enqueue.

WVservices2

Depending on the vegaweb options chosen, there could be the need to start some other VEGA client applications i.e. WVServices2 and/or VegaREST. Their scope is to give real-time updates to the web application.

VEGAWEB database

This is the Oracle database containing a partial-replica of the VEGA contents. It's usually installed on a external datacenter, to ensure maximum availability to the application, even if the VEGA server is down (for updates, line issues, failures).

Vegaweb REST server

This is the core component of the vegaweb infrastructure. It's a weblogic application server running java apps who manage the communication between the front-end (mobile app and/or website) and the vegaweb database.

Vegaweb site front-end

This is the website with responsive interface the users will use from a web browser.

Vegaweb application deploy

Customer network:

The "Customer network" components usually don't require structural changes.

The WVservices2 and Vegaweb2 are usually run on one of the customer's syncpalmari machines, so they do not require new servers. Check with customer what machine he prefer to use, explaining that it should have a static (private) ip address to be reachable from the "Vegaweb REST server" via vpn or firewall rules.

VEGAWEB network:

All of the other roles will be run on a datacenter network but they will be mostly safe because only a small subset of the services will be exposed on the Internet.

The communication between the components will be limited to the following flows:

In addition, the VEGAWEB machines will need to access the Internet to download updates and, in some deployments, to send emails.

VEGAWEB server

Depending on the customer size and requirements we will opt for a partially/totally shared infrastructure or for dedicating a machine for one or more roles.

Many small customers can share a database server, a REST server and a front-end machine while bigger companies need dedicated machines for same or all of the roles.

Digisoft is offering dedicated and shared cloud servers for any roles but the customer can decide to use its own machines. In this case the customer will provide the servers and the network configurations and he will manage the infrastructure (OS updates, IPS filter check, service monitoring, etc). Digisoft will configure the applications on the provided machines and will update the components when needed. We will need administrative rights on the machines to be able to configure them.

If the customer will choose Digisoft managed hosting, we will plan the infrastructure depending on the customer size and needs (basically, how many roles can be shared or will have to be dedicated). The servers will be hosted on a high-available cloud datacenter and managed by digisoft. During the deploy phase, we will need the customer's IT assistance to establish the communication between the VEGA and the vegaweb machines. In case the firewalls are already managed by Digisoft, we will be autonomous in all of the deploy phases.

In case of installation on customer's machines there will not be the option to share dht servers so the vegaweb infrastructure can be deployed on 2 machines (except for very specific needs):

.