Cornerstone Concepts Paper Published

First draft of Cornerstone Concepts has bee published. It should be interesting read for everyone. We will be adding examples to illustrate the rather abstract concepts.

What Can We Learn from the Comair Snafu?

Today many blogs quoted this article about how a 16-bit counter overrun grounded the entire fleet of Comair on Christmas Day.

The SBS Crew Check system tracks all the details of where each crew member is scheduled and keeps a log of every scheduling change. Tom Carter, a computer consultant with Clover Link Systems of Los Angeles, said the application has a hard limit of 32,000 changes in a single month. "This probably seemed like plenty to the designers, but when the storms hit last week, they caused many, many crew reassignments, and the value of 32,000 was exceeded," he said.

Well, 32,000 does seem a lot to me. However, using a 32-bit counter adds no cost compared to a 16-bit one. So I think we can learn two lessons from this:

1. Doing the mininum possible to satisfy requirements (an XP principle as I understand it) should be augmented to say: if there is no (minimal) cost increase, build in the greater capability.
2. Always do the right things and never be lazy. This was the first I learned doing a real job after school. You can be lazy and OK for a moment but will be haunted later if you do care for the health (a word Kent Beck says he likes) of your software.
   

Onto Better Templating

There have been many efforts to provide an alternative to JSP: Velocity and all. JSTP is another new one. They reuse JSP syntax (which is not the best syntax to follow) and decouple templating from servlet, which is a good thing. In the Cornerstone Framework, we use a tiny subset of JSP in our MVC module. With Cornerstone Template, we also try to provide an alternative to JSP that achieves the following goals:

• Templating decoupled from servlet, so that templates can be used outside the context of servlets, for example, when you produce an email to send from a template.
• Zero coding in templates, so that templates can be done by web designers without expertise of programming
• Support of a simple and yet powerful expression language (we support OGNL)
• Support of template nesting, so that complex templates can be built on top of simple ones
  

No Non-Web RIAs, Please!

I went to this site and played with the Flex version of BlogReader. Want to know what I think? I am really concerned, to say the least. My question is why are we building a wall between this kind of applications and the Web? The Web is the level playground. When I am inside Flex BlogReader, many questions pop up in my head:

1. Why are the hyperlinks not indicated in any way?
2. When I right-click on a link, how do I open it in a tab (instead of a window)?
3. How do I do a Save Link as ... on it?
4. How do I bookmark the link directly?

You say, well, all these functionalities can be added to the implementation of this Flex BlogReader. But these are standard browser behaviors and why are they suddenly missing from this exciting new kind of RIAs (Rich Internet Applications)?

RIAs should not be non-Web. They should be part of the web. The user doesn't want to know that s/he is inside 1) a standard browser; OR 2) a special Flex window of the standard browser; OR 3) a special Laszlo window of the standard browser; OR 4) a different Swing/SWT window so that s/he knows how to react. Everything should just be the Web. That's why Cornerstone Framework pursues the Rich Thin Client approach (sophisticated and yet easy to use DHTML client) to RIA.

BTW, what do I use to read blogs? The excellent Mozilla Thunderbird. Its RSS support makes blog reading easy and well integrated with the browser.

References

---

Other People Worried about RIAs Too
Web or Desktop?

Triumph of Customizability

Niloy and I were working on release 2 of a Cisco internal application. Release 1 was built on Cornerstone. Presentation actions were all written in plain Java and then wired into page flows (they are really continuations) using the registry. Release 2 is the enhancement on some old technology. We need to call release 1 functionality remotely (release 1 and 2 run on two different servers, one with BowStreet and the other Tomcat). So we started tinkering with calling release 1's flows directly. There are many differences in the flows themselves and how they are called. So we could not reused release 1 flows as is. But the customizability of Cornerstone made it very easy for us to create alternative sequence controllers to do things a little differently. Now with only added entries in the registry and zero change to release 1 code, we were able to customize release 1 to the needs of unanticipated usage scenarios in release 2. This is the power of customizability, as is designed into Cornerstone. You can imagine we are very happy to see it work in reality.

Free Licenses for Confluence and JIRA Granted

Atlassian has just granted us a free open source license for Confluence (Wiki) and another for JIRA (issue tracker). We commend their support for open source software. Our Wiki can be found here and also our website. JIRA will be up soon. From here on, Cornerstone Framework will be full-steam ahead.

More Talk about Rich Internet Applications

It looks like more and more people are talking (ref) about the kind of Rich Internet Applications that Cornerstone Framework advocates and implements (ref1 and ref2): rich thin client approach implemented with existing DHMTL standards that has the following advantages:

1. richness of functionality
2. zero client deployment
3. standard (not only implementation technology but also client behavior) compliance

Watch this space for another series on Cornerstone: the Enabler of Rich Internet Applications.

Haloscan commenting and trackback have been added to this blog.

Cornerstone Website Gone Live!

Cornerstone website has gone live! Although the information is far from complete as we are still working on it, we are very excited at this important milestone!

UML vs DSL

There is some debate of UML vs DSL. Grady Booch basically doesn't like DSL. He wants people to stick with UML (naturally so because he was one of the founders of UML). Want to know my position? Both are right :).

Our view is there will be two tiers of developers:

• Tier 1: the traditional software professional type who write services which may require good programming expertise and experience.
• Tier 2: the casual users who just compose or orchestrate existing services created by Tier 1 people to put them together in a way suitable for the situation at hand, which should not require much programming expertise in the traditional sense. Many visual aids and metaphors can be utilized here. The user may be just dealing with, e.g., sources that provide data, sinks that consume data and service compositions/orchestrations in the middle to tie them together. For example, user's particular calendar is the union of two other calendars from the same family, in which case the 2 sources are the two other calendars and the sink is his own calendar and the service in the middle is union.

UML targets Tier 1 without a doubt. DSL currently targets Tier 1. However we think probably only DSL can suite Tier 2. DSL then is really the Cornerstone Shell concept we have talked about.

Cornerstone: the API Simplifier

Cornerstone is certainly about the big things such as software mass customization. But its impact on a developer's everyday probably starts from the fact that it's an API simplifier. The reason why simplification is possible is that the common use case is indeed simple and can be kept that way.

JMX Simplifier

A developer needs to have zero knowledge of JMX to make his/her application JMX-enabled. All that needs to be done is the following 2 lines of code:

IJMXManager jmxManager = (IJMXManager)

   Cornerstone.createInstance(IJMXManager.class);

jmxManager.manage(anyObject);

Now you can use any JMX user interface (such as the HTML adapter in the JMX Reference Implementation or MC4J) to view all the constructors, properties and operations (methods) of this object. It doesn't get simpler than that :).

Persistence Simplifier

Cornerstone provides a persistence API that is much simpler than the state of the art today. Even when you are using an excellent O-R mapping tool such as Hibernate, you have to be intimated involved with sessions and all that. When using Hibernate with Cornerstone, a developer doesn't directly use Hibernate's API. For example:

IComponentManager componentManager = (IComponentManager)

   Cornerstone.createComponent(IComponentManager.class);

IPersistentObjectFactory userFactory = (IPersistentObjectFactory)

   componentManager.createComponent(IFactory.class, "myUserFactory");

IUser user = (IUser) userFactory.createInstance(10002);

user.setFirstName("John");

userFactory.store(user);

Cornerstone is the meta-container (a container of other containers). componentManager is the component container. In a Cornerstone application, you actually don't see these interfaces because all of the dependencies are (can be and should be) injected. So the above code is more typically written this way:

IUser user = _userFactory.createInstance(10002);

user.setFirstName("John");

userFactory.store(user);

where _userFactory is an instance variable (data member, whose value is injected by Cornerstone at runtime according to configuration; or change it to getUserFactory() to make getter injection posible). Now you wonder where is the connection and also the transaction? Let's leave that to another post.

"What is Cornerstone?" Series

We have a lot of documentation to do. When we have our instance of Confluence up and running, I think we will dive right in. Before that, I am thinking about starting a series on What is Cornerstone in which we document our thoughts of what we have made Cornerstone so far and where we want it to go.

Presentation State Caching

Jon's Radio had a interesting piece today on UI of RIA (rich internet applications).

I entirely agree with the first point. Advanced widgetry alone will not save the day. We'll also need an intelligent cache -- along the lines of what the Alchemy project aimed to be.

You know what? Cornerstone is already there in term of the cache. Our modelRoot is the presentation state cached in the client through which we can do wonderful things of DHTML.

Going forward, we will move it one notch up to have a wrapping frame cache the modelRoot data and all content inside this frame will share modelRoot. This way modelRoot can be optionally retained across page refreshes. This is by the way the GMail approach.

For more views on this subject, see Jun's personal blog.

Jun's Personal Blog

Before this blog was created, Jun blogged about Cornerstone on his pesonal blog.

Temporary Cornestone Group Created on Google

Before we become a formal project at Apache, we need some facilities for developing a community. Today the Google Group for Cornerstone has been created. Yes, we tend to stay on the bleeding edge and are usually early adopters, if you notice the beta version of new Google Groups is only available today (CNET and Google Blogoscoped). It's a public group and anyone can join.

Join it today and welcome aboard!