On 11/21/13 6:30 AM, Frank wrote:
Dear Collegues,
how does Hessian support versioning. ZeroC guys described the problem
nicely:
*/from the zeroc website/*
*/Once a distributed system is deployed, it requires maintenance to
accomodate bug fixes and improvements. With conventional technologies,
it is difficult to do this because changes to interfaces or data types
break the existing on-the-wire contract between client and server,
forcing all components of a system to be upgraded at once./*
*/Ice provides two solutions for dealing with this problem. Using
optional values, data members and operation parameters can be added
and removed without breaking the on-the-wire contract. With facets,
you can add new features or change existing features in an elegant and
non-intrusive way. You can easily make changes such that they remain
backward compatible and, therefore, upgrade a distributed system
gradually./*
How does Hessian support versioning ? Feedback would be appreciated....
At least for Hessian, it's best to think of versioning as a set of types
of changes that can be handled.
Specifically Hessian can manage the following kinds of changes:
1) if you add or drop a field, the side that doesn't understand the
field will ignore it.
2) some field type changes are possible, if Hessian can convert (e.g.
int to long)
3) there's some flexibility on map(bean) types, depending on how much
information Hessian has (which is a reason to prefer concrete types.)
So, if the sender sends an untyped map {"field1", 10} and the target is
known to be MyValue { int field1; }, then Hessian can map the fields.
But it cannot manage things like:
1) field name changes (the data will be dropped).
2) class name changes where the target is underdefined, like Object
field1. If you send a MyValue2 as the new field1, when the previous
version was MyValue1, Hessian can't make that automatic transition. (But
as with #3 above, a "MyValue2 field1" would give Hessian enough
information to translate.)
3) class splits, e.g. creating a subclass and pushing some fields
into it.
4) map to list or list to map changes.
-- Scott
_______________________________________________
hessian-interest mailing list
hessian-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/hessian-interest
_______________________________________________
hessian-interest mailing list
hessian-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/hessian-interest
