Sponsored Link •
Sean Neville, previously the lead architect of Macromedia's JRun application server, talks with Bill Venners about the messaging approach used to implement remote method invocations in JRun, and situations in which enterprise developers may find Jini useful.
Although Macromedia architect Sean Neville currently works on Flash-related rich application products for both .NET and J2EE platforms, he originally joined Macromedia to work on the JRun application server. As enterprise architect of JRun 4, Neville was involved with implementing many aspects of the J2EE (Java 2 Platform, Enterprise Edition) specifications, including EJB (Enterprise JavaBeans) containers, JNDI (Java Naming and Directory Interface) providers, JDBC (Java Database Connectivity) managers, and JTA (Java Transaction API) monitors. Neville also represents Macromedia on the JCP (Java Community Process) Executive Committee. In this two-part interview, Neville describes how he used Jini to enable clustering in the JRun 4 application server. In Part I, Neville describes the object clustering architecture he wanted for the app server, and how Jini facilitated it. In this second and final installment, Neville describes a messaging approach underlying method invocations on remote objects in JRun, and suggests situations in which enterprise developers may find Jini useful.
Bill Venners: In the clustering architecture you created for
the JRun J2EE application server, you used the Jini lookup service to enable remote
objects in a cluster to discover each other and exchange stubs. When a client receives a
remote reference, that reference actually contains all the stubs in the cluster of equivalent
remote objects, which enables a pluggable algorithm to perform load balancing and
The remote objects also register for and receive events from the lookup service,
indicating new peers have arrived or existing peers have departed from the lookup
service. Is there a way to notify a client of changes in the peer list?
The remote objects also register for and receive events from the lookup service, indicating new peers have arrived or existing peers have departed from the lookup service. Is there a way to notify a client of changes in the peer list?
Sean Neville: There is a callback mechanism. If a client makes a call -- during which the server discovers, via a Jini event, that the stub list has changed (either someone has dropped out or joined) -- then the server gives the client the updated stub list, in addition to actually performing the invocation. The server tacks the stubs onto the invocation.