On Jan 28, 2020, at 2:00 PM Ronnie wrote:
> I have an application running in a hospital environment for a number of years.
> In the light of the increasing awareness of data security, the client’s IT in
> their own words are looking at "redoing the whole 4dcis database onto 2 or 3
> tier system where there is a database separation from application layer”
>
> The current setup is a v15 client-server application, with about 80
> concurrent client licenses serving users located at 2 separate locations.
>
> As it stands, a 4D application already has a 2-layer architecture being a
> client-server application.
> We could perhaps enhance it a little to make it a 2-tier environment by
> moving the segregating the 4D Server software and the 4D structure files
> (business logic) on to one server and the 4D data files (database) on to a
> separate server. Doing that however has no effect on the 4D database
> architecture, it still remains a 2-layer database architecture.
>
> Apart from re-developing the application into a complete web-based
> application, how can a 4D application be refreshed into a 3-tier system?
>
> I would like to tap on the collective wisdom of the forum to gather some
> views on the plausibility of the above.
If a “3 tier system” a hard requirement, then introduce another 4D Client layer
running a web server. You create some kind of API — maybe a REST interface —
that would be accessed by running 4D Web Server — or NTK — on 4D Client. Then
you have end user 4D Clients connect to this new 4D Client web server.
The new 4D Client web server machines connects to 4D Server directly and act as
a relay between the 4D Client at the user end. You would run 2 4D Server
instances. Probably on different machines. One stores the data and it what the
4D Client web server machines connect to.
Your end user 4D Clients connect to another 4D Server and this is purely an
application server. It just serves the 4D structure to 4D Clients. The database
would be empty.
Looks something like this:
4D Client End User —> 4D Client Web Server —> 4D Server with data
|
|---------------------------------------------------> 4D Server
with no data (serving the application layer)
That’s a complex system. You’ve got too good of a system. Too easy. You need to
add more layers and complexity. But maybe that is what IT wants. More layers
because they think that means more places to add more control and more security
protections.
You could also make the case that your new API web server interface — that will
be running on 4D Client — could be used by a newly created web app running in
the browser. The web app would connect to 4D Client web server using the same
API that the 4D Client end user machines use. That way, if IT really has the
idea they want to move to a pure web app front end, you could provide this with
your 4D backend. And your 4D backend is a 2 tier system — 4D Client -> 4D
Server.
Setting up a system like this would allow end users to continue to use 4D
Client and keep the same UI they are used to. Once you have your REST API
working, you switch out all SAVE RECORD and QUERY and database access commands
that 4D Client now uses to use your new REST API.
Get that all working and then you can provide that API to the web app
developers. They build a web app using the same calls that 4D Client is using.
The 4D Client web server does not know or care if requests are coming from a 4D
Client doing an HTTP Request or from a web browser.
Tim
*****************************************
Tim Nevels
Innovative Solutions
785-749-3444
[email protected]
*****************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
