by Kade Hansson

Object Transport Layer and Data Formats

 Overview

Mr Architecture is a component architecture based on EJB 2.1. Its hallmark properties are:

• Simplicity
  • Bean provider supplies three components per business object type, with one being completely generated automatically
    (in EJB, the bean provider must also supply a deployment descriptor)
  • First component is partially defined through inheritance, partially defined through graphical modelling (e.g. Rational Rose) and partially defined by automatic code generation scripts in the modelling tool
  • Second component is partially defined through graphical modelling (e.g. Rational Rose) and partially defined by an automatic code generation script
  • Third component is generated entirely by a script in a graphical modelling tool (e.g. Rational Rose)
  • Deployment descriptor (describing bean interrelationships) is inferred given naming conventions
  • One-to-one mapping between business object types and database tables, which are synchronized by tools (e.g. Rational Rose)
• Good scalability
  • Java makes it easy to migrate to more powerful hardware to accomodate new demands in both the server and client
  • No limits on number of business objects in the architecture
  • No complex configuration needed to include new business objects...
    1. generate the required components
    2. use tools to generate the database tables
    3. add two lines to the application's ContainerFactory class
    4. generate the Mr Architecture implementation classes using DeploymentTool
• High portability
  • Java offers write once, run anywhere capability
  • Server deployment can occur in any servlet enabled web server (e.g. Apache Tomcat, JBoss (open source); IBM WebSphere or Sun ONE Server (commercial)) or through a stand-alone server module supplied as part of the Mr Architecture 3.0 package
  • Mr Architecture is weakly coupled with the underlying database, allowing any vendor to be supported through a specialized MrDatabase subclass which maps from high-level concepts like sequences to the underlying SQL queries required
  • Client deployment can occur in any Java-enabled web browser or computer with standalone Java runtime environment
• Powerful extensions to EJB
  • Mr Architecture adds the ability to execute pseudo-SQL queries in order to allow flexible and efficient access to underlying relational structures, where these exist, while still retaining an object-oriented view over returned record sets
  • Mr Architecture implements a more powerful version of TimerDrivenBeans (introduced in EJB 2.1) which allows the server to process waiting data in the background, which allows for data replication and batch processing facilities without database support
  • Mr Architecture allows EJBLocalObjects to selectively invoke methods remotely through a round-trip send-call-return facility
• High speed
  • Unlike EJB, object interations occur at object granularity instead of method granularity (sacrificing concurrency and load balancing capacity for a performance trade off)
  • Java's HotSpot performance engine delivers object code which runs as fast as compiled programs
  • Transport layer uses Java object serialization for a compact and robust data representation
  • Transport layer capable of communicating a virtually unlimited number of related business objects in one or two handshakes
  • Server is multi-threaded for low latency
  • Server caches object representations of frequently accessed database records and record sets
  • Database connections are pooled so that during periods of high demand, many transactions from multiple clients can be processed simultaneously
• Modest resource demands
  • Mr Architecture demands no more resources than any other enterprise grade application...
    • space for recording metadata about business objects
    • space for recording transaction states
    • some space for caching (but flexible)
    • time as required for multiple concurrent transactions from application clients to progess
    • enough space for all the data in any concurrent transactions application clients might make
    • reasonably efficient network transport
• Based on accepted standards
  • Java 2 Enterprise Edition (J2EE)
  • Java Database Connectivity (JDBC)
  • Enterprise Java Beans (EJB)
  • Java Servlet API
  • Java Transaction API

Mr Architecture takes the best of EJB 2.1 and shoehorns it into a framework which allows the rapid deployment of efficient, reliable and scalable applications.

 Object Transport Layer

The Mr Architecture object transport layer is used for communication between the ServerContainer, of which there is one per database application, and the ClientContainers, of which there are as many as there are simultaneous application clients. Both Containers perform similar tasks, and share much common code. However, their main difference is their effective use of the object transport layer.

The containers can be thought of containing as many MrBeanHomes as there are types of business object. Each of these homes can be thought of containing as many MrBeans as there are business object instances. However, at any one time, a container may not be able to provide direct access to a particular business object instance. These object instances may live in another container, the ServerContainer, or in a database. In these cases, the retrieval of the object from the ServerContainer over the network, or from a database through a JDBC connection, via the home should be transparent.

The ClientContainer accesses beans by communicating Commands (containing beans) across a HTTP connection to the CommandServlet. The CommandServlet passes the commands to the ServerContainer, which acts upon them and returns Responses (also containing beans.) These responses are sent back on the same HTTP connection and the connection is closed.

Security is implemented by the CommandServlet, which interprets requests for certain types of beans - LoginEntityBeans and SessionEntityBeans - as login and session establishment requests. UserEntityBeans are also handled with additional care as these contain authentication data. Sessions are typically managed through cookies containing a truly randomly generated session ID (as provided for by the servlet infrastructure).

HTTPS is not used in the transport layer by default, but there is no difficulty in using it, as it is supported in the servlet infrastructure.

 Data Formats

The form of a request sent to the CommandServlet is a HTTP POST request to the URL to which the servlet is linked. This request contains a standard HTTP header, which contains the unique session ID cookie where appropriate, and serialized Java object data, which is a binary format understood by the standard Java libraries. The object data is a Collection (defined by the Java libraries) of Commands (defined by the architecture).

The form of a response is similar. It consists of the standard HTTP header (possibly containing a set-cookie field if this is the first request from a new client), then either the serialized representation of a Java Exception, or a serialized Collection of Responses (corresponding to the commands in the request on a one-to-one basis).

The recognition and parsing of serialized data is almost immediate, and carries very little processing overhead. The generation of such data is so fast as to be negligible. Java object serialization also has advantages in allowing data formats to evolve over time, and is also quite robust in terms or rejecting invalid data (though not to the level of semantics).

XML was considered as a transport option, but for ordinary internal business transactions the space and time overhead appeared to be excessive. There is also some start-up time in producing suitable XML representations for data, and in particular agreeing on a document format which will best allow interoperability of systems managing similar data. Java object serialization is a ready-made solution which allows good interoperability for most purposes.

It is also worthwhile to recognise that XML is commonly used to represent data, not logic. What is required in the transport layer of a component architecture is the transmission of commands and responses to those commands. Commands are not business data, they are atoms of business logic. Responses are often in the form of business data, but it seems an unnecessary complication to use a different data format for responses from commands.

XML's two main advantages over Java serialization are to allow the interoperability of systems managing similar data, and its inherent validation.

Arguably, interoperability is only required at the frontiers of systems, and should not be a major concern during internal processing. XML transport could be added to the architecture by producing an additional form of CommandServlet - say XMLCommandServlet. If a corresponding ClientContainer (say XMLClient Container) were generated, and because the transport layer is transparent to the client and server alike, this would have no effect but to slow down communications.

Additionally, and this brings us to the second advantage of XML - inherent validation. Mr Architecture already provides for validation - the containers in Mr Architecture validate data by invoking the validate method (assuming one exists) of the business object - so it is arguable whether a less flexible scheme in the transport layer would be warranted. With an XMLCommandServlet and an XMLClientContainer, this would move the burden of validation of data from the ServerContainer to the XMLCommandServlet and additionally require validation be done in the XMLClientContainer on the responses from the server. (Currently the assumption is made in Mr Architecture that we can inherently trust the data returned by the server to be valid.)

As mentioned, the containers in Mr Architecture validate data by invoking the validate method of the business object. This relies on code generated by the bean provider to enforce business rules upon the data in addition to the type rules of the Java language (which are naturally enforced during object serialization.) Some automation is possible using tools (such as Rational Rose) to generate metadata which can be used to perform simple validation (viz the simpleValidate method of the architecture). The key advantage to validation of this form is that it is far more powerful than any validation XML alone can provide, and indeed it can be integrated into an XML parser at a future point (as at some point the parser must produce the DOM representation, and at this point the logic of the validate method can be enforced).