|
|
This section describes the example Communication Service in the Platform Development Studio:
The Communication service example demonstrates the following:
The example is based on an end-to-end Communication Service, with a set of simple interfaces
The SendData and NotificationManager interfaces are used by an application and implemented by the Communication Service.
The Notification interface is used by the Communication Service and implemented by an application.
The Communication Service to network node interface is a simple TCP/IP based interface that defines the two commands:
Figure 5-1 illustrates the flow for these operations.
The flow marked A* is for sendData, the flow marked B* is for startNotification and stopNotification, and the flow marked C* is for notifyDataReception.
The modules marked with 1 are automatically generated based on the WSDL files that defines the application-facing interface and code generation templates provided by the Platform Development Studio. The modules marked with 2 are skeletons generated at build time.
sendData.sendData method in the class SendDataPluginNorth. It will always invoke a class named PluginNorth, that has a prefix that is the same as the Java representation of the Web Service interface.The initial steps (B1-B3) are similar to flow A*. Instead of translating the request to a command on the network node, NotificationManagerNorth uses the StoreHelper to either store a new or remove a previously registered subscription for notifications. The data stored, the NotificationData, is used in network-triggered requests to resolve which application started the notification and the destination to which to send it. In the example the notification is started on an address, so the address is stored together with information to which endpoint the application wants the notification to be sent.
receiveData on NetworkToNotificationPluginAdapter.
The example Communication Service translates between an application-facing interface, defined in WSDL, see Web Service Interface Definition and a network interface, TCP/IP based, see Network Interface Definition.
This interface is a simple interface containing operations for sending data.
Input message: sendDataMessage
Output message: sendDataResponse
The Notification Manager Web Service is a simple interface containing operations for managing subscriptions to network triggered events.
Start the subscription of event notification from the network.
Input message: startEventNotificationRequest
Output message: invokeMessageResponse
Stop the subscription of event notification from the network.
Input message: stopEventNotificationRequest
Output message: stopEventNotificationResponse
The NotificationListener interface defines the methods that the Communication Service invokes on a Web Service that is implemented by an application.
Method used for receiving a notification.
Input message: notifyDataReceptionRequest
Output message: notifyDataReceptionResponse
This command sends data from the Communication Service to the network node.
This command sends data from the network node to the Communication Service.
Below is a description of the directory structure for the example Communication Service.
communication_service+- build.properties+- common.xml+- build.xml+- example| +- common| | +- build.xml| | +- dist| | | +- request_factory_skel| | | +- tmp| | | +- example.war| | | +- example_callback.jar| | | +- example_callback_client.jar| | | +- example_service.jar| | | +- resources| | | | +- enabler| | | | + facade| | | +- src| | | | +- com/<package name>Plugin| | | | | +- ExceptionType.java| | | | | +- NotificationManagerPluginFactory.java| | | | | +- SendDataPluginFactory.java| | | | | +- handlerconfig.xml| | | | | +- weblogic.xml| | +- wsdl| +- dist| | +- com.acompany.plugin.example.netex.store_4.0.jar| | +- example_enabler.ear| | +- example_facade.ear| +- plugins| | +- nextex| | | +- build.xml| | | +- dist| | | | +- example_netex_plugin.jar| | | | +- com.acompany.plugin.example.nextex.store_4.0.0.0.jar| | | +- build| | | +- config| | | | +- edr| | | | | +- alarm.xml| | | | | +- cdr.xml| | | | | +- edr.xml| | | | | +- alarm.xml| | | | +- instance_factory| | | | | +- instancemap| | | +- dist| | | | +- com.acompany.plugin.example.netex.store_4.0.jar| | | | +- example_netex_plugin.jar| | | +- src/com/acompany/plugin/example/netex/| | | | +- context| | | | +- management| | | | +- notification| | | | +- notificationmanager| | | | +- senddata| | | | +- store| | | +- storage| | | | +- wlng-cachestore-config-extensions.xmlBelow is a list of WSDL files that define the application-facing interface and the Java representation of these in the plug-in.
example_common_faults.wsdl
example_common_types.xsd
example_data_send_interface.wsdl
example_data_send_service.wsdl
example_notification_manager_interface.wsdl
example_notification_manager_service.wsdl
example_notification_interface.wsdl
example_notification_service.wsdl
Below is a list of Java source directories for the Communication Service Common and the Plug-in.
com.acompany.example.plugin.ExceptionType
com.acompany.example.plugin.NotificationManagerPluginFactory
com.acompany.example.plugin.SendDataPluginFactory
com.acompany.plugin.example.netex.context.ContextTranslatorImpl
com.acompany.plugin.example.netex.management.ConfigurationStoreHandler
com.acompany.plugin.example.netex.management.ExampleMBean
com.acompany.plugin.example.netex.management.ExampleMBeanImpl
com.acompany.plugin.example.netex.management.Management
com.acompany.plugin.example.netex.notification.north.NotificationHandlerNorth
com.acompany.plugin.example.netex.notification.south.NetworkToNotificationPluginAdapter
com.acompany.plugin.example.netex.notification.south.NetworkToNotificationPluginAdapterImpl
com.acompany.plugin.example.netex.notificationmanager.north.NotificationManagerPluginNorth
com.acompany.plugin.example.netex.senddata.north.SendDataPluginNorth
com.acompany.plugin.example.netex.senddata.south.SendDataPluginSouth
com.acompany.plugin.example.netex.senddata.south.SendDataPluginToNetworkAdapter
com.acompany.plugin.example.netex.senddata.south.SendDataPluginToNetworkAdapterImpl
com.acompany.plugin.example.netex.store.FilterImpl
com.acompany.plugin.example.netex.store.NotificationData
com.acompany.plugin.example.netex.store.StoreHelper
com.acompany.plugin.example.netex.ExamplePluginInstance
com.acompany.plugin.example.netex.ExamplePluginService
Only the Communication Service common components have associated resources. The resources are XML files that serve as deployment descriptors for the network tier EAR and the access tier EAR.
Contains deployment descriptors for the access tier EAR file. These must be present in the META-INF directory of the EAR. See http://download.oracle.com/docs/cd/E13222_01/wls/docs100/programming/app_xml.html
application.xml
weblogic-application.xml
The code generation creates these files, and the build script takes care of the packaging.
Contains deployment descriptors for the network tier EAR file. These must be present in the META-INF directory of the EAR. See http://download.oracle.com/docs/cd/E13222_01/wls/docs100/programming/app_xml.html
application.xml
weblogic-application.xml
weblogic-extension.xml
The code generation creates these files, and the build script takes care of the packaging.
Sample entries to add in the EDR, CDR, and Alarm filters.
alarm.xml
cdr.xml
edr.xml
These serves as examples. Add the contents of these to the EDR configuration file. Use the EDR Configuration Pane as described in Managing and Configuring EDRs, CDRs and Alarms in the System Administrator’s Guide.
Sample instance map for mapping of classes, interfaces, and abstract classes.
When using com.bea.wlcp.wlng.api.util.InstanceFactory to retrieve instances for a given interface, class, or abstract class, this mapping is referenced. The mapping can be overridden. See JavaDoc for InstanceFactory for details.
instancemap
Sample store configuration file. Defines how the Storage service is used by the plug-in, store type, table names, query definitions, and get and set methods. See StoreHelper, FilterImpl, and NotificationData.
wlng-cachestore-config-extensions.xml
build.properties
Defines the installation directory for Network Gatekeeper and for the Platform Development Studio.
common.xml
Defines properties, class paths, task definitions, and macros for the build.
build.xml
Main build file to build the Communication Service. This build file also contains targets for packaging deployable artifacts into the access and network tier.
build.xml
Build file for the common parts of the Communication Service.
build.xml
Deployment artefacts for the Communication Service.
example_facade.ear
The part of the Communication Service that is deployed in the access tier.
example_enabler.ear
The part of the Communications Service that is deployed in the network tier.
JAR and WAR files for the common parts of the Communication Service.
example_callback_client.jar
example_callback.jar
example_service.jar
example.war
Auto generated source for skeleton classes extending com.bea.wlcp.wlng.api.plugin.RequestFactory.
One class is generated per Service WSDL, that is per interface that defines application-initiated operations.
The classes are named <PreFix>PluginFactory, where <PreFix> is picked up from the WSDL binding in the WSDL file.
In the subdirectory that corresponds to the package name, the following classes are generated:
NotificationManagerPluginFactory.java
SendDataPluginFactory.java
These are generated as skeletons, but in the example they are adapted to the specific use cases.
Contains individual JAR files comprises the plug-in.
com.acompany.plugin.example.netex.store_4.0.jar
Includes the schema file for the store used by the plug-in, packaged together with the classes for which instances are stored. This file must be put in $DOMAIN_HOME/config/store_schema on each server in the network tier. The server needs to be restarted if any changes have been done to the store schema or the classes referred to in the store schema.
example_netex_plugin.jar
Output directory for the MBean that has been processed by the javadoc2annotation ant task.
Below is a description of the classes and the methods defined in these classes:
Enumeration for exception types:
Helper class that is used by the service EJB for two purposes:
| Note: | This class needs to remain in this package and the class name must not be changed. |
Validates the request to make sure that mandatory parameters are present. Operates on a Java representation of the Web Service call.
Used by the service EJB to extract routing data from the method call. The routing data is then given to the Plug-in Manager. This method returns the routing data in a RequestInfo object.
Called by the service EJB in order to convert Exceptions thrown by the Plug-in Manager and the Plug-in to Exceptions defined by the called method.
Converts a PluginException to an Exception that can be thrown by the method called by the application.
Implements interface com.bea.wlcp.wlng.api.plugin.context.ContextTranslator.
Responsible for setting any non-simple parameter into the RequestContext.
Puts the member variables of a complex data type into the ContextInfo.
Gets the simple data types provided in the parameter param.
Puts each of the parameters into the ContextInfo object.
These parameters are provided in each subsequent EDR that is emitted in the request.
Package: com.acompany.plugin.example.netex
Implements ManagedPluginService.
Initial point for the network protocol plug-in.
Defines the life-cycle for a plug-in service.
Also holds the data that is specific for the plug-in instance.
This class manages the life-cycle for the plug-in service, including implementing the necessary interfaces that make the plug-in deployable in Network Gatekeeper. It is also responsible for registering the north interfaces with the Plug-in Manager. At startup time it uses the InstanceFactory to create one instance of each plug-in service and at activation time it registers these with the Plug-in Manager. The InstanceFactory uses an instancemap to find out which class it should instantiate for each plug-in interface implementation. The instance map is found under the resource directory. It also has
Checks to see if the plug-in service is in running state.
Returns a list of address schemes the plug-in supports.
Initializes the plug-in service with its ID and a reference to its plug-in pool.
When entering state Started, the plug-in instantiates a TimerManager.
The plug-in service does not handle graceful shutdown: it propagates the request to public void handleForceSuspending().
When the plug-in is being forcefully suspended, the plug-in service iterates through all plug-in instances and calls public void handleSuspending() on each.
While there is a connection to the network node and the plug-in is in state ACTIVE/RUNNING this method must return true, in all other cases false. This method is invoked by the Plug-in Manager during route selection.
Returns the type of the service. Used by the Plug-in Manager to route requests to a plug-in instance that can manage the type of request. The ServiceType is auto-generated based on the WSDL that defines the application-facing interfaces.
Returns a descriptive name of the network protocol being used.
Creates a new plug-in instance.
Package: com.acompany.plugin.example.netex.
Implements ManagedPluginInstance
Defines the life-cycle for a plug-in instance/
This class manages the life-cycle for the plug-in instance including implementing the necessary interfaces that make the plug-in an instance in Network Gatekeeper.
It is also responsible for instantiating classes that implement the traffic interfaces and for initializing stores to use and MBeans.
Returns the plug-in instance ID.
Re-throws a ServiceDeploymentException if any other exception is encountered. The exception is wrapped in a ServiceDeploymentException.
Returns a handle to the ConfigurationStore used by the plug-in instance. The ConfigurationStore was initiated in public void activate().
Returns handle to the NetworkProxy. The NetworkProxy was initiated in public void activate().
Connects to the network using NetworkProxy.
Inner class of ExamplePluginService.
It has one method, run(), that tries to connect to the network node, if not connected. This class is instantiated and scheduled as a java.util.Timer in public void handleResuming().
Handles storage of configuration data using the StorageService.
A set of default settings are defined as static final variables. These are used to populate the ConfigurationStore with default values the first time the plug-in is deployed.
Takes the plug-in ID as a parameter. The plug-in ID is the key in the ConfigurationStore.
Uses ConfigurationStoreFactory to get a handle to the ConfigurationStoreService and gets the local ConfigurationStore that handles configuration data for the plug-in instance.
The plug-in only deals with configuration data that is unique for the instance in a specific server, so the store is fetched as outlined in Listing 5-1.
ConfigurationStoreFactory factory = ConfigurationStoreFactory.getInstance();
localConfigStore = factory.getStore(pluginId, LOCAL_STORE, ConfigurationStore.STORE_TYPE_LOCAL);
If the plug-in uses a ConfigurationStore that is shared between the plug-in instances in the cluster, it must fetch that one as well, as outlined in Listing 5-2
ConfigurationStoreFactory factory = ConfigurationStoreFactory.getInstance();
sharedConfigStore = factory.getStore(pluginId, SHARED_STORE, ConfigurationStore.ConfigurationStore.STORE_TYPE_SHARED);
After the ConfigurationStore is fetched, it is initialized with default values for the available configuration settings. These default values can be changed later on, using the MBeans, see ExampleMBean.
The methods above are used to set and get data to and from the ConfigurationStore. One set/get pair must be implemented per data type in the ConfigurationStore. It is only necessary to implement set/get methods for the data types actually used by the plug-in.
In the set methods, the parameter name/key is provided as the first parameter and the actual value is provided in the second parameter.
In the get methods, the parameter name/key is provided as the parameter and the actual value is returned.
Management interface for the example simulator.
It defines the following methods:
Implemented by ExampleMBeanImpl.
All MBean methods should throw com.bea.wlcp.wlng.api.management.ManagementException or a subclass thereof if the management operation fails.
Handles registration of the ExampleMBean in the MBean Server.
Delivers data originating from the network node to the application.
NetworkToNotificationPluginAdapterImpl calls this method upon a network triggered request.
The actual delivery is not done directly to the application. Instead it is done via the service callback client EJB which forwards the request to the service callback EJB. Both of these are generated during the build process.
First, the NotificationData associated with the destination address is fetched.
NotificationCallback, which is a generated class, is fetched using private NotificationCallback getNotificationCallback().
NotifyDataReception, a generated class that is a Java representation of the operation defined in the callback WDSL is instantiated.
The correlator associated with the NotificationData is set on NotifyDataReception.
The data (payload) in the network triggered request is set on NotifyDataReception.
The originating address in the network-triggered request is converted to a URI and set on NotifyDataReception.
The endpoint associated with NotificationData is fetched.
A remote call is done to the method notifyDataReception on the Callback EJB in the access tier. The endpoint and NotifyDataReception are supplied as parameters.
Helper method to get the object representing the Callback EJB.
If the object is already retrieved it is returned, otherwise the NotificationCallbackFactory is used to get a new object. This is the preferred pattern.
Using the CallBackFactory ensures high-availability between the network tier and the access tier for network triggered requests.
The Callback is generated during the build process when the access tier is generated. Three files are generated per callback WSDL. The names are based on the interface name defined in the WSDL. The interface in the WSDL is Notification, so:
The classes are completely based on the WSDL file for the callback interface. The factory shall be used to retrieve the implementation class that implements the interface.
Helper method to fetch the NotificationData from the StoreHelper. The NotificationData is retrieved based on the key destination address.
extends PluginSouth, NetworkCallback
Defines the interface between NetworkToNotificationPluginAdapter and the network node.
Implements NetworkToNotificationPluginAdapter.
Sets NotificationHandlerNorth in the class.
From interface com.bea.wlcp.wlng.api.plugin.PluginSouth
Gives the plug-in an opportunity to add additional values to the RequestContext before the network-triggered requests is passed on to public void receiveData(@ContextKey(EdrConstants.FIELD_ORIGINATING_ADDRESS) String fromAddress, @ContextKey(EdrConstants.FIELD_DESTINATION_ADDRESS) @MapperInfo(C) String toAddress, String data).
This method is called only once per network-triggered request. It is invoked after resolveAppInstanceGroupId(ContextMapperInfo), when the RequestContext for the current request has been rebuilt.
The default implementation is supposed to be empty.
RequestContext contains the fully rebuilt RequestContext.
ContextMapperInfo contains the annotated parameters in public void receiveData(@ContextKey(EdrConstants.FIELD_ORIGINATING_ADDRESS) String fromAddress, @ContextKey(EdrConstants.FIELD_DESTINATION_ADDRESS) @MapperInfo(C) String toAddress, String data).
The network node invokes this method when a network-triggered events occurs.
The method is annotated with @Edr, so the method is woven with annotation EDR.
fromAddress and toAddress are annotated with @ContextKey, which means that they will be put it the current RequestContext under the key specified by the string in the argument of the annotation. As illustrated in Listing 5-3, they are put in the RequestContext under the keys EdrConstants.FIELD_ORIGINATING_ADDRESS and EdrConstants.FIELD_DESTINATION_ADDRESS, respectively. These keys ensure that the values will be available in all subsequent EDRs emitted during this request.
toAddress is also annotated with @MapperInfo, which means that the value should be registered in ContextMapperInfo under the key specified by the string in the argument of the annotation. In Listing 5-3, the key is C.
...
@Edr
public void receiveData(
@ContextKey(EdrConstants.FIELD_ORIGINATING_ADDRESS)
String fromAddress,
@ContextKey(EdrConstants.FIELD_DESTINATION_ADDRESS)
@MapperInfo(C)
String toAddress,
String data) {...
Implements NotificationManagerPlugin.
Starts a subscription for notifications on network-triggered requests.
The method is a Java representation of the application-facing operation startEventNotification, defined in the WSDL that was used as input for the code generation.
As illustrated in Listing 5-4, the method is annotated with @EDR, and the parameter is put in the RequestContext using the annotation @ContextTranslate, since the parameter is a complex data type that requires traversal in order to resolve the simple data types. When using this annotation, the class is provided as an ID.
...
@Edr
public StartEventNotificationResponse startEventNotification(
@ContextTranslate(ContextTranslatorImpl.class) StartEventNotification parameters)
throws ServiceException {...
In the operation, these parameters are included:
<xsd:element name="correlator" type="xsd:string"/>
<xsd:element name="endPoint" type="xsd:string"/>
<xsd:element name="address" type="xsd:anyURI"/>
The values of correlator and endPoint are put in NotificationData.
The application instance ID for the originator of the request, the application that uses the Web Services interface, is resolved from the RequestContextManager and put in NotificationData.
Using StoreHelper, NotificationData is put in the StorageService.
Ends a previously started subscription for notifications on network-triggered requests.
The method is a Java representation of the application-facing operation stoptEventNotification, defined in the WSDL that was used as input for the code generation.
The method is annotated in a similar manner to public StartEventNotificationResponse startEventNotification(@ContextTranslate(ContextTranslatorImpl.class) StartEventNotification parameters).
Using StoreHelper, NotificationData corresponding to the correlator provided in the requests is removed from the StorageService.
Sets SendDataPluginToNetworkAdapter to be used for application-initiated requests.
The method is a Java representation of the application-facing operation sendData, defined in the WSDL that was used as input for the code generation.
The method is annotated in a similar manner to public StartEventNotificationResponse startEventNotification(@ContextTranslate(ContextTranslatorImpl.class) StartEventNotification parameters).
Passes on the request to SendDataPluginToNetworkAdapter.
If there is a need to retry the request, this method re-throws a PluginRetryException, so the request can be retried by the service interceptors.
Sends data to the network node.
Passes on the request to sendDataToNetwork using the NetworkProxy.
The method is annotated with @Edr.
Empty implementation that returns null. This method has meaning, and is used, only in network-triggered requests.
The application instance ID is already known in the RequestContext, since the class only handles application-initiated requests.
From interface com.bea.wlcp.wlng.api.plugin.PluginSouth
Gives the plug-in an opportunity to add additional values to the RequestContext before the application-initiated requests is passed on to public void send(NetworkProxy proxy, String address, String data).
Empty in this example. Normally all data about the request should be known at this point, so no additional data needs to be set.
Defines the interface between the plug-in and the network node for application-initiated requests.
Instantiates SendDataPluginSouth.
Sets the NetworkProxy object. This is a remote object in the network node.
Hands off the request to the network node using SendDataPluginSouth.
Implements interface com.bea.wlcp.wlng.api.storage.filter.Filter.
This is the query filter used for the named store NotificationData.
Evaluates whether an entry in the named store NotificationData matches the filter. The filter is defined in XML, see Store configuration.
Must be invoked after public void setParameters(Serializable ... parameters).
Returns true if the value provided in Object matches parameters[0], as set in public void setParameters(Serializable ... parameters).
Sets the query parameters for the filter.
The parameters are ordered as provided to the StoreQuery and it is the responsibility of the implementation to handle them in this order.
The data structure representing a notification. The notification is registered and de-registered by applications using the application-facing Web Services interfaces and represents a subscription for network-triggered events. The NotificationData is used for:
NotificationData is stored using the storage service, normally using the invalidating cache storage provider for cluster-wide access and high performance.
Each of the attributes to be stored must have a corresponding set method and get method.
The class must be serializable.
Helper class for storing NotificationData using the StorageService.
Returns the single instance of StoreHelper.
Stores the NotificationData using the Storage Service.
The named store is retrieved using private Store<String, NotificationData> getStore().
The NotificationData is put into the named store. The address is the key and the object is the value.
The named store is released. This should always be done in a finally{...} block.
Removes NotificationData using the StorageService.
The named store is retrieved using private Store<String, NotificationData> getStore().
A Set of matching entries are returned using private Set<Map.Entry<String, NotificationData>> getEntries(String correlator, Store<String, NotificationData> store).
If there are matching entries, all are removed using private void removeEntries(Set<Map.Entry<String, NotificationData>> set, Store<String, NotificationData> store).
The named store is released. This should always be done in a finally{...} block.
Gets NotificationData using the StorageService
The named store is retrieved using private Store<String, NotificationData> getStore().
The NotificationData that is keyed on destinationAddress is fetched from the store.
The named store is released. This should always be done in a finally{...} block.
Gets a named stored from com.bea.wlcp.wlng.api.storage.StoreFactory.
Gets a java.util.Set of entries of NotificationData from a named store using the StorageService. The query being used is a named query, com.bea.wlcp.wlng.plugin.example.netex.Query, defined in wlng-cachestore-config-extensions.xml.
Removes a java.util.Set of entries of NotificationData using the StorageService. The NotificationData is removed from a named store.
Implements com.bea.wlcp.wlng.api.plugin.ManagedPluginInstance.
Defines the life-cycle for a plug-in instance.
Also holds the data that is specific to the plug-in instance.
The id is the plug-in instance ID, and the parent is the Plug-in service the of which the plug-in is an instance.
The plug-in instance returns the ID that it was instantiated with.
Called when the plug-in instance is activated, so the plug-in:
If the plug-in service is in state ACTIVE (RUNNING), public void handleResuming() is called.
If the connection fails, a timer is triggered to retry the connection setup.
Called when the plug-in instance is deactivated.
If the plug-in service is in state ACTIVE (RUNNING), public void handleSuspending() is called.
The call-back is unregistered from the network node.
If existing, the timer associated with connection setup is cancelled.
The plug-in disconnects from the network node.
Returns a list of the interfaces.
Returns true if there is a connection to the network node, that is if the plug-in instance is ready to accept traffic.
Checks which operation that is about to be invoked on the plug-in instance by introspection of the RequestInfo associated with request.
If the operation is StopEventNotification and the correlator provided is cached using the Storage service, the request must be sent to all instances of the plug-in, since the request depends on an earlier request (startNotification). MATCH_REQUIRED is returned.
If the operation is any other than StopEventNotification, the request is unrelated to any previous operation and any plug-in instance can be used. MATCH_OPTIONAL is returned.
Re-throws a DeploymentException given another exception. The exception is wrapped in a DeploymentException.
Gets the ConfigurationStoreHandler.
Implements com.bea.wlcp.wlng.api.plugin.ManagedPluginService.
Defines the life-cycle for a plug-in service.
Also holds the data that is specific for the plug-in instance.
Gets a handle to the TimerManager.
Checks if the plug-in service is in RUNNING state.
Returns an array of supported address schemes.
Initializes the plug-in service with the ID and a reference to the plug-in pool.
The PluginPool holds all plug-in instances.
Instantiates a TimerManager to be used.
Empty implementation. Nothing to do here.
Iterates over all plug-in instances using the PluginInstancePool and calls public void handleResuming() on ExamplePluginInstance
The nature of the example network protocol is that is does not have connections to maintain. Because it is possible to treat this event as in public void handleForceSuspending () the request is passed on to that method.
When the plug-in service is being forcefully suspended, the plug-in instances are disconnected from the network node immediately, without waiting for any in-flight requests to complete.
This is done by iterating over the PluginInstancePool and calling public void handleSuspending() on ExamplePluginInstance
Returns the service type, com.acompany.example.servicetype.ExampleServiceType.type. The type is automatically generated when the service EJB is generated.
Returns the network protocol. A string used for informational purposes.
Creates a new instance of the plug-in service. The ID for the new plug-in is supplied together with the object that created the instance (this).
The store configuration file wlng-cachestore-config-extensions.xml defines:
Listing 5-5 shows the store configuration file for the example Communication Service.
The configuration file defines:
The configuration file, together with any non-complex data types must be packaged into a Jar and put in the directory $DOMAIN_HOME/config/store_schema so it can be accessed by the storage service.
<?xml version="1.0" encoding="UTF-8"?>
<store-config xmlns="http://www.bea.com/ns/wlng/30"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/wlng/30 wlng-cachestore-config.xsd">
<db_table name="es_example">
<key_column name="address" data_type="VARCHAR(100)"/>
<value_column name="correlator" data_type="VARCHAR(100)">
<methods>
<get_method name="getCorrelator"/>
<set_method name="setCorrelator"/>
</methods>
</value_column>
<value_column name="endpoint" data_type="VARCHAR(255)">
<methods>
<get_method name="getEndPoint"/>
<set_method name="setEndPoint"/>
</methods>
</value_column>
<value_column name="appinstance" data_type="VARCHAR(100)">
<methods>
<get_method name="getApplicationInstance"/>
<set_method name="setApplicationInstance"/>
</methods>
</value_column>
</db_table>
<store type_id="wlng.db.wt.es_example" db_table_name="es_example">
<identifier>
<classes key-class="java.lang.String" value-class="com.acompany.plugin.example.netex.store.NotificationData"/>
</identifier>
<index>
<get_method name="address"/>
</index>
</store>
<query name="com.bea.wlcp.wlng.plugin.example.netex.Query">
<sql><![CDATA[SELECT * FROM es_example WHERE correlator LIKE ?]]></sql>
</query>
</store-config>
Below is an example SLA for the example Communication Service. There are examples of service provider group and application group SLAs in:
$PDS_HOME\pte\resource\sla
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Sla xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" applicationGroupID="default_app_group" xsi:noNamespaceSchemaLocation="app_sla_file.xsd">
<serviceContract>
<startDate>2008-04-17</startDate>
<endDate>2099-04-17</endDate>
<scs>com.acompany.example.plugin.SendDataPlugin</scs>
<contract/>
</serviceContract>
<serviceContract>
<startDate>2008-04-17</startDate>
<endDate>2099-04-17</endDate>
<scs>com.acompany.example.plugin.NotificationManagerPlugin</scs>
<contract/>
</serviceContract>
<serviceContract>
<startDate>2008-04-17</startDate>
<endDate>2099-04-17</endDate>
<scs>com.acompany.example.callback.NotificationCallback</scs>
<contract/>
</serviceContract>
</Sla>
|