What is XTT? - the technology perspective

Flagship Feature - Automated Data Binding

One of the key features of the XTT framework is the automated data binding. The framework manages the binding of data elements to Java Swing controls, all that is required is that the visual controls are set to point at the data element. Developers no longer have to write custom marshalling logic for every form.

Without the automated data binding, custom marshaling logic that would be required to be written for each form. That would involve aggregating the data from the visual controls, based on the form state (create, read, update, delete) issue an appropriate directive to the application server, have the application server execute the request and send an appropriate response to back to the form.

With automated data binding developers can create and deploy web forms in minutes and not hours or days. They can focus and concentrate on writing the business logic which after all is what the clients really pay for.

XTT in the Java EE (J2EE) architecture

architecture-j2ee.jpg

XTT plugs into the Java EE (J2EE) stack as the top two tiers of an n-tier application. The two tiers have the following components:

  1. XTT Server - resides inside a web container/application server and is implemented as a servlet
  2. XTT Client - the Java front end comprised of one XTT run-time jar along with the developer's front-end visual form classes

The XTT Server component operates at the Interface Plugin tier and is implemented as a servlet. The XTT server has 2 major roles:

  1. Act as a "controller" to communicate with the client tier (currently over HTTP/HTTPS) to stream both data (relational data and/or objects) and the results of remote method calls.
  2. Provide access to all tiers available in the context of the application server it is deployed in.

The XTT Client component is the distributed part of the application and is a collection of Java classes deployed as Java Web Start or as an applet. It has 3 major roles:

  1. Communicate with the XTT Server over HTTP/HTTPS in order to send and receive data, make remote calls, etc.
  2. Hold the data objects and/or relational records in a client side data model along with the state of each data element (example: new, modified, not modified, read only, etc) so they can be automatically re-synchronized with the XTT Server.
  3. Provide the ability to refresh the visual controls with the data that they are bound to and synchronize the changes between the visual controls and the client-side data model (along with updating the state of the data element).

XTT in the SOA architecture

architecture-soa.jpg

In the context of a SOA architecture XTT acts as an interface plugin that communicates with the different workers in the business service interface.

The physical part of XTT that performs the communication with the business service interface is XTT Server - which is deployed as a servlet and can access the business processes through the local context of the application server.

It is the XTT Server's duty to communicate with the remotely deployed XTT Client instances in order to either stream data to them, as well as to receive requests from them.

XTT in the ESB architecture

architecture-esb.jpg

 

An enterprise service bus generally provides an abstraction layer on top of an Enterprise Messaging System which allows integration architects to exploit the value of messaging without writing code. It (often) uses XML and Web services to transport messages and it includes adapter standards (such as J2C/JCA) for incorporating existing applications into the bus. In the context of this architecture, both XTT itself and any applications developed using XTT directly use any services that an enterprise service bus implementation makes available.

XTT itself can use HTTP, JMS, JCA, or any other application server available protocol. The applications written in XTT usually use XTT's infrastructure for convenience, but you can circumvent XTT and communicate directly with the bus over different protocols.

XTT's own Architecture

Nested MVC architecture

The best way to describe XTT is to think of it as a 'nested' Model-View-Controller (MVC) architecture, which is comprised of a double MVC pattern.

The MVC architectural pattern offers an enormous advantage by decoupling and separating the functionality of the different parts of an XTT-based application. Thus improving the robustness and reducing the complexity of the code. It also serves to standardize the way that both the data model and the visual components are accessed.

The decoupled nature of the MVC pattern also enables multiple views for the data in the model as it is the controller's job to trigger the refresh of each visual view component with the appropriate data from the model.

Additionally, because the view obtains the data through the standard access methods of the controller (XTT Server), there is never "hard-coding" to specific data sources from the view. Therefore the data source behind the model can be completely replaced without affecting the view (obviously as long as the structure of the data remains the same). Some practical examples of this include:

XTT's first (outer) MVC pattern closely matches the classic Model 2 approach best described in Designing Enterprise Applications
with the J2EE Platform, Second Edition
.

Outer MVC pattern

mvc-outer.jpg

Figure 1: XTT's outer MVC pattern

The outer MVC pattern has the following components:

The View part of the outer MVC layer itself implements a separate 'inner layer' of MVC architecture. This separate, inner, MVC layer is composed of classes within the XTT library that are deployed to the client. This classic MVC design paradigm is illustrated in Figure 2.

Inner MVC pattern (client tier)

mvc-inner.jpg

Figure 2: Inner MVC pattern (client tier)

The inner MVC pattern defines the behavior of the client tier of an XTT application. Specifically the inner MVC pattern applies to the visualization and modification of the data once it is moved to the client tier. The inner MVC pattern has the following components:

XTT versus other frameworks

Vastly superior to AJAX

In XTT AJAX (Asynchronous JavaScript and XML) style functionality is just one of many feature that XTT offers. Because XTT is built on Java, a full programming language, it has many advantages over HTML/JavaScript based solutions.

Recently it has became popular to selectively disable the JavaScript from being evaluated in the browser as in the case of Mozilla Firefox. Once this is done the any web application relying on Java Script including AJAX becomes crippled. XTT is Java(tm) based so it does not suffer from the inefficiencies of JavaScript.

AJAX's impact on end user experience is a step in the right direction, however because of its JavaScript nature it still presents many challenges. Java and XTT always had the inborn ability for asyncromous communication, the server push (publish/subsribe application model) is just one example. By using XTT to develop your applications you are building on a strong, secure, scalable and reliable foundation and not on the technology "Du Jour".

Traditional Web App Comparison

Most Java development tools today continue to follow the "Java-on-the-server" paradigm; in fact, tool providers are using the new JSF framework to deliver a more robust Java web application development platform (similar to VB or PowerBuilder). However, while these new tools enhance developer productivity, the resulting HTML-based application offers little overall improvement for the growing population of sophisticated end users.

XTT really should be thought of as "Java-on-the-server-and-client". XTT takes advantage of all the serve-side Java functionality and adds a very rich yet thin user interface along with the ability to delegate processing of actions to client or the server ( ex. sorting, event handling, desktop access, etc.).

One of the most critical differences between the XTT framework and other "Java-on-the-server" frameworks is the ability for XTT to provide automated data binding to both objects (EJBs, POJOs, Java classes and web services) as well as JDBC based data sources. XTT's seamless ability to bind to Java objects makes it an obvious choice for enterprise scale n-tier applications.

XTT excels over HTML/Java Script based solutions for transactional applications in areas such as reliability, scalability, performance, and security. Please read the XTT Features section to get the a full appreciation for the richness of the XTT feature-set.

XTT Features

Wizard Based Form Construction

XTT offers wizards to streamline the form development. Listed below are the construction wizards and their uses:

Form Wizards are extremely extensible, they can be modified with a new set of form templates, new custom controls and new formatters and verifiers. All of this contributes to efficiently generated code at an unprecedented speed. Developers are not engaged in tedious coding but rather are mapping data elements which they want to project on a form to visual controls.

Commonly wizard generated code is considered “black-box” in many frameworks. Nothing could be farther from the truth when it comes to XTT. XTT Wizard generated code is simple and a pleasure to maintain.

Integrates with many different technologies

A major design consideration of XTT is that while it adds value through the functionality it provides, it should not limit in any action that a developer would otherwise be able to perform in the application server. Designing XTT in this manner assures that XTT will remain an enabling framework that allows access to any future developments in the Java space that may complement current applications and functionality.

Integrates with existing HTML based web applications

XTT based applications can be deployed as Applets and can be embedded in an HTML page. A complex workflow of a transactional web application can be greatly simplified without drastically re-designing the whole application.

Complex portlet functionality can be simplified by using Applets built with XTT. The resulting solution will enhance the overall the robustness of the portal.

Integration with 3rd party Java components

One of key benefits of XTT is the ability to add new Java controls to the XTT framework. Application architects and developers are now free to choose whatever controls that they want or need for their applications. If no suitable control can be found in the Java community, one can always be created from scratch. Other web technologies will limit the number of controls that can be used and do not allow the use of third party controls.

The XTT architecture also actively encourages developers to take advantage of and use any existing Java libraries, or API. This helps to eliminate the majority of pitfalls in Java projects. Third party components can be used either "out-of-the-box" as is or can be integrated into the XTT framework to be used in the XTT Wizards.

Capable of integrating with desktop applications. ie:Word/Excel

XTT can integrate with popular products like Microsoft Word or Excel or most other desktop applications through available commercial or open source Java libraries.

Reports Integration

XTT applications can be integrated with many reporting packages that exist in the marketplace today. What is interesting about reporting integration is that there is no technological requirement on the reporter package. The integration is straight forward (usually it consists of one API call) as long as the reporting software offers some interface (or API) through which we can specify parameters for the report.

As far as XTT is concerned, reporting technologies can be categorized in two ways; Client side Java Reporters and Server-based Reporters. You will be able to integrate XTT with both reporting types.

Client Side Java Reporters

The advantage of using a client side Java reporter is that it can be seamlessly integrated in the XTT based Java application. This means that there will be no differentiation between a form and a report, except for the actual display. Also launching of the reporter can be sometimes more 'user friendly' with a client side Java Reporter.

Here is a list of some Java based Reporting Technologies :

Server based Reporters

The advantage of using not using a Java reporter on the client is that your deployed application will have a smaller footprint since you do not need to ship the reporting libraries to each client. Depending on the product, server reporting can be more robust at a cost of being less interactive. The report is usually displayed either in a browser or as a PDF document..

Here is a list of some Server Based Reporting Technologies :

Automated Data Binding

One of the key features of the XTT framework is the automated data binding. The framework manages the binding of data elements to Java Swing controls, all that is required is that the visual controls are set to point at the data element. Developers no longer have to write custom marshalling logic for every form.

Without the automated data binding, custom marshaling logic that would be required to be written for each form. That would involve aggregating the data from the visual controls, based on the form state (create, read, update, delete) issue an appropriate directive to the application server, have the application server execute the request and send an appropriate response to back to the form.

With automated data binding developers can create and deploy web forms in minutes and not hours or days. They can focus and concentrate on writing the business logic which after all is what the clients really pay for.

Communication Modes in XTT

XTT can support many communication modes between the client and the application server. XTT's APIs abstract away the difficulties of remote Java development by using a simple and intuitive process. XTT communicates via XML over HTTP/HTTPS, thus eliminating the security risk that comes from opening special ports in corporate firewalls. These different communication modes allow XTT framework to support different Application Modes.

Synchronous/asynchronous remote calls from client to server side Java classes

XTT contains a very efficient API to invoke Java classes in the application server tier in a synchronous or asynchronous mode. These classes can be anything from simple Java classes, to EJB clients, to web service clients, etc.

Server push

XTT enabled applications are capable of immediately notifying the client of any server events without the need for continuous client polling. This greatly reduces the CPU load on the server by not requiring the repetitive opening and closing connections. Please see our product documentation for further details.

Developer-controlled streaming from the server side to the remote client

XTT's architecture is built to efficiently process object collections or relational result sets. Using a conventional approach to retrieve a very large data set from the data source to the client is very inefficient. Normally the request has to be processed in its entirety, which is time and resource consuming. There are even scenarios in which an unqualified request for vast amounts of data overload or severely slow down the application server. To overcome these difficulties XTT directly streams the data from the data source as it becomes available. XTT streaming improves the server load and response times. Streaming on the client can be controlled programmatically or by end-user user actions (ie: stop streaming once the data element arrived or was found).

Not only are XTT's APIs able to stream data from different data sources, but the XTT remote method API allows the results from Java calls to be streamed back to the client as well. Streaming provides a more responsive GUI and thus a better end-user experience.

Asynchronously streaming binary data from the remote client to the server

XTT also supports the asynchronous (separate thread) streaming of data to a server-side Java class. A graphics file, video clip, or other binary content can be sent to the application server tier with full notification as to the progress of the transfer, and acknowledgement of full receipt. This can be done on a separate thread and therefore does not tie up the user interface of the application (as is the case in traditional browser-based web applications).

Application Modes

XTT supports a variety of Application modes. They are: The Traditional Web Application Mode, Stand-Alone Application Mode and Publish/Subscribe Application Mode. An application can be designed using only one or all of these modes. It is up to the application designer fit the appropriate application mode to the specific business requirement.

Traditional Web Application Mode

This is the conventional way an XTT based application is used. A client form is either synchronously or asynchronously communicating with the application server over the internet connection to execute business logic or to display data.

Stand-Alone (disconnected from the Internet) Application Mode

Since XTT allows developers to distribute logic to either the client or app server depending on where the code would run most efficiently you can easily create applications that will continue to operate when disconnected from the Internet. The XTT application can persist new data on the client until such time that it can be re-synchronized with the application server.

XTT applications can be designed to gracefully deal with a loss of the Internet connectivity. If the application becomes disconnected either by accident or design, the user can have the option to save their data locally until the connectivity is restored and that data can be synchronized with the server again. In a browser based solution this is not an option. Browsers were simply created for browsing.

Publish/Subscribe Application Mode

Publish/Subscribe is an asynchronous messaging pattern. In Publish/Subscribe, publishers post messages with specific “topics”, rather than sending messages to specific recipients. The messaging system then broadcasts the posted messages to all interested parties (subscribers).

XTT supports the Publish/Subscribe mode through the XTT feature called Server Push. This feature allows the remote client application to register with the server and be notified immediately when an event is triggered there. The Server Push feature removes the extreme load that the server would be experiencing due to continuous polling from many clients.

Built-in pessimistic locking

One of the major requirements for a complex, transactional application is the ability to control concurrent access to objects and records from multiple clients.

For relational databases, XTT provides pessimistic locking implementation "out-of-the-box". This implementation is database independent. If the database itself implements record-level pessimistic locking then the native locking mechanism is used, otherwise locking is managed in the application server by XTT.

For object based persistence layers like Hibernate and JDO pessimistic locking is also available. Again this implementation is persistence layer independent. The API can also be used for arbitrary objects assuming that they have unique IDs.

This built-in implementation drastically reduces the amount of code a developer has to write to ensure the integrity of the data in the system. The pessimistic locking implementation is unobtrusive to the data source; no changes need to be made to the underlying schema.

Java security with XTT

XTT allows for the use of all Java security implementations along with additional pluggable 3rd party implementations (for example custom encryption packages written by DoD, CIA, or Homeland security dept). The only requirement for the 3rd party implementation is that it must be a implemented in Java that works with JRE 1.4 or 1.5. Some of the more common standards for Java security are:

The software industry has established best practices for dealing with the issue of application security. The XTT platform provides mechanisms for the implementation of these best practices in an efficient and flexible manner. Some of the major best practices are described below. For a detailed discussion on security and XTT consult the Product Documentation.

XTT Authentication

XTT has an extensible API for Authentication. Through this API XTT can interface with any Authentication Service or Server software.

XTT Authorization

Specific to XTT is the Authorization level security API. This API allows any client communication with the server to be validated on the data level. Not only do XTT based applications make sure that only the authenticated users have access to the system/data, but that a particular user based on his permission level has access only to data that he is authorized to view.

SSL/HTTPS Support

To ensure that applications developed in XTT are secure, XTT takes full advantage of SSL (Secure Socket Layer) and HTTPS technologies.

Encryption

In addition to SSL/HTTPS support, messages that are created in the XTT client and then sent to the server for processing can be further encrypted by using various encryption schemes. This provides another level of security not available in other products or technologies.

Deployment Advantages

The XTT Framework provides many performance and scalability advantages over other Rich Internet Application frameworks::

Runtime Advantages

The XTT Framework provides many runtime advantages over other Rich Internet Application frameworks :

Scalable enterprise level architecture

Architecturally, XTT plugs into the Java EE (J2EE) stack as the top two tiers of an n-tier application. XTT provides automated data binding to virtually any SOA persistence layer including EJBs, POJOs, Web Services, server-side Java Classes, or JDBC.

The server side component of XTT was designed to run as a servlet. This enables XTT to take advantage of the business and data layers (EJBs, web services, persistence layers, database connection pools and java classes) in the application server. The XTT server is then responsible for streaming data from those sources to the remote XTT clients over HTTP. XTT also takes full advantage of the other features of the application server like: clustering, security modules or integrations servers.

Because of the Java smart client, many of the actions that would traditionally have to be handled by a server can now be handled in the client tier (like: data validation, sorting, filtering, etc). This eliminates a huge amount of requests from burdening the application server, which in turn can now allow a much greater number of users to be supported. This leads to direct savings as the number of servers (including hardware costs and licenses for their software) required to support the application can be reduced.

Additionally, XTT based applications use very little bandwidth because once the thin client Java application is downloaded to the client machine all that is transmitted back and forth is data over HTTP.