This chapter contains the following topics:
In a client/server environment, applications must communicate across different platforms. These platforms can have different communications protocols, database management systems, and hardware operating systems. For clients to communicate with servers and servers to communicate with other servers, a mechanism must exist that can bridge multiple protocol and multiple vendor issues. This mechanism is a layer of software called middleware, which resides between the operating system and the business applications. It is important to have an application architecture that is based on a single, consistent middleware strategy.
Oracle's JD Edwards EnterpriseOne provides these types of middleware:
To communicate with each other across a network, the two computers must share a communications protocol (or set of protocols). A communications protocol is a formal set of rules that specifies the format and relationship for exchanging data among different devices. The communication middleware is concerned with these protocol layers:
JDENet is the JD Edwards EnterpriseOne proprietary communication middleware package that provides server-to-server and client-to-server communication.
JDENet is a peer-to-peer middleware solution. For example, think of a client as a network conversation initiator and a server as a network conversation responder. In this example, a client always initiates the conversation by asking for something from another machine, and a machine acts as a server when it responds to a network request, such as when it gives something asked for by the client. In this peer-to-peer middleware solution, the distinction between client and server is determined by which machine starts the conversation. Any machine, running on any platform, can act as a client or as a server at a given time.
With JDENet, communication between client and server occurs through messages. JDENet messages contain processing requests, such as requests for business functions, batch jobs, or JD Edwards EnterpriseOne login security. JDENet messages can originate from the client or the server. JDENet handles database requests only if multiple servers are in use and if they are different server types.
Application requests (messages) can be synchronous or asynchronous. A synchronous message, such as calling a business function, requires the client to wait for the server to complete the request. An asynchronous request, such as a batch process, enables the client to continue with another task while the software processes the request. In some circumstances, business functions can also be called asynchronously.
A socket is a communications endpoint through which an application sends or receives packets of data across a network. Sockets provide a duplex communication channel between one or more systems. JDENet uses stream sockets to provide end-to-end communications. Sockets guarantee that the data arrives intact.
Message-based communication means that applications send service requests for logic or data in the form of messages that are received and stored in a queue for processing. The middleware handles message transmission, which enables the client application to process other tasks. Without messaging services to handle these jobs, the application must wait until the request is handled and the results returned.
Messaging is most appropriate for event-driven applications. It is the opposite of remote procedure calls (RPC), which are synchronous. The message packaging and "handshaking" of JDENet ensures that the message transmission is complete.
Although client workstations can have more than one copy of JD Edwards EnterpriseOne loaded, only one JD Edwards EnterpriseOne Windows-executable application can be running at any one time. The software uses an internal network process (also referred to as a net process) called JDENet to communicate a request to the JD Edwards EnterpriseOne server.
Servers also have a net process called JDENet. This process communicates with the client workstations and routes request messages to appropriate dedicated JD Edwards EnterpriseOne processes. In turn, the dedicated processes route work to the appropriate platform-specific logic processes, such as DLLs, shared libraries, and job queues. A server can have multiple JD Edwards EnterpriseOne main processes, multiple dedicated processes, multiple DLLs, shared libraries, and job queues.
The advantage of this architecture is that multiple workstations can make requests to the same server at one time. You can control the number of workstations that can make and maintain a session connection to a main server process. You also can define the total number of dedicated processes (and the number of each type) that the software uses to process specific types of workstation requests.
A relationship exists among network processes, dedicated processes, and logic processes. This relationship is specifically defined by the jde.ini file on the enterprise server. Every enterprise server must have at least one JD Edwards EnterpriseOne network process, which is referred to as a JDENET_n job. This job handles network connections and traffic for JD Edwards EnterpriseOne.
As defined in the jde.ini file for each server, multiple JDENET_n processes can exist. Regardless of the number of JDENET_n processes that exist, the initial JDENET_n process serves as the master listener. On a Windows server this master listener is called JDESNET.
If multiple JDENET_n jobs are specified, the software starts the jobs as required, allocating a job to each request. When the maximum number of JDENET_n processes is started, the software automatically alternates between the currently running JDENET_n jobs until the maximum number of connections is reached, providing load balancing among network processes. If the maximum number of connections for the JDENET_n job is met on a given server, a client or server cannot initiate an additional JD Edwards EnterpriseOne session on that server until an existing session connection is ended. By design, all connections to JDENET_n persist for the duration of a session.
For example, suppose that the jde.ini file on the server specifies that four JDENET_n processes are enabled. The first JDENET_n request is routed to the master listener, which is the initial JDENET_n process that is run at server start-up. When a second request to JDENET_n is received, the master listener receives the request and assigns it to a second JDENET_n process, which it then starts. This assignment persists for the duration of the session between the requesting device and the server. The same process occurs for the third and fourth JDENET_n requests. When the fifth request is received, it is assigned to the first JDENET_n process, and the cycle continues.
The JDENET_n process is responsible for handling the network layer of communication. If the JDENET_n job determines that the incoming message is a request for logic processing, it routes the request to an appropriate JDENET_k job. The software determines an appropriate JDENET_k job based on message identifiers. The JDENET_k job is the process that provides the link between the JDENET_n job and the appropriate platform-specific processing job. The JDENET_k process is applicable only to servers.
The JDENET_k job handles the two-way routing to and from the various logic processes, and the JDENET_n job handles the return delivery to the appropriate machine. Many dedicated kernel types exist, and each is responsible for a specific type of JD Edwards EnterpriseOne process.
Examples of logic processes include dynamic link libraries (.dll) for Windows platforms, shared libraries (.sl or .so) for UNIX platforms, and JDENet processes for IBM i platforms.
Different database management systems (DBMS) have their own version of Structured Query Language (SQL). For example, this demonstrates how Microsoft SQL Server, Oracle, and DB2 for IBM i handle the same SQL statement:
| DBMS | SQL Statement |
|---|---|
| Microsoft SQL Server | SELECT * FROM PRODDTA.F0101 |
| Oracle | SELECT * FROM PRODDTA.F0101; |
| DB2 for IBM i | SELECT * FROM PRODDTA/F0101 |
The purpose of a database middleware layer is to provide a common interface to interpret the various versions of SQL. JD Edwards EnterpriseOne has a database middleware product called JDEBase, which is a common set of application programming interfaces (APIs) that programmers can call to request data and perform data manipulation logic. JDEBase interprets the generic APIs and converts the SQL into the appropriate statements for JD Edwards EnterpriseOne to access the database.
Multiple databases in a distributed environment require a monitoring program to ensure database integrity. This monitoring program is referred to as a transaction monitor. The JDEBase database middleware has an embedded transaction monitor.
JDEBase provides:
The ability to insulate developers from platform-specific SQL coding
Rapid development of native drivers
Server-to-server communication
Transaction processing
JDEBase provides a set of APIs to the developer and a set of translation programs to JD Edwards EnterpriseOne. The translation programs are embedded in the data source definitions.
For example, suppose a data request for Address Master is made. The Object Configuration Manager (OCM) determines which data source contains the requested table. The Data Source Master table (F98611) provides the database information.
This section provides overviews recommendations for Data and Logic Distribution and discusses how to:
Set up direct-connect processing
Set up object mapping for direct-connect environments
To achieve the best performance with direct-connect processing, use these recommendations for data and logic distribution:
Map the transaction data to a data server.
Map user defined codes and menus to the workstation. You also can map other static files locally. If the maintenance costs are more than the performance returns in mapping these tables locally, you can map them to a data server.
Map all batch applications to the enterprise logic server.
In direct-connect processing, workstations are connected directly to servers that can store data and process logic. For performance reasons, distribute the data and logic in a manner that reduces network traffic and unnecessary input and output on the server.
Before performing the tasks in this section, you will need to have all workstations connected directly to servers.
The process overview for setting up direct-connect processing is as follows:
Create a production environment and verify that the new environment uses a production path code.
Determine the name of the master business functions that you should map to the server, if applicable.
Modify the Object Configuration Manager mappings for the new environment.
This section lists the prerequisites and discusses how to set up a master data administration environment.
Before performing the tasks in this section, you will need to:
In a direct-connect environment, you need to identify the master business functions so that you can map them to a server.
Depending on the configuration, you might require multiple direct-connect environments. For example, to support multi-tiered configurations you might need an environment that maps all application processing to one server and all data to a corporate server.
The data administrator uses the Master Data Administration environment to maintain the published tables in the central location.
To set up a Master Data Administration environment:
Map all table objects to a business data source on the server.
Map user defined codes and menus to a control table data source on the server.
The control data contains the published set of user defined codes.
Map system tables to the system data source.
Map Object Librarian tables to the Object Librarian data source.
Map data dictionary tables to the data dictionary data source.
Map batch applications to the server.