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.

Setting up a development environment for distributed processing does not have to be complex or expensive. Much of the program code written for this book was developed on a single Pentium 200 MMX machine. Additional testing was done by networking it with a Pentium 133 running NT Server. This machine was built from spare parts, and I think that NT and SQL Server probably cost more than the computer. I also used the Java SDK, Borland's JBuilder, and Microsoft Access.

This appendix will describe the two configurations, as well as how to use them to compile and run the program examples. The topics covered will include:

• Development using a single computer

• Development on a network

• Compiling and testing Java and RMI

• Setting up JDBC

Development Using a Single Computer

Experimenting and testing Java, RMI, and JDBC only requires a single computer. Windows 95 and 98 do a good job of multi-tasking, so there is no reason to go through the trial or expense of networking a second computer. Working on a single computer also saves wear and tear on the chairs and carpet moving back and forth between computers.

Figure A-l shows the processes that must be running to make RMI work on a single computer. Before the application server and the applet can communicate, you must have the RMI registry running on top of an Internet server. For you to use JDBC, you must also have the appropriate drivers and database server running. All of these processes take quite a bit of memory, so the more memory in the machine, the better.

Just as the service interface layer connects the application server to user interface programs, the persistent object layer connects the application server to databases, object stores, and other external applications. Once the business objects perform the processes requested by the service interface, the resulting data must be stored for later use. The persistent object layer routes this data to relational databases or other forms of long-term storage.

In the business environment, data is most often stored in relational databases. Although there are other persistence alternatives, such as object database management systems (ODBMS) that directly store and retrieve objects, these are products that are just now starting to move into the mainstream. Relational database is a mature technology that has been refined over 25 years, and business data processing relies heavily on this technology. For the application server to fit into the business environment effectively, the persistence layer must bridge application server objects with the relational data model.

A number of methods can be used to implement persistent objects, and many of these will be explored in this chapter. Depending on the size and scope of the application server project, these methods can range from a simple set of collections, each representing similar business objects, all the way to a comprehensive persistence service that acts as an object broker, handling persistence, life cycle, and directory services for the entire application server.

The persistent object layer forms the foundation of the application server. This layer is responsible for creating, initializing, and storing business objects derived from relational databases or other external applications. It also serves as the object broker for the application server, tracking and locating business objects already in memory. All of these tasks must be done quickly and efficiently to provide fast response time but must also work carefully to maintain the integrity of the data.

When an object is requested, the persistence layer must know how to access the data from a storage medium such as a relational database, then create the requested object from the data. Once the object is created, the new object must be registered into a data structure where it can be quickly located when the same object is requested by another process. The persistence layer must also provide concurrency control and synchronization to ensure that the data remains consistent with the database and other processes and is not corrupted when more than one process attempts to modify the attributes at the same time. The objects must also be synchronized with changes that occur in the database from other external applications so that the database itself is not corrupted.

This chapter will illustrate how to create a simple persistent object layer and discuss the implementation and programming issues involved. Although the Java language and JDBC will be used to illustrate the problems and tradeoffs that must be considered, the implementation could just as easily be done using C++ and ODBC. Java was chosen for its simplicity and brevity, not because it is a superior platform.

Part 2 examines the issues involved in designing an open, scaleable application server architecture. These include requirements analysis, user interface and business object design, persistent storage, and application integration. Emphasis is on user involvement through joint application design teams, use cases analysis, and incremental, iterative development.

Over the past year or so, quite a few software vendors have released packages they call application servers. Inprise, Oracle, BEA, and a number of others all have jumped onto the application server bandwagon, extending their product lines with products that target enterprise computing. So, what exactly is an application server?

This chapter will explore the reasons why application server technology will play an important role in the next generation of enterprise computing. Topics include:

• Two-tiered vs. multi-tiered computing

• Why I chose multi-tiered client/server

• What can an application server do?

• Costs and disadvantages of application servers

• Moving from traditional client/server to n-tier computing

Two-Tiered vs. Multi-Tiered Computing

There are quite a few advantages to traditional two-tiered client/server. The database products are very mature with heavy competition to constantly improve performance and features. Client-side development tools like Microsoft Access, Borland Delphi, and C++ Builder have become so easy to use that much of the code writes itself. Even the networks are easier to install and maintain.

But as most client/server developers soon discover, it is almost too easy. New applications multiply on the server and, with the constantly plunging price of computers, more clients keep coming on board. In no time at all, the server is overloaded. Even after all of the memory slots have been filled, more CPUs have been added, and thousands of dollars have been spent to upgrade the network, the users still complain that response time is too slow.

Up to now, this book has looked at application servers as abstract concepts—first from an architectural view, then from the designer's vantage point. It's almost time to roll up our sleeves and start the real work: translating the abstractions into program code. But before we can start programming, we need to establish a general framework that can hold the service interfaces, business objects, and persistent objects that implement the server. This chapter bridges the discussion between design and programming, describing how to establish this framework.

In addition to the program framework, we must also create an organizational framework that manages and structures the development process. This includes communication channels, programming tools, testing strategies and other administrative details. Although the emphasis of this book is on the technical side of application server development, these topics will also be discussed in this chapter.

This chapter will examine the following topics:

• The application server framework

• Additional application server requirements

• Development strategies

The Application Server Framework

In the previous chapters, we examined each of the different application server layers as separate entities, each having different responsibilities and requirements. This is the advantage of using a layered architecture: each layer can be examined on its own, viewed independently. Business object design can focus on the needs of the application. Service interface design can implement services for the user interface. The persistence layer design can focus on mapping business objects to their representation inside databases or persistent storage. By focusing on a single layer at a time, it is easier to manage the complex requirements of the application server design.

To those outside the application server team, an application server is just a set of services that support the user interface programs. The user interface collects data and then sends it to the application server, where the data is processed. Depending on the result, the application server returns either the requested data or an error message. The user interface programmers do not need to know how the service interface does its job—only that it works according to the specifications.

This is the goal of a good service interface design. The implementation details should be irrelevant to those working with the services. The services are well defined and documented and the results are understood, but only the application server programmers need to know how the results are obtained.

This chapter will examine how the service interfaces are designed, from use case analysis through design specifications. The topics covered will include:

• What is a service interface?

• Design by interface

• More on JAD: developing use cases

• Turning use cases into services

• Building services out of business objects

What Is a Service Interface?

A service interface is more than just a list of function calls specified by the user interface programmers. Each interface should contain a set of standardized services that not only make sense within the context of a single application, but conform to an organization's standard application architecture. This requires each service to conform to standard naming conventions and use consistent parameter-passing and exception-handling protocols. The user interface programmer should be able to take a new service interface and quickly and easily integrate it into an application with a minimum of research and testing.

A service interface is a set of consistent, easy-to-use application services that can be called by user interface programmers to perform the tasks requested by the user. When the post transaction button is clicked, the user interface calls the post transaction service, supplying the relevant data items. The user interface programmers have no need to know how the transaction is posted; they simply need to know how to request the appropriate post transaction service.

Once the data is supplied to the service interface, it is up to the application server programmer to ensure that the necessary business objects are retrieved by the persistent object layer and that methods are called to perform all of the tasks requested by the service interface specification. If the business objects are designed correctly and the persistence layer can correctly retrieve the business objects, programming the service interface should not be a difficult task.

What complicates service interface programming is the additional layers of middleware managing objects distributed over a number of different computers. This restricts the amount of data that can be passed between the client and the service interface, since much of the data must be passed through network connections and be marshaled to meet the requirements of the remote machine's data format. The network also adds a multitude of new exception and error conditions that must be anticipated. As an added restriction, the same service may be executing simultaneously for a large number of different clients, each requesting services for any number of different sets of data.

This chapter will examine these technical requirements and explore some of the programming techniques available to address these challenges.

One of the most striking differences between traditional client/server development and the application server environment is the need to service a large number of users simultaneously. Instead of relying on database servers to manage concurrent access, it is now the responsibility of the application programmer to anticipate these needs, making sure that one user's service request does not interrupt or corrupt another service already running. Because of this added complexity, the programmer must decide when objects can be shared, when separate instances must be created, how to synchronize persistent data between objects, and how to coordinate changes in data when there is a chance that it can be modified by other applications.

Fortunately, you have many tools and techniques available to handle these issues. You can purchase middleware tools to replace some of the functionality that used to be provided by the database server. Most development environments provide tools to manage concurrent access, object brokers can assist in life cycle management, and transaction monitors can support complex application dependencies. There are also techniques that can ease concurrency and life cycle management. Application server implementation is far more complex than traditional client/server development, but with the proper approach, your application framework will be open, robust and ready to grow with your business.

This chapter will examine the following issues:

• The trouble with multiprocessing

• Multiprocessing within the application server

• The class factory model

• Multi-threading

• Synchronizing objects and data

• Transactions

The Trouble with Multiprocessing

Multiprocessing, the ability to service many different users at the same time on the same machine, introduces several new issues that are not often addressed in traditional client/server development.

Part 1 offers an overview of application server architecture, describing its benefits in the business environment and providing an overview of its fundamental technologies including multi-tiered client/server computing, distributed applications and middleware.