Skip navigation.

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

Plug-ins that executes as a SLEE service and a web application

The following sections contain descriptions of plug-ins that uses or exposes Web Services:

 


Introduction

There are a lot of network nodes that exposes Web Services (SOAP/HTML) or other protocols with HTPP as a bearer. When plug-ins communicate with these network elements they can utilize the Tomcat servlet engine provided by the Network Gatekeeper. This section describes how a plug-in, or any SLEE service can interact with the Tomcat.

The plug-in must be divided into two parts, one part that executes as a regular SLEE service and one part that executes as a web application in Tomcat. The Tomcat is itself deployed as a SLEE service, Embedded_Tomcat.

When creating a server part for incoming HTTP requests, a web application in the form of a servlet or a Web Service needs to be created and deployed in Embedded_Tomcat. When creating a client part for outgoing requests, the client part should also be created as a servlet or a Web Services client, and deployed in Embedded_Tomcat. The reason for creating and deploying a servlet or a Web Service client in Embedded_Tomcat is that the necessary Axis classes are a part of the Embedded-Tomcats classpath and not a part of the SLEEs classpath.

Because of the classloader hierarchy in the Network Gatekeeper, the SLEE service part of the plug-in needs to register itself into the SLEE Common loader and the interface needs to be retrieved by the part of the plug-in that executes in Embedded Tomcat.


 


 

Figure 7-1 Classloader hierarchy

Classloader hierarchy


 

 


Interaction between the web application part of a plug-in and the SLEE service part of a plug-in

Interface class registration

It is the responsibility of the SLEE service part of the plug-in to register all interface classes associated with the communication between the SLEE Service part of the plug-in and the web application part of the plug-in. It is important that these classes are registered into SLEE Common Loader before any of them are used within the plug-in. If this is not the case a ClassCastException will occur when the SLEE Service part and the web application part communicate.

When the plug-in goes into Started state, the jar file that contains the interface definition of the implementation together with the fully qualified classname of the interface is registered in the SLEE Common Loader. In the example below, m_sc is the service context provided by the SLEE.

Listing 7-1 Registering the class interfaces

String mySOAPReciever_if = "com.acme.MySOAPReciever_if";
String JarName = m_sc.getJarName;
SleeCommonLoader.getInstance().registerClass(JarName, mySOAPReciever_if);
String mySOAPSender_if = "com.acme.MySOAPSender_if";
String JarName = m_sc.getJarName;
SleeCommonLoader.getInstance().registerClass(JarName, mySOAPSender_if);

Incoming requests

For request that originates in the network, a web application or Web Service part of a plug-in needs to be implemented. This part of the plug-in needs to communicate with the part of the plug-in that executes as a SLEE service.

In the SLEE service part of the plug-in

As the SLEE service gets into state Activated, the plug-in instantiates the implementation of the part of the plug-in that handles incoming request.

The object is added to the SLEE Common Loader. An ID is provided when registering the object. This ID is by the web application part of the plug-in to bind the implementation to the interface.

Note: It is important that the object is added in the SLEE Common Loader immediately after it has been instantiated.

Listing 7-2 Add the implementation of the interface to the SLEE Common Loader

soapReceiver = new MySOAPReciever_impl(TheContext.getServiceContext(), this);
SleeCommonLoader.getInstance().addObject(MY_SLEESERVICE_OBJECT_ID, soapReceiver);

In the web application part of the plug-in

The web application part of the plug-in gets the object that implements the SLEE service part of the plug-in from the SLEE Common Loader. The object is accessed via the ID that the object was registered in the SLEE Common Loader by the SLEE service part of the plug-in, see Listing 7-2. The object returned is then casted to the correct class. The object shall be retrieved for each request.

Listing 7-3 Fetch the interface from the SLEE Common Loader

Object obj = SleeCommonLoader.getInstance().getObject(MY_SLEESERVICEOBJECT_ID);
MySOAPReciever_if mySOAPReciever_if = (MySOAPReciever_if) obj;

Since the web application part of the plug-in is fetching the object from the SLEE Common loader, the object must exist, and it must have been registered in the SLEE Common Loader. This means that the web application part of the plug-in must start before the part that executes as a SLEE Service. This is done automatically since the regular SLEE services always are started prior to Tomcat.

Outgoing requests

For request that originates from the Network Gatekeeper, a HTPP client or Web Services client needs to be implemented. This part of the plug-in needs to communicate with the part of the plug-in that executes as a SLEE service.

In the web application part of the plug-in

The part of the plug-in that executes in Embedded_Tomcat should be responsible for constructing and performing the HTPP request. If it is a SOAP request it should be responsible for creating the SOAP message with the help of the AXIS classes available for applications running in Emdedded_Tomcat service.

When the web application being instantiated, it should add itself to the SLEE Common Loader according to Listing 7-4.

Listing 7-4 Add the implementation of the interface to the SLEE Common Loader

soapSender = new MySOAPSender_impl(TheContext.getServiceContext(), this);
SleeCommonLoader.getInstance().addObject(MY_SERVLET_OBJECT_ID, soapSender);

It is important that the web application part of the plug-in implementation is registered into the SLEE Common Loader before the SLEE Service part of the implementation tries to use the interface. One way to achieve this is to add a method in the interface used by the web application part (and implemented in the SLEE Service part of the plug-in) that notifies the SLEE service part of the plug-in that is has started, and make the web application part of the plug-in to call this method when it goes into state Active.

Since the web application parts always starts after the SLEE services, this will make sure that the SLEE part of the plug-in does not try to use interface prior to that the implementation has been instantiated.

In the SLEE service part of the plug-in

For outgoing requests, the SLEE service part of the plug-in uses the interface class registered by the web application part of the plug-in.

This means that it should fetch the object via the SLEE Common Loader and cast it to the correct class. The object shall be retrieved for each request.

Listing 7-5 Fetch the interface from the SLEE Common Loader

Object obj = SleeCommonLoader.getInstance().getObject(MY_SERVLET_OBJECT_ID);
MySOAPSender_if mySOAPSender_if = (MySOAPSender_if) obj;

This also means that the SLEE service part of the plug-in must wait until the part executing in Embedded_tomcat has registered the implementing class in the SLEE Common loader.

 

Skip navigation bar  Back to Top Previous Next