The publisher is a widget, which purpose is to send messages to the hub. It has input fields for a topic and a message; and a “Send message” button that transmits the message to the hub. Moreover, there is another button “Send complex message”, which sends a whole JavaScript object as the message. By clicking the button, a complex JavaScript object is assembled and sent to the hub. The subscriber is a widget that subscribes to all topics of the hub. If a message is sent to the hub, the subscriber outputs the message. If the message received is a JavaScript object, it is serialized to JSON for visualization. Screenshot of the working prototype can be viewed in Figure 9.
34
Under the mashed OpenAjax Hub widgets, there is a keyword input and a button to instantiate a Wookie-OpenAjax Hub Bridge. When the button is pushed the initWookieWidget function in wookieWidgetFactory.js is invoked. As a result, the invisible Wookie-OpenAjax Hub Bridge is initialized and a URL to identify the specific mashup is generated to the following input. In other words, the “id” parameter in the URL identifies the Wookie-OpenAjax Hub Widget instance, thus the widget instance can be reinitialized afterwards. This generated URL can now be shared between browsers or computers. Particularly the URL can be posted to Facebook’s wall for other users to view. The “post to wall” button is implemented in the manager.html as shown in Example 16. When pressed, the submitToWall function is invoked, which makes a request to the Facebook API that opens a dialog, like shown in Figure 10. If a user presses the “Publish” button, the link will be posted to user’s wall in Facebook. If the link is clicked in Facebook, the user is redirected back to the microsite. Due to the “id” parameter in the URL, the Wookie-OpenAjax Bridge will be revived.
<a href="javascript:void(0)" onclick="submitToWall()" class="fb_button fb_button_small">
<span class="fb_button_text">Post to Wall</span> </a>
Example 16. Facebook post to wall button.
Figure 10. Facebook Post to Wall dialog.
The Wookie-OpenAjax Hub Bridge initialization passes through the following steps. Firstly, a POST request is made via the proxy to the Wookie REST API to get a widget instance. The Wookie Engine composes a response, which is an XML document (see
35
Example 1 above). When the response arrives back to the microsite, a widgetResponseCallback is executed in the wookieWidgetFactory.js. The callback traverses the response XML and extracts Wookie widget’s URL. Then the initIframeContainer function creates an invisible HTML <iframe> element and loads the Wookie-OpenAjax Hub Widget in it with a GET request directly to the Wookie Engine. The widget will become operational after all its onload activities are done. The widget instantiation is described in Figure 11.
36
7. Conclusions and Future Work
This thesis focuses on the data sharing of widget-based applications by enabling mashups to store their states within application. Furthermore, it enables to exchange the states between applications. The latter enables usage of social networks in inter-application state exchange.
This thesis proposed a solution for the OpenAjax Hub enabled mashups to record and reproduce messages exchanged by widgets to overcome the limitations current platforms have. The Wookie-OpenAjax Hub Bridge implemented in this thesis, combines Wookie’s state storing abilities and the OpenAjax Hub’s message delivery capabilities to enable a mashup to store its state without additional coding. In other words, instead of implementing the state-storing mechanism for your system, this widget can be included to your mashup. Additionally, a test application was implemented to demonstrate the Wookie-OpenAjax Hub Bridge in action. The test application included two widgets in addition to the Wookie-OpenAjax Hub Widget. Furthermore, a feature to share the state of the mashup via Facebook was implemented in the test application.
As a future work, it is possible to improve the Wookie-OpenAjax Hub Bridge in many ways by adding features that could make the state sharing more intelligent. One certain direction to extend the solution could be to make the topics that the widget records or replays dynamically configurable. Some systemic data could be stored in the Wookie’s database besides the messages sent by other widgets in the mashup. This can be done by defining some special messages – a set of commands to manipulate the systemic data. For example, a microsite can send a special message, with a predefined topic that would define which messages would be stored and replayed. Of course there should be a mechanism to filter out all the systemic preferences not to replay them to other widgets. This enhancement allows scenarios where the microsite can dynamically manage, which parts of the state is restored from the database.
Yet another quite simple but crucial improvement would be to remove the messages from a Wookie-OpenAjax Hub Widget’s instance. This can be done by implementing a special command, which removes the preferences in the database. By utilizing this feature, resetting of the state of the mashup can be evoked.
37
Currently, messages with identical topics will be overwritten in the Wookie-OpenAjax Hub Widget. If that is not considered a feature, a technical improvement can be implemented. Depending on the expected outcome, messages that are currently overwritten could be added together, or perhaps ignored at all.
Another possible scenario for a future development is to add multiple Wookie-OpenAjax Hub Widgets to a microsite. These widgets can be configured in such a way that each widget instance would be recording different topics. This kind of approach would make possible to use these widget instances as separate sources in terms of mashups. These sources could be later used either separately or mashed with each other later. As an example of this scenario, let us imagine there is a mashup that deals with data from Central Commercial Register and Land Records. The responsibility to store messages could be shared by two widget instances correspondingly.
The Wookie-OpenAjax Hub could be improved by introducing a systemic read-only flag, which would denote whether the data stored in the Wookie’s database could be modified. This improvement would enable the mashup creator to lock the state before sharing it. In another words, one user could share the state of the mashup without worrying about the possibly unwanted modifications the other user could make.
To combine the latter and the penultimate, more sophisticated mechanisms could be developed. For example, branching which is common in Version Control Systems. In particular, if one user shares a mashup to another user, the state is copied from one Wookie-OpenAjax Hub Widget instance to another. As a result, there will be two copies of the state which will be modified in parallel by two different users.
38