Document directory
- General Service-oriented principle --- from Chapter 8 of SOA concepts, technologies and Design
- WCF programming-service-oriented overview
- Architecture Principles
- Practical principles
SOA new business language new system architecture-SOA principles
General Service-oriented principle --- from Chapter 8 of SOA concepts, technologies and design, we have established more than one SOA definition in Chapter 3rd. There are also more than one standard body that controls and defines the principles behind service orientation. Similarly, there are many open it organizations, vendors, and consulting organizations that share the composition of services. It is said that the root cause of service-oriented is the separation of concerns in software engineering theory ". This theory is based on the idea that it is helpful to break down a major problem into a series of individual concerns. This allows the logic to break down the issues to be solved into smaller sets of related fragments. Each segment of logic processes a specific focus. This theory has been implemented by different development platforms in different ways. For example, object-oriented programming and component-based programming methods achieve separation of focus by using objects, classes, and components. Service orientation can be seen as separation of focus in a completely different way. The service-oriented principle provides a method that supports this theory and implements a basic paradigm. On this basis, many contemporary SOA features can be constructed. In fact, if you study these features again, you will notice that several (directly or indirectly) are associated with the separation of concerns theory. As mentioned above, there is no official service-oriented principle. However, there are some of the most common service-oriented association principles. These principles are listed below, which will be further described in this section.
- Service reusabilityWhether or not there are opportunities for instant reuse, services are designed to support potential reusability.
- Share a formal contract with a serviceTo interact with a service, you only need to share the formal contract that describes the definition of each Service Information Exchange term.
- Services are loosely coupledThe service is designed to interact without close and cross-service dependencies.
- Service is the abstraction of underlying logicOnly some services exposed through the service contract are visible to the external world. The underlying logic expressed outside the contract is invisible and has nothing to do with the service requestor.
- Services can be combinedServices may be combined with other services. This allows the logic of different granularities and facilitates the creation of reuse and abstraction layers.
- Services are autonomousThe logic is controlled by the service and located within a clear boundary. The service has been controlled within this boundary and does not rely on other services that execute its control.
- The service is stateless.The service should not need to manage status information, so it can maintain loose coupling. The service should be designed as stateless as much as possible, even if it means to move status management elsewhere.
- Services are discoverableThe service shall allow its description to be discovered and understood by the service requestor who may exploit its logic manually.
In these eight principles, autonomy, loose coupling, abstraction, and the need for formal contracts are considered as the core principles that form the fundamental foundation of SOA. As follows:
How is the service-oriented principle internally related?As explained in the section, these four principles directly support the implementation of other principles (and their mutual. WCF programming-service-oriented overview Architecture Principles service-oriented methodologies are responsible for managing what is happening between services (see figure A-1 ). It has a set of design principles and best practices for building service-oriented applications, known as service-oriented architecture principles:
Service boundary is clearAny service is always restricted after boundaries such as implementation technology and distribution location. The contract and Data Types exposed by the service do not disclose its implementation technology and distribution location to the client, thus hiding the nature of these boundaries. Adhering to this principle can make the service have nothing to do with location and technology. No matter how you think about this principle, the idea it expresses is that the more the client knows the implementation of the service, the higher the coupling between the client and the service. To reduce the potential coupling, the Service must explicitly disclose its functions, and only operations (or data contracts) can be explicitly disclosed to the client for sharing. The rest of the service is encapsulated. Service-oriented technology uses the default Programming Model "opt-out". The published content is clearly marked as "opt-in" [note]. Note: opt-out and opt-in are two different actions and authorization methods in advertising. Here, opt-out indicates that if the service member is not explicitly set, it is not exposed by default, that is, the denial mechanism. Opt-in indicates that only the Member to be exposed is explicitly marked, and the member will be involved in the Service and can be called across the service boundary.
Services are autonomousThe service does not need to obtain the content of its client or other services. The Service Running and version should be independent of the client. This principle allows the service to evolve independently from the client. The security of the service is also independent. It can protect the service itself and transmit messages without considering the security level used by the client. In addition to common knowledge, this can also remove the coupling between the client and Service Security.
Service sharing operation contracts and data styles, rather than metadata of types and specific technologies.What the service needs to do is to decide that the content outside the service boundary should be made public and has nothing to do with technology. A service can convert a local data type into a technically unrelated representation, rather than sharing local, specific technical content, such as the assembly version number or its type. In addition, the Service should prohibit the client from knowing local implementation details, such as instance management mode or concurrent management mode. The service only discloses logical operations. The service is not transparent to the client to implement and execute operations.
Service and policy consistencyA service should publish a policy to indicate what it can do and how the client interacts with the service. The access constraints (such as reliable communication) embodied in the policy should not depend on the implementation details of the service. Not all clients can interact with all services. This type of incompatibility is completely effective and can prevent special clients from accessing the service. The publishing policy is the only method that the client determines whether they can interact with the service. At the same time, there should be no out-of-band mechanism for the client to make such a decision. The difference is that the service must be able to express the content that the service can execute and the way the client can communicate with it in the standard expression of the policy. If it cannot be expressed, it means that the service design is poor. Note: If the service is private (that is, it is not a public service), it may not actually publish any policies. This principle implies that a policy should be published if the service is needed.
The principles listed above are very abstract. Their support is mainly reflected in the technical aspects of development, calling, and designing services. Therefore, applications may follow these principles to varying degrees, just as developers can write non-object-oriented code in C ++. However, well-designed applications should try to stick to these principles. Therefore, I have added some more practical principles:
Services are secureThe service and its client must use secure communication. At least, messages sent from the client to the service must be secure and the client must have a method to verify the service. At the same time, the client may provide their security certificates in the message so that the service can authorize and authenticate them.
Services must be in the same status in the systemPartial replacement is not allowed when a client request is executed. All resources accessed by the service must be consistent after the client call. The service cannot have any remaining content as a result of an error, for example, partially affecting the system status. The service should not seek help from its client. After an error occurs, the service will restore the system to a consistent state.
Services are thread-safeThe service must be designed as thread-safe to maintain concurrent multi-threaded access. The service can also process the causal relationship or re-import of logical threads.
The service is reliable.If the client calls the service, the client can always determine whether the message is received by the Service in a certain way. Messages should be processed in the order they are sent, rather than in the order they are received.
The service is robust.The service and its error separation can prevent the error from affecting the service itself or other services. The service cannot require clients to change their behavior based on the type of errors encountered by the Service. This can facilitate service decoupling between the client and the error handling layer.
Optional principles
We can regard practical principles as mandatory principles and a set of optional principles that are not required by all applications, although adhering to these principles is usually a good idea: Services are interoperable.The designed service should be called by any client without considering the Client technology.The Service scale remains unchanged.The Service Code should be the same regardless of the number of clients or the service load. With the development of the system, this design can greatly reduce the cost of maintenance services and support different deployment scenarios.Services are availableThe service can always receive client requests without stopping them. If the service is unavailable, it means that the client needs to solve the service problem, and coupling will be introduced in turn.The service responds in a timely manner.When the service starts to process client requests, the client cannot wait too long. If the service cannot respond in time, it means that the client needs to solve the service problem, and coupling will be introduced in turn.Services are restricted
Any operation performed by the service should be as short as possible, so it cannot take too much time to process client requests. A long process means that the client needs to solve the service problem, and coupling will be introduced in turn.
