Because an XML document is self−describing, it is easy to change it into another format or into another XML document that conforms to someone else's DTD.
You took a closer look at how to move back and forth between XML documents and Java objects representing the same data. You learned the following:
How to use Cascading Style Sheets (CSS) to display XML documents. The advantage of this method
•
is that the presentation is more attractive in browsers that support this feature. The disadvantage is that the document itself isn't changed, and the way in which the document is rendered is very browser−dependent.
How to use Extensible Style Sheet Language Transformations (XSLT) to actually change an XML
•
document into other formats. In this chapter's example, you changed an XML document into an HTML document.
How to use XSLT style sheets to transform an XML document conforming to one DTD into an XML
•
document conforming to another DTD. This is a particularly useful ability when you're sharing data between organizations that have developed different ways of thinking about how the data should be organized. If you can come up with a reasonable mapping from one organization to the other, then this process can be automated.
That the Java APIs for XML Binding (JAXB) enable you to take a DTD and transform it into Java
•
classes that can be used to represent data stored in an XML document, which can then be validated against that DTD. The transformation of data stored in these XML documents to and from Java objects is called marshalling and unmarshalling, respectively. This transformation simplifies the task of working with data persisted in XML documents.
307
Part V: Abstracting the System
Chapter List
Chapter 15: Exploring the RMI Mechanism
Chapter 16: Introducing Enterprise JavaBeans
Chapter 17: Using Advanced EJB Techniques
Chapter 18: Introducing CORBA
Chapter 19: CORBA Applications in the Enterprise
Chapter 20: Why Dream of Jini?
308
Chapter 15: Exploring the RMI Mechanism
Overview
If you have Java on the client and the server, you can use Remote Method Invocation (RMI) to communicate between them. The client will have a piece of stub code that acts as a proxy for particular classes on the server. The client interacts with this code as if it were the remote object itself. By this we mean that you use the same methods, not that there aren't additional considerations that could affect your performance. You are passing objects back and forth across the network: You should consider carefully what it is you are passing and how frequently you are passing it.
In this chapter, we'll explore the RMI mechanism by presenting an example of having a remote Java client interact with Java classes on the server. We'll look at developing a distributed application first in a single directory, then in two directories on a single machine, then on two different machines, and finally using the RMI daemon. Each iteration of this example will introduce a new issue. Initially, nothing is really being passed back and forth, as everything is in the same CLASSPATH. This approach will enable us to discuss specific features of RMI rather than introducing them all at once.
The Components of a Basic RMI Application
We'll begin our examination of RMI with an example that enables you to create each of the components in a basic RMI application. In the next section, we will expand upon this example to create an actual distributed, albeit small, application. For now, we will concentrate on creating the interface. In this case, you will pass in a String called name, and the Greeter will respond with the String Hello name. Of course, you don't need a distributed application to print a personalized greeting for a user. You can accomplish the same task using a servlet or JSP as we mentioned in Chapter 3, "Creating Dynamic Content with Servlets," and Chapter 4,