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.

SOA Modernization of Legacy Applications

Legacy applications are generally implemented as a set of COBOL programs running directly under a mainframe operating system (for example, z/OS or i/OS). These programs use terminal I/O protocols (for example 3270 or 5250) and native print spooling facilities. Often the programs use an I/O module which abstracts access to tables in the mainframe database (for example, DB2) or even flat files under an access method (for example, VSAM). Batch programs are invoked by a batch supervisor process (for example, JECL or CL).

ESB as a Strategy for SOA Migration

Practical considerations often dictate that an organization migrate to a service-oriented architecture in stages, rather than as a monolithic project. Usually, this requires that the service-oriented architecture serve as the scaffolding for progressive re-engineering of a legacy application as well as serving as the infrastructure for new applications and extensions.

One strategy that can meet this need is to use an Enterprise Service Bus (ESB) to implement the service-oriented architecture. Assuming the required capabilities in the ESB, an architect might approach the SOA migration in several general stages.

Performing Service-Oriented Analysis and Design

A development architect or technical lead performs service-oriented analysis to determine how the business requirements for an automated system can best be represented as services. This analysis guides the service-oriented design, which details the services sufficiently for implementation. Both service-oriented analysis and service-oriented design should be performed as part of the technical specification process for each project involved with a service-oriented architecture.

SOA Success Factors in a Nutshell

Based on my experience and research, here is a summary of observations and best practices for successful Service Oriented Architectures.

An Example JEE Application

Application development for the Java Enterprise Edition (JEE) platform using open-source products generally requires a good deal of up-front integration effort. This is relatively straightforward for a new project. However, as the application grows, it becomes more difficult to add new components to the stack or upgrade the versions of existing components simply because of the number of objects that need to be changed.

It is useful to have a simple example application that has just enough features to exercise all the necessary integration points, but not so many as to encumber experimentation and troubleshooting. The code should be non-proprietary so that it may be freely published to support forums and used in presentations.

I've developed such an example application for a typical JEE platform stack. The techniques for this are widely available and all of the libraries and platforms I've used are open-source. It's just that there was some assembly required, so I'm presenting it in the event that it may be useful to others.

Reflections on an Ubuntu 9.10 Server Installation

The first time I ever installed a UNIX system, I loaded System V on a proprietary server called a Quotron 1000. You performed the installation by restoring a dd tape and booting into a simple configuration script. The script let you select the applications you wanted and then installed them in a preordained configuration.