How does SOA go?

What is the path to SOA?

As we all know, SOA is a service-oriented architecture and a method for building distributed system applications. It transmits application functions as services to end users or other services. It solves the problem of cross-platform enterprise. It is a technical solution for cross-platform enterprise systems. With SOA, the original three-tier structure has changed. Many people add a layer of service layer on the original business logic layer, or name the business logic layer the service layer, the purpose is to provide a service to the UI or other systems instead of a class library. This service can be used across platforms. This is a good starting point. Because of this, many people like SOA and begin the hard journey of SOA.

At the beginning of SOA, many people or companies will first think of the need to standardize the current company's development methods. Package methods originally used in the business logic layer into a service. As a result, this specification is added to the company's development standards. Try to use the WCF or Web Service Federation system Service to provide it to other users or the UI Layer. In this case, Every programmer starts to write services, and strives for the early implementation of the company's SOA architecture. To achieve this goal, the company began to work on some middleware (or ESB product) that conforms to the SOA Architecture concept two years ago ). However, up to now, these targets have been suspended. Of course, there are various reasons, such as: there are too few mature products that truly conform to the concept of SOA architecture, and there are too few people with practical experience on the concept of SOA architecture. No experience, so the company does not dare to blindly implement various risks. These are not questions I want to share today. I would like to share with you the following questions: Many people or companies have not made a full assessment before preparing to apply SOA and have made a full observation of the problems encountered in previous development.

In the past, when I did not consider SOA, it was easy to write services. I thought it was nothing more than package the methods of the previously written business logic layer. Recently, when I was doing a program analysis and architecture design, I didn't think much about this system because it involves many associated systems. I just wrote the service in the original method. But later, when I was about to complete the system design. I found that many server features have been designed repeatedly, and some of them have not been split, but should not be split. This has also led to the use of service calling services in many places, and may be nested with several layers. In particular, some functions of external services need to be called. Many people may also say that there is no problem with doing so. Some people think that the smaller the service should be split, the better, so as to achieve the possibility of reuse. Some people think that this kind of nested service will cause serious system performance problems, and the practice does prove this.

This is the question of service granularity. How can we grasp the service granularity? How can transaction mechanisms be implemented between various services at the same time? Is distributed transactions really feasible. If yes, it is not recommended for so many people. Is there any other solution to solve the transaction problem? In response to these questions, what are the design suggestions? What should we prepare before implementing SOA? I hope you can discuss it together. Thank you!