This chapter details deployment specifications for TIBCO EBX® on a Java application server. For specific information regarding supported application servers and inherent limitations, see Supported environments.
EBX® uses the following components:
Library ebx.jar
EBX® built-in web applications and optional custom web applications
Default user and roles directory, integrated within the EBX® repository, or a third-party system (LDAP, RDBMS) for the user authentication
To increase EBX® independence and interoperability, it embeds its own third-party libraries. Even if some of them have been modified, preventing conflicts, others must remain unchanged since they are official Java APIs.
The ones that can produce conflicts are:
Apache Geronimo JSON
Javax Activation
Javax Annotations
Javax JSON Bind
Javax SAAJ API
Javax WS RS
Javax XML Bind
For more information regarding the versions or the details of the Third-Party Library, please refer to the: TIB_ebx_5.9.17_license.pdf
.
Since those libraries are already integrated, custom web applications should not include them anew, otherwise linkage errors can occur. Furthermore, they should not be deployed aside from the ebx.jar
library for the same reasons.
EBX® requires several third-party Java libraries. These libraries must be deployed and be accessible from the class-loader of ebx.jar
. Depending on the application server and the Java runtime environment being used, these libraries may already be present or may need to be added manually.
The EBX® repository requires a database. Generally, the required driver is configured along with a data source, if one is used. Depending on the database defined in the main configuration file, one of the following drivers is required. Keep in mind that, whichever database you use, the version of the JDBC client driver must be equal to or higher than the version of the database server.
H2 | Version 2.1.210 validated. Note that H2 is not supported in production environments. If the repository has been created using H2 version 1.x, this process must be applied, to migrate to the H2 v2 format. |
Oracle JDBC | Oracle database 12cR2 is validated on their latest patch set update. Determine the driver that should be used according to the database server version and the Java runtime environment version. Download the |
SQL Server JDBC | SQL Server 2012 SP4 and greater, with all corrective and maintenance patches applied, are validated. Remember to use an up-to-date JDBC driver, as some difficulties have been encountered with older versions. Include the |
PostgreSQL | PostgreSQL 9.6 and above validated Include the latest JDBC driver version 4.2 released for your database server and Java runtime environment. |
The library for JavaMail 1.5.6 email management is required.
The following libraries are used by email features in EBX®. See Activating and configuring SMTP and emails for details on the configuration.
javax.mail.jar
, version 1.5.6, from August 10, 2016
smtp.jar
, version 1.5.6, from August 10, 2016
pop3.jar
, version 1.5.6, from August 10, 2016
These libraries are required if your web applications use SSL features.
jsse.jar
: https://www.oracle.com/java/technologies/jsse-v103-for-cdc-v102.html
ibmjsse.jar
: https://www.ibm.com/developerworks/java/jdk/security/
When using JMS, version 1.1 or higher is required.
Depending on whether a Java EE application server or a Servlet/Java Server Pages (JSP) implementation is being used, the library required is as follows:
For an application server based on Java EE (Java Platform Enterprise Edition), the required JMS provider library is available by default. See http://www.oracle.com/technetwork/java/javaee/overview for more information.
For a Servlet/Java Server Pages (JSP) implementation using Java SE (Java Platform Standard Edition), for example Apache Tomcat, a JMS provider library such as Apache ActiveMQ may need to be added. See http://www.oracle.com/technetwork/java/javase/overview for more information.
In EBX®, the supported JMS model is exclusively Point-to-Point (PTP). PTP systems allow working with queues of messages.
A library holding the XML Catalog API, introduces by the JAVA SE 9, is required if your web applications are running over a Java Runtime Environment 8 or below, except when a WebLogic 12c R2 application server is used. To ease the installation steps, the following library has been bundled aside from ebx.jar
, in the EBX® CD.
xml-apis-1.4.01.jar
, version 1.4.01, from August 20, 2011
See Installation notes for more information.
EBX® provides pre-packaged EARs that can be deployed directly if your company has no custom EBX® module web applications to add. If deploying custom web applications as EBX® modules, it is recommended to rebuild an EAR containing the custom modules packaged at the same level as the built-in web applications.
Web application deployment on /
path context is no more supported. The path context must not be empty nor equals to /
. Moreover, web applications deployment on paths of different depth is deprecated. Every web application path context must be set on the same path depth.
For more information, see the note on repackaging the EBX® EAR at the end of this chapter.
EBX® includes the following built-in web applications.
Web application name | Description | Required |
---|---|---|
| EBX® entry point, which handles the initialization on start up. See Deployment details for more information. | Yes |
| EBX® root web application. Any application that uses EBX® requires the root web application to be deployed. | Yes |
| EBX® user interface web application. | Yes |
| EBX® user interface web application. | Yes |
| EBX® data model assistant, which helps with the creation of data models through the user interface. Note: The data model assistant requires the | Yes |
| EBX® data services web application. Data services allow external interactions with the EBX® repository using the SOAP operations and Web Services Description Language WSDL generation standards or using the Built-in RESTful services. Note: The EBX® web service generator requires the deployment of the | Yes |
It is possible to extend and customize the behavior of EBX® by deploying custom web applications which conform to the EBX® module requirements.
This section describes the various options available to deploy the 'ebx
' web application. These options are available in its deployment descriptor (WEB-INF/web.xml
) and are complemented by the properties defined in the main configuration file.
For JBoss application servers, any unused resources must be removed from the WEB-INF/web.xml
deployment descriptor.
The web application 'ebx
' (packaged as ebx.war
) contains the servlet FrontServlet
, which handles the initialization and serves as the sole user interface entry point for the EBX® web tools.
In the file WEB-INF/web.xml
of the web application 'ebx
', the following elements must be configured for FrontServlet
:
| To ensure that |
|
|
FrontServlet
must be authorized to access other contexts, such as ServletContext
.
For example, on Tomcat, this configuration is performed using the attribute crossContext
in the configuration file server.xml
, as follows:
<Context path="/ebx" docBase="(...)" crossContext="true"/>
When several EBX® Web Components are to be displayed on the same HTML page, for instance using iFrames, it may be required to disable the management of cookies due to limitations present in some Internet browsers.
For example, on Tomcat, this configuration is provided by the attribute cookies
in the configuration file server.xml
, as follows:
<Context path="/ebx" docBase="(...)" cookies="false"/>
If the EBX® main configuration specifies the property ebx.persistence.url
, then the environment entry below will be ignored by EBX® runtime. This option is only provided for convenience; it is always recommended to use a fully-configurable datasource. See Configuring the EBX® repository for more information on this property.
The JDBC datasource for EBX® is specified in the deployment descriptor WEB-INF/web.xml
of the 'ebx
' web application as follows:
Reserved resource name | Default JNDI name | Description |
---|---|---|
| Weblogic: JBoss: | JDBC data source for EBX® Repository. Java type: |
If the EBX® main configuration does not set ebx.mail.activate
to 'true', or if it specifies the property ebx.mail.smtp.host
, then the environment entry below will be ignored by EBX® runtime. See SMTP in the EBX® main configuration properties for more information on these properties.
SMTP and email is declared in the deployment descriptor WEB-INF/web.xml
of the 'ebx
' web application as follows:
Reserved resource name | Default JNDI name | Description |
---|---|---|
| Weblogic: JBoss: | Java Mail session used to send emails from EBX®. Java type: |
If the EBX® main configuration does not activate JMS through the property ebx.jms.activate
, the environment entry below will be ignored by the EBX® runtime. See JMS in the EBX® main configuration properties for more information on this property.
The JMS connection factory is declared in the deployment descriptor WEB-INF/web.xml
of the 'ebx
' web application as follows:
Reserved resource name | Default JNDI name | Description | Required |
---|---|---|---|
| Weblogic: JBoss: | JMS connection factory used by EBX® to create connections with the JMS provider configured in the operational environment of the application server. Java type: | Yes |
For deployment on WildFly, JBoss and WebLogic application servers with JNDI capabilities, you must update EBX.ear
or EBXForWebLogic.ear
for additional mappings of all required resource names to JNDI names.
To configure data services to use JMS instead of the default HTTP, you must configure the JMS connection factory and the following queues, declared in the WEB-INF/web.xml
deployment descriptor of the 'ebx
' web application. This is the only method for configuring JMS for data services.
When a SOAP request is received, the SOAP response is optionally returned if the header field JMSReplyTo
is defined. If so, the fields JMSCorrelationID
and JMSType
are retained.
See JMS for more information on the associated EBX® main configuration properties.
If the EBX® main configuration does not activate JMS through the property ebx.jms.activate
, then the environment entries below will be ignored by EBX® runtime. See JMS in the EBX® main configuration properties for more information on this property.
Reserved resource name | Default JNDI name | Description | Required |
---|---|---|---|
| Weblogic: JBoss: | JMS queue for incoming SOAP requests sent to EBX® by other applications. Java type: | No |
| Weblogic: JBoss: | JMS queue for failures. It contains incoming SOAP requests for which an error has occurred. This allows replaying these messages if necessary. Java type: Note: For this property to be read, the main configuration must also activate the queue for failures through the property | No |
To speed up the web applications server startup, the JAR files scanner configuration should be modified to exclude, at least, the ebx.jar
and ebx-addons.jar
libraries.
For example, on Tomcat, this should be performed in the tomcat.util.scan.DefaultJarScanner.jarsToSkip
property from the catalina.properties
file.
EBX® can be deployed on any Java EE application server that supports Servlet 3.0 up to 5.0 except. The following documentation on Java EE deployment and installation notes are available:
The EBX® installation notes on Java EE application servers do not replace the native documentation for each application server.
These are not general installation recommendations, as the installation process is determined by architectural decisions, such as the technical environment, application mutualization, delivery process, and organizational decisions.
In these examples, no additional EBX® modules are deployed. To deploy additional modules, the best practice is to rebuild an EAR with the module as a web application at the same level as the other EBX® modules. The web application must declare its class path dependency as specified by the Java™ 2 Platform Enterprise Edition Specification, v1.4:
J2EE.8.2 Optional Package Support
(...)
A JAR format file (such as a JAR file, WAR file, or RAR file) can reference a JAR file by naming the referenced JAR file in a Class-Path header in the Manifest file of the referencing JAR file. The referenced JAR file is named using a URL relative to the URL of the referencing JAR file. The Manifest file is named META-INF/MANIFEST.MF in the JAR file. The Class-Path entry in the Manifest file is of the form:
Class-Path: list-of-jar-files-separated-by-spaces
In an "industrialized" process, it is strongly recommended to develop a script that automatically builds the EAR, with the custom EBX® modules, the EBX® web applications, as well as all the required shared libraries.
In order to avoid unpredictable behavior, the guideline to follow is to avoid any duplicates of ebx.jar
or other libraries in the class-loading system.
In case of deployment on Oracle WebLogic server, please refer to the Module structure section.