A ramble on SOA (service-oriented architecture)

The idea of service-oriented architecture is nothing new in the architecture of the whole software. I simply think that the service is a modular extension, so the service has a similar and modular advantages and disadvantages. This is no longer a discussion of the communication protocols between services and services, such as WSDL, and so on, which I don't see as the essence of service. Even if the Java language uses RMI for communication between services and services, it still does not violate the purpose of service. Why do I need a service-oriented architecture

1. I think the fundamental benefits of service-oriented are easy to manage, but also the inevitable outcome of application to a certain time. This often coincides with the organizational structure. In fact, unreasonable service division will also bring about the confusion between services.
2. Service-oriented is a decoupling process, loosely coupled to reduce the dependency between services, but also means that service a service failure is not easy to cause chain reaction, but also better control the relationship between service and priority.
3. Communication between different languages. Two. The benefits of service-oriented architecture

The benefits are already being addressed in the service-oriented architecture. Here are some simple examples to illustrate. For example, an application is deployed on a machine, however, no matter how the optimization of a single computer can not prop up the entire application. There are two ways of thinking.
Horizontal expansion, that is, the entire application as a whole, and then horizontally extended to multiple machines.

Figure A

Service split, this is decoupled process, also conforms to the software engineering "high cohesion, low coupling" idea. Often the first step will be modular. This may not be enough and we need to allow them to survive on their own. Such a large service "split" into a relatively small can be independently generated services, the key here is to be able to survive independently, meaning that they can be deployed on different machines, to a certain extent, to achieve a "distributed" effect.

Figure B three. Summary

The above mentioned machine extensions from two dimensions. Both of these are present in the system split. The first scenario should be used in terms of pure performance. The second scenario is not considered an overall solution to performance. and mainly from the point of view of software management to split. This split makes the whole business more and more granular granularity, will be more and more control, to ensure the high cohesion of each service, there are clear boundaries.
Service-oriented architecture is an idea, of course, for large systems, the benefits will outweigh the disadvantages, and the system is relatively small when blind split and service will actually lead to the whole maintenance costs rise. The system architecture does not have the same level of routine, nor does it necessarily follow a pattern entirely. Everything in the practical application of the combination of specific application scenarios. It should be said to be the concrete product of "methodology".

Reproduced from: http://blog.csdn.net/luohuacanyue/article/details/12521699