Planning a GroupWise DMS System
(Last modified: 25Feb2002)
This document (10066600) is provided subject to the disclaimer at the end of this document.
Planning a GroupWise DMS System
GroupWise 5.x, 6.x
In the past, setting up a GroupWise post office was based solely around messaging. Issues such as user access, disk space, security and bandwidth were addressed in the context of store and forward electronic messaging. The purpose of this section is to make users aware of the new architecture and the considerations that should be taken into account when setting up GroupWise 5.5 with its Document Management Services (DMS).
With a basic knowledge of the DMS components, we are free to talk about structure. For those who have administered networks or messaging systems, you know the value of an organized structure. A well organized system is easier to setup, administer and troubleshoot. These benefits will drastically reduce the cost of ownership.
GroupWise Post Office Architecture
GroupWise is a new form of GroupWare product. It is the first to blend the functionality of messaging, calender and scheduling with document management. GroupWise operates as either a file sharing based messaging system or as full client/server. The server, delivers not only messages, but documents as well. Other functions are also processed at the server level such as gateways, indexing, routing and administration.
The GroupWise architecture includes domains, post offices and libraries. The domain and post office serve basically the same role they have in the past. The optional library is a combination of document databases and the documents themselves which are stored in a separate Document Storage Area.
Document Management Services are only available to users of the 32 bit clients. The 32bit client supports ODMA32 which allows tight integration between applications compliant with 32bit ODMA. GroupWise also provides point to point integrations for the Microsoft Office 95 Suite. Later versions of Microsoft Office support ODMA with the exception of Excel. Most other applications can be loosely integrated with GroupWise. Documents sent via email to GroupWise users can be embedded attachments or references to the GroupWise library.
The addition of Document Management Services means the documents created by your organization will now be stored in the GroupWise system rather than scattered on PC hard drives and network users and temp directories. Because the organizations documents are now centrally managed in the GroupWise system, disk space requirements for GroupWise 5.x and 6.x are greater than those of GroupWise 4.1.
For existing GroupWise administrators the additional size of the GroupWise system may be an adjustment. This size difference is offset somewhat by the file compression used when objects are stored in a Binary Large Object (BLOB) format. Drive space can also be reclaimed by either archiving or deleting objects that no longer need to remain online. GroupWise has the ability to automatically archive or delete objects depending on the length of inactivity.
Before installing a GroupWise system it is recommended that system administrators calculate the size requirements of their current and future documents. Estimating disk space requirements can be challenging. One way to estimate would be to calculate the amount of disk space currently dedicated to documents. If your organization currently uses some form of document management or is storing documents in a centralized manner, this may be as simple as performing a DOS command such as DIR *.* /s, to find the amount of space being used in document directories. You can then divide the amount of disk space by its creation time in months. The resulting number is a rough estimate of how much space the organization is using for documents each month.
The described method has a number of flaws. First, if your company has steadily grown over time then this number may not properly estimate future document creation. If you have performed document deletion or archival then this number may also be skewed. Another point to consider is that documents created today are much larger than documents created in the past. For instance, a Microsoft Word document is 5K in size before you begin adding text or graphics. Another important aspect to consider is your past or future use of imaging or graphical design. These types of documents can be very large.
If documents are stored on PC hard drives or users directories, calculating your organizations document space requirements may be a challenge.
GroupWise should decrease the amount of space these documents would normally require by compressing the documents in a Binary Large Object, or BLOB, database. The compression averages 50% or more, depending on the information being stored. This should be considered when calculating your disk space requirements. Because documents stored in GroupWise are already compressed it is not necessary to use NetWare File Compression.
One of the most important decisions to make is how you want to group your users into post offices. Users who are both local to each other and send a lot of messages between each other probably should belong on the same post office. Heavily used document management limits the number of users that you should put in a post office. As a rough rule of thumb, 250 users using document management can coexist comfortably on a single post office.
For most organizations, Novell recommends Geographical then Departmental configuration.
One Library vs. Many Libraries
Depending on your organization you may have one or more libraries. The best rule of thumb is to locate libraries adjacent to physical workgroups. Try to align your libaries with your organizational structure. The same basic principles that are used in planning Novell Directory Services Containers and GroupWise Post Offices apply to GroupWise libraries.
GroupWise libraries are designed to serve any number of users as long as you follow the basic rules of setting up a post office. For instance, if you had 250 users on a post office, you could create one library to service all of them on an daily basis. That library may actually service thousands of users in the system as they occasionally access that libraries documents. In some cases, you may want to setup multiple libraries on the post office for smaller workgroups or departments. This would be helpful if each group had specific demands on how they would like the library configured i.e. document types, custom fields, naming etc. You should be careful to not break your system into too many libraries because each will require some degree of administration.
Because documents are accessible by users in other post offices and domains, GroupWise has been designed to minimize network traffic. For instance, after a reference to a document on another post office library is found and placed on the users desktop, they will no longer need to search the WAN for that document next time it is edited. The can simple search their own desktop to find the reference. This is possible because GroupWise replicates a copy of the wordlist index file to that users home post office.
When documents are accessed over the WAN, the client connects directly to the remote POA through IP. If IP communications are not available, users can use the Remote client to access the document through the ASYNC gateway. This passes the document to the user via the store an forward process.
Because searches on remote libraries may have to pass through various queues and gateways it may take time for results to come back. While the search is taking place the user can alt-tab back to the GroupWise desktop and allow the query to complete.
You should remember when setting up a GroupWise system with DMS, that documents being accessed outside of a users own post office will require a dedicated TCP/IP link. If the post office being accessed is in another location you will need a dedicated line such as a T1 or 56KB. If a direct line is not setup, users can access documents on a remote post office though GroupWise Remote. GroupWise Remote forces documents to be transferred though the store and forward process.
Because documents are generally larger than email messages, they will take longer to transmit over the wire. This may not be a huge concern if your dealing with mostly wordprocessor or spreadsheet documents. If users will be accessing images, drawings or graphics over the WAN you will need to take this point under consideration when setting up your network infrastructure. Keep this in mind as you answer the following questions. Where will your message servers and gateways be located and how will they communicate with each other? What platforms will you implement to get the desired performance? What do you expect traffic loads to be between each component in the system? Ultimately the network infrastructure you setup will determine the response times you can expect out of your document management system.
One of the primary factors in network speed is the amount of bandwidth. Bandwidth is the amount of data that can be passed through the network per second. A number of elements make up network bandwidth: cable types, transmission protocols and hardware. The more bandwidth your network has, the better it is able to handle heavy traffic. Ethernet networks are susceptible to wide fluctuations in speed during periods of heavy traffic. The ability to reduce the amount of network traffic can be very beneficial. This is especially true on a Wide Area Network (WAN).
The GroupWise post office can be located in an area that will help you decrease network traffic. Locating the post office in close proximity to the users who will access it will mean less traffic through routers, bridges and other network hardware. Running GroupWise in client/server mode will also reduce network traffic.
Performance and Reliability
Assuming a good overall architectural design, performance and reliability are going to be affected primarily by the speed and reliability of your network infrastructure. GroupWise tries to operate at the Application (highest) layer of the OSI networking model in order to provide wide interopeability. This means GroupWise relies heavily on the underlying stability and soundness of lower network layers.
What is the status of the network that GroupWise will depend on? A network that is slow, unreliable or is already close to overload may be pushed over the edge by the addition of a workgroup application. Most users given access to GroupWise will become heavy users of the system, even if they hardly used the network for anything else previously. Keep in mind that a good workgroup application will motivate users who never had much use for the network to suddenly realize what a valuable resource it is.
Client/server is a computing model that allows you to split the processing load between two machines: the client and the server. The client program runs on an end-user's PC, while the server program runs on a network server. These two programs use a network connection to exchange information. The client/server model allows one process to operate independently of the other, performing specialized tasks, while sharing the processing load. The client/server architecture offers both the customer and the developer a number of benefits. These will now be discussed in detail.
The client program does not directly access the database. Instead, the client communicates directly with the server and the server accesses the database. In this model, records in the database will not become corrupted in the event of a client failure such as: general protection faults, lockups or crashes. These failures often cause partial writes to database records which is a form of corruption. Using client/server, the partial writes are never committed to disk and the database integrity is preserved. You also receive database protection from invalid or corrupt packets being sent by the client PCs.
GroupWise versions 5 and later uses an enhanced FLAIM database that supports transaction tracking and rollback. This feature is part of the database engine. Transaction tracking means all writes to database files are monitored until they are complete. In the event of a server failure, a record of all complete database writes is known. This allows the FLAIM engine to roll the system back to a safe state before the incomplete transactions existed. This means any writes to the database that were not completed before the failure, will not be committed to disk. When you bring your file server back up, the final record may be missing from the database but the database will not be corrupt. The use of transaction tracking and rollback is not a direct benefit of the client/server architecture but client/server makes transaction tracking more efficient.
It is not necessary to flag GroupWise files as transactional with NetWare Transaction Tracking System (TTS) when running on a NetWare server.
Reduced Network Traffic
In a non-client/server environment, all data needed by the client for processing must be sent across the network. When complex searches are being performed, the amount of data needed by the client can become quite large. When large amounts of data are being sent over the network, contention based systems such as Ethernet can experience slowness. This is another area where the client/server model offers great benefits. The parameters of the client request are sent to the server for processing. The server not only has the data readily available, possibly in cache, but it most likely doesn't need to send network packets to get it. [In some cases you may load a POA on a server apart from where the post office data resides. In those cases additional network traffic would be created in order process user requests.] After the request has been processed, the results, much smaller than the volumes of data processed, are sent back to the client for display. The benefit becomes even more important in WAN installations.
Because the client/server model creates less traffic, everyone connected to the LAN benefits by not having to wait on a congested network segment. In most situations client/server also means faster processing time which equates to faster performance. This is only true if the server has a processor adequate for its workload. This is also true for the client PCs since they will be processing information as well.
GroupWise supports full client/server operations for its Messaging and Document Management Services (DMS). The client software connects to the server process via IP. All of the server processes used by GroupWise are not part of the client/server model. Many of these processes simply perform administrative or maintenance functions. They are not specifically off loading work from the client. Examples of these programs are the administration server, gateways and MTA's.
If running in client/server mode all GroupWise finds (searches) are handled by the POA. The client simply displays the search results. For example, Mr. Smith wants to perform a search on his documents in the accounting library. From the client he selects Tools|Find and types Smith in the dialog box. He then limits the search to the accounting library. When he clicks ok, a request is passed to the POA running on the post office to which the accounting library belongs. The POA will perform all the necessary calculations and simply send the results back to the Mr. Smith.
Finds or searches operate differently when the client and the library are in different post offices. For example, Mr. Jones wants all of the documents in the development library which contain the word "starter". Mr. Jones is a user in the Los Angeles post office and the development library is under the Houston post office. Mr. Jones's query is sent to his own POA. If parts of this query are for that information in the Los Angeles post office that POA will perform that function. At the same time it will send the request, though the store and forward process, a high priority message to the Houston post office's POA. The amount of time this takes will depend on the configuration of the system. Gateways, line speeds, polling cycles and hardware will all affect the speed of the query. During this process Mr. Jones is free to perform other operations on his computer either in GroupWise or other applications. When the Los Angeles POA receives the search results from the Houston POA the results are passed to Mr. Jones.
Accessing documents is performed in much the same manner as searching with a few exceptions. When a user wants to access a document in a library from within their own post office, a request is sent to the POA and the POA sends the document back down to the client. The client program decompresses and decrypts the file and places it in a document staging area. When access is finished the document is sent back to the POA and the POA places the document in a new location in the BLOB storage area.
If a user requests to access a document in a library under a different post office a direct IP connection is established between the client and the other sites POA. This operation differs from performing searches on libraries in secondary locations in which the information is passed back through the store and forward process. When using IP GroupWise client communicates directly with a secondary POA. Obviously this type of WAN connection requires dedicated lines between sites. If dedicated lines are not available then the client can access the document through GroupWise Remote. By using GroupWise Remote the GroupWise system knows to transmit the document to the users home POA via the store and forward process.
Two types of connections are created between the client and the server: physical connections and virtual connections. Physical connections are established IP connections between the client and the server. Virtual or application connections ride on the physical connection. At any point in time, you may have multiple physical connections and/or multiple virtual connections. For example, the client program GRPWISE.EXE, API and the address book each use one physical connection if they are all being run from GRPWISE.EXE. In this case, certain API and address book calls have been integrated as threads under the main GroupWise client program. However, custom executables can be created with the API. Each of these custom applications would make its own virtual connection to the server. The Address Book (addrbook.exe) can also be run separately. Virtual connections are also created for each proxy, shared folder and personal address book.
These virtual connections can share one physical connection. On the client, GWENV1.DLL acts as a broker with the physical connections. If other processes request access to GroupWise, they can simply piggy-back upon the physical connection. Each virtual connection takes up 2-3K of server memory. It is estimated that each user will have on average 3 to 4 virtual connections at a time. Virtual connections exist as long as the client software is loaded. Physical connections take up very little memory on the server. Physical connections are terminated by the client software after they are inactive for 10 seconds. The server will terminate the physical and virtual connections if they are inactive for 15 minutes. Generally the server will be terminating connections in the event of a PC crash or lost network connection.
A full client/server implementation eliminates user access to the message and document store. Also, the user's GroupWise password is verified at the server.
Using the client/server access method increases the number of concurrent users that a post office can support. GroupWise will support more than 1,000 concurrent users. This would probably be difficult when combined with heavy DMS use.
Seamless Cross-Platform Access
Multiple client platforms access the data store via TCP/IP. There is no need for non-native file system support on the server that houses the message store.
The server accesses information in the message store and retrieves the necessary information before sending it to the client. This greatly reduces the amount of network traffic caused by a client directly accessing information in the message store.
Increased Database Integrity
Concurrent access problems are reduced because only the post office agent (POA) manipulates data in the message store. This all but eliminates file locking conflicts and increases the integrity of data in the message store.
Simplified Client Connections
The client can communicate with any POA in the GroupWise system. The POA will then route the request to the POA for the user's post office (also called redirection).
Cross-Post Office Proxy
A user can proxy for another user on another post office. This means that a user in one workgroup (LAN server) can access the mailbox of a user in another workgroup (LAN server).
TCP/IP is the transport mechanism that allows clients to communicate directly with the server.
Decentralized vs. Centralized Document Libraries
By using GroupWise you will immediately be using centralized document management. This offers many benefits to the system administrator in areas such as: backup, administration, fault tolerance, global access etc. A system administrator may want to take centralization to the next level by storing all the document management libraries in an organization or location, under one post office. This may provide a number of benefits, one of which may be dedicated hardware i.e. RAID, fast backup units etc. In a large organization, you may also find it beneficial to dedicate or allow one administrator to specialize in document management. The benefits of centralized libraries are substantial and can be a high priority to an organization.
Decentralization has some compelling benefits as well. Because libraries are distributed throughout the organization you have increased fault tolerance. If one file server should fail the entire document management system is not out of commission. Performance may be drastically reduced in a centralized system. This is because document operations may be performed on different systems than the ones the users are already connected. For instance, users are connected to the server in which their POA is serving their mail. If documents are located on a different post office they will have to connect directly to the other PO for document access. Though this operation is very fast and invisible to the user, it may have to pass through multiple network systems such as routers and bridges which slow down the network.
GroupWise provides strong internal and external security. All documents are encrypted and access is exclusive to the GroupWise client. Combined with inherited security in NetWare, the GroupWise system is very secure. Access to the documents can be restricted via NetWare file rights. If rights are granted to the BLOB storage area, documents are still encrypted and can only be decrypted by the GroupWise client after proper login. If a user attempts to import a document from the BLOB, a verification process will occur that will determine if the user performing the import has previously accessed that document. If they have previously accessed the document the BLOB file will be decrypted and decompressed.
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.
- Document ID:
- Solution ID: NOVL65466
- Creation Date: 06Dec2001
- Modified Date: 25Feb2002
Did this document solve your problem? Provide Feedback