This document describes the architectural changes made for Entire Net-Work 7.2.
The primary function of Entire Net-Work is to transmit Adabas calls from a client application (such as Natural) to a remote Adabas database. In the past, the model for Entire Net-Work has been ‘nodal’ in nature. That is, each system participating in network operations requires a separate task, known as the Entire Net-Work Kernel to process both client side and database messages. This is known as the classic model and is depicted in the following diagram:
Different versions of Entire Net-Work have been developed on different platforms, using diverse construction languages and employing multiple communication protocols. In addition, multiple versions of the critical ADALNK module (the client interface for the Adabas call) have been developed with different Interprocess Communications (IPC) mechanisms that take advantage of specific equipment features, such as hardware instructions.
The disadvantages of pre-Version 7, classic, Entire Net-Work systems can be summarized as follows:
Multiple code bases for the Kernel and the ADALNK module limit the ability to enhance them functionally and reduce the speed at which technology changes can be performed.
The use of multiple communication protocols confuses administrators.
The different configuration methods and file syntaxes used by different platforms are confusing.
Users must configure all nodes in a network, including simple client systems.
There are different command and control methods on different platforms.
A heavyweight model Kernel is required on systems with only clients, leading to slow throughput.
The use of multiple processes for the Kernel and protocol handlers on UNIX systems reduces system performance and requires extensive administration.
The large size of messages headers increases networking traffic and requires extensive construction and processing.
The UNIX installation process is particularly complex.
Irritating restrictions exist in the number of clients, message sizes, and database ID range.
There is no Java or other new language support.
Entire Net-Work 7 has been radically redesigned in response to these customer concerns with the classic model. The new Entire Net-Work 7 architecture is described in New e-Business Architecture.
Entire Net-Work 7 is a major redesign of prior versions of Entire Net-Work.
This section covers the following topics:
The main goals of this Entire Net-Work redesign are to:
Increase its processing speed
Reduce the amount of space it occupies (its footprint), especially on the client side
Make it easier to manage
Simplify the installation, providing a common look and feel across all platforms
Rearchitect it so it can be easily expanded, removing all existing limitations and allowing any new products to be supported.
Provide a common code base with a common look and feel across all platforms
However, this new design must also be compatible with all current classic Entire Net-Work versions and must provide a comprehensive migration path for customers with production environments depending on it. For more information about migrating from prior versions of Entire Net-Work to Entire Net-Work 7, read Planning Steps for Entire Net-Work 7.
The primary objective of Entire Net-Work has not changed. Adabas calls are still shipped from a client to a database and a reply is shipped back. However, the Entire Net-Work 7 model, referred to as the e-business model, is asymmetric in nature, providing for far simpler client operations. The following diagram depicts this asymmetric design (which can be compared with the classic design depicted in Original Classic Architecture):
An e-business client is any Adabas client application that uses the Entire Net-Work 7 e-Business model and its associated message protocol and Directory Server entries to access Adabas databases. Hence, all of the following applications are or can be e-business clients:
Jadabas client applications
Natural applications
Tamino applications
Adabas SQL Gateway applications
Any 3-GL user-written application that makes the Adabas() call.
Entire Net-Work 7's e-business model makes use of a number of other Software AG products to achieve its design goals: the Directory Server and the Adabas Manager.
This section covers the following topics:
The new Entire Net-Work 7 client uses the new Entire Net-Work 7 e-business message protocol to access Adabas databases. It no longer needs a Kernel residing on the same system or its attendant control console, so the Entire Net-Work 7 client is much smaller than in previous versions and no longer requires any client-side IPC mechanisms to manage. Entire Net-Work 7 clients are simpler, faster and easier to deploy.
Simply install an Entire Net-Work 7 client on any machine from which you wish to access Adabas databases. Assuming the appropriate Entire Net-Work 7 Kernels have been installed in your enterprise and the Adabas Directory Server entries have been migrated for Entire Net-Work 7, your client should be immediately able to access the Adabas databases it needs.
The new Entire Net-Work 7 Kernel provides access to local and e-business Adabas databases. It requires a set of standard URLs (maintained using the Directory Server) to control its activities.
The Entire Net-Work 7 Kernel is the most complex component in the product because it provides various migration bridge technologies to assist you.
A Kernel provides access to local Adabas databases. It manages Directory Server URLs so that all e-business clients can use the new e-business message protocol to access the database via the Kernel. In addition, it broadcasts database availability to all connected classic nodes so that clients on those nodes can also access the database via the older protocol.
A Kernel provides access from e-business clients to databases on connected classic nodes using the older Entire Net-Work protocols. When a classic node connects or is connected to, the Kernel detects available remote databases and manages Directory Server URLs accordingly. Consequently, e-business clients can send Adabas calls to the Kernel where they will be converted to the older Entire Net-Work protocol and relayed to the classic node. Each reply is reconverted to the newer, e-business protocol and returned to the client. The Kernel also keeps track of database transitions (starts, stops, crashes), connections, and disconnections for databases on connected classic nodes.
A Kernel provides access from classic clients to e-Business Adabas databases. When an e-Business database is connected to a Kernel, the database availability is broadcast to all connected classic nodes using the older Entire Net-Work protocol. Classic clients can then send Adabas calls to the Kernel where they will be converted into the e-business protocol and sent to the database. Replies are reconverted to the classic message protocol and relayed back to the client.
Note:
Currently mainframe e-business Adabas database access is
only supported if Entire Net-Work 6 (or later) ADATCP or Simple Connection Line
Driver (TCPX line driver) are installed on the mainframe host.
In summary, once all classic connection definitions have been converted, the Entire Net-Work 7 Kernel, using the Directory Server entries, becomes the bridge between classic Entire Net-Work installations and new e-business Entire Net-Work 7 installations, as depicted in the following diagram:
Kernels can also be assigned to specific Entire Net-Work 7 partitions. For more information, read Partitioning.
The Adabas Directory Server is used to store Entire Net-Work configuration information. Both clients and Kernels retrieve all necessary data from the Directory Server. Consequently, populating and maintaining the Directory Server is an important task.
 |
Warning: The Directory Server is critical to the functions of Entire Net-Work 7. It should be on a dedicated system that is operational 24 hours a day, with a UPS. The location of the Directory Server must be specified to the Kernel and clients when they are installed. In addition, the location of the default Directory Server may be defined in the SAGXTSDSHOST entry in the DNS. You may need to consult with your Information Technology department to make updates to the DNS. If no Directory Server can be found for your enterprise, Entire Net-Work cannot function. |
All Directory Server data is stored in the form of a Universal Resource Locator (URL) that is familiar to any Internet user. The Directory Server allows complex URLs to contain management data for Entire Net-Work using this standard industry-wide syntax. More importantly, an Entire Net-Work Kernel can dynamically add, modify, or delete URLs in the Directory Server for use by clients.
An Entire Net-Work Client only needs to be able to extract the location of the Adabas database it is trying to access from the Directory Server. Consequently, a single Directory Server URL is required for each Adabas database in the enterprise in order for all e-business clients to access that database. If Entire Net-Work partitioning is used, more than one Directory Server entry may exist for a given database. For more information, read Partitioning.
When operational changes occur for a database (startups, shutdowns, and movement between machines), the Entire Net-Work Kernel automatically maintains the URLs in the Directory Server: it adds a URL to the Directory Server when it discovers a database (and can accept Adabas calls intended for that database); likewise it can remove the same URL when a database becomes unavailable.
At least one Adabas Directory Server should be installed in your enterprise; we recommend that you install only one Directory Server to ensure centralized administration. However, your enterprise network configuration may require more than one. For example, you may want to install more than one Directory Server to fully direct requests to specific databases. While partitioning can also be used to restrict database access, all entries (in all partitions) of a Directory Server can be maintained via the Adabas Manager, so restriction is not complete. If, however, you use multiple Directory Servers, you can limit what entries are available for viewing in the Directory Server portion of the Adabas Manager.
Entire Net-Work 7 introduces partitioning of Adabas Directory Server entries. Partitioning allows you to use one Directory Server for your whole enterprise, rather than separate Directory Servers for different departments within your enterprise. The partitions each need to be managed separately, but only one Directory Server needs to be installed.
When you install an Entire Net-Work 7 Kernel or client, you are prompted for an optional partition name. If you specify one during a Kernel installation, the Directory Server entries created for that Kernel are stored in a partition by that name in the Directory Server; the Directory Server entries in the partition are maintained separately from the other entries in the Directory Server. The Kernel is only able to access databases, classic Entire Net-Work nodes, and other Kernels that have entries in this partition. Likewise, when you specify a partition name during a client installation, the client can only access databases for which there are Directory Server entries in the specified partition.
Here are some of the advantages of partitioning:
You can use partitioning to direct specific clients to specific databases.
If you have created Adabas databases with identical database IDs, you can use partitioning to correctly identify which client calls get directed to which Adabas database.
You can use partitioning to group client calls to an Adabas database, thus reducing the number of actual connections required for that database. This can be especially useful if you are using an Entire Net-Work mainframe product to access a specific Adabas database. It also provides you with some level of client control: if you want to remove access to a specific database for clients in a given partition, simply remove the access URL entry for that database (using the Adabas Manager) or stop the Kernel in that partition.
Using SSL, you can use impose real security requirements on calls made by clients in specific partitions.
The Adabas Manager (AMN) provides centralized management of all Software AG products installed in the enterprise, using a Web-based graphical user interface. The use of the Adabas Manager eliminates the need for a system administrator to visit individual machines or maintain multiple product windows on the desktop.
|
Warning: Adabas Manager should be on a dedicated system that is operational 24 hours a day. If Adabas Manager is not available, you cannot maintain and control Entire Net-Work or the Adabas Directory Server. |
Adabas Manager is used by Entire Net-Work 7 to manipulate configuration information. Using Adabas Manager, you can easily change the URLs stored in the Directory Server without fully understanding the syntax. In addition, the Kernel can be examined and controlled via Adabas Manager. The status of classic nodes and databases for which connections have been defined can be determined. Statistics can be examined and various control functions, such as node disconnection, Kernel shutdown, and trace settings can be performed.
This new e-business Entire Net-Work 7 design has the following advantages:
A single, platform-independent ADALNK module (the client interface for the Adabas call) which supports multithreading is used.
All control operations are centralized using the Adabas Manager (AMN), easing network administration.
The client no longer needs a Kernel or its attendant control console, so its footprint is much smaller than in previous versions and you no longer need to manage the Kernel on the client side. In addition, there are no client-side IPC mechanisms to manage. Consequently, Entire Net-Work Clients are simpler, faster, and easier to use and deploy.
The client deployment is unfettered by networking resource limitations that existed in prior releases.
A new message protocol is used that speeds message transmission and reduces processing load. This new protocol layer is one-third the size of the protocol layer used by classic Entire Net-Work.
A standardized installation method is provided that is similar on all platforms.
A Kernel is only required on a system where databases are present or if a migration path to a classic Entire Net-Work system is required. Hence, management is further reduced.
Partitioning may be used to direct specific Kernels and clients to specific databases.
For information about migrating from prior versions of Entire Net-Work for open systems to Entire Net-Work 7, read Planning Steps for Entire Net-Work 7.