分类：
2011-08-03 15:14:07
Interface Pattern
You assign each service interface an interface pattern, which describes the type of the communication to be executed. Before we describe the interface patterns Stateless, Stateful, and TU&C/C, it is necessary to clarify the terms stateless and stateful:
● Stateless communication means that the messaging runtime does not support the saving of a status at the provider once the messaging runtime has completed the message exchange successfully.
● Stateful communication means that the messaging runtime supports the saving of a status at the provider once the messaging runtime has completed the message exchange successfully.
Note that the messaging runtime can explicitly support or not support such a procedure. If the messaging runtime supports stateful communication, the application programmer can use the corresponding methods of the messaging runtime.
If you select the following interface pattern, you are choosing communication using the Web service runtime:
● Stateless
Web service runtime supports a point-to-point communication using Web services for this interface pattern.
● Stateful
Successive calls use a state at the provider. This interface pattern is only needed for a few special technical scenarios. It does not guarantee a common update of data at the receiver.
● TU&C/C
An interface pattern that is based on the existing protocols for synchronous and asynchronous communication and enables cross-system ROLLBACKs (see below). The interface pattern supports a point-to-point communication using Web services.
The selected interface pattern determines how an application developer programs communication in the back end. If you change the interface pattern, the application program in the back end must also be changed. This is true for a switch between interface patterns.
For cross-system updates, it is better to work with synchronous communication, because the quality of service Exactly Once (In Order) (EOIO) guarantees that a message is delivered once (in the case of EOIO in the correct order), even after a system crash.
However, if the continuance of a transaction depends on the results of a service call, you can work with a synchronous call. In this case, calls within a component are unproblematic: When the called service updates changes in the system, these updates are part of the calling transaction. The caller determines for the whole transaction whether the system writes the changes to the database (COMMIT) or not (ROLLBACK). There is no such automatism for cross-system service calls. Instead, you can ensure the consistency of the data by using the TU&C/C protocol.
The TU&C/C protocol ensures that data can be updated consistently at the receiver in spite of synchronous calls. The basic procedure is as follows:
● The consumer uses a synchronous tentative update operation to call a service at the provider for updating data. However, as the name of the operation implies, the provider does not update the data just yet. Instead, the provider makes a note of the changes. A flag shows that the data still has to be updated.
● Further calls by synchronous tentative update operations are possible. If the corresponding transaction ID is transferred, the provider can assign the collected changes to a transaction.
An application that uses the TU&C/C protocol must transfer the transaction ID itself. Therefore, application developers must model a field for the transaction ID during modeling of the data type that is to be used for the message type for communication.
● The consumer then calls an asynchronous compensate operation or an asynchronous confirm operation:
○ The consumer uses the compensate operation to declare all previous tentative update operations of a transaction as invalid. The provider does not update them and can delete the temporary entries.
○ The consumer uses the confirm operation to declare that all previous tentative update operations of a transaction are to be updated. The provider writes the data to the database.
This mechanism is based on guaranteed processing of asynchronous messages and only functions under the following conditions, which are often referred to as the contract between the consumer and the provider:
● The consumer system sends either a confirm message or a compensate message as soon as the running transaction ends, not only if this is as the result of an explicit COMMIT or ROLLBACK, but also if the transaction is canceled due to a system error.
● The provider system makes sure that the provisional changes of the tentative update operations are written to the database as soon as a confirm message is received, or that they are rejected as soon as a compensate message is received. This happens regardless of a provider system failure or similar errors. This guarantee also applies to changes that the provider saved provisionally in addition to the changes of the tentative update messages.
The provider ignores the compensate message if a tentative update message has not yet been received.
Messaging runtime makes sure that the compensate message is sent in all error or failure situations. To do this, it registers a compensate message before the first call of a tentative update operation. If the system crashes, the system can find and send the message upon restart. If the transaction is completed successfully, the system replaces the compensate message with a confirm message, to inform the provider.
Since the TU&C/C protocol requires agreement between the consumer and provider, it is only suitable for scenarios within a system landscape and not for cross-company scenarios such as communication with anonymous users using the Internet.
其中operation pattern是根据interface pattern的选择而选择的：
Interface Pattern | Operation Pattern | Mode of Operation |
Stateless | Normal Operation | Synchronous or Asynchronous |
Stateful | Normal Operation | Synchronous |
Commit Operation | Synchronous | |
Rollback Operation | Synchronous | |
TU&C/C | Normal Operation | Synchronous or Asynchronous |
Tentative-Update Operation | Synchronous | |
Confirm Operation | Asynchronous | |
Compensate Operation | Asynchronous | |
Stateless (XI 3.0 compatible) Note: This interface pattern will be available only if you have the SAP NetWeaver PI installation in your landscape. | Normal operation | Synchronous or asynchronous |
