"WCF Technology Insider" translation 11:1th Part _ 2nd Chapter _ Service-oriented: 4 Principles for service

Service-oriented 4 principles

So far, we've seen the service-oriented concept, looked at the service-oriented message structure, examined the message address requirements, and discussed the industrial standards for message addresses. If you understand the motives of the standard address structure in the so message, it is not difficult to understand the service-oriented principle. Each service-oriented design follows the following 4 yards (often referred to as the 4 principle).

Clear boundary

In service-oriented, services can interact with each other's services through messages. In other words, services can send messages across boundaries to other services. The service can send and receive messages, and the message shapes that can be sent and accepted define the bounds of the service. These boundaries are well defined, clearly represented, and are the only service feature access points. More realistically, if service 1 is to interact with service 2, service 1 must send a message to service 2. In contrast, in an object-oriented or component-oriented world, service 1 should create an instance of service 2 (or a proxy for a service 2). In this case, the boundaries between these services become blurred because service 1 is controlled for all purposes by service 2.

If service 1 sends a message to service 2, is there a problem with the location of service 2? The answer is, as long as service 1 allows the message to be sent to service 2. It is speculated that sending a message across a boundary can bring costs. This cost should be taken into account when building a service. In particular, our services should travel as little as possible across the border. The opposite of efficient service is "wordy" (the analogy is to send unnecessary messages over the service boundary repeatedly, resulting in unnecessary written consumption).

Service autonomy (to a certain extent)

My view is that service-oriented systems should strive to be a somewhat self-governing service, since pure self-government is impossible. True service autonomy means that services do not depend on anything but themselves. In the real world, this type of entity does not exist, and I suspect that we will see a lot of purely autonomous services in the world of distributed computing. A true service autonomy service is to dynamically establish channels, negotiate security policies dynamically, ask message schemas dynamically, and exchange messages dynamically with other services. A purely autonomous service means a late-bound architecture. We have seen this system, both in the IUnknown interface and in the misuse of reflection. The bottom line is that the developers and architects prove again and again that these types of architectures don't work (though the book says it's great). I have to revise these comments to acknowledge that the steps in the service-oriented arena are dazzling. Just 5 years ago, service-oriented applications were rare and now commonplace. This drive may take us to the path of pure self-government, but now I don't think it is necessary to overemphasize too many autonomy issues.

In practice, what does autonomy mean? From a practical point of view, it means that a service is a boundary that can control the lifecycle, control availability, and control additional services. A negative example of this behavior can be described in SQL 2000 database and proxy, where two services are hosted as Windows services, but the proxy service has a built-in database service dependency. Stopping the database service means that the proxy service will also stop. The tight coupling between the services means that they cannot be separated, or independent version control. Tight coupling reduces the flexibility of buying a service and the application in the enterprise.

Contract sharing

Because service-oriented focus on messages that are passed between participants, there must be a way to describe what these messages and successful message exchanges need. Broadly speaking, these descriptions are called contracts (contract). A contract is not a new programming concept. On the Windows platform, leases are generated in COM and DCOM. A COM component can only be accessed by a contract that is published and shared. In fact, a contract is an interface (Interface), represented by an interface Description Language (IDL). This contract makes the caller unaware of the implementation details. As long as the contract is not compromised, the caller can accommodate the software upgrades and updates of the COM component.

The concept of service-oriented systems extends the COM IDL contract. Service-oriented Systems express contracts in a more widely understood language, XSD and WSDL. More specifically, schemas are used to describe message structures, and WSDL is used to describe message endpoints. In summary, these xml-based contracts represent the message structures that are sent and received, endpoint addresses, network protocols, security requirements, and so on. The natural attributes of XML allow the sender and final recipient to run on any platform more easily than COM. In these east, the sender must know the recipient's message structure and format, and these contracts will be defined. In essence, a sender of a message needs to rely on the contract rather than the service itself.

Policy-based compatibility

A service must be able to describe the underlying environment in which other services interact with it. For example, some services require that the initial sender have a valid AD account (active Directory) or a X509 certificate. In this case, the service must express these requirements in an xml-based strategy. When writing a book, Ws-policy is the standard syntax for expressing these needs. In the fanatical pursuit of a service-oriented world, the sender of a message needs to ask the metadata instead of sending the message, further decoupling the service sender and the message recipient. As mentioned earlier, service policies are more likely to be queried at design time rather than run time.

"Address": http://www.cnblogs.com/frank_xl/