Thin Client Collaboration Web Services

1. Thin Client Collaboration Web Services Minjun Wang Department of Electrical Engineering and Computer Science Syracuse University, U.S.A mwang03@syr.edu Geoffrey Fox Indiana University, U.S.A gcf@indiana.edu Marlon Pierce Indiana University, U.S.A mpierce@cs.indiana.edu Presented by Ahmet Sayar Indiana University, U.S.A asayar@indiana.edu

2. Outline • Introduction • Problems • The Idea of Thin Client Collaboration Web Services • Thin Client Web Services in Collaboration • Deployment and Usage of Collaboration Web Services • Initial Effort and Future Work toward the Implementation of the Idea • Conclusion

3. Introduction • Collaboration applications over the Internet • Online conferencing, distance education, e-Science, e-Business, etc. • The advantage to make collaboration applications to be Web Services • The idea of Thin Client Collaboration Web Services • Separation of the native interface from the rest of the software, correlation of the native interface to a web service friendly user interface (e.g. in SVG & Java) • Two sets of ports: User-facing Input/Output ports (associated with a WS viewer) and Resource-facing Input/Output ports (associated with a resource) • Transcoding in both directions between the two sets of ports with respect to displays and events • Collaborative projects – collaborative PowerPoint, collaborative Impress and collaborative ReviewPlus – as resources; SVG related projects in converting some native data to SVG format.

4. Problems Difficulties with packaging the whole package of a collaboration application as Web Service: • If the package is big in size • Collaborative Impress of OpenOffice, as well as the whole underlying OpenOffice source • If the package is related to proprietary software • Collaborative PowerPoint, as well as the underlying Microsoft PowerPoint application • If the package itself is complicated in architecture and deployment, possibly involving fire walls • Collaborative ReviewPlus • If the package was developed in a language that has not yet had accompanying tools for developing web services

5. The Idea of Thin Client Collaboration Web Services • Transcoding in both directions between the two sets of ports with respect to displays and events • 1. [] Web Service takes the event message from the SVG viewer/Web browser to the input port (I) of the user-facing I/O [] translates the event message to the equivalence of the event structure of the native interface of the resource [] and directs the result to the output port (O) of resource-facing I/O. • 2. [] Web Service takes the output display of the resource to the input port (I) of the resource-facing I/O [] translates the information in the native interface to the equivalence in SVG format, [] and directs the result to the output port (O) of the user-facing I/O. • Separation of the native interface from the rest of the collaborative application, correlation of the native interface to a web service friendly user interface (e.g. in SVG & Java) • Two sets of ports: User-facing Input/Output ports (associated with a WS viewer) and Resource-facing Input/Output ports (associated with a resource – collaborative application)

6. Thin Client Web Services in Collaboration • Thin Client Web Services in the real Collaboration applications. • Three scenarios are proposed. We will be mentioning just one of them. • We use our collaborative projects as resources. Each has at least one master client that generates event message, and at least one participant client that consumes the event message. • The master and participant(s) communicate with and cooperate on the event messages. • The thin client web services contact only with the native interfaces of the clients and access/control them in collaboration. • The scenarios bring interoperability, flexibility and diversity to collaboration.

7. Thin Client Web Services in CollaborationScenario - 1 • The Master client controls the process of a session of collaboration, captures events and sends event messages to all Participant clients through NaradaBrokering (NB) event broker; the Participants do not interfere with the process, they just receive the event messages and render the same output displays as the Master under the instructions in the messages. • Only one instance of the Web Service is hooked up with the Master client of the resource, and the controller or lecturer is controlling the process through a WS viewer; at least one instance of the Web Service is hooked up with each Participant client, and the audiences or students are viewing the displays via the WS viewers. • The clients of the resource and the web service do not need to be deployed on the same location. • The WS Viewers can be any SVG rendering tools: SVG viewers, Web browsers, Personal Digital Assistants (PDA), or other mobile devices, because of one factor – the output of the web service to the viewers is in SVG format. This makes universal access to resources possible, and so for universal collaborations. Instances of a web service in collaboration, with only one instance for the master client and at least one instance for each of the participant clients

8. Deployment and Usage of Collaboration Web Services • Service Interface Descriptions are in WSDL • Web Service is published to a UDDI Registry service to make itself discoverable by the service consumers. • Resource consumers (collaborative applications) find and binds to the general Collaboration Web Service and cooperates with it through its resource-facing I/O; on the other end, a WS viewer performs the same procedure to bind to the general Collaboration Web Service and cooperates with it through its user-facing I/O. • More specifically, incase of a video conferencing, the speaker’s WS viewer is bound to the instance of the general Collaboration Web Service that has the Master client of a resource bound to it, and each audience’s WS viewer is bound to the instance of the general Collaboration Web Service that has the Participant client of the corresponding resource bound to it. • For each resource type, the Master client and the Participant client(s) collaborate on event messages via the underlying communication of the NB event broker.

9. Initial Effort and Future Work toward the Implementation of the Idea • Effort in the direction from the resource to the viewer, or from the resource-facing I/O to the user-facing I/O. Effort in the conversion of native interface data to SVG format. • A converter which converts HTML file to SVG file • A converter which converts files in WMF format to SVG format • Transcoding of events from the viewer to the resource, or from the user-facing I/O to the resource-facing I/O. • Converting other kinds of file formats to SVG format. • Automating the Web Service with resources as well as with WS viewers, and so forth.

10. Conclusion • In this paper we introduced some resources of collaboration applications, and the needs in making them to be Web Services. We proposed and described the idea of Thin Client Collaboration Web Services, and explored some potential scenarios of this idea in which it shows its merit and the freedom resulted in collaboration. • Such a Web Service has two sets of ports: User-facing Input/Output ports and Resource-facing Input/Output ports. The user-facing I/O contacts a WS viewer, and the resource-facing I/O contacts a collaborative application. Hence, the role of the Web Service is to transcode in both directions between the two sets of ports with respect to displays and events, so that the user accesses the WS viewer as if the resource itself. • We used our collaborative projects as examples of resources, and projects in SVG as the indication of our initial effort toward the implementation of a general Thin Client Collaboration Web Service. We described briefly the SVG projects, gave some results enough to indicate the effort, and pointed out the future work.

11. THANKS !The main author can be contacted for non-answered questionsMinjun Wang :minwang@indiana.edu