Hi,

So we have several applications where we follow a similar pattern. We use
java EE but any framework that allows you to intercept your business
services and supports JPA EntityListener's should be capable of directly
implementing this.

Our EntityListener implementation has a @PostPersist, @PostUpdate and
@PreRemove that captures the delta of the jpa entity. These deltas are
stored in TransactionSynchronizationRegistry. We need to use the registry
rather than thread locals to deal with EJBs that are run in separate
threads.

Then we add an interceptor on our business services and the boundary/very
first service that is invoked by the client is responsible for collecting
all the changes out of the TransactionSynchronizationRegistry and routing
them to "interested" clients. The clients then receive the deltas and apply
them to their local model. The changes are packaged up into one message per
transaction, which ensures the client-side state is always consistent.

The content based routing is the hard part. Clients subscribe to "graphs".
Typically we define graphs that have a single root entity. When an entity
delta is routed we allocate it to 0 or more graphs. Then the graphs
determine which clients the delta is routed to. Then the deltas are
aggregated into a single message for each client.

Imagine a domain model as simple as the following.

class Company { int id: String name; }
class Person { int id: String name; Company company; Person reportsTo; }

And there is two possible subscriptions. You can either subscribe to a
Company and receive all changes for a company or you can subscribe to a
person and all the direct reports.

So if we imagine data like

Company {1, "Bobs Bobcats"}
Company {2, "Marys Mowers"}

Person {1, "Bob", 1, null}
Person {2, "Bill", 2, 1}
Person {3, "Mary", 2, null}

So imagine a change happens to Person 2. The change would be associated
with the "Supervisor Graph" rooted at Person 1 and it would be associated
with the "Company Graph" rooted at Company 1. If a change happens to Person
3. The change would be associated with the "Company Graph" rooted at
Company 2.

The changes are pushed out to the clients based on a combination of long
polling, server-sent events and websockets.

Of course this is quite complicated so we have a DSL that generates the
majority of this with a couple of extensions points where developers can
write routing code etc.

Mostly this means have fairly complex apps with up to 80 entities that are
replicated to the client with most developers being completely unaware of
how it works and being able to write simple code paths. The UI developers
only care about receiving changes and reflect them on the UI, the server
side developers just write simple state transform code, the network layer
is extremely efficient and it is trivial to build multi-client interactive
applications.

HTH

On Wed, Dec 10, 2014 at 4:27 AM, andymel <soundnee...@gmail.com> wrote:

> Hi,
>
> I think about how to implement a *browser GUI that primarily will show a
> list of a lot of data objects*. When something is added to the list on
> server side or one of those objects is changed, the client side *GUI
> should be updated*. So I need a *server push*. I already have a websocket
> connection and used the AutoBean functionality for something else. In
> theory I could immediately implement the whole thing by either pushing the
> whole list each time something is changed or even do any suitable caching.
> But I'm relatively new to GWT and I'm sure there are a lot of things that I
> don't know yet. I'm curious* how people with more experience would
> implement it*.
>
> During my research today I discovered the RequestFactory where caching
> seems to be included. At least I found the sentence *"Furthermore, the
> EntityProxy interface enables RequestFactory to compute and send only
> changes ("deltas") to the server.*" Can this be used to have a
> List/Result entity on the server and client that is updated automatically
> with just a little bit of traffic in between without thinking about what
> was changed by myself?
>
> Do you recommend anything else for this use case?
> Thanks in advance!
> Andy
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,

Peter Donald

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to