Sunday, March 22, 2009
Form Maker debut
We have been asked a number of times "where is the Jetfire visual designer"? Our attention was aimed at getting the programmatic model correct. We are now starting to deliver purpose-built visual designers. Why multiple designers?
The objective of Jetfire visual designers is to:
- Provide simple GUI's for building applications
- Take the 'programming' out of 'application programming'
- Easily deploy applications
- Provide a one-step process to writing and deploying applications
Figure 1: Form Maker in design mode
Our first release for purpose-built visual designers includes Form Maker. It is a simple first step, but designed to be practical. The key features of Form Maker include:
- Add one or more properties
- Reorder properties
- Identify the property type (text, date, duration, integer, and more)
- Build applications based on previous programs
- Form validation
- One-click deployment
Figure 2: Form Maker in layout mode
Click the 'Show Form Layout' link and Form Maker displays how the Form is displayed to a user.
The differentiator of Form Maker is one-click deployment. The user creates an application and with one click adds the application to the Jetfire ecosystem – ready for use.
Figure 3: Property types
Figure 3 shows the types of properties that can be added to a form in Release 1.
'UnknownType is displayed when reviewing an existing program and the property type is unknown, e.g. an enumeration.
Labels: Jetfire
Supporting Quality Processes
In a previous blog, we stated that the "objective of Jetfire is to simplify the workflow creation/modification process so that Power Users can build workflows and upgrade them".
In the early 90's, I worked for a large corporation that implemented ISO-9001. To be compliant with ISO-9001, each department has to show that they followed their processes. The easiest process to show compliance was the software submission process, because it was tooled. Tracking the paper processes required continuous manual intervention.
Continuous Improvement is the name of the game to improve product quality. Software that naturally reinforces the rules is required to support quality processes. Tooling with the ability to easily upgrade is required. With this back-drop, let's look at Jetfire.
- New Jetfire workflows are easily added, without upgrading system software.
- Jetfire workflows should easily up-version.
- Light-weight workflow ecosystem
Jetfire programs are built on an object oriented ecosystem that executes Jetfire code interpretively. This approach allows Jetfire workflows to be easily uploaded, without the need to upgrade the system software.
To up-version code, version is included in every object in the system. New code creates a new version of a Workflow Class, which are related to previous versions of the named workflow class. New and previous versions of the Workflow Class are accessible with the preferred class to be instantiated being the current version.
Finally, the small size of the Jetfire ecosystem provides a compact environment that is targeted at building applications.
Labels: Jetfire
Writing programs for the workflow domain
Jetfire is a DSL (domain specific language). So what domain are we talking about?
When we started Jetfire, the goal was to create a language that makes workflows easy to write. I can say without reservation that we have achieved that goal. Let's review the differences between Jetfire and C#.
- Jetfire is based on C#, so that programmers can easily write it.
- The keyword 'workflow' replaces 'class'. 'workflow' is used to activate first class support for workflow constructs.
- Dynamic Access Modifiers are used to make class members public/private depending on who is using the class.
The Jetfire domain specific language incorporates first class support for workflow constructs.
Let's review some examples of how Jetfire simplifies writing workflows.
Example 1: States – Some workflows are state driven. Jetfire Methods include a new type of method: the state method. 'enterstate' is a keyword used to promote the workflow into the specified state.
public workflow MyFlow // 'Start' state Start() { // place code to be executed when the state is entered. } // constructor public MyFlow() { // put the workflow into the Start state enterstate Start() } } |
Example 2: Dynamic Access Modifier example using states – the AddData method is public when the workflow is in the Start state. Otherwise, the AddData method is private.
private ArrayList dataList = new ArrayList(); // method 'AddData' has a dynamic access modifier public void AddData(string data) : states(Start) { this.dataList.Add(data); } |
Example 3: Dynamic Access Modifier example using access – the DoSomething method is public if the logged in user has the Role 'Approver'. Otherwise, the DoSomething method is private.
public void DoSomething() : access("Approver") |
These are some powerful examples how a domain specific language can simplify writing workflows.
Labels: Jetfire
Tuesday, March 17, 2009
Why a Domain Specific Language is better than a Framework!
If you are a programmer you use frameworks. Some frameworks such as a collection framework are almost indistinguishable from the language. I know in my C# code I find almost all my classes contain either 'List' or 'Dictionary'.
Other frameworks such as ADO .net are very large and require quite a bit of time learn. They provide an indispensible service to your application but are very difficult to learn and use. The application code that employs the framework is almost unintelligible. Adding more comments or the more judicious use of variable names seems to have no effect on making the code look better. The problem is that most frameworks need to expose details of internal concepts to application as numerous tunable parameters and properties. This is required since a typical framework has no other mechanism of inferring intent.
The need for the framework to have numerous tunable parameters and properties (lazy loading, concurrency issues, etc) compounds usage problems. This is because in order to be used correctly they need to be understood. Subtle errors in understanding a concept of a framework produces either subtle errors in the application or causes the application not to run a peak performance.
Using a domain specific language addresses a number of these problems.
- A domain specific language after all is just another language. Most languages can be learned in a few hours to a few days. When we wrote Jetfire we started with C# syntax adding few specific features. A programmer's investment in understanding languages could be reused. The additional features in Jetfire, for example, are consistent with the C# programming paradigm.
- The code in a DSL is designed to be understandable and compact. Unlike working with a framework where hundreds of lines of code are required just to provide initialization, working with a DSL typically requires very little code.
- When you write code in a DSL the language is able to understand the programmer's intent and therefore is able to hide most of the complexity. For example Jetfire understands that variables should be saved to persistent storage. Therefore Jetfire does this automatically without the application programmer writing extra code. Jetfire also knows if a variable is used inside a method that it doesn't need to be saved because that variable is only valid as long the method is executing.
Further reading:
Labels: Jetfire, persistence
Subscribe to Posts [Atom]
