# Installing WebLogic RFID Edge Server

# Configuring WebLogic RFID Edge Server

You can configure an WebLogic RFID Edge Server by editing the `edge.props` file or by using the Administration Console. As installed, the default is to use the Administration Console.

The edge.props file is a configuration properties file for the Edge Server. It is located in `RFID_EDGE_HOME/etc`, where `RFID_EDGE_HOME` is the directory in which you installed the RFID Edge Server software.

This file is formatted as a Java properties file, where each line defines a configuration parameter. Lines beginning with a pound sign (#) character are comments and are ignored by WebLogic RFID Edge Server during processing. The file is self-documenting in that each property or set of properties is described by the comments preceding it.

The installation program writes initial configuration settings to this file.

Some setup tasks you might want to perform include:

- Configuring Readers
- Reader Simulator Configuration
- Specifying State Data Persistence
- Configuring the HTTP Notification Driver
- Enabling the SNMP Log Handler
- Setting Up the JMS Notification Driver
- Setting Up the JNDI Provider and JMS Server

## Configuring Readers

The following sections provide information related to configuring the readers that will interact with the RFID Edge Server:

- Two Approaches to Configuring Readers: edge.props or Administration Console
- Comparing Physical Readers and Logical Readers
- Using Composite Readers
- Adding Additional Physical Readers
- Using Composite Readers
- Defining Composite Readers
- Adding a Transient Filter
- Using 64-bit Tags
- Using 96-bit Tags

### Two Approaches to Configuring Readers: edge.props or Administration Console

You can configure WebLogic RFID Edge Server to communicate with supported readers, printers, filters, and a workflow configuration in one of two ways:

- Editing the `edge.props` file directly to configure these devices.
- Editing this information using the Administration Console.

The default behavior is controlled by a property in the `edge.props` file called `com.connecterra.ale.dynamicConfig.enabled`. The default setting for this property is `true:`

    com.connecterra.ale.dynamicConfig.enabled = true

This means that you can, for example, configure logical and composite readers using the Administration Console. If you want to add and configure readers by editing the `edge.props` file, set this property to `false`.

Important: One group of options is configured only through `edge.props`, and a second group of options (those mentioned earlier: readers, printers, filters, and workflow configuration) can be configured either through `edge.props` or through the Administration Console. For this second group of configuration options, if you choose to use:

- `edge.props`, anything set previously through the Administration Console is ignored.
- the Administration Console, anything set previously in `edge.props` is ignored.

You can think of the `dynamicConfig.enabled` property as a single big switch: everything in the second group of properties is configured either through `edge.props,` or through the console, but not both. Therefore you should change the setting of `dynamicConfig.enabled` to `false` only after careful consideration of these implications. (The `dynamicConfig.enabled` property itself is part of the first group, `edge.props` only.)

Note: | If `com.connecterra.ale.dynamicConfig.enabled` is set to `true`, the persistence flag, `com.connecterra.ale.persistence.disabled`, should be set to `false` (the default value) to allow reader configuration information to persist across invocations of RFID Edge Server.

RFID Reader Reference provides detailed information about the physical reader driver parameters, acceptable values, and defaults for readers recognized by WebLogic RFID Edge Server.

### Comparing Physical Readers and Logical Readers

In specifying an event cycle or programming cycle, an application names one or more readers of interest. This is necessary because a single Edge Server may manage many readers that are used for unrelated purposes. For example, in a large warehouse, there may be 10 doors, with three readers at each door (a total of 30 readers). In such a case, a typical ALE request may be directed at the three readers for a particular door, but it is unlikely that an application tracking the flow of goods into trucks would want the reads from all 30 readers to be combined into a single event cycle.

This raises the question of how applications specify which readers are to be used for a given cycle. One possibility is to use identities associated with the readers themselves; for example, a unique name, serial number, IP address, etc. This is undesirable for several reasons:

- The exact identities of readers deployed in the field are likely to be unknown at the time an application is authored and configured.
- If a reader is replaced, this unique reader identity will change, forcing the application configuration to be changed.
- If the number of readers must change — for example, because it is discovered that four readers are required instead of three to obtain adequate coverage of a particular loading dock door — then the application must be changed.

To avoid these problems, ALE introduces the notion of a "logical reader." Logical readers are abstract names that an application uses to refer to one or more readers that have a single logical purpose; for example, readers positioned around a door might be called DockDoor42. Logical readers may be usefully thought of as being equivalent to "locations." Within the Edge Server, an association is maintained between logical names such as DockDoor42 and the physical readers assigned to fulfill that purpose. Any event cycle or programming cycle specification that refers to DockDoor42 is understood by the Edge Server to refer to the physical reader (or readers) associated with that name.

In many cases, a single RFID reader may support the use of more than one antenna, with the ability to treat each antenna independently. The Edge Server permits such readers to be configured so that each antenna is exposed through ALE as a separate logical reader. This gives flexibility to applications to use antennas independently or in concert, by simply specifying one or more logical readers in an ECSpec.

### Adding Additional Physical Readers

If you decide to configure readers through the RFID Devices pane on the Administration Console, see Using the RFID Edge Server Administration Console for full instructions on configuring readers, and refer to the RFID Reader Reference for details on each reader's properties.

The remainder of this section describes the reader configuration parameters used to configure additional readers in `edge.props`.

Within the `edge.props` file, each reader is configured by including several related lines of parameter definitions. Every physical reader configuration includes a line having the following form:

    com.connecterra.ale.reader.<deviceID>.class = <className>

- `<deviceID>` is the name you assign to the reader being configured. The name must be unique among all physical reader name assignments within the `edge.props` file, and must consist only of alphanumeric characters, hyphen (-), underscore (_), and plus sign (+).

The physical reader name is used to refer to the reader within the WebLogic RFID Edge Server Administration Console. It also appears in the `physicalReaderNames` list that is returned as a part of event cycle reports that include data from this reader.

- `<className>` specifies the name of a driver provided by BEA for the specific make and model of the reader. For example, the Reader Simulator is defined as:

    com.connecterra.ale.reader.SimReadr.class = com.connecterra.ale.readertypes.ThingMagicMercury4PhysicalReader

Accompanying each instance of a reader configuration is a block of additional properties that are specific to that particular reader. The properties for a given physical reader are identified by sharing a common `<deviceID>` within their property names. The properties required within each configuration block depend on the reader make and model - the particular properties required by each reader type are listed in the RFID Reader Reference.

Each provisioned physical reader has one or more logical readers associated with it, one logical reader for each operational antenna. The definition of a logical reader specifies the logical reader's name, which is used when identifying the logical reader within an event cycle specification.

Each reader configuration line in `edge.props` looks like this:

    com.connecterra.ale.reader.<deviceID>.<prop1>=<prop1value>

The `<deviceID>` is the same for all properties corresponding to a particular physical reader, `<prop1>` is the name of a property, and `<prop1value>` is the value assigned to that property. If a property is identified as optional, you can omit the corresponding line in the `edge.props` file and the default value will be used instead.

See Reader Simulator Configuration for an example of the as-shipped configuration for the Reader Simulator in `edge.props`.

Note: | A single `edge.props` file can contain properties definitions for many readers. For testing and development purposes, you may want to keep some definitions (for example, for the simulator) in the file, but inactive. You can prevent the RFID Edge Server from trying to communicate with a reader by commenting out the first line of a reader's property definitions.

### Using Composite Readers

You specify names for logical readers when defining physical readers. You can create additional logical readers by combining existing logical readers. A logical reader created in this way is called a composite reader. By defining composite readers, you can decouple applications from decisions you take at deployment time about how many readers are needed to cover a single location.

For example, suppose that today, you have four logical readers covering a location called LoadingDock23:

- `LoadingDock23_Reader1`
- `LoadingDock23_Reader2`
- `LoadingDock23_Reader3`
- `LoadingDock23_Reader4`

You specify these reader names in each `ECSpec` that you create for LoadingDock23.

Then suppose you discover that you really need five readers to cover LoadingDock23. If you specified single logical reader names in each `ECSpec`, then you would need to:

- Add the fifth reader, using the `edge.props` file, or the Administration Console RFID Devices node.
- Go back and edit each `ECSpec` to include the new fifth reader.

Changing every `ECSpec` is undesirable, especially if some applications generate `ECSpec` instances for LoadingDock23 on the fly.

The alternative is to define a composite reader called `LoadingDock23`. Initially, this composite reader is configured to contain `LoadingDock23_Reader1` through `LoadingDock23_Reader4`. Applications that want to read from Loading Dock 23 simply specify `LoadingDock23` as the sole logical reader in their `ECSpec` instances.

Then, when you add your fifth reader, all you have to do is:

- Edit the `edge.props` file or use the Administration Console RFID Devices node to:

- Add the fifth reader.
- Change the definition of the `LoadingDock23` composite reader to include the fifth reader.

- Leave your `ECSpec` instances unchanged.

For information on how to define composite readers, see Defining Composite Readers.

### Defining Composite Readers

If you have chosen to configure composite readers through the Composite Readers pane on the Administration Console, see Using the RFID Edge Server Administration Console for full instructions on configuring readers. The remainder of this section describes how to define composite readers in `edge.props`.

Use the following lines in `edge.props` to define composite readers:

- `com.connecterra.ale.compositeReader.composite_reader_name.members = logical_reader_1 logical_reader_2`

`composite_reader_name`: The name you want to use for this composite reader.

`logical_reader_1 logical_reader_2`: List the logical (or composite) readers that make up this composite reader. Put a space between each reader name.

For example:

    com.connecterra.ale.compositeReader.LoadingDock23.members= LoadingDock23_Reader1 LoadingDock23_Reader2 LoadingDock23_Reader3 LoadingDock23_Reader4

Note: | Cyclic member specifications among composite reader definitions are not allowed and will be detected.

- `com.connecterra.ale.compositeReader.composite_reader_name.reportFailedMembers = false`

`composite_reader_name`: The name assigned in the statement above to identify this composite reader.

When a reader fails, you can have `ECReports` include either the name of the composite reader that the failed reader belongs to OR the logical reader name of the failed reader.

`true`: Lists failed readers by logical reader name.

`false`: Lists failed reader by composite reader name. This is the default.

### Adding a Transient Filter

You can apply a transient (tag) filter to any logical reader that you configure in edge.props. Different logical readers may share the same filter settings, or have different settings.

For each transient filter you add, three parameters that control its operation:

- `minReads` - The number of times a tag must be read before being included in the filter (i.e., visible to the event cycle).
- `firmInterval` - The maximum time (in milliseconds) allowed between reads that increase the minReads count.
- `expiredInterval` - The maximum duration (in milliseconds) for a tag not to be read before expiring from the filter.

These parameters control the filter in the following way. A tag is considered "soft" until it has been read `minReads` times, with no more than `firmInterval` milliseconds passing between each of those reads. A "soft" tag is not included in the filter's output, and therefore will not be considered by any active event cycles. If a "soft" tag is not read for more than `firmInterval` milliseconds, the count starts over again the next time the tag is read.

When the count reaches `minReads`, the tag becomes "firm." A "firm" tag is included in the filter's output, and will be considered by any active event cycles that use this logical reader. A "firm" tag remains "firm" even if the tag is not read in every read cycle, until it is not read for `expiredInterval` milliseconds. When that happens the tag is considered "expired." The next time the tag is read, it will be considered "soft", and the filter process starts again.

Setting `firmInterval` to -1 means that the count for a given tag will continue to increase towards `minReads` regardless of the time between reads, until the filter is reset. Setting `expiredInterval` to -1 causes any "firm" tag to remain "firm" until the filter is reset.

When choosing values for `firmInterval` and `expiredInterval`, you must be aware of the rate at which the logical reader performs read cycles. For most physical reader types, this is the `defaultRate` parameter times the number of active logical readers. If the `firmInterval` is less than this, tags will never become "firm" and no tags will be reported to any event cycle. Likewise, if the `expiredInterval` is less than the `defaultRate` parameter times the number of active logical readers, then it is equivalent to specifying an `expiredInterval` of zero.

To add a transient filter to a logical reader, add the following settings in the `edge.props` file. First, add the following lines to define a named filter (in the example, the filter is named `myfilter1`):

    com.connecterra.ale.filter.myfilter1.class=
      com.connecterra.ale.filtertypes.TransientFilterFactory
    com.connecterra.ale.filter.myfilter1.minReads = 3
    com.connecterra.ale.filter.myfilter1.firmInterval = 1400
    com.connecterra.ale.filter.myfilter1.expiredInterval = 1400

Then, for each logical reader to which you want to add the filter, add a line like this (in the example, the logical reader is named `myreader`):

    com.connecterra.ale.logicalReader.myreader.filters = myfilter1

To apply the same filter parameters to more than one logical reader, you may specify the same filter name for more than one reader. Even though more than one logical reader refers to the same filter name, each logical reader is processed by a different filter instance.

### Using 64-bit Tags

WebLogic RFID Edge Server supports the following 64-bit tag formats as defined by the EPCglobal Tag Data Standards Version 1.1:

- General Identifier (GID-I)
- Serialized Global Trade Item Number (SGTIN)
- Serial Shipping Container Code (SSCC)
- Serialized Global Location Number (SGLN)
- Global Returnable Asset Identifier (GRAI)
- Global Individual Asset Identifier (GIAI)
- United States Department of Defense (USDOD)

When encoded onto 64-bit tags, these tag formats require an external translation table to translate the EPC Company Prefix Index field of the tag into an EAN.UCC Company Prefix. EPCGlobal supplies a translation table at this URL (that WebLogic RFID Edge Server uses by default):

    http://www.onsepc.com/ManagerTranslation.xml

Note: | WebLogic RFID Edge Server installations include a copy of this file in the `etc` subdirectory.

Alternatively, you can specify a local file as the source of the translation table by changing the value of `com.connecterra.ale.epcIndexTableURL` in `edge.props` to `file:///c:mydir/myfile.xml`, where `myfile.xml` has the general form:

    <GEPC64Table>
    <entry index="1" companyPrefix="0037000"/>
    <entry index="2" companyPrefix="0041333"/>
    ...
    <entry index="16383" companyPrefix="0614141"/>
    </GEPC64Table>

Note: | The `file:///` (three slashes) is the required format for specifying a file in this context.

If a file name is specified without an absolute path, the path given is assumed to be relative to WebLogic RFID Edge Server's `./etc` directory. You may also specify a list of URLs, separated by spaces:

    com.connecterra.ale.epcIndexTableURL = http://www.onsepc.com/ManagerTranslation.xml file:///c:/mydir/myfile.xml

The Edge Server will try each URL in turn, from left to right, until it successfully reads from one of the URLs. You can use this syntax to specify the EPCglobal table as the primary source, and use the local file syntax as a backup in case the EPCglobal site is unreachable.

### Using 96-bit Tags

WebLogic RFID Edge Server supports the following 96-bit tag formats as defined by the EPCglobal Tag Data Standards Version 1.1. These tag formats do not require an external translation table.

- General Identifier (GID)
- Serialized Global Trade Item Number (SGTIN)
- Serial Shipping Container Code (SSCC)
- Serialized Global Location Number (SGLN)
- Global Returnable Asset Identifier (GRAI)
- Global Individual Asset Identifier (GIAI)
- United States Department of Defense (USDOD)

## Reader Simulator Configuration

The Reader Simulator provides a minimal simulation of a ThingMagic Mercury4 reader with two antennas running on your local system on port 5050. To modify the default Reader Simulator configuration using the Administration Console, you can enter properties into the Reader Configuration dialog box; for information on how to do this, see Using the RFID Edge Server Administration Console.

If you are using `edge.props` for reader configuration, the following properties are the as-shipped defaults for the Reader Simulator:

    com.connecterra.ale.reader.SimReadr.class =
      com.connecterra.ale.readertypes.ThingMagicMercury4PhysicalReader

    com.connecterra.ale.reader.SimReadr.hostname = localhost
    com.connecterra.ale.reader.SimReadr.port = 5050
    com.connecterra.ale.reader.SimReadr.defaultRate = 0
    com.connecterra.ale.reader.SimReadr.uhf2LogicalReaderName = ConnecTerra2
    com.connecterra.ale.reader.SimReadr.uhf1LogicalReaderName = ConnecTerra1

See Two Approaches to Configuring Readers: edge.props or Administration Console for a discussion of these reader-configuration mechanisms.

With minor modifications to the command that starts the Reader Simulator in the `RunReaderSim` script, the simulator can provide a minimal simulation of a Printronix printer. For information on configuring and using the Reader Simulator, see Using the Reader Simulator.

## Specifying State Data Persistence

You can configure the Edge Server to either keep or discard state data each time you stop and start the Edge Server. "State data" means:

- The `ECSpec` instances, `PCSpec` instances, `EPCCacheSpec` instances, and subscribers that you create through the ALE and ALEPC APIs.
- `ECSpec`, `PCSpec`, `EPCCacheSpec` information including the number of subscribers for a given `ECSpec`, `PCSpec`, or `EPCCacheSpec`, the number of times it has been activated, and the date/time of last activation and report delivery.
- Reader configuration data for readers configured using the Administration Console.

You configure how you want to handle state data by editing `edge.props`, as described below.

The Edge Server also includes a utility that removes all state data. For information on how to use this utility, see Using ClearEdgeServerState to Delete State Data.

### Editing edge.props to Configure State Data

Table 8-1 describes the `edge.props` properties that define how the Edge Server handles state data:

Table 8-1 State Data Values in edge.props
edge.props Property | Description
--- | ---
`com.connecterra.ale.persistence.disabled = false` | This line tells the Edge Server whether or not to keep state data each time you stop and start the Edge Server. `true`: Discard state data. `false`: Keep state data.
`com.connecterra.ale.persistence.directory = ../var/edgestate` | Relative path to the directory where you want the Edge Server to store state data.
`com.connecterra.ale.persistence.allowBadData = false` | When it starts, the Edge Server may discover that the state data you have is incomplete or not properly formatted. When this happens, you can tell the Edge Server to either stop, or continue starting with the bad data. `true`: Continue Edge Server startup, using as much data as it can, and moving the bad data aside. `false`: Stop startup if the Edge Server encounters bad state data.
`com.connecterra.ale.persistence.interval = 0` | How frequently to save different types of state data. Can be zero or a non zero positive integer (milliseconds). Zero: Tells the Edge Server to save state data ONLY when: An `ECSpec` is defined or undefined. An `ECSpec` is subscribed or unsubscribed. An `ECSpec` delivers reports. A non-zero positive integer: Tells the Edge Server to: Save state data under the conditions listed for zero, AND Save the activation count and last activated time periodically (according to the value of the integer), even when activations do not result in reports being generated.

### Using ClearEdgeServerState to Delete State Data

The `ClearEdgeServerState` utility removes all state data that you are storing in your state data directory. After you run `ClearEdgeServerState`, your Edge Server will start with no `ECSpec` instances defined. This `ClearEdgeServerState` utility also removes all dynamic configuration data. Be sure that you want the Edge Server in a newly installed stated before you the use this utility.

To run `ClearEdgeServerState`:

1. Stop the Edge Server.
2. Run `ClearEdgeServerState` as appropriate for your environment:

Windows: From a command line in the `RFID_EDGE_HOME\bin` directory, type:

    ClearEdgeServerState.bat

UNIX: From the `RFID_EDGE_HOME/bin` directory, type:

    ClearEdgeServerState.sh

3. `ClearEdgeServerState` displays a confirmation message warning you that running `ClearEdgeServerState` will reset the Edge Server to the state it was in when it was newly installed, and that client applications that depend on Edge Server state may fail.

Note: | If you run `ClearEdgeServerState` with the `-force` flag, no confirmation prompt is displayed.

4. If you are sure you want to reset the Edge Server state, type:

    YES

## Configuring the HTTP Notification Driver

To configure the HTTP notification driver, you can use the `edge.props` timeout values shown in Table 8-2.

Table 8-2 edge.props Timeout Values
Property | Description
--- | ---
`connectTimeout` | Specifies, in milliseconds, how long the driver will wait to connect to an HTTP endpoint before failing. Defaults to 30000 milliseconds if not specified.
`readTimeout` | Specifies, in milliseconds, how long the driver will wait for a response before failing. Defaults to 30000 milliseconds if not specified.

For example:

    com.connecterra.ale.notificationDriver.http.class =
      com.connecterra.ale.notifytypes.HTTPNotificationDriver
    com.connecterra.ale.notificationDriver.http.connectTimeout = 5000
    com.connecterra.ale.notificationDriver.http.readTimeout = 10000

## Enabling the SNMP Log Handler

WebLogic RFID Edge Server installations support an SNMP Log Handler, which creates SNMP traps from WebLogic RFID Edge Server log event messages and sends them to one or more configured destinations (called trap sinks). Typically, these destinations are SNMP-based Network Management Systems.

The default installation of WebLogic RFID Edge Server does not enable the SNMP Log Handler. To enable it, use the following instructions to edit the `etc/logging.props.edge` file. This file contains Java property definitions that control which log messages are forwarded to which handlers.

1. Add the handler class `com.connecterra.mgmtagent.SNMPLogHandler` to the comma-separated list of handlers in `logging.props.edge`.

    handlers = com.connecterra.mgmtagent.SNMPLogHandler

2. Set the logging level associated with the SNMP Log Handler. We recommend setting the level to either `WARNING` or `SEVERE` to avoid excessive numbers of traps.

    com.connecterra.mgmtagent.SNMPLogHandler.level= WARNING

3. Configure one or more trap sinks as shown below. Each trap sink has a unique name assigned to it, `sink1` in the following example, and up to four configuration properties. The `hostname` property is required; the `port`, `snmpversion`, and `community` properties are optional.

    com.connecterra.mgmtagent.SNMPLogHandler.trapSink.sink1.hostname =
    myMgmtStation.acme.com

    # port is an optional property. The default SNMP UDP port is 162

    com.connecterra.mgmtagent.SNMPLogHandler.trapSink.sink1.port = 162

    # snmpversion specifies the version of the SNMP protocol SNMP traps
    # directed to this trapSink will be encoded in. This is an optional
    # parameter, which if present must be set to either "v1" or "v2c". The
    # default value is "v2c".

    com.connecterra.mgmtagent.SNMPLogHandler.trapSink.sink1.snmpversion = v2c

    # community specifies the community string that appears in SNMP trap
    # messages. This is an optional parameter; its default value is "public"

    com.connecterra.mgmtagent.SNMPLogHandler.trapSink.sink1.community = public

4. Save your changes and restart the Edge Server. When log events of the type(s) specified are generated, SNMP trap information will be sent to the destination(s) you provided.

The MIB files can be found under `share/mibs` in the WebLogic RFID Edge Server installation directory.

## Setting Up the JMS Notification Driver

To use the JMS notification driver, you edit various WebLogic RFID Edge Server configuration files to include JMS specifications, which is covered in this section. In addition, you set up a Java Naming and Directory Interface (JNDI) provider and JMS server, which is covered in Setting Up the JNDI Provider and JMS Server.

To use the JMS notification driver, edit the following Edge Server configuration files:

- `RFID_EDGE_HOME/etc/edge.props` (see `edge.props`)
- `RFID_EDGE_HOME/etc/jms.options` (see `jms.options`)
- `RFID_EDGE_HOME/etc/naming.props` (see naming.props)

### edge.props

Find the notification driver properties, and under the property `com.connecterra.ale.notificationDriver` (shortened to `ND` in the following example), edit the JMS notification driver properties as follows.

1. Find and uncomment the ND.jms.class line.

    com.connecterra.ale.notificationDriver.jms.class = com.connecterra.ale.notifytypes.JMSNotificationDriver

2. Find and uncomment the `ND.jms.default.namingPropertiesFile` line, then set it to the file name of the JNDI naming properties file. The file name may include either an absolute path or a path relative to the location of `edge.props`.

    com.connecterra.ale.notificationDriver.jms.default.namingPropertiesFile = /bea/rfid_edge20/etc/naming.props

See naming.props.

3. Find the `ND.jms.default.namingInitialContextClass` line. Setting this optional property configures the JMS Driver to use the specified class to perform JNDI lookups. The value of this class must be a valid Java class that is available in the system classpath. The value defaults to `javax.naming.InitialContext`, which is used when this property is not specified. Other values for this class are:

    javax.naming.directory.InitialDirContext

    javax.naming.ldap.InitialLdapContext

See the Javadoc for these classes when deciding which class to use.

### jms.options

Edit the `JMS_LIB` environment variable to indicate the location of the JAR and ZIP files provided by your JMS vendor that provide the naming context factory class (as you previously specified in `edge.props`) and all other classes required by JMS clients for your JMS vendor's implementation. Vendor-specific samples of JMS options are in `samples/JMSSamples`.

The exact convention for setting this environment variable depends on your operating system and shell environment.

- Windows example: `set JMS_LIB=d:\programs\libraries\jmsclientlib.jar`
- UNIX example: `JMS_LIB=/opt/lib/jmsclientlib.jar`

For WebLogic Server, `JMS_LIB` must contain the location of `wljmsclient.jar`; `wlclient.jar` must also be in the same path. These files are normally installed in the WebLogic Server product installation directory (`WL_HOME`) in `WL_HOME/server/lib`; for example, in /bea/weblogic91/server/lib. An alternative is to add both jars to the CLASSPATH.

### naming.props

The naming properties file is used to initialize the instance of the javax.naming.Context class. The names and values of the properties specified in the file are used as Context environment properties, as with, for example, the properties from the BEA `naming.props` file:

    java.naming.provider.url=t3://localhost:7001
    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory

You will need to create this file in the `RFID_EDGE_HOME`/etc directory. You can copy a sample file from the vendor-specific examples located in:

    RFID_EDGE_HOME/samples/JMSSamples/<vendor_name>/etc.

To create a naming properties file:

1. Copy a `naming.props` file from the appropriate `JMSSamples/<vendor_name>/etc` directory to the `RFID_EDGE_HOME`/etc directory. (You do not have to name the copy of the file `naming.props`. What matters is that the file name you use matches the value you set for the `namingPropertiesFile` property in the next step.)
2. Specify the file name as the value for the following property in `edge.props`:

    com.connecterra.ale.notificationDriver.jms.default.namingPropertiesFile

For example, if you copy the BEA `naming.props` file to `etc/naming.props.BEA`, the `edge.props` entry would be:

    com.connecterra.ale.notificationDriver.jms.default.namingPropertiesFile = ../etc/naming.props.BEA

Note: | The properties in a naming properties file are considered default values, and can be overridden by a notification subscription URI (by adding the equivalent property to the notification URI as a query parameter). See Programming with the ALE and ALEPC APIs for instructions on overriding these properties.

## Setting Up the JNDI Provider and JMS Server

To use WebLogic RFID Edge Server's JMS notification driver, you need to set up the following components in your environment:

- Java Naming and Directory Interface (JNDI)

The WebLogic RFID Edge Server JMS notification driver in the Edge Server uses the JNDI provider to obtain the necessary JMS objects for sending JMS messages. Examples of JNDI providers include:

- LDAP provider
- File system provider
- JNDI provider built into an application server

You will have to configure the JNDI provider with a connection factory and queue name along with their corresponding JMS objects. Each vendor provides administrative tools for administering JMS objects.

- JMS server

You need to configure the JMS server with the appropriate destinations: queue or topic. Each vendor provides administrative tools for configuring the JMS server.

The following sections include configuration instructions for the following vendors:

- BEA® WebLogic Server® Configuration
- IBM WebSphere Configuration
- JBoss Application Server Configuration
- Sun Java System Application Server Configuration
- TIBCO Enterprise for JMS Configuration

### BEA® WebLogic Server® Configuration

Use the BEA WebLogic Server Administration Console (for example, `http://<wlhost>:7001/console`) to configure the JNDI provider and JMS server.

For example, use the following Administration Console page flows:

- Configure JMS Server:

Services, JMS, Servers, Configure a New JMS Server

Create a JMS server. Example: `jms_server1`

For information on configuring JMS in WebLogic Server 9.x, see Configuring and Managing WebLogic JMS.

- Configure JNDI Provider:

Services, JMS, Servers, `jms_server1`, Configure Destinations, Configure a new JMS Queue

Create a new queue with name (example: `TestQ`) and JNDI name (example: `jms/TestQ`)

Note that BEA provides `weblogic.jms.ConnectionFactory` and`weblogic.jms.XAConnectionFactory` as default connection factories.

For information on WebLogic JNDI, see Programming WebLogic JNDI.

For additional information, see the WebLogic Server System Administration Documentation:

- For 8.1, see: http://download.oracle.com/docs/cd/E13222_01/wls/docs81/admin.html
- For 9.x, see: http://download.oracle.com/docs/cd/E13222_01/wls/docs91/admin.html

### IBM WebSphere Configuration

- WebSphere Application Server with Embedded Messaging Configuration
- WebSphere Application Server with Full WebSphere MQ Configuration
- WebSphere MQ Stand-alone Configuration
- Additional IBM Product Information

#### WebSphere Application Server with Embedded Messaging Configuration

Use the WebSphere Application Server Administration Console (for example: `http://<was_host>:9090/admin`) to configure the Internal JMS Server and to configure a listener port.

For example, use the following Administration Console page flows:

- Configure Internal JMS Server:

Servers, Application Servers, `server1`, Server Components, JMS Servers

Add queue name (example: `TestQ`)

- Configure Listener Port:

Servers, Application Servers, `server1`, Message Listener Service, Listener Ports, New

Specify Listener Port Name (for example: `JMSTestListener`)

Specify Connection Factory JNDI name (for example: `jms/TestQCF`)

Specify Destination JNDI name (for example: `jms/TestQ`)

- Configure WebSphere JMS Provider:

Resources, WebSphere JMS Provider, WebSphere Queue ConnectionFactories, New, Create an object for ConnectionFactory "TestQCF" with JNDI name "jms/TestQCF".

Resources, WebSphere JMS Provider, WebSphere Queue Destinations, New, Create an object for Queue "TestQ" with JNDI name "jms/TestQ".

- Apply Changes to Master Configuration:

Click on Save link and then Save button to apply changes to master configuration.

- Restart Application Server:

Stop the application server and then start the application server to utilize the saved master configuration.

#### WebSphere Application Server with Full WebSphere MQ Configuration

Use the WebSphere Application Server Administration Console (for example: `http://<was_host>:9090/admin`) to configure a listener port.

For example, use the following Administration Console page flows:

- Configure Listener Port:

Servers, Application Servers, `server1`, Message Listener Service, Listener Ports, New

Specify Listener Port Name (for example: `MQJMSTestListener`)

Specify Connection Factory JNDI name (for example: `jms/MQTestQCF`)

Specify Destination JNDI name (for example: `jms/MQTestQ`)

- Apply Changes to Master Configuration:

Click on Save link and then Save button to apply changes to master configuration.

- Restart Application Server:

Stop the application server and then start the application server to utilize the saved master configuration.

#### WebSphere MQ Stand-alone Configuration

Use the WebSphere MQ Explorer to create a queue manager (for example:`QM_host1`) and to create a queue (for example: `MQ_JMS_Q`) under the queue manager.

Use the JMSAdmin tool to define connection factories and queues.

- Update `JMSAdmin.config` file with appropriate values for `INITIAL_CONTEXT_FACTORY` and `PROVIDER_URL` environment variables.
- Update JMSAdmin script to set and use the classpath with the JAR files in `Java/bin` of the WebSphere MQ installation directory.

For example, use the JMSAdmin tool to define a connection factory with JNDI name of `jms/MQTestQCF` and a queue with JNDI name of `jms/MQTestQ` as follows:

    InitCtx> define qcf(jms/MQTestQCF) qmgr(QM_host1)

    InitCtx> define q(jms/MQTestQ) qmgr(QM_host1) queue(MQ_JMS_Q)

#### Additional IBM Product Information

For additional information, see the IBM Product Publications:

    http://www.ibm.com/support/publications/us/

The following publications are recommended:

- IBM WebSphere Application Server and WebSphere MQ Family Integration Redbook (SG24-6878)

    http://www.redbooks.ibm.com/abstracts/sg246878.html

- IBM WebSphere Application Server, Version 5.1: Getting Started (SC31-6323)

    http://publibfp.boulder.ibm.com/epubs/pdf/c3163231.pdf

- IBM WebSphere MQ: Using Java:

    http://publibfp.boulder.ibm.com/epubs/pdf/csqzaw12.pdf

- IBM Tivoli Directory Server: Administration Guide. Links to Tivoli product documentation are available at:

    http://www-306.ibm.com/software/tivoli/products/directory-server/

### JBoss Application Server Configuration

JBoss provides a default connection factory (with JNDI name of `ConnectionFactory`) which can be leveraged without any additional JNDI configuration.

For EJBs (Message Driven Beans configured to receive JMS messages) deployed in the JBoss application server, the JBoss-specific EJB deployment descriptor (`jboss.xml`) contains the destination JNDI name (example: `TestQ`) to be configured. Note that JBoss automatically configures the destination JNDI name in the "queue" JNDI context for queues (example: `queue/TestQ`) or "topic" JNDI context for topics (example: `topic/TestTopic`).

For more advanced JMS or JNDI configurations, use the JBoss JMX administrative console (example: `http://<jboss_host>:8080/jmx-console`) to configure the JMS server and JNDI provider.

For more information, see the JBoss Administration and Development Documentation:

    http://jboss.org/docs/index

### Sun Java System Application Server Configuration

Use the Application Server Admin Console (example: `http://<sun_host>:4848/asadmin`) to configure the JNDI provider and JMS server.

For example, use the following Administration Console page flows:

- Configure JMS Server and JNDI Settings:

Java Message Service, JMS Hosts

Java Message Service, Connection Factories, New

Create a new connection factory with JNDI name (example: `jms/TestQCF`), type of `javax.jms.QueueConnectionFactory`, and resource enabled.

Java Message Service, Physical Destinations, New

Create a new physical destination with name (example: `PhysicalQueue`) and type of queue.

Java Message Service, Destination Resources, New

Create a new connection factory with JNDI name (example: `jms/TestQ`), type of `javax.jms.Queue`, and resource enabled.

Add additional property called Name with value of `PhysicalQueue`.

- Restart Application Server:

Stop the application server and then start the application server to utilize the new configuration.

For additional information, see the Sun Java System Application Server Administration Guide. The Platform Edition 8.2 manual is available at:

    http://docs.sun.com/app/docs/doc/819-4712

### TIBCO Enterprise for JMS Configuration

Use the JMS Administration Tool to create JMS connection factories and queues.

For example, after starting the JMS Server, use the JMS Administration Tool to define a connection factory with JNDI name of `TestQCF` and a queue with JNDI name of `TestQ` as follows:

    > connect host1:7222

    tcp://host1:7222> create factory TestQCF queue
    tcp://host1:7222> create queue TestQ

For additional information, see the TIBCO Enterprise for JMS User's Guide, located in the installation directory of TIBCO Enterprise for JMS:

    JMS/doc/pdf/tib_jms_users_guide.pdf

## What's Next: Developing for the ALE and ALEPC APIs

You can now start your own application development, using the ALE API. For complete reference information, sample applications, and code walkthroughs, see Programming with the ALE and ALEPC APIs.