Enterprise Haskell

This is a survey page aimed at helping to answer the question: How can we use Haskell in the Enterprise?

Introduction

When a business searches for software to meet a particular need, along with the functional requirements, they provide a set of non-functional requirements that they expect to be met. These non-functionals are mostly common to any application that is required to be enterprise grade. The Haskell core language in itself doesn't meet these non-functionals so in the discussion that follows the word "Haskell" is used to mean the core language plus libraries and packages built by the community.

In the inital version of this paper, the following sources for packages are used:

• 'Haskell Communities and Activities Report' [1]
• HaskellDB [2]

Features of enterprise systems

The features common to all enterprise systems are:

• Persistent Data - Data needs to be stored between instantiations of the application. Typically for a desktop application these are files on a local disk which the application reads and writes to directly. This sort of storage is not suitable for enterprise systems for the reasons that follow.

• Lots of Data - A simple file based storage for an application is acceptable where there is a 'small' amount of data but when indexing and caching are brought in, a database management layer is required.

• Concurrent Data Access - Not only is there lots of data, it needs to be accessed by more than one person and not just as a partition for each user (which can be achieved by files) but the data needs to be shared and control imposed over access and updates.

• Lots of User Interface Screens - Not only is the application itself complex but there is likely to be different modes of operation depending on the class of users - some users require just query and viewing access whilst others require full update access. These modes of access and their associated screen layouts should be configurable rather than hard coded.

• Integration - No system is an island. Integration to other systems is required and done using standard middleware

With all of the above complexity, the system still needs to perform as well as a dedicated desktop application. In order to met this the application is typically divided into tiers:

• Database Layer (also referred to as Model)
• Application Logic (Also referred to as Controller)
• Presentation Layer (Also referred to as View)

The question then breaks down into how can Haskell meet of the above architectural needs and in particular how can multi-tier Haskell applications be constructed?

Refer to Patterns of Enterprise Application Architecture, Martin Fowler

Non-Functional requirements and Haskell

The architectural needs listed in the previous section are often presented in the form of non-functional requirements (NFRs). Furthermore, it is not expected that the developers will implement all the NFRs from the ground up since some of these can be meet using a third-party tool or library. In the latter case integration, typically through an API, is required to be supported.

At first sight NFRs, seems to be self contradictory, surely all requirements are functional - they are what I want the system to do? Yes, this is true but think of these as non-domain specific requirements or domain free requirements - they are requirements for all applications regardless of whether it is is an e-commerce application or a customer management system. Having said that, one persons NFR is another persons' requirement; a security NFR is a functional requirement for someone developing a security package. In most cases however security is an NFR.

NFRs are broken down into the following. The order of the list is from the most concrete and technical to ones that are slightly more subjective or forward looking. These later ones are often met by words, rather than technical deliverables.

The table below describe how Haskell and associated libraries and contributions can meet each of the above NFRs. How it can provide the building blocks to build Enterprise applications.

Foreign Language Integration	Key to meeting many NFRs as it provides access to libraries that do realise the requirements.	The following build on Haskell's Foreign Function Interface (FFI) FFI Imports Packaging Utility [3] C to Haskell [4]
Database	Integration to well know database backends, SQL based. It is not expected that enterprise applications come with their own 'home cooked' database and instead the expectation is that they will utilise an existing database package, typically an RDMS. In most cases this is mandatory, as the enterprise can leverage existing DBA skills, be guaranteed that their data is not locked away in a proprietory database and they can access it easily using reporting and data mining applications. So the need here is for the language to support access to well know database packages.	Refer to Section 4.5 of the report CoddFish [5] Takusen [6] HaskellDB [7] [8]
Integration	Integration using common messaging middleware CORBA/COM Web Services JMS	HAIFA [9]
Security	LDAP Support Auditing and logging user actions Secure password - expiring, checking, encryption Secure protocols; nothing is left open for snooping Untrusted code cannot be run	ldap-haskell [10]
Client Delivery	Thin client (ie based in a web browser) or automatic desktop deployment is supported. Configuration of UI can be done through non-code means such as XML.	GUI Library for Haskell based on Gtk [11] wxHaskell [12] hscurses [13] HAppS [14] WASH/CG [15]
Scalability	Is it easy to scale the application to handle more users and also greater amounts of data?
Standards	XML, SOAP, SOA etc etc	HAIFA [16] HAppS [17] HaXml [18] Haskell XML Toolbox [19]
Monitoring	Able to easily monitor performance of system identify troublespots and bottlenecks
Robustness & High Availability	ACID - Data is not lost due to a crash in a part of the system If a part of the application stops due to hard or software fault can the application recover without impacting users or other systems? Failover Few/No single point of failure	HAppS [20]
Extendable	Package must be easily extensible preferablly through configuration rather than long code - compile - link cycles. Some form of scripting or plugin architecture is good. Configuration management can be done using common tools and processes.	hs-plugins [21]
Development Tools	Tools to assist programmer to streamline the edit-compile-debug cycle. For example intelligent editors, integrated development environments, tracing, profiling and debugging tools, test automation tools.	Haskell Program Coverage [22] Visual Haskell [23] Haskell & Eclipse [24] Hat [25] Buddha [26] SmallCheck [27] Dr Haskell [28]
Support	Must integrate well into business support regieme. Must be easy to support and not require months of training and years of experience. Must be easy to perform basic admin tasks.