Three tier computing using DataExpress.

Project: nTier
Author: JBuilder Team
Company: borland.com
 

Description: Simple example of 3 tier Distributed Computing using RMI and DataExpress components.

Setup

  1. Start the Java RMI registry, by selecting Tools | RMIRegistry from the menu.
  2. Select Run | Run project to run the ServerApp.

    Note: Beginning with JDK 1.2, it is necessary to grant an RMI server special security rights in order for it to listen for and accept client RMI requests over a network. Typically, these rights are specified in a java security policy file defined by a special property (java.security.policy) passed via a command-line argument to the VM of the server. Similarly, a property specifying the location of classes used by the server (java.rmi.server.codebase) is also passed to the server's VM via a command-line argument.

    Before running the server, select Project | Project properties... and select the "Run" tab of the dialog to inspect the parameters passed to the server's VM. Check that the java.security.policy and java.rmi.server.codebase properties point to the proper locations of the security policy file and server classes for your JBuilder installation ("file:/usr/local/jbuilder/samples/NTier/SampleRMI.policy" and "file:/usr/local/jbuilder/samples/NTier/classes/" by default, respectively).

  3. Finally, to run the client, click on the small arrow next to the "Run project" button on the toolbar and select the "Run Client" run configuration. Goals of this design pattern
    1. Stateless server.  Server objects maintain no state from one remote method invocation to the next.  This allows this pattern to be extended for Object pooling.
    2. Transactional business logic is easily partitioned to a middle tier.
    3. Two or three tier operation is a choice.  An app can be initially designed for two tier with Entity framework outlined in samples/TwoTier/TwoTier.jpr and can be later extended for 3 tier operation.  Note that in all classes in the TwoTier project operation are also used in the 3 tier nTier project.  The difference between the two is that the nTier project seamlessly partitions the transactional logic to the middle tier.
    4. Entities developed in com.borland.samples.dx.orderentry.entities package are shared on client and server using the same classes.  Although not required, there are many applications that benefit from being able to surface constraints, defaults, etc. on the client.  In this way, users are provided with immediate feedback and transactions submitted to the server will be much less likely to fail.
    5. Project Tour

      This project reuses the presentation (TestFrame) entities (Customer and Orders), and transactional logic (ServerModule) from the com.borland.samples.dx.orderentry.entities package that were used by the samples/TwoTier/TwoTier.jpr.  The same code is used, but the the ServerModule is pushed to a middle tier.

      To partition ServerModule to the middle tier  an broker layer is placed between the presentation/entity logic and the ServerModule.  This broker layer is comprised of:  1) ClientModule.  Like ServerModule, this DataModule implements the com.borland.samples.dx.entities.Module interface and contains the same entities.  The difference is that the ClientModule uses RMIProvider/Resolvers to delegate transactional requests to a remote ServerModule.  Note that since the entities know only about the com.borland.samples.dx.entities.Module interface, they are ignorant of whether they are contained by a ClientModule or a ServerModule.  2) Broker.  This broker class sits on the middle tier and brokers requests from the client RMIProvider/Resolvers to the remote ServerModule.  The data of DataSets and Parameters is passed between the tiers using DataSetData and RowData components.  DataSet and ReadRow components cannot be used for this purpose since their java.io.Serialization implementation only persists property component state, not the actual data stored.

      Benefits of this approach:  1) Entity framework is leveraged to partition Transactional logic to a middle tier.  This allows an application to be developed as a 2 tier app and deployed as a 3 tier app.  2) Data integrity can be maintained on a middle tier by the ServerModule.  3) Identical entity components can be shared on client and server side.  4) JDBC driver is not needed on the client.  This makes for a slightly thinner client and allows for easier usage of JDBC drivers that rely on native code support like the JDBC-ODBC bridge.
       

      Multi-tier architectures supported by DataExpress

      Smart client, transactional business logic partitioned to middle tier.  This architecture is the focus of the ntier project.  The nTier example allows for the partitioning of Transactional business logic to another tier while allowing data source independent entity definitions to be shared on multiple tiers.  The Application Server edition of JBuilder provides design time and deployment support for this model using the Inprise CORBA orb.

      Thin HTML/XML client, entities and transactional business logic partitioned to middle tier.  JBuilder 3.0 provides design time and deployment support for this model.

      Traditional two tier thick client.  The benefits of this model are that these apps are simple to develop.  If the framework laid out in the com.borland.samples.dx.entities is followed, the application will be much easier to partition in the future.
       
       Extensions/Alternate implementations
       

      • CORBA instead of RMI
      • Object pooling for RemoteBroker
      • Connection pooling for JDBC connections.
      • Support for load balancing, monitoring, failover.
      • Security
      DataExpress extensions for this framework
       

      In developing this sample some issues arose with the 3.0 components.  Most of these will be addressed by a future release of JBuilder, but in the meantime some additional components and component extensions were developed and are delivered in the dataset package of this project.  This includes:
       

      • RowData.  Provides efficient serialization for a row of data.  Used for passing parameters from one tier to another.  Component will be added to DataExpress dataset package in the future.  See the ntier project for usage of this component.
      • RMIProvider.  This is an implementation of a DataExpress Provider that is used on the Client to submit data retrieval requests to a remote ServerOrderEntryModule.  See the ntier project for usage of this component.
      • RMIResolver.  This is an implementationof a DataExpress Resolver that is used on the client to resolve edits back to the ServerOrderEntryModule.  See the ntier project for usage of this component.

      • DebugQueryProvider.  Simple extension of QueryProvider that allows for debugging fetchAsNeeded master detail relationships.
      How do I get more information