Chen Zhihao chain: http://blog.9cbs.net/chzg99/admin/editposts.aspx
The result of a service is usually made to change the state of the consumer, but it can also be a change in the provider state, or both. For example, after you hear the music played by the CD player, the mood has been changed from "depression" to "happiness". If you want an example including the two states, then you are a good example in the restaurant, you spend money to enjoy the meal, and the restaurant serves service. We want some people to help us work because these people are experts. Consumption is more efficient than the usual cost than personality. Many people know that they will become experts, they will become experts, and the same reason can be applied to build software systems, we are called "Separation of Concerns", which is considered software engineering One principle. How can SOA get loose coupling in the software agent interaction? This is to use two architecture constraints: 1 For all participating software agents, there is a small set of simple and universally applicable interfaces. Only generic semantics are encoded in the interface. These interfaces should be widely available to all service providers and consumers. 2 Description Messages are restricted by the transmitted scalable scheme between interfaces. System behavior is not passed or only a minimal through message description. Scalable scheme limits the vocabulary and structure of the message. Scalable scheme allows new versions of services to be introduced without having to break the original service.
In the power plug example, it is important to see that the interface is important. If the interface does not work, the system cannot work. Interface connections are costly in distributed applications and is easy to have errors. An interface needs to describe system behavior, which is very difficult to get correctly through different platforms. Remote interfaces are also the slowest part in many distributed applications. Rehabilize some universal interfaces for all applications instead of establishing a new interface for each app, it makes sense. Since we have only some universal interfaces, you must indicate the semantics of the specified application in the message. On the interface, we can send any of the messages, but before the architecture is a service-oriented service, there are some rules that need to be observed. First, the message must be descriptive instead of guiding. Because the service provider is responsible for solving problems. Just like going to the restaurant, you tell the service to give birth to what you want to eat and your taste, but you don't tell how to make your dishes. Second, if your message is not written into format, structure, and vocabulary that can be understood by all parties, the service provider will not understand. Limitations of vocabulary and structures of messages, it is necessary for effective communication. The more messages are restricted, the easier it is to understand the message, although this is based on reducing scalability. Third, scalability is very important. It is not difficult to understand this. This world is constantly changing, so the environment in which a software system is constantly changing. These changes require a corresponding change in the software system, service consumers, service providers, and those they exchange. If the message is not scalable, the service consumer and service provider will be fixed on a service-specific version. Despite the importance of scalability, it is traditionally ignored, and most simple think is a good practice rather than the basic principle. The restrictions and scalability are firmly wrapped together, both you need, the growth will cost the other party. There should be a modest balanced strategy. Fourth, a SOA should have a mechanism that enables consumers to search for a service context to discover a service provider. This mechanism is flexible, there is no need to have a registry.
