Please correct me if I'm mistaken, but my impression from the Seam Reference document is that if you enable Seam Remoting then any Entity bean that you've given a Seam @Name has it's data model exposed.
Let's say you have a large corporation and a developer uses a wonderful IDE wizard to turn their database model into a package of easy to use Seam-enabled entities. Next the developer enables Seam Remoting to use an @WebRemote enabled session bean.
It is clear that session beans require @WebRemote annotation. Why are entity beans automatically exposed without such an annotation?
They are only exposed if they are the return value of a method marked @Remote. And only their state is exposed, not their methods.
Is the documentation completely wrong then?
In section 7.2.2 Seam.Component, the example shows an entity bean that implements serializable with @Name('customer') which is later called through:
var customer = Seam.Component.newInstance("customer");
// Or you can set the fields directly
customer.lastName = "Smith";
That code instantiates a *new* object with empty values. Hence no security hole.
I'm not stating that the data is insecure, but that the model is.
A company's data model can constitute proprietary information or trade secret.
What I'm blatantly saying is that as much as sessions beans require @WebRemote to have their methods exposed under Seam Remoting, entity beans in the same distribution should be afforded the same level of preventative measure.
Instantiating a *new* object tells me plenty about how the database is modeled and in some cases can reveal proprietary information or trade secret.
A developer may wish to prevent various entity beans from having their model exposed. I'll go a step further and say that entity beans should not have their model exposed by default, but that they should be configured with @WebRemote as well. It fosters uniformity and errs on the side of security.
I wouldn't go as far as to constrain all entities by default, it would add another "speedbump" that a developer would need to be aware of when implementing remoting in their app. Section 7.9 in the remoting chapter of the documentation describes how object graphs returned by invoking a session bean can be constrained to exclude sensitive or unnecessary objects. I've got no problem implementing a similar exclusion for entity classes. Maybe @NonRemotable, or even @NoWebRemote would be a good annotation for this use case.
I don't think it's any more of a hassle than creating a @Remote or @WebSerivce interface. In fact we're talking about just one tag, @WebRemote, in a class.
It would also be easier for developers who are new to Seam Remoting to follow if it is consistent. "I have to use @WebRemote on sessions, but @NoWebRemote on entities? Why'd that do that?"
If you're worried about existing developers or eliminating the speed-bump, you can always create a property in a config file somewhere that would enable/disable entity model remoting restrictions.
From a security standpoint, I think it's much better to err on the side of security, i.e. you have to specifically enable which entity models you want exposed.