Extension SDK for BEA WebLogic Network Gatekeeper
|
 |
 |
|
 |
 |
The following sections contain descriptions of the frameworks used by extensions to WebLogic Network Gatekeeper:
All software modules executing as SLEE services interacts with the SLEE. The Web Services framework is used when a software module implements or uses a a Web Service, in both these cases the software module executes as a web application in Embedded Tomcat. The stateless adapter framework is used by the SESPA modules, while the Service capability framework is used by the ESPA modules. The plug-in framework is used by the plug-ins for interacting with the plug-in manager.
The framework for interacting with the SLEE is described in Interacting with the SLEE and the SLEE Utility Services.
The login ticket represents a login from an application. The login ticket is provided when the application logs in. The ticket shall be provided in the SOAP header of every request the application makes towards Network Gatekeeper.
The login ticket is provided in the WSSE part of the SOAP header as illustrated below. In this header, the application login user ID is also provided.
Listing 5-1 WSSE header in SOAP Header
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
<wsse:UsernameToken xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
<wsse:Username xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
domain_user@app_domain_1.default_provider
</wsse:Username>
<wsse:Password xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext" Type="wsse:PasswordText">
app:73183493944772289
</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
The login user ID is found in the <wsse:Username> tag, in the form, <Application Instance group>@<Application Account ID>.<Service Provider ID>. The login ticket is found in the <wsse:Password> tag in the form app:<login Ticket>.
The SOAPHeaderHandler is a utility class in com.bea.wespa.util.SOAPHeaderHandler. The login ticket is provided as a parameter in each request from the WESPA SC to the SESPA SC, see example below.
Listing 5-2 Calling a SESPA method
returnValue = m_serviceCapability.myMethod(
m_SOAPHeaderHandler.getCurrentSessionTicket(),
endpoint,
data,
address,
serviceCode,
requesterID);
In the example, m_SOAPHeaderHandler is instantiated from the SOAP header handler utility.
See Stateless adapter framework for a description on how SESPA implements the method and resolves a an ESPA Manager form the login ticket.
In order for a WESPA SC to use an object in SESPA it is necessary to use the SLEE Common Loader. This section will outline how to use an object in SESPA, while Stateless adapter framework describes how the class is registered and the object is loaded.
A WESPA SC must know under which name the object is registered in the SLEE Common loader.
Listing 5-3 Obtain a reference to the interfaces to a Stateless Adapter (SESPA SC)
try {
if (m_serviceCapability == null) {
Object obj = SleeCommonLoader.getInstance().getObject(
OBJ_SESPA_MY_SERVICE_CAPABILITY);
m_serviceCapability = (com.incomit.sespa.myservicecapability.MyServiceCapability) obj;
}
} catch (Throwable t) {
....
}
The SLEE Common Loader is queried for the interface object registered under the name OBJ_SESPA_MY_SERVICE_CAPABILITY. The returned object is casted to the correct class.
Since the SESPA SC uses methods in the interface exposed by the WESPA SC, WESPA must also register the interface classes and add the interface objects into the to the SLEE Common loader.
The implementation of the Web Services and the software modules executing within the SLEE cannot get hold on each others classes directly. In order to make them reach each other, the SLEE Common Loader is used. The SLEE Common Loader provides a registration and lookup mechanism as described below.
Listing 5-4 Registering a class in the SLEE Common loader
m_sc = serviceContext;
String[] ifClasses = {
"com.incomit.sespa.myservicecapability.MyServiceCapability",
"com.incomit.sespa.myservicecapability.MyServiceCapabilityListener"
};
try {
for (int i=0; i<ifClasses.length; i++) {
SleeCommonLoader.getInstance().registerClass(m_sc.getJarName(),
ifClasses[i]);
}
} catch (SleeCommonLoaderException ex) {
....
}
In the example above, the SESPA SC implementation registers its interfaces classes so that they can be used by the WESPA SC implementation. First, the name of the classes are defined in a list, and they are registered in the SLEE Common Loader together with the name of the JAR-file they are found in. In this case, the name of the file is resolved using the object m_sc, which is of type ServiceContext. Refer to Services fetched from the SLEEContext for a description of ServiceContext.
The next step is to instantiate an object and then add it to the SLEE Common loader, allowing the WESPA SC to use the objects. This is illustrated below.
Listing 5-5 Add object to the SLEE common class loader, allowing WESPA to access the object.
try {
m_myScImpl = new MyServiceCapabilityImpl(m_sc, m_dbHelper);
} catch (Exception ex) {
String errorMsg = "Failed to create MyServiceCapabilityImpl. Reason: "
+ ex.getMessage();
throw new ServiceDeploymentException(errorMsg,
errorMsg,
m_sc.getName(),
0);
}
try {
SleeCommonLoader.getInstance().addObject(OBJ_SESPA_MY_SERVICE_CAPABILITY,
m_myScImpl.getProxy());
} catch (SleeCommonLoaderException ex) {
...
}
The class is instantiated, and the object is added to the SLEE Common Loader. The object is the object implementing the interface given when registering the class (com.incomit.sespa.myservicecapability.MyServiceCapability). When the object is added, a name for it is provided (OBJ_SESPA_MY_SERVICE_CAPABILITY) which is used for looking up of the object by the WESPA SC. The name must be unique, and it is recommended to use the actual class name as a part of the name. Instead of the object itself, a proxy representing the object is provided. This is due to high availability reasons, and is further explained in High availability.
See Web Services framework for information how the object is used by the WESPA SC implementation.
Below is outlined how the object is removed from the SLEE Common Loader.
Listing 5-6 Removing an object from the SLEE Common Loader
try {
SleeCommonLoader.getInstance().removeObject(OBJ_SESPA_MY_SERVICE_CAPABILITY);
} catch (SleeCommonLoaderException ex) {
String errorMsg = "Failed to deregister SESPA MyServiceCapability
service from SleeCommonLoader. Reason: "
+ ex.getMessage();
throw new ServiceDeploymentException(errorMsg,
errorMsg,
m_sc.getName(),
0);
}
The object is removed from the SLEE Common Loader, using the name for lookup. When removing the object, all resources used should be cleaned up, and the affected applications should be notified. Objects should be cleared when SLEE calls deactivate(...) on the implementation of the service.
The ESPA SC provides the SESPA SC with an application session and a Manager on which the ESPA SC methods are invoked.
In general there is a three step process:
There are utility classed in SESPA which assist in retrieving the session and the Manager based on the login ticket.
Below is an example that illustrated how to retrieve the application session and a manager.
Listing 5-7 Getting an application session and a manager
ApplicationSession appSession = m_dbHelper.getApplicationSession(loginTicket);
MyServiceCapabilityManager espaManager = getEspaManager(loginTicket);
result = espaManager.myMethodWait(data,
address,
waitTimeoutSeconds,
serviceCode,
requesterID,
appSession);
First, the application session is fetched from the database where the correlation between the login ticket and the application session object is stored. This is done using the SESPA utility class com.incomit.sespa.util.DbHelper. m_dbHelper is an object instantiated from this class.
Then the ESPA Manager for the SC is fetched based on the login ticket. The ESPA Manager represents the ESPA SC, and the methods implemented in the ESPA SC can be invoked on this object as illustrated above. Below getEspaManager(...) is illustrated
Listing 5-8 getEspaManager(...)
public MyServiceCapabilityManager getEspaManager(String loginTicket)
throws GeneralException{
MyServiceCapabilityManager manager = null;
try {
ESPAManager espaManager = null;
espaManager = m_dbHelper.getEspaManager(loginTicket,
MyServiceCapabilityManager.SERVICE_NAME);
manager = MyServiceCapabilityManagerHelper.narrow(espaManager);
} catch(AccessException ex) {
...
}
return manager;
}
The code fragment illustrates how the ESPA manager is fetched based on the login ticket and the service name defined in MyServiceCapabilityManager.SERVICE_NAME. Where ServiceName is defined in the IDL file for the ESPA SC interface.
The manager is then narrowed to the actual class.
For information on how to interworking with the SC Manager, see SC manager and Plug-in manager interfaces.
For information on how to interworking with the Plugin manager, see Plug-in manager interfaces.
|
|
|