|Return to Main Contents
ShowTable of Contents
APPENDIX A Custom Setup
Expeditor integrator Sample Configuration File
An example of the XPDinteg.xml file is provided with the delivered Expeditor integrator runtime under <XPDINTEG_HOME>/config.
Collection of Setup Information
This is as suggestion of a sheet where Expeditor integrator specific installation data can be kept.
Table: Expeditor integrator custom configuration values
Set-up Steps for a manual Expeditor integrator installation
|Parameter Name||Configure Value||Comment / Test result|
|LocationID||<location_ID>||Unique ID of each Store Server (value is carried in each message for routing purposes)|
|Back-end MQ Server / Message Broker Configuration|
|AI Message Broker Hostname : Port and IP Address||msgBroker.ibm.com 14103||Ping & Telnet successfully / unsuccessful|
|Queue-Manager, MQGR||MQSD.IBMEN0||Queue manager of back-end MQ Server|
|Port||14103||Port of queue manager|
|Channel||SYSTEM.DEF.SVRCONN||Used MQ Channel|
|ReqOutQx||STXPD.ReqOutQ100||ReqOutQx: queue that contains all messages FOR store server x (queue depth=100000)|
|ResInQx||STXPD.ResInQ100||ResInQx: queue that retrieves all messages FROM store server x|
|CtrlOutQx||STXPD.CtrlQ100||CtrlOutQx: queue that contains control messages for the store server x|
|Common queues that receive messages from all store servers|
|MQ Username / Password||(n.a.)||Can be the local Windows user account under which Expeditor integrator is running|
|microbrokerCleanStart (=false)||false||This indicates whether the micro broker instance creates all queues and the Bridge (old messages and settings are discarded). This should be set to TRUE when a configuration update to the micro broker / -bridge occurred.|
|Local communication port of the micro broker (make sure this is not blocked by any local Firewall).|
|micro broker max message size in KB|
|Local directory where the micro broker stores its queue content persistently (should by backed up)|
|Max size of the internal micro broker objects in KB|
|micro broker Log size in KB|
|JndiInitialContextFactory= com.ibm.pvc.jndi.provider.java. InitialContextFactory||com.ibm.pvc.jndi.provider. java.InitialContextFactory||Name of the class that provides the Initial Context Factory|
|JndiURL=local||local||Local of the JNDI (in the future, configuration information could be provided in a centrally managed JNDI)|
|Expeditor integrator Standard Configuration|
|Hostname of the Store Server|
|Full-qualified domain name|
|IP Address of the Store Server|
|Provide the subnet mask as well|
|User account under which the Expeditor integrator is running|
|Might be the same as the MQ Username / Pwd|
|User account under which the Expeditor integrator is registered as Windows Service||System account (that is allowed to log to console)||The registered Windows Service needs to be started with this user account.|
|Directory for the Expeditor integrator|
|is the @nowiki@3variable|
<XPDINTEG_HOME> contains enough disk space
|- for Runtime: 250 MB||150 MB for pure Runtime
100 MB for the temporary storage of the messages in the File System
|FTP Server Default Configuration|
|4690EL and FTP Server name|
|as Full-qualified Domain Name|
|4690EL and FTP Server IP address|
|FTP User / Password||1 / 1||This user needs read and write access to the appropriate directories|
|FTP Timeout value||n.a.||In milliseconds. Should be set pretty high so that connection losses between the Expeditor integrator and the FTP Server are minimized|
|FTP Type||4690||The type of FTP server  | [DEFAULT]|
|List of FTP directories for READ access||/IBM||This directories will be read by the Expeditor integrator|
|List of FTP directories for WRITE access||/IBM||Expeditor integrator needs write access|
|File System Access Configuration|
|User account: File system access rights for the account under which the Expeditor integrator is running||LocalSystem, local Administrator||Make sure that the Expeditor integrator user account has read and write access to the target and source directories for the file transfer|
|List of directories that need READ access||c:\xpd||Directories that are read by the Expeditor integrator|
|List of directories that need WRITE access||c:\xpd||Directories that are written by the Expeditor integrator|
|Transaction Service Configuration|
|Location of the transaction log file|
|Size of the transaction log file in KB|
|trace level for the transaction log|
|Custom Log Service|
|This is the log level of a created log entry which triggers that the log entry is placed in a message and forwarded to the Monitoring System. This can be configured by administrator and stored in the Configuration Store.
1 = Error, 2 = Warning, 3 = Info, 4 = Debug
|monitoringBundles=com.ibm. integrator.app.customconfigservice, com.ibm.lbsbb.XPDINTEG.app.queuedispatchersvc, com.ibm.integrator.app.customeventservice, com.ibm.integrator.app.transactionservice, com.ibm.integrator.app.sacsvc, com.ibm.integrator.app.resoucemonitorsvc, com.ibm.integrator.app.resourceadapters, com.ibm.integrator.app.sacactivities|
|Comma-separated list of bundle names of which the log events are monitored. When the bundles in this list reach the states specified below, the CustomLogSvc needs to send this information to the LogQ of the Monitoring System|
|Comma-separated status numbers.that trigger a bundle status change to be forwarded (send as a message)
32 - The bundle has been resolved
2 - The bundle has been started
4 - The bundle has been stopped
When the bundles in the above list reach these specific states, the CustomLogSvc needs to send this information to the LogQ of the Monitoring System
|Expeditor integrator Tivoli Monitor Service (iTMS)|
|TecTransportType||LCF||Type of transport: |
SOCKET: Events sent directly to the TEC Console |
LCF: Events sent via the local Tivoli Endpoint
DISABLE: service is not used
|#TecServerLocation||<tec-server-name.yourco.com>||n.a. for LCF|
(Name of the host where the TEC server is running. This is a required parameter only if TecTransportType is SOCKET)
|#TecServerPort||5529||n.a. for LCF|
(Port number on which the TEC server is listening. This is an optional parameter. The default value is 5529, if no value is specified.)
|TecEventMaxSize||4||Maximum length of TEC event messages in KBytes. This is an optional parameter|
|TecBufEvtPath||persistent/tec/tivoli.send.cache||Specifies the full path name of the cache file. The EIF events are stored temporarily in this file if connection to TEC is unavailable and later sent when the connection is available. This is a required parameter.|
|TecSpaceReplacement||TRUE||Optional parameter. When SpaceReplacement is…
- FALSE: any spaces in the subsource field of the event log messages are left unchanged.
- TRUE: any spaces in the subsource field of the event log messages are replaced with underscores (_). The default is FALSE.
|itmsTopicList||com/ibm/integrator/SxpdApplStatusEvent||List of topics of the OSGi Event Admin service events that are captured by this service|
|Optional parameter which specifies the full path name of the trace file.|
|TecTraceLevel||DEFAULT||Optional parameter that specifies whether the application generates trace messages or not.
DEFAULT: no messages are generated |
ALL: generate messages |
any other value or no value: trace messages are not generated.
|Optional parameter that specifies the full path name of the log file.|
|TecLogLevel||DEFAULT||Optional parameter which specifies whether log messages are generated or not.
DEFAULT: no messages are generated |
ALL: generate messages |
any other value or no value: messages are not generated
- Install the Expeditor integrator
- Copy, unzip, and adjust paths XPDinteg-retail_v20 package
- Configure the XPDintegTT
- Test access to back-end Message Broker with XPDintegTT
- Configure the Expeditor integrator
- Edit the XPDinteg.xml file
- Adjust the MQ Server settings
- Servername, port, queue manager name, queue names
- Edit target FTP Server settings (4690)
- IP address, port, passive mode, 4690 type, username, password, target files and directories
- Use the PasswordUtil utility for FTP password creation
- Target directory and filenames
- Flow file directory polling interval
- Configure Flow files (use only one)
- Prepare sample files and target directories
- Run resetscript/XPDintegReset.bat
- Install Expeditor integrator as Windows Service
- Run XPDintegStart.bat or start Windows Service
APPENDIX B Technical Details
Importing Expeditor integrator Event Classes into Tivoli Enterprise Console
The following steps explain how the provided XPDINTEG event classes can be enabled in the Tivoli Enterprise Console (TEC) v4.1:
- Make sure the Tivoli Services are running, e.g. Tivoli Object Dispatcher and Tivoli Remote Execution Service
- Start Tivoli Desktop and make sure that the EventServer is running (Click on EventServer with right mouse button and choose Start-up.)
- Bring up the Rule Bases (Click on EventServer with right mouse button and choose Rule Bases…)
- Create a new Rule Base: Create | Rule Base. Provide a name and select a directory where the rule configuration is saved, e.g.
Name = XPDinteg
Directory = backbone-service-bus:C:/Development/tec_rules
- After creating the Rule Base, import the XPDinteg.baroc file into the XPDinteg Rule Base (The XPDinteg.baroc baroc file is provided with each XPDinteg runtime under <XPDINTEG_HOME>/config/tecserverfile)
- Right click on the created new Rule Base (e.g. XPDinteg Rule Base), go to Class Definitions area and check the Import Class Definitions check box. In the Directory Path area, click on File and select the baroc file, e.g.
Directory Path = backbone-service-bus:C:/user/XPDinteg.baroc
- Make sure that Insert After is selected in the Position to insert imported class file area. Click Import & Close.
- Compile the XPDinteg Rule Base: Right click on the XPDinteg Rule Bases and select Compile…
- Load the XPDinteg Rule Base: Right click and select Load… Select Load and activate the rule base.
- Quit the Tivoli Enterprise Console and Tivoli Desktop (Depending to the operating system, the services may need to be re-started to activate the new classes.)
Tivoli Endpoint Installation and Configuration Example
Finally, a Tivoli Endpoint that is used to connect from the Expeditor integrator server to the TEC must be installed and configured.
- Make sure that the Tivoli Enterprise Console is up on the TEC Server before installing the endpoint.
- If TEC is not started, Tivoli Desktop-> EventServer: Right click and select Start-up.
- Start the Endpoint installation: 411LCF46\LCF\WINNT\SETUP.EXE
- The Endpoint can be downloaded from (Please, double check the Tivoli Support Web Site for the latest recommended Endpoint Version (e.g. March 2010: 431LCF04LA)):
e.g. for version 4.3.1: ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_4.3.1/4.3.1-LCF-0002/4.3.1-LCF-0002.tar
(or alternatively 431LCF04LA.zip)
- The license agreement screen will be displayed. Click Yes to accept the agreement.
- The following window describes what accounts should be created and what permissions should be set in order to ensure the proper operation of the software. Click Next to continue.
- Choose the destination folder. Click Next to continue.
- The next panel asks for the Remote Access user ID and password. As this was not specified during the IBM Tivoli Management Framework installation, we do not enter any value. Click Next to continue.
- The Advanced Settings window is now displayed. In this panel, you should specify the following:
- The Endpoint Gateway communication port. Default to 9494.
- The Endpoint communication port. Default to 9495.
- In the Options box, the login interfaces to the Endpoint Gateway:
-D lcs.login_interfaces=<Endpoint_GW_IPADDR>+port, where
<Endpoint_GW_IPADDR> is the Endpoint gateway IP address and port is the communication port specified in the Gateway port box.
In our case, use -D lcs.login_interfaces=184.108.40.206+9494
- Click Next to continue.
Figure 42: Advanced settings for Tivoli Endpoint
- Review the installation settings, and click Next to start the installation.
- When the installation completes, the Endpoint tries to log on to the Endpoint gateway using the information provided in the Advanced Configuration panel (“Waiting to see if login to gateway successful…”)
- If successful, you will see the message: “Gateway login successful”.
- Press Next and Finish to complete the installation process (reboot the machine).
The following command can be executed in console window on the Tivoli Endpoint server (TEC) to check whether the created Endpoint has successfully connected :
…displays the status of all enrolled Endpoints. The installed Endpoint should be in status connected.
…displays the installed product versions and patch levels on the server.
If connection problems occure, please double check the lcfd.log file under the Tivoli Endpoint DAT directory (e.g. C:\Program Files\Tivoli\lcf\dat\1). The trace level can be increased in the last.cfg file in the same directory. Connectivity problems may also be handled by adding this statement to the last.cfg file:
Manual Configuration steps after installing the endpoint:
(see Figure 42).
If the TecLcfUtil tool is NOT available (default path: <XPDINTEG_HOME>/tools/XPDintegTools), the environment can also be set-up manually. Follow these configuration steps to enable sending EIF Events from the Expeditor integrator to TEC Console through the Tivoli Endpoint:
- After installing the Endpoint, the environment(System) variables corresponding to the following file needs to be set in WINDOWS (if instance 1 of the Tivoli Endpoint is used):
- Listing 65 shows a sample lcf_env.cmd file content:
Regarding to Listing 65 the following Windows System environment variables must be added (System Variables are created under Windows System Properties | Advanced | Environment Variables):
LCFROOT=C:\Program Files\Tivoli\lcf LCF_INSTANCE=1
Furthermore, the following values must be appended to the following existing Windows System environment variables:
Listing 65: Sample lcf_env.cmd file
REM Licensed Materials - Property of IBM
REM (C) Copyright IBM Corp. 1994, 2005 All Rights Reserved
REM US Government Users Restricted Rights - Use, duplication or
REM disclosure restricted by GSA ADP Schedule Contract with
REM IBM Corp
rem Generated at lcf install time
if not "%LCF_BINDIR%" == "" goto END_ENV
set LCFROOT=C:\Program Files\Tivoli\lcf
set LCF_DATDIR=C:\Program Files\Tivoli\lcf\dat\1
echo Tivoli LCF environment variables configured.
- Also, the Windows Environmental variable Path needs to be appended with the directory containing the following DLLs from TEC (e.g. <XPDINTEG_HOME>\tools\tec)
- libteceif.dll, libtecgw.dll, teclcf.dll (can be simply copied to the Expeditor integrator server )
- These DLLs are a part of the 3.9.0-TEC-FP05-NON_TME-EIF.tar.gz and can be downloaded from ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_3.9.0/3.9.0-TEC-FP05/
- These DLLs are also provided with the Expeditor integrator package in the <XPDINTEG_HOME>/tools/tec directory.
Configuring SSL for the Lotus Expeditor Client Web Container
This chapter contains the required steps to enable SSL for the WebContainer which is shipped with IBM Lotus Expeditor client for Desktops.
Per default, the Expeditor integrator Service/Daemon uses the XPDintegServiceServlet for handling platform start/stop/restart requests. It is only accessible throught SSL port of the Webcontainer which is, therefore, always available per default (on default port 8778). Default key- and trustStore files are in folder /config/system/ssl.
The active Webcontainer configuration is stored during runtime in
These default settings are provided in
The following chapters show the steps which are required changing the Webcontainer SSL settings of Expeditor integrator in case this is required
The following steps need to be followed on the Expeditor integrator client:
Create KeyStore and TrustStore files
- You can create files using keytool, a command-line utility that comes with JRE.
- Run the following commands for Creating the key store
- <JRE>\bin\ keytool.exe –genkey -alias <alias for the key> -keypass <password for the private key> –keystore <keystore path> -storepass <password for the keystore>
E.g.: <JRE>\bin\ keytool.exe -genkey -alias store102Key –keypass password -keystore keyStore102.jks -storepass password
- Fill the details needed when prompted for. keyStore102.jks file is created in the bin directory.
Figure 43: Creating the Key Store for Expeditor Client
- Run the following command for Creating the trust store
- <JRE>\bin\ keytool.exe –genkey -alias <alias for the key> -keypass <password for the private key> – keystore <truststore path> -storepass <password for the truststore>
<JRE>\bin\ keytool.exe –genkey -alias store102TrustKey -keypass password keystore trustStore102.jks -storepass password
- Fill the details needed when prompted for. trustStore102.jks file is created in the bin directory.
Figure 44: Create the Trust Store for Expeditor Client
- Export certificate to the JRE KeyStore
- Execute the following commands:
Figure 45: Export certificate to JRE Key Store
Figure 46: Creating key store
The password for the JRE keystore “cacerts” is “changeit” (by default).
SSL Configuration file
- Create a text file with SSL configuration properties. i.e. ssl_config.txt (E.g.: under <XPDINTEG_HOME>/config/system/ssl). The configuration properties can be chosen from the list of properties given in the table.
If the access to th web UI should be secured by SSL and client authentication is not required (browser does not need to provide an according certificate) it's recommended to leave the SSL configuration for port 8778 to the default settings and to configure an additional SSL port with according settings. This is done, by specifying the port number after the according SSL configuration property
Table 52: SSL configuration properties for Expeditor Client WebContainer
SSL [default], SSLv3, TLS, TLSv1
Specifies the protocol to use
SSO-KS [default], PKCS12
Specifies the type of keyStore to use
Absolute or relative path to file on the file system. If relative path is specified, path must be relative to the current working directory.
Specifies the location of keyStore on the file system
SSO-KS [default], PKCS12
Specifies the type of trustStore
Absolute or relative path to file on the file system. If relative path is specified, path must be relative to the current working directory.
Specifies the location of trustStore on the file system
Plain-text password for keyStore
Specifies the password to open the keyStore
Plain-text password for trustStore
Specifies the password to open trustStore
true | false
Specifies whether or not the client application requires authentication. The default is false.
2. Set the system property com.ibm.pvc.webcontainer.ssl.configfile to point to the SSL configuration file created in (a)
3. Set the HTTPS port using the system property com.ibm.pvc.webcontainer.port.secure.
The Web Container will only secure requests if the HTTPS port is set and the SSL configuration file is supplied to the Web Container. If the port is not set, the Web Container will default to running the requests on the HTTP port. If an additonal SSL port is configured for the webcontainer, all SSL ports need to be speciied in brackets and comma-separated (e.g. [8778,9001].
4. Copy the truststore and KeyStore files - keyStore102.jks and trustStore102.jks to <XPDINTEG_HOME>/config/system/ssl
5. An example ssl_config.txt
file, when configured with secured port
, will look like the one in the following Listing. It is recommended to keep the SSL configuration on port 8778
for default reasons and to configure an additional port for custom Web container applications.
Listing 66: Example ssl_config.txt with additional recommended SSL port
The rcpinstall.properties file will have these lines added:
Listing 67: Expeditor WebContainer configuration in rcpinstall.properties
#Web Container Configuration
#To disable listener on HTTP port(use only HTTPS)– set this property to -1
#SSL for webcontainer
6. If the client (e.g. the XPDintegTT) accessing the WebContainer is running on a different JRE, import the certificate into the JRE the WebContainer is running on.
Figure 47: Import the certificate
Refer the Info Center link for more information on this:
Note: The WebContainer copies the properties in the ssl_config.txt file to <XPDINTEG_HOME>/workspace/.config/webcontainer.properties and deletes the ssl_config.txt file.
Logs and Traces
General Webcontainer tracing can be enabled with the steps given in chapter Enable Expeditor Webcontainer tracing.
The SSL handshake routine can be debugged by setting this flag:
-Djavax.net.debug=ssl,handshake in the
/ rcp/eclipse/plugins/com.ibm.rcp.j2se.linux.x86_/jvm.properties file
Using the micro broker trace utility (MBtrace)
IBM Lotus Expeditor integrator is shipped with a trace facility for its internal messaging provider (IBM micro broker) to allow creation of detailed support information in case of messaging related problems. The micro broker trace utility (MBtrace) is included in the /tools/XPDintegTools.zip and can be executed under the supported operating systems Windows and Linux.
The MBtrace tool is configured and started outside of Expeditor integrator and creates detailed information for IBM’s support.
The following information gives an overview of the available configuration parameters. Most up to date information and configuration is provided on IBM’s support web site. It is strongly recommended to consult this information when the MBtrace tool needs to be used (see Expeditor integrator Wiki).
- Unzip the XPDintegTools.zip into folder with the same name (e.g. \tools\XPDintegTools).
- Configure the MBTrace.properties file. The following configuration options are available:
Table 53: MBtrace tool configuration options
|Property||Description||Comment / Test result|
|mbserverip||IP address of the server on which microbroker is running||localhost|
|mbserverport||Port on which the microbroker server is running||1883|
|userid||User name used to logon to the microbroker server||Admin|
|password||Password used to logon to the microbroker server||Admin|
|tracelevel||Microbroker trace level||TRACE_LEVEL_MAX
Additional values are:
TRACE_LEVEL_MIN, TRACE_LEVEL_LVL1, TRACE_LEVEL_LVL2, TRACE_LEVEL_LVL3, TRACE_LEVEL_LVL4, TRACE_LEVEL_LVL5
|tracelocation||Absolute or relative path where trace files should be stored||../../persistent/microbroker/traces
The entire path (but the last folder name) should be pre-existing. The last folder would be created if not already present. If the last folder already exists, all files inside it will be deleted.
|traceinterval||Time interval in milliseconds after which traces should be captured from the buffer ||900000
(= every 15 minutes)
|tracecaptureduration||Duration for which the tool will continue to capture traces at regular intervals as specified by the traceinterval. The tool will exit on completion of this duration.||172800000
(= 48 hours)
- Launch the micro broker Trace Utility. Start Expeditor integrator and subsequently execute the MBtrace.bat (or MBtrace.sh on Linux) once the integrator OSGi console appears (The batch file may be found in the \tools\XPDintegTools directory.).
- After problem determination run these command to create a dump (run more than once):
Listing 68: OSGi console commands for creating dumps using the MBtrace tool
Operating a second Expeditor integrator instance on the same server
Since Lotus Expeditor integrator uses local IP ports for its operation, the additional instance must be configured with different port settings.
Note: Unfortunately, the automatic service start-up can only be attached to one instance.
Follow these extra configuration steps on additional Expeditor integrator instances:
1. The Expeditor integrator Webcontainer IP ports (default 8777, 8778, 8780) must be changed to free local ports (e.g. to 9777, 9778, 9780) in the following files:
2. Adjust the path variables in Expeditor integrator scripts. An easy way to achieve this is to run the following command in the installation folder of the second instance (e.g. /opt/ibm/lotus/Integrator_2
>sudo grep -lr / . | xargs sed -i 's/\/Integrator\//\/Integrator_2\//g'
This uses the sed
command to replace all occurrences of “/Integrator/” with “/Integrator_2/” where all “/” of the sed argument need to be escaped with a “\”. (e.g. “/opt/ibm/” would become “\/opt\/ibm\/”).
3. Change the Messaging Service (micro broker) in the Expeditor integrator configuration file (XPDinteg.xml
- Change the name and the port number for micro broker in Section_2: MESSAGING SERVICE (check whether port 2883 is locally available):
Listing 69: Configure micro broker name and port in XPDinteg.xml for additional Expeditor integrator instance
<!-- INTERNAL Settings - Please, do only change if you know what you are doing! -->
FTP connection issue on Red Hat Enterprise Linux
When Expeditor Integrator is installed on a host running Red Hat Enterprise Linux and Integrator is using FTP resource adapters, exceptions might occur when using FTP passive mode.
This is related to the firewall settings on Red Hat Enterprise Linux which prevents the system from opening the required ports for passive FTP communication. By stopping the firewall (e.g. stopping the iptables service) this issue won’t occur.
Instead of stopping the hosts firewall, it is recommended to add the module “ip_conntrack_ftp” to the iptables configuration which takes care of the required ports for communication with the FTP server.
Please follow these steps to configure the firewall accordingly:
1. Open a terminal and login as superuser (root)
2. This module is included in the standard Red Hat Enterprise Linux installation, anyhow it’s recommended to check if the module can be loaded. Check with “modprobe ip_conntrack_ftp”
3. Back-up the file “/etc/sysconfig/iptables-config” and configure the module at the top section of the file by setting IPTABLES_MODULES=”ip_conntrack_ftp”.
4. Restart the firewall using the command “service iptables restart”. Verify that the module has been loaded successfully by checking the console output (this should be “Loading additional iptables modules: ip_conntrack_ftp [ OK ]”).
APPENDIX C Glossary
· Point-of-Sale (PoS; till) software controller that manages attached PoS systems
· A structure supported by Windows® 2000 that lets any object on a network be tracked and located. Active Directory is the directory service used in Windows 2000 Server and provides the foundation for Windows 2000 distributed networks.
· A software or tool based on a product (e.g. Lotus Expeditor)
· Verifying the identity of a user who is logging on to a computer system or verifying the integrity of a transmitted message.
· Business Use Case
· Is a Java application that implements the required OSGi Framework services so that it can run in and be managed by the OSGi Service Platform (although referred to as OSGi Bundle).
· Expeditor integrator events that describe the status of a local business process or transaction. These events can be forwarded to back-end systems.
· Data Integration Facility (standardizes POS data to support open standards that are compatible with existing and future store systems)
· a hierarchical structure that stores information about objects on the network
· Device Management Service: Component that is provided through IBM’s Access Services. It consists of a server and a client (agent) part. The agent polls the server for device management jobs that it needs to perform (e.g. SW management, configuration, remote control of the Expeditor integrator and it’s platform -> Eclipse). The OMA-DM protocol is used (see http://www.openmobilealliance.org
· Demilitarized Zone: zone between two firewalls that separate the Internet (first firewall) and a secured local network (second firewall) from each other.
· Hierarchical distributed database used for name/address translation and client-server rendezvous.
· Domain Name System is the namespace used on the Internet to translate computer and service names into TCP/IP addresses.
· Active Directory uses DNS as its location service, and so clients find domain controllers via DNS queries.
· Enterprise Application Integration
· Eclipse is an open source community whose projects are focused on providing an extensible application runtime environment on client devices (incl. graphical user interface), a development platform and application frameworks for building software (see www.eclipse.org)
· Event Integration Facility (package contained in Tivoli Enterprise Console, TEC, for creating and sending TEC events).
Global Services Method
· IBM’s project management method. It includes descriptions of best-practices, recommendations and examples as well as templates which can be used to manage a project efficiently.
· A namespace, such as the DNS namespace and the Active Directory namespace that is hierarchically structured and provides rules that allows the namespace to be partitioned. See also namespace.
Java® ME / J2ME
· Java® Micro Edition (Java Standard environment for embedded devices, e.g. gateways, set-top boxes and mobile devices), formerly called Java 2 Micro Edition
· Virtual machine from IBM for Desktop environments that are able to run Java programs
· Java Component Architecture
· Java Transaction Architecture
· Java Naming Domain Interface
· Java Embedded Transaction Container. Transaction container provided in IBM WebSphere Application Server (WAS).
· Java Messaging Service
· A security system that authenticates users. Kerberos doesn’t provide authorization to services or databases; it establishes identity at logon, which is used throughout the session.
· The Kerberos protocol is the primary authentication mechanism in the Windows 200x operating systems.
Lightweight Directory Access Protocol (LDAP)
· A protocol used to access a directory service. LDAP is a simplified version of the Directory Access Protocol (DAP), which is used to gain access to X.500 directories. It is the primary access protocol for Active Directory.
· Standard OSGi Framework event that is fired through the OSGi Event Admin Service when a log entry is created using the OSGi Log Service.
· Application Integration infrastructure: messaging based back-end infrastructure for application integration (enterprise service bus etc.)
· Client component (Access Service) delivered with IBM Lotus Expeditor which provides local JMS services.
· IBM’s messaging protocol and product series.
· Open Mobile Alliance (www.openmobilealliance.org
· OMA® is the focal point for the development of mobile service enabler specifications, which support the creation of interoperable end-to-end mobile services. OMA drives service enabler architectures and open enabler interfaces that are independent of the underlying wireless networks and platforms. OMA creates interoperable mobile data service enablers that work across devices, service providers, operators, networks, and geographies. Toward that end, OMA will develop test specifications, encourage third party tool development, and conduct test activities that allow vendors to test their implementations.
· Consolidation of mobile initiatives like WAP-Forum, SyncML etc.
· OMA Device Management (DM) Working Group: was formed by consolidating the device management activities taking place previously in the former WAP Forum and the former SyncML Initiative.
· The goal of the Device Management Working Group is to specify protocols and mechanisms that achieve management of mobile devices including the necessary configuration to access services and management of the software on mobile devices (see http://www.openmobilealliance.org/tech/wg_committees/dm.html).
· OMA Data Synchronization (DS) Working Group: The goal of the Data Synchronization Working Group is to continue development of specifications for data synchronization, and to develop other similar specifications, including but not limited to SyncML technology. These specifications will include conformance specifications and a set of best practices that describe how to use the data synchronization technology specifications within the OMA Architecture (see http://www.openmobilealliance.org/tech/wg_committees/ds.html
· Open Services Gateway Initiative (standard for a Java application framework especially designed for remote management of applications and devices with limited resources, see http://www.osgi.org
· OSGi platform is one Java instance in which all Java applications (bundles) are running. Management services are standardized and provided (e.g. HTTP services, Servlet container, Log service, Configuration admin etc.). These services help to remotely control, install and configure these bundles. The application control service (Device management agent) is also standardized by the OMA.
· Part of a message that carries custom/user data.
· See public key infrastructure.
· Point-of-Sales that is used for tracking sales transactions (e.g. till in a supermarket)
· Quality of Service
· In database management, the function that keeps distributed databases synchronized by routinely copying the entire database or subsets of the database to other servers in the network. There are several methods of replication, including primary site replication, shared or transferred ownership replication, symmetric replication, (also known as update-anywhere or peer-to-peer replication), and fail over replication.
· Active Directory provides multi-master replication, which is a form of symmetric replication (see multi-master replication).
Software and solution development methodology.
· Expeditor integrator Control Service
· Serial Access parser API for XML that helps reading data from an XML formatted document. Alternative to the Document Object Model (DOM).
· Novell® SuSE® Linux® Enterprise Server
· Service Oriented Architecture
· Simple Object Access Protocol: Protocol which is used in SOA to access objects over standard transport protocols, like HTTP
XPDinteg / Expeditor integrator
· Expeditor integrator is a light-weight integration hub for remote locations (e.g. retail stores). This component integrates the remote (e.g. in-store) processes with back-end systems (XPDinteg).
· The OMA Data Synchronization Working Group continues the work originated in the former SyncML Initiative (see OMA-DS)
· Total Cost of Ownership (full lifecycle view of costs for a solution)
· Single-byte encoding
WebSphere Message Broker
· WebSphere® Process Server: one of IBM’s WebSphere Business Integration products
· IBM® Lotus® Expeditor: IBM middleware which provides most of the Distributed Client Extension Services (Thin and Rich Distributed client extension services)