Steve Vinoski's Blog

In my column entitled “The Functional Web,” published in the IEEE Internet Computing magazine, I write about the application of functional programming languages and techniques to web development. You can access the original columns on-line at the Internet Computing website, or access PDFs of the same using the links below.

Please note: The IEEE holds the copyrights on these works. This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author’s copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

• In the November/December 2012 column, The Nitrogen Erlang Web Framework, I take at Nitrogen, a popular open source Erlang Web framework that supplies developers with a rich set of features for building websites. It uses an event-driven model, letting Erlang developers use regular language features to write client-side elements as well as server-side code for handling webpage events. It also lets developers easily write interactive Web applications that use AJAX or long-polling techniques to deliver excellent responsiveness to end users. This article provides a brief introduction to Nitrogen along with examples highlighting the framework’s features.

• In the September/October 2012 column, Server-Sent Events with Yaws, I explore the fact that developers are increasingly building Web applications that rely on notifications from the server, such as updates from social networks, alerts from application monitors, or information from sensor networks. But given that HTTP is a request-response protocol, such notifications can be challenging, giving rise to techniques such as long polling and to entirely new protocols such as WebSocket. These challenges can be especially significant for mobile applications due to intermittent client connectivity and device battery-life issues. This column explores how the Yaws Web server, written in the Erlang programming language, supports the W3C Server-Sent Events notification approach.

• In the July/August 2012 column, Play2: A New Era of Web Application Development, guest columnist Sadek Drobi, CTO of Zenexity, talks about how today’s Web evolutions and the emergence of software as a service and Web services have led to new challenges in programming: distribution, scalability, management of various data formats, stream management, and so on. He explains that the open source Play2 framework can significantly aid developers in capitalizing on the opportunities the Web offers while minimizing potential risks by leveraging the strengths of functional programming. He outlines functional programming’s power in this context at several levels: data and data format manipulation using higher-order functions; reactive composition with nonblocking I/O for scalability; and reactive stream processing and manipulation using Iteratees with WebSockets and Server-Sent Events.

• In the May/June 2012 column, Roy: A Statically Typed, Functional Language for JavaScript, guest columnist Brian McKenna explains that JavaScript can be hard to write correct programs with but is one of the only ubiquitous platforms in computing. Roy is a safe language for writing correct programs on this platform. It uses type safety and immutability to provide guarantees about your program and help with reasoning. Roy also tries hard to output clean JavaScript to help with debugging, performance, and reasoning.

• In the January/February 2012 column, Wriaki, a Webmachine Application, I describe a wiki application called Wriaki built in Erlang over Webmachine and Riak. Webmachine is a Web toolkit unlike any other. Whereas typical Web frameworks focus on programming language first, sprinkling pieces of HTTP into the mix where convenient, Webmachine puts HTTP semantics front and center. In doing so, it handles much of the HTTP “heavy lifting” for applications, and helps them perform as good Web citizens that work well with other Web components such as caches, proxies, and web-savvy clients.

• In the November/December 2011 column, ClojureScript: Functional Programming for JavaScript Platforms, guest columnist Mark McGranaghan covers the ClojureScript programming language. ClojureScript is a compiler from a Clojure-like functional programming language to JavaScript. ClojureScript features deep integration with the Google Closure JavaScript library and whole-program optimizing compiler. ClojureScript brings efficient functional programming to JavaScript environments such as the browser, which are becoming increasingly important components of full-stack Web applications.

• In the September/October 2011 column, Scala Web Frameworks: Looking Beyond Lift, guest columnist Dean Wampler explains how Scala developers have many options for Web development frameworks tailored to their language, in additional to other JVM-based Web frameworks written in other languages. He also points out that Scala’s best-known Web framework is Lift, which was explored in two previous columns. Dean’s column surveys the other Scala alternatives and dives into three representative examples: Play, Scalatra, and Finagle.

• In the July/August 2011 column, Yaws: Yet Another Web Server, I cover the modestly named Yaws, an open source Erlang Web server known for its reliability, stability, and scalability. It started in 2001 as the brainchild of legendary Erlang programmer Claes “Klacke” Wikström, who also invented several important Erlang features, including Erlang term storage (ets), Distributed Erlang, the Mnesia database, and the Erlang bit syntax. Yaws is a general-purpose HTTP 1.1 Web server consisting of a relatively simple core surrounded by implementations of a wide variety of features such as file serving, response streaming, AJAX support, websockets, support for CGI and FCGI, and application embedding. This column details some of the features of Yaws.

• In the May/June 2011 column, Warp: A Haskell Web Server, Michael Snoyman of Suite Solutions details the Warp web server. Warp is very fast and quite small — fewer than 500 source lines of code — due to recent advances in the state of the Glasgow Haskell Compiler (GHC), the multithreaded Haskell runtime and high-performance libraries.

• In the March/April 2011 column, Process Bottlenecks within Erlang Web Applications, I explore performance issues related to process fan-in within Erlang web applications. Erlang processes are so fast and inexpensive to create that it’s easy for developers to forget to pay attention to processes that could become severe bottlenecks under load.

• In the January/February 2011 column, The Snap Framework: A Web Toolkit for Haskell, guest columnists Greg Collins and Doug Beardsley discuss web development in the Haskell programming language. They look at Snap, a simple, expressive web development framework with an integrated, high-performance HTTP server.

• In the November/December 2010 column, Node.js: Using JavaScript to Build High-Performance Network Programs, co-columnist Stefan Tilkov and I write about one of the more interesting developments recently gaining popularity in the server-side JavaScript space, Node.js. It’s a framework for developing high-performance, concurrent programs that don’t rely on the mainstream multithreading approach but use asynchronous I/O with an event-driven programming model.

• In the September/October 2010 column, Clojure Templating Libraries: Fleet and Enlive, guest columnist Glenn Vanderburg describes his experiences with the Fleet and Enlive templating libraries for Clojure

• In the July/August 2010 column, Getting Started with Google App Engine and Clojure, guest columnist Aaron Bedra shows how to use Clojure, a relatively new but robust Lisp implementation on the Java Virtual Machine, create and deploy an application using the Compojure web framework on the Google App Engine platform.

• In the May/June 2010 column, A Chat Application in Lift, David Pollak and I show how to develop a chat application in Lift, a web framework that abstracts the HTTP request/response cycle. It’s written in Scala, and it owes much of its brevity and power to the language.

• In the March/April 2010 column, Developing RESTful Web Services with Webmachine, Justin Sheehy and I evaluate Webmachine against the RESTful Web Services Development Checklist. Many web frameworks focus on projecting programming language entities out onto the web, handling HTTP header parsing and the protocol itself but leaving it up to developers to make sure their classes and objects obey the rules of REST and HTTP RFC 2616. Webmachine is an innovative and unique Erlang framework that codifies the rules and decision flows of HTTP, thereby allowing resource developers to focus mostly on resource implementations and state representations. Webmachine also provides sensible defaults for what it requires of resource implementations, enabling developers to implement only the specific framework callbacks required to realize their particular resources.

  Note: thanks to Ian Wilkinson for catching a typo in this column. The part explaining how to generate a Webmachine server includes an example that calls ./scripts/new_webmachine.erl where it should have called ./scripts/new_webmachine.sh instead.

• In the July/August 2009 column, Build Your Next Web Application with Erlang, Dave Bryson and I describe Erlang-based web development’s current state of the art, highlighting several Erlang web servers and web development frameworks. In our experience, Erlang is very well suited for server-side web applications.

• In the May/June 2009 column, Scala and Lift — Functional Recipes for the Web, Debasish Ghosh and I explore Scala, an OO-functional language on the Java virtual machine, and Lift, a framework implemented on Scala’s functional features. The Scala language offers functional programming features and asynchronous message-passing concurrency alongside a statically typed model. Lift exploits this model to offer secure, higher-level abstractions to Web developers.

• In the March/April 2009 column, Welcome to “The Functional Web”, I introduce my brand new column, covering the application of functional programming languages and techniques to the world of web development. This column explains why I believe functional languages offer much promise for software development in general and web development in particular, and talks about a few of the languages and frameworks I intend to cover in future columns.

---

All the columns below are from my old Internet Computing column, “Toward Integration.” In that column, which ran from March/April 2002 through January/February 2009, I wrote about various aspects of middleware, integration, distributed systems, and programming languages and techniques for developing such systems.

• In the January/February 2009 column, New Year’s Integration Resolutions, I suggest a few new year’s resolutions you might make if you want to improve your projects and approaches this year to make them more integration-friendly. All the resolutions I offer are based on real-world issues I’ve personally experienced in my own work.

• In the November/December 2008 column, RESTful Web Services Development Checklist, I cover five of the primary areas that developers must address when writing good RESTful web services, including “Applications and Hypermedia,” “Methods,” and “Conditional GET.” You can also access the PDF for this column via the Internet Computing website.

• In the September/October 2008 column, RPC and REST: Dilemma, Disruption, and Displacement, I explore technology adoption and how it affects the “RPC vs. REST” debate. Technologists often act as if the debate were purely technical, but technology choices are never really quite so black and white. This column examines the non-intuitive theories and evidence behind Clayton Christensen’s “innovator’s dilemma” to explore technology life cycles, discuss what makes different customers choose different technologies, and consider how different types of innovation affect the evolution of integration products. This column is also available in the IEEE Distributed Systems Online journal.

• In the July/August 2008 column, Convenience Over Correctness, I look back over the history of RPC-oriented distributed computing approaches and wonder why we’ve pursued them for so long even though we’ve been aware of their fundamental flaws for many years. The answer, I believe, is that we’ve chosen convenience over correctness — we’ve treated distribution as something we can jam underneath our general-purpose programming language abstractions, rather than as something that to be done correctly requires entirely different abstractions and approaches. This column is also available in the IEEE Distributed Systems Online journal.

• The May/June 2008 column, Multilingual Programming, explores reasons why being adept at using multiple programming languages can be helpful for integration projects (and actually, useful for programming projects in general). Integration projects inherently involve diverse technologies. Even so, many integration developers try to force problems to fit their favorite programming language, regardless of how well that language helps solve the problem, and regardless of whether other languages offer a better fit. Multilingual programmers embrace the diversity of programming languages, enabling them to apply different languages to different integration problems to produce higher-quality solutions that are faster, easier, and less expensive to develop, maintain, and enhance. This column is also available in the IEEE Distributed Systems Online journal.

• In the March/April 2008 column, Demystifying RESTful Data Coupling, I discuss issues surrounding data coupling in RESTful systems. REST detractors often claim that the uniform interface constraint simply moves all the coupling issues from the interface to the data, but as this column explains, that simply isn’t the case. RESTful data allows for looser coupling than data exchanged in RPC-based systems. This column is also available in the IEEE Distributed Systems Online journal.

• In the January/February 2008 column, Serendipitous Reuse, I explore some issues that arise in distributed services systems that either inhibit or enhance reuse. By definition, we can’t plan for serendipity, but it might be possible to make a given situation more amenable to it. The question becomes: Is it feasible to arrange the primary elements of an area such as enterprise integration in a way that encourages the development of beneficial applications that the enterprise architects never dreamed of? This column is also available in the IEEE Distributed Systems Online journal.

• In the November/December 2007 column, Reliability with Erlang, I explore Erlang’s outstanding support for building highly-reliable systems. I first discuss some of the problems that such systems face, and then explain the core primitives that Erlang provides for dealing with them. This column is also available in the IEEE Distributed Systems Online journal.

• In the September/October 2007 column, Concurrency with Erlang, I follow up Rachid Guerraoui’s column from the previous issue (see below) and suggest that another answer to enabling developers to write highly-concurrent systems is to give them a language specifically designed for just that. Erlang is getting a lot of attention these days, not only because of its concurrency capabilities, but also because the robustness and reliability of the systems it can help produce. Joe Armstrong’s excellent book Programming Erlang is also helping fuel the current interest in Erlang. In this column, I show some example programs in Erlang and compare them against similar multithreaded code in Java and C++. This column is also available in the IEEE Distributed Systems Online journal.

• In the July/August 2007 column, A Smooth Concurrency Revolution with Free Objects, my guest columnist Rachid Guerraoui discussed the fact that popular programming languages and approaches are ill-equipped to deal with the fact that our processors are rapidly gaining multiple cores and are thus far more capable than ever of executing software concurrently at virtually all times. He explains the notion of “free objects” as a way of introducing concurrency into OO systems without forcing programmers to give up the OO development approaches they’re comfortable with.

• In the May/June 2007 column, Let’s Have a Conversation, my guest columnist Gregor Hohpe discusses conversational patterns. He provides an overview of what such patterns are, explains choreography and orchestration, and explains that conversations are a critical but often overlooked aspect of a service’s interface.

• There was no March/April 2007 column. I was too busy with a job change to write for that issue — sorry about that!

• In the January/February 2007 column, REST Eye for the SOA Guy, I try to take a middle ground with respect to the REST vs. SOA debate by trying to explain to SOA proponents like myself the benefits that REST brings to distributed systems. This column is also available in the IEEE Distributed Systems Online journal.

• In the November/December 2006 column, Advanced Message Queuing Protocol (AMQP), I provide an overview of AMQP, which is targeted to become the first standardized enterprise messaging protocol. This column explains the basics of AMQP and describes what’s currently happening in the AMQP community. This column is also available in the IEEE Distributed Systems Online journal.

• In the September/October 2006 column, Ruby Extensions, I explore how you can integrate Ruby with your existing C or C++ middleware. Writing Ruby extensions is relatively easy, but still requires good design and proper layering to get it right. The productivity gains you can get from being able to write Ruby instead of C or C++ can be quite significant. This column is also available in the IEEE Distributed Systems Online journal.

• In the July/August 2006 column, Enterprise Integration with Ruby, I review Maik Schmidt’s new book of the same name. If your background is like mine — building middleware with traditional languages like C++ and Java — you’ll want to read this book. Ruby is a great language, and Schmidt provides a broad, balanced, and compelling picture of how it can be successfully applied to enterprise integration projects. This column is also available in the IEEE Distributed Systems Online journal.

• In the May/June 2006 column, Scripting JAX-WS, I continue my exploration of the general lack of overlap between the middleware and dynamic scripting language communities. This time, however, I contribute an answer: how to script JAX-WS 2.0 using the JavaScript or E4X languages, based on the Celtix open source ESB. This column is also available in the IEEE Distributed Systems Online journal.

• In the March/April 2006 column, The Language Divide, I explore why it seems there’s so little overlap between the middleware and dynamic scripting language communities. I also explain why I believe this is changing. This column is also available in the IEEE Distributed Systems Online journal.

• In the January/February 2006 column, The Social Side of Services, I talk about some of the hardest barriers to successful SOA development and deployment. Here’s a hint: they’re not technical. This column is also available in the IEEE Distributed Systems Online journal.

• In the November/December 2005 column, Old Measures for New Services, I go back to structured programming to see how its measures of system quality can still be applied to today’s service-oriented applications.

• In the September/October 2005 column, RPC Under Fire, I review Steve Loughran’s and Edmund Smith’s excellent paper entitled Rethinking the Java SOAP Stack, which provides a detailed and accurate critique of JAX-RPC, and I also talk about problems with RPC in general. I conclude the column with a look at alternatives to RPC-style programming.

• In the July/August 2005 column, Java Business Integration, I take a look at the JSR 208 specification and why it, unlike most Java specifications, uses something other than Java for service interface definitions. This column is also available in the IEEE Distributed Systems Online journal.

• In the May/June 2005 column, WS-Addressing Metadata, I discuss the ability to include metadata within WS-Addressing endpoint references (EPRs), and how it resolves my concerns regarding the use of EPRs as web service references. This column is also available in the IEEE Distributed Systems Online journal.

• In the March/April 2005 column, Web Service References, I discuss issues with and progress toward the provision of a standard web services reference, used for addressing web service instances. This column is also available in the IEEE Distributed Systems Online journal.

• In the January/February 2005 column, A Time for Reflection, I discuss the growing utility and importance of reflective approaches for modern applications. Reflective techniques offer significant flexibility advantages for today’s systems.

• In the November/December 2004 column, WS-NonexistentStandards, I take a look at the “WS-*” collection of specifications and wonder why we have so many web services (WS) specifications, but so few actual standards. This column is also available in the IEEE Distributed Systems Online journal.

• In the September/October 2004 column, Is Your Middleware Dead?, I step outside the realm of pure technology and discuss our industry’s tendency to declare anything but the latest technologies or approaches as "dead" without any consideration for how technology markets actually work. This column is also available in the IEEE Distributed Systems Online journal.

• In the July/August 2004 column, Dark Matter Revisited, I touch again on the subject of "middleware dark matter," discussing three different distributed computing frameworks written in dynamic programming languages such as Python and Perl. This column is also available in the IEEE Distributed Systems Online journal.

• In the May/June 2004 column, More Web Services Notifications, I continue my investigation of Web Services events and notification systems from the previous column with a brief overview of the WS-Notification specification. In addition, I conclude this column with a quick look into some middleware-related weblogs. This column is also available in the IEEE Distributed Systems Online journal.

• In the March/April 2004 column, Web Services Notifications, I discuss several specifications that companies such as BEA, Microsoft, and HP have written for Web Services events and notification systems, and the various issues surrounding them, especially the need for Web Service references in such systems.

• In the January/February2004 column, The More Things Change…, I discuss middleware versioning issues, covering the fundamentals of versioning problems in distributed object systems and messaging systems. You probably won’t like my conclusion! This column is also available in the IEEE Distributed Systems Online journal.

• In the November/December 2003 column, Integration With Web Services, I talk about the promise of handling enterprise integration problems using Web Services abstractions. SOAP is not the real strength of Web Services — WSDL is. Specifically, WSDL can be used as a multi-middleware abstraction language, providing an unprecedented level of abstraction across middleware systems that’s concrete enough to allow for seamless binding and messaging to different middleware systems using their native formats and protocols.

• In the September/October 2003 column, Do You Know Where Your Architecture Is?, I talk about various issues related to middleware architectures, or the lack thereof, including the difference between technology and architecture. I also compare Extreme Programming (XP) and Model-Driven Architecture (MDA) as different ways of developing architectures.

• In the July/August 2003 column, Invocation Styles, I present the basics of different kinds of ways distributed applications call services, and discuss the various trade-offs one makes when adopting a particular calling style.

• In the May/June 2003 column, It’s Just a Mapping Problem, I talk about issues related to mapping the artifacts from one middleware system into another. This topic gets a lot of attention today because those working with Web Services are just now discovering how thorny some middleware mapping problems can get. This column is also available in the IEEE Distributed Systems Online journal.

• In the March/April 2003 column, The Performance Presumption, I discuss what I see as an unbalanced pursuit of middleware performance. I explain why I think performance receives more focus than it often deserves, and discuss other middleware characteristics that often deserve as much or more attention and focus. This column is also available in the IEEE Distributed Systems Online journal.

• In the January/February 2003 column, Service Discovery 101, I present the basics of service discovery. As more and more people move toward service-oriented architectures, they find out just how important — in fact, critical — discovery is for any flexible middleware deployment, where avoiding hard-wired point-to-point connections is key.

• In the November/December 2002 column, Chain of Responsibility, I talk about one of my favorite and most frequently used patterns in middleware development: the Chain of Responsibility pattern. It’s amazing how many times this pattern appears in modern middleware.

• In the September/October 2002 column, Middleware Dark Matter, I present a case for the existence of middleware “dark matter.” This dark matter represents non-traditional middleware that’s used extensively for simple integration projects, but nobody ever really talks about it — things like Perl, Python, Tcl, and Visual Basic. However, this dark matter heavily influences all of middleware, and is a large part of the drive behind Web Services. This column is also available in the IEEE Distributed Systems Online journal.

• In the July/August 2002 column, Web Service Interaction Models, Part 2: Putting the “Web” in Web Services, I conclude my coverage of Web Services interaction models by discussing RPC, messaging, orchestration, and the application of the REpresentational State Transfer (REST) architectural style to Web Services. REST is what has allowed the Web itself to proliferate, so standardizing Web Services interaction models that ignore REST would be very Web-unfriendly.

• In the May/June 2002 column, Web Services Interaction Models, Part 1: Current Practice I write about Web Services interaction models and why some popular approaches to web services are not as simple as they’re made out to be. Some like to promote the direct exposure of low-level software assets directly as web services, but I explain why that approach, while sometimes useful, generally causes problems because of inappropriate levels of abstraction.

• In the March/April 2002 column, Where Is Middleware?, I provide a general overview of the state of middleware in our industry today. Middleware is basically everywhere, and I discuss the various forces that have shaped it, along with where it seems to be going.