generalFaultReport event) RO-INVOKEindication I-invokeReport(ex.: LSM request-event) RO-RESULTindication I-invokeReport(ex.: LSM confirm-event) RO-ERRORindication I-invokeReport(ex.: LSM refuse-event) RO-REJECT-Uindication I-invokeReport(LSM generalFaultReport event) RO-REJECT-Pindication Fig. 6.3 ROSE primitives compared to AMLn meta-primitives for remote operation handling The model shows that the primary difference between ROSE and AMLn is that ROSE does not define meta-primitives. Instead, primitive types of LSM events that are carried by AMLn invokes are defined as ROSE primitive types. For example, an AMLn r-invokeOrder that carries a request-type of LSM event, must be carried by an RO-INVOKErequest if ROSE were used. An AMLn r-invokeOrder that car- ries a confirm type of LSM event must be carried by an RO-RESULTrequest etc. Besides that ROSE needs five operations (RO-INVOKE, RO-RESULT, RO- ERROR, RO-REJECT-P, RO-REJECT-U) where AMLn copes with two (r-invoke, I-invoke), the major disadvantage with ROSE is that the primitive types of LSM events are made visible in SAGs. A ROSE-based common agent layer can there- fore only support abstract protocols that apply the ROSE operation classification system, while the AMLn invokes support any type of operation classes, including ROSE and AMLs. Note also that the ROSE remote operation protocol must define many message types due to this solution, while the corresponding AMLn protocol defines a single message type for invokes (see Fig. 2.26). Thus, by not realizing the need for meta- primitives, a ROSE-based common-agent layer is not only restricted in its applica- bility, but also considerably more complex than the AMLn common agent layer. The ROSE solution to primitives in SAGs would make some sense if the ROSE ASE did verify the validity of LSM events. For example, if an agent received a message that identified a duplicate of a previously received LSM event, it could just discard it; if it received a message that contained an LSM event of type Request when an event 