- cation takes place through a common connection which uses TCP socket or remote method invocation (RMI). User-written modules can also use this common connec- tion through the API. The BE server performs "core tasks" such as receiving and processing traps. The FE server deals with clients and performs "client tasks" such as servicing client requests and maintaining the state of the client with respect to the data being dis- played. A BE server provides services to one or more FE servers and each FE server provides services to one or more clients. A user-defined FE server can act as either server or client. To distinguish these, we refer to it as ServerFE when it acts as a server and as ClientFE when it acts as a client. The user-defined client module connects to the framework client. This client in turn connects to the FE server. The FE server then creates a session dedicated to this client connection and passes the session to the user-defined ServerFE class. The ServerFE class uses the session reference to create a user-defined sessionFE class instance which processes the user's client requests. If requests to the client are not processed in the user-defined sessionFE, then they are forwarded to the BE server. The request transferred by the user-defined sessionFE module, ClientFE, is routed to a user-defined sessionBE for processing. When the ClientFE connects to ServerBE, OSS for Telecom Networks FE server client BE server FE server client FE server client Figure 11.15 Services provided by BE and FE servers. the serverBE creates a session dedicated to this ClientFE connection and passes the instance of the session to the user-defined ServerBE class. The user-defined ServerBE class using the session reference and creates a user-defined sessionBE, which processes the user's requests which are specified by clientFE (see Figure 11.16). The transport provider interface allows users to use their own protocol imple- mentation for communication between the client and the FE server. Thus, the com- munication between th