Hi, Andrus,
> This won't even require refactoring - Cayenne supports it already: > > http://objectstyle.org/confluence/display/CAYDOC/Generic+Persistent > +Class Thanks. I need it. > I still like to entertain the idea of a generic data service that > does not need a new WSDL definition when the schema changes. But I > also like your idea of WSDL serving as an EntityResolver to the > client. And I don't think the two contradict each other :-) My +1 on > that. I also think that currently it would be better to do as you say - static WSDL, etc. When this will work good enough, then we can think about changes. > > Actually it doesn't look like too many things to refactor. Everything > you outlined can be done as a thin layer on top of the existing > Cayenne stack (see the ClientServerChannel and generic object > comments above). If we limit the queries (at least for now) to just > NamedQuery with parameters, queries become trivial. ObjectId handling > can be skipped for queries too. > > However what is overlooked here is update capability. Even if we Yes... > Our design ignores "getEventManager" method (which is ok, let's keep > ignoring it), replaces "getEntityResolver" with the WSDL (which is > great), and addresses "onQuery". It does not address "onSync", i.e. > the update part. This is probably the most non-SOA'ish piece as it > requires a smart context on the client that tracks object changes and > submits the diffs for commit (and brings back the diffs generated by > the server on commit, such as generated PKs). > > I am open to discussion on this. The choices that I see are: > > * Ignore it for the purpose of this project :-) No good. :) > * Define simple serialization formats (or data transfer objects) for > GraphDiff and ObjectId. Both are just maps of values after all. This > of course is what requires client to be smart. I choose this way ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > * Pass around the entire objects instead of diffs. This approach, > while inefficient, is much more portable and reduces the requirements > for the client (if an object is new or dirty, send it back to the > server to figure out the changes). This leaves the question of how we > handle deleted objects (so at least a desired persistent state will > have to be attached to an object), and how do we pass back generated > keys for the new objects (we can make it a requirement for the client > to provide the key??) > Andrus, I think, it would be better to create AXIS serialization mechanisms for update and delete infrastructure. Clients on other languages must be very smart in this case, but it's ok. Let's say more: they must be as smart as Cayenne Java implementation. In few days I will try to show some work with synchronization (adaptation current Cayenne mechanisms). Let's see, how it will work, and then talk. > Andrus -- Best regards, Michael
