Matthias Ernst's Weblog

Maybe it's time to think a little further

If you're bored of the "property" word, please skip.

If not, you may note that some of the REST principles apply to properties:

We expect to read a property without visibly affecting the object. Reading properties is supposed to be a safe operation. We also expect setting the same value for a second time to have no tangible effect. Setting properties is supposed to be idempotent. The values we see from properties may or may not be the actual state of an object, they are merely a representation.

In a distributed, concurrent environment, atomicity also is of concern. I feel progressively unsure about using an array of setter invocations for reconfiguration of a service, e.g. through JMX. The REST way of PUTting an entire representation of the -desired- resource's state looks a lot safer to me. It gives the object a chance to implement atomicity. Recently, we built a service that is reconfigurable through PUTting an entire configuration document, and this approach feels really solid compared to fine grained remoted JMX-based management. The admin UI operates not on the object but on a representation of its state and then submits it to take effect.

What is my point? I believe that applying REST principles to OO programming lends itself to separate the "life" objects with their logic from "dumb" state representations that can be manipulated or bound to. We might not want to bind UI elements directly to property methods. We might rather go and implement representations through simple structs w/ fields that are also nicely transported, persisted, versioned, ... Putting that state into side-effects would be of no concern at this stage. Useful linguistic support would be compile-time checked field references so we can bind some UI element to a field of the state representation.

There's a ton of open questions - no question about that. And this may be a pile of bull. But thinking about how representations (external ones, too), state, binding, ... all fit together is definetely a larger topic than just syntactic sugar around field declarations.

Comment by Eamonn McManus @ Jan 15, 2007 2:58 PM:

Atomicity and JMX

Hi Matthias,

Re your entry "May it's time to think a little further", indeed I think configuring a JMX object with a sequence of setAttribute operations is suboptimal. There are a few ways to avoid this within the JMX API:

• As of Java SE 6, you can use an MXBean with a single complex attribute representing the collection of values to set. This is basically a "struct". Because it is mapped to a standard Java type (CompositeData) the potential problems with versioning and serialization are reduced.

• In earlier versions you can still use the MBeanServer.setAttributes operation to set a bunch of attributes at the same time. But there's no way to require that the attributes all be set together, and there's some work needed to make the set atomic. It doesn't have to be very much work though, for instance using this idea from Nick Stephen.

• An alternative to both of the above is to have an MBean operation rather than an attribute, the parameters to which are the values to set. This means there's no longer a way to set just some of the values, which overcomes the chief drawback of the preceding approach; it also works better with management consoles such as JConsole than either of the two alternatives. The operation can be called setSomething without ambiguity.

I'm not sure how this fits into the wider debate about properties, though. I think the questions that arise when setting things remotely are distinct from the questions that arise for local objects, though they do overlap. In particular the idea of extending the JavaBeans conventions so you can have a setter that sets more than one thing seems interesting. One of the advantages of immutable objects is that you can't get an inconsistent object state by an unfortunate combination of setters, but the same advantage could be had by only providing setters that set enough properties to retain consistency.

Aren't properties objects?

Surface syntax aside, implementation-wise a property is all object-like and I'm surprised we're still talking generating methods according to a naming convention. A property *has* setter and getter, it can be referenced, especially in order to bind it to a UI component, you can attach listeners, ...

ValueModel anyone?

public final RWProperty<String> name = new Slot<String>();

mernst.name.get();
mernst.name.set("matthias");
mernst.name.attachListener(...);
label.bind(mernst.name);

Comments

Stephen Colebourne @ Jan 13, 2007 7:28 PM:

Hi,

See my blogs about this

http://www.jroller.com/page/scolebourne?entry=java_7_property_objects
http://www.jroller.com/page/scolebourne?entry=more_detail_on_property_literals

And responses including
http://blogs.sun.com/abuckley/entry/properties_in_java

Also
http://joda-beans.sf.net

As for whether
> mernst.name.get();
> mernst.name.set("matthias");

should be exposed to the application code, I'm not yet convinced that isn't too big a leap from the current conventions. It would be nice not to have get/set methods though.

Understanding the threats posed by XmlHttpRequest vs SCRIPT

Stefan agreed and received comments that matters just ain't so.

I admit that my experience with XSS is not extensive, so I went reading, too. I'll try and formulate the understanding I've reached now (main source being Jeremiah Grossman):

The fundamental threat of XSS is that a script from site A (attacker) has the browser talk to site V (victim) (using V's cookies), having V reveal some sensitive data, and consequently transfers this data to A. That's why cross-site XHR is prohibited. In contrast to XHR, SCRIPT tags cannot read the response and thus not make any malicious use of it. Instead, the SCRIPT response is evaluated as executable Javascript code by the browser. If V never responds with the data in an executable format that data is safe from A. Thus SCRIPT tags are allowed to load scripts from a different site.

Now it has become popular to return data in JSON because it is so accessible from Javascript code. When this data is evaluated by a SCRIPT it gets dangerous since a clever script can intercept the inocouusly looking array- and object constructors and intercept the data - or easier, instruct the server to pass the data to a callback function, which seems to be popular, too.

Conclusion: only data in executable format, returned on a GET authenticated through a cookie, is in danger of being hijacked through a SCRIPT tag. But that's more a fault of the server than the browser security model.

Two notes on current controversies

On the JSON v XML debate: what good is a same-domain requirement for XmlHttpRequest if you can do a GET on any host via a SCRIPT element? It's like saying "applets can't contact arbitrary hosts through sockets but URLConnections are ok".

On Closures and LINQ: LINQ introduces the notion of expressions. Restricting the contents of the curly braces to expressions might seem like an interesting approach. It avoids transfer-of-control-problems. But the most interesting part: LINQ allows you to reflect over an expression structure and gives you some interesting options to optimize the query.