Implementation points of SOA concepts misunderstanding

Key Points of SOA implementation:

1. Order of SOA construction. Is it from top to bottom or from bottom to top? I personally tend to grasp the overall situation, because what is important in SOA is not technology, but business positioning. If you design services from the bottom up, you may do a lot of repetitive work, or rework when you actually use them. Sufficient demand research should be carried out during the design to find out the core of the business and provide it externally. However, there will certainly be a lot of things that are not taken into account during the design, or the thinking is too rough, so you can further discuss the services that need to be made public during development, add the part with finer granularity. That is to say, first grasp the overall situation from top to bottom, and then grasp the details from bottom to top.

2. SOA testing process. As a client program, you need to create an interface-based fake service for testing when the required service has not yet been created. After the service is deployed on the network endpoint, use the service proxy to replace it (of course, the ideal way is to automatically generate the fake service and test data by the client proxy ). As the service owner, you must strictly test the service boundary, logic, and performance before the service is released. As a server, I don't know what my customers are, I want to handle all possible situations.

3. Continuous SOA Construction. Although the contract remains unchanged, it does not mean that the service remains unchanged. The service logic needs to be improved constantly. Services can also be expanded. Nothing is perfect at the beginning. if the service is not continuously built as a guarantee, it may take a lot of time to make the service that few people are willing to use, as a result, the entire service layer is increasingly isolated from SOA, leading to the failure of SOA implementation. We should not be afraid of poor service performance. if the service is not consumed by customers, it will be dangerous.

4. Basic Structure of SOA. No matter what it is called ESB or other terms, the infrastructure is always needed and should be built before implementation. Some of them are very important. The first is to ensure the reliability of services, such as how to perform load balancing of services, how to do transactions, how to control service traffic, and how to implement message encryption and security. Second, service monitoring and management, such as service call exception records, system status, system configuration, and system deployment. The third is service mediation, such as service routing, asynchronous queue, and message conversion. The fourth is the service management platform, such as process management, contract management, and deployment management. Technically speaking, this infrastructure should be as transparent as possible to developers, and it also requires a small amount of human participation to be implemented using code generation tools, AOP, and management tools. This framework is required in the early stage of SOA development and is also the most technically difficult. After the completion of the training, technical training and Process training for developers.

 

SOAConcept misunderstanding:

1. SOA is not a technology (or web service, of course), a product, a new concept, or a dust. SOA is so a, that is, an architecture that conforms to the service-oriented idea (a Web Service may need to be involved as a technology, but it cannot be said to be a Web Service ). The success of SOA requires the support of a set of products, but it is not a product. Why is SOA not a new concept? We need to use various services in our lives. We only need to write some tables (Contracts) as required, and the other party will give us results. This is not what SOA is, in computer hardware, SOA is also the idea in many places (in fact, I have always thought that software engineering is behind hardware engineering, and many development ideas can be found in hardware design ). On the day when SOA is not implemented, it must be constantly changing and improving.

2. SOA can be big, small, internal, or between enterprises. It can be homogeneous or heterogeneous platforms. Therefore, it is difficult to apply SOA, no company implements SOA exactly. SOA may be very simple or complicated. complexity is not to say that it is technically complicated. It is often due to management complexity. Because the business is integrated, the business will change. The complexity is also reflected in the implementation based on the old system and the data compatibility and dataset issues need to be taken into account.

3. SOA is not necessarily a layer. There is no rule that the service consumer must be a client. The service consumer can be a service, that is, a combination of services. Multi-layer services can be further reused.