Naked Objects
By Richard Pawson and Robert Matthews
Building a multi-user system
Sharing Naked Objects between multiple users
It is possible to run Naked Objects as a set of discrete client applications, each one linking directly to the persistence mechanism via an object store within the client. This is known as a 'fat client' architecture. This is not recommended unless you need to preserve compatibility with an existing fat client architecture, or your application involves a great deal of numerical processing on small numbers of object instances.
More commonly your clients
will each communicate with a shared object server, which in turn
will talk to the object store to access the persistence mechanism. The
Naked Objects org.nakedobjects.Client and
org.nakedobjects.ObjectServer are both sub-classes of
org.nakedobjects.Application (as is the
org.nakedobjects.Exploration used during
prototyping).
The terms 'client' and 'server' do not imply anything about physical location. A common set-up is to have the clients running on user platforms and the server running on a central machine. But it is also possible to run both the client and the server on a standalone PC for prototyping purposes. Equally you may run some clients and the server on a shared platform, with the clients communicating with user platforms via, say, a webserver. Thus the client and server should be thought of only as two tiers in an n-tier architecture.
When an object server is deployed, each naked object that is
used on any client will be replicated from the server. The framework
keeps the two replicas in synchronization. If two users are manipulating
(or just viewing) the same object then the two client replicas of that
object will be linked to the same object on the server. If one user
changes an object then that change will immediately be propogated to all
other client replicas. (This is one reason why it is important to
include the
objectChanged
statements in your methods.)
All this happens transparently. The developer does not have to write any specific code to manage the replication, and indeed thinks of the naked objects as existing only in one place. Setting this up can be as simple as running the client on each user platform and advising it of the location of the server, then specifying the set of naked object class definitions that are to be made available. All this is done in the configuration file. In a future release it will be possible to set up the server so that the client can obtain the class configuration information and the needed class and image files directly from the server - thereby eliminating the need to update clients manually when new naked object classes are introduced.
The Naked Objects client and server are complete applications. The replicated objects are fully functional: the code for each of the object's methods exists on both client and server replicas. It would be possible to run all the business functionality on either client or server objects. However, if the client has been told (through the configuration file) that there is a server then it will automatically sub-contract the execution of most methods to the server version. This ensures that any resulting changes to the objects are made persistent and that all the clients using that object are immediately notified. In theory your persistence mechanism could perform this alerting function directly, but this would probably require a lot of manual programming. The Naked Objects framework ensures that this automatic alerting and updating happens whichever persistence mechanism you are using. The second reason for delegating execution of methods to the server replica is that it is likely to be physically closer to the object store and therefore yield higher performance if the method involves any retrievals or updates to persistent objects.
Copyright (c) 2002 nakedobjects.org You may print this document for your own personal use, or you may copy it in electronic form for access within your organisation, provided this notice is preserved.