Extension SDK for BEA WebLogic Network Gatekeeper
The Extension SDK for WebLogic Network Gatekeeper consists of template source code and build tools that assists the creation of WESPA modules, SESPA modules, ESPA service capabilities, and network plug-ins that execute in WebLogic Network Gatekeeper. It also contains examples of a Policy utility class that can be used from Policy rules.
The template source code illustrates how a request from an application is propagated through the internal layers of the Network Gatekeeper down to the plug-in. It also illustrates how a network initiated request is propagated from the plug-in, through the different layers and up to an application. The network initiated part of the templates also illustrates how the application registers to listen to network initiated events.
esdk21_wlng21.zipto the file system. The file is extracted to the directory
bea\wlng21\esdk. The directory structure described in Directory structure for the templates on page 15-15 is created.
<Orbacus installation path>\bin.
ANT_HOMEenvironment variable to the Ant directory provided by the Extension SDK. The ant directory is located in
<install path to Extension SDK>\bea\wlng21\esdk\dev_tools\ant
<install path to Extension SDK>\bea\wlng21\esdk\dev_tools\ant\bin.
An overview of the WebLogic Network Gatekeeper software architecture supporting the above extension alternatives is shown in Figure 15-1.
The southern most layer, the plug-in layer, contains logic for communication with underlying network systems. The interface between the ESPA Service Capability and the plug-in, the plug-in interface, is an asynchronous CORBA interface used for communication with the service capability layer, and is defined in my_plugin_if.idl. The south bound interface of a plug-in is undefined and depends on the underlying network system. Each plug-in specifies it's type (for example CALL_CONTROL) and it's supported address plans (for example E164). The type can be customized and could be any string. Based on these criteria, plug-ins are accessed from the service capability layer.
The middle most layer, the service capability layer, enforces traffic restrictions and policies. On the northbound side of the service capability layer is the CORBA based ESPA interface and the south bound is the plug-in interface. ESPA service capability implementations register themselves in the ESPA access framework from which they can be accessed, ensuring that they can only be accessed after client authenticity has been assured by ESPA access. ESPA service capabilities can for each service request get a a plug-in that the request shall be mapped onto based on plug-in type and address plan as described above.
The Extension SDK can be used to create web services based access interfaces. These interface modules are divided in two, one SESPA part which makes a stateless native Java representation of the ESPA CORBA interface, and one web services part (WESPA) executing in Tomcat/Axis.
The south bound interface of the SESPA layer is hence the ESPA interface. The northbound SESPA interface is defined using plain java classes. WESPA will access SESPA from the web services environment executing in Tomcat/Axis, therefore both SESPA and WESPA must be loaded in the same Java class loader. A utility in the SLEE is used for this purpose, the SLEE CommonLoader. The WESPA services' northbound interface is defined in plain java files, from which WSDL files are generated. A client can use the WSDL files to generate it's own stubs in the language it uses.
For the application initiated requests, the template exposes two methods to an application in the WESPA service capability, myMethod(...) and myMethodWait(...). The method myMethod(...) returns the result asynchronously via a call to the Web Service method myMethodResult(...), or if an error has occurred via myMethodError(...). The corresponding calls are tied together via an assignment ID given by the application in myMethod(...) and provided as parameters in myMethodResult(...) and MyMethodError(...). The methods myMethodResult(...) and MyMethodError(...) are calling a Web Service that shall be implemented by the application.
The method myMethodWait(...) returns the result synchronously via the return value. The WESPA implementation calls the corresponding methods myMethod(...) and myMethodWait(...) exposed by the SESPA Service Capability module. These calls are pure Java calls.
If the login was successful, a login ticket representing the session is returned. The login ticket must be provided by the application in every consecutive call to the WESPA module. The ticket is provided in the SOAP header and is retrieved by calling the method getCurrentSessionId() in com.bea.wespa.util.SOAPHeaderHandler. The session ID returned is provided as a parameter to the call to both myMethodWait(...) and myMethodWait(...) exposed by the SESPA service capability.
For the application initiated requests, the template exposes two methods to the WESPA module in the SESPA service capability, myMethod(...) and myMethodWait(...). The method myMethod(...) returns the result asynchronously via a call to the WESPA method myMethodResult(...), or if an error has occurred via myMethodError(...). The corresponding calls are tied together via an assignment ID given by an application in myMethod(...) and provided as parameters in myMethodResult(...) and MyMethodError(...). The method myMethodWait(...) returns the result synchronously via the return value. The SESPA implementation calls the method myMethod(...) exposed by the ESPA Service Capability module.
For the method myMethodWait(...) exposed to the SESPA module, the asynchronous method myMethod(...) exposed by the ESPA module is called. The SESPA module waits for the ESPA module to call either the method myMethodResult(...) or myMethodError(...) on the SESPA modules listener interface until returning. The method could also return if the timer associated with the call to myMethodWait(...) expires. It is important to convert any, from an application point of view, synchronous calls to asynchronous as early as possible, in order to block as few threads as possible in the Network Gatekeeper. This means that these conversions should be done in the SESPA layer.
For each traffic method invocation, the SESPA service capability module retrieves the CORBA client session objects from the login ticket. First, the application session object is retrieved using the database helper utility defined in com.incomit.sespa.util.DbHelper. The object is provided in the constructor of MyServiceCapabilityImpl. By calling getApplicationSession(...) the application session object is returned. This object is provided as a parameter in when the traffic method request is propagated to the ESPA service capability module. The ESPA Manager object is also retrieved using the database helper utility. By calling getEspaManager(...) on the database helper utility the correct ESPA Manager object is returned. The Manager object is found based on the login ticket and the SLEE service name the ESPA Service capability module is registered under. The traffic method request is performed on the ESPA Manager object.
For the application initiated requests, the template exposes one asynchronous method, myMethod(...), to the SESPA module. The result of the method myMethod(...) is reported asynchronously via a call to the SESPA callback method myMethodResult(...), or if an error has occurred via myMethodError(...).
The method myMethod(...) calls an internal method, myMethodInternal(...) which implements a Policy Enforcement Point. If the request is allowed, the class MyServiceCapabilityPluginTask is instantiated and provided in the request to scheduleResourceTask(...) on the plug-in manager. When the plug-in manager has found a suitable plug-in and allocated a task, the SLEE will call doTask(...) on MyServiceCapabilityPluginTask. A reference to the plug-in is provided as an argument to doTask(...). In the doTask(...) method, the ESPA service capability module call the method myMethodReq(...) exposed by the plug-in. The result of the call to the method myMethodReq(...) is reported asynchronously to the call back interface implementation MyPluginListener_impl via the methods myMethodRes(...) or myMethodErr(...).
For each traffic method invocation, the SESPA service capability module checks if the ESPA service capability module is suspended and if it is overloaded. If not, it checks if the application session is valid. This is done by calling checkSessionValidity(...) on the ESPA utility class com.incomit.espa.util.ApplicationSessionValidityHelper.session. The Application session object is provided as a parameter in each traffic method invocation.
For the application initiated requests, the template exposes one asynchronous method, myMethodReq(...), to the ESPA module. The method myMethodReq(...) schedules a new task using scheduleSLEETask(...) on the SLEE Task Manager. As an argument to scheduleSLEETask(...) is an instance of MyMethodReqTask which is the class that will perform the actual protocol-specific communication with the underlying network node. In MyMethodReqTask the method doTask(...) will be invoked when the SLEE Task manager has assigned a new task. In the implementation of doTask(...), the interface to the Web Services part of the plug-in is fetched from the SLEE Common Loader via a call to SleeCommonLoader.getInstance().getObject(OBJ_NETWORK_INTERFACE). The Web Services part of the plug-in is called via myNetworkMethod(...) and a call to the call-back is performed via a call to myMethodRes(...) on the listener object.
The SLEE services part of the network plug-in called the method myNetworkMethod(...) in the class NetworkInterfaceImpl. This method class the underlying node via a Web Services call and returns the result to the SLEE services part of the network plug-in.
The network triggered part of the template is divided into two parts, a registration part where an application registers for network initiated events the traffic flow part where a request reaches the network plug-in and is propagated through the template traffic path up to an application. The registration part is initiated by the application and described below. The traffic path is described in Traffic flow for network triggered requests.
For the registration for network triggered notifications, the template exposes two methods to an application in the WESPA service capability, enableNetworkTriggeredEvents(...) and disableNetworkTriggeredEvents(...). The method enableNetworkTriggeredEvents(...) returns a ticket identifying the notification. The method disableNetworkTriggeredEvents(...) removes the registration for network initiated notifications. The WESPA implementation calls the corresponding methods enableNetworkTriggeredEvents(...) and disableNetworkTriggeredEvents(...) exposed by the SESPA Service Capability module. These calls are pure Java calls.
The application must login to the WESPA Access module prior to calling enableNetworkTriggeredEvents(...) or disableNetworkTriggeredEvents(...). See the Network Gatekeeper development documentation for information on how to login to WESPA Access. If the login was successful, a login ticket representing the session is returned. The login ticket must be provided by the application in every consecutive call to the WESPA module. The ticket is provided in the SOAP header and is retrieved by calling the method getCurrentSessionId() in com.bea.wespa.util.SOAPHeaderHandler. The session ID returned is provided as a parameter to the call to both enableNetworkTriggeredEvents(...) and disableNetworkTriggeredEvents(...) exposed by the SESPA service capability.
For the registration part for network triggered notifications, the template exposes two methods to the WESPA module in the SESPA service capability, enableNetworkTriggeredEvents(...) and disableNetworkTriggeredEvents(...). When the method enableNetworkTriggeredEvents(...) is invoked, an object representing the notification, NotificationInfoId, is created and a check is performed that there are not other applications that have registered for notifications with the same criteria using getIdenticalNotifications(...) on the helper class MyServiceCapabilityPersistentStorage. If there are identical notification criteria, and the notification is created by the same application, the notification is fetched from the database by calling getNotification(...) on the helper class MyServiceCapabilityPersistentStorage. The listener object is created using the method internalAddNetworkListener(...) and the listener is stored in the database using storeNotification(...) on the helper class MyServiceCapabilityPersistentStorage. An event is broadcasted to other instances of the SESPA module via a call to generateEnableNotificationEvent(...) on the event helper class MyServiceCapabilityEventHelper. The method internalAddNetworkListener(...) creates a listener object from the class MyESPAServiceCapabilityNetworkListener_impl.
When the ESPA Service capability module becomes activated, it registers the callback interface for the communication between the plug-in and the ESPA Service Capability module. The listener object is registered in the SC manger. The plug-in will query the SC manager for a suitable ESPA Service capability when a network triggered event occurs.
For the registration part for network triggered notifications, the template exposes two methods to the SESPA module in the ESPA service capability, addNetworkTriggeredEventListener(...) and removeNetworkTriggeredEventListener(...). When the method addNetworkTriggeredEventListener(...) is invoked a check that the application session is valid is performed. After this check, the method addNetworkTriggeredEventListenerInternal(...) is invoked. This method implements the Policy Evaluation Point and enables the notification via the NotificationHandler class. This class handles distribution of events between the different instances of the ESPA Service Capability module. The events are distributed when one of the following occurs:
NotificationHandler holds a hashtable, represented by the variable m_notifications, containing registered notifications and callback interfaces. The NotificationHandler class distributes the details about the notification, such as which application that has requested the notification and stores the information in the database using the NotificationHelper class and distributes the notification information to all other instances of the ESPA service capability module via the SLEE Event Handler. The event is created using generateEvent on the SLEE event channel.
The SLEE service part of the network protocol plug-in is not involved when registering for network triggered notifications. A listener, MyWPluginNetworkTriggeredEventListenerImpl, is instantiated and registered in the SLEE Common loader when the SLEE service is instantiated. The plug-in also registers in the Plug-in manager when it becomes activated.
The Web Services part of the plug-in registers the implementation of the network triggered interface NetworkInterfaceImpl and MyWPluginNetworkTriggeredEventResultListenerImpl in the SLEE Common Loader, when MyWPluginServlet.init(...) is called at startup of the servlet.
The network triggered part of the template is divided into two parts, a registration part where an application registers for network initiated events and the traffic flow part where a request reaches the network plug-in and is propagated through the template traffic path up to an application. The traffic flow is described below and the registration part is described in Registration flow for network triggered requests.
The network node performs the Web Services call myDeliverNetworkTriggeredEventMethod on the Web Service implemented in the Web Services part of the plug-in. The Web Service is bound to the class NetworkTriggeredEventListenerSoapBindingImpl.
The method myDeliverNetworkTriggeredEventMethod(...) is invoked on the class NetworkTriggeredEventListenerSoapBindingImpl. Via the method NetworkTriggeredEventListenerSoapBindingImpl.nameLookUp() the object in the SLEE service part of the plug-in is retrieved from the SLEE Common Loader via the name, OBJ_NETWORK_TRIGGERED_EVENT_LISTENER
MyWPluginNetworkTriggeredEventListenerImpl, which implements the listener for network triggered events, was instantiated and registered in the SLEE Common Loader when the SLEE service part of the plug-in was activated, that is when doActivated() is invoked by the SLEE on the class MyPluginSleeService.
In DeliverNetworkTriggeredEventTask.doTask() the class MyPluginNetworkTriggeredEventResultListenerImpl is instantiated. This class is used by the ESPA SC to send back responses to the plug-in describing the outcome of the request.
DeliverNetworkTriggeredEventTask.getListener().myDeliverNetworkTriggeredEventMethod(...) is invoked, where DeliverNetworkTriggeredEventTask.getListener() asks the SC manager for an object in the ESPA SC that listens for network initiated request and returns the listener. This object is instantiated from the class DeliverNetworkTriggeredEventTask in ESPA.
The class MyPluginNetworkTriggeredEventListener_impl implements the listener object the SLEE service part of the plug-in calls when new network initiated events arrives. The class was instantiated and registered in the SC manager when it was activated.
The SLEE service part of the plug-in calls MyPluginNetworkTriggeredEventListener_impl.myDeliverNetworkTriggeredEventMethod(...) where the class DeliverNetworkTriggeredEventTask is instantiated and provided as a scheduled task to the SLEE Task Manager via a call to scheduleSLEETask(...).
The method NotificationHandler.internalNotificationArrived(...) checks if any application has registered for notifications for the events via the method NotificationHandler.findEnabledNotification(...). The method findEnabledNotification(...) returns a list of notifications enabled by the applications.
NotificationHandler.findEnabledNotification(...) checks in the Hashtable m_notifications for notifications registered by the applications. The method returns an object of type MyServiceCapabilityNotification which holds information on which application has registered for notifications and an array of IORs to the SESPA listeners that represents the listeners registered by the applications.
A Policy Evaluation Point is implemented where it is verified if the application is permitted to receive notifications. If the policy rules denies the request, a CDR is generated that the notifications could not be delivered because of a policy violation. If the policy rules permits the request, the method NotificationHandler.executeNotificationArrived(...) is invoked.
In NotificationHandler.executeNotificationArrived(...) the class MyServiceCapabilityNetworkTriggeredEventResultListenerImpl is instantiated. This object is used by the SESPA SC to report successful or failed deliveries of notifications to the ESPA SC. The method MyServiceCapabilityNotification.getCallback() is invoked. This method returns a SESPA object representing a callback that SESPA has registered for an application. MyServiceCapabilityNotification.getCallback() returns the IOR to the SESPA listeners that corresponds to a listener registered by an application.
The class MyESPAServiceCapabilityNetworkTriggeredEventListener_impl implements the listener object in the SESPA module. The class was instantiated and provided to ESPA when the application enabled the network triggered event listener.
ESPA calls myDeliverNetworkTriggeredEventMethod(...) on the object instantiated from the class MyESPAServiceCapabilityNetworkTriggeredEventListener_impl where the class DeliverNetworkTriggeredEventTask is instantiated and provided as a scheduled task to the SLEE Task Manager via a call to scheduleSLEETask(...).
First, DeliverNetworkTriggeredEventTask.doTask() calls MyESPAServiceCapabilityNetworkTriggeredEventListener_impl.getNextCallback() which returns an object instantiated from the class MyServiceCapabilityCallbackInfo. The method gets the object from the AbstractList m_callbackList which holds a list of object instantiated from the class MyServiceCapabilityCallbackInfo. The class MyServiceCapabilityCallbackInfo holds information about the notification ticket and the endpoint of the Web Service implemented by the application that enabled network triggered notifications.
Then the object in the WESPA SC that performs the Web Services call to the application is fetched from the SLEE Common loader. The object returned is instantiated from the class MyServiceCapabilityNetworkTriggeredEventListener. The method myDeliverNetworkTriggeredEventMethod(...) is invoked on the class MyServiceCapabilityNetworkTriggeredEventListenerImpl in the WESPA SC.
After the calls has been returned from the WESPA SC, and the application, the method myDeliverNetworkTriggeredEventMethodResult(...) is called on the object provided as result listener. This object is instantiated from the class MyServiceCapabilityNetworkTriggeredEventResultListenerImpl. The method passes the result to the plug-in.
Finally the call to the Web Service implementation in the application is performed using a call to MyServiceCapabilityNetworkTriggeredEventListener.myDeliverNetworkTriggeredEventMethod(...). When the application has returned the call, the execution proceeds in the ESPA SC module.
Source code is found under
src and IDL interface files are found under
idl. Any stubs generated from IDL files will be put under a directory
generated, while compiled class files and packaged jar files will be stored under
This is a main build file for the entire Extension SDK. This build file prepares the environment by extracting necessary jar files under
lib, and builds all targets under module_templates. Note that each module may be built by itself under
module_templates\<module_name>\build, but this file must be built once initially to do the preparations.
The SLEE Service part of the plug-in uses a set of utility classes that implements the Basic SLEE services interfaces ServiceDeployable and ServiceAccessible, and extends these classes as described in Help classes for network plug-ins.
MyPlugin is used by the ESPA service capability module to invoke methods on the plug-in. The method definition
myMethodReq serves as a template for an asynchronous method request. It uses the parameter
assignmentID to keep track of corresponding requests and responses. The parameter
MyPluginListener is the callback interface as defined in the interface
myDeliverNetworkTriggeredEventMethod which is invoked when the plug-in receives a network initiated event. It is the responsibility of the plug-in to invoke this method, while it is the responsibility of the ESPA service capability module to implement it.
The purpose of this file is to define the interface between the plug-in and the OAM functionality of the SLEE. Methods defined in this interface will be accessible via the Network Gatekeeper OAM interface and the Management Tool.
Implements the class MyPluginContext. The purpose of this class is to define the service context for the plug-in and to hold data that is global for the plug-in. This class extends the wrapper class PluginContext. The following static variables are defined:
PLUGIN_TYPEdefines the plug-in type that the plug-in specifies when registering in the plug-in manager. Service capability implementations will use this type identifier when retrieving plug-ins for handling service requests. The type must match one of the allowed types in the plug-in manager service. Custom types are allowed, but must be registered in the plug-in manager.
ADDRESS_PLANSis an array holding information on the address plans supported by the plug-in. Example:
Implements the class MyPluginSleeService. The purpose of this class is to implement the state control of the plug-in as a SLEE service and to instantiate and provide a reference to the class that implements the traffic interface, the class MyPlugin_impl.
When the service gets activated and started, when the doActivated() and doStarted() methods are invoked, it creates the object that listens for network initiated traffic from the class MyPluginNetworkTriggeredInterfaceImpl, and it registers it in the SLEE Common Loader so it will be accessible by the Web Services part of the plug-in. See Plug-ins that executes as a SLEE service and a web application for more information about interaction between the web application part of a plug-in and the SLEE service part of a plug-in.
Implements the class MyPlugin_impl. The purpose of this class is to implement the traffic interface of the plug-in as a SLEE service and to implement the plug-in interface used by the ESPA service capability. The template implements the plug-in interface, used by the ESPA service capability module. The actual logic is performed in a separate class,
MyMethodReqTask. This task class is scheduled as a SLEE task. The SLEE will put it in it's transaction queue and assign a thread to it and let it execute in due time.
The class MyMethodReqTask performs the actual processing. See MyMethodReqTask.java.
The POA name MyPluginPOA reflects the name of the plug-in interface. In this case
MyPlugin. See the description of
The methods defined in the plug-in interface are implemented here. The method
myMethodReq serves as a template for all methods to be used in the plug-in interface. All methods defined in the plug-in interface must be implemented here. Also the corresponding callback interface must be used. For example, the method
myMethodReq and the callback interface
myPluginListener is defined in the plug-in interface, and
myMethodReq method signature is:
Implements the class MyMethodReqTask. This class performs the operations towards the Web Service part of the plug-in. It is implemented in a separate class in order to use the SLEE task processing functions for asynchronous operations. It fetches the object that defines the interface to the Web Services part of the plug-in from the SLEE Common Loader and calls the method
myNetworkMethod implemented in the Web Services part of the plug-in.
Implements the class MyPluginNetworkTriggeredEventResultListenerImpl. The purpose of this class is to receive the result from a previously delivered network triggered event from the ESPA SC. The results are processed in the methods myDeliverNetworkTriggeredEventMethodResult(...) and myDeliverNetworkTriggeredEventMethodError(...). Both these methods schedules SLEE Tasks that performs the actual processing, in the classes MyDeliverNetworkTriggeredEventMethodResultTask and MyDeliverNetworkTriggeredEventMethodErrorTask.
Implements the class MyWPluginNetworkTriggeredEventListenerImpl. The purpose of this class is to receive notifications on network triggered events from the Web Services part of the plug-in and to schedule a SLEE Task on the class DeliverNetworkTriggeredEventTask when a notification arrives.
The purpose of this file is to add the object implementing the interface the SLEE service part of the plug-in uses to propagate the request to the Web Services part of the plug-in. The object is added to the SLEE Common loader in the
init(...) method of the servlet.
This class implements the Web Service called by an underlying network node when network initiated requests arrives. It implements the Web Service method
myDeliverNetworkTriggeredEventMethod(...) and calls the corresponding method implemented in the SLEE Service part of the plug-in.
In contrary to the plug-in interface, which is asynchronous only, the ESPA interface offers both synchronous and asynchronous request methods to it's clients (SESPA in this case). A client that uses the synchronous request method (see below) does not have to implement or use the callback interface.
myMethod, a template for an asynchronous method request. It returns an assignmentID to keep track of corresponding requests and responses.
addNetworkTriggeredEventListener, for enabling listeners for network triggered events.
removeNetworkTriggeredEventListener,for removing listeners for network triggered events.
MyServiceCapabilityNetworkTriggeredEventListener, for forwarding network initiated requests to the SESPA SC.
MyServiceCapabilityNetworkTriggeredEventResultListener, for delivering the result of previously delivered network triggered notifications.
This file holds a class that implements the plug-in callback interface (
MyPluginListener_impl). It also handles a supervision timer on request invocations towards the plug-in to avoid session hangs if the plug-in fails to deliver a result or error callback.
This file holds the class serving as the service deployable interface. It handles notifications about SLEE service state change and also implements the ESPA Service interface defined in ESPA Access. This interface must be supported by any service that should be accessible via the ESPA Access framework.
This file contains a class with methods for distributing events to other ESPA SCs. It broadcasts and listens to events originating from an application adding or removing listeners for network triggered events. It uses incoming network triggered notifications from the network plug-in and connects them with listeners that has been registered by the SESPA SC.
This file implements the server part of the
MyServiceCapabilityManager interface. It implements the Policy Enforcement Point (PEP) and utilizes an inner helper class
MyServiceCapabilityPluginTask for performing the actual invocations towards the plug-in.
The following line schedules the helper class as a SLEE resource task, which causes the SLEE to obtain a plug-in according to the type defined in
PLUGIN_TYPE and executes the task from a separate thread:
POLICY_SERVICE_NAMEdefines the service name, visible in the Policy service Rule files for this service are loaded with this name.
POLICY_SERVICE_GROUPdefines the Policy service group of this service.
PLUGIN_TYPEdefines the plug-in type string that the service uses when obtaining plug-in references from the plug-in manager. This must be the same name as the plug-in uses when it registers itself in the plug-in manager.
SERVICE_TYPEto define the ESPA service capability type the ESPA service capability module belongs to. Possible values are defined in the JavaDoc for the ESPA service capability and plug-in interfaces.
A Policy Enforcement Point (PEP) forwards data about a certain method invocation to a Policy Decision Point (PDP), where the data is evaluated, and possible manipulated, by a policy rule. The data, which may be modified, is returned to the PEP and the execution continues if the request was allowed according to the PDP. If the request was not allowed, an exception is thrown.
The implementation of a PEP resides in the method definition of the method that will implement a PEP. In the templates, the file
MyServiceCapabilityManager_impl.java in the directory
espa_sc_impl\src\com\acompany\espa\mysctype holds an example on how a PEP may be implemented.
The example PEP resides in the method
myMethodInternal(...). The basic implementation steps of building a PEP is creating an instance of the class
PolicyRequest_impl and populating it with service context specific data, and then passing it to the policy service for evaluation. Policy evaluation may result in approval or denial of the service request. Denial is communicated to the PEP implementor through exceptions. If a PEP is accepted, the
PolicyRequest is returned by the policy service, containing the same data as the original
PolicyRequest except for that some data may have been modified by the policy rule.
The template example code in
myMethodInternal() shows how the
PolicyRequest is instantiated and populated with mandatory parameters. Any properties specific to the particular context where the PEP is enforced may be passed to policy rules as optional additional parameters in the
PolicyRequest. In the example, the data and address parameters are passed as optional.
The purpose of this class is to expose a public method,
subscriberExists, that checks in a database if a user exists. The class is a singleton class in order to be called from a Policy Rule. It uses the Subscriber profile plug-in interface to fetch subscriber data. The plug-in is found in
lib\b_db_sp_resource.jar. See Creating an example Policy Utility for information on how to deploy the plug-in and to provision users in the database.
The Policy Utility called from the example rule
DenySubscriberNotExists, found in
policy\rules\sp\. The rule is triggered from PEP in the template ESPA Service Capability, see Policy implementation concept.
myMethod, a template for an asynchronous method request. It returns an assignmentID to keep track of corresponding requests and responses.
myMethodWait, a template for a synchronous method request. It returns the result of the request.
enableNetworkTriggeredEvents, a template for enabling listeners for network triggered requests.
disableNetworkTriggeredEvents, a template for disabling of previously registered listeners for network triggered requests.
MyServiceCapabilityListener interface is a callback interface used by the SESPA module to provide the result of an asynchronous method invocation made by a WESPA module. It contains two methods,
The purpose of this class is to implement the listener the ESPA SC module calls when the ESPA SC receives notifications on network triggered notifications. It also maps ESPA login information and notification IDs to login tickets and notification IDs used in the WESPA SC.
The purpose of this class is to keep the different instances of the SESPA SC in sync. It generates events when an application has registered for notifications on network triggered events and it also handles reception of these events. It is also responsible for acting on events related to the login ticket expirations and refresh.
The purpose of this class is to implement the service deployable interface. It instantiates help classes when the SESPA module's state is changed from
started and performs class loader registration at activation. At deactivation the classes are unregistered from the class loader. Clean up procedures are performed both when the module is deactivated and stopped.
The reason for the class loader registrations is that the interface between SESPA and WESPA is a normal Java interface. Class definitions and objects must therefore be loaded into a class loader that is common for both SESPA and WESPA. The interface class files,
MySESPAServiceCapabilityListener.class, must only be included in the SESPA jar file and not in the WESPA war file since the services must share a common definition. The
SLEECommonLoader class loader is used by both services for registering and retrieving classes and objects. This is a parent class loader of both services, the WESPA service executes in Tomcat, and Tomcat has SLEECommonLoader as parent class loader.
The purpose of this class is to implement the service manageable object and the OAM methods defined in the
MyServiceCapabilityOAM.idl file. In addition, it sets the service context and creates a child POA for the ESPA service capability listeners.
myMethod, a template for an asynchronous method request. It returns an assignmentID to keep track of corresponding requests and responses.
myMethodWait, a template for a synchronous method request. It returns the result of the request.
enableNetworkTriggeredEvents, for enabling listeners for network triggered events.
disableNetworkTriggeredEvents, for disabling previously registered listeners for network triggered events.
MyServiceCapabilityListener interface is a callback interface used by the WESPA module to provide the result of an asynchronous method invocation made by a client. It contains two methods,
The network simulator application uses a Web Service implemented by the Web Services part of the network plug-in and implements the Web Service called by the Web Services part of the network plug-in. For application initiated requests it receives the request and prints the request data to System.out. For network initiated requests it performs a Web Services call to the Web Services part of the network plug-in.
In order to create a new set of modules, copy the relevant modules from
bea\wlng21\esdk\module_templates to a new directory where the development will take place. This directory will be referred to as
Depending on which modules to be developed, the build files for these module needs to be adapted to reflect the new modules. All module-specific build files are named build.xml, and are located directly under the directory for the module.
For a completely new traffic path, there is a main build file,
exampleproj\build\build.xml, that calls a a set of build files specific for the individual modules. If the new project does not include all modules this build file should be adapted to include only the relevant modules.
In the root of the jar file there is a deployment descriptor. This is an XML file describing how the software module is deployed. The name of the XML file is always srv_depl.xml, and the build files automatically creates this file in the ant target "jar". Below is a description of the tags in the XML file.
name: the name of the SLEE Service, fetched from the property local.deployName.
version: the version of the service, fetched from the property local.fullVersion.
max_alarms:-maximum number of CRITICAL alarms the service is allowed to generate before the service is set is state ERROR by the SLEE.
trace: ON or OFF. Defines if trace shall be activated for the service when it is started for the first time.
"Slee_common_loader". If it is a SESPA service, set this attribute to
"SESPA_access". SESPA_Access has the
Slee_common_loaderas a parent class loader, so the SESPA services have access to the classes in the SLEE Common loader. See Plug-ins that executes as a SLEE service and a web application on page 7-1 and Stateless adapter framework on page 5-4 for more information on SLEE Common Loader.
<NAMESERVICE_VISIBILITY>ON or OFF. Defines if the CORBA objects that implements the ServiceAccessible interface shall be registered in the CORBA nameservice, and be reachable from outside the SLEE.
bea\wlng21\esdk\module_templatesto the working directory for your project. This directory will be referred to as