This isn't so much a pattern as a "general design principle." It occurred to me that this needed to be stated explicitly last night when a friend called and was talking about how OpenDoc might get swirled into Java.
Ack, I thought. OpenDoc over networks is built over the SystemObjectModel which is compliant with the CommonObjectRequestBrokerArchitecture and now we have a heap of work to do anything.
CORBA is something I consider, at least in many of the current implementations, to be archetypally bad. In the sense that it actively prevents messing around and doing little tiny prototypes. You have to develop a client. You have to develop a server. You have to think about lifecycle policies and security policies and persistence policies and ....
El mondo yucko. These decisions shouldn't be made until after you've played around. Done some explorations, maybe a prototype (or a "proof of concept" or whatever).
To some extent, designs have to be evolutionary. There's what you thought the design was and there's what the design turned out to be and there's what the design should have been (which is, one hopes, the starting point for v2).
JavaRemoteMethodInvocation is wonderful, at least as far as the spec goes, in this respect. It's simple, it's semi-transparent, it has a lot of defaults which get you up and running and exploring the relevant issues quickly.
In short, it allows for bootstrapping. And then, once you're sure you've got the outline right, once you're more certain of the design issues involved (and what the technology tradeoffs are), then you go back and worry about the persistence and security and ... issues.
Huh? Now what is the point of AllowForBootStrapping?