The Groove shared space of one (maybe it's two) When Groove was being designed, one of the goals was to create a platform that could ultimately be leveraged as infrastructure for collaborative applications. The idea was that Groove would provide the "plumbing" so that developers could focus on their application logic/behavior - things like security, communications, synchronization, cross firewall traversal, offline support would already be taken care.
Over the past few years many people at Groove Networks, including myself, have been educating people on how Groove helps fit into their collaborative applications strategies. We have discussed things like how to bring groups of people together into contextual environments. How to leverage swarming effects upon notifications of information/data changes. How to seemlessly share content with people across disparate organizations.
Recently I have been getting an education of my own with respect to how people envision uses for Groove and what they believe it's value to be. One of the more popular use cases that is emerging is the use of Groove as the secure, self-synchronizing, offline extension to an application/process that they use today. No collaboration per se, just allowing people to generate information and have it get sent to center based systems. For example, expense reporting systems are a main source of frustration for many people we deal with, with their primary complaint being the inability to enter information while disconnected from the server. They view Groove as a means by which this problem could be solved.
When I think about a high level design for such a solution, given that Groove deals with shared spaces that have members and tools, I start by considering who will be using the tool. While there may be many people within an organization who need to submit expense reports, it probably would not be a good design to create a single Groove shared space that has an expense tool in it for the following reasons:
- Groove's design center of 15-25 people. Arguably you could have more people in the space if the expense tool was the only tool in the space and the amount of data generated was small, but the space simply would not scale for large numbers of people.
- People probably should not be able to see each other's information/data . There are techniques by which the tool could hide/encrypt the data generated by the user so that other people can't read it, but the point is that Groove will ensure that the data is distributed to all members of the space. Why send data to people that they can't read/use?
So let's assume that there is only one member in the shared space and move on to the tool. Unlike many Groove tools, it does not make sense that more than one instance of this tool should be used for expense reports - essentially there should be one place for the user to go for submitting expense reports. This means having only instance of this tool in a shared space, and only having one shared space in which this tool lives. I would almost describe this as the "My Expense Reports Space" for the user - similar in concept to "My Messages" that can be found in Groove today.
So now that I've described the creation of a Groove shared space that has one member and one tool it need, I'll get to the last part of the design which is the manner in which data will be synchronized from Groove to the center based system. There are two models to choose from - direct and indirect.
Considerations for the direct model:
- Would require a connection between the Groove client and the expense reporting system via LAN/WAN/VPN or by placing it in DMZ
- Would require logic for checking for connectivity has to be built into the application, which can be tricky depending upon the system and the network connection, but is certainly doable.
- Would require queueing of pending changes. This means that the logic for storing changes when connectivity is unavailable and applying changes when connectivity is available has to be built into the application. Again, this is doable, especially given that Groove provides mechanisms for persistent queueing.
- Would always require client code to be updated when bug fixes/new functionality need to be applied, meaning every user must receive new version. This is important because there are 2 main parts to the solution - one part that handles Groove tool/data handling and one part that handles integration with the expense reporting system.
Considerations for the indirect model:
- Would require using a bot to perform the integration with the expense reporting system. This means that the bot has to be invited into the shared space so that it can detect when expense reports are submitted.
- Assumes that Enterprise Integration Server (EIS), the bot hosting mechanism, will have network proximity to expense reporting system (i.e. inside firewall and on same LAN as expense reporting system). This means that no VPN implementation/infrastructure is required, and no servers need to be placed in the DMZ.
- Does not require queueing of pending changes to be built into application. Since Groove handles dissemination of data to all members, when data changes are received by the bot, the changes will be applied to expense reporting system.
- Would require client code and/or bot code to be updated when bug fixes/new functionality needs to be applied. This means that if the tool code needs to change, every user still must receive new version. However, if just bot code (i.e. integration code) needs to change, only EIS must receive new version.
I'll continue to think about this will and will provide updates here...
2:20:17 PM 
|
|
