The QAFE architecture consists of several layers, each with their own purpose (see overview architecture image)

Top-down description

Presentation Technologies

This is the set of possible UI Toolkits that are available in the market. From Google’s Webtoolkit, Adobe Flex, Microsoft Silverlight and other that are yet to come. We’ve seen in the last decade that UI toolkits came and went away in a high pace (most of them with a lifetime of 2 years). This is for Enterprises a huge hurdle to overcome, since the chosen technology was not necessary to last for a long time. The developments in the world of webtechnologies go in a high pace, so it’s hard to predict what the next cool kid on the block is going to be.

QAFE Presentation Framework

To overcome the highly changing world of webtechnologies, we said that if  it possible to describe the User Interface and the Behavior on that User Interface (“what should happen when you click on this button”) in an abstract way, it would be possible to render to the specific technologies on the fly. That’s exactly what the QAFE Presentation framework is all about.  Focus on what is needed instead of worrying about the technology and how to do it. One great benefit of taking a step back from a specific technology is that you can easily switch from technology. With QAFE for example it’s possible to see the application rendered in Google Webtoolkit and at the same time see the same application in Adobe’s Flex (without programming MXML + Actionscript).

QAFE Business Framework

The QAFE Business framework was needed because:

  • There is no such thing as a standalone application (It might seem in the beginning of the lifecycle of an application that it only connects to one resource, but in time it will need information from other resources)
  • Integration is by default (see previous item)
  • There are framework that either only implement the User Interface or only the backend integratie
  • Heavy Enterprise Service Bus/BPEL engines take lots of resources and take time to setup.  We are pro ESB’s and BPEL engines by the way, but this is most of the time large scale, enterprise-wide implementation. We want the same possibilities on a smaller scale.

Stating this, this results in the fact the QAFE Business Framework can be seen as a “BPEL Engine”-light, that is: it works on any application server and is  in fact embedded in the application. The QAFE Business Framework implements Control Flow, because we already know that we want to integrate services (from database, webservices or Java) in a quick and straight forward way.

The Business Framework consists of several layers:

Business-tier

The Business-tier is meant for having the high level business-actions defined. This business-action should be more or less the same as a business analist would describe. For example: If an insurance company decides to additionally also sell car insurances, the business-action would be “getCarInsurunceInfo” with two inputs: the userId and the car licenseplate number. In the business-tier you are independent of the underlying technology.

Integration-tier

The integration-tier is meant as the API on top of your native resource. So in the insurance example (see Business-tier), there would be two services: UserService with method to get the User Information by the userId (that goes to the local database) and another service CarService with a method to get the Car Info (that gets the car info from the remote webservice from the Car registration Institution).

Resource-tier

This is where you define the native resource. The native resource can be a Java class,  a Spring Resource, Database name (either through JNDI or local pooling). The database resource has the functionality of a broker, comparable to for example iBatis. ORM is not necessarily the way to go, but the Java classes can on their turn use it. So developers can still use their favorite tools to test and debug the functionality. We just connect to that.

Backend

The backend technologies like Java, Database (any vendor) or WebServices. This is where the native logic can be found.

Datastore/pipeline

Datastore (aka pipeline)  is the way the layers can be independent and support the idea of Reusability. Component based development is supported in this. The datastore connects each layer flawlessly and complex datatypes are supported  independent of the technology is used.

Third Parties

The Service Oriented mindset is to reuse and easily make available of what you have made. In this case “Third Parties” can use the business-actions that you’ve created.

How we do this ?

We have chosen for  a monolithic application design leveraging on the possibilities of modern web. The model is based on the Event-Driven model. We have chosen to describe the application in a declarative way using QAML (QAFE’s Markup Language), which is in fact a way to define the application (an application-definition). This application-definition is interpreted at startup-time and results in live applications in runtime (by means of rendering in the specific presentation technology). Editing the QAML file can also be done in a Graphical tool: The QAML Builder.

To summarize what this all results in:

• Open Architecture
• Easy Development Learning Curve
• Rapid Application Development
• Handles large Data Entry Applications
• Service Oriented Architecture
• Future proof (technology independent)
• Many Supported Platforms (and support for all browsers)
• Renders to GWT, Adobe Flex, Silverlight, HTML5, etc.
• Low Maintenance
• Based on Industry Standards
• Highly Scalable
• Limitless Integration Possibilities