XFFDS Server on Jboss /AOP framework
bigboss Mar 29, 2004 1:24 AMI wish to start an open source project . The aim and deliverables of the project are described below:
The XFFD Server Project. : a complementary EE [Enterprise Engineering] platform
In software development for business and so called enterprise systems separation of presentation logic from business logic is a standard adorable practice in the software engineering arena. JSP has been pushed by Java camp with this promise . How much it has succeeded in reality is a debateable . . The fact is a Web designer is interested in the look and feel and movement on the page rather than how to produce dynamic data that populates those pages. Ideally the Web designer should be able to design and paint using a presentation technology and programmer should be able to pipe in the right data into the right spots which would have some identifiable name in the page as the user interacts with the page.
Coming from an old mainframe background, this was precisely what was happening 20 years back. Only limitation was how much the designer could do with those fat green screens of the dumb terminals. In fact designers were never called in to help to set up the old BMS [basic mapping support from IBM] screens. At the most we [programmers] would do some prototypes of those screens and sit with the business analysts to figure out if the positions of the fields would be right or if the flow of the screens would be right.
After 20 years of relentless progress and after being swept over by two generations of new technology [the client server and then the internet] , and in today amidst technological opulence we seem to be back with a problem that the old dumb terminals would have solved by trying to over- come the limitation of technology.
In the old days BMS solved the problem by giving each field in the screen [we used to call it a MAP ] a unique name and then producing a data structure on which the processing programs would receive data from as well as map their data to by “receive and send screen” command. This worked extremely efficiently. The input and outputs and business logic could be handled by different functional modules and the screen attributes, for example, colour and character highlighting could be changed and the static texts like headers and prompts could be changed and the map recompiled without touching the program modules or ever recompiling them.
We are back with the issue of mixing presentation and design feature with code today because primarily adding code any where has become so much easy and cheap to do with our current technology.
However this problem keeps coming back because we have not solved a fundamental problem in program design and execution. Let me state the problem. When we write an application there are features in the application to which we put our mind into. Depending on the nature of the issue in hand we get domain experts, coding experts in different areas like taxation, security and usability to address these features. However the product we produce at the end of the day ie. the run time module is one big chunk or a random mix of smaller chunks. We have no idea which feature is being produced as the machine is executing the application code. In terms of object technology methods are passed almost randomly from one object to other without any recognition of features these objects are catering for.
We might keep the separation of concern alive at the code level , when it comes to the technology of run time or execution it is a mix of all features. The code cannot run by features selectively.
The current dilemma with mixing of presentation engine with business logic is just a revelation of the weakness in this program execution technology. Our technology does not allow taking two different features [at our system definition process] and mixing them at will at the execution time or withdrawing one selectively at execution time. This problem so far to some extent is similar to what AOP is trying to solve.
However XFFDS takes an approach where features become fundamental unit of programming rather than after thoughts.
To summarise XFFDS approach: an object can be looked upon as a collection of fields and methods. What each method in an object does is to create a subset of fields from the object and link with another subset of fields in another or the same object. In XFFDS we propose to give each of these links a name and represent an application feature as a sequence of these links and subsets. If we take this view a feature is represented in the same fashion at design time and run time. The links between the subsets at design time will give a meta-view of the application which is embedded in the code itself. This meta-view are the links that states why the designer did what he did. The flow between subsets then become staff that we can study before putting a single line of program code.
This can sit on top of the AOP framework in Jboss. This will enable any java object to adopt to XFFDS framework with no code change in the object. XFFDS stands for execution, feature and Focus based server. There are 3 servers co-operating enabling the seperation of feature, focus and their mixing. The focus is referring to the subsets of fields mentioned above.
The approach will complement today's object technology by looking at subsets [which I actually call hypersets] the more fundamental units that objects are made of . In effect we have a prototype building for data flow and entity flow as part of Jboss on which builds the features as skeleton of the application before putting the flesh- the actual program code . I welcome your feed back and interest.