1. HOOPS/Net Server Introduction

2. HOOPS/Net Architecture

3. Platform/API/Network Protocol Support

4. Sample Usage Scenarios

1. Introduction

The use of collaboration within companies varies greatly between forms of synchronous and asynchronous collaboration including: publishing of data to web repositories; simultaneous view and mark-up; real-time co-modeling; customer focus sessions; or CAE analysis interpretation in a virtual setting. Using forms of collaboration, manufacturing organizations can leverage the benefits of collapsed time-to-market, improved product design, and a tighter link with suppliers and customers.

The HOOPS/Net Server is a multi-tier client/server framework that facilitates the creation of new collaborative applications and the addition of collaborative functionality to existing applications. It provides built-in support for a variety of networking environments and communication paths, and can be customized to support additional environments, protocols, and application-specific features. The HOOPS/Net Server is complementary to, but independent of, other modules in the HOOPS 3D Application Framework.

2. HOOPS/Net Architecture

Server Architecture

The primary features of the HOOPS/Net Server include:

Core Logic

This logic manages collaboration sessions, which involves storing session and user information, providing facilities for adding/removing users, and forwarding messages to client(s). The core logic is supported via a set of built-in message handlers.

Customization ('Plug-In') Interface
Custom functionality can be 'plugged into' the server by registering custom message handlers via a callback mechanism. The server will dispatch a user-defined message to a matching user-defined function that has been registered to handle the message.

The server interfaces with the protocol-independent HPI interface to send/receive messages to and from clients. The pre-built drivers for the TCP/IP and HTTP protocols encapsulate protocol-specific logic and developers do not need to deal with any server-side networking issues when using them. If a different transport/communications mechanism were to be desired, an HPI driver could be created to abstract the core server from the transport details.

The server also provides support for registering user-supplied password and encryption functions.

Client Architecture

The HOOPS/Net client module (HNET) also consists of an HPI interface that abstracts the developer from the underlying network protocol details. The HPI interface is used to send/receive messages to and from the server. Similar to the server module discussed above, pre-built HPI drivers are included for the TCP/IP and HTTP protocols. (The message types are discussed in the following section.) A number of customized HOOPS/MVO classes are provided as a reference implementation of collaborative view/markup functionality.

HOOPS Protocol Interface Drivers

TCP/IP
The HPI driver for TCP/IP consists of a fairly straightforward wrapper over the TCP/IP functions. This driver would typically be used in corporate Intranets where the clients and server reside on the same LAN, or in situations where the client and server can talk to each other over the Internet but can use a direct connection (perhaps through a port that has been opened in a firewall). It would probably not be used if the client were running inside a web browser since the only available/acceptable protocol might be HTTP.

HTTP
The HPI driver for HTTP maps the outgoing and incoming messages to the appropriate HTTP commands. This is usually referred to as "HTTP Tunneling" and is the preferred communication method when no other alternative is available (for example, when only HTTP connections are allowed because the client is behind a firewall). In this scenario the HOOPS/Net Server communicates with the HTTP-Server via a custom CGI/Script (similar to a backend database application) and local domain sockets.

Message Types
The various message types can be broken down as follows:

Built in Client to Server:
The client sends a message that is supported by core server logic, such as 'JoinSession'. The server processes the message, and sends a confirmation to the client.

Custom Client to Server:
The client sends a message that has a custom handler registered with the server, such as 'CalculateFluidFlow'. The server dispatches the message to the appropriate message handler. The custom message handler may utilize the HPI programming interface to dispatch messages (which may include data) back to the client(s).

Custom Client to Client:
The client sends a message that is not understood by the server, but is intended to be sent to other clients for client-side processing, such as 'SetCamera'. (The message is neither built into the server, nor registered with the server as a custom message handler.) Such a message is automatically assumed to be a 'collaboration' message, and will be forwarded to all other clients, or perhaps to a specific list of clients depending on the recipient list included in the message header.

3. Platform/Network Protocol/API Support

Both the client and server modules are supported on all major Unix and Windows platforms and on Linux. (For a detailed list of supported platforms and compilers please refer to the HOOPS/3dGS platform support notes in the Platform and Device Guide.)

Built-in networking support is provided for the TCP/IP and HTTP protocols via pre-built HPI drivers. These drivers reside on both the client side and server side.

The client-side HPI interface is C++ based and is natively built for each platform. The set of custom HOOPS/MVO C++ classes that interface with HPI are platform independent. The server module itself is written in C++ and is natively built for each platform.

4. Sample Usage Scenarios

Creating a Collaborative View/Markup Client Application

One of the most common uses of the HOOPS Net Server will be to provide collaboration view/markup capabilities where users can work with shared views by interacting with them, marking them up, etc... Typically, a shared view would be controlled by one user at a time and requests for control could be made/granted. In this situation, the built-in collaboration and session management features, along with the high-level HPI interface on both the client and server, address the server-side needs of such an application. The clients themselves would support a set of custom messages handled via client-side logic.

For example:

1. A client initiates a session by sending a 'CreateSession' and 'JoinServer' message to the server. The session consists of a shared view of a custom HSF file that resides on a remote server and is streamed to the client. This client has control of the shared view.
2. Another user connects to the server to get the list of sessions, and sends a 'JoinSession' message to connect to particular session. The shared view is created.
3. The client with the control interacts with the shared view via panning, zooming, orbiting, performing a walk-through, etc… As the interaction is progressing, or perhaps at the end of the interaction, the client sends a 'SetCamera' message: SendMessage[msg_type, msg_data]
4. The server is not registered to handle SetCamera message, and forwards them to the other client.
5. The 'view-only' client gets the message and a call is made to the appropriate camera manipulation functions.

Note: The sample client-side implementation of common view and markup messages/logic is provided via a set of custom HOOPS/MVO objects that interface with HOOPS/3dGS. However, the client does NOT have to use HOOPS/MVO, HOOPS/3dGS, or any other HOOPS 3D Application Framework modules. It could simply use HOOPS/Net for collaboration session management and message passing, while using an existing application architecture and logic to handle all other functionality.

Adding Custom Server-side Data Streaming Logic

The HOOPS 3D Application Framework includes support for creating and streaming HOOPS Stream Files (HSF files). The HSF format is highly compressed and stream-enabled. Currently, HOOPS/3dAF only utilizes client-side logic (via the use of the HOOPS/Stream Toolkit) to stream over HSF files residing on a remote location such as a file server or web server. One logical area for server customization is to add HSF streaming logic that leverages the customization capabilities of the HOOPS/Net Server, as well as the high-level HPI interface on both the client and server. The following two scenarios outline where server-side logic would be utilized:

Partial/On-demand streaming:
Rather than simply streaming over an entire HSF file in a serial fashion, the client may choose to pull over the lowest level of detail (LOD) for all the objects in the HSF file and then give the user the ability to pull in the full resolution of objects (and perhaps attached user-data) on demand. Because this 'sweetening' process requires random access of the remote HSF file, server side logic and a message-passing mechanism is required.

View-dependent streaming:
First, either the client or the server would do the work of checking which items are coming 'into view'. Then, specific objects stored in the file would be streamed over from the server to the client. Again, this requires randomly accessing the remote file, which requires server side logic.

This custom server-side logic would be exposed via a new set of messages supported by the server, such as 'GetEntity'. Clients could then optionally utilize this additional functionality to enhance existing support for streaming of HSF files.