ReportConfirm Reject Confirm or Refuse ReportRefuse Accept Confirm or Refuse ORDER U_REPORT OFFER Order Offer Reportinit Reject Accept In all these cases, AM1 is the user and AM2 the provider, since AM2 runs all operations. The operation classification system does, however, allow both users and providers to be the initiator of an operation execution. It allows for uncon- firmed and confirmed operations and, in the latter case, it always defines different primitive types for successful and unsuccessful operation executions.2 AMLs also defines the difference between synchronous and asynchronous oper- ations in abstract protocols (operational synchronism), as shown by the figure below. Synchronous operations Asynchronous operations Request(op1, Request(inv1,op1,..) Request(inv2,op1,...) Confirm or Refuse Confirm or Refuse Request(op1,... Confirm or Refuse Confirm or Refuse This concept can also be used for particular operations in an interface, i.e., some operations may be synchronous, others asynchronous. Thus operational synchro- nism may be defined for an abstract protocol as a whole, or on the level of opera- tions (in operation specifications). Abstract machines can also have a peer relation, as mentioned before, which implies that they both can execute operations on behalf of the other AM. The next figure gives two examples of that. Request(op1,.. Request(op1,..) Confirm or Refuse Request(op3,...) Confirm or Refuse ReportInit(op2,...) Confirm or Refuse Management layers and layers realized on CORBA platforms are control layers that define a kind of objects. To support object-oriented interfaces between abstract machines (without presuming any particular 00 design language), AMLs defines The purpose is similar to the ACK and NACK messages in some older protocols. It is also com- mon for many protocols to add a confirmation of a previous message as a "piggy-back" bit in the next message sent. This demonstrates one aspect off the difference between ASPs and mes- sages (messages being realizations of ASPs). the ab