Coulouris defined distributed systems as “systems in which hardware and/or software components existing in a computer network communicate and coordinate their actions by exchanging messages”.
This concept has become popular in recent years due to several factors. The first factor that promoted the development of distributed systems was the emergence of high-speed local area networks. Another important factor was the technological advance in the performance of personal computers and the development of software to support distributed applications. Distributed systems are linked to the concept of the Web and the Internet. With the evolution of the Web, and the appearance of new areas, interactions, needs and applications, the concept of Web 2.0 appears. This term was coined by Tim O'Reilly in 2004 to refer to a second generation in the history of the Web based on user communities and a special range of services, such as social networks, blogs, wikis or folksonomies, that encourage collaboration and quick exchange of information between users.
The first architectures that can be considered service-oriented (SOA) were based on CORBA (Common Object Request Broker Architecture), which acted as an abstraction layer to interconnect the different elements of the architecture and build services. Other earlier technologies were DCOM (Distributed Component Object Model) or RPC (Remote Procedure Protocol). With the need to efficiently design and implement distributed systems on the Web, several challenges arise, some focused on the development itself (performance, user experience, etc.) and other complementary ones, based on the reusability and compatibility of services. From these needs arise Web Services, which provide standardized mechanisms to interconnect different users with information servers.
SERVICE-ORIENTED ARCHITECTURES
According to SOA (Service Oriented Architecture) are software architectures that define the use of services to support business requirements, whose objective is to achieve the least possible coupling between software agents. A service is a unit of work performed by a service provider to achieve an end result desired by a service consumer. Both service provider and service consumer are roles played by software agents, not software owners. In a general sense, a service-oriented architecture is a software solution intended to enable an enterprise to organize and make use of various processes. With SOA, software applications are no longer massive blocks of functions and processes. Instead, these applications are made up of assembled modular services. Remember that a service is a simple software function (like canceling a CD). It can be run on demand by any system, regardless of operating system, platform, programming language or geographic location.
What is revolutionary about SOA is not the concept itself, which has been around for a long time, but the fact that it can be implemented over the WWW (World Wide Web). In the same way that web pages load on any platform, web services work similarly regardless of platform as they are built using
universal standards.
The idea of SOA stems directly from object-oriented programming, which suggests a relationship between data and its processing. Thus, they formally define services through interfaces that are independent of the underlying platform and programming language. These interfaces hide the peculiarities of their implementation, which makes them independent of the developer and programming language. Through these architectures, it is possible to design and implement highly scalable systems that reflect the business logic and at the same time facilitate the interaction between different proprietary or third-party systems. The reason we want someone else to do the work for us is because they are experts. Using a service is usually cheaper and more effective than doing it yourself. So most of us understand that we can't be experts at everything. The same rule can be applied to building software systems.
Interfaces are very important, if they are not well defined or do not work, the system does not work. Integrating more interfaces is expensive and also increases the potential for errors in distributed applications. Remote interfaces are the slowest part of most distributed applications. With all this, instead of building new interfaces for each application, it makes more sense to reuse generic interfaces for all applications.
So, since we only have a few generic interfaces available, we must include application-specific semantics in the messages. We can send any kind of message through our interfaces, but there are some rules to be followed to say that an architecture is service-oriented.
– Firstly, the messages must be descriptive, not instructive, as the service provider is responsible for solving the problem. For example, it would be similar to the situation of going to a restaurant and telling the waiter what you would like to drink and your preferences, but we shouldn't explain to the cook how to prepare your dishes, step by step.
‐ Second, service providers will not be able to understand your request if their messages are not written in a format, structure and vocabulary understandable by all involved. Thus, limiting the vocabulary and structure of messages is a
necessary for effective communication. The narrower the message, the easier to understand.
- Thirdly, the possibility of extensions is of vital importance. The world is an ever-changing place, and so is the environment in which software lives. These changes require corresponding changes in system software, consumers of services, providers and the messages they exchange. If messages are not extensible, consumers and providers are locked to a specific version of the service. Constraint and extensibility are deeply related, you need both, and increasing one means reducing the other. The ideal is to achieve a correct balance.
– Fourth, an SOA must have a mechanism that allows the consumer to discover a service provider in the context of a service sought by the consumer. The mechanism should be flexible and not a centralized registry.
- Fifth, Stateless service: Each message that a consumer sends to a provider must contain all the information necessary for the provider to process it. This restriction makes a service provider more scalable, as the provider does not need to store state information between requests. This can be called a “mass production service” as each request can be handled generically. This restriction also provides more visibility, as any monitoring software can independently inspect a request and extract its intent. This also allows for easy recovery from partial failures as there are no intermediate states, making the service more reliable.
- Sixth, idempotent requests (making no changes): duplicate requests received by a software agent have the same effect as a single request. This requirement allows providers and consumers to increase the overall reliability of the service, simply repeating the request if there was any failure.
So we can say that SOA is not a tool, but a set of standards for building new applications, more dynamic and less dependent. SOA facilitates access to business logic and information across multiple services in a systematic way, and can also orchestrate multiple remote services to compose a single one. most of the definitions identify the use of Web Services, which we will see in the next chapter, in the implementation of a service-oriented architecture. However, it can be implemented using any other service-based technology.