Contexts, When Bound as Contexts, Have No Attributes Contexts Can Create Subcontexts Directly There Are No Remote Iterators

well in our use case involving the bank example but isnt quite flexible enough to make the printer example feel natural. For example, consider document-types. Our printer example currently has three: PDF, PostScript, and PCL. We have two options: • We can encode this as delimited strings. For example, we can say that the document type attribute takes one of the following values: pdf, postscript, pcl, pdf, postscript, postscript, pcl, pdf, pcl, or pdf, postscript, pcl. • Alternatively, we can encode this as boolean-valued attributes: handles pdf, handles postscript, and handles pcl. This might be the first requirements-level decision reversed in Version 2.0.

15.4.5 Contexts Are Handled by a Separate Set of Methods

Recall that contexts can be bound into other contexts without being subcontexts. In order to fully support this, we need to have a separate set of context-specific methods. Calling: public void bindPath path, String name, AttributeSet attributes, Remote server and passing in an instance of Context is semantically distinct from calling: public void bindSubContextPath path, String name, Context context throws RemoteException, NamingException; and passing in the same arguments. Note that in order to pass in the same arguments, the attribute set has to be null in the first call. This extra bit of flexibility is rarely used, but is traditional. [ 3] [ 3] Traditional in distributed computing often means, as it does here, The people who designed CORBA did it this way, and I cant think of a good reason to change it.

15.4.6 Contexts, When Bound as Contexts, Have No Attributes

Consider what happens when we call: public Remote lookupPath path, String name, AttributeSet attributes throws RemoteException, NamingException; Now consider what happens in the printer example, when we have a location context and attributes that specify the printer more fully. Those attributes dont really apply to the contexts along the path; they really only describe the final server. If we want to associate attributes with contexts, we must associate an AttributeSet with every component of the path. While this is possible, it is rarely useful, and the extra functionality doesnt seem worth the extra complexity, both in server implementation and in client-side coding.

15.4.7 Contexts Can Create Subcontexts Directly

Recall one of the design points we discussed in When Should a Subcont ext Be Feder at ed? : Frequently accessed servers should be accessed via paths that stay inside a single naming service. The basic idea is that you should avoid network latency whenever reasonable. Related contexts and paths that are frequently accessed as units should exist on a single machine, and should probably exist inside a single JVM. This means that, in daily use of a naming service with a well- structured context hierarchy, the following case holds: Most of the frequently accessed subcontexts of any given context will be objects inside the same JVM. [ 4] [ 4] That is, Federation is very useful and rarely used. In order to support this in a flexible way, a context needs to be able to create subcontexts directly; since bind cannot create an object inside another JVM, we need the createSubContext method. createSubContext also implicitly binds the created subcontext.

15.4.8 There Are No Remote Iterators

This is another decision based on past experience and anticipated usage and may be removed quickly in Version 2.0. Basically, the idea is that with the addition of a well-designed set of attributes, queries should have very few return values of which, even fewer are superfluous. This means, in the general case, iterators would make the clients more complex without saving us much bandwidth. For now, the interface seems complicated enough.

15.5 The Value Objects