Requires management and protection services. Policy consists of a set of rules, and each rule applies to a certain aspect of runtime behavior. For example, the service may have multiple interfaces; the rules for the entire service can be set, or the rules that apply only to one or more service interfaces can also be set.
This page
Strategic Introduction Agreement Using Policy Strategy in Organization
Introduction to the strategy
In tissue, not only different departments undertake different business logic partial responsibilities, which in turn undertake different service responsibilities, and different departments or roles often manage various services. All of these groups have different responsibilities: Maybe a group is responsible for defining security rules, while another group needs to ensure the normal runtime and response of the system. Typically, these management rules need to be considered in the design phase of the project, but these solutions are usually not flexible enough to adapt to future changes. Policy is used to set rules for rules for controlling communication and service behavior. To add a strategy during the design process, you can improve flexibility and make it easier to manage.
Back to top
agreement
The message stream is an early design of the solution design phase; the message flow will be perfect and optimized in the detailed design and implementation phase of the project. The message format will be detailed and the service quality rules are set; for example, you can decide to use a reliable transactional message processing. In this way, the agreement between the services can be considered during the design process, and it is optimized and improved after the implementation phase.
When deploying the solution, the actual address will be assigned to the service and the trust rules have been defined and the authentication mechanism is specified for all communication with the outside world. In order to achieve the ideal reliability and performance purposes, the failover mechanism and load balancing mechanism will be established. At this stage, the agreement will be expanded.
During the use of the solution, new understanding may be obtained so that security rules may be required. Business relationship will change, and trust rules will also change; both will affect the agreement between services. Alternate the server and re-deploy the service. For all these reasons, the agreement may be changed.
Back to top
Use strategies in organizations
Services have different trust levels in other services. These services will turn to specific services due to specific reasons and trust the service to perform this function. However, they will not trust all services that perform this feature. For example, they trust a domain controller to provide a domain user list, but they don't trust other servers to provide this information. Compared to external services, these services will trust services in the local (in the same organization). How do these services know all this?
• Fire and forget. When using this form, only one message is sent and is not desired to get (or unwilling to accept) response. This form is usually used to send state updates, such as temperature readings. • Monolog. When using this form, the message stream is pushed to the service port and does not answer. Solden usually used for audio / visual content, often use multicast or broadcast to introduce content to more than one recipient. • Request / Response (Request / Response). This is a form that we are familiar with. At this time, the client expects to immediately get the response to the information request. This is the main message exchange form for HTTP used on the web. • "Dialog" (conversation). This is a point-to-point connection established with a plurality of associated exchanges that are bound by an approved protocol. Simple Mail Transfer Protocol (SMTP) uses this form. • Conversations. Although all previous forms can be considered as "session" form, the term is used herein to describe a flexible exchange that may involve many services. Using session forms, complex exchanges necessary to support actual business functions can be made.
The answer is that organizations can define rules and rules use the behavior of any part of the policy control software. You can set a policy to adjust the service or server runtime behavior; you can set the policy to adjust the components, communications, and service interfaces; in fact, you can define a policy for anything to be observed and managed at runtime. Policy consists of a set of rules, and each rule applies to a certain aspect of runtime behavior. For example, the service may have multiple interfaces; the rules for the entire service can be set, or the rules that apply only to one or more service interfaces can also be set. It can determine the priority of the setup and the access rights of the service, or you can decide to set the communication protocol of the interface and the access rights of the interface. In order to implement an agreement for the service interface setting policy; the policy is typically set in the service directory within the organization. Many service providers provide service-level protocols for their service users. These protocols often use legal agreements, define what services provide services and often define their service quality (QoS). Due to the formal characteristics of the SLA, you need to specify the quality of service with measurable terms, for example, a guaranteed service normal run time, the guaranteed service parallel user number, and the guaranteed service longest response time and average response time. In a non-formal method, SLA can be defined between the organization's department or define SLA for a single service. In order to ensure the quality of the commitment, it is necessary to incorporate load balancing, failover, and many other mechanisms. Then, the rules defined in the policy will then control these mechanisms.
The message processing infrastructure can adopt policies defined for specific service interfaces and enable and implement these rules. Through this strategy, organizations can specify trust relationships and communication, other services, and how to ensure the rules of the service level protocol.
The infrastructure can explain these strategies and provide the correct behavior; it supports and implements the correct authentication mechanism of all communications, a consistent protocol and encoding, design-time aggregate, review, and so on. The basic architecture can also provide searching mechanisms and showing the policy part of affecting external behavior. For example, the search mechanism does not need to display it is auditing communication; however, it should display the Simple Object Access Protocol (SOAP) of binary encoding is a choice.
In most tissues, different groups or different roles are responsible for different aspects of the infrastructure structure. A group may be responsible for service security, while another group may be responsible for service response time and normal running time; different services may be within a different scope of responsibility. These two organizations must negotiate agreements when both services managed by two different organizations need to communicate. This will end with different aspects of this agreement due to the different groups of the two sides. Basic Agreements will involve design or functionality, such as message format, message sorting, and whether to use queues; other aspects may involve security protocols, and other aspects may involve service level protocols. These agreements will correspond to the policies of both parties; these policy packets can be packetized according to the responsibilities within the organization and the collaboration agreements. Some strategies are not reflected in all agreements; but they can be packetized according to responsibility. This grouping method will support the internal responsibility of the organization.
Figure 1 demonstrates the relationship between the different aspects of the agreement with different strategies.
Figure 1. Agreement and strategy
Back to top
Strategy summary
Policy is used to define rules related to the runtime behavior of the service. It can include communication, security permissions, audit strategies, and more in service. In the design phase of the project, you can make services more flexible and easier to manage.
Using strategies can not only define their own important tasks, but also provide flexibility in changing specific details in the future. For example, a policy can be set to enable internal employees to access specific services, while in the future, the primary vendor can be added to the user of the service.
Go to the original English page
