 Хай! Наймемо здається дуже важливий і великий тапик. Я говорив про сервисоріотичну архітекту та спеціальний кейс «Майкросервіс». Він є модернів, що виймають, щоб створювати багато сфотографів сьогодні. Сервисоріотична архітектура вимагає експлукційну функціональність, щоб бути дівчинені як сервиси та рікація вимагання, що вимагають випадку сфотографів. Сервиси будуть ласкові, бо ми вимагаємо стандартні випадки, які можуть бути вимагані, публішені та вимагані. Сервисоріотичні архітекту вимагають експлукціональність та спеціальний кейс «Майкросервіс». Вимагаємо інтерфейси, які випадки вимагають експлукціональність. Сервисоріотична архітектура вимагає бути дівчинені як продельник, кілька – ідентих, координатори, транспорти і технологів. Тобто вимагає бути відводені як такий. Сервисоріотичник aslında міг вимагуються сервиси у сервису-карміна. The service consumer searches the service registry directory and discovers needed services. Now the service consumer is able to invoke specific services and acquire the results. On the other hand, we can make a shortcut if we know the service provider API or we develop that API ourselves. In that case, we just invoke services. There are two major approaches for organizing service-oriented architecture implementation. We can use SOAP or REST web services. SOAP, an acronym for Simple Object Access Protocol, is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. It uses XML information set for its message format and relies on application layer protocols, most often HTTP. Let's take a closer look at the example of the SOAP interface description. What you see here is the XML file that describes provided services or functions that could be invoked. In this example, we see that there is a function called addInteger. In order to invoke it, the application needs to provide two integers of a long type. Naturally, there are integers that will be added. And the result is also an integer of a long type. Of course, there are other types and even complex ones. Take a look at FindPerson function. It takes a string and returns the complex structure of the type person. The development environments understand this format and you can import that file using a link. Easy, isn't it? REST, an acronym for Representational State Transfer, is more of a software-architectural style that was created to guide the design and development of the architecture for the World Wide Web. REST defines a set of code strains and any web service that obeys the REST code strains is informally described as RESTful. REST is a lightweight approach that uses simple formats such as JSON to exchange information. Remember, we presented a layered architecture and gave the web application an example. Now, let's investigate it from the service-oriented architecture point of view. Let's go to the presentation layer. Here we see that the application frontend invokes the API function called getUser. It uses the get method and provides a parameter in the URL. Now let's go to the server-side code. Here we see the so-called endpoint that is defined by the root. If URL contains getUserString followed by the parameter, then this function is executed. It returns a status code of 200 and the JSON-encoded information about the user. Let's review the key principles of a service-oriented architecture approach. Services are automomers. Each service is maintained, developed, deployed, and versioned independently. Services are distributable. Services can be located anywhere on a network, locally or remotely, as long as the network supports the required communication protocols. Services are loosely coupled. Each service is independent of others and can be replaced or updated without breaking application that uses it as long as the interface is still compatible. Services share schema and contract and not the class. Services share contracts and schemas when they communicate, not internal classes. Compatibility is based on policy. Policy in this case means the definition of features such as transport, protocol, and security. And here I listed the main benefits. The main alignment. The use of common services with standard interfaces business and technology opportunities and reduces costs. Abstraction. Services are automomers and accessed through a formal contract, which provides loosely coupling and abstraction. Discoverability. Services can expose descriptions that allow other applications and services to locate them and automatically determine the interface. Interoperability. Because the protocols and data formats are based on industry standards, the provider and consumer of the service can be built and deployed on different platforms. Rationalization. Services can be granular in order to provide specific functionality, rather than duplicating the functionality in a number of applications which removes duplication. Now let's investigate the special case of service-oriented architecture, microservices in the next video. See you.