Weaponizing Mobile Web Apps

At the outbreak of World War I, airplanes were a novelty. By its close, the military uses of aircraft had progressed to the essence of their modern form. In just four years, a chain of innovations opened a new strategic front of warfare which was to be decisive in the next world war and in many conflicts since.

Charge Both Ways

At the turning point of the Battle of Parker's Cross Roads, Confederate cavalry commander Nathan Bedford Forrest discovered that his forces had been caught in a pincer movement between two Federal armies, each of them much larger than his own. Having narrowly escaped personal capture by means of an audacious bluff, Forrest was approached by his aides, who asked in despair, "General, what shall we do?" "Charge!" he ordered. "Which way, sir?" they asked. "Both ways!" he replied. Powered no doubt by a combination of desperation, adrenaline and chicory-laced coffee, that's what they did -- and smashed their way through a stunned enemy to escape.

Grails From the Crypt: WebFlows

Some may argue, but as a practical matter, Tesler's Law of Conservation of Complexity is ironclad. Essential software complexity can neither be created or destroyed -- it can only be hidden.

Grails does a good job of hiding the complexity of Java web-application programming, but it has to rely on some fairly elaborate mechanisms to do this. And, like any other lie, abstraction becomes more likely to unravel as it gets more complex. As The Bard tells us:

Truth will come to light; murder cannot be hid long; a man's son may, but in the end truth will out.
[1596 Shakespeare Merchant of Venice ii. ii. 73]

A first encounter with the serialization requirement for objects in Grails webflow is like being a newlywed who has just unearthed a human femur while working in the garden. You have a choice. You can dig further to reveal the gruesome truth. Or you can shovel it over and try to set aside the possibility that your new beloved is an axe-murderer.

Grails in the Cloud: The Democratization of SaaS

Software as a Service (SaaS) is an increasingly common delivery model for horizontal-market business applications such as CRM and HR, particularly at the enterprise scale. SaaS has compelling advantages for small-scale vertical-market applications as well. However, applications for these markets tend to be authored by a domain expert working alone or as part of a small start-up. The development complexity and run-time infrastructure costs associated with web application technologies are a significant barrier to these developers. That's why most software solutions for this market tend to be stand-alone applications written using productive, but fundamentally unscalable development platforms.

Presentation Architecture: Web UI vs. GUI

This article sets out the factors bearing on the decision to implement a given user interface using a web UI or GUI presentation architecture in an enterprise architecture. It is not intended to be an exhaustive list of the pros and cons of each architecture. Rather, it presents the major differentiators that should always be considered in this decision.

Refacing Legacy Systems

Refacing is a term used to describe the process of enabling legacy applications (usually COBOL) using terminal display protocols (for example, 3270 or 5250) to present a user interface using more modern technology, typically web or GUI. In the usual sense, the term implies that the legacy display programs themselves are to remain unmodified. A typical approach is the use of software tools to generate the user interface descriptions from the display files and the use of server software to translate the user interface at run-time.

Standards for COBOL Service Interface Definitions

A service interface is the combination of:

• The set of service operations supported by a service-enabled COBOL program
• The set of data structures describing the input and output messages exchanged between a service-enabled COBOL program and its clients for each supported service operation
• The interaction mechanisms by which these messages are exchanged
• The set of guarantees that the service-enabled COBOL program asserts for each operation

The service interface describes the interface contract between the service-enabled COBOL program and all of its possible clients including data-terminal based user interfaces, batch process monitors, report programs, and web services. As long as this interface contract is unchanged, developers may change the implementation of the client without having to change the server or vice versa.