Another possible direction with ROP is to strip it down to a very simple and performant "ORM proxy":
* define a protocol for protobuf and JSON serialization (still need to look at Kryo). Limit it to the smallest usable subset of queries (EJBQL is a good candidate ... any other object select can be translated to it) and generic update operations. * make the server generic - use generic entities instead of precompiled Java classes. * remove stateful ObjectContext layer from the server. Perhaps serialize DataRows directly (can be tricky with prefetching, but doable). Will still need request-scoped ObjectContext for commits I guess. While this will take away the ability to add business logic to the server, it has a number of advantages too: * no more modeling the client and server separately and messing with 2 sets of classes * possible to package server as a reusable Docker image that will automatically run against any DB (perhaps with auto reverse engineering of the model [1]). * simplicity of writing a client. E.g. Apple just open-sourced Swift. To the best of my knowledge Swift has no decent DB drivers or ORM. A reusable Java/Cayenne proxy with clear protocol would allow writing a Swift ORM with a fairly low effort. Same goes for other languages. * even LinkRest can probably use such an ORM proxy via a Java ROP client Thoughts? Andrus [1] Imagine you do this: # Docker used as an example; proxy can be packaged in many different ways $ docker pull cayenne/proxy # Start the proxy. On first run it reverse-engineers # the DB and drops the XML somewhere $ docker -p 1234:1234 run cayenne/proxy <db_url> # you open XML with the Modeler, # tweak it to your liking, save and put in Git # the server auto-reloads # On subsequnt runs, DB changes are detected and merged into the Model # "client" is the client to the proxy; # it can actually be a server-side app cd client/ mvn cgen-from-proxy # now you have your app...
