The following topics provide an overview of the NexJ solution architecture of a deployed NexJ solution.

NexJ system architecture overview

The deployed NexJ solution consists of four interactive layers.

The solution model is served by NexJ Model Engine, which is deployed on a Java EE container. The container communicates with the rest of the enterprise system, including databases, web servers, mail servers, and other components.

NexJ Solution Model

The NexJ solution contains one or more NexJ applications, such as NexJ Customer Relationship Management, NexJ Admin Console, and NexJ System Admin Console.

The model defines channels, which are interfaces to resources that will be provided by the model engine, Java EE container, or the entire enterprise system. It also defines data store schemas that will be managed by the model engine, container, or enterprise. The channels and data store schemas are defined without knowing the details of underlying resources the interfaces will be bound to or what underlying stores the schemas will be bound to. The model defines platform-independent application behavior that interacts with channels and data stores.

The metadata for the model is contained in a series of XML files, including the data store definitions and channel definitions used by the application. These metadata files are stored in a single JAR file, which is called nexj-meta-<app>-<version>-<checksum>.jar. Since the solution model is platform independent, the same metadata is used regardless of where and how the application is deployed.

The NexJ solution model is designed in NexJ Studio.

NexJ Model Engine

NexJ Model Engine runs the NexJ application as the runtime interpreter of the NexJ solution model. It is platform independent and is deployed identically to any supported Java EE container. It implements any channel or data store defined in a model, either directly, or by delegating to the Java EE container.

NexJ Model Engine is an EAR file called nexj-<app>.ear, which contains the following files:

• One or more NexJ solution models.
• NexJ Model Engine libraries and third-party libraries.
• Definitions of the platform-specific interface bindings, for use by the model engine: nexj-env.jar. These bindings are mappings from system resources to channels and data stores.
• Definitions of the platform-specific interface bindings, for use by the Java EE container: nexj-ejb*.jar, nexj-*.rar, and nexj-web*.war. These bindings describe the available NexJ Model Engine APIs to the Java EE container.

NexJ Model Engine is configured using NexJ Studio.

Java EE Container

The Java EE container deploys NexJ Model Engine. It can be a third-party application server, specifically IBM WebSphere Application Server, and can reside on multiple application servers in a clustered environment. You can also to deploy with NexJ Server, developed by NexJ Systems, instead of a third-party Java EE container.

The Java EE container binds directly to the operating system interfaces and also to enterprise resources, such as database servers. It implements HTTP request handling, including encryption, authentication, and load balancing.

The container provides standard Java class libraries and APIs upon which NexJ Model Engine relies. It also has information about the model engine APIs used by the container.

Other container configuration details include the following:

• Application-independent container configuration (for example, tuning and security settings).
• Logging configuration.
• Credentials needed to access other enterprise servers and resources.
• Public key certificates required by the application server.

The container must include the following platform-specific libraries, which are custom implementations of container module APIs:

• nexj-websphere.jar
• nexj-boot.jar

The Java EE container is configured by a combination of NexJ Studio tools, manual configuration, and third-party tools.

Enterprise network

The enterprise network includes additional servers implementing the other tiers of the application, including database servers, HTTP servers, the push redirector, Microsoft Exchange Server, and other third-party servers. It provides all the network peers with which the NexJ application integrates.

These integration points are configured manually or using third-party tools. The connections between these servers and the NexJ application are defined in the channel and data source files created for the NexJ application in NexJ Studio. In addition, you may need to use NexJ Admin Console and NexJ System Admin Console to enable various third-party functionality for NexJ CRM users.

NexJ deployment overview

The NexJ solution is deployed on a Java EE container, such as WebSphere Application Server or NexJ Server. It requires a relational database to store both NexJ metadata and client data.

This minimal configuration might be sufficient for a sample deployment used for development. A production deployment in an enterprise environment has a large number of optional components, depending both on the existing environment and on the desired NexJ application functionality.

NexJ CRM end-user interfaces

End users can access NexJ CRM using an Internet browser on their computer. In addition, mobile versions of NexJ CRM are available.

Ensure that the end users who will access the product you deployed have one of the browsers or mobile devices listed in the Release Notes document for your version of the product.

In addition, for users accessing NexJ CRM using an Internet browser, you can install NexJ Add-In for Microsoft Office to allow interaction with Microsoft Word and Microsoft Outlook. For more information, see Using Microsoft Add-In extensions.

HTTP servers

One or more HTTP servers (or web servers) are used to host the web sites that represent the NexJ solution, including NexJ CRM, NexJ Admin Console, and NexJ System Admin Console. The web servers can be configured to provide user authentication, so that information between the user interface and the application server that serves the NexJ CRM application is sent securely. They can also be used to distribute requests from the user interfaces across multiple application servers.

The IBM WebSphere Application Server is distributed with the IBM HTTP Server, so their integration is seamless.

Push redirector

The push redirector is used to push data, such as messages and notifications, from the application server to the NexJ CRM client. For more information about the push redirector functionality and instructions for deploying the push redirector, see Push server configuration.

Java EE container

The deployed NexJ solution runs on an application server or an application server cluster.

For information on installing and configuring WebSphere Application Server, see Setting up the WebSphere Application Server Environment.

For information on installing and configuring NexJ Server, see Setting up NexJ Server.

Online help

Online help for your NexJ solution can be deployed on the same web server as the applications or a separate web server, which may allow easier updates. For more information, see Enabling online help.

Microsoft Exchange Server

Use Microsoft Exchange Server to synchronize Microsoft Outlook email and calendar information with NexJ CRM. For information about deploying Microsoft Exchange Server and about NexJ integration with Microsoft Exchange Server, see Microsoft Exchange Server Synchronization.

Simple Mail Transfer Protocol (SMTP)

To enable sending mail using NexJ CRM, you need to create a mail channel using NexJ Studio.

Relational databases

NexJ requires a clean default relational database to contain metadata for NexJ CRM. You need to configure one or more database servers to contain this default relational database as well as any other database with client data required by NexJ CRM users. For more information, see Configuring a database environment.

Authentication configuration

You can configure single sign-on authentication for NexJ applications so that users are able to access other enterprise applications without having to again log in until their session has expired. NexJ uses Windows Authentication and the SPNEGO negotiation mechanism to securely authenticate users and determine their level of authorization. If Windows Authentication is not an option, Java Kerberos can be used as an alternative. For more information, see Configuring user browsers for silent single sign-on.

BI and ad hoc report configuration

To enable end users to generate reports using NexJ CRM and to add Business Intelligence (BI) functionality, you need to synchronize the operational database with a dedicated reporting database, create a new BI model, and create
a new reporting environment. For more information, see Enabling Ad Hoc Reports and BI functionality.

Session persistence configuration

Session persistence allows server-side load balancing, as well as storing information about the user and the state of the user interface to create persisted sessions. This information can be stored in a database or a file in the file system. For more information, see Session persistence.

Enterprise Component Registry

The Enterprise Component Registry contains information about the portlets included in your NexJ solution. It also includes the User Registry, which contains information about NexJ users and user permissions. The functionality for ECR is packaged with your deployed model. The data for ECR is stored in a database, whose details are defined as a datasource connection file using NexJ Studio.

Attachment storage

In NexJ CRM, users can add computer files, such as Microsoft Word documents, to activities, campaigns, batch emails, or documents. Use a datasource connection file in NexJ Studio to indicate whether you want the attachments saved in a separate database or file system to improve performance.

Messaging configuration

NexJ supports internal message queues using ObjectQueue channels. However, it can also support third-party Java Message Service (JMS) providers such as Apache ActiveMQ, Progress SonicMQ, and IBM WebSphere MQ. For more information, see JMS engine integration.