10
In the chapter of Software Design (SWEBOK) when talking about architecture styles are cited client-server and three-tiers:
Various Authors have identified a number of major architectural Styles: Distributed systems (for example, client-server, three-tiers) [...]
I don’t really understand the difference between these architectural styles. Moreover, it seems that these styles are outside the scope of design software.
10
The client-server is a two-tier model where it usually has a software component that interacts with the user or operates something in the most visible front of a system, while the server is responsible for doing the more specific work elsewhere physically separate.
An easy example is what we find on the web where you have the browser acting as client and the HTTP server obviously acting as server, so one of them starts the whole action by requesting something from the server that knows what to do with that request and delivers the result for the client to operate as it sees fit, in case it renders an HTML page and things like that.
Another example that is often cited and that is still client-server, but the way they use it is a little 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 database is not part of its architecture so it even has a client and a server, but your system cannot be classified as such, the solution as a whole is up to a client server.
It is common for each of these two parts to be on separate machines on the same network or on another, but nothing prevents it from being in the same, there are several such cases, only it is not usually so visible. In a certain way all the service consumption of the operating system is so always has its application as 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 only, but only the fact that the software is separated already indicates that it has a service being consumed by a customer.
It is less common for people to see this (which is not to say that it is uncommon to exist) but there are client-architecturesdifferent server, for example a window system where what you see is the client but the most internal processing is done by another component rather isolated 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 swap components, access remotely, interoperability), and in some cases more performance (despite a certain overhead that this generates), besides being able to simplify the functioning, at least in a certain point of view. In the context of the question the distribution becomes simple since it has a clear separation of each part.
The key point is that you have a requisitioner and a deliverer of results.
When you add a component in the middle to intermediate the process, in general called middleware you have the 3-layer architecture. This middleware can delegate to another layer certain tasks, coordinating this work. In general it increases the complexity and not always the gain is obvious, so it is less common to find this type of architecture. Nowadays one either makes the client-server pure or opts for something more decentralized accessing what would be a third layer directly by the client distributing even more work.
Some people consider that if you have a client, an application server and a database you have 3 layers, again I think an error, but informally it may be acceptable. So some people consider that a typical web system is so since it has the browser, the HTTP server and the database. At least it’s an easy way to understand.
These architectures should not be used to organize development.
Just be careful with 3 tiers and 3 layers, which in general we translate both to 3 layers.
The first is an architecture standard of the software components where it is made 3 deploys and so it is comparable with the client server and can be distributed within the context of the question.
The second is a code organization standard, 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 middleware (less common because this tends to be a "traffic guard" of the solution, so it is not a distribution pattern that is quoted in SWEBOK (its context makes the separation clearer). It’s not common to mention 3 tiers so if you research you will find more about 3 layers.
MVC is a known form of 3 layers in this sense. This is a case for organizing development.
Excerpts from SWEBOK 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 construc-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 were copied in full in the question perhaps this gives more context that are items of physical separation since 3 examples disaggregate more:
Distributed systems (for example, client-server, three-tiers, Broker)
For context the Broker is a form of middleware used in SOUNDS (Service-oriented Architecture), something that has been supplanted by microservices (for me both are mistaken in almost all scenarios)
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.
4
Based on the Presentation Domain Data Layer, Fowler, a 3-layer application consists of:
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 access to the bank.
Fowler considers and defends (in general) the use of this architecture for a simple question: scope of attention. The team in the presentation layer is not too concerned about what is happening in the business layer, so for them just 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 how it will be persisted/rescued, focusing 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 only need to know this from the resource/data layer.
The persistence layer team does not need to worry whether the calculations will be done in the right way, just know how to assemble the requested data or save it. The option to save to a temporarily embedded database, keep in memory, or even send to the perennial database is a concern of this layer.
Fowler himself, describing the behavior of a euquipe working in these 3 layers (free translation):
When I’m working on [layer of] presentation I can focus on UI behavior, treating any data to be shown or updated as magically appearing through function calls. By separating these elements I funnel the scope of my thinking into each piece, p that makes it easier for me to give continuity to what I need to do.
Even though there is occasionally some development cross-Section (cutting by multiple layers), incremental development becomes more natural. Imagine that you are making a sales application and, when you are doing the interface, you come across "puts, I forgot the ICMS-ST". Thus, the presentation layer leaves a little box ready to receive an arbitrary data with the value of this tax (which eventually modifies the value of buying but does not modify the sale). So, with that ready, he can worry about rescuing from the bank correctly the rates of this tax and its tariff value, to then, in the business layer, decide if the data are favorable to use rate or tariff and make the relevant calculations, delivering to the presentation layer a round die.
Note that this type of 3-layer architecture does not impose where this processing should take place. For example, where I work, we use GWT. We write in Java and in an XML dialect called ui.xml the presentation layer, and the GWT magically transforms it into Javascript and sends it to the client. The business layer is usually in a dependency part, which internally we call core of the system.
If you want to read more, I wrote an article on Medium which also deals with this
The kernel 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 leaving it viable for Android too, soon I will write an article on the subject
In addition to the core, where the validations of business rules occur, we also have a layer that we call DAO (or I-DAO, there is a pseudolayer M-DAO) by force of habit. This layer, implemented by the application that calls the nucleus, is concerned only with assembling the data to give them to the nucleus or saving the data coming from the nucleus. The only thing that matters to the kernel is that it can call through Java and that they are synchronous methods (choose this questionable, but there was not much support for asynchrony in Totalcross).
In the Totalcross implementation of this layer, it is basically written in Java with TCDBC (like JDBC, but Totalcross; too similar, but has some differences that require a lot of attention). In the Java Web implementation (irrelevant whether 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 an XML dialect and "text" in SQL within the tags. Sometimes it is preferable in this layer to turn the business object into another data transport that is easier to handle with Mybatis, as well as to recover transport objects to mount them properly after calling the database.
This separation allowed a much more optimized work of the team, especially in the GWT part. The GWT part was rewritten from scratch, totally abandoning the old GWT part in order to update technology (like Mybatis, which was previously iBatis) and removing the business rules from the presentation layer. Legacy GWT code still made a lot of business rule in the presentation layer.
In the Totalcross part, however, there was no full rewrite. In fact, from this part was extracted the nucleus in an experimental and exploratory way and we were gradually adapting some parts extracted to communicate with the nucleus, but punctually and with the whole load of a legacy giant code on the back. There is still a lot of business rule in the layers that should be concerned only with data presentation, especially on low customization screens and with low incidence of reported bugs.
Legacy code and the "disharmonious" 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 at the time, the TJ protocol.
The implementation of this protocol consists of a client and a server, but does not determine the function of each one. We have the case that both client and server are able to write and read in this protocol. Other cases where only writing happens, others where only reading happens.
When 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 much complacent, there is only the reading of what was presented and sends to the database 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 analyzed through the 3 layers, where there is only concern with presentation and rescue. The implementation of the receipt, in turn, has no data presentation, only the parse (maybe someone considers business layer? ) and persistence.
The architecture client-server is independent of 3-layer architecture. In the traditional client-server architecture, you have an application that is listening (the server) and another that eventually makes a request.
In this architecture, who indicates that 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) asks for a resource (a web page) for the server. When the communication ends, the two say goodbye and goodbye, only if there is another request from the client to send data.
But not all client-server communication needs to be like this, just the client pushing data. SSH is also client-server, in which case the command top, when typed from the client terminal, starts the executable top which is constantly updating the client with the resource consumption information of the machine on which the server is located. The 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 the applications that work with the TJ protocol. We have a client written in ADVPL to run in Erps Protheus able to present the data in TJ format, as well as read the information and decide how to persist them in Protheus. But our server was written client independent, accepting to be plugged by other Erps, testable via HTTP request.
I edited mine, take a look :)
0
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. Worth consulting https://en.wikipedia.org/wiki/Client%E2%80%93server_model.
On the other hand, when it comes to 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 "Aurélio da Engenharia de Software" (ISO/IEC/IEEE 24765:2017). This does not mean that they are not relevant, they serve for our communication.
Browser other questions tagged software-engineering software-architecture software-project
You are not signed in. Login or sign up in order to post.
I did not have prior access to SWEBOK, this may have caused the confusion well explained by you. I will study some more and revise my answer. And in the meantime read your updated answer =D
– Jefferson Quesado