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.
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.