"WCF Technology Insider" translation 13:1th Part _ 2nd Chapter _ Service Oriented: Why so meaningful and this chapter summary

Why so makes sense

Developers and architects often ask me, "Why do we need service-oriented?" "My answer is simple: scalability, maintainability, interoperability, and flexibility." In the past, distributed component technology was like COM tightly binding all the components together. At the very least, these distributed technologies must share common type systems and are often a run-time. With these dependencies, upgrades and software upgrades become complex, time-consuming, and laborious. Service-oriented application systems, on the contrary, do not require the same type of dependency, thus demonstrating the behavior that is more appropriate to the enterprise's actuarial needs.

Version upgrade

The requirements of the application system will change over time. This problem exists only when the computer appears, and there is no indication that it will slow down in the future. Developers, architects, and project managers have done a great deal to get to the software development process and want to be able to adjust and control the number and steps of application system changes. In the declaration cycle of the entire application system, some of the ideas in the development process will prove futile. In some cases, the final integration of the application system will result in a series of cascade other application system changes. Autonomous, well-defined, contractual service-oriented applications provide several layers of encapsulation to cushion the impact of partial version upgrades of these systems. In a service-oriented application system, the only agreement between the sender and receiver of the message is the contract. Both can be free to change their implementation according to their own expectations, as long as the contract remains unchanged. The same applies to the component architecture, the universal nature of the service contract decoupling the sender and receiver from the implementation, thus making the version upgrade cycle shorter. Service-oriented does not remove the need for a good versioning upgrade process.

Load Balancing

Each application has some bottlenecks, and the advantages of these bottlenecks may prevent an application from expanding to increase throughput requirements.

Figure 2-4: A traditional component-oriented application

In this scenario, data retrieval may be a performance bottleneck. If this is the case, a way to extend a component-driven Web site is shown in Figure 2-5.

Figure 2-5: Scaling a component application