Skip navigation.

eDocs Home > BEA Extension SDK for WebLogic Network Gatekeeper 2.1 Documentation > Extension SDK for BEA WebLogic Network Gatekeeper > General sequence diagrams

Extension SDK for BEA WebLogic Network Gatekeeper

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

General sequence diagrams

Below are a set of generalized sequence diagrams describing the call flow through the Network Gatekeeper. The flows are described from an end-to-end perspective, from a northbound, application-facing, Web Service interfaces to a plug-in.

The following sections contain sequence diagrams:

 

Asynchronous application-initiated

Below is a sequence showing the flow of an arbitrary method request through the Network Gatekeeper. The method call is performed asynchronous from the point-of-view of the application, and the request is performed asynchronous trough the Network Gatekeeper. Requests must always be asynchronous inside Network Gatekeeper, otherwise resources will be reserved for too long from an end-to-end perspective.

Figure 4-1 Asynchronous application-initiated sequence

Asynchronous application-initiated sequence


 

  1. An application performs a method request (SOAP) towards the Web Services implementations (WESPA SC). The implementation of the WESPA SC is deployed in the Embedded Tomcat server.
  2. The methods request is propagated to the stateless adapter (SESPA SC). This is a normal Java request, since SESPA has registered its interface, all classes, and all objects in the SLEE Common Loader.
  3. A listener class is instantiated. This object is provided as a call-back object when the method request is propagated to the ESPA SC. This method call is using CORBA.
  4. In the ESPA SC, a request to evaluate (eval) the request is performed towards the Policy service. This request is called a Policy Enforcement Point (PEP). Two scenarios are possible after policy has evaluated the request:
    1. The method request is denied by the Policy Service, and a PolicyException shall be thrown towards the SESPA SC. The exception will be propagated to WESPA SC and finally to the application.
    2. The method request is accepted by the Policy Service. The parameters feed into the evaluation requests are returned. These may be altered by the Policy Service so the original request parameters shall be updated with the ones received from the policy evaluation.
  5. A resource task is scheduled by calling scheduleResourceTask on the plug-in manager.
  6. ScheduleResourceTask returns immediately and the execution thread returns back to the SESPA SC, the WESPA SC, and finally to the application.
  7. When the Plug-in manager has found a suitable plug-in and a free thread is available from the pool of threads. The SLEE Tread Pool Manager performs doTask(...) on the call-back listener object provided in the call to scheduleResourceTask.
  8. When doTask is called, a listener object is created.
  9. The request is propagated to the plug-in, with the newly created listener call-back object sent as an argument.
  10. The plug-in performs the protocol specifics related to the request. Illustrated here is an asynchronous request, so the operation toward the network node is returned immediately, but the result of the operation will be received later on.
  11. When the response to the request reaches the plug-in, it propagates the response to the ESPA SC listener.
  12. When the SC has received the response it creates a CDR using the SLEE Charging service.
  13. The response is propagated from the ESPA SC listener to the SESPA listener.
  14. The SESPA listener propagates the response to the WESPA SC, which propagates the response to the application.

 

Synchronous application-initiated

Below is a sequence showing the flow of an arbitrary method request through the Network Gatekeeper. The method call is performed synchronous from the point-of-view of the application, although the request is not performed synchronous trough the Network Gatekeeper. Requests must always be asynchronous inside Network Gatekeeper, otherwise resources will be reserved for too long from an end-to-end perspective.

The synchronization is performed in the SESPA layer.

Figure 4-2 Synchronous application-initiated sequence

Synchronous application-initiated sequence


 

  1. An application performs a method request (SOAP) towards the Web Services implementations (WESPA SC). The implementation of the WESPA SC is deployed in the Embedded Tomcat server.
  2. The methods request is propagated to the stateless adapter (SESPA SC). This is a normal Java request. Since SESPA register its interface, all classes, and all objects in the SLEE Common Loader.
  3. A listener class is instantiated. This object is provided as a call-back object when the method request is propagated to the ESPA SC. This method call is using CORBA.
  4. In the ESPA SC, a request to evaluate (eval) the request is performed towards the Policy service. This request is called a Policy Enforcement Point (PEP). Two scenarios are after policy has evaluated the request:
    1. The method request is denied by the Policy Service, and a PolicyException shall be thrown towards the SESPA SC. The exception will be propagated to WESPA SC and finally to the application.
    2. The method request is accepted by the Policy Service. The parameters feed into the evaluation requests are returned. These may be altered by the Policy Service so the original request parameters shall be updated with the ones received from the policy evaluation.
  5. A resource task is scheduled by calling scheduleResourceTask on there plug-in manager.
  6. ScheduleResourceTask returns immediately and the execution thread returns back to the SESPA SC.Where SESPA waits for the response to the request to arrive to the listener.
  7. When the Plug-in manager has found a suitable plug-in and a free thread is available from the pool of threads. doTask is performed on the call-back listener object provided in the call to scheduleResourceTask.
  8. When doTask is called, a listener object is created.
  9. The request is propagated to the plug-in, with the newly created listener call-back object sent as an argument.
  10. The plug-in performs the protocol specifics related to the request. Illustrated here is an asynchronous request, so the operation toward the network node is returned immediately, but the result of the operation will be received later on.
  11. When the response to the request reaches the plug-in, it propagates the response to the ESP A SC listener.
  12. When the SC has received the response it creates a CDR using the SLEE Charging service.
  13. The response is propagated from the ESPA SC listener to the SESPA listener.
  14. The SESPA listener performs a notify on the listener, and thus returning releasing the object previously set in state wait. The response is finally returned to the application through the SESPA SC and the WESPA SC.

 

Network-triggered

Below is a sequence showing the flow of an arbitrary method network triggered request through the Network Gatekeeper.

Before receiving and forwarding requests originating from the network to an application, the application must register to notifications for the event in question.

Figure 4-3 Network-triggered sequence

Network-triggered sequence


 

Registering the listener

  1. An application performs a method request (SOAP) towards the Web Services implementations (WESPA SC). The implementation of the WESPA SC is deployed in the Embedded Tomcat server. The method request (addListener) provides an URL to an end-point, where the application has implemented the Web Service that is used by Network Gatekeeper not notify the application about network-initiated events.
  2. The request to add the listener is propagated to the stateless adapter (SESPA SC). This is a regular Java request. Since SESPA register its interface, all classes, and all objects in the SLEE Common Loader.
  3. A listener class is instantiated. This object is provided as a call-back object when the method request is propagated to the ESPA SC. This method call is using CORBA.
  4. In the ESPA SC, a request to evaluate (eval) the request is performed towards the Policy service. This request is called a Policy Enforcement Point (PEP). Two scenarios are after policy has evaluated the request:
    1. The method request is denied by the Policy Service, and a PolicyException shall be thrown towards the SESPA SC. The exception will be propagated to WESPA SC and finally to the application.
    2. The method request is accepted by the Policy Service. The parameters feed into the evaluation requests are returned. These may be altered by the Policy Service so the original request parameters shall be updated with the ones received from the policy evaluation.
  5. The ESPA SC call getResourceCtx on the ResourceDiscovery interface in the plug-in manager. The type of plug-in requested is provided together with a property that asks for if the plug-in is capable of handling network initiated traffic. A plug-in is returned.
  6. The ESPA SC updates the database with the reference and distributes the reference to other ESPA SCs.
  7. An ID for the listener is returns to the SESPA SC, which also updates the database with the references and distributes the references to other SESPA SCs.
  8. The ID is returned to the Application. This ID is used to when removing the listener.
  9. When a plug-in has been chosen, the plug-in manger invokes addListener on the plug-in, which starts to listen on network-initiated events. As an alternative there can be one listener in the ESPA SC, and the plug-in distributes all incoming events to this listener. The registration of the listener should be performed when the ESPA SC becomes activated.

Handling incoming events

  1. An network-initiated event is routed to the plug-in.
  2. The plug-in queries the SC manager for information on which ESPA SCs that has registered for notifications on the event, using the method getSCSCtx on the SCSDiscovery interface. The parameters provided are matched to the parameters given when the listener was created.
  3. ScheduleResourceTask returns immediately and the execution thread returns back to the SESPA SC.Where SESPA waits for the response to the request to arrive to the listener.
  4. A list of matching ESPA SCs is returned, and the plug-in invokes a method on the ESPA SC, in this case the method called is notify. Which methods to call is specific to the SC.
  5. The ESPA SC tries to find all registered listeners in SESPA.
  6. When a listener is found, the method request is propagated to the SESPA SC listener which performs the charging specifics.
  7. The method request is propagated to the WESPA SC, which will perform a request to the application.

 

Skip navigation bar  Back to Top Previous Next