When Jack Welch makes the Net his top business priority you can be sure that the Internet and Net-based business have taken the critical step from possibility into reality. In fact, General Electric and countless other Global 2000 companies are quickly investigating and applying the newest Internet technologies. These companies seek to gain and retain competitive advantages in new and evolving markets through highly adaptive Net-based enterprises. Everywhere you turn, both the mainstream and business news media are focused on the Net Revolution. Both alluring and critical reports about the Web, the Information Superhighway, and Internet ventures abound.

The Net is the backbone for the new digital economy that is radically changing business models around the globe. These new business models have become differentiators that redefine market winners and losers. No one is safe from the changing tide. Past critics of the Internet have said that it's a gadget for hobbyists and computer geeks—not a valuable tool for business. It's all hype, they said. As evidence they pointed to the astronomic market capitalization of so-called Internet stocks. They said that conventional enterprises are safe from these over-publicized startups. Put simply, they were wrong then, and they're wrong now. As Business Week says “You are Merrill Lynch when Schwab.com comes along.

In Chapters 2 and 8 we defined modules for geometric shapes and regions, respectively. We will now build a third layer onto this structure: a module that provides the ability to color regions and to place them on a “virtual desktop” in a graphics window. These colored regions will be called pictures. Once placed, you will be able to “click” on a picture using the mouse, which will cause that picture to rise to the surface of the desktop (i.e., any objects partially occluding it will be pushed beneath it). As usual, I will begin the discussion by providing the module interface:

Note that the Region module is imported and exported; and recall that the Region module includes the Shape module.

In this section Haskell's pattern-matching process will be explained in greater detail. Haskell defines a fixed set of patterns for use in case expressions and function definitions. Pattern matching is permitted using the constructors of any type, whether user-defined or predefined in Haskell. This includes tuples, strings, numbers, characters, and so on. For example, here's a contrived function that matches against a tuple of “constants:”

This example also demonstrates that nesting of patterns is permitted (to arbitrary depth).

Technically speaking, formal parameters to functions are also patterns – it's just that they never fail to match a value. As a “side effect” of a successful match, the formal parameter is bound to the value it is being matched against. For this reason, patterns in any one equation are not allowed to have more than dne occurrence of the same formal parameter.

A pattern that may fail to match is said to be refutable; for example, the empty list [ ] is refutable. Patterns such as formal parameters that never fail to match are said to be irrefutable. There are two other kinds of irrefutable patterns, which are summarized below.

The first pattern is known as a wildcard. Another common situation is matching against a value we really care nothing about. For example, the functions head and tail can be written as:

in which we have “advertised” the fact that we don't care what a certain part of the input is. Each wildcard will independently match anything, but in contrast to a formal parameter, each will bind nothing; for this reason more than one are allowed in an equation.

The second kind of irrefutable pattern in Haskell is called a lazy pattern, and has the form ̃pat.

Whoever invented the button didn't need much of a business architecture model to cope with the change he unleashed. The button, a thirteenth-century invention, took 400 years to achieve widespread use. The bicycle appeared in 1818 and took 50 years to catch on. The telephone, invented in 1876, needed 35 years to find the beginnings of a mass market. Television took 26 years; the personal computer, 16 years.

Those adoption rates seem pretty leisurely by today's standards. The unyielding environment of speed in technology-induced business change is so pervasive that a CEO (or any C*O, responsible for operations, finance, human resources, technology, marketing, or any other function) who doesn't occasionally get a sense of panic perhaps doesn't get a lot of other things either.

And speed is only one element of the profound paradigm shift that is happening in how business is transacted as a result of the Internet. The e-Revolution is on and—as is the tendency of revolutions—things can be a bit confusing while the participants sort themselves out.

Maybe it was acceptable that your company created its first Web site to “keep up with the Joneses”—whoever they are in your industry. You didn't need much of a model or architecture for that decision; the Joneses, after all, were equally unsure about what they were doing and why. Maybe you made your first forays into electronic commerce and electronic business in the same fashion.

Programming, in its broadest sense, is problem solving. It begins when we look out into the world and see problems that we want to solve, problems that we think can and should be solved using a digital computer. Understanding the problem well is the first – and probably the most important step in programming, because without that understanding we may find ourselves wandering aimlessly down a dead-end alley, or worse, down a fruitless alley with no end. “Solving the wrong problem” is a phrase often heard in many contexts, and we certainly don't want to be victims of that crime. So the first step in programming is answering the question, “What problem am I trying to solve?”

Once you understand the problem, then you must find a solution. This may not be easy, of course, and in fact you may discover several solutions, so we also need a way to measure success. There are various dimensions in which to do this, including correctness (“Will I get the right answer?”) and efficiency (“Will I have enough resources?”). But the distinction of which solution is better is not always clear, because the number of dimensions can be large, and programs will often excel in one dimension and do poorly in others. For example, there may be one solution that is fastest, one that uses the least amount of memory, and one that is easiest to understand. Choosing can be difficult and is one of the more interesting challenges that you will face in programming.

The last measure of success mentioned above – clarity of a program – is somewhat elusive, most difficult to measure, and, quite frankly, sometimes difficult to rationalize. But in large software systems clarity is an especially important goal, because the most important maxim about such systems is that they are never really finished! The process of continuing work on a software system after it is delivered to users is what software engineers call software maintenance, and is the most expensive phase of the so-called “software lifecycle.”

It is possible to use a language such as FAL to control thongs other than graphics images and animations. In particular, one could use FAL to control robots, not only in terms of their dynamic movement, but also their interaction with the real world. This is an interesting declarative approach to robot control that some researchers have in fact pursued. However, I will not do so here, for two reasons: First, there are no inexpensive, standard robots that I could use to make this effort truly worthwhile (although this may change over the next few years). Second, to demonstrate this idea using a graphically simulated robot would not make it significantly different from what I have already done with FAL.

Therefore, in this chapter I will describe a simple imperative language for robot control, using a simple graphics image to simulate the robot motion. My purpose is primarily to demonstrate the use of monads to implement stateful (i.e., imperative) computations. The language, which I will call IRL (for “imperative robot language”), is much less sophisticated than FAL, although it still qualifies as an embedded DSL.

The implementation also uses a new data structure, an array, as part of the representation of the state of the robot's world. An array is functionally no different from an indexed list, but is more efficient in access time.

IEL by Example

As I did with FAL, I will begin with a brief description of how to program in IRLS and return to its implementation in the next section. Being an imperative language, the essence of IRL is a set of commands. These operations must be sequenced properly to achieve some desired behavior. Not surprisingly, it is most convenient to use the do syntax to achieve this, implying that the underlying structure is a monad.

Recall that a polymorphic type such as (a → a) is really shorthand for ∀(a)a → a, which can be read “for all types a, functions mapping elements of type a to elements of type a.” Note the emphasis on for all.

In practice, however, there are times when we would prefer to limit a polymorphic type to a smaller number of possibilities. A good example is a function such as (+). It's probably not a good idea to limit (+) to a single (that is, monomorphic) type such as Integer → Integer → Integer, because there are other kinds of numbers - such as floating-point and complex numbers - that we would like to perform addition on. Nor is it a very good idea to have a different addition function for each type of number we wish to add, because that would require giving each a different name, such as addlnteger, addFloat, addComplex, and so on. And, unfortunately, we can't give (+) a type such as a → a → a, because this would imply that we could add things other than numbers, such as characters, lists, tuples, and any type that you might define on your own!

Haskell provides a solution to this problem through the use of qualified types. Conceptually, you can think of a qualified type just as a polymorphic type, except that in place of “for all types a” we will be able to say “for all types a that are members of class C”, where the class C can be thought of as a set of types. For example, suppose there is a class Num with members Integer, Float, and Complex. Then we could give an accurate type for (+), namely: ∀(a ε Num)a → a → a. But in Haskell, instead of writing ∀(a ε Num) … we will write Num a ⇒ ….

In an era of e-Everything, there is no shortage of books proselytizing the benefits of participating in the e-Universe and warning that the failure to develop and execute a Net commerce strategy threatens your company's survival. There's no shortage of vendors and consultants offering to sell you Net commerce solutions and presenting themselves as experts with broad strategic scope and knowledge of “how to do it right.” While most of these purveyors talk a good game at the information and strategy level, they lack a rigorous approach in putting it all together.

The reason there are so many claims is because the underlying value proposition and the opportunities are enormous. Enterprises that develop a business strategy that perfectly integrates traditional real world operations with a great Net business model, and that are able to simulate its implementation and test its assumptions before investing millions, will have a major competitive advantage. A rigorous, continuously fine-tuned approach to execution will also be on the critical path.

It's not an easy thing to do. Furthermore, it has to be done fast the first time, the second time, the third, and the nth time. Your markets—everybody's markets—are changing that quickly. But major winners will determine how to innovate, sustain, remain, and then re-innovate.

Faisal Hoque has developed a robust methodology that enables an enterprise to develop its electronic commerce vision and strategy; to architect and simulate the business processes and technology applications that operationalize the strategy; and to create the repository so that every architectural component can be reused in the next iteration (and the next, and the next).

In this chapter simple graphics programming in Haskell will be explained. Graphics in Haskell is consistent with the notion of computation via calculation, although it is special enough to warrant the use of special terminology and notation. In the next chapter we will use the techniques learned here to draw in a graphics window the geometric shapes defined in the last chapter. The ideas developed in this chapter will be put into a module called SimpleGraphics:

There are many predefined functions and data types in Haskell, so many, in fact, that they demand some organization. Entities that are deemed essential to defining the fundamental nature of Haskell are contained in what is called the Standard Prelude, a collection of modules defining various categories of functionality. Entities that are deemed useful but not essential are contained in one of several Standard Libraries, also a collection of modules. The entire Standard Prelude is automatically imported into every program that you write, whereas the Standard Libraries need to be imported module-by-module.

Unfortunately, there is no standard graphics library for Haskell yet, although there is one in popular use on Windows machines called Graphics. The basic graphics functionality that we will use is defined in a library called SOEGraphics, which is very similar to Graphics but is guaranteed to work with this textbook, whereas the Graphics library may evolve over time. To use SOEGraphics, it must be imported into the module that is using it, as follows:

Graphics is a special case of input/output (IO) processing in Haskell, and thus I will begin with a discussion of this more general idea.

Basic Input/Output

The Haskell Report defines the result of a program as the value of the name main in the module Main. On the other hand, the Hugs implementation of Haskell allows you to type whatever expression you wish to the Hugs prompt, and it will evaluate it for you.

The goal of business software design is to create information tools that support the organization's business activities. The software developer has to work closely with the end users and be able to communicate in business language as well as computer language. At the same time, the end users have to become educated to understand the computer's capabilities and limitations. Business needs change quickly, so an effective design methodology must be flexible and adapt easily to changing business requirements.

N-tier computing complicates the design process even more. While traditional two-tiered client/server emphasized applications and user interfaces, n-tier design requires both application-oriented software design as well as process-oriented business object design. The pressure is on to produce applications in shorter timeframes while creating more robust, reusable business objects. The days of the coding cowboy are over.

Fortunately, there are methodologies and tools to support these requirements. The joint application development GAD) team approach brings software developers and end users together to design software jointly. Iterative, incremental development provides shorter design and programming cycles to ensure that the project stays on track and meets the end user's needs. The Unified Modeling Language (UML) can be used by both software developers and end users to communicate design ideas. Computer-aided software engineering (CASE) tools such as Rational Rose can streamline this process by creating UML diagrams, generate skeleton code and then update the UML models as the design progresses.

Creating business objects is a straightforward process in any object-oriented language. Just declare a class, list the attributes and methods, then fill in the business logic. This is basic object-oriented programming. The difficulty lies in linking these objects across a distributed network and getting them to perform useful work. This chapter will use the Java programming language to illustrate how business objects can be created and distributed across a network.

The Java programming language, released by Sun Microsystems in the mid-1990s, was originally intended to be used in consumer electronic devices such as personal digital assistants, cable access boxes, television sets, and other devices that required simple user interfaces. The language was designed to be hardware-independent by compiling to an artificial byte-code instruction set that could be easily implemented in an interpreter on almost any microprocessor device.

As the Internet and World Wide Web gained momentum, Web page authors wanted to add features like animation and interaction to their Websites. Since the Internet browsers had to run on a large variety of different computer platforms, the browser manufacturers found that the Java programming language, with its platform-neutral instruction set, was a good fit. The software could be compiled once, placed on a Web server, then run on any Java-enabled browser on a PC, Mac, UNIX, or other machine. Besides being platform-independent, the compiled files were small and moved quickly over the Internet.

Legacy software—the words conjure up images of glass-walled rooms, guys with crew cuts, lab coats, and horned-rimmed glasses, COBOL, FORTRAN, RPG, ISAM, line printers, tape drives, and maybe even punch cards: everything that's ancient and evil, old and obsolete. This is the image that vendors want their customers to see as they show off their latest client/server tools. But in reality, legacy software is a core resource. Those ancient COBOL programs are the tools that keep the business running smoothly. If this were not true, the Y2K problem would never have been an issue and all of this ancient software would have been replaced long ago. It is a tribute to those old COBOL programmers that the code still plays an important part in their organizations 15 or 25 years later.

This chapter will examine how to integrate application server technology into the existing information system environment. Topics will include:

• Design issues for application integration

• Application mining

• Turning subroutines into services

• Input and output streams

• Accessing application databases

• Synchronizing transactions

Design Issues for Application Integration

When approaching application integration, remember that there is no one best solution. Integration tasks will vary depending on the hardware and software platforms, system architecture, communication links, data models, and a host of other factors. The level of integration may also vary based on the amount of information needed and the directions of data flow. A task may require a simple data transfer, or it may need to share procedural code. What worked when linking to the general ledger system may not work when accessing inventory.