I think two real-world examples can make you understand a little bit better why this is relevant. As a matter of fact, when I read your question I got interested and went to research and saw that I’ve been working with it for some time and I didn’t even notice. As I had never really heard of SOA I wrote this answer more to try to help with some things that I have noticed in my work and that I think are related. I ask those who really know the subject to correct me if I say any nonsense there. Come on:
1. Single Page Applications (SPA’s)
Nowadays there are several single-page applications out there. The classic example is gmail. These applications are marked by the fact that they have a web-based interface that is extremely interactive and doesn’t need to reload the page, that is, a large part of the application is loaded in the first execution and the subsequent executions serve to receive necessary resources at certain times.
I will not discuss the advantages and disadvantages of SPA’s, but basically to make a quality SPA you implement two totally separate things: a graphical interface written with HTML/CSS/Javascript and a web service. The web service consistently exposes all methods to perform the manipulations on the domain your application needs.
2. WPF applications using MVVM
When you develop an application for windows desktop using WPF it is common to want to approach this with the MVVM standard. A common way then to encapsulate the logic for accessing data in these applications is to use a service. When I worked with this I remember that I saw some tutorials and books and were used at the time of WCF services. The reasons are practically the same as the SPA’s.
Perks
With this kind of approach you get some things
Separation of concepts well done: the interface knows the interface, the server knows the domain. Interface changes do not affect the domain, and domain changes usually do not require major interface changes.
The same service can be used for multiple interfaces. If you need to use the same data in a second interface (on a website for example, or on a mobile app), you can request the same service. Again, changing something on the server does not require changing multiple places.
So, in addition to you having the ability to share features in several different environments (they just need to know how to communicate via HTTP in the case of web services), you can allow the responsibilities of different components that make up your system to be well defined, so that you can have ease of maintenance.
Suppose you develop your object-oriented service and you can actually build it with low coupling and high cohesion using the principles of object orientation and everything. If you need to change the logic of data access, it will change in one place, on the server and all client applications without any kind of change in your code will benefit from this.
If you change the way a domain type is implemented, the same thing happens. In general you can with this reuse a lot of code, allow a much bigger portability and have a great flexibility when creating your graphical interface.
In the case of web services, imagine that api.meuservidor.com/clientes/ is a URL that points to a resource capable of returning a customer list. When building the interface this is all you need to know to render a customer list. How customers are implemented, how they are stored, or etc., is not necessary to know. If you work in a team and there is a programmer responsible for the graphical interface, it will make his life much easier.
In short, implementing the real functionalities of your application that deal with domain types and so on in a service layer allows you to reduce coupling, increase code reuse and facilitate the maintenance of your application. Thus, SOA is a methodology, as you said yourself, a style of architecture, which instructs you to have in your software a layer of services to be able to have all these advantages among others.
References
Service-Oriented Architecture - Wikipedia US
Service-Oriented Architecture (SOA) Definition
I think it’s an excellent time to update the SOA tag Wiki.
– Leonel Sanches da Silva
Hello Geison, how are you? Man, to be very honest I find it difficult to answer a question so wide in the format of Stack Overflow. That question (closed) of Soen has good attempts, but the truth is that the scope of the question is too broad to answer without making generalizations somewhat coarse.
– Anthony Accioly
Hello, @Anthonyaccioly. I believe that as difficult as it is to define a term, depending on its level of abstraction or complexity, it has a definition or several and therefore is feasible to be conceptualized.
– Geison Santos
"I read some definitions on the web", Please state what they are and why you were not allowed to reach such a level. Nothing more boring than someone giving an answer and having to listen, "oh, no, I already know...". The cool thing is you put all your information on the table, so there’s no misunderstanding.
– brasofilo