What is the difference between client-server and three-tiers?
In the Software design Chapter (SWEBOK ) when talking about architecture styles are mentioned client-server and three-tiers:
Various authors have identified a number of major architectural styles : distributed systems (for example, client-server, three-thirds ) [...]
I don't quite understand the difference between these architectural styles. Also, it seems that these styles are outside the scope of software design .
3 answers
Client-Server
The client-server is a two-tier model where it usually has a software component that interacts with the user or operates something on the more visible front of a system, while the server is responsible for doing the more specific work on another physically separate part.
An easy example is what we find on the web where you have the browser acting as a client and the HTTP server obviously acting as a server, so one of them starts the whole action requesting something to the server that knows what to do with that request and delivers the result for the client to operate as they see fit, in which case it renders an HTML page and things like that.
Another example that is very cited and that does not cease to be client-server, but the way they use it is a bit mistaken is the desktop application that accesses another service that is a database, so the first is the client and the DB would be the server. I think this is a mistake because the Bank of data is not part of your architecture so you even have a client and a server, but your system cannot be classified so, the solution as a whole is even a client-server.
It is common for each of these two parts to be on separate machines in the same network or in another, but nothing prevents it from being in the same, it has several cases like this, it just does not usually be so visible. In a certain way every consumption of services fromoperating system is so always has its application as a client and the operating system is the server. It is important to note this because the invisibility of the hardware gives the impression of being one thing, but only the fact that the software is separate already indicates that it has a service being consumed by a customer.
It's less common for people to see this (which doesn't mean it's unusual to exist) but there are different client-server architectures, for example a window system where what you see is the client but the more internal processing is made by another rather isolated component that is the server, this is interesting because it gives the advantages mentioned below, the X-Window is an example.
This tip ode architecture can give more security, scalability, flexibility (can exchange components, remote access, interoperability), and in some cases more performance (despite a certain overhead that this generates), besides being able to simplify the operation, at least in a certain point of view. IN question context the distribution becomes simple since it has a clear separation of each part.
The key point is that you have a requester and a result deliverer.
3 layers
When you add a component in the middle to Intermediate the process, usually called middleware you have the 3-layer architecture. This middleware can delegate certain tasks to another layer by coordinating that job. In general increases the complexity and not always the gain is obvious, so it is less common to find this type of architecture. Nowadays either you make the client-server pure or you opt for something more decentralized accessing what would be a third layer directly by the client distributing the work even more.
Some people consider that if you have a client, an application server and a database you have 3 layers, again I find it an error, but informally it may be acceptable. Then some people consider that a typical web system is like this since it has the browser, the HTTP server and the database. At least it's a simple way to understand.
Confusion
These architectures should not be used to organize development.
Only take care of 3 tiers and 3 layers, which we generally translate both to 3 layers.
The first is an architecture pattern of the software components where 3 is made deploys separately and so it is comparable to the client-server and can be deployed, within the context of the question.
The second is a code organization pattern, it is something more internal and does not need to generate different software components. It is common to have the 3 only on the server, or only on the client or even only on the middleware (less common because this tends to be a" transit guard " of the solution, so it is not a distribution pattern that is quoted in SWEBOK (the context of it makes the separation clearer). It is not common to talk about 3 tiers so if you search you will find more about 3 layers.
MVC is a known 3-layer form in this sense. This is a case for organizing development.
SWEBOK snippets that give more context:
A distributed system is a collection of physically separate, possibly heterogeneous computer systems that are networked to provide the users with access to the various resources that the system maintains. Construction of distributed software is distinguished from traditional software construction-tion by issues such as parallelism, communication, and fault tolerance. Distributed programming typically falls into one of several basic architectural categories: client-server, 3-tier architecture, n-tier architecture, distributed objects, loose coupling, or tight coupling algorithm selection - influences an execution speed and size.
If the excerpt was copied completely in the question, it might give more context that they are physical separation items since 3 examples disambiguate more:
Distributed systems (for example, client-server, three-thirds, broker)
For context the broker is a form of middleware used in SOA (Service-oriented architecture), something that has been supplanted by microservices (for me both are mistaken in almost all scenarios)
Middleware
Middleware is a broad classification for software that provides services above the operating system layer yet below the application program layer. Middleware can provide runtime containers for software components to provide message passing, persistence, and a transparent location across a network. Middleware can be viewed as a connector between the components that use the middleware. Modern message-oriented middle-ware usually provides an Enterprise Service Bus (ESB), which supports service-oriented interac-tion and communication between multiple software applications.
Source .
3 Layers
Based on Fowler's Presentation Domain Data Layer , a 3-layer application consists of:
- presentation
- business
- access to resources / data
With this architecture, it focuses on the information to be rendered / presented, the information to be operated and the information to be saved/rescued.
Note that the database is not part of this architecture, but rather the bank access layer .
Fowler considers and advocates (generally speaking) the use of this architecture for a simple matter: scope of attention. The team that is in the presentation layer is not very concerned about what is happening in the business layer, so for them it is enough to know how to display the data provided through a previously determined API.
The business team will not need to worry about how the information will be displayed, nor nor how it will be persisted/redeemed, focusing your attention merely on manipulating the information correctly and giving the correct result. People on this team need to have a known API to request resources or to have them persist, and they only need to know this from the resource/data layer.
The Persistence Layer team doesn't have to worry about whether the calculations will be done the right way, just knowing how to assemble the requested data or save it. The option to save to a temporary embedded bank, keep in memory, or even send to the perennial database is a concern of this layer.
By Fowler himself, describing the behavior of a team working on these 3 layers:
When I'm working on the [presentation layer] I can focus on UI behavior, treating any data to be shown or updated as magically appearing through calls functions. By separating these elements I narrow the scope of my thinking in each piece, p which makes it easier for me to continue in what I need to do.
Even though there is occasionally some cross-section development (which cuts through multiple layers), incremental development becomes more natural. Imagine that you are making a sales app and when you are making the interface you are faced with "puts, I forgot ICMS-ST". Thus, the layer of presentation leaves a small box ready to receive an arbitrary data with the value of this tax (which eventually modifies the value of purchase of the goods, but does not modify the value of sale). So, with this ready, he can worry about rescuing from the bank correctly the rates of this tax and its value of staff, so then, in the business layer, decide if the data is favorable to use rate or staff and make the relevant calculations, delivering to the layer of presentation a round die.
Note that this type of 3-layer architecture does not impose where this processing should occur. For example, where I work, we use GWT. We write in Java and in a dialect of XML called ui.xml the presentation layer, and GWT magically turns this into JavaScript and sends it to the client. The business layer is normally in a dependency on the part, which we internally call the core of the system.
If you want to read more, I wrote an article in Medium that deals with this too
The core is all written in Java and made to run as Java Web, compatible (in the strictly necessary part) with GWT serialization and compatible with TotalCross.
We are making it workable for Android too, I will soon write an article on the subject
In addition to the kernel, where the validations of business, we also have a layer that we call DAO (or I-DAO, there being a pseudo-Layer M-DAO) by virtue of habit. This layer, implemented by the application that calls the kernel, is concerned only with assembling the data to give it to the kernel or saving the data coming from the kernel. The only thing that matters to the kernel is that it manages to call through Java and that they are synchronous methods (pick this questionable, but there wasn't much support for asynchrony in the TotalCross).
In the TotalCross implementation of this layer, it is basically written in Java with TCDBC (like JDBC, but from TotalCross; too similar, but has some differences that require a lot of attention). Already in the Java Web implementation (irrelevant to be GWT or not), we have to DAO written in Java chews the data to call MyBatis optimally, without the queries written in the MyBatis way of being that mixes a dialect of XML and" text " in SQL within the tags. In some sometimes it is preferable in this layer to transform the business object into another data transport object that is easier to manipulate with MyBatis, as well as retrieve transport objects to assemble them correctly after calling the bank.
This separation allowed a much more optimized work of the team, especially in the GWT part. The GWT part was rewritten from scratch, completely abandoning the old GWT part to be able to update technology (such as mybatis, which was formerly iBatis) and removing business rules from the presentation layer. Legacy code in GWT still made a lot of business rule in the presentation layer.
In the TotalCross part, however, there was no total rewrite. In fact, from this part the core was extracted in an experimental and exploratory way and we were gradually adapting some extracted parts to communicate with the core, but punctually and with all the load of a giant legacy code on the back. There is still a lot of business rule in the layers that should only worry about data presentation, especially in screens with little customization and low incidence of reported bugs.
Legacy code and the "disharmonic" part of the city.
We have another" application " at work that, in fact, there is no business rule. It is only the implementation of a communication protocol designed to meet the limitations provided by TotalCross né Epoca, the TJ.
The implementation of this protocol consists of a client and a server, but does not determine the role of each. We have the case that both client and server are able to write and read in this protocol. Other cases in which only writing happens, others in which only reading happens.
In sending data, the application is composed only of a thin layer of access to the bank to retrieve the information to be sent and a presenter, which will envelop the ResultSet in a JSON. In receiving data, which by the TJ protocol needs to be very compliant, there is only the reading of what was presented and sends to the database the upsert or delete of the corresponding line, therefore there is the need to implement a thin layer of introspection of the tables and a layer of Assembly of the upsert.
Thus, these "applications" that implement TJ sending can be parsed through the 3 layers, where there is only concern with presentation and rescue. The receipt implementation, in turn, has no data presentation, only the parse (maybe someone considers business layer?) and persistence.
Client-server
The architecture client-server is independent of the 3-layer architecture. In the traditional client-server architecture, you have one application that is listening (the server) and another that eventually does one request.
In this architecture, the one who indicates that he wants communication is the client. A server is only able to send some data to the client when it is connected.
The HTTP 1.0 model is an example of client-server architecture, where the client (usually the browser) requests a resource (a web page) for the server. When the communication ends, the two say goodbye and bye, only if there is another request from the client to be able to send data.
Mas not all client-server communication needs to be like this, just the client pushing data. SSH is also Client-Server, and in this case the command top, when typed from the client terminal, starts the executable top that is constantly updating the client with the resource consumption information of the machine where the server is. watch also causes the server to send data without having to be explicitly bothered by the client.
In my work, we turn more strongly the client-server architecture precisely in applications that work with the TJ protocol. We have a client written in ADVPL to run in Protheus ERPs capable of presenting the data in TJ format, as well as reading the information and deciding how to persist it in Protheus. But our server was written independent of the client , accepting to be plugged in by other ERPs, testable via HTTP request.
Client / Server is a "model" where there are those who play the role of client and there are those who play the role of server in a given relationship. And these roles can vary depending on the relationship. For example, the server (who offers a particular service), can also play the role of client in another relationship, possibly to meet the request of its clients. It is worth consulting https://en.wikipedia.org/wiki/Client%E2%80%93server_model .
By on the other hand, when we talk about tiers, in general, we are talking about distinct physical elements, where each of them performs a set of processes. Again, the wikipedia may provide some guidance.
It should be noted that these names are not "essential" elements of a problem or solution. Interestingly, they are not even part of the" Aurelio of Software Engineering " (ISO/IEC/IEEE 24765:2017). This does not mean that they are not relevant, they serve our communication.