Chen Zhiwu chain chzg99@21cn.com
"Things should be as simple as possible, but it can't be too simple" - Einstein
introduction
The famous saying of Einstein many years, today is still suitable for building high quality software systems. Unfortunately, anyone who has experienced experience in IT industry will point out that there are many software systems to violate this famous saying in Einstein. Among them, some software systems are too simple to complete the desired tasks, or it is too complicated, making the construction and maintenance costs rapid growth, and do not say to integrate different software systems. To reach a suitable simpleness, it looks like a dream. What is wrong?
Loosely coupled coupling
We don't have to go to the deep mind to think about the problem. The more similar situations and patterns will be seen when we build software systems. It is natural that we think of multiplexing the functionality of the deposited system, not everything from the head. Realistic dependence is a state of an event that is manifested in a system that relies on the functions provided by other systems. If there is only real-reliance in the world, then Einstein's test has passed. The problem is that we have established some people dependence, which coexist with reality. If you go abroad, you know that you have to bring your power adapter, otherwise you will encounter trouble. You need a power supply to be realistic, and your plug must match the local power outlet, this is human dependence. Different countries have a plug in different sizes and shapes, they are somewhat small and compact, some big and cumbersome. The experience here is that we can't remove people-dependent, but we can reduce it. If the person in the system is reduced, it is ideally minimized, and we get loosely coupled. In a sense, Einstein said is loose coupling. I can change the name of Einstein as: "Artificial dependence should be minimized, but reality should not be changed."
SOA definition and explanation
You can now define the service-oriented architecture. SOA is an architecture that is a loosely coupled in the interaction of software agents. A service is a work unit for a service provider to get the final result of the service consumers. Servers and consumers represent their own roles in software agents. This sounds too abstract, but SOA is indeed nothing. Let us find an example of a SOA in your housing. For example, playing a CD, you can put the CD to be played into the CD machine, the CD machine will play this CD for you, and the CD is provided with a CD playback service. The advantage here is that you can play the same CD with a different CD machine. They can provide the same CD playback service, but the quality of service is different. SOA's idea is significantly different from object-oriented programming, and the object-oriented programming. It should be binded to it. So in the object-oriented programming style, each CD has its own CD player, and they cannot be disassembled. This sounds strange, but this is how we have set up many software systems.
