Deployment for Enterprise Service Portals
The SDX software provides a framework for building enterprise service portals. Service providers use this API and framework to develop Web applications that their enterprise customers can use to manage their services.
The following sections explain the architecture, component interactions, and deployment for key cases.
Enterprise Portal Architecture
Figure 19 shows the basic elements and communication protocols of an enterprise service portal.
Elements for an Enterprise Service Portal
An enterprise service portal 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 enterprise service portal requires a NIC to identify which SAE is managing a subscriber. This NIC takes the distinguished name (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 enterprise service portal
Internally, the enterprise service portal 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 9 describes the communication protocols that are used between elements in the enterprise service portal network.
Deployment Scenario for an Enterprise Service Portal
This section covers deployment and component interactions for enterprise service portal deployment as shown in Figure 20.
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 enterprise service portal 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 enterprise service portal receives feedback on the session state and parameter values of a session using remote procedure calls through the CORBA connection directly to the SAE managing the session.
Advanced Services Gateway Architecture
Figure 21 shows the architecture for the Advanced Services Gateway (ASG). The ASG allows a gateway client—an application that is not part of the SDX network—to interact with SDX components. The ASG supports several Web applications that allow gateway clients to interact with the SDX network. These Web applications communicate with gateway clients through SOAP interfaces.
