ments that peer protocol elements use, which is why we must classify protocols, service elements and message handling functions (called MEH) of the integrator accordingly, see Fig. 5.21. OSI application Message application Abstract protocol Event protocol Message protocol handler application handling (EVH) entity element Message-handling Message-handling Message-handling Integrator protocol Integrator protocol Integrator protocol The message handler The message handler The message handler is an ASP handler is an abstract syntax is a PDU handler handler Fig. 5.21 Three basic types of protocols Abstract protocol: Peer protocol elements can communicate by remote proce- dure calls, defined by abstract service primitives (ASP). The service elements are then called event handler (EVH). A logical node that handles this type service elements must implement a message-handling function that can handle ASP instances (called communication events) and format and encode messages that are adapted to the transport service that is used by the logical node. Examples of abstract protocols are the MAP protocols between logical nodes in the GSM-PCS. TCAP provides the message-handling function in this case. Another example are protocols defined between OSI application entities that run on top of the OSI Remote Operation Service (ROSE). The ROSE protocol is, in this case, part of the message-handling protocol. A similar message-han- dling function is provided by the General Inter-ORB Protocol (GIOP, see stand- ard ISO/IEC DIS 19500-2), defined by CORBA. Abstract protocols are transparent with respect to message formats, encoding and transport service constraints. OSI application layer protocol: Peer protocol elements can communicate by data elements that are defined by abstract data types (called "abstract syntax" by OSI). The message-handling protocol in this case is the OSI presentation layer (layer 6). OSI application layer protocols are transparent with respect to encoding and transport service constraints. Message application prot