Client aims and design principles

The development of client applications and client side GUI components (aka controls) is an ongoing project which encompasses all of our component products. Below we detail the aims of this ongoing project and the design principles on which it is built.

Aims of our Client Project

Within our products we include a number of client applications and client side components which form part of our ongoing client side development. The aims of our client side project are as follows:

1. Demonstrate Technical Functionality - Through a question and answer dialog which illustrate the type of domain specific problems which our components can address.
2. Reuse of Client Examples and Components - We aim to provide full working client applications and client side components which you can customize for use within your client applications.
3. Offer GUI functionality across platforms - Offer the same examples in terms of logic and GUI functionality across our supported platforms.

Demonstration of Functionality

The client examples will not only show a components functionality by will also act as a tutorial on the components use. Moreover, for most given problem you should be able to customized these examples to the particular problem you wish to address within your application. If however you find that none of our examples can be customized to address your problem type then just email us a description of your problem and we will (in almost all cases) write (without any charge) a custom client example for your application.

Reuse of Client Side Logic and Components

Within all our example applications we will endeavor to wrap as much of the client examples functionality as components allowing for the reuse of the GUI functionality and logic within other applications. Moreover, the "glue code" which binds together the components and details the clients logic will when appropriate be wrapped as a component. By using a component methodology throughout our client development process will provide greater level of reuse of the GUI functionality and/or the logic contained within our client examples.

Design of the Client Project

As mentioned above we will design the client applications so that there functionality can be reused within your applications. We will also use the clients to demonstrate the functionality of our business components. Our third aim is to offer the "same" examples across platforms by implementing the "same" example on a number of platforms. Though the graphical libraries differ significantly across platforms and application type by adhering strictly to the Model-View-Controller (MVC) paradigm, we will be able to implement the GUIs logical structure exactly across platforms whilst keeping the GUI functional contained within the components as close as is practically possible. For thin clients the implementations across platforms will be identical but for fat clients there may be significant differences.

The range of clients types which we support include:

• Thin Clients
  • Console Applications - Examples provided as text console applications being non-graphical offer the easiest choice of client type when things of customizing an example for redeployment within your own application.
  • Java Server Pages (JSP) - Can be viewed live over the Web or deployed locally environment.
  • ASP.NET - Can be viewed live over the Web or deployed locally.
• Fat Clients
  • Java - Swing clients, Java Applications
  • .NET - .NET Windows Forms
  • Delphi - VCL
• Smart Clients - Used as clients for Web services and as a tools which can be extended through the use of an addin.
  • Microsoft Excel
  • Star Office/Open Office

Porting GUI Applications between J2EE and .NET

Since the logical structures which exist within the .NET and J2EE development platforms are identical for any application its logic structure will always be able to be ported exactly. Moreover, if a GUI application only uses GUI elements (Swing/JavaBeans in Java, ASP.NET/ActiveX controls in .NET) which the other platform also implements then the GUI application will also be able to be ported exactly. However, if a GUI application use a control which the other platform does not support out-of-the-box then when porting the application the developer will either have to use a control with similar characteristics or develop the control from scratch on the other platform.

For this reason within our business component bundled GUI bundle, we have provided the same GUI components it terms of functionality and internal logic on all our supported platforms.

Architectural Differences between J2EE and .NET

The below diagram illustrates the correspondence between components within the .NET and J2EE Platform, associated development tools and languages.

Reproduced with permission from:
`ASP.NET and Struts: Web Application Architectures, MSDN Microsoft'

Model-View-Controller (MVC) Paradigm

Within all of our client example we will adopted a MVC approach. The MVC paradigm is the pre-eminent architectural approach to the design of enterprise n-tier applications. Where appropriate for each of our supported platforms we will use standard MVC based frameworks which greatly offer to increase the level of developer productivity when assembling MVC based applications. The frameworks we will use will include:

1. Apache Struts - the standard MVC framework for the Java platform
2. Microsoft Application Blocks for .NET - provides a simple yet extensible MVC framework for developing user interface processes.

Further Details

For further details we refer the interest reader to the following articles:

1. Sun J2EE Detailed Pattern in MVC
2. ASP.NET and Struts: Web Application Architectures, MSDN Microsoft
3. Implementing Model-View-Controller in ASP.NET
4. Struts Applications - provide example Struts applications and hosts Struts extensions and utilities
5. Patterns and Practices, Microsoft Corp