As newer more sophisticated plant floor information systems become available, techniques used to develop software for them must change. In order to create software on these disparate systems, software firms need better ways to deploy their wares. Consequently, the next logical step is coming from the Object Oriented (OO) technology that has matured since the late 1980’s into today’s Component Model. Using this model, reusable components that are "written once and run anywhere" have the potential for revolutionizing the software industry.

By leveraging this technology, vendors of software products for the corrugated industry will be able to better harness the power of the ongoing communications explosion. For the end user, this will ultimately result in faster deployment of plant information systems, less disruption to manufacturing operations in the process and a greater overall long term return on investment.

In order to understand where client server technology is today, we must first examine the evolution of network computing. Client/server architecture is commonly described in terms of tiers. Each tier represents a paradigm shift in computing technology that results in better levels of service to the end users.

SINGLE TIER

The mainframe/terminal model of interactive computing was the earliest to be widely adopted. In this model of computing all data and programs reside on a single machine or host. This centralized host runs the user interface as well as the database and business applications. Consequently, it is referred to as single-tier.

The user interacts with this machine through a terminal that has little intelligence. It knows only how to receive screens, respond to keystrokes, and send data back to the host. [Valesky 99]

TWO TIER

n the 1980’s, personal computers became popular. PCs were attractive because they were less expensive and more responsive than their mainframe counterparts, didn’t require costly mainframe computing time, and gave their users a new sense of freedom and empowerment by providing local "intelligence" or processing power. A PC user could bring a set of data into a business application such as a spreadsheet and manipulate it locally for hours without placing any requirements on the centralized mainframe system. At first, PC’s were standalone units, but over time they were integrated into networks. Eventually, many organizations began to build new information systems on the PC instead of on the mainframe. At the same time, dedicated database management systems began to appear. The combination of these two elements: the database server and the PC client are referred to as a "two-tier" or client/server architecture. [Valesky 99]

In a two-tier client/server system, the user interface runs on the client PC and the database resides on a separate server. The server in this scenario is called a database server. The application running on the client machine issues queries to the database server. The client machine contains both the presentation logic which is the code needed to build and run the user interface and the business rules which is the logic that governs how data is manipulated. Two-tier systems are still very common today.

While this is a very flexible solution, problems do arise when the need for upgrading the clients and the database occurs simultaneously. All machines must shut down for upgrades and clients or servers that fall behind in their software version typically are not useable until they are upgraded. The following example will help illustrate the issues that arise when changes need to be made in a two-tier system. [Valesky 99]

We have been given the task to implement an application that simply computes the pay rate for all our employees. We meet with our friends in accounting and determine that the business logic for compensation is as follows:

pay = hours_worked x pay_rate

In a two-tier system, the application logic follows this pattern:

1. Prompt the user for pay_rate, hours_worked, and an employee_number.
2. Calculate the pay for the employee.
3. Generate a Structured Query Language (SQL) statement to update the database.

Update payroll
set pay = (calculated pay)
where employee_number = (employee ID input by user)


4. Execute the SQL statement against the database server.

We then implement our application, install it on 50 different desktops and head for home. As we arrive at work the next morning we are greeted by a mob of angry hourly workers. It seems that we forgot one small detail in our business logic—overtime!

After realizing the mishap—and blaming the accounting department for inaccurate problem definition—the client program is rewritten and redistributed to the same desktops. For a short period of time everyone is happy. However, as weeks go by payroll notices that our application is assigning overtime for employees that should only be paid a standard rate! Again we make the necessary client program changes, kick everyone off the system, perform the upgrade and redistribute the application.

This simple example illustrates how the user interface that was developed for our two-tier client/server payroll system remained the same throughout several changes in the business logic. Unfortunately, the two-tier client/server system does not give us the ability to separate the interface specifications from the business rules; nor does it simplify the process of implementing these changes. In addition, implementation of these software changes to our two-tier client/server system still proved to be disruptive to our business operations. Consequently, let us consider an information system architecture that will greatly reduce the disruptions that everyone has learned to accept when implementing even minor software changes.

THREE TIER

In a traditional client/server architecture, the client application has grown "fat" because it contains presentation logic governing window and control manipulation, business logic governing algorithms and business rules, and data manipulation logic governing database connections and SQL queries. In a three-tier architecture, the client application contains only presentation logic which makes it a "thin" client. [Thomas 98]

This approach, as in the two-tier approach, uses the database as the ultimate repository of information and the client remains responsible for providing the user- interface logic. The business rules, however, are separated into a middle tier which is known as the Application Server. Instead of having the client machine update the database directly, the client makes a call to the Application Server, which then updates the database. This frees developers from the low-level system details of managing transactions, managing threads of execution, and system load balancing. The application developer can concentrate on business logic and leave the details of managing the data processing to the system framework. [Valesky 99]

A three-tier approach to the pay-calculation problem that we discussed earlier would consist of a client that presents the same user interface as the two-tier model. However, instead of performing the pay calculation and database update itself, the client simply calls a function named update_pay() on the Application Server. The client passes the update_pay() routine all the user-supplied parameters. The update_pay() routine then executes the business logic for determining the employees pay and updates the database accordingly.

Now, when we are faced with having to make changes to our business logic in a three-tier architecture, only the middle-tier must be changed. As you can imagine, this approach greatly simplifies the rollout of our change as it only needs to be made in one place—the middle tier.

But, what type of implementation is going to allow us to create this software distribution when you consider that a corporate computing environment contains mainframes, mid-frames, PC’s, laptops and other "electronic appliances"? Not to mention the variety of software and hardware vendors that exist on the Box plant floor. In fact, our industry is not alone:

Survey data of manufacturing sites shows that 41% of them will be implementing at least two and up to six different manufacturing application modules in 1996. These will be distributed applications and will be expected to work together. For manufacturing sites that are investing in any vertical applications, 55% would prefer to purchase the applications in suites and only 4% claimed they would prefer to purchase only best of breed, ignoring integration. The rest 41%, claimed to prefer a mix of suites and best of breed, according to the importance of the specific application to their business. [IDC 98]

Box plants should be free to purchase the best manufacturing process point solutions, also referred to as "Best of Breed," from different vendors and integrate them seamlessly into their existing information networks. As a practical matter, information system purchases will be constrained for the foreseeable future by the reality of having to support a multitude of vendor platforms and products that must inter-operate. In addition, far too much of most project budgets are consumed by integration costs. Integration has become a gray area with no clear answers leaving some to conclude that it is time to return to single source monolithic suites.

THE COMPONENT MODEL

A new type of distributed application will be needed to better facilitate these "conversations" between disparate systems. Many leading software vendors have cooperated to create a new paradigm called the Component Model.

First, let us define the term Component.

A component is a reusable software building block: a pre-built piece of encapsulated application code that can be combined with other components and with handwritten code to rapidly produce a custom application. Component-based development allows for large-scale sharing and reuse of components across projects. [Thomas 98]

Components come in a variety of shapes and sizes. A component can be a very small, simple GUI widget such as a button; or it can be implemented as a complex application service such as a payroll management function. The architecture that will guide development and interaction between these components is called the component model.

A component model defines the basic architecture of a component, specifying the structure of its interfaces and the mechanisms by which it interacts with its container and with other components. The component model provides the guidelines to create and implement components that can work together to form a larger application. Application builders can combine components from different developers or different vendors to construct an application.[ [Thomas 98]

Although each purchased component is a standardized product with its own advantages, the process of component assembly allows the opportunity for significant customization. Component software also puts an end to the problem of massive upgrade cycles. Traditionally, fully integrated solutions required periodic upgrading, usually involving a painful process of migrating old databases, ensuring upwards compatibility, retraining staff, buying more powerful hardware and so on. In a component-based solution, evolution replaces revolution. The individual upgrading of components can be done as needed which allows for a much smoother operation. Obviously, this requires a different way of managing services, but the potential gains are immense. [Szyperski 97]

BENEFITS OF THIS APPROACH

There are several key areas in which component technologies will impact the design, implementation, maintenance, and upgrades for developed applications. Each benefit outlined below may have a direct and positive impact on the return-on-investment scenario for a Box plant’s system implementation. [Hurwitz 98]

According to Hurwitz componentization will:

• Enable highly distributed implementation designs.
Componentization enables a more complete distribution of functionality while maintaining tight integration.


• Allow customers to mix integrated applications with best-of-breed solutions.
The published interfaces available in a component infrastructure allow third-party applications to effectively become an adjunct component to a larger packaged application.


• Allow differential upgrade strategies.
Instead of upgrading an entire monolithic package, users can upgrade individual components at a significantly lower cost.


• Manage complexity.
Object technology and component-based development techniques support the modeling, design, construction, and testing of well-defined software components that will allow easier creation of mission critical applications.


• Reduce development time.
Software development and maintenance costs are reduced by delivering components that can be shared and reused across multiple projects.


• Adapt to changing requirements.
Using component modeling techniques, a seamless traceablity between business process models, application software models, and physical database models are created over the lifetime of the application.

Although server components and multi-tier concepts have been around for nearly a decade, relatively few organizations have put them to use. Until recently, the scalability pressures that required a multi-tier architecture were not felt. The thrust of Web-based computing is driving a growing interest in the multi-tier approach. Web-based business applications require a thin-client application architecture to support massive scalability and to support browser-based clients and rapid applet downloads. [Gilpin 98]

A thin-client application is easier to manage than traditional client/server applications. Very little code is actually deployed on the client system. Most of the application logic is deployed, managed and maintained on the servers. Fixes, upgrades, new versions and extensions can all be administered through a centralized management environment. Experts in the software industry feel that this is the future of client/server design. "By the year 2000, the application server will be the dominant computing model," says Inprise CEO Del Yocam, "its impact will be even greater than the relational database."

As with any technology, component-based development is not a silver bullet. But it does bring something new to the development process that directly addresses problems inherent in integration and it opens the doors for better systems. Without its arrival, development would surely have stalled as poorly designed systems failed to scale. Ultimately, systems could not be maintained because the complexity of the business logic had grown beyond the scope of the basic services provided in the older client/server schemes. [Rivas 97]

This approach is having a major impact on application design, development and deployment. The component model’s use of object technology and component-based development techniques to incrementally build and deliver mission-critical applications formalizes a process that was overly complex and unwieldy. As it becomes more widespread and well-defined, and as repeatable application development strategies are adopted, the successful completion rate of client/server applications will begin moving upwards. [Rivas 97] To be able to adopt these emerging standards as procedure and, in the process, satisfy stringent user requirements has the potential to save our industry millions of dollars in costly IS development overruns.

WHERE DO WE GO FROM HERE?

Like any "bleeding edge" technology, we need to approach the Component Model cautiously. At this point there are several "flavors" of the model. In order to achieve industry wide adoption, a leader must emerge. Because there are subtle differences between each of the competing models, it may be inappropriate to directly implement any one technology. However, we feel it is an important advancement in the computer industry and are using these concepts in designing future systems. Currently, there are two major schools of thought on the actual implementation of the Component Model. One is driven by Microsoft and is called DCOM. The other is called Java and it is lead by a group of companies that include IBM, Oracle, Baan, Sybase, and Netscape. At this point in time there is no absolute preferred choice because each model has its strengths and weaknesses.

From a development standpoint, these new component technologies will probably see wide spread adoption in the next three to five years. While this may mean little to the purchasers of software applications now, it will speak volumes when it comes to upgrades, enhancements and integrationbetween vendors. This will ultimately result in less disruption as well as faster deployment and greater returns for the customer.

References:

[Gilpin 98] Gilpin, Mike. A Market is Born. Miller Freeman Inc., 1998

[Hurwitz 98] Hurwitz Group, Inc. J.D. Edwards’ OneWorld: Componentization for Business Advantage. Hurwitz Group Inc. 1998

[IDC 98] Picardi, Anthony C. Beyond Client/Server: Application Paradigms for the Rest of the Century. IDC 1998

Rivas 97] Rivas, Erick. Enterprise Component Modeling Strategies-ECM clears the applications bottleneck through component-based development and object-oriented techniques. Object Magazine Abril de 1997

[Szyperski 97] Szyperski, Clemens. Component Software – Beyond Object-Oriented Programming. Addison-Wesley, 1997

[Thomas 98] Thomas, Anne. Enterprise JavaBeans Technology-Server Component Model for the Java Platform. Patricia Seybold Group, 1998

[Valesky 99] Valesky, Tom. Enterprise JavaBeans – Developing Component-Based Distributed Applications. Addison-Wesley, 1999