|
Two
critical components of the platform are the plug-in
(middleware), and the Meeting Engine (the notion of plug-in is used
here in a loose sense. Technically, SRTC implementation for Internet
Explorer does not use a plug-in). Middleware has been introduced
to ensure high platform reliability. It also plays important role
in platform
security. The crucial idea behind middleware is that collaborative
tools cannot communicate directly with the messaging server. Instead,
they use middleware method calls for such communication. The middleware
acts as a message filter and multiplexer, preventing applications
from sending ill-formed or illegal messages. An ill-behaved tool
might not work but it would not disturb the overall platform operation.
Use
of the plug-in as data multiplexer simplifies implementation of
the messaging server.
Each platform client connects to the engine just once. A proprietary
protocol provides all services necessary to identify message sources
and addresses. In absence of the multiplexing plug-in, each application
would have to open a separate connection to the messaging server.
Such a solution practically precludes implementation of strong and
coherent security mechanisms. In the TI platform secure communication
is implemented between the plug-in and the messaging server.
The
messaging server is a central element of the platform. It is
primarily responsible for message routing. The first thing
to understand about the TIME is that it is not an HTTP server.
Meeting Engine is more like an IP router. It makes sure the messages
get to the intended receivers. Unlike a router, though, a collaboratory
Engine accepts permanent connections and it holds a considerable
amount of state. The Engine works together with all active instances
of CollabWorx Session Managers
to to establish a fault-tolerant state of the collaboratory sessions.
In user terms, TIME is a meeting point in the cyberspace. Each
TIME can support one or more communities, and multiple Engines can
support branches of the same community. On the communication level,
each Meeting Engine accepts connections (via middleware layer) from
an arbitrary number of Session
Managers. All events created by application modules connected
to active Session Managers are sent to the Engine and then properly
distributed.
In
contrast to data servers such as HTTP or FTP, ME does not perform
any local file operations. For its authentication and authorization
functionality, ME communicates through encrypted connection with
the database placed behind the firewall. Optionally, digital certificates
may be used for authentication during database access to eliminate
possibility of ME spoofing. The database is accessed by ME in
read-only mode. The reason for this approach to ME security design
is that the messaging server cannot be placed in a highly secure
environment without seriously impairing its basic function of message
routing. In the case that ME is broken into, the server does not
provide any means to further compromise OS or data source security.
As
shown in the platform diagram,
SRTC platform has one special collaboration tool, the Session Manager.
The tool is implemented as a portlet, and, depending on platform
configuration, it may present platform user with a graphical interface,
or it may be hidden, in which case its operation is defined by startup
scripts. Session Manager (SM) uses special protocol to communicate
with the plug-in. This protocol supports complex and potentially
unsafe operations such as loading the application code and data
and starting application execution on remote machines. SM tool participates
in user authentication and authorization, and it also provides unified
mechanism for meeting floor control. Under these circumstances,
code and communication protection of SM is critical. SRTC solves this
problem by digitally signing both the SM and middleware code and
by verification of digital signatures before communication can be
established.
SRTC
platform achieves scalability
and high performance by making a careful distinction between
the data and event communication channels. Let us
consider a shared browser tool. In the popular shared display (a.k.a.
shared screen) mode of collaboration, a master browser would download
the data from a Web server, and then the platform such as NetMeeting
would replicate display of the Internet Explorer on the workstations
of all shared browser session participants. This clearly is not
an optimal solution. SRTC platform works differently: under the control
of Session Manager, a shared browser tool is started on multiple
workstations. The session chair, or master, selects a URL to load
into the browser. The browser sends the URL to ME, which, in turn,
distributes it to other instances. The “slave” instances download
the URL from the same Web server or, if the platform URL mapping facility
is used, from a replicated server. With properly configured topology
of the platform it is possible to have sharing of HTML documents while
incurring only minimal network traffic. The same principle can be
now used to capture browser events such as page scrolling, DHTML
layer control etc. Shared browser perfectly demonstrates all advantages
of event sharing.
Clearly,
the same principle can be used to implement a shared whiteboard,
or a shared world described by a VRML scene graph. Event-sharing
methodology of state sharing works best if the amount of information
necessary for state synchronization is small compared to the amount
of “static” data. In our solution, dynamic data is distributed via
messaging server; static data always comes from Web infrastructure,
which is either Web-server based, or, as we stated above, is based
on a arbitrary peer-to-peer data manager.
Event
sharing principle can be also used in case of a chat application.
We can distribute chat messages via ME, since chat messages are
short and, being generated by humans, infrequent. The paradigm breaks
with applications such as audio-video conferencing. The data streams
become “fat” and they are also time-sensitive. In such case, SRTC
platform uses TIME only to establish collaborative sessions of
the specialized tools, such as an audio
or video conferencing, and it allows the tools to use their
private communication channels. This is a mechanism very similar
to the H.323 approach, where Q.931 and T.245 protocols are used
to establish the “calls” and then RTP protocol is used to distribute
dynamically created data streams in the peer-to-peer mode, optionally
using IP multicast to minimize necessary network bandwidth.
|
