EASP Deployment

The SDX software includes an API and framework for building Enterprise Access Service Portals (EASPs). Service providers use this API and framework to develop Web applications that their enterprise customers can use to manage their services.

For more information about EASP, see Chapter 3, Enterprise Services.

The following sections explain the architecture, component interactions, and deployment for key EASP cases.

Enterprise Portal Architecture

Figure 19 shows the basic elements and communication protocols of an EASP.

Figure 19: EASP elements and communication protocols

EASP Elements

The EASP consists of a server cluster that communicates with the following network elements:

• Directory system - a distributed set of directories with information shadowing and chaining agreements between master and slave servers
• (Optional) Network information collector

For SDX implementations that use more than five SAEs, the EASP requires a NIC to identify which SAE is managing a subscriber. This NIC takes the DN of an access as the key and returns the corresponding SAE as the value. For SDX implementations that use five or fewer SAEs, you can use directory eventing to identify the SAEs.

• Remote SAE
• Manager PC - a client PC where the enterprise manager runs a Web browser to communicate with the EASP

Internally, the EASP consists of a J2EE application server cluster that implements an Enterprise Portal API, an enterprise Web application that uses this API, and an enterprise server. The enterprise server requires persistent sessions in the cluster. That is, the cluster member that receives the first manager session request must receive all subsequent requests for the same session. The enterprise server works with the same NIC deployments as described in the previous sections.

Communication Protocols

Table 10 describes the communication protocols that are used between elements in the EASP network.

 Table 10:  EASP communication protocols  

 Protocol
 Used for Communication Between 

 HTML/HTTPS (HyperText Markup Language over Secure HyperText Transmission Protocol)

 Enterprise manager's Web browser and the enterprise portal Web application running in the EASP


 Enterprise Portal API

 Enterprise Web application and the enterprise server


 CORBA (Common Object Request Broker Architecture) 

 Enterprise server and remote SAEs running in a different Web application server than the enterprise server


 LDAP 

 Enterprise server and SDX directories



 

EASP Deployment Scenario

This section covers deployment and component interactions for EASP deployment as shown in Figure 20.

Figure 20: EASP deployment

The directory servers are synchronized by means of server-to-server protocols, such as DISP and DSP in the case of X.500 directories, and DirX and equivalent protocols in the case of native LDAP directories, such as Sun ONE Directory Server.

In this configuration, bulk service session requests and implicit subscription reactivation caused by substitution changes are made through replication of directory information. The EASP writes new information to its local directory, and the server-to-server protocols transfer the information to the SAE's local directory. Then the SDX directory eventing system notifies the SAE of the new information, and the SAE reacts by activating and deactivating subscriptions.

The EASP gets feedback on the session state and parameter values of a session using remote procedure calls via the CORBA connection directly to the SAE managing the session.

SDX Gateway Architecture

Figure 21 shows the architecture for the SDX gateway. The SDX gateway allows a gateway client—an application that is not part of the SDX network—to interact with SDX components. The SDX gateway supports several Web applications that allow gateway clients to interact with the SDX network. These Web applications communicate with gateway clients through SOAP interfaces.

Figure 21: SDX gateway architecture