Skip to Content
Author's profile photo Former Member

Gravity, Realtime Collaborative Interfaces and Why Google Wave?

Last week at TechEd Bangalore, Marilyn Pratt and I were having a conversation about Gravity – Collaborative Business Process Modelling within Google Wave, we talked about how innovative it was and how such collaborative user interfaces could be useful in various different business applications, in addition to just BPM. During this discussion, I expressed to her that I don’t understand why Google Wave was chosen as a platform for building Gravity … don’t get me wrong, I really like Wave and I’m very excited about its potential, but at the same time I realize that Wave will probably not become a reality in our workplace for another few years. Gravity, on the other hand is something people have a need for today and that is the reason I wonder why it was not built on a platform that can be delivered sooner.

Looking at the Gravity – Collaborative Business Process Modelling within Google Wave I can make out that the core functionality Gravity needs from Wave is the ability of keeping multiple clients synchronized to create a realtime collaborative environment, which is what makes me wonder, since creating such an environment should be feasible outside of Wave, I’m thinking XMPP, JMS or even a simple custom protocol.

Later that night, I spent some time actually writing a rudimentary prototype of such a server. I’ve been learning Erlang for the past month or so and creating such a server seemed like an interesting learning exercise. So 47 lines of erlang code later, here’s what I had …          

 

As you watch the above video, note as I drag a rectangle in any one Flash application, its sends messages to the server and the server multicasts those messages to other connected clients and those clients update in almost realtime. While in the example above all the application instances are running on the same system, they could just as easily be running on different system in the browser and still communicate via the server.
 
Here’s the code for the Erlang server ..
 
 

Click to download code

  

This ability of having realtime synchronized clients, as I understand it, is the primary ability that Gravity needs from Wave which is why I’m puzzled.
 
It should be feasible to build Gravity’s realtime messaging on top of existing solutions like Adobe’s Lifecycle Data Services, XMPP or even custom protocols like a more elaborate version of the code I wrote above, so I wonder what were the reasons to choose Google Wave as the base for building Gravity. I’m also curious if Gravity’s messaging layer is replaceable with some other protocol, if so, then I would love to know if the team behind gravity is considering any other such options.
 

Assigned Tags

      6 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Mrinal,

      thanks for the blog. I asked myself the same questions. At first, when I heard about the use of Wave together with BPM - and not knowing Wave at this time - I thought that Wave had the capability to collaborate on shared documents that were restricted by a metamodel. In other words, I had the naive idea that Wave allowed to load a BPMN metamodel and declare graphic bindings to each of the elements of the metamodel, and then allow users to graphically edit models within the constraints of the metamodel.

      In fact, as I understand it today, Wave does not have any of those capabilities, except the document sharing and collaboration capabilities that are also at the core of your Erlang demo.

      I have not read up on Gravity, so I'm not sure how the SAP Research colleagues really integrated the BPMN graphics. I suspect they built a plug-in, but that still means that they only made use of the part of Wave that is equally present in Erlang. I suspect the Scala implementation of ESME would provide a similar starting point for realtime collaboration.

      So, where does this leave us ? I think you put your finger right on the issue. If Wave were a fully adopted part of everybody's desktop, that would make it somewhat natural to use it, but that's not the way it is. So right now, I only see a dependency on Wave (which is not even open source). Instead, Erlang is open source available under a BSD license.

      There is still much more work to be done, like to persist documents, and use an editor that understands the BPMN metamodel. However, you could argue that the editor already exists in form of the Galaxy Eclipse BPMN editor, but is unfortunately not open source right now. If it were, we could take your ideas and innovation further immediately.

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi Michael,

      Thank you for the comment, and you're right ESME could be used as a starting point for this as well, could be any messaging server for that matter .. although ESME uses long polling over HTTP (so does Google Wave I think) .. while my example above and servers for IM protocols like XMPP etc. create their own TCP socket .. so there is no periodic polling but instead a push from the server when needed.

      While in case of microblogging, the comet/long polling approach works fine ... in the use case we're discussing here, where many messages have to be sent at very short intervals (as the rectangle is being dragged) .. I feel the open TCP stream might work better, we could send extremely compressed binary data, since the clients in conversation are programs (not humans like in case of microblogging) they can easily understand a binary format.

      In the Erlang/Flash example above clients exchange AMF encoded binary data over a TCP Socket  to communicate with each other. A client sends an AMF encoded binary message to the server and the server multicasts that message to all connected clients. AMF is native to Flash and extremely compressed so deserialization to an ActionScript object is very fast.

      Taking it a step further, the latest Flash Player 10.1 (still in beta) can actually create Socket servers, earlier versions could only create Socket clients, now if we could have socket servers in each flash client then one could imagine a peer-to-peer kind of arrangement as well, which would drastically minimize the load on the server in the above arrangement .. I still have to explore Flash Player 10.1 in more detail though.

      Mrinal

      Author's profile photo Former Member
      Former Member
      ...and as one of the first few "Wavers" (I built a couple Wave robots the week after Google I/O), I'm encouraged by the new modalities of communications that it enables but not as bought into the hype  that Wave is the only way to achieve it.

      It seemed that a lot of the "goodness" of Gravity was in the great job that Alex and team did with the  Gadget and the magic behind it, but it also seemed that it could be brought to life with any near-real-time messaging infrastructure and any container (AIR, browser, Flex, Silverlight 4, etc.)

      I, for one, would love to see native XMPP support become part of the next generation/HTML 5 browsers, much the way XML and AJAX support was provided in the last generation.  Think of the possibilities!

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      XMPP built into browsers and accessible to web pages would be very cool indeed
      Author's profile photo Krishnakumar Ramamoorthy
      Krishnakumar Ramamoorthy
      Mrinal

      Good blog and I don't know much about Erlang, but how does security play in to this. I understand with  Google wave, you could control security across system and network boundaries and may be one reason for choosing Google wave for gravity? My 2 cents..
      KK

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi KK,

      Good point about Security, I'm not sure what is the proposed model of security in Google Wave .. clearly the current use of  google id is not going to be acceptable in enterprises.

      Erlang is just a programming language+VM so you could build a security system in it and plug it into existing mechanisms.

      That aside, if someone were to build such a system ..it would make sense to take advantage of maybe the Portal or however Webdynpro apps provide security ... by embedding the Flash app in the portal or inside a WebDynpro application as an Island. The realtime system will be outside of SAP but this realtime system doesn't need very a complex security setup .. since this realtime system could only be responsible of communicating position of certain drawings on the screen .. and these messages it passes around could be totally disconnected from any business data, which lives inside an SAP system

      Thanks,
      Mrinal