This page
Status Introduction Business Processing Use Other Service Online Processing and Offline Processing Status Summary
Service management status; the status referred to here is the reason for the service. Service protects this status, ensuring that the status is consistent and correct. This status is the only real current source of information.
Status
Almost all services manage persistent states; that is, stored on a certain persistent medium (eg, a file system or database). The service receives a request from another service, retrieves a state from a persistent medium, and then generates a response or update the state. Using a persistent state, the service can temporarily stop without losing the context; when the service recovers again, the lasting state is still informing, the service can continue, just like anything. The service is trying to keep the persistent state unanimously; of course, it is also necessary to keep the application status in the memory, but if a problem occurs, the service is only aborted, ignores its memory state, and then uses a persistent state to reset. Services often use the ACID transaction to maintain a consistent persistent state. The transaction is a sequence of operations performed by a single logical work unit. The ACID transaction must have four properties, called the ACID attribute:
• Atomicity. The work unit is not sluggable; either perform all data modifications or no data modifications. • Consistency. After the transaction is completed, all data must be consistent. • ISOLATION. The data of the middle state cannot be seen outside of the transaction. • DURABILITY. After the transaction is completed, its role will be permanently stayed in the system.
ACID transactions typically involve the database, so it will also involve locking of data. The service does not want to lock its data for untrusted people, because if the lock lasts for a long time, other users cannot access. Allow services to join the atomic transaction with other services means some degree of trust and some degree of coupling. Processing services are generally unable to rely on shared atomic transactions because the service may or does not participate in the atomic transaction (many old systems can be done so), or may be in a remote location (such as behind the firewall, etc.).
Service should achieve good performance and excellent maintainability through design. The internal data structure and data storage should be fully considered in design. There are some additional requirements for the design of the outside world, so you may not want it to match the internal data structure. These two mappings (data storage to internal data structure and internal data structure to the outside) can be different from each other.
Back to top
Business processing
Service processing requests, sometimes you have to process multiple requests to complete a business transaction. This process can be organized using business processing, and business processing is also referred to as processing, which controls the operation of performing a step in steps to enable the system from one state to another. In each step, the business process performs a business operation. For example, business processing can accept incoming order requests, update order systems, send responses, and then update customer relationship management (CRM) systems and production systems. Another example is to manage the entire order, delivery, and payment process. This processing will accept the quotation request, send the requested offer, accept the order, check if the order requirements can be met, send order confirmation, arrange delivery, send invoices, and so on. Each step makes the process from one consistent state into the next consistent state.
Treatment involves three persistent states:
• Permanently. This is a state in which the update is processed. This is what we usually think of when talking about the service state. In the previous example, this state is the order database and the CRM database. This status still exists after processing. • Processing status. Business processing can maintain its status; such a service can stop processing and restart processing. In the previous example, if the physical processing is running over the computer over the entire duration of a business process, it is obviously nothing to do; therefore, the business process keeps its status and stops there. When the message is received, the process is restarted; processing the status of its state and then processes the request. Take a bit, process will dehydrate and then water. We refer to the handling state of the processing. The processing state only exists during the duration of the processing, and the processing state is deleted when the processing is completed. • Message status. When the message is sent from one service to another, it is created in memory. The message is transmitted after being created, and then eventually be embodied in the memory of the other end. However, when the storage forwarding mechanism such as a queue is used, the message is held in the queue and then transmitted, then held on the other, and is deleted at the message source. At the receiving end, the whole process is very similar. The message is received and handles some processing. If everything goes well, the message is deleted from the destination, but the message can also be saved for review and tracking. The message state exists when the message is sent. As mentioned earlier, the message enters the next state from a consistent state; all combinations of all three states must be consistent after each step. Processing must be stored in an ACID transaction to store changes in a permanent state, processing status, and message status.
Transactional message processing
During the ACID transaction, no updated messages can be sent freely at any point or receive responses. As long as the sending message produces an actual effect, for example, change the persistent state of the recipient's end, you need to make sure that the message can only be sent when transaction is committed. For example, you may need to update the CRM system only when the order is accepted; so you need to send the update message to the CRM system only when the order transaction is submitted.
When the sender of the message is part of the transaction, the message will not be sent if the transaction is aborted. This shows that the message can only be sent after transaction commit. This means that it is impossible to receive a response in the same transaction.
Similarly, receiving the message in a transaction means that the message is only left when the transaction is submitted to leave the message processing infrastructure.
For a transactional queue system, this is a typical behavior.
Transactional treatment
Processing the business activity by step. Processing can update its persistent state, you can send a message, you can keep your own status. Each step can be composed of a plurality of operations, each step, makes the processing from one consistent state into the next consistent state. Each step can be included in an ACID transaction. If the permanent state, the combination of processing status, and message state can be consistent, it can be considered that the state is consistent. For example, you have to carry out the reuse and credit, if the reserves are recorded after the completion of the completion, you know that the status is consistent with the statement. In the previous example, if the order is accepted, it is known that the CRM and the production system need to be updated, or the state is consistent, or if the order is accepted, the message has been sent to the CRM system and the production system, and the state is consistent.
Figure 1 illustrates how the processing service is gradually executing a series of transactions.
Figure 1. Transaction steps in processing
Long-run business
Processing often cannot merge a series of steps into an ACID transaction; the reason is that the reason is that the processing must wait for the result of another service, or because the steps need to be too long. Treatment often uses long-term running transactions to ensure proper results. Long-term running transactions include part of business processing, which defines the logic that is compensated for any operation that has been performed without canceling the transaction. As long as the event cannot be combined into an atomic transaction, it is very useful for long-term operations. This article discusses the effects of compensation operations rather than undo operations, because we often unable to restore the original state; in many cases, the undo operation may not even be available. For example, a general ledger record has been carried out, which cannot be only changed by renovating the account value, deleting the item from the journal and reports to undo the operation. Instead, another record should be required to compensate for the original record.
As shown in Figure 2, the sending and reception of invoices and payments is a long-standing transaction. If the subscribed goods cannot be delivered, it may be necessary to cancel the invoice, or partially refund. This is different from the work that is completed, as the system does not return the original state, but compensates for the work that has been performed.
Figure 2. Transaction type
Take another example: You can book a hotel room, then cancel the reservation. The system must be able to retain this schedule, but you may ask you to pay the management fee, so it doesn't return the original state.
If a business service or user wants to cancel the transaction, an exception will be generated to the business process, and then the exception is to ensure that the compensation transaction is performed, and the compensation transaction itself can consist of one or more long-running transactions. If there is no long-term running transaction, the abnormal process will become very complicated.
Back to top
Use other services
The service includes state, the current state is always in the service to prevent an external attack. The service not only uses the data of its own management, but in many cases, the data obtained from another service is also used.
Snapshot data
Any data released outside the service is a snapshot. Generally speaking, a snapshot is a limited view of the state reserved within the service, but it is not necessarily the current view, because the status within the service may have changed after the snapshot is created.
Reference data
The reference data consists of multiple snapshots, and each snapshot contains the different data sets created after the request. When the service agent retains this reference data for reuse, we call it cache. Services can store snapshots generated from one or more services. Since the reference data is composed of different snapshots obtained from different times, some snapshots are older than other snapshots, and the possibility of containing current data is smaller.
For this reason, reference data should be stabilized so as to keep value with the change of space and time. This object can be achieved by a number of methods, including:
• Add timestamp, for example, when conducting stock price quotation, the stock value when the price starts - "(
When your reference data is stable, you can copy and use in various locations because the copy of the data is as effective as the original. However, the meaning of data does not mean that it can be trustworthy; because the data may have been out of date. For example, this may happen, your stock has enough accessories to handle a request at 9:00 am, but the accessories are not enough at 3:00 pm.
In order to minimize the possibility of this kind of thing, you should develop some update policies between service and service proxy to ensure that reference data reserved outside of the service is recreated by appropriate intervals. Service agent and status
The service agent uses reference data when helping to create the user requests that will be submitted to the service. It relies on snapshot data, and snapshot data may reflect the current state in the service or may not be reflected.
Because the request is based on reference data, the reference data may be different from the current data stored in the service, the service must be able to process the outdated request and solve the problem, the most likely way to use the reject request. Then, the service agent is responsible for processing the rejected request, and the method that may be used includes updating the data and re-submits the request, or communicates with the user next steps.
The service agent can also manage each user data. This data may be the data input to the service, or may be a user-specific data required for creating a new request.
You can use the service agent anywhere in the service and anywhere in the service and anywhere in the data without locking; in the above case, you use the reference data, that is, the data that may have been outdated. . Web services, web clients, and almost any service users operate from other services; they handle reference data and per user status. All of these participants face the challenge of using reference data.
Back to top
Online processing and offline processing
As long as you work, you are using the snapshot data. This means that in fact, all the work outside the service is essentially offline; that is, you are using non-current data. The time to create a snapshot is getting closer now, the greater the possibility of current data; however, you must always assume that the data may have changed when designing an application.
Figure 3 illustrates all snapshot data, no matter the old, it is not considered to be current data.
Figure 3 Snapshot data is not current data.
The only difference between online processing and offline processing is determined by the frequency of the update from the service, it is determined that the condition of the offline processing is that the request cannot be executed before reconnecting, whether it is requested for information or an update Request.
For example, if you are using an offline email system, your inbox may not be in the latest state; however, this may not be a problem, because the email itself does not change when the server is waiting to be downloaded. However, when you use a schedule, you can find concurrency issues because you and others may specify the same day for one day. In this case, the system must be able to detect and may resolve conflicts. In theory, this kind of thing may also happen when online, the only difference is that the system will notify you to make an appointment conflict earlier. You can make a react now.
Back to top
Summary
The presence of a service is to protect the status. You allow other services to access the status in your service through many definition interfaces. For example, a message is sent to the service, including a request to access the state stored in the service. The service changes part of this state after receiving the request, or sending a copy back to the request service.
The message can be sent or received in an ACID transaction; however, waiting for a response in one atomic transaction, it is unrealistic, and therefore, the long-term running transaction can be combined into a transactional unit. In this case, the operation is not revoked, but is compensated in the transaction. Using compensation transactions can make the error between the services easier.
Although the state is protected in the service, other services may need to reference this state to create their messages. This can be achieved using reference data obtained from the service. You can't assume that this data is valid data because it may have changed inside the service after you create a snapshot, so you should consider the mechanism for stabilizing data and processing a request that contains an outdated state. Go to the original English page
