Integrating WebHuddle:
Adding WebHuddle as a sychronous-meeting module to another J2EE application.

Charles Roth, croth@q2learning.com.
Copyright (C) 2007 Q2Learning LLC.
Original version: 12/03/2007
Last revised 12/06/2007

  1. Introduction.  WebHuddle is a lovely open-source synchronous meeting application.  It uses J2EE/Struts on the server side, with a Java applet on the client side, to provide:

    WebHuddle is a self-contained application.  But it is arguably even more useful when treated as a module in a larger "master" application.  In our case, we've extended WebHuddle so it can be launched from Q2Learning's commercial "eCampus" product, which is a sophisticated asynchronous collaboration and learning platform.

    The particular values of WebHuddle to us were:

  2. Our Integration Needs.  Our "eCampus" product is the master application.  Users login to it and we expect them to be able to create, see, and join WebHuddle meetings without any further authentication.  So the integration "connections" we needed with WebHuddle were:
    1. Create new meetings.
    2. Create moderators (aka the user "hosts" of WebHuddle meetings).
    3. Join meetings.
    4. Capture meeting data (chat text, etc.) so we can use it directly in the master application.  (This item is still under development, but we believe that it is possible.)

    Out-of-the-box, WebHuddle provided for many, but not all, of our needs.  But we found that by (a) writing a wrapper class that simulates some browser interfaction, and (b) making a few very small extensions to the WebHuddle code, we were able to meet all of these needs.

  3. The WebHuddle API.  WebHuddle provides some services via a few simple web-service-like URLs, in particular, "create meeting" and "join moderator to meeting".  We have reformatted the original API documentation into HTML, and made a few corrections -- see WebhuddleAPI.html.

  4. WebHuddle wrapper class.  Since the WebHuddle API does not currently provide for our other needs, we've written a java "wrapper" class that simulates a user stepping through the web user interface.  In particular, by calling the wrapper methods, we can now:

    Our approach is described in the wrapper class javadoc

    At the moment, the code for this class is proprietary, although we are considering GPL-ing it.  (Equivalent donations of other code by other parties would be a motivating win-win consideration.)  But writing similar code is not intrinsically difficult; the hardest part is parsing the generated HTML in order to simulate a user's browser interaction.

  5. WebHuddle code changes.  We also had to make a few, very small, changes to the base WebHuddle code, in particular to support the "join a user to a meeting" capability.  These changes are published below, as required by the WebHuddle GPL license -- and described in some detail because we like WebHuddle and want to "give back".

    1. In EnterRoomAction.execute(), in the "else" block of if("enter".equals(action)), the code takes parameter values from the 'request' and copies them into the EnterRoomForm.  We've added:
         erForm.setEmail(request.getParameter("email"));
         erForm.setParticipantName(request.getParameter("participantName"));
      

      This makes it possible for the "j.do" URL (from which a user can join a meeting) to pass along the user's email address (aka their WebHuddle userid) and their full name, without having to actually type those values into form fields.

      (It should be possible to add these two lines to the master WebHuddle code w/o compromising or changing its function; but that, of course, is up to the primary WebHuddle developer(s).)

    2. In wmTemplate.jsp, we've added the ability to call a custom Javascript "onLoad" function.  Right after the <html:base/> tag, we've added:
         <script language="javascript">
            function callMyOnLoadIfExists() {
               if (window.myOnLoad)  myOnLoad();
            }
         </script>
      
      And changed the <body> tag to include onLoad="callMyOnLoadIfExists();".

      This means that any JSP page that includes wmTemplate.jsp may have its own definition of "myOnLoad()", which will then be called when the page finishes loading.

      (This code could similarly be added to the master WebHuddle distribution.)

    3. Finally, we've changed enterroom.jsp to take advantage of #1 and #2, and simply made it submit itself as soon as it is loaded.  So right before the <html:form> tag, we've added:
      <script language="javascript">
         function myOnLoad() {
            document.enterRoomForm.submit();
         }
      </script>
      

      (This is an incompatible change, but it could easily be cleaned up by, say, adding another querystring parameter to j.do, say "autosubmit=1", passing it through EnterRoomAction to the EnterRoomForm, and then having myOnLoad() check it.)

  6. Configuring for port 80.  It's actually very simple to arrange to use WebHuddle over port 80, which keeps from running afoul of corporate firewalls.  We use Apache to redirect port 80 requests to a virtual host, to port 8080 (WebHuddle's default port).  Here's a sample Apache virtual host file:
       <VirtualHost 111.222.333.444 > 
          ServerName webhuddle.myserver.com 
     
          ProxyVia on 
          ProxyPreserveHost on 
          ProxyPass / http://127.0.0.1:8080/ 
          ProxyPassReverse / http://127.0.0.1:8080/ 
     
       </VirtualHost> 
    

    This assumes that Apache and WebHuddle are running on the same server.

  7. Future thoughts.  In the near future, we expect to also implement and document:
    1. How to extract data from recorded WebHuddle meetings.