Archive for May, 2007

Every IT generation has its seminal tome that transcends time and connects the dots in a way that no book had before it. For the object oriented generation in the 1980s, it was the Gang of Four (GoF) book. For the application architecture generation in the 1990s, it was Fowler’s book on patterns (PoEAA). “RESTful Web Services” will be, in my opinion, that book for the 2000s Web services generation.

RESTful Web Services - The Book

There is something absolutely special about this book that readers of GoF or PoEAA will immediately recognize and appreciate. The book covers a breadth of technologies and ideas yet it helps the reader see how they all connect. It uses short code samples (in Ruby, the choice of this generation) to illustrate rather than obfuscate the ideas. Most importantly, it makes the complex comprehensible and delivers epiphany-like experiences throughout the book.

There are too many highlights in this book to enumerate in this review. However, some of the coverage that I appreciated most included:

  • The chapters on resource-oriented design, since there was practically no written information available on this topic prior to this book
  • The chapter on resource-oriented best practices
  • An overview of the service building blocks, including the different representational formats and WADL, which I wasn’t aware of
  • The chapter comparing and contrasting RESTful services with the “Big” (e.g. SOAP) service overhead that is common in most enterprise environments

I would have liked to see this book touch on simple POX versus true REST and handle the resource-oriented security concerns in a bit more detail but you can only ask so much of any one book. I’m fairly confident that “RESTful Web Services”, like the seminal tomes that have gone before it, will become assumed reading

Comments No Comments »

Eliminating or reducing enterprise system batch processing is the bane of many architects looking to convert large-scale legacy systems to current platforms. Some believe, rightly or wrongly so, that mainframe-style batch has no place in modern system architectures and attempt to eradicate its existence entirely. Others are a bit more accepting and attempt to understand the role that batch processing fills in enterprise application architectural space. Even for these people, finding people with the skills to engineer batch processing systems with these newer technologies is not an easy proposition since little or nothing has been written about batch on the Java or .NET platforms.

I’ve seen various attempts at non-mainframe batch processing over the years from the simple CRON / Quartz type attempts to more sophisticated approaches that handled concepts such as scheduling, job control, retry and rollback, and parallel processing. There are commercial applications that purport to take care of much of this for you. Many of these are, for better or worse, nothing more than mainframe tools ported to the Java and .NET platforms with little regard for the differences between mainframe and non-mainframe architectures.

I’ve seen several attempts at batch processing frameworks in .NET. The earlier versions (pre .NET 2.0) of Rocky Lhotka’s Component Scalable Logical Architecture (CSLA) included admittedly simple batch functionality. Avanade’s Avanade Connected Architecture (ACA.NET), which formed the backbone of Microsoft’s Enterprise Library, had a batch element, entitled fittingly ACA Batch. Until recently, the Java open source community had only produced several half-hearted batch processing architectures which, given their lineage as the first “true” legacy replacement technology, is actually more than a bit disappointing.

A couple of month’s back, word got out that Rod Johnson, the brains behind the widely respected Spring framework, was going to be presenting the Spring Batch Framework at this year’s JavaOne conference. Yesterday, the formal announcement was made of the addition of Spring Batch to the Spring portfolio. A combination of Interface21 (the folks behind Spring) and Accenture (the folks behind Avanade) resources have collaborated in the creation of this batch framework.

I haven’t checked out the source code yet but Spring Batch purports to be non-dependant on other Spring facilities. The architectural diagram for Spring, which is shown below, won’t tell you much.

Spring Batch - Java Batch Processing

Perhaps more telling are the use cases upon which their framework is based:

  • Simple Batch Repeat
  • Automatic Retry After Failure
  • Commit Batch Process Periodically
  • Asynchronous Chunk Processing
  • Copy File to File in a Batch
  • Massively Parallel Batch Processing
  • Manual Restart After Failure
  • Sequential Processing of Dependant Steps
  • Partial Processing
  • Whole-Batch Transaction
  • Scheduled Processing.

If any or all of these things are present needs of your existing system and will need to be replaced over time, I encourage you to look at Spring Batch. Even if you’re developing in a language other than Java, take a look at Spring Batch. If historic success provides even the slightest indicator of future success, than Spring Batch will be another exciting and innovative addition to the Spring Suite.

Comments No Comments »