Client/Server Model
This section helps show the flow of what happens as an outside client makes a web call or page request. The diagram shows clients (laptops, desktops, tablets, phones) connecting or requesting something from a normal web server through HTML (hyper text markup language). If the web server can handle it, the web server returns the request. This is called static HTML or a basic web site.

If the normal web server does not know what to do, for example a ColdFusion page request, the web server hands it (the request) off to the ColdFusion server. Basically it is a please help me, I don't know what to do with this... The ColdFusion server than plays with all of its options and assets and returns the results in normal web language (html). The ColdFusion server is kinda like the brains of the process. It is very flexible and can deal with variables, conditional logic (if statements), loops, multiple sets of data coming from different sources, and even database and API connections. Very powerful.

If the ColdFusion server needs database information or records, it uses an internal API (application programming interface) to get the data back to the ColdFusion server. This is the wall outlet looking piece of the diagram. ColdFusion (the brain) then talks to the database through a language called SQL or structured query language (database talk). The database responds and sends the information back to the internal API and then back to ColdFusion. The trip between ColdFusion, the internal API, and the database all happen very fast and possibly multiple times per page request. Think of those three pieces (ColdFusion, internal API, and the database) as the three musketeers. They work very well together. Most of the work in the system is done by bouncing between those three players.

By the time everything is done, ColdFusion converts the values into normal web or HTML and sends it back to the normal web server that sends it back to the client. All of these connections are done in super fast, lighting quick phases so that it appears that only a single page was requested, processed, and returned. In reality, there are multiple different servers working in combination, each doing their own job, to make the whole. If you take any part of it out, the process would fail.

Another fun part of the model deals with how an external API socket connection might take place. We, at Adilas, allow access to backend database pieces based on settings and permissions set inside of the main secured environment. The external API is represented by the surge protector type piece that has sockets, data ports, and plug-ins. This section takes a standard piece or request and sends it to the internal API (wall socket in our diagram). The connection is made in a non native format like JSON (java script object notation) or XML (extensible markup language). This allows various 3rd party players or 3rd party solution providers to play with functions, data, and pieces of the Adilas.biz business platform. Basically, they (the 3rd party players) are able to code in their native environments (other programming languages) and then request, pass, or pull data from our servers (logic and databases) using external API socket connections. See this help file for more information about the Adilas.biz API.

« Back . [contact Adilas support - email form]