Design Considerations: From Client/Server Applications to e...

SG24-5503-00

International Technical Support Organization

www.redbooks.ibm.com

Design Considerations: From Client/ServerApplications to e-business Applications

Indran Naick, Luca Amato, Jason K. O’Brien, Jim Nicolson, Tsutomu Oya

http://www.redbooks.ibm.com/

Design Considerations: From Client/ServerApplications to e-business Applications

December 1999

SG24-5503-00

International Technical Support Organization

© Copyright International Business Machines Corporation 1999. All rights reserved.Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

First Edition (December 1999)

Comments may be addressed to:IBM Corporation, International Technical Support OrganizationDept. JN9B Building 003 Internal Zip 283411400 Burnet RoadAustin, Texas 78758-3493

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute theinformation in any way it believes appropriate without incurring any obligation to you.

Before using this information and the product it supports, be sure to read the general information inAppendix D, “Special notices” on page 317.

Take Note!

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi

Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvHow this book is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Part 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. About e-business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 e-business and e-commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Business transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 e-business examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.2 Evolving business value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Developing an e-business vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 e-business categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.1 Business-to-consumer e-business . . . . . . . . . . . . . . . . . . . . . . . . 91.4.2 Business-to-business e-business . . . . . . . . . . . . . . . . . . . . . . . . 101.4.3 Intra-company e-business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5 e-business technology traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 2. Solutions architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1 Using an asset-based approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Problems with the current approach . . . . . . . . . . . . . . . . . . . . . . 152.1.2 Using a sound architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.3 Application Framework benefits . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Client/server and e-business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.1 Client/server model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.2 e-business model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 The IBM Application Framework for e-business . . . . . . . . . . . . . . . . . 202.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.2 The application programming model . . . . . . . . . . . . . . . . . . . . . . 23

2.4 Application topology and building block diagrams. . . . . . . . . . . . . . . . 252.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

© Copyright IBM Corp. 1999 iii

Part 2. Design approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 3. e-business transformation. . . . . . . . . . . . . . . . . . . . . . . . . . 313.1 The e-business cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1 Transform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.2 Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.3 Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.4 Leverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2 Build: Application leverage points . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.1 Client/server topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.2 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.3 Application leverage points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.4 At first glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3 The approach provided in this redbook. . . . . . . . . . . . . . . . . . . . . . . . 433.3.1 Gather requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.3.2 Develop a set of architectural alternatives . . . . . . . . . . . . . . . . . 453.3.3 Choose one of the alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3.4 Select components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 Guidance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Chapter 4. Gather requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.1 Overview of the requirements gathering process . . . . . . . . . . . . . . . . 50

4.1.1 Preliminary requirements that indicate an e-business solution . . 504.2 Assessing your readiness for an e-business solution . . . . . . . . . . . . . 534.3 Understanding the business drivers . . . . . . . . . . . . . . . . . . . . . . . . . . 544.4 Proposing a solution workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4.1 Why a workshop? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.5 Pre-workshop preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.5.1 Identify participants from the company and vendor . . . . . . . . . . . 574.5.2 Communicate the goals of the workshop . . . . . . . . . . . . . . . . . . 584.5.3 Gather documentation on your environment . . . . . . . . . . . . . . . . 594.5.4 Understand the current environment. . . . . . . . . . . . . . . . . . . . . . 604.5.5 Develop and distribute workshop agenda . . . . . . . . . . . . . . . . . . 64

4.6 Conducting a workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.6.1 Review initial understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.6.2 Checkpoint on items reviewed . . . . . . . . . . . . . . . . . . . . . . . . . . 654.6.3 Solicit requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.6.4 Checkpoint for requirements gathered . . . . . . . . . . . . . . . . . . . . 664.6.5 Prioritize requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.7 Chapter checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

iv Design Considerations: From Client/Server Applications to e-business Applications

Chapter 5. Developing architectural alternatives . . . . . . . . . . . . . . . . . 715.1 Overview of the developing architectural alternatives phase. . . . . . . . 715.2 Is a simple e-business solution applicable? . . . . . . . . . . . . . . . . . . . . 735.3 Developing a business scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.4 Using e-business building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.4.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.4.2 System management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.4.3 Client building block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.4.4 Network building block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.4.5 Server building block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.4.6 Application logic building block . . . . . . . . . . . . . . . . . . . . . . . . . . 945.4.7 Connectors building block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.4.8 Enterprise data and application building blocks . . . . . . . . . . . . 103

5.5 IBM intellectual capital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.5.1 How to get access to existing IBM solutions . . . . . . . . . . . . . . . 1055.5.2 IBM intellectual capital and our building blocks . . . . . . . . . . . . . 106

5.6 Creating architectural alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.7 Chapter checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Chapter 6. Choose an architectural alternative . . . . . . . . . . . . . . . . . 1116.1 Overview of choosing an architectural alternative phase . . . . . . . . . 1116.2 Building a matrix of requirements to alternatives . . . . . . . . . . . . . . . 1126.3 Grading the architectural alternatives . . . . . . . . . . . . . . . . . . . . . . . . 113

6.3.1 Weighing alternatives against requirements . . . . . . . . . . . . . . . 1146.3.2 Grading session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.4 Selecting the best alternative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.5 Ensuring commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.6 Chapter checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Chapter 7. Selecting technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257.1 The framework and the application topology. . . . . . . . . . . . . . . . . . . 1257.2 Classifying technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

7.2.1 Framework categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267.2.2 Identifying key technology selection influences. . . . . . . . . . . . . 127

7.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1287.3.1 Choosing the client technologies . . . . . . . . . . . . . . . . . . . . . . . 1287.3.2 Markup-based clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297.3.3 Illustrative examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

7.4 Web application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1327.4.1 Internet/Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1327.4.2 Application services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1337.4.3 Illustrative examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

7.5 Network-based infrastructure services . . . . . . . . . . . . . . . . . . . . . . . 136

v

7.5.1 Illustrative examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1367.6 Integration services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.6.1 Database connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1377.6.2 Packaged application API integration . . . . . . . . . . . . . . . . . . . . 1387.6.3 Middleware integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387.6.4 Component model integration . . . . . . . . . . . . . . . . . . . . . . . . . . 1387.6.5 Custom integration service development kit . . . . . . . . . . . . . . . 1387.6.6 Application integration approaches . . . . . . . . . . . . . . . . . . . . . . 1387.6.7 Illustrative examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

7.7 Web application programming model . . . . . . . . . . . . . . . . . . . . . . . . 1407.7.1 Influence of the component model . . . . . . . . . . . . . . . . . . . . . . 1407.7.2 Influence of architectural design patterns . . . . . . . . . . . . . . . . . 1417.7.3 Illustrative examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

7.8 e-business application services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427.8.1 Illustrative examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

7.9 Systems management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437.9.1 System management model . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447.9.2 Cross-enterprise systems management . . . . . . . . . . . . . . . . . . 1457.9.3 Illustrative examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

7.10 The development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477.10.1 e-business application development team roles . . . . . . . . . . . 1477.10.2 Choose the right tool for the role. . . . . . . . . . . . . . . . . . . . . . . 1527.10.3 Illustrative examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Part 3. Exploring design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Chapter 8. Finder application experiences . . . . . . . . . . . . . . . . . . . . . 1578.1 Why the Finder application? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1578.2 The Finder application design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

8.2.1 Application functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1588.2.2 Application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1598.2.3 Technical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

8.3 Business requirements for the new application . . . . . . . . . . . . . . . . . 1618.3.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

8.4 Application migration strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638.4.1 Migration approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638.4.2 Migration leverage points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648.4.3 Migration strategy decisions for Phase 1 . . . . . . . . . . . . . . . . . 1668.4.4 Subsequent migration phases . . . . . . . . . . . . . . . . . . . . . . . . . 167

8.5 Architecture alternatives/selection . . . . . . . . . . . . . . . . . . . . . . . . . . 1678.5.1 Architectural basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678.5.2 Architecture design decisions . . . . . . . . . . . . . . . . . . . . . . . . . . 169

8.6 Technology selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

vi Design Considerations: From Client/Server Applications to e-business Applications

8.6.1 Technology impact of requirements . . . . . . . . . . . . . . . . . . . . . 1738.6.2 Skillsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738.6.3 Tactical approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738.6.4 Strategic approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

8.7 What was accomplished . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758.8 Chapter layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Chapter 9. The e-business client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1779.1 Before we start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

9.1.1 Visit successful e-business Web sites . . . . . . . . . . . . . . . . . . . 1789.1.2 Is a browser-based interface the correct choice? . . . . . . . . . . . 1789.1.3 Review application type and device combinations . . . . . . . . . . 179

9.2 Designing e-business client interface . . . . . . . . . . . . . . . . . . . . . . . . 1809.2.1 Examining the existing Finder application user interface. . . . . . 1819.2.2 Understanding the users and the tasks. . . . . . . . . . . . . . . . . . . 1839.2.3 Examining the competition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849.2.4 Determining content and structure . . . . . . . . . . . . . . . . . . . . . . 1899.2.5 Selecting development tools and technology . . . . . . . . . . . . . . 1919.2.6 Start with a low-fidelity prototype . . . . . . . . . . . . . . . . . . . . . . . 192

9.3 Migration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1949.3.1 Native GUI interface & Web interface are different paradigms . 1949.3.2 HTML presentation limitations . . . . . . . . . . . . . . . . . . . . . . . . . 1959.3.3 Browser differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1969.3.4 Client/server apps may involve significant client processing . . . 1979.3.5 Intermingled business logic and presentation logic . . . . . . . . . . 1989.3.6 A development environment technical issue . . . . . . . . . . . . . . . 1999.3.7 Some other issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

9.4 Thin client development suggestions . . . . . . . . . . . . . . . . . . . . . . . . 200

Chapter 10. The Web and application server . . . . . . . . . . . . . . . . . . . 20310.1 From Web server to Web/application server . . . . . . . . . . . . . . . . . . 20310.2 Application architectural view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20410.3 User Interface Logic design considerations . . . . . . . . . . . . . . . . . . 206

10.3.1 Java-based dynamic HTML generation technologies . . . . . . . 20610.3.2 Using an approach based on design patterns . . . . . . . . . . . . . 20810.3.3 The Model-View-Controller (MVC) pattern . . . . . . . . . . . . . . . 20910.3.4 Applying the MVC pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21010.3.5 The Interaction controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21410.3.6 User Interface Logic issues . . . . . . . . . . . . . . . . . . . . . . . . . . 218

10.4 Domain Abstraction Layer design considerations . . . . . . . . . . . . . . 22110.4.1 Separation of roles and skills . . . . . . . . . . . . . . . . . . . . . . . . . 22210.4.2 Separation of distributed and non-distributed technologies . . . 22210.4.3 Independent evolution of technologies and platforms . . . . . . . 223

vii

10.4.4 Performance and scalability in a distributed environment . . . . 22310.4.5 Some design approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22410.4.6 Command layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22710.4.7 Comparing approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

10.5 Business logic design considerations . . . . . . . . . . . . . . . . . . . . . . . 23210.5.1 Server component models . . . . . . . . . . . . . . . . . . . . . . . . . . . 23310.5.2 Enterprise Java Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23410.5.3 Reexamining the migration process: Subsequent phases . . . . 23610.5.4 Preliminary EJB-based design . . . . . . . . . . . . . . . . . . . . . . . . 239

Chapter 11. Accessing enterprise applications and data . . . . . . . . . 24511.1 Decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24611.2 Accessing the Finder application and data . . . . . . . . . . . . . . . . . . . 247

11.2.1 The tactical approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24711.2.2 The strategic approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

11.3 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24811.3.1 Lack of design documentation . . . . . . . . . . . . . . . . . . . . . . . . 24811.3.2 Multiple versions of source code. . . . . . . . . . . . . . . . . . . . . . . 24911.3.3 Inability to rebuild an existing system . . . . . . . . . . . . . . . . . . . 24911.3.4 Non-object-oriented applications . . . . . . . . . . . . . . . . . . . . . . 24911.3.5 No JDBC driver for database . . . . . . . . . . . . . . . . . . . . . . . . . 24911.3.6 Transactionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25011.3.7 Connection pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25111.3.8 Dynamic vs. static SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25111.3.9 Proprietary SQL extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 25111.3.10 Object serialization and non-Java programs . . . . . . . . . . . . . 25211.3.11 Primitive types and compatibility with legacy applications . . . 25211.3.12 Handling little-endian data . . . . . . . . . . . . . . . . . . . . . . . . . . 253

11.4 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25611.4.1 Strategic approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25711.4.2 Tactical solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

11.5 JDBC and SQLJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27511.5.1 JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27611.5.2 SQLJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28111.5.3 SQLJ and JDBC comparison . . . . . . . . . . . . . . . . . . . . . . . . . 28111.5.4 SQLJ JDBC Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . 286

11.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Appendix A. e-business application performance . . . . . . . . . . . . . . . . 289A.1 When to consider performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289A.2 Other performance factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290A.3 End-to-end performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290A.4 A few general guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

viii Design Considerations: From Client/Server Applications to e-business Applications

A.5 The budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293A.6 Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Appendix B. IBM software and development tools. . . . . . . . . . . . . . . . 295B.1 IBM product portfolio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295B.2 IBM development tools classification . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Appendix C. Applying the e-business design approach . . . . . . . . . . . 299C.1 Gathering requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

C.1.1 Requirements that indicate an e-business solution . . . . . . . . . . . . 300C.1.2 Assessing readiness for an e-business solution. . . . . . . . . . . . . . . 300C.1.3 Understanding business drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . 300C.1.4 Proposing a solution workshop. . . . . . . . . . . . . . . . . . . . . . . . . . . . 300C.1.5 Finder application requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

C.2 Develop architectural alternatives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302C.2.1 Is a simple e-business solution applicable? . . . . . . . . . . . . . . . . . . 302C.2.2 Developing business scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 303C.2.3 Using e-business building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . 306C.2.4 Creating architectural alternatives . . . . . . . . . . . . . . . . . . . . . . . . . 313

C.3 Selecting architectural alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313C.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

Appendix D. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Appendix E. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321E.1 IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321E.2 IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321E.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321E.4 Referenced Web sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

List of Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

IBM Redbooks evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

ix

x Design Considerations: From Client/Server Applications to e-business Applications

Figures

1. e-business and e-commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42. Increasing business value with e-business evolution . . . . . . . . . . . . . . . . . 63. Comparing legacy systems and processes to e-business processes . . . . . 84. Three-tier computing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205. Web Application Server architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216. IBM Application Framework for e-business services . . . . . . . . . . . . . . . . . 237. Structure/topology of e-business applications . . . . . . . . . . . . . . . . . . . . . . 248. e-business application topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259. The building blocks of an e-business solution . . . . . . . . . . . . . . . . . . . . . . 2610. The e-business cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3211. Client/server: Remote data (two-tiered client/server). . . . . . . . . . . . . . . . . 3612. Client/server: Remote presentation (three-tiered client/server) . . . . . . . . . 3713. Client/server: Distributed function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3814. Application leverage points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4015. Application leverage points by topology. . . . . . . . . . . . . . . . . . . . . . . . . . . 4116. Flowchart of e-business design approach activities. . . . . . . . . . . . . . . . . . 4417. Overview of the requirements-gathering phase . . . . . . . . . . . . . . . . . . . . . 5018. Skills needed in a solution workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5819. Checkpoint, gather requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6920. Overview of developing architectural alternatives phase. . . . . . . . . . . . . . 7221. e-business building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7622. Example of IBM intellectual capital design. . . . . . . . . . . . . . . . . . . . . . . . 10623. Simplified version of IBM intellectual capital design . . . . . . . . . . . . . . . . 10724. IBM intellectual capital design mapped to building block diagram. . . . . . 10725. Checkpoint: Develop architectural alternatives . . . . . . . . . . . . . . . . . . . . 11026. Overview of the choose architectural alternative phase . . . . . . . . . . . . . 11227. Example: Architectural alternative 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11628. Example: Architectural alternative 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11729. Example: Architectural alternative 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11730. Checkpoint: Choosing architectural alternatives . . . . . . . . . . . . . . . . . . . 12331. IBM Application Framework for e-business architecture . . . . . . . . . . . . . 12632. Application integration approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13933. System management model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14434. Matching development tools with roles . . . . . . . . . . . . . . . . . . . . . . . . . . 15335. Finder application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15836. Existing Finder application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 16037. Finder application leverage points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16538. Network node view of Finder application . . . . . . . . . . . . . . . . . . . . . . . . . 16839. Internal structuring of the server/application logic building block. . . . . . . 16940. Architectural alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

© Copyright IBM Corp. 1999 xi

41. Finder application (tactical approach) . . . . . . . . . . . . . . . . . . . . . . . . . . . 17042. Finder application (strategic approach) . . . . . . . . . . . . . . . . . . . . . . . . . . 17143. Chapter breakdown.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17644. The e-business client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17745. The client/server Finder application - Create query . . . . . . . . . . . . . . . . . 18146. The client/server Finder application - Browse query result set . . . . . . . . 18247. The client/server Finder application - Display full details . . . . . . . . . . . . . 18248. IBM intranet Blue Pages - Create a query . . . . . . . . . . . . . . . . . . . . . . . . 18549. IBM intranet Blue Pages - Browse query result set . . . . . . . . . . . . . . . . . 18650. IBM intranet Blue Pages - Display full details . . . . . . . . . . . . . . . . . . . . . 18751. Simple search and result set limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18852. Advanced search and result set/details display . . . . . . . . . . . . . . . . . . . . 18953. User object model for the e-business Finder application . . . . . . . . . . . . . 19054. The initial e-business Finder application navigation structure . . . . . . . . . 19155. Low-fidelity prototype - Home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19256. Low-fidelity prototype - People search page . . . . . . . . . . . . . . . . . . . . . . 19357. The Web and application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20358. Architectural roles of the Web/application server. . . . . . . . . . . . . . . . . . . 20559. JavaServer pages compilation process . . . . . . . . . . . . . . . . . . . . . . . . . . 20860. How would we reuse the Login functionality for our application? . . . . . . 21761. The concept of domain firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22562. The standard basic command pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . 22763. Incorporating the Command Manager into the Command Model . . . . . . 22964. Servers and containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23565. Strategic migration (Step 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23766. Strategic migration (Step 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23867. Strategic migration (Step 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23968. Prelimary EJB-based business logic design . . . . . . . . . . . . . . . . . . . . . . 24069. Accessing enterprise data and applications. . . . . . . . . . . . . . . . . . . . . . . 24670. Two solutions chosen for further exploration . . . . . . . . . . . . . . . . . . . . . . 24771. LEDataInputStream class and relationships . . . . . . . . . . . . . . . . . . . . . . 25572. LEDataOutputStream class and relationships . . . . . . . . . . . . . . . . . . . . . 25673. Socket communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25974. SocketQuery class and associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26375. DBQuery class and associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26776. Proprietary connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26977. The CallUpConn project inside Visualage C++ . . . . . . . . . . . . . . . . . . . . 27478. Web-based transaction flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29179. Response time budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29480. IBM software product families mapped . . . . . . . . . . . . . . . . . . . . . . . . . . 29581. IBM tool classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29782. Flowchart of the e-business design approach . . . . . . . . . . . . . . . . . . . . . 29983. e-business building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

xii Design Considerations: From Client/Server Applications to e-business Applications

Tables

1. Summary of standard supported protocols and APIs . . . . . . . . . . . . . . . . 262. Documentation about your environment . . . . . . . . . . . . . . . . . . . . . . . . . . 593. Information about the current network environment . . . . . . . . . . . . . . . . . 614. The company’s integration requirements. . . . . . . . . . . . . . . . . . . . . . . . . . 625. Example of ranked requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676. Business scenario - Electric utility company . . . . . . . . . . . . . . . . . . . . . . . 747. Security decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778. User identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799. System management decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8110. Client decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8311. Client architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8512. Network decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8713. Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8814. Server decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8915. Internet server types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9116. Session and state management techniques . . . . . . . . . . . . . . . . . . . . . . . 9317. Application logic/development decision points. . . . . . . . . . . . . . . . . . . . . . 9418. Application logic decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9619. Tool selection questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9820. Types of development tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9921. Connectors decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10022. Connector types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10223. Enterprise data access decision points . . . . . . . . . . . . . . . . . . . . . . . . . . 10324. Enterprise data and applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10425. Requirements to architectural alternatives. . . . . . . . . . . . . . . . . . . . . . . . 11326. Definition of grading symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11327. Examples of what to look for in architectural alternatives . . . . . . . . . . . . 11428. Customer grading of requirements to architectural alternatives . . . . . . . 11829. Explanation of grades assigned to example alternatives. . . . . . . . . . . . . 11930. Client technology examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13031. Web application server technology examples . . . . . . . . . . . . . . . . . . . . . 13432. Network-based infrastructure technology examples . . . . . . . . . . . . . . . . 13633. Integration technology examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14034. Programming model technology examples . . . . . . . . . . . . . . . . . . . . . . . 14235. e-business application service technology examples . . . . . . . . . . . . . . . 14336. Systems management technology examples . . . . . . . . . . . . . . . . . . . . . 14637. Content authoring roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14838. Application programming roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14939. Application assembly and management roles . . . . . . . . . . . . . . . . . . . . . 15140. Web application development technology examples . . . . . . . . . . . . . . . . 153

© Copyright IBM Corp. 1999 xiii

41. Ranked business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16142. Grading of requirements to architectural alternatives . . . . . . . . . . . . . . . 17243. Technology selection for the tactical migration approach . . . . . . . . . . . . 17344. Technology selection for the strategic migration approach . . . . . . . . . . . 17445. Markup language-based client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20046. Internet/Web Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20147. JSP to servlet flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21448. Comparing design approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23249. Component models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23350. Java primitive types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25251. TCPCLIW.c functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27052. Instances variable in CallUpConn object . . . . . . . . . . . . . . . . . . . . . . . . . 27253. Java interface for the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27254. Ranked business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30255. Application objects (user view) and user rights . . . . . . . . . . . . . . . . . . . . 30456. Security decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30757. User identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30758. System management decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . 30859. Client decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30960. Network decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30961. Server decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31062. Application logic/development decision points. . . . . . . . . . . . . . . . . . . . . 31163. Tool selection questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31164. Connectors decision points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31265. Enterprise data access decision points . . . . . . . . . . . . . . . . . . . . . . . . . . 31366. Business requirements decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

xiv Design Considerations: From Client/Server Applications to e-business Applications

Preface

The objective of this book is to describe process and design considerationswhen migrating an application from the client/server to the e-businessapplication model. The intended audience for this book includes projectmanagers, IT architects, systems designers, and programmers interested ine-business.

Most migration projects may require advanced skills. IBM Global Services (IGS)professionals are trained to provide all types of customers with a consistentapproach to applying the process and building e-business solutions.

This book is the result of a residency conducted at the International TechnicalSupport Organization, Austin Center, over a six week period. During thisperiod, residents took an existing client/server application, mapped out themigration options, and investigated two possible e-business applicationalternatives.

An OS/2-based application was intentionally selected to demonstrate how itcan be effectively ported to a platform-independent application - today! IBMhas stated that it intends for OS/2 customers to be able to achieve platformindependence from the existing client/server environment through the IBMApplication Framework for e-business. To help with this transition, IBMrecommends solutions that exploit all or most of the key technologies of theApplication Framework for e-business:

• Java for program portability

• XML for data portability

• Internet protocols for data transmission and communication control

• Browsers for the user interface

By using Java technology, this publication demonstrates that customers caneffectively migrate their client/server applications to e-business applicationsusing the Application Framework for e-business. In addition, for thosecustomers who rely on external programming services, IBM does offerfee-based transition services centered around Java and a logical multitierarchitecture. For information on these services, access the Web sitehttp://www-4.ibm.com/software/developer/services/java/ncs.html or send ane-mail information request to [email protected].

© Copyright IBM Corp. 1999 xv

How this book is organized

The book is divided into three parts. Part one of this book will help clarify thee-business concept and describe its effect on both the business andtechnology dimensions of an organization. The intent is to be non-technical,much like an executive overview. It describes the e-business roadmap andintroduces the IBM Application Framework for e-business.

Part two of this book will help technical professionals who are faced with thetask of proposing or designing an e-business solution for a customer. Itsintent is to guide professionals in mapping e-business solutions to acustomer’s business and technology requirements. Some level of familiaritywith e-business technologies is assumed.

Designing an e-business solution is not a precise process; so, nostep-by-step checklists are provided, nor does this section attempt to be acomprehensive source of technical and product information. However, it doespresent a broadly-defined approach that, when coupled with businessinformation, helps you design e-business solutions.

Part three describes our experiences with migrating the OS/2 client/serverapplication. This part uses the approach described in part two to develop andselect alternative migration approaches. We then select and explore twoalternative approaches. Our intent is to describe our experiences inimplementing our alternative solutions and develop some guidelines based onthis experience.

This publication does not describe low-level coding techniques. We hope tofacilitate the transformation of your application by describing our experiences.We hope that this will assist you in identifying solutions for some of the designproblems that you encounter.

The team that wrote this redbook

This redbook was produced by a team of specialists from around the worldworking at the International Technical Support Organization, Austin Center.

Indran Naick is a Project Leader and Senior IT Specialist at the InternationalTechnical Support Organization, Austin Center. He has 10 years of industryexperience. He writes extensively and teaches IBM classes worldwide on anumber of client/server topics. Before joining the ITSO in 1999, Indranworked for the IBM Software Group, Southern Africa, as a Software Solutions

xvi Design Considerations: From Client/Server Applications to e-business Applications

Architect. He holds a Bachelors degree in Computer Science from theUniversity of the Witwatersrand in South Africa.

Jason K. O’Brien is a senior IT Specialist in IBM Global Services - UnitedKingdom. He has 10 years of experience in Software Development. He holds aBachelor’s degree in Computer Systems from Cardiff University. His areas ofexpertise include object-oriented design and development, data modeling, andClient/Server enterprise solutions.

Jim Nicolson currently holds the position of Technology Architect at MincomLtd, Australia. Mincom is an IBM Business Partner. He has 12 years ofexperience in the IT industry. This includes seven years in applicationdevelopment for the OS/390 environment and five years in client/servertechnology research and development. His current interests are applicationdevelopment environments, component-based architectures, and theInternet. He holds a Bachelor's degree in Applied Science (Computing) fromthe Queensland Institute of Technology.

Tsutomu Oya is an Advisory IT Specialist at the International TechnicalSupport Organization, Austin Center. He is responsible for working with OS/2and the Application Framework for e-business. Before joining the ITSO, heworked in the Personal Software Product division, Technical Support, in IBMJapan for four years. He worked primarily on Critical Situations for OS/2customers. He has worked on many OS/2 products, from OS/2 V2 to WarpServer V4. He is a certified OS/2 Engineer and a certified IBM LAN ServerEngineer.

Luca Amato is an IT Architect who has more than six years experience inSoftware Development. He has participated as a consultant and project leader inmany projects in the PC field around the world. Luca specializes inobject-oriented application architecture and has a wealth of experience buildingclient/server systems as well as experience with object-oriented modeling anddata modeling. He has worked with the Visualage product family (Smalltalk, C++,and Java) for at least five years. Luca holds a degree in Information Technologyfrom the University of Pisa, Italy and teaches a language theory course at theUniversity of Pavia. Luca now works in the Application Development andMaintenance group for IBM Italy.

We would also like to give special thanks to Abdulamir Mryhij for hisinvaluable contributions to the project.

Abdulamir Mryhij is a senior IT consultant who has more than 15 yearsexperience in Software Development and IT consulting and participated as aconsultant, project manager, and chief architect in many projects around the

xvii

world. Amir specializes in Software Engineering and Application Architectureand has extensive experience building distributed systems. Amir holds aMasters degree in Information Technology from the University of WesternSydney. He is also Microsoft certified for SQL server, Windows Architecture,and Windows NT. Amir is country consulting services manager at GBM-Qatar.

Part two of this book was produced by a team of specialists working at theInternational Technical Support Organization Poughkeepsie Center. Wewould like to thank Don Bagwell, George Galambos, Randy Van Winkle,Adrian Walmsley, and William G. White for their contributions.

Special thanks goes to Mike Schlosser, who provided invaluable guidanceand input on all the subjects throughout the course of this project.

Thanks to the following people for their invaluable contributions to this project:

Don NeelyIBM Austin

Jim SidesIBM Austin

David AllisonIBM Raleigh

Ronald TaylorIBM Raleigh

Mike ConnorIBM Austin

Bill Lawton, Craig Becker, Shane Claussen, Bryce A. Curtis, Greg Flurry,Jimmy M. Hsu, Matthew D. McClain, Stewart E. Nickolas, Wayne Vicknair, LinXuSoftware Group Technology Center, IBM Austin

Fernando LopezIBM, Boca Raton, Java and e-business Marketing

Temi Rose, Milos Radosavljevic, Ron AguirreInternational Technical Support Organization, Austin Center

Carol ShermanGraphic Illustrations

xviii Design Considerations: From Client/Server Applications to e-business Applications

Abdulamir MryhijGBM Qatar

Bill RittalerIBM U.S.A.

Comments welcome

Your comments are important to us!

We want our Redbooks to be as helpful as possible. Send us your commentsabout this or other Redbooks in one of the following ways:

• Fax the evaluation form found in “IBM Redbooks evaluation” on page 351to the fax number shown on the form.

• Use the online evaluation form found at http://www.redbooks.ibm.com/

• Send your comments in an Internet note to [email protected]

xix

xx Design Considerations: From Client/Server Applications to e-business Applications

Part 1. Introduction

The following chapters describe e-business concepts and their effect on thebusiness and technology dimensions of an organization. This is a vast topic,and the information presented here is in no way comprehensive. The intent isto serve as an introduction and cover concepts that are used later in thebook.

Chapter 1, “About e-business” on page 3, describes the factors motivatingchange. It defines e-business as a business-transformation process in whichtechnology is an integral component. It also presents some analysts’ notes onhow best to approach this business-transformation process.

Chapter 2, “Solutions architecture” on page 15, explains the need for anarchitectural model when building an application. The IBM ApplicationFramework for e-business and the associated programming model are alsodescribed on a conceptual level.

© Copyright IBM Corp. 1999 1

2 Design Considerations: From Client/Server Applications to e-business Applications

Chapter 1. About e-business

The Web is changing many aspects of our lives, but no area is undergoing asrapid and significant a change as the way businesses operate. Forbusinesses today, Internet technology is no longer an afterthought in forminga business strategy but has become the cause and driving force.

e-business is defined by many organizations as the transformation of keybusiness processes through the use of Internet technologies. One of the keymessages contained in this definition is that the transformation affects boththe business processes as well as the technologies used to implement them.Moving from client/server applications to an e-business application is onlyone part of transforming an entire traditional business into an e-business.

This chapter will attempt to summarize the impact of e-business on both thetechnology and the business models of many organizations. The rest of thebook is dedicated to describing the design considerations technical personnelare faced with when moving their client/server applications to e-businessapplications.

This part of the book is intended to address three questions:

• What is e-business?

• Why does e-business make business sense?

• How does a business transform itself into an e-business?

1.1 e-business and e-commerce

e-commerce is defined as buying and selling over a digital medium.e-business embraces e-commerce and includes intranet applications. It letsemployees better manage their knowledge and operations. Extranetstransform the way an organization works with its suppliers, distributors, andpartners. e-business is not just about e-commerce transactions, it’s aboutredefining old business models with the aid of technology. e-business is theoverall strategy, and e-commerce is an extremely important subset ofe-business.


Figure 1. e-business and e-commerce

The IDC chart shown in Figure 1 shows how e-commerce is dwarfed by thelarger e-business domain.

1.2 Business transformation

The convergence of Internet technologies, IT systems and businessprocesses creates new business models: e-business models. e-businessposes the most significant challenge to the traditional business model.Computers have increased business speed by automating tasks but have notfundamentally altered the business foundatation. e-business does this. If anyentity in the value chain begins to do business electronically, similarcompanies must follow suit or risk being eliminated. Rethinking andredesigning the business model is not an option but a necessary step tosurviving in the information era.

1.2.1 e-business examplesExamples of companies implementing an e-business model include electronicretailers offering customized shopping and online purchasing or electronicfinancial service organizations that reduce the high cost of transactions whileproviding improved access to customer accounts. Even vendors that supplythe technology required to implement effective e-business solutions will needto transform their own business to adopt the new model. e-business hasmoved from becoming a token initiative to an imperative for all.

Business to Consu

mer

Businessto

Business$50.48M

1998 1999 2000 2001 2002 2003

$1.317T

Source IDC


So, in what way is e-business different than the old order? Somecharacteristics of the e-business model that set it apart from legacy businesssystems are:

• e-business facilitates transactions with a much wider group ofrespondents.

• Communication and other transactions are instantaneous.

• Customers are empowered.

• Fierce Competition.

• Emergence of customer communities.

Some examples of e-businesses:

• An integrated health care delivery organization deploys a Web-basedsystem to retrieve remote medical records for an emergency room facilityand realizes annual cost savings of over $1 million U.S. dollars along witha projected increase of $3 million to $4 million U.S. dollars due to higherlevels of patient retention and member attraction.

• A German manufacturer of industrial cabling implements a Web-basedcustomer ordering system integrated with its procurement, inventorymanagement, and manufacturing systems. Custom orders are turnedaround 75 percent faster and more than $500,000 U.S. dollars per year inadministrative costs are eliminated.

• A large national bank implements a Web bill presentment and paymentsolution for its 16 million customers. Early data indicate customers are fivetimes less likely to leave the bank, that their balances are three timeslarger, and that they generate 2.6 times the profit of an average on-linebanking customer.

These are only a few examples of the value that companies are creating whenthey implement e-business. But, realizing this value is not simply a matter ofestablishing a Web site or a single, discrete, on-line application. It arises froman e-business vision and an e-business roadmap that begins with an initialsolution that is extendable into other high-value areas of the business.

1.2.2 Evolving business valueCompanies have found that success in e-business is typically based onbuilding efficient value-added relationships with their customers. Thosecompanies exhibiting the highest degree of satisfaction and success withe-business consistently focus their strategy on improving their performancefor their customers. Whether simply making it efficient for a customer to placean order for a product or service, Web-linking and customizing access for a

About e-business 5

supplier network, or integrating a real-time collaborative productdesign/development process, the goal is to serve customers better.

Regardless of size or industry, companies follow a similar pattern ofe-business adoption. Figure 2 illustrates the general business value evolutionfor customer relationship management solutions.

Figure 2. Increasing business value with e-business evolution

Beginning with their first external static Web sites, companies learn, fromfeedback and other experiences, that the network offers an opportunity toestablish more personal, efficient, and competitive relationships with theircustomers. It is this realization that inspires the e-business journey. In thepilot phase, companies concentrate on making their data ready for customeraccess and self-service. For example, in the travel industry, airlines began bymaking their departure/arrival information much easier to understand anddirectly accessible to their customers online.

During the e-business adoption phase, companies make available data aboutcustomer and/or partner/supplier transactions or commerce. The travelindustry, for example, offered on-line bookings while retail banking offeredonline banking. During this phase, not only can a customer buy/transact online whenever they wish, but the company gains valuable insight and

PublishAccess data

Transactbusiness

Leverage yourexperience

VALUE

Awareness Presence Pilot Adoption ProcessInvestment

CrossProcess

Integration

Use theinternet

internally

Establisha Web Site

Allowaccessto core

systems(read only)

Allowtransactions

on coresystems

Improve corebusiness

process(es)

Redefinecore

process(es)

Get you informationon the Web

Integrate the Webwith business systems

Transform the wayyou conduct business

1 2 3 4


knowledge about the specific needs and behaviors of its customers. They canalso segment customers from a behavioral perspective as well as from avalue perspective. However, without the initial effort to make the datacustomer-ready, value for both the customer and the enterprise, though real,would be minimal. Many companies have begun offering online transactionsto reduce their costs without considering the value for their customers and,therefore, have not achieved sustained customer commitment to the system.

In the process adjustment phase, armed with this customer knowledge andwith the integration of business intelligence tools, analyses, and insights,companies can improve the customer relationship process by personalizingcustomer interactions online and integrating the customer view for their entireenterprise. Through these personalized interactions, customer retention andloyalty analysis can be applied to serving the customer more effectively at thepoint of need rather than integrating this information after the fact.

Cross process integration, the fourth phase in e-business evolution, focuseson integrating across all the processes in an enterprise as well as acrosscustomer processes. For the enterprise, this means integrating all thecustomer touchpoints across all operational systems from supply to demandfulfillment and through customer satisfaction. For the customer, it meanslinking the systems of all the suppliers involved in their process. Airlines, forexample, have integrated their booking systems with their frequent travelerservices internally and have linked into their travel partner systems to beginoffering passengers a single convenient point of fulfillment; retail banks areintegrating their services into a much broader single service access point fortheir on-line customers.

1.3 Developing an e-business vision

A vision for integrating business processes to better serve customers iscritical to becoming an e-business. In a recent survey, companies thatdeveloped an e-business vision later in the adoption process indicated thattheir initial solutions would probably have been different or at least wouldhave been implemented differently in the presence of an e-business vision.Without a longer-term roadmap, these point solutions, though successful inthemselves, constituted a costly, complex, disjointed collection of initiativesthat frustrated the effort to fully integrate business processes in a rationalway. Even more frustrating was the diminished return on their e-businessinvestment. Finally, after deploying several sub-optimized point solutions, theywere forced to develop a vision that would bring their disparate e-businessinitiatives together under the umbrella of improved customer service. Thosebusinesses that had executed against such a vision were much better

About e-business 7

positioned to serve customers and experienced a much higher level ofsatisfaction with the results of their e-business investment.

This difference is explained primarily by the fact that e-business solutions thatstreamline individual processes and/or systems without regard to their overallcontext merely result in a better individual process. A roadmap that integratesall these individual processes can result in significant new levels ofe-business value and service to customers, partners, and suppliers, thus,dramatically increasing competitive advantage and levels of satisfaction withe-business investments.

Figure 3. Comparing legacy systems and processes to e-business processes

1.4 e-business categories

e-business activities can be classified in a number of ways. In this chapter,they are divided based on the players at each end of the transaction. Threecategories are defined:

• Intra-business

• Business-to-consumer

• Business-to-business

Legacy Systems & Processes e-business Processes

e-business Implementation

CustomerSystem/

Database

InventorySystem/

Database

LogisticsSystem/

Database

CustomerSystem/

Database

InventorySystem/

Database

LogisticsSystem/

Database

CustomerServiceProcess

InventoryManagement

Process

LogisticsManagement

Processe-business

Customer Relationship Management

Results in finite process improvement/streamlining of existing process

Results in new level of service to customers/competitve differentiation


Classification of e-business activities, or business processes, is described inmore detail in the following sections.

1.4.1 Business-to-consumer e-businessThis is, by far, the most common type of e-business. Activities are driven bythe consumer and usually based around the Internet. The consumer isoutside of the organization using the service. This service could take the formof goods or information.

Some of the services provided by a business-to-consumer solution may alsohold true for intra-company solutions. Some of the most common processesthat are contained within this activity are:

• One-way marketing is the electronic presentation of goods and services,such as:

• Site Information

• Press releases and announcements

• Forming part of a marketing strategy based on a brand or corporation -a form a Web-selling, but the commodity is brand or corporateinformation

• Customer Self-service includes queries from customers (consumers orbusinesses), such as:

• Account inquiries

• Customer service

• Help desk

• Online ordering (Transaction/Dynamic) includes online order taking andbill presentation for:

• Electronic Catalogs

• Web stores

• Web selling

• Web auctions

One could argue that consumer-to-consumer demands its own category.Auction sites where consumers sell to other consumers is one example ofthis category. For the purposes of this section, we classify this type ofactivity in the business-to-consumer category.

Note

About e-business 9

• Bill Payment (Transaction/Dynamic) includes online payment andtransaction handling.

1.4.2 Business-to-business e-businessThese solutions focus on using the Internet and/or extranet to improvebusiness-to-business partnerships and transform inter-organizationalrelationships. Organizations can cut the cost of operations and production,improve business processes, and deliver more value to market by leveraginge-business enhanced partnerships.

e-business nurtures new kinds of relationship between organizations. Someof the newest types of relationships are:

• Automation - Automating the exchange of information betweenbusinesses

• Collaboration - Sharing information and knowledge between businessesfor mutual benefit

• Virtual Markets/Communities - Creating a market to exchangeinformation and transactions

The most common process that is contained within this activity is supplychain integration.

• Supply Chain Integration

Web-enabling legacy systems to provide visibility to select partners,suppliers, and customers and integrate the supply chain into othercorporate processes using customized extranets.

An organization may have already had some or all of its supply chainintegrated using earlier technologies, such as Electronic Data Interchange(EDI).

The following are a few processes related to Supply Chain Managementand how they might be improved using the Internet as described in thebook Frontiers of Electronic Commerce by Ravi Kalakota and AndrewWhinston:

• Supplier Management

Reduce the number of suppliers, and get them to become partners inbusiness in a win/win relationship.

• Inventory Management


Shorten the order-ship-bill cycle by electronically linking them, thus,allowing the reduction of inventory levels, improved inventory turns,and eliminating out-of-stock occurrences.

• Distribution Management

Move documents related to shipping, such as bills of landing, purchaseorders, advanced ship notices, and manifest claims, into an electronicmode, thus, allowing improved resource planning.

• Channel Management

Quickly disseminate information about changing operational conditionsto trading partners. Technical, product, and pricing information thatonce required telephone calls to find out can now be posted toelectronic bulletin boards allowing instant access.

• Payment Management

Link the company, supplier, and distributors so that payments can besent and received electronically, thus, eliminating thousands of laborhours per week.

• Financial Management

Enable global companies to manage their money in various foreignexchange accounts.

• Sales force productivity

Improve the communication and flow of information among sales,customer, and production functions, thus, creating greater access tomarket intelligence and competitor information.

1.4.3 Intra-company e-businessMost intra-company solutions will be based on an intranet infrastructurewhere the purpose of an intranet is to share company information andcomputing resources among employees. An intranet can also be used tofacilitate working in groups and for teleconferences.

Content can be acquired from:

• Existing internal databases

• Existing internal publications

• External database and publications

• New content from employees

There are four general categories:

About e-business 11

• Internal communication creates an involved and communicativeenvironment by making information accessible to an organization’semployees/members.

• Collaborative work exploits the Web technology to create team-orientedwork environments that are more productive, higher quality, and enjoyable.

• Knowledge Management means facilitating an environment whereknowledge, such as standards, common processes, and best practices isshared and exploited by any group, department, or division in anorganization. This involves the process of capturing and leveraging acompany’s intellectual capital, which is a valuable commodity in manycompanies.

For example, using business intelligence to interpret vast quantities ofdata-customer demographics, product purchase histories, cross-sales,service calls, Internet experiences, and online transactions turnsinformation into insight to develop conclusive fact-based strategies to gaina competitive edge.

Using the latest e-business technologies, this intelligence can then bedistributed around your company or around the world helping to makecrucial and profitable decisions.

• Business process redesign means transforming inefficient practices andprocesses inside the organization, from supply chain management tointernal procurement or expense reports.

1.5 e-business technology traits

As mentioned previously, it is clear that technology is the driving cause of thisnew business model. It is the convergence of standards-based technologiesthat is facilitating this change. These enabling technologies have the followingcharacteristics:

• Universal access with little or no regard to platform issues on the client orserver.

• Lower deployment and distribution costs than traditional methods.

• They have achieved high adoption rates in short timeframes.

The above characteristics lead to more and more individuals and companiesworldwide being linked electronically. The impact of digitally bindingconsumers and companies in a low-cost way is as significant as any otherinvention of the twentieth century. Old conventions of businesses built oninformation asymmetry are being cast aside. The new killer applications are


interactive and transaction-intensive, and they let people do business in moremeaningful ways.

The rest of this book is dedicated to discussing many of the technologychoices that are available for the implementation of e-business solutions; so,no further time is spent on the subject here.

1.6 Summary

In this chapter, we have conveyed the following messages:

• e-business is more than just updating technology; it is about a new way ofdoing business.

• e-business is more than e-commerce; it is a series of disciplines abouthow one does business.

• e-business is about transforming core processes, applications, andsystems into a new way of doing business.

• An e-business transformation is crucial to a company’s survival.

• e-business isn’t just about technology; it is about interjecting the righttechnologies to remain elastic in an ever-changing world.

• A holistic approach is necessary for sustainable long-term benefits to beachieved from this new model.

About e-business 13

Chapter 2. Solutions architecture

The aim of this chapter is to help the reader position the IBM ApplicationFramework for e-business and understand the value it can provide whenarchitecting a solution.

While this book focuses on application migration and technology choices, it isimperative that you understand the importance of other disciplines, such as thesoftware development process, software engineering maturity, architecture,configuration management, and testing.

In this chapter, we focus on the importance of keeping your solutionarchitecture-centric. Most of this chapter is based on the feature article in theIBM Systems Journal Vol 38, No 1 - Enterprise Solutions Structure, TechnicalReference Architectures by P.T.L. Lloyd and G.M. Galambos, Oct 8 1998. Thisarticle is highly recommended for more complete reading.

2.1 Using an asset-based approach

Today’s approaches to solution development are still primarily based onhandcrafting and bear little relationship to the asset-based engineeringmethods so successfully used in other disciplines. Handcrafting approachesare obsolete, and a more disciplined and constrained method is needed forsolution development.

2.1.1 Problems with the current approachToday, the most common model for solution development is based on anapproach that we call heroic. A highly-skilled energetic team studies andrefines the stated requirements, defines the architecture for a solution to meetthose requirements, carries out a detailed design, and builds the system. Theprimary assets brought to the table are the skills and experience of theindividuals who make up the team. In the 1970s and, to some extent, the1980s, the heroic approach seemed reasonably effective, but it is clear that itis no longer adequate for today’s enterprise-scale systems.

In 1996, surveys of 20 major enterprise solution development projects inNorth America and Europe showed that solution development project riskincreased rapidly with project size. For projects requiring more than 100person-years, the risk of project delay or failure was very high. Moreover, forvarious reasons, the amount of project resources needed to replace existingbusiness systems is rising rapidly. In the 1960s, utility billing systems couldbe developed in 50 person-years using batch technology; in the 1970s, the


first-generation online systems, which provided the genesis for the IBM CICS(Customer Information Control System) transaction monitor, needed about100 person-years; in the 1980s, the figure was up to 150 person-years withmore sophisticated personal computer (PC)-based interfaces. However, bythe mid-1990s, with the advent of object-oriented front ends and distributedlogic, client/server, and other technologies, several projects were up to 500person-years with an elapsed time of four to five years. A considerable part ofthis effort, perhaps one-third, was spent on integrating new functions withexisting (legacy) IT systems and handling data migration to new databasedesigns. These figures are not unique to the utilities industry. The sametrends are apparent in the insurance industry. Specifically, the replacement ofexisting contract management systems in a large insurance company inFrance was recently reported to have consumed 500 person-years over anelapsed time of six years or more.

It goes without saying that any project of 500 person years is exposed toconsiderable risk - not only the risk of technical failure, but also the risk that,upon final delivery, the business requirements will have changed beyondrecognition, and the delivered solution may no longer meet business needs.These are known as instant legacy solutions.

Older or legacy systems frequently seem, to the end user, to bedisconnected, with independently-operating silos. For example, in aninsurance company, one IT system may deal with life insurance business andanother with general business, such as car insurance. More likely, the lifeinsurance business itself will run multiple systems to handle various products,such as unit business, group products, and so on. With today's focus oncustomer service, it is increasingly unacceptable for an enterprise tocommunicate with its customers separately from each system. To put it in amore positive way, a more coherent view of a customer that considers allproducts held by that customer provides excellent marketing opportunitiesand improved customer retention; so, the existence of silos, typicallymanifested both through incompatible hardware and incompatible orsegregated software, is a serious issue.

Many development efforts start from scratch, and architectural componentsare integrated to create a custom architecture without the use of a template orblueprint. Frequently, the project creates extensive custom middleware, whichmight not have been needed if a blueprint-driven approach had been taken.The selection of products from vendors is left to the skill of one or a few keyarchitects. As a consequence, the solution takes longer to develop anddeliver, and the costs and risks are higher. Along the way, opportunities toleverage existing products, services, the prior integration of components, andthe opportunity to acquire knowledge for subsequent reuse have been lost.


When we combine this risk with the likely development costs of $50 million ormore, it is apparent that our industry is facing a crisis. In thesecircumstances, it is not surprising that enterprises are seeking to mitigate riskby taking an asset-based approach.

2.1.2 Using a sound architectureA sound architecture is an essential prerequisite for the successfuldevelopment of an enterprise-scale IT solution.

• It aids communication among stakeholders. The architecture is a basis forensuring mutual understanding.

• It represents the earliest design decisions about a system. Thesedecisions are absolutely critical in terms of development, deployment, andfuture maintenance costs. For example, in development, they play acrucial role in team organization, and this is later reflected in theorganization of the company for which the solution is being developed. Inmaintenance, the flexible qualities built into the architecture will be key tothe ability of the solution to respond to changes in business andtechnology.

• It provides a compact and understandable abstraction of a system and,thus, is a mandatory prerequisite for the reuse of software assets.

At the beginning of a specific solution development project, the architectureteam has the option of creating the architecture in a number of ways. It candevelop the architecture from scratch, it can pick from a library ofarchitectural styles, or it can reuse and build upon an existing framework.

In this book, we take the approach of developing a solution based on the IBMApplication Framework for e-business.

A framework is a reusable design expressed as a set of abstract patterns and theway their interfaces collaborate. It is a reusable design for all or part of a softwaresystem; a user interface framework only provides a design for the user interfaceof a system while an Application Framework provides a design for the entireapplication. Early frameworks revolved around programming languages, such asan object-oriented design framework. Application Frameworks do not have to beimplemented in an object-oriented language, but they do have characteristicssimilar to OO design in that everything has defined interfaces and can be treatedas a component.

The Application Framework provides a context for the software, servers, andservices necessary to create, deploy, and manage complex e-businessapplications. The Programming model, the architecture of technologies (and

Solutions architecture 17

tools), and e-business disciplines, such as CRM, SCM, etc., overlay theApplication Framework.

2.1.3 Application Framework benefitsTo transform traditional business processes into e-business processes, youare going to need, among other things, a foundation for developing newbusiness applications. The IBM Application Framework for e-business is acomprehensive scalable platform that supports all the services you will needto develop and deploy e-business solutions. The benefits of developingapplications using the Framework are illustrated by the following keyprinciples that have guided its development:

• Maximize the ease and speed of development and deployment. Byadopting a server-centric Java-based component model and toolset, youre-business applications can be developed and deployed quickly with skillsranging from non-technical graphic designers to programmers.

• Accommodate any client device. Support of Internet standards and aserver-centric model expand access to your e-business applications to abroad range of client devices.

• Ensure portability across a diverse server environment. Support of theopen unifying Java platform makes it easy to deploy your e-businessapplications on the systems that best meet your scalability andquality-of-service requirements.

• Leverage and extend existing assets. To improve time-to-market andreduce the cost of development, e-business applications must leverageand extend the reach of secure, reliable, and scalable applications that arethe core of many business processes.

• Flexible and extendable. Able to accommodate future technology, such aspervasive computing, Internet2, etc.

2.2 Client/server and e-business

The title of this book is Design considerations: From client/server Applicationsto e-business Applications. In the context in which they are referenced, bothclient/server and e-business would be application models based on anexisting architecture.

2.2.1 Client/server modelThe client/server computing model for distributing applications is a logicalmodel that defines the existence of a client (the requester of a service) and a


server (the provider of the service). A service can entail data, a function, orany resource that can be shared. The server can be local or remote. Theserver is usually remote, thus, there is a need for communications to connectthe client and server(s). Client/server applications usually display thefollowing characteristics:

• Homogeneous clients

• Simultaneous build and deployment

• Configuration-dependent applications

• Limited deployment options

2.2.2 e-business modelThe IBM Application Framework for e-business programming model is usedas a basis for the design of e-business applications. This model has evolvedfrom the traditional client/server computing model. The key properties ofapplications based on this model are as follows:

• Universal connectivity based on HTML/Java-enabled thin clients, that is,manageable clients that can be configured so they do not require localsoftware installation and data backup, such as the IBM WorkSpaceOn-Demand Client solution.

• Rapid development of write-once-run-anywhere applications withjust-in-time deployment.

• Software reuse to minimize new code, promote quality, and maximizeproductivity.

• Universal access to data.

• Workload optimization across servers.

• Application deployment is independent of client and server operatingsoftware and hardware.

• Connections to external services where existing business applications anddata reside leveraging their value for customers, business partners, andemployees.

Moving applications to the e-business model also brings design problems thatmany developers may never have faced before. Among the new factorsdevelopers must now consider are the following:

• Web Browser clients and other new technologies and paradigms

• The distributed multi-tier nature of e-business applications

• Direct support of customers


• Unique security problems on the open Internet

• Developing universal applications that are usable across geographies,each with their own quirks.

• New dynamics of volume (peak to average ratios)

• Unknown client population without preexisting business (trust) relationship

• Dramatic increase in the number of clients (users)

2.3 The IBM Application Framework for e-business

The IBM Application Framework for e-business provides a model fordesigning e-business solutions. The Framework is based on an n-tierdistributed environment where any number of tiers of application logic andbusiness services are separated into components that communicate witheach other across a network. In its most basic form, the Framework can bedepicted as a logical three-tier computing model meaning that there is alogical, but not necessarily physical, separation of processes. This model isdesigned to support thin clients with high-function Web application andenterprise servers.

Figure 4. Three-tier computing model

A prototypical three-tier architecture consists of the following:

• A client tier containing logic related to the presentation of information (thatis, the graphical user interface) and requests to applications through abrowser or Java applet

ThinClients

WebApplication

Servers

Content

EnterpriseJavaBeans

ExternalServices


• Web application servers containing the business logic and processes thatcontrol the reading and writing of data

• Servers that provide the data storage and transactional applications usedby the Web application server processes

The application elements residing in these three logical tiers are connectedthrough a set of industry-standard protocols, services, and softwareconnectors. See http://www.software.ibm.com/ebusiness/sysmodel.html forfurther details.

The framework consists of many concepts. In this chapter, and for the rest ofthe book, we will be working mainly with the framework’s architecture and theprogramming model. The next few sections describe each of these concepts.

2.3.1 ArchitectureThe IBM Application Framework for e-business architecture provides a fullrange of services for developing and deploying e-business applications.Because it is based on industry standards, the Framework has the ability toplug-and-play components provided by almost any vendor.

Figure 5. Web Application Server architecture

The architecture is composed of the following key elements:

• Clients based on a thin client Web browser/Java applet model that enablesuniversal access to Framework applications and on-demand delivery ofapplication components.

DevTools

e-business Application Services

Web Application ProgrammingEnvironment

System Management

Application ServerSoftware

ApplicationIntegration

Network Infrastructure

Web Application Server Architecture


• A network infrastructure that provides services, such as TCP/IP, directory,and security, whose capabilities can be accessed via open standardinterfaces and protocols.

• Application server software that provides a platform for e-businessapplications and includes an HTTP server, database and transactionservices, mail and groupware services, and messaging services.

• Application integration that provides access to existing data andapplications.

• A Web application programming environment that provides the server-sideservlet and Enterprise Java programming environment for creatingdynamic and robust e-business applications.

• e-business application services that provide higher levelapplication-specific functionality to facilitate the creation of e-businesssolutions.

• Systems management functions that accommodate the uniquemanagement requirements of network computing across all elements ofthe system including users, applications, services, infrastructure, andhardware.

• Development tools to create, assemble, deploy, and manage applications.

Figure 6 on page 23 describes the services offered by each of thearchitectural components in more detail.


Figure 6. IBM Application Framework for e-business services

2.3.2 The application programming modelThe application programming model defines application topologies andsolutions using the services defined by the framework. For the most part, ourwork deals mostly with the application programming model.

The next figure illustrates the major elements of the Web application topologysupported by the Framework. It is important to note that the Web applicationserver and external services are logical tiers capable of running on the samephysical machine. In addition, functionality on the Web application server canbe spread across multiple physical machines. Frequently, the front-end andbusiness logic parts of a Web application are run on separate servermachines. The parts of a Web application topology are illustrated in Figure 7on page 24.

Systems Management

e-business Applications Data Stores

Relational

Notes Object

File

TCP/IP

Java VMSecurityServices

DirectoryServices

FileServices

Infrastructure

Web Server with CORBA ORB

ApplicationProgramming

Support

FoundationServices

Connectors

Mail &Community(e-mail, chat...)Collaboration(groupware,workflow)DatabaseTransaction

DataApplicationExternalServices

DevelopmentToolsJavaBeansAppletsServlets


Figure 7. Structure/topology of e-business applications

The parts of a Web application’s topology are as follows:

There are Internet and intranet clients through which users communicatewith Web application servers (using Internet standards, such as TCP/IP,HTTP, and HTML) to access business logic and data. The primary role of theclient is to accept and validate user input and present results received fromthe Web application server to the user.

Infrastructure services provide the Web application server and its businesslogic components with directory and security services. Included in theseservices are firewalls that shield an organization's network from exposurewhen connecting to the Internet and prevent hackers and others from gainingunauthorized access to internal data and computing resources.

Web application servers are the hubs of the Web application topologyprocessing requests from clients by orchestrating access to business logicand data on the server and returning Web pages composed of static anddynamic content back to the client. The Web application server provides awide range of programming, data access, and application integration servicesfor writing the business logic part of a Web application.

BusinessLogic

UILogic C

onne

ctor

s

HT

TP

Ser

ver

Inte

rnet

Fire

wal

l

Inte

rnet

Dis

patc

her

Web/Application Server

Directory & Security Services

HTMLClient

AppClient

UIData

AppClient

BusinessData

BusinessPartners and

External Services

ExistingApps and Data


External services consist of existing mission-critical applications and datawithin the enterprise as well as external partner services, such as paymentservices, financial services, and external information services.

Most often, these existing applications and services control the company'score business processes.

2.4 Application topology and building block diagrams

Throughout part one of this redbook, we use different diagrams to describethe building blocks and application topology. The application topologydiagram is a subset of the e-business building block diagram. The buildingblock diagram describes all the components of e-business solutions ingeneral. For specific application issues, we have decided to use theapplication topology diagram shown in Figure 8. This is a flat architecturaldiagram that roughly maps to the more graphic Figure 7 on page 24 butexcludes e-business building blocks, such as systems management andsecurity. We have excluded the infrastructure services, not because they areunimportant, but because they are outside the scope of this project. Thefocus of this book is on the application, and, for this project, these areconsidered additional topics, which we did not have sufficient time to cover.

Admittedly, this is exactly what happens in many real-world projects. It shouldbe noted that these services are imperative and affect the entire design.

Figure 8. e-business application topology


Server-sidePresentationLogic

Business Logic

DomainAbstraction

Layer

BusinessDomain Objects

CoreServices

e-businessclient

EnterpriseData and

ApplicationsConnectors


Figure 9 represents the building blocks that are used to construct ane-business solution.

Figure 9. The building blocks of an e-business solution

Admittedly, this is a very simple diagram. Real e-business solutions involvefar more detail than is implied here. However, the value of using such adiagram remains. By using the building blocks in each chapter, we keep yourfocus on the basic issues of e-business solution design while we take youthrough the process described in this redbook.

2.5 Summary

Table 1 summarizes the standard protocols and APIs supported by eachcomponent of the Application Framework for e-business. While IBM willprovide a complete and competitive set of products that implement theFramework, other implementations can also work within it, thus, customerscan choose from providers that support these open standards. Likewise,solution providers can build their solutions using a variety ofdifferently-sourced software products.

Table 1. Summary of standard supported protocols and APIs

Service Protocol Standard API

Application Server Software

Messaging (Mail) SMTP, POP3, IMAP4 Notes APIs for Java

The Web*

Security

System Management

Client Network ServerAppl.Logic Connection

Enterprise Dataand Application

#

# The enterprise data and applications may or may notreside on the same tier as the application logic.

I/T

* Applies to extranet andintranet as well as

internet


Community IRC, NNTP, FTP, CAP Notes APIs for Java

Collaboration N/A Notes APIs for Java

Database ODBC, DRDA JDBC, SQLJ, EJB

Transactions CORBA OTS/IIOP EJB, JTS, JTA

Commerce EDI, OBI, SET, XML (IOTP,RosettaNet)

N/A

Web Application Programming Environment

Web Server HTTP,HTML,XML Servlets,Server-side-includes

Web Browser HTTP,HTML,XML Applets, DOM Level 1

Component model CORBA IIOP JavaBeans

Business componentmodel

CORBA IIOP EJB, RMI

Authoring and Versioning WebDAV, UML, XMI N/A

Scripting ECMAScript JSP (Java Server Pages)

Message Queuing N/A JMS

Message Routing,Transformation

EDI, XML (OAG) AMI-J, MQSeriesCMI-J

Workflow CORBA WfM/IIOP, WfMC N/A

Host Access 3270, 5250 IBM Host Access Beans

Security and Management

Directory LDAP JNDI

Security CDSA, SSL, IPSec,x.509v3

JSSL, JCE

Network TCP/IP JDK java.net

File AFS/DFS JDK java.io

Print IPP, LPR/LPD JDK java.2d, JNPAPI

Pervasive Computing(Wireless)

WAP/WML, VxML N/A



In this chapter, the message we hoped to convey can be summed up by thefollowing quotation from Barry Boehm that states the role of architecture well:

"If a project has not achieved a system architecture, including its rationale,the project should not proceed to full-scale system development. Specifyingthe architecture as a deliverable enables its use throughout the developmentand maintenance process."

Part two of the book describes the process of developing a solution using theIBM Application Framework for e-business. These new applications mayintegrate with existing IT applications, or they may be completely new. Theamount of existing business leveraged depends on your e-business strategy.However, the approach, or process, is similar.

Distribution(Install/Config)

DMTF-CIM AMS

Operations (Fix/Change) DMTF-CIM AMS

Performance (Monitor) SNMP ARM

Events (Alarms) SNMP TEC



Part 2. Design approach

The intent of this part of the book is to guide professionals in mappinge-business solutions to business and technology requirements. Some level offamiliarity with e-business technologies is assumed.

Designing an e-business solution is not an exact science; so, no step-by-stepchecklists are provided, nor does this section attempt to be a comprehensivesource of technical and product information. However, it does present abroadly-defined approach that, when coupled with business information,helps you design e-business solutions.

Chapter 3, “e-business transformation” on page 31, discusses where to beginan e-business transformation. It identifies possible leverage points in ann-tiered client/server architecture and introduces an approach for designingand building e-business applications, which is the main subject for the rest ofthis book.

Chapters 4, 5, and 6 describe the process that could be used to architect asolution. Architecting a solution is not a precise process; so, no step-by-stepchecklists are provided. However, this section presents a broadly-definedapproach that helps you design e-business solutions. From a migrationperspective, client/server represents the current architecture, and e-businessrepresents the target architecture. This approach takes into account theexisting application and technical environment as part of thesolution-development process

Chapter 7, “Selecting technologies” on page 125, provides direction inselecting the technologies to be used in developing an e-business solution.This chapter classifies the technologies according to the IBM ApplicationFramework for e-business. For each category, there is a descriptive sectionfollowed by a table identifying some representative products and thetechnologies they support. This section does not provide a comprehensive listof products.


Chapter 3. e-business transformation

This chapter is an introduction to the approach we use for migration. Thechapter serves as a summary of the processes described in the chapters thatfollow.

This section describes (without going into significant depth) how to transformyour business, leverage the knowledge in your business, and manage yourexisting systems more effectively. These topics are wide-ranging and warranttheir own books.

In this chapter, we will:

• Discuss the e-business cycle

• Discuss migration points, that is, where in your existing applicationarchitecture you would look to begin your transformation?

• Introduce an approach for designing and building e-business applications,which will be the main subject for the rest of this part of the book.

3.1 The e-business cycle

We have determined that e-business is more than a technology discussion.The move requires a clear vision of what needs to be done and an equallyclear picture of how to make that vision a reality. The e-business cycle is theIBM model for how customers can transform their businesses intoe-businesses. The e-business cycle is shown in Figure 10 on page 32.


Figure 10. The e-business cycle

The e-business cycle is made up of four stages: Transform, build, run, andleverage. There is no hierarchy in this cycle; you can start anywhere at anytime. Each of these represents a concrete set of actions. An organization maybe active in more than one phase at any one time. This is also an iterativeprocess.

In this redbook, we focus only on the Build stage of the e-business life cycle.However, all the stages are described briefly to put the Build stage in context.

3.1.1 TransformThis stage is about transforming core business processes. It is about takingan existing business model and extending it into the networked world tocreate an e-business model. At the end of the day, it is a reinventing andtechnically-enabling processes. Businesses are defined in new ways byapplying Internet technologies to create maximum value for them. e-businesschanges the rules for Customer Relationship Management, Supply ChainManagement, and Electronic Commerce.

As described in Section 1.3, “Developing an e-business vision” on page 7,when transforming business processes, it is imperative that each process beviewed in its overall context. Streamlining individual processes without regardfor their overall context merely results in a better individual process. It may

Leverageknowledge and

information

Runa scalable,

available, safeenvironment

Buildnewapplications

Transformcore businessprocesses


not necessarily have the effect you desired - that of wanting to improve youre-business value and service to customers.

3.1.2 BuildThe subject matter within this book focuses on the building applicationsquadrant of Figure 10 on page 32. Transforming core business processesrequires a new generation of applications. Building also encompassesmigrating existing applications to the Web using an open standards-basedapproach.

If the applications are neither open nor standard, they will not be e-businesssolutions. The attributes of e-business applications are as follows:

• Standards-based

• Server-centric

• Leverage core systems

• Scalable

• Quick to deploy and easy to use

• Manageable

The standards-based approach is an integral part of enabling youre-business. By definition, it allows your customers, business partners, andsuppliers to connect to your business using standards-based software.

Applications built today must satisfy two competing requirements: Anincrease in functionality and a decrease in time available to market. The onlysolution is to build applications that are built out of components that are quickto develop and deploy.

3.1.3 RunThe Run stage refers to the organization being able to deploy and run ascalable, available, safe environment. Usually, the infrastructure is builtaround your business and applications. Users want systems that are easy touse yet always responsive. The infrastructure services need to have thefollowing attributes:

• Availability

• Scalability

• Manageability

• Security

e-business transformation 33

3.1.4 LeverageThe leverage stage is about using existing knowledge and information. Aresponsive organization will make intelligent use of all types of data andorganizational knowledge.

The focal point here is knowledge and leveraging what we know, which is thedefinition of knowledge management. It differs from information management,which deals strictly with explicit knowledge. Knowledge Managementembraces both explicit and tacit knowledge.

Explicit knowledge is dealt with in traditional IT systems. It is knowledge thatcan be written down and coded. On the other hand, tacit knowledge is whatwe know that is not written down. Tacit knowledge is based on intuition,experience, and insight.

In order to attract and retain your best customers, you need a precise portraitof what their wants, needs, and buying patterns are. Business intelligencepaints that picture by analyzing and interpreting vast quantities ofdata-customer demographics, product purchase histories, cross-sales,service calls, Internet experiences, and online transactions turninginformation into insight and developing conclusive fact-based strategies togain a competitive edge.

Using the latest e-business technologies, this intelligence can then bedistributed around your company or around the world helping to make crucialand profitable decisions, such as which markets to enter, which customers topursue, and which products to promote.

3.2 Build: Application leverage points

In order to build effective e-business applications, it is necessary to establisha clear point of origin. What is the application type that you currently have?How do you transform your processes and their related applications? Withinyour application, where is the best place to start? This section primarily dealswith the existing application model that you have and establishes what we callleverage points. Leverage points are points that mark the ability to leverageexisting functionality and data depending on the topology (starting points).

3.2.1 Client/server topologiesClient/server is a multi-tiered computing model that allows an application tobe distributed across different tiers. To efficiently implement a multi-tieredarchitecture for any application, the following questions must be answered:


• On which tier (or tiers) should the data be placed?

• On which tier (or tiers) should the application logic be placed?

• On which tier (or tiers) should the user interface be placed?

Many different system architectures exist in the enterprise today. The physicaland/or logical separation of each of the mentioned components creates anumber of distinct client/server sub-architectures.

Most non-trivial commerce applications will consist of application parts, eachof which could have a different sub-architecture implemented.

It would be impossible to describe all of them, identify the problems witheach, and show how e-business is attempting to solve them. Instead, thissection will focus on three flavors of client/server architecture:

• Remote data

• Remote presentation

• Distributed function

3.2.1.1 Remote dataHere, all application and presentation logic resides on the client with the dataresiding on a remote server. This is a classic two-tiered client/serverarchitecture, and there tends to be a close coupling (or integration) betweenthe presentation and application logic.

We will identify the differences between them and the key issues with each.Figure 11 on page 36 illustrates the remote data architecture.

In the architectural diagrams shown in this section, all the componentsdrawn are logical components. These components, although drawn inseparate boxes, may or may not reside on the same hardware.

Note


Figure 11. Client/server: Remote data (two-tiered client/server)

This architecture has the following advantages and disadvantages.

Advantages

• Improved client performance - Assuming that some of the applicationlogic deals with input from the user. It makes sense to place theapplication logic as close to the source of the input as possible. Thealternative is to send user input to the server for processing and back todisplay the results over the network.

• Reduced network traffic - If the entire application logic resides on theclient network traffic between the presentation and application, processinglogic can be significantly reduced.

• No synchronization problems - There is no need to synchronizebetween application logic units that reside on different tiers.

Disadvantages

• Complex systems management - The need to maintain multiple copiesof the same application logic on every client represents a serious systemsmanagement problem.

Client

PresentationPresentation

Logic

ApplicationLogic

Network ConnectorsServerEnterpriseData and

Applications

Security

System Management

The server box is shown for consistency. It is only there to show that thereis a separation between the client and the server. In fact, in most cases, theenterprise data and/or applications will reside on this server.

Note


• Lack of server power - The power of a server machine is not fullyleveraged. At the same time, the clients could be overloaded, which mightrequire a hardware upgrade and investment.

• Price/performance - At one time, with the high cost of servers,particularly mainframe servers, it appeared to make economic sense tooff-load application logic processing from the expensive server to theinexpensive client. However, recent studies have shown that the cycles forrunning an application on a server are almost equal to maintainingcommunication with the application running on the client. In addition,mainframe and midrange server costs have dropped significantly.

• High client development costs - In large enterprises, client softwareneeds to be developed, tested, and maintained for each of the clientoperating platforms.

• Network traffic - Chatter of the data access protocol is a pitfall for mostclient/server applications with non-trivial transaction rates.

3.2.1.2 Remote presentationFigure 12 illustrates the remote presentation architecture.

Figure 12. Client/server: Remote presentation (three-tiered client/server)

Here, there is a clear separation between presentation logic and applicationlogic with all of the application logic residing on the server.

This architecture has the following advantages and disadvantages.

Advantages

Security

System Management

Client

Network

Server

ConnectorsEnterpriseData andApplication

ApplicationLogic

PresentationPresentation

Logic


• Placing common application logic on a central system eliminates coderedundancy, simplifies systems management, and allows for betterleveraging on the investment in the server hardware.

• Placing application logic on the database server reduces network trafficbetween an application and a database.

• There is no need for synchronization between application logic units (thatis necessary if the units are distributed between client and server).

Disadvantages

• Placing the entire application logic on the server system can result in anoverload of the server resources, thus, necessitating a server hardwareupgrade. This is especially true when many different applications have toshare the same server system.

• Interactions between the presentation and application logic cansignificantly increase network traffic and the response time for real-timeapplications.

• The power of the client PC’s or workstations can be underutilized, thus,reducing the return on investment.

3.2.1.3 Distributed functionFigure 13 illustrates a distributed function architecture.

Figure 13. Client/server: Distributed function

This architecture is probably the most common three-tiered client/serverarchitecture in enterprises today. It is a trade-off combining the advantages of

Security

System Management

Client

Network

Server

Connection

EnterpriseData andApplication

Appl.Logic

Presentation

ApplicationLogic

PresentationLogic


the first two architectures (Remote Data and Remote Presentation) whilereducing the other approaches’ disadvantages.

Distribution of the application logic is a critical design issue. This architecturefocuses on the distribution of application logic between the client and theserver. Common fragments of application logic can be placed on servers,while presentation-related application logic can be placed on the client, closeto the user. Thus, redundancy can be eliminated and network trafficoptimized.

This type of architecture can provide the most benefits, but it is also the mostcomplicated. Proper distribution of application logic is critical to its success.

3.2.2 CharacteristicsTo summarize, client/server applications that exist in the enterprise todaytend to have some or all of the following characteristics or problems.

3.2.2.1 InfrastructureTraditional client/server models created fat clients with unnecessarily complexoperating systems and incompatible interfaces. Servers came in a variety ofconfigurations, each networked in various ways to a subset of clients.

A variety of networked topologies served different subsets of the enterpriseand had limited interoperability. The overall effect decreased enterprisefunctionality and reliability as the complexity of the network infrastructureincreased.

3.2.2.2 ApplicationsThe client/server model created a large body of legacy applications on avariety of platforms that cannot be immediately replaced. Client and serverapplications were usually written in different languages that ran onincompatible platforms and operating systems. Multiple and oftenincompatible client applications reside in various points on the network.Multiple versions of network applications that are either incompatible or donot interoperate properly, such as e-mail, are deployed.

3.2.2.3 DataUsually, enterprises are left with multiple incompatible databases holdingdata. The data sources usually lack a standard method of accessingenterprise data uniformly.


3.2.2.4 Systems ManagementUsers who customize the local fat client with personal applications mayreduce enterprise reliability and/or security.

The networks have ever-escalating support costs and apply never-endingeffort to keep clients and servers uniformly updated across the network.

Another characteristic is that they usually result in large and dispersedsupport organizations dedicated to providing client on-site support.

Also, forced migrations to the latest version of software and/or operatingsystem may yield a near-zero return on investment.

3.2.3 Application leverage pointsWith the adoption of Web-based technology and standards, the IBMApplication Framework for e-business provides a way of simplifyingenterprise computing without scrapping existing investments. In most cases,you will need to decide how much, if any, of the existing application is to beretained and integrated into the new solution.

In most solutions, there are three points of integration as shown in Figure 14.

Figure 14. Application leverage points

Application Programming Interface (API) - the application may be welldesigned and structured with a clear set of APIs. If this is the case, it might bepossible to utilize these as part of the integration effort; otherwise, the task ofintegrating existing application logic becomes more complex.

Network - At the center of most commerce solutions is the network; so, it isonly natural that leverage points exist on either side of the network. However,application logic tends to reside on both sides of the network, and this maymake migration to an e-business solution complex. If no application logic in

Client

Network

Server

ConnectorsEnterpriseData and

ApplicationClient sideApp Logic

Serverside

App Logic

API Network API Data


the client is required but some or all of the application logic is on the server,the network is the starting point. However, if some of the required applicationlogic resides on the client, the network may not be the best leverage point.The decision will be based on how much application logic resides on theclient and how complex it is.

Data Source - The data is another possible integration point. A number ofinterfaces are available for integrating with relational and non-relational datasources. The main issue here is maintaining the consistency and integrity ofthe data while allowing access from multiple and potentially differentapplications.

The diagram shown in Figure 15 is a slight adaptation of the Gartner Grouptopology diagram for client/server applications. In this diagram, the clientserver communication is shown vertically as opposed to the horizontal layoutin Figure 14 on page 40. The diagram describes, from left to right, four typicalclient/server application types. The dotted line shows the split between theclient and the server. The ability to leverage existing functionality and datadepends on the topology. The main leverage points for each topology areshown. The lowest line of arrows describes the possible migration selection.

Figure 15. Application leverage points by topology

Identifying the leverage point to use or at least which ones to consider is not atrivial task. It is determined by a number of variables, for example:

• The complexity of the application to be integrated.

• How much additional function is required in the new application?

Application

Data

Presentation

Data

Presentation

Application

Data

Presentation

Application

Data

Presentation

Client

Server

Application

Share database Retarget rendering

Remote Data

Reuse business logic

Distributed Function Remote Presentation


• Where does the application logic currently reside? Is it on the client or theserver?

• Is the application logic tightly integrated with the presentation logic?

• Does the application logic reside in different enterprise applications?

• Do you have designs and an in-depth knowledge of the application logic?

• Would it be quicker to rewrite than to integrate?

• Can the application logic be ported to a central server?

These are only a few questions that you will need to answer when decidinghow much, if any, of the existing application logic is to be reused and/orintegrated in the final solution.

The data itself is another point at which to integrate an e-business solution. Ifyou only want to use the data, there exist numerous standard-basedmechanisms (or interfaces) that can be used, JDBC being the most notablefor relational databases. If you decide that none of the existing applicationlogic is needed and only the data is required, a new set of issues is involved,for example:

• Is more than one data source going to be integrated?

• How do you keep consistency and integrity between separate datasources?

• Are the current applications that maintain the data going to exist in thefinal solution. If so, how will they be affected?

• Does the data management software need to be upgraded to a versionthat is compatible with the IBM Application Framework for e-businessinterfaces?

• If an upgrade is required, will this destabilize the current application thatmaintains the data?

3.2.4 At first glanceAs mentioned above, each application needs to be treated independently.However, for specific e-business environments, the following might apply.

3.2.4.1 Business-to-businessIn a business-to-business solution, the main objective is to use the Web tointegrate two or more applications that exist in separate organizations, that is,one organization’s servers talk to another organization’s servers across theInternet. The focus is on exchanging data between two systems, and there isa clearly-defined set of allowable interactions between systems.


Based on this environment, there might be more possibilities for leveragepoints at the network, server, and connectors layers.

3.2.4.2 Business-to-consumerHere, you will have very little, if any, control on the client. All requests forinformation tend to be marshalled via a Web-server that sits on the networkbehind a firewall. This Web-server interfaces with, or connects to, enterprisedata and applications.

In this environment, there might be more possibilities for leverage points atthe network layer.

3.2.4.3 Intra-companyHere, you have more control over the client, which allows you to place moreapplication logic on the client. If designed correctly, the functionality providedby the new application can be extended outside of the enterprise. However,remember that you have little or no control over clients outside of theenterprise and, as such, a limited scope placing application logic on theclient.

Once again, in this environment, there might be more possibilities forleverage points at the network layer.

3.3 The approach provided in this redbook

With your vision formed, you are ready to embark on the road to e-businesstransformation. Like any complex design project, some form of process isneeded to go from the first idea to the completed design. That process mightbe completely subjective, as it might be when you prepare a meal, or it maybe very complex and require formal project management. However, someprocesses always take place.

We are very deliberate in our use of the term approach rather thanmethodology. A methodology implies a formalized process with fairlywell-defined entry and exit criteria at each step of the process. Methodologiestend to be very thorough, complex, and well-suited for what they are intendedto do, but well beyond the scope of this document.

Instead, we borrow some of the key concepts from these existingmethodologies to create a simpler less formalized approach.

With this approach, we discuss the following:

• Gathering the customer’s requirements


• Developing a set of architectural alternatives

• Choosing one of the architectural alternatives

• Selecting components that address the chosen alternative

This approach is represented using the flowchart shown in Figure 16.

Figure 16. Flowchart of e-business design approach activities

The arrows that loop back illustrate a very important point: This is an iterativeprocess. If a significant new requirement surfaces after you have developedthe architectural alternatives, you may need to go back and redevelop thealternatives. Similarly, if, during the choosing of the architecture, you find thecustomer indicates that none of the alternatives really meets theirrequirements, you will need to go back and gather the requirements again.

Each of these phases is described in more detail in this chapter and again, infar greater detail, in individual chapters dedicated to each step of theapproach.

3.3.1 Gather requirementsThe requirements you gather act as the foundation upon which the rest ofyour solution will be constructed. It is these requirements to which you map

Implement

Gather Requirements

Develop Architectural Alternatives

Choose Architectural Alternatives

Select Technologies


your architectural alternatives, and it is these requirements that are the basisfor the selection criteria used when choosing an architecture.

Requirements come in many forms: Business, technical, personal, andpolitical, to name a few. In this phase of the approach, we focus on businessrequirements and technical requirements. Your relationships will largelydetermine how well you understand the personal and political agendas thatmight be present.

Along with gathering requirements for the new e-business solution, you willalso need to understand your company’s existing environment. New solutionsare rarely developed completely separate from what is already in place.

Gathering requirements sounds like an easy thing to do, but it is not. Itrequires that you have knowledge of both your company and the e-businesssolutions, and that you are skilled in asking questions and listening to theanswers provided. It also requires that you use your time efficiently.

This topic is covered in detail in Chapter 4, “Gather requirements” on page49.

3.3.2 Develop a set of architectural alternativesSome business problems can be solved using well-understood designpatterns. More often, several architectural alternatives will be technicallypossible. Presenting multiple alternatives is valuable because it provides aforum in which to discuss the technologies relative to the requirements. It isusually at this point that additional requirements or issues arise.

Being able to understand all the available architectural options in detail is adaunting task. It would be impossible to deliver that level of detail in a singledocument such as this; so, instead, we will focus on the approach andprovide examples of some of the issues.

The following might be helpful:

• An outline of a workshop approach to gathering requirements• A set of sample requirements that indicate an e-business solution• An exit checklist to be used to ensure you have agreement and that the

requirements gathered are complete and accurate

Note


This topic is covered in detail in Chapter 5, “Developing architecturalalternatives” on page 71.

3.3.3 Choose one of the alternativesOnce a set of architectural alternatives has been developed, the next phaseis to decide which alternative is best suited to your environment. This is doneby reviewing each of the requirements gathered in Chapter 4, “Gatherrequirements” on page 49 and assessing, or grading, how well eachalternative provides for the fulfillment of that requirement.

This phase, like others in this approach, requires some level of understandingof the architectures and technologies. What is important is coming to aconsensus within your company about which alternative will be the one uponwhich the implementation project is based. By doing so, you focus the energyof the project on implementation rather than competing between options.

This topic is covered in detail in Chapter 6, “Choose an architecturalalternative” on page 111.

The following is provided:

• A discussion and example of a business scenario used to validate therequirements and the proposed alternatives

• A discussion of how to settle upon a few basic high-level architectures• Information on how to select technologies for each building block

including a set of questions to help you understand the issues andreference information to help you select from the available technologies

Note


• An overview of a process by which the requirements gathered aremapped against the architectural alternatives

• A description of a proven approach to grading the alternatives on howwell they suit each requirement, as well as an example of this gradingprocess

Note


3.3.4 Select componentsPrior to this point, we have been discussing architectures and technologies,not specific components or products. Once the architecture has been settledupon, the task of choosing the components begins.

There will be occasions where certain components will have been listed as acustomer mandate, as discussed in Section 4.6.3.3, “Existing conditions” onpage 66. If, after an architecture has been settled upon, this mandate fromthe customer still exists, it must be factored into the solution.

This topic is covered in detail in Chapter 7, “Selecting technologies” on page125.

3.4 Guidance

The approach presented in this redbook could consume a considerableamount of time and resources. That is why it is important to balance the valueof the solution against the time and effort you will put into it. Many times, thecomplexity of a solution is related to the business problem, not to its scale.

Migrating an existing system in line with an e-business strategy is fraught withmany issues and challenges. We are unable to cover all of these becausemost off them relate to migration of the specifics of an application’sarchitecture. Instead, we will focus on a core set of issues and challenges.

3.5 Summary

After reading this chapter, you should be aware that:

• This redbook is about building e-business applications and not abouttransforming business processes, leveraging knowledge, or runninge-business-enabled infrastructures.

• We have defined the three types of client/server architecture that exist inmost enterprise computing environments today.


• A listing of the common components available by building block• Information you can use in your selection of the components• Some assistance on where to go to gain further knowledge of specific

components

Note


• We have identified possible leverage points that leverage existingenterprise data and/or applications.

• We have introduced an approach to developing e-business applications,which will be the subject of the rest of this part of the book.


Chapter 4. Gather requirements

The importance of developing a good understanding of your businessrequirements cannot be overstated. Gathering requirements is not a processthat occurs only once; rather, it is an iterative process that may recur severaltimes as the e-business solution evolves through the phases described in thisdocument. Remember, the business requirements drive the e-businesssolution. Do not allow technology to drive the solution.

There are multiple techniques that can be used to gather your businessrequirements. If a company has an opportunity identified, some of therequirements may already be known. The challenge is to bring theserequirements forward, analyze them, and prioritize them so that the processof identifying architectural alternatives can begin.

In addition to business requirements, there is another set of requirements tobe gathered. These could include obstacles, existing conditions, andfunctional or technical requirements that you or your company have alreadydecided on and that must be adhered to in the solution (for example, Oracleis the relational database that must be used, or Windows 95 is the clientplatform). You may need to deal with these because your company may havealready decided on them as a company standard.

Presented here is a list of questions that can be reviewed to ensure that allareas of the opportunity have been explored in terms of businessrequirements as well as a description of a workshop approach that can beemployed to discover requirements and prioritize them. We also discussunderstanding the current environment because this can create some of thebiggest obstacles in developing an e-business solution.


4.1 Overview of the requirements gathering process

Figure 17 illustrates the high-level approach presented in this chapter.

Figure 17. Overview of the requirements-gathering phase

One final point about this flowchart: It is assumed that some form ofe-business opportunity is apparent, and you have qualified your own interestin exploring it further. Before you embark on proposing a solution workshop,you need to ensure that all interested parties are committed to developing ane-business solution.

4.1.1 Preliminary requirements that indicate an e-business solutionSome of the requirements you got early in the planning stage indicate that ane-business solution may be what you are seeking. When you spot theserequirements, continue to ask questions to get a better understanding of whatyour company is looking for. A brief explanation of the e-business solutions

Exit Checkpoint for this Phase

GatherRequirements

DevelopAlternatives

ChooseAlternative

SelectTechnologies

Assessing Readiness for ane-business Solution

Understanding the Business Drivers

Proposing a Solution Workshop

Pre-Workshop Preparation

Conducting a Workshop


behind the requirement is provided to help you qualify the problem andproceed to the gathering of requirements that leads to a solution design.

4.1.1.1 e-mail and collaboration requirementsThe following is a list of requirements that may indicate the need for ane-mail- and collaboration-based solution:

• Share information between groups or departments - If you find thatdifferent groups within the company tend to duplicate their efforts becausethey are not aware of what the other is doing, a collaborative solution willhelp overcome this without imposing the drudgery of meetings and statusreports.

• Reduce the cost of planning for projects - Projects often requireplanning in the early phases that involves travel, which is costly. Aneffective collaboration solution can reduce this cost while still maintainingthe flow of information between participants.

• Overcome the obstacles of teams in different parts of the world -Organizing status meetings, even by phone, is difficult when teammembers are located across the globe. Collaborative solutions can reducemuch of this effort by allowing participation on each members’ schedule.

• Reduce the processing of paper forms and processes - Processesbased on paper involve delay and cost. Collaborative solutions canreplace paper-based forms with electronic forms and route and file theseforms based on any number of conditions.

• Have better control over who accesses information - Simple Web sitescan offer information to users, but determining exactly who is accessingthe site is difficult. User ID and password schemes can be employed, butthey do not offer complete protection against fraud. Lotus Notes, as anexample of a collaborative solution, uses digital certificates that offer amore robust form of security. The server can be more certain of the trueidentify of the person accessing the site with such technologies in place.

4.1.1.2 e-commerce requirementsThe following is a list of requirements that may indicate the need for ane-commerce based solution:

• Expand the base of companies - Because a business presence on theWeb is available to people from all over the world, more people will havean opportunity to see and consider doing business with your company.

• Have hours of operation that are 24 x 7 - Because an e-commercesolution can be an automated process, you now have the opportunity tostay open for business 24 hours a day. If your base is now the entireworld, staying open 24 hours a day becomes critical.

Gather requirements 51

• Reduce the cost of a sales transaction - To the extent that you canautomate the sales process through an e-commerce solution, you canstart to reduce the cost of that sales transaction. This is particularly true ofmundane sales transactions where the customer knows what they want.

• Provide better pre-sale and post-sale support to customers -e-commerce solutions can provide pre-sale information that is important tocustomers and can help customers enjoy and use their purchases afterthe sale.

• Make the existing Web site more dynamic in nature - Many early Webimplementations consisted of static HTML pages. This becomes verydifficult to manage if the number of pages gets too large. An effectivee-business should be largely dynamic taking advantage of technology thatautomates this process rather than relying on manual processes.

• Tie the existing Web site into existing enterprise systems - Anyexisting Web site that relies on the manual duplication of data fromanother system is one that can be improved. Most of the business data inthe world today exists in enterprise servers that can be connected to theWeb servers to make this process far more effective.

• Employ new methods of payment over the Internet - Newer paymenttechnologies, such as Secure Electronic Transactions (SET) can providegreater security and integrity to the Web site wishing to use them. Arequirement to use these new technologies is suggested for those whohave concerns about their own business security or who believe morebusiness can be generated by employing the technologies.

4.1.1.3 Web application server requirementsThe following is a list of requirements that may indicate the need for a Webapplication server:

• Tie a Web server into existing enterprise systems - A Web site thatstands alone is one that will not do much good. If you want a Web site toperform a real function, as opposed to only offering static documents,some form of connection to other existing systems will be required. Sincemost of the business data in the world exists on enterprise servers,connections to those systems are imperative.

A 24 x 7 solution means more than simply keeping a Web server up 24x 7. If connections are made to enterprise applications or data, thosesystems must also support a 24 x 7 operations window. All of thisimplies that a careful study of what 24 x 7 means in your setting shouldbe conducted before a 24 x 7 solution can be assured.

Note


• Process requests on the Web server; do not just serve static pages -Often, a user will request that something be done based on the clicks oftheir mouse. This processing can be done entirely on the same server asthe Web server, or it can be done on a different processor. How youarchitect this is, in large measure, what this redbook is about.

• Provide customized reporting to users from a Web site - Offeringcontent based on a user’s identify or request provides valuable content fora user. This requires processing logic at the Web site. Web ApplicationServer solutions can be used to provide this function.

• Update the content of a Web site automatically not manually -Countless hours are spent every day by people manually updating Websites. This update process can and should be accomplished automaticallywhenever possible.

• Provide good performance and the ability to scale the server - TheWeb Application Server should provide good performance and the abilityto manage performance with techniques, such as support for caching,clustering, and load balancing.

• Providing session management capability - Web applicationdevelopers should not spend valuable time worrying about how tomaintain sessions within the application. The Web Application Servershould provide these services.

4.2 Assessing your readiness for an e-business solution

You should determine your readiness for an e-business solution. This is not aformal checklist activity. It is more an informal assessment based on thecustomers own experiences and requirements.

Knowledge of your company’s readiness will help shape the education youprovide in the Solution Workshop (see Section 4.4, “Proposing a solutionworkshop” on page 56), as well as the final solution design. If you or yourcustomer are running SNA over a coax connection, you might be a candidatefor a slower phased approach, while, if you have more advanced Internetskills, you might be ready to accept a more aggressive solution.

Therefore, this assessment would include the following:

• The level of technical skills including:

• Web server

• Object technologies

• Java

• Application development tools


• Database skills related to distributed data

• Transactional skills

• Maintaining state in a Web application

• Security

• Standards

• The attitude of all decision makers towards new technology adoption.

• The degree of risk you are willing to support.

The attitude and degree of risk will have an effect on the architecture of thesolution. Some companies are reluctant to move quickly on new technologyadoption, even if the technology is proven in the marketplace. Such areluctance can result in the adoption of an unnecessarily complex design.Alternatively, ambitious designs might entail some degree of risk of failure orof greater cost than originally planned. A company unwilling to assume muchrisk will tend to shy away from such a design. You must factor into yourdesign your assessment of your company’s willingness to adopt newtechnology and the company’s willingness to accept risk.

This assessment should be in the form of a simple rating of high, medium, orlow.

Armed with this information, you can determine the level of detail needed indiscussing the technologies. Reassessment of these readiness factorsshould be done as the design process continues.

4.3 Understanding the business drivers

Technology is seldom desired for its own sake. Rather, some need or problemor opportunity presents itself, and those responsible for the business begin toseek out a solution.

It is very important to understand the forces that drive the business whendesigning a solution. They form the basis from which other requirementsderive and provide the justification for the eventual solution.

The objective of this chapter is to gather sufficient requirements to developseveral architectural alternatives for consideration. Business requirementsthemselves do not usually equate directly to technological solutions, butquestions about the business drivers offer a valuable tool to uncoverrequirements that can be used in the solution design.


Remember that we started with the assumption that an e-businessopportunity had been identified and qualified. Though a design is not yetavailable, some early notion of a solution is typically in the mind of thearchitects/decision makers, such as “Make our customer order informationavailable from the Internet.” To further refine the company requirements, askthe following questions: How will this e-business solution

• Increase the number of customers?

• Lower operating costs?

• Enhance the image of the company?

• Get our products to market faster?

• Make our business more competitive?

• Reduce our development cycle?

• Increase revenue or decrease costs?

• Enhance customer relationships?

• Improve inventory and procurement management?

• Improve channel relationships?

• Improve customer service?

• Make our employees more effective in teaming and collaboration?

• Allow us to reach new markets?

• Reduce distribution costs?

This is a conversation best had with an executive, rather than an IT-focussedperson, who will be more able to state their business goals.

From this, you will derive a list of things the executive has on his or her mind.For example, the cost per sale to customers may be above the industryaverage, or it could be that customers have complained about post-salessupport being too difficult. These are the business drivers. These kinds ofissues are what companies want to address with an e-business solution.

When you have developed this list of business drivers, review them with theexecutive sponsors and gain agreement that they are complete and accurate.Later, in the Solution Workshop, you will review this list with both thebusiness and technical representatives present to make sure the businessdrivers are understood.


4.4 Proposing a solution workshop

A solution workshop is simply a gathering of key business and technicalpeople from both the company and the e-business solution vendors, such asIBM, who will have a say in the final solution design. The goals of a solutionworkshop are:

• To understand the existing environment and requirements

• To review the business application

• To provide education where appropriate

• To clarify the objectives, both short and long term

• To identify the issues

• To discuss technical alternatives (pros and cons)

• To recommend the next logical steps

A workshop may run anywhere from half a day to several days depending onthe complexity of the environment. Do not expect this to be a two-hour affair.

4.4.1 Why a workshop?Getting everyone in a room together for a workshop affords many advantagesover attempting to work through this requirements-gathering process withpeople individually:

• Time is saved by having everyone present.

• With everyone present, the technical people can hear and understand thebusiness people’s perspective, and the business people can hear andunderstand the technical people’s concerns.

• Often, competing views from within the technical community can be airedand resolved, which leads to consensus on the final solution.

• Experience has shown this to be the most effective way in which toaccomplish the task of arriving at a solution design.

The challenge of a solutions workshop is that it represents an investment inpeoples time, particularly when a number of key people need to be broughttogether at the same time.

Therefore, your first order of business is to propose and secure permissionfrom the executive sponsor of the e-business plan to hold a solutionsworkshop.


4.5 Pre-workshop preparation

Before a Solution Workshop can be performed, some up-front work needs tobe done:

• Identify participants from the company.

• Identify participants from an e-business vendor, such as IBM.

• Communicate the goals of the workshop to everyone.

• Gather documentation from your company on your current environment.

• Develop the Solution Workshop’s agenda and distribute it to allparticipants.

In the following sections, each of these items is discussed in greater detail.

4.5.1 Identify participants from the company and vendorThe most important aspect of a successful workshop is who participates inthe solutions workshop. A cross-functional team from both the company andthe solution provider is the key. As illustrated in Figure 18, your companybrings to the table information and knowledge concerning its business,applications, and current environment, while solution providers, such as IBM,


bring their knowledge of e-business technologies and experience indeveloping successful e-business solutions.

Figure 18. Skills needed in a solution workshop

The total number of people in a workshop should be kept to a manageablenumber. Our experience has been that the company should supply betweenfour and six people, and the solution provider should supply around fourpeople. No more than a dozen people should be at the workshop.

The person from your company who represents the business requirementsshould be capable of making decisions regarding the final requirements.

Do not underestimate the value of a good meeting facilitator. That skill islisted at the top of the list for good reason: a skilled facilitator will keep ameeting on track and help the group reach consensus.

4.5.2 Communicate the goals of the workshopAs mentioned in Section 4.4, “Proposing a solution workshop” on page 56,the goals of a Solution Workshop are:

• To understand the existing environment and requirements

• To review the business application

• To provide education where appropriate

Sol

utio

nW

orks

hop

Your companyBusiness Requirements

End-User Requirements

Application DevelopmentEnvironment

Existing Databases andRequirements

Existing Network andRequirements

Existng Platform Environmentand Requirements

Systems ManagementEnvironment andRequirements

Solution Vendor (eg IBM)

Meeting Facilitation

e-business Design Approach

Proven e-business designassets

e-business Technologies

Development Tools andTechniques

System Integration Tools andTechniques


• To clarify both short-term and long-term objectives

• To identify the issues

• To discuss technical alternatives (pros and cons)

• To recommend the next logical steps

Capture these in a document, identify the executive sponsor of the workshop,and distribute these goals to the identified participants.

4.5.3 Gather documentation on your environmentInformation about your current environment that will be pertinent to thee-business system or architecture design plans should be identified anddocumented before the workshop is conducted. This allows both thecompany and the solution provider adequate time to understand and preparefor the workshop. The information should include known businessrequirements, information on the current environment, and any knownrestrictions.

Table 2 describes the types of documentation that can be helpful:

Table 2. Documentation about your environment

Documentation Comments

Target application overview (this may behigh-level or sketchy at this point in theprocess).

Provides a way of communicating withIBM experts and a reference to look forexisting design assets.

Existing network logical and physicaldesign.

Assists in understanding what e-businesstechnologies are best used on the existingnetwork, which may have capacityrestrictions or other factors that need to betaken into account.

Existing databases and database design.Helps with the development ofconnections between Web-based serversand back-end systems, which typicallyinvolves database access.

Existing Web environment (servers,firewalls, and so on).

Indicates the Web maturity of yourcompany and gauges the scope of thesolution.

Existing server environment includingconfiguration diagrams, softwareversions, and future software upgrades.

Helps with discussions about leveragingexisting infrastructure versus new.


4.5.4 Understand the current environmentUnderstanding as much as possible about your current environment is thekey to having a successful workshop. The vendor team should review thematerials received from the company. The workshop provides the forumwhere any questions or clarifications can be made.

Experience has shown that, with good documentation from your company,understanding the current environment can be rather straightforward.However, areas where problems can arise are usually associated with theexisting network infrastructure and integrating with existing enterpriseapplications and data.

Security requirements.New security facilities are key to manye-business solutions, which cannot bedeveloped without existing securitypolicies.

Operational parameters (24 x 7 and soforth).

The expectation of 24 x 7 service over theWeb puts the focus on the operatingschedule of the existing systems.

End-to-end performance requirements.

If an end-to-end service-level agreementis in place, it is best to understand thatbefore a design is proposed. End-to-endperformance across the Internet cannotbe guaranteed. Certain e-businesstechnologies can also consume too muchof this end-to-end time and, therefore, beundesirable.

Existing standards (network, naming,protocols, and so forth).

Provides an indication of what some of thefixed parameters may be in the solutiondesign.

Organization charts with skills.Places your company in the workshopwithin the context of their organizationalstructure.

Documentation Comments


4.5.4.1 Understanding the network infrastructureAn assessment of the current network infrastructure should be conducted.Table 3 shows what information is necessary:

Table 3. Information about the current network environment

Depending on the level and quality of the documentation from your company,this activity can be included in the Solution Workshop, or it may require aseparate workshop. This may uncover the need for additional services, suchas developing a baseline, troubleshooting, network design, and so forth.

4.5.4.2 Understanding integration requirementsProviding connections to the existing servers to get access to existingbusiness functions and data is relatively easy. There are a number of IBM andnon-IBM middleware products that provide connectivity. The difficult issue is

Information Comment

Network baseline information thatincludes bandwidth, current networktraffic, response times, and so forth.

Low-speed remote links can impedeintranet solutions. Intranet applicationscan add substantial load to the corporatenetwork.

IP design and facilities (DNS, VPN), if anIP network exists.

Existing IP network experience willexpedite the implementation of ane-business solution.

Network topology diagrams includingrouter and switch placement, sources, andsync points

Network isolation and address spaceseparation are important elements ofe-business solutions and, thus, impacttheir complexity.

Application/Data/Object placementprinciples and actuals

Mature organizations tend to haveplacement principles, which may bemandatory for the proposed solution. Also,many e-business opportunities demandaccess to existing applications and data.

Management and security policies

These may enable or restrict the use ofcertain technologies or components. Forexample, a firewall may restrict traffic toport 80 only, which may prohibit the use ofapplets that use different ports forcommunication.

The role of the Internet in the solution.The Internet brings with it a whole list ofsecurity and performance issues. Thoseissues need to be incorporated into thesolution design if the Internet is utilized.


understanding the existing business functions and data structures so that thecorrect decisions can be made regarding which type of connectivitytechnology should be employed. If your company is planning to integrate anew application with existing applications, the following issues should beexplored:

Table 4. The company’s integration requirements

Issue Comment

Need for real-time access.

This will influence the selection of middleware usedfor access to the existing application or server. Realtime generally implies a synchronous logicalconnection to the server but could include messagequeueing technologies. Non-real time would permitthe use of asynchronous connections used withmessage queueing technologies.

Ability to modify existingapplications.

The existing applications may be off-limits tomodification. This may be the case because thesource code is no longer available or is a vendorproduct and, therefore, never open for modification,or the application is stabilized.

Design of the existingapplication.

The existing application’s design will indicate howthe connection can be made. For example, an older3270 CICS application might not be open formodifications; so, some form of interface to the 3270layer of the application would need to be used toaccess the application. However, if the applicationsource code is open for modification, aprogram-to-program connection might be possiblewith EXCI or ECI.Also, look at how the presentation layer isabstracted from the logic and data layers. Olderapplications typically employed programmingtechniques that blended the three layers together.To the extent that the layers are logically separate inthe application’s design, the more flexibility youprobably have in making the connection.


Because integration requirements can be complex, this activity might requiresomeone on the IBM team to work with your company for several days. Thisactivity would investigate these areas to come up with an assessment as tothe best way to interface with the existing systems.

Existing infrastructure.

Evaluate the type of middleware that presentlyexists (if any), and determine your attitude towardsmaintaining that middleware or moving to a newtechnology.For example, in the late 1980s, screen scraping wasa popular technique by which data from an existingapplication was accessed and passed to a graphicalinterface. Your company might have a very largeinvestment in that type of infrastructure and mightwish to maintain all or some parts of it.

Programming skills.

Connecting a new application to an existing one willalmost always involve some level of codecustomization in the new application or in theexisting one, or both. Your company’s programmingskills are a valuable resource, and your solutiondesign may need to use that existing resourcerather than stipulating a new programming skill.That being said, many technologies, such as Java,require object programming skills. If your companyhas no such skills in-house, you might wish to phasein a design over time or make the case to utilizecontract skills to complete the project.

Data usage

The amount and type of data that needs to be sentand received from the client is an important factor. Ifyour network infrastructure is robust, the amountbecomes less of a factor unless some of the clientsare remote and across dial lines.Similarly, the form of the data might need to bemodified because it travels from data source topresentation point (the client, in other words). If thedata is on an S/390 host, an EBCDIC-to-ASCIIconversion will need to take place, which can bechallenging for binary data types, such as packeddecimal, floating point, and signed fields. Also, theissue of national language support (NLS) comesinto play if the clients are located in differentcountries.

Issue Comment


4.5.4.3 Understand target client environmentThe client environment will have an impact on the technology options you canpropose. At issue is the degree of control your company has over the clients.If the target environment includes clients not under your company’s control,you may not be able to specify things, such as:

• The configuration of the client

• Issuing code updates to the client

• Testing of new releases of the client code

• The use of applets (Java, ActiveX) or other code

For example, the use of Javascript might be restricted because of the waydifferent browsers behave with JavaScript. Similarly, regarding thedistribution of code updates or the use of Java applets, firewalls placedbetween your server and the clients may prevent the transport of anythingmore than HTTP.

4.5.5 Develop and distribute workshop agendaYou should distribute the planned agenda for the workshop to all theparticipants prior to it being conducted. At a minimum, you should plan ondoing the following in a workshop:

• Review the goals of the workshop (this sets the stage).

• Review the business drivers behind the desire for an e-business solution(this brings everyone to the same level of agreement and positions thebusiness needs as the true solution drivers).

• Review the current environment (this allows everyone to agree on thebase assumptions as the solution design goes forward).

• Provide some level of education on the technology (not products) of ane-business solution. Not everyone will be familiar with this technology; so,now is a good time to provide this.

• Gather more detailed requirements of an e-business solution; see Section4.6.3, “Solicit requirements” on page 65.

4.6 Conducting a workshop

The workshop itself is used to go through the entire approach described inthis part, all the way from gathering requirements to the selection of anarchitecture. However, the aspect of the Solution Workshop covered in thissection only focuses on the first block in our original flowchart (see Figure 16on page 44).


4.6.1 Review initial understandingAs a starting point to the workshop, you should review the following itemswith all in attendance:

• The goals of the workshop

• The business needs and drivers (ideally, you would have the personresponsible for these present this review)

• The current environment, as everybody understands it, from the companydocumentation collected.

A simple review of these items may very well generate some usefuldiscussion, which may help to further refine requirements.

4.6.2 Checkpoint on items reviewedBefore you proceed, make sure that everyone in the room is in agreement onthe three items reviewed in Section 4.6.1, “Review initial understanding” onpage 65. With everyone in agreement, the foundation is now set.

4.6.3 Solicit requirementsBecause the workshop covers a broad range of topics concerning yourcompany’s application, the opportunity exists for a single workshop to extractother requirements associated with the implementation of an e-businesssolution.

As you collect these other requirements, do not challenge them as they areoffered; simply collect them. You will prioritize them later, as described inSection 4.6.5, “Prioritize requirements” on page 67.

You may find disagreement between people from your company over whatconstitutes a requirement. These discussions are valuable sources ofinformation about your environment. Listen carefully, but do not allow thediscussion on any given point to drag on too long. This is where having agood meeting facilitator becomes so important.

These other requirements can be broken down into the following categories:

• Functional requirements

• Obstacles

• Existing conditions


4.6.3.1 Functional requirementsThese are the functions needed in the application. For example, if theapplication has the requirement to allow the user to navigate through multipleviews of data related to claims information, the complexity of this requirementmay dictate that the architecture accommodate a complex set of widgets(small icons on the screen) that control presentation. This may lead to a Javaapplet solution requirement versus an HTML presentation.

4.6.3.2 ObstaclesSome individuals may already have technology favorites. This is an obstaclein that they attempt to influence the decision so that it favors their technologychoices.

Again, capture these requirements and ask questions to understand the whybehind the requirement. Do not challenge it at this time. The requirements willbe prioritized in Section 4.6.5, “Prioritize requirements” on page 67, and therequirement may fall away.

It is imperative that decisions be made based on requirements rather thanindividual whims and fancies.

4.6.3.3 Existing conditionsNormally, a company will have a set of existing conditions that have alreadybeen decided upon. The workshop gives an excellent environment in which totest these existing conditions.

Some examples of existing conditions are:

• That a specific set of application development tools be used

• That Windows NT be the application server platform

• That TCP/IP must be the networking protocol

• That certain industry standards must be followed

• That Sybase is the distributed database of choice

• That the client workstation will be Windows 95 or 98

• That the solution must be an object-oriented design

4.6.4 Checkpoint for requirements gatheredThis process is clearly iterative. Before you move on to the prioritization ofthe requirements, you should ask whether any more requirements exist.


4.6.5 Prioritize requirementsThe process of gathering requirements will yield many items. The only way tomeaningfully deal with them is to prioritize them. Experience has shown thatprioritization should be kept simple and accomplished quickly. Therecommended approach is as follows:

1. Get agreement from everyone to prioritize the list of requirements.

2. Quickly go through each item in the list of requirements restating therequirement and making sure everyone agrees that it is still a requirement.This will often cause a requirement to be discarded or consolidated.

3. Go back to the top of the list and ask everyone for their agreement that therequirement has a priority of either high, medium, or low.

4. If you end up with many high-priority items, you may wish to sequence theones marked high into an order of importance.

5. Gain agreement from everyone that this prioritized list is accurate and thatit represents the needs of the functional areas of the business.

The requirements marked high (and perhaps some of the mediums) becomethe things that drive the architecture and the final e-business solution.

Table 5 shows an example of what a set of ranked requirements might looklike:

Table 5. Example of ranked requirements

Requirement Rank

Business Requirements

Reduce the cost of project planning High

Reuse information and knowledge between groups High

Utilize the market leader’s technology Low

Adhere to industry standards Medium

Other Requirements

Use TCP/IP on network High

Desktop system used for multiple applications High

If you do not get agreement, then you must go back and keep workingon the list until you do gain agreement.

Note


4.7 Chapter checkpoint

At this point, you are well into your Solutions Workshop, and you should havea prioritized list of requirements. Before you move on to developingarchitectural alternatives, ask yourself the following questions:

• Do you believe that all of the business needs and requirements areproperly understood and agreed to by all of the participants in theworkshop?

• Do you believe that you and the solution provider fully understand thecompany’s current environment?

• Do you believe the requirements you have gathered so far in the workshopare complete, accurate, understood, properly prioritized, and agreed to byall participants in the workshop?

• Is everyone in the workshop in agreement that you may move to the nextstep?

If you can answer yes to each question, move on to Chapter 5, “Developingarchitectural alternatives” on page 71; otherwise, you may need to go backand repeat some of the steps in the Gather Requirements phase.

Use Windows NT as a server platform Low

Use an existing Ethernet network Medium

Use C++ as a programming language Low

Response time end-to-end must be less than two seconds Medium

User access must be secured High

Access to data must be by user identification High

Access must be dialup as well as LAN Medium

Requirement Rank


Figure 19. Checkpoint, gather requirements

Develop Proposal

Gather Requirements



Select Technologies

You are here


Chapter 5. Developing architectural alternatives

In this phase, you will start to develop the architecture for your project bycoming up with a few alternative architectures from which the final one will beselected.

This chapter builds on the business and technical requirements that youcollected in Chapter 4, “Gather requirements” on page 49. It takes youthrough the process of developing an architectural model based on thee-business building block diagram shown in Figure 9 on page 26, and itprovides information that gives guidance on the various choices. It alsorecommends detailed questions that you should ask and decisions that youshould make in order to develop an architecture.

A company may already have some designs in mind and may even haveexpressed a preference for certain products. You need to take that intoaccount. However, practice has shown that it can be helpful to reviewarchitectural options at this stage and to do so, as far as possible, withoutmaking assumptions about specific product choices.

The benefit of this approach should be an increased confidence on the part ofyour company in the solution that is finally selected, whether it be theoriginally-envisaged architecture or whether the exercise has highlighteduseful alternatives.

This chapter provides guidance on choosing among the architectural options.

If the e-business system that you are designing is particularly large orcomplex, you should consider involving a practitioner trained in one of thearchitecture design methods, possibly as part of a services contract.

5.1 Overview of the developing architectural alternatives phase

The main input to this phase of the design process is the list you drew upfollowing the steps in Chapter 4, “Gather requirements” on page 49.

This book cannot offer you a simple formula that you can use to develop anarchitecture based on the requirements. No simple if requirement X, thenarchitecture Y statements can be made; therefore, a large part of thisprocess requires you to rely on your own experience, or the experience ofpeople involved in the project, to develop the architecture.

Note


Figure 20 shows the steps in the architecture development phase of thee-business solution design.

Figure 20. Overview of developing architectural alternatives phase

After an initial check to determine whether the requirements are so clear-cutthat you can base your solution on an existing design, create a businessscenario (used as a requirements-based guide and tool to validate thealternatives), define some fundamental aspects of the architecture, and thendevelop architectural options building block by building block.

It is helpful to construct the architectural alternatives in a workshop, just asyou did during the requirements-gathering phase. Conducting this phase in aworkshop setting allows you and your company to arrive at agreed-upondiagrams of possible solution architectures in a very effective way.

List of Requirements


GatherRequirements

Is a Simple e-businessSolution Applicable?

Developing a Business Scenario

Using e-business Building Blocks

Using IBM's Intellectual Capital

DevelopAlternatives

ChooseAlternative

SelectTechnologies

Creating Architectural Alternatives


5.2 Is a simple e-business solution applicable?

Before investing the time to define your architectural alternatives, you shouldbriefly review the requirements to see whether a clear agreed-upon solutionexists. For example, a requirement for a collaborative workflow system mightdictate a Notes/Domino solution, or the requirements may be a close fit withthe functions provided by Net.Commerce. If all parties to the project agree,you could bypass the step of building architectural alternatives.

Note that even a simple e-business solution composed of a singlecomponent, such as Notes/Domino or Net.Commerce, requires planning forimplementation (although that topic is outside the scope of this redbook).However, even if you decide to bypass the formal construction of architecturalalternatives, it is still a good idea to review the questions and comments fromSection 5.4.2, “System management” on page 81, up to and including Section5.4.6.1, “Tools” on page 98.

5.3 Developing a business scenario

A business scenario is a textual description of the problem being addressed.A business scenario is useful for putting the requirements in context and forproving the high-level designs that you will prepare for use in this phase. Thepreparation and use of a business scenario is a common practice inconsulting engagements.

Is the development of a business scenario a required step? No. Can it behelpful in gaining commitment to your design? Yes. Therefore, werecommend that you employ this tool as a part of the architecturalalternatives development phase.

It would be helpful to introduce and define three terms at this point: Businessflow, walkthrough, and event flow. These are different forms of businessscenarios, from very high-level to a more detailed description.

• A business flow is a high-level description of the ultimate business uses ofthe solution being designed. These would typically relate closely to therequirements gathered and describe what business tasks are targeted forinclusion in the solution.

• A walkthrough is a narrative that describes what people and systems willdo with the solution once it is implemented. Remember that we are dealingwith very high-level designs at this point; so, the descriptions will be interms of activities, not products or specific program tasks.

Developing architectural alternatives 73

• An event flow is a more refined form of a walkthrough. It attempts todescribe, in high-level terms, the events that occur and processes that areinvoked because of those events. We do not illustrate an event flow in thisredbook.

Which of these you choose to use really depends on which ones the team ismost comfortable with.

During the development of architectural alternatives, this business scenario isused to validate the alternatives to ensure that they are capable of providingfor the needs of the business. The business scenario is also useful forconfirming the solution architecture that is ultimately chosen.

An example of a business scenario for an electric utility company that seeksto deploy an e-business solution is shown in Table 6.

Table 6. Business scenario - Electric utility company

Business Flow Walkthrough

Determine replacement costs of rawmaterials. This will involve accessing out-side information sources to determine thecurrent price of the raw material (gas, oil).It will also involve access to raw materialinventory to determine how much replace-ment material will be required.

The production planner, using aworkstation, launches an application todetermine the cost of raw materials.

Determine the burn efficiency of fuel.

A request is sent to a server, which, inturn, sends requests to retrieveinventory and forecast information, andto Web sources, such as Reuters, to getcurrent raw material prices.

Determine current operating costs. Thiswill involve access to the financialsystems and possibly the workmanagement system.

Based upon the returned information,the replacement cost of raw materials iscalculated, complemented by the burnefficiency and current operating costs.

Calculate costs based on apredetermined formula.

Finally, the energy cost is calculated anddisplayed to the production planner.

Perform market analysis. This willrequire access to external informationsources.

The production planner launches arequest to retrieve market informationfrom the brokers’ Web server and gridoperator’s Web server via the Internet.


Additional architectural options may emerge as you explore the e-businessbuilding blocks and the related technologies found in this chapter.

Because e-business solutions tend to have object-oriented componentsinvolved (Java, Enterprise, JavaBeans, and so forth), you might want toutilize some object-oriented techniques during the phases discussed in thisredbook. Presenting object-oriented analysis and design approaches isbeyond the scope of this redbook. However, you are encouraged to becomefamiliar with these techniques (see Appendix E, “Related publications” onpage 321). For example, developing use cases is an effective way objectdesigners have of generating requirements for an application.

While the two columns in Table 6 can represent use cases at different levels,typically, a use case will be documented utilizing recognized use casetemplates. Use cases tend to be precise, formal, and accountable. What ismeant by accountable is that a use case document will act as a contractbetween users and developers.

Use cases can be developed at multiple levels - usually using a template toenforce discipline in the process; so, if someone on your team is familiar withuse cases, you can substitute these for the business scenario step.

5.4 Using e-business building blocks

At this point, you should have gained agreement from the company on twokey points:

• The complexity of the requirements does not lend itself to a simplee-business solution, and a more extensive design process (the subject ofthis chapter) is required.

• The business scenario created and presented correctly reflects what theenterprise is trying to achieve.

Create product price based onpredetermined profit margins.

The production planner calculates theproduct price using the daily marginretrieved from the productionapplication.

Contact grid operator and place bid.The production planner forwards the bidprice for the energy to the grid operatorvia the Internet.

Business Flow Walkthrough


As stated earlier, you should conduct this phase in a workshop and makegood use of a drawing board for diagrams. Depending on the size andcomplexity of the project, you may or may not run this workshop as acontinuation of the process described in Section 4.6, “Conducting aworkshop” on page 64. Again, depending on the nature of your project, youmay be working with the client, or the solution provider may be preparing adesign for presentation to the client.

Before starting on the individual building blocks of the diagram shown inFigure 21, you should cover the two layers in the diagram that overlay thewhole design: Security and system management. The decisions that you takein these two areas will affect every component of the design.

Figure 21. e-business building blocks

You should note that, although this diagram shows a client communicatingwith multiple servers in a Web environment, the diagram can and, whenapplicable, should be extended to cover server-to-multiple servercommunications.

In each of the sections about building blocks that follow, you will find atable listing Decision Points together with some notes about the impact ofeach decision on the design of that building block.

Where appropriate, we have included a second table with more detailedinformation and usage comments about aspects of that building block.

If, because of the resource available and the size of the project, you are notable to answer all the design questions, you should make clear whatassumptions have been made and revisit those questions when youproceed to a more detailed design.

Note

System Management

Client Network ServerAppl.Logic Connectors


Security


5.4.1 SecurityTable 7 lists questions to consider when deciding on the security policy,procedures, and practices for your company’s site:

Table 7. Security decision points

Decision Points Impact

Do transactions need to beencrypted?

Encryption is an expensive operation and willimpact your end-to-end budget. Deciding suchthings as which transactions or which parts of amessage need encryption and the levels ofencryption needed inside the firewall versusoutside the firewall may impact the design and,certainly, the technologies. Technologies, such asSecure Socket Layer (SSL) and SET, should beanalyzed for applicability.

If servers or clients will belocated outside the USA, is40-bit encryption acceptable?

The U.S. is relaxing some controls over the exportof cryptographic products. Financial institutions inmany countries can now obtain export licences.But, if this does not apply, your customer mayneed to seek strong cryptography from non-USsources.

How will users be identified?

Decide what information will be open to all visitorsand at what point users need to be identified.Table 8 on page 79 summarizes the technologiesused to identify users.Cookies can also be used to recognize repeatvisitors to the site without needing to know any oftheir personal details.The use of digital signatures should be evaluatedfor applicability.

Is there an existing customerdatabase that should be usedto identify online visitors to thesite?

User profiling can help collect information aboutvisitors to your customer’s site providingcapabilities to dynamically control interactionswith users. Investigating technologies to enablethese possibilities should be pursued.

Does your customer need torestrict access to parts of thesite?

The number and placement of firewalls isimportant to restrict unwarranted access tosensitive data and applications. Reviewingexisting IBM Intellectual Assets can helpunderstand proven techniques for using firewallsand designing solutions that properly positioncomponents around firewalls for asset protection.


Table 8 on page 79 lists various methods of user authentication on the Webwith explanatory notes. Table 16 on page 93 gives guidance on statemanagement and its security implications.

What privacy rules should beapplied to information providedby users?

Policies should be in place for the use of collecteduser data. Many countries now have legislationgoverning the holding of personal data oncomputer files.

What are the legalrequirements and companypolicies for auditing content,changes, and transactions?

Companies have been held legally liable for thecontents of their Web site.

Does the company alreadyhave a secure DeMilitarizedZone (DMZ) into which the Webserver could be placed?

If so, you must ensure that the current Webarchitecture will support requirements of the newe-business solution or else decide oncompromises to allow your e-business solution tooperate within established guidelines.



These security considerations will have to be revisited when dealing witheach building block.

Table 8. User identification

IdentificationMethod

Uses Comments

Basicauthentication

Simple userid/passwordauthentication

Basic Authentication has a specificmeaning within the Web protocol. It issupported by most servers - includingDomino - and allows simple control overaccess to files and directories based on auser ID. There are two main shortcomingsto this method:

• The password is masked rather thanencrypted for transmission; so, thismechanism is not recommended forhigh-value transactions without someother form of authentication.

• The browser caches the password andresubmits it on demand for latertransactions. There is no explicit logoffmechanism. This makes it unsuitable forwalk up-and-use kiosk applications.Unless a user remembers to close thebrowser, his of her identity can beassumed by the next user of theworkstation.

Basic Authentication is, in most cases, usedin conjunction with SSL 2. Here, the passwordis actually encrypted as the data trafficgenerally is.

Client certificates Strongauthentication

This method authenticates a user withpublic/private key technology. Thetechnique is used by Notes/Domino and bythe standard X.509 certificates of the WebSSL3 protocol. Because of theinfrastructure required to issue and managecertificates, this technology is not yetwidespread on the Web, although it iswell-handled by Notes/Domino.IBM and Lotus are leading industryinitiatives to enhance the interoperability ofdigital certificates.


5.4.1.1 Confidentiality, integrity, and accountabilityA detailed treatment of encryption tools and techniques and how they can beused to ensure confidentiality and accountability (non-repudiation) is outsidethe scope of this book. For a reading list and a basic introduction, see:http://www.ibm.com/security

5.4.1.2 Protecting your Network using Firewalls and RoutersA detailed discussion of the use of firewalls, filters, and routes for networkprotection is outside the scope of this book.

For more information on all aspects of confidentiality and security, start at theIBM SecureWay home page:

http://www.ibm.com/security

Application-specific

General userauthentication

In this method, user identification ishandled completely within the application.The application controls passwordverification and maintenance. This is themost common way of authenticating visitorsto a protected or e-business site.Frequently, the application includes afacility for a forgotten password to bemailed to the e-mail address associatedwith a user’s account.

Cookies

Not forauthentication,but toassociate avisitor to yoursite withprevioustransactions

Although it is reasonable to use a cookie tomaintain state during a shoppingtransaction, application designers shouldnot rely on cookies for recognition of usersacross visits separated by days or more. Ifthe user accesses your site from a differentworkstation or has reinstalled his or hersoftware, the cookie will not be available tothe server.

Note - The cookie is a mechanism introduced by Netscape, but it is now standard across mostbrowsers. The server can request that a piece of information be stored on the client computer,which can then be retrieved on a subsequent transaction. Expiry periods can be associatedwith cookies. For a shopping cart application, the expiry period might be on the order ofminutes; whereas, the expiry period for tracking browsing patterns might be months or years.The server matches a returned cookie, which is typically a large random-looking number,against previously-issued cookies to determine whether this is a new or a known user.

IdentificationMethod

Uses Comments


http://www.ibm.com/security/html/cryptography.html


5.4.2 System managementSystem Management is a very broad term encompassing many disciplines,such as performance measurement, availability reporting, reactive problemreporting, software distribution, as well as updates, proactive monitoring toanticipate problems, and other problem determination tools. Many of thesesystem management disciplines can be applied, to some degree, even whenthe network is the Internet (an environment over which you have no control).

However, you should note that some things, such as end-to-end performancemanagement or problem determination of network outages cannot be donefor the Internet. Other things, such as the distribution of software updates, arequite applicable to the Internet.

It is tempting to create a pilot site as a proof of concept and then put the sitelive on the Internet without considering system management issues.However, it is usually harder to add system management tools andtechniques after your site has gone live.

Table 9 shows some of the system management policy decisions concerningthe management and operation of the system that you should resolve duringthe architecture development phase and describes the impact of thosedecisions on the design.

Table 9. System management decision points


Does the company have theinfrastructure to install and runits own e-business server?

If not, you may need to factor into your designways of developing the appropriate infrastructure.This may lead to recommendations for personnel,technologies, and support products, or thecustomer may wish to have a third party host theservice.

What hours should the servicebe available?

Bear in mind that the company’s site may beaccessed from different time zones and thattypical Internet users expect 100 percentavailability.

Security is a primary area of concern among customers consideringe-business solutions. If your company’s security requirements are verycomplex, you should consider involving a qualified solution provider, suchas IBM.

Note



Is it acceptable to have anyscheduled downtime formaintenance?

If not, provision should be made in the design forhow maintenance and upgrades are to be made.Availability issues such as these will affect thecost of the solution.If back-end systems are subject to interruption forbackup or maintenance, the customer may stillwant their home page to be available to givedetails of service status.

How important is it that theservice never be interrupted,even for unscheduledcomponent failures?

Avoiding all single points of failure may be costly.Considerations for redundancy in all componentsshould be investigated.

If interruptions do occur, whatshould the target time forrestoring service be?

This implies that service-level agreements shouldbe established. Knowing the requirements for theservice-level agreements will impact the decisionpoints for availability of your e-business solution.

How should partial or totalservice failures be monitoredand handled?

Think about how the application will handlefailures. Technologies, such as Simple NetworkManagement Protocol (SNMP), assist inmonitoring the application environment by makinguse of Management Information Base (MIB)standards. You should investigate how well themanagement tools you select support thesemanagement standards.

What are the response timetargets?

Response time targets will probably vary bytransaction type. Establishing an end-to-endbudget for response time provides a way tocheckpoint each component within the buildingblocks during the design phase, as well as laterduring implementation and testing.

Do you need a recovery plan forthis e-business system, or will itbe covered by yourorganization’s existingprocesses?

This should cover the loss of individualcomponents, such as hard drives or processors,as well as a disaster that involves the entire site.

How should the architecturesupport the process of problemreporting, tracking, and fixing?

Who should be alerted, and how, if there is ahardware or software problem that affects thesite?



5.4.3 Client building blockTable 10 lists important questions to ask when defining the architecture foryour client building block.

Table 10. Client decision points

What statistics do you need tokeep about the site, and howwill they be analyzed?

One essential measure of the effectiveness of asite is the number of visitors. It is important tounderstand how easy it is to find information bytracking their navigation patterns.

What instrumentation should beincluded in the design tomeasure performance,response times, andavailability?

You need these details to make informeddecisions about capacity plans. Also, yourapplication can provide event information so thatoperations can take proactive steps to recover incase of an application failure.

Should the architecture includea repository for statistical data?

Can you make an estimate of the storage spacerequired by the repository? Does the design needto include off-loading of historic statistical data toarchival storage?

Decision Point Impact

Who is the customer (Internetor intranet)?

On an intranet you may have some control overthe hardware and software specifications of theclients. You may even choose to use some clienttypes other than, or in addition to, a standardbrowser.If your application is to be made available over theInternet, your design point will probably be the twoleading browsers.

What is the level of the user’sskill?

This will impact screen design. You may wish toplan for human factors studies of the dialogs.Other related factors include possiblerequirements to support text-only mode ofoperations for sight-impaired people or forscientific professionals, who have been reportedto prefer the speed of text-only mode whenreading academic papers online.



What languages should the sitesupport?

You clearly need to support the language of thecountry of your e-business customer set. If youneed to support more than one language, youshould think carefully about the implications ofmaintaining versions of your pages in differentlanguages.

What are the user’s usagepatterns?

Recent studies show two distinct patterns ofusage of the Internet to find information: browsingand direct searching. You should consider makingit easy for visitors to your site to use either mode.For ease of use, it is also recommended that youshould be able to find any piece of informationwithin three clicks. Additionally, your businessrequirements may require transaction capabilityfor your users.

Is there a need to distributeapplication code, and if so, howwill it be done?

Even if you are just making your applicationavailable over the Internet, you may not be able toassume that your potential users have Internetaccounts. You may need to distribute guidanceand even code to help them access the Internet.If there is application code, other than thebrowser, that cannot be downloaded and needs tobe physically distributed, you will need a supportstructure to handle this.

How will the applicationmaintain state?

See Section 5.4.5.2, “Session and statemanagement” on page 93.

How will the choice of clientaffect end-to-end response?

You should consider key Internet technologies andhow they might affect response time.

• HTML is the common method of renderingpages on a browser. The design of HTML pagesis an important aspect of end-to-end responsetime. For example, if your page has manycomplex objects, the number of connectionsrequired by HTTP may be large, download timemay be impacted, and rendering time on thebrowser workstation may suffer.

• The use of Java applets will slow down initialresponse while the applet loads but may allowsubsequent interactions to be faster.

• Technologies, such as IIOP and RMI, should beinvestigated for applicability. Decisions heremay be influenced by a desire for openstandards.



Table 11 provides background information to assist you in your choice ofclient architecture. It lists the most common types of client that are found onthe Internet together with comments about their applicability to e-businesssolutions.

Table 11. Client architecture

Is the browser the only userinterface (UI)?

There may be requirements for mail orcollaborative applications for which a browser isnot the best (or only) option.

Client Type Uses Comments

Standard browser

You must design for astandard browser whenyou cannot dictate thechoice of client, forexample, when dealingwith the general publicor with third partiesover the Internet.

Avoid designing for a specificbrowser.One British supermarketimplemented an online store thatwas specific to Internet Explorerand rejected users with NetscapeNavigator. Following negativepublicity, the site was redesigned tosupport both leading browsers.Even within a standard browser,you need to determine your designpoint: 640x480 with 256 colors orabove?

Specific browser Preferably never.

Even for intranets, where you candictate the choice of client, the bestpractice is to support multipleleading browsers. This preservesyour ability to extend the applicationto third parties or newly-acquiredsubsidiaries that might havedifferent browser standards.



Standard mailclient(POP3 or IMAP)

Informalcommunications.

Because these mail standards areso widespread, it is important thatany company wishing to establish aWeb presence provide a way ofhandling inquiries submitted bye-mail.However, since there is no way ofbeing sure that the originator of anincoming e-mail is who his or hersignature says he or she is, youshould not use e-mail for valuetransactions without some addedform of authentication.

Secure mail clientFor e-mail withencryption and strongauthentication.

This can solve the e-mailrequirements for confidentiality,positive identification, andnon-repudiation. However, thereare competing standards (S/MIME,PGP and Notes). As with SSL3Web client authentication, acertificate managementinfrastructure is needed.

Collaborative

Applications involvingcollaboration and/orworkflow or requiringstrong authentication.

Although mainly used withinsingle-company intranets, there areexamples of successfulbusiness-to-business collaborationprojects.

Thin client

Chiefly used withinintranets to reduce thecost of ownership. NCsmay be used for Weband e-businessapplications fromkiosks to simplifymaintenance.

There are several flavors of thinclient: Network Computers, such asthe IBM Network Station, NetworkPCs, and clients using IBMWorkSpace On-Demand.From the e-business applicationperspective, treat them as a clientwith browser and e-mail capability.

Client Type Uses Comments


5.4.4 Network building blockTable 12 lists decisions that you should take for the Network Building Blockand their implications.

Table 12. Network decision points


Will my solution involve theInternet?

If this is the first time that company systems willbe connected to the Internet, you should involvenetwork design and security people from both theclient and IBM so that they can agree on policiesand design.

What protocols will I use?

HTTP is the standard protocol used by browsers.Other protocols that you might find are FTP (forfile transfer) and HTTPS (secure HTTP).Application protocols might include IIOP, RMI,Messaging, or RPCs. The firewalls and filtersprotecting your site will need to be set up to allowthe appropriate protocols to pass through.

What about data, object andapplication placement?

In order to understand the impact of thee-business application on your network, you needto know the data and application placement.Analyses of projected transaction volumes, theamount of data typically being requested, and theamount of object interaction are required to helpwith decisions about your architecturalalternatives.

What security functions arerequired/provided by thisbuilding block?

Protocols can affect security design. You need tocheck whether the IIOP, RMI, Messaging, orRPCs that you may be considering can flowacross your network. The level of encryption thatyou are considering will affect your networkrequirements and will have performanceimplications.

Will my existing networkfunction as required?

While your current network infrastructure mayfunction with the introduction of a new e-businesssolution, additional work may be needed innetwork design. The network may need to beexpanded with additional function or capacity.This activity would typically be a separate effort,perhaps conducted in parallel with thedevelopment of the new e-business solution.


Table 13 lists some network technology options and comments on their use.

Table 13. Network architecture

How does the network affect myend-to-end response time?

Compare estimated traffic against availablebandwidth to come up with initial estimates ofnetwork responses. Take into account peaks aswell as average loadings.

Network Type Uses Comments

IP - InternetLinks to thirdparties or thegeneral public

It will be impossible to commit to end-to-endresponse time targets when transactions arerouted over the open Internet.

IP - intranetIntranets bydefinition

An intranet can be securely extended acrossan open network to create a Virtual PrivateNetwork (VPN) using, for example, the IBMeNetwork Firewall product. You can use thistechnology to link different regions of thesame company or a company with itsbusiness partners.

IP - LAN Intranets LAN (as opposed to WAN) IP connectionsallow for greater bandwidth applications.

ProprietaryExistingsubnetworks

An existing subnetwork using a protocol,such as SNA, DECNET, or Appletalk, mayform part of an e-business network.Network-dependent middleware will beneeded to connect to back-end systems.



5.4.5 Server building blockIn Table 14, we list questions to consider when selecting server components.

Table 14. Server decision points


Is this an end-userclient-to-server model, or willremote server-to-servercommunications be required?

If other existing servers are involved, how doesthat affect the choice of this server?Understanding the technologies available canhelp with possible alternatives.

• Messaging: Excellent choice if there are multipleservers that the application needs to interactwith but have different operating environments.May require some programming on the targetserver to accept and reply with a message.

• RMI or IIOP would be considered if theapplications on the other servers are objectbased.

• Proprietary interfaces (RPCs for example) maybe needed for certain servers.

• Standard SQL access might be appropriate forRelational Data Base access. JDBC, ODBC, ora native interface may be needed.

Does this design call for asingle server or multipleservers?

You may choose to use multiple servers for loadbalancing and redundancy or to run different kindsof workloads.If you intend to load balance across multipleservers now or in the future, what are theimplications for concurrent database updating?Capabilities of the application server, such ascaching, clustering, and load balancing, should beconsidered and will have an impact on componentselection.

Does my choice of clientoptions affect the serverdesign?

For example, you may have decided that, sincethe general public is involved, your design pointwill be a low specification PC, and you cannotassume that the client can run Java applets withacceptable performance.


How will I implement myapplication server businesslogic?

Will I use servlets, distributed objects, CGIprograms, or server APIs? Usage patterns of users,the skill level of developers, the number ofconcurrent users, and expected response times areall factors that will affect how the business logicshould be architected. For example, casualinfrequent access by a user may dictate a simpleCGI or server API interface, while a highlyinteractive user requiring repeated interaction withthe server may dictate a servlet or a distributedobject approach.

Will I use applet gateways?

An applet gateway runs on the server andinterfaces between an applet on the client and theback-end system for which it is the gateway. Thiscan be a straightforward way to Web-enableback-end systems with a minimum of modificationbut will also dictate some of your server options.

Do I need to provide mail orconferencing facilities?

You need to understand how the mail orconferencing will be handled and what functionsthe server will need to provide.

Do I have workflowrequirements?

If so, what level of function do you need? Can youprovide this using a normal Web development toolor an integrated solution, such as Lotus Domino,or do you need a special purpose workflowpackage?

Should the server provideindexing and searching or othersite navigation aids?

Some servers, or server packages, provide thesecapabilities as standard, but, depending on yourrequirements, you may need a special purposeindexing/search engine.List the searching capabilities that you need: Doyou need to be able to search a single server ormany? What should be indexed: HTML files, wordprocessor files, PDF files, other formats, ordatabases?



Table 15 summarizes the various types of servers that are found on theInternet and comments on their applicability to e-business designs.

Table 15. Internet server types

Is distributed object supportneeded?

Requirements for a highly-interactive transactionalsystem may lead to a requirement for distributedobjects to provide services across the enterprise,possibly from several servers. You may need toinclude an Object Request Broker in yourarchitecture to provide distributed object services.An evaluation of technologies for distributed objects,such as IIOP and RMI, will be needed as well as anunderstanding of your customer’s requirements forstandards, such as CORBA.

What security functions arerequired in this building block?

All areas of security should be considered:Confidentiality, integrity, authentication, accesscontrol, and auditing capabilities. While anin-depth treatment of security is outside the scopeof this redbook, see Table 8 on page 79 for insightinto authentication approaches.

How can I estimate the servercomponent of end-to-endresponse time?

This is usually not straightforward. The StandardPerformance Evaluation Corporation athttp://www.specbench.org now includesSPECweb and SPECJVM among its publishedresults. At best, these results can be used to gaina general feel for the relative speeds of variousprocessors and allow a very rough estimate oftransaction throughput.In practice, the results that you will achieve willdepend, in large measure, on your applicationdesign. You should include some performancetesting in your project plan.

Server Type Uses Comments

Generic HTTPserver

Basic servingof flat HTMLfiles.

Basic HTML serving is not enough for mostof today’s needs.



http://www.specbench.org./

Combined Weband applicationserver

e-businessapplications

Most Web servers provide additionalapplication support, sometimes bundled withthe server and sometimes availableseparately and callable via interfaces thatthe server provides. At this stage in thedesign, you should identify the functions thatyou require from the server. For example,you may need the application server toprovide support for:

• Servlets• Java Server Pages• Caching• Clustering• Load balancing• State management• User profiling• The ability to build a searchable index

Mail server Mail services

Although an e-business will wish to provideits own employees with e-mail capabilities, itwill not normally want to act as the homee-mail server for people outside theorganization.However, you may well receive requests bye-mail and wish to build a workflowapplication to handle this.

News serverDiscussionsandconferencing

We identify this as a specific server typebecause the conferencing (NNTP) protocolis well known on the Internet and is olderthan HTML browser technology. Ane-business may well wish to provideconferencing in support of its products (forexample, the Agfa company does this).

Because the NNTP protocol does notnormally work through companies’ firewalls,if you have a conferencing requirement, youmay choose to use a product that supportsconferencing using browser protocols, suchas Lotus Domino or Allaire’s Cold Fusion.

Special purposeserver

Multimedia,real-time

There are special-purpose methods ofserving audio and low-bandwidth video tobrowsers, such as IBM Bamba.Real-time conferencing solutions includeLotus Sametime.

Server Type Uses Comments


5.4.5.1 Platform selectionAt this stage of the design, we are trying to develop an architectureindependent of specific products. The questions about the server have notbeen platform-specific. If there are overriding reasons for selecting aparticular hardware platform, you should note them here.

5.4.5.2 Session and state managementArguably, one of the reasons for the initial success of the Web was thesimplicity of its stateless protocol. A server could treat each request as anindependent event and did not have the overhead of keeping track of opensessions. This model was fine when the Web was used for retrievingindividual pieces of information, but it is not good for e-business applicationswhere, for example, a purchase transaction continues over severalinteractions with the server. To meet this requirement, various techniqueswere developed as described in Table 16.

Table 16. Session and state management techniques

Type Uses Comments

Cookies Maintainsession state

See the note in Table 8 on page 79 for adescription of cookies. Also note that a usermay set his or her browser to refuse cookiesbecause of (unfounded) fears that theyintroduce privacy exposures.For this reason, your application should bedesigned to work when cookies areunavailable.

Hidden fields orURL component

Maintainsession state

Hidden fields or strings appended as optionsto a URL can be used to contain an encodedfield that defines the session state.

Note that, since these are visible to userseither directly or via the browser ViewSource command, they should not contain,for example, passwords in cleartext.

The server should also take care to destroythe session variable at the completion of atransaction because the information couldpersist in the browser’s cache. This wouldallow a subsequent user of the workstationto attempt to continue the previous user’stransaction.


5.4.6 Application logic building blockThe decisions you take about application logic are closely linked with those inSection 5.4.3, “Client building block” on page 83.

Table 17 lists some decisions you should make in determining what style ofapplication development to use.

Table 17. Application logic/development decision points

Applet Managesession

An entire transaction consisting of severalinteractions with a server can be performedby a single Java applet that, therefore,maintains state. This is more complex toimplement since it involves selecting andimplementing a protocol for communicatingbetween the applet and its partner on thehost.

Decision points Impact

Is this a logical two-, three-, or n-tiersolution?

Note that we are referring to logical tiers andnot physical tiers. It is perfectly possible,and sometimes advisable, to design alogical three-tier solution having two of itslogical tiers (typically the Web server andthe data server) on the same physicalserver.

Has it been decided whether to useObject Technology, traditionalprogramming development, orintegrated packages?

Existing packages, if they meetrequirements, are usually faster toimplement. Object Technology, with itsbuilt-in reuse capability, also offersimplementation benefits in conjunction withthe appropriate development tools.

Is application control needed todetermine what information theend-user can print or save to disk?

If your customer is selling information, he orshe may wish to make it hard for the user tosave or print it, but this also complicates thedesign.

Is a normal HTML presentationadequate, or should the userinterface be enhanced through theuse of Java Applets?

Java applets can be used to make thepresentation more flexible and user friendly,especially in higher volumetransaction-based applications. However,they take time to download and may be aconcern over dial-up connections.

Type Uses Comments


Is client-side scripting needed? Atwhat level?

JavaScript, JScript, or ECMAScript arelanguages interpreted by the browser thatcan be used to enhance the user interfaceand perform some basic input validation.Because of implementation incompatibilitiesbetween the different levels of browsersfrom Netscape and Microsoft, you shouldplan to test against all likely clients.

Will the site use proprietary scripts,tags, or plug-ins?

The use of proprietary features is generallydiscouraged since it limits the application’sportability.

Will the site use Java applets? Whatare their connectivity requirements?

As part of the standard security built intoJava, an applet can only communicate withthe server from which it was downloaded. Ifthe applet needs to communicate withanother server, this has to be done indirectlyvia its own server or through the use ofdigitally-signed applets.

How will the application be splitbetween client-side logic andserver-side logic?

Assuming that a logical three-tier architecturewill be the basis for developing thearchitectural alternatives, you shoulddetermine how to distribute presentation logic.For example, you can use straight HTML. Thisimplies that all user field validations will becarried out on the server. This might be veryappropriate for a decision support applicationwhere little input is needed from the user.Creating HTML with JSP or servlets might bemost appropriate. However, if interaction isneeded from the user, such as intransaction-based applications, can theapplication support the amount ofclient-to-server interaction that this mightproduce? If it is decided that the client shouldperform these functions, is a scriptinglanguage needed, or should applets beemployed?

Decision points Impact


Table 18 gives detailed comments about some of the application logicdecisions that you will have to take.

Table 18. Application logic decisions

Application Type Uses Comments

Client-sideJavaScript

Simple animation andinput validation.

Now pervasive on the Web andrecommended for making pagesattractive. It offers a good way ofproviding field-level validation oninput from a user immediately,without the need to incur networkoverhead. Implementations differ;so, be sure to test with multiplebrowsers.

Java applets(client-side)

Animation and datavisualization.Other uses includesession maintenanceand locally-writtensecurity functions,such as strongencryption andnon-repudiation.

This can be a very powerful tool fordata manipulation and visualizationat the client. Use with care becauseof the time needed to downloadJava applets, especially overdial-up connections.


Server-sideapplications

The basic buildingblock for tailoring Webpages to the user,whether based onsome informationabout the user’spreferences orquerying a database inresponse to an explicittransactional request.

The following are some ways ofproviding server-side applicationsupport:

• CGI is the most common. It haslow portability but wideprogramming language support.Even with Fast CGIenhancements, however, it doesnot scale well.

• SSI: Server Side Includes is asimple way of producing dynamicpages. However, it cannotprocess FORM data and has lowportability.

• Proprietary APIs, such as ISAPIfrom Microsoft and NSAPI fromNetscape, improve performanceover CGI at the expense ofapplication portability.

• Servlets are very portable andmake it easy to share databetween servlets; they provideeasy session tracking.

• JSP: Java Server Pages aresimilar to Microsoft’s ActiveServer Pages (ASP) and SSI,and have the portability of Java.

• A Java application can provide fora robust object-basedapplication. It may takeadvantage of Object RequestBrokers (ORB) that can provideservices, such as locating objects(directory) and handling requeststo the operating environment,allowing platform independenceand enforcing standards of howdistributed objects willcommunicate.

Application Type Uses Comments


5.4.6.1 ToolsAs part of the application logic definition, you should try to decide whichattributes you will look for in a set of tools. Table 19 lists questions that youshould ask when selecting tools for creating and maintaining the site.

Table 19. Tool selection questions


How will the applications bebuilt: Using applicationgeneration tools, prebuiltpackages, or a combination?

Most modern sites use a combination ofintroductory pages of regularly-updatedstatic HTML and application pages thatare dynamically-generated.

Will content authoring tools beused?

As well as being a valuable productivityaid, content authoring tools make it easierto enforce design consistency.

What content managementtools are needed to control thesite?

You need a sign-off process for pages.There may even be a legal requirement toknow what was displayed on a particulardate.You may also wish to associate “go-live”and “do not display after” dates withdocuments. For a small site, manualprocedures may be adequate; for a largesite, they are unlikely to be.

How much integration isprovided by the applicationdevelopment tool?

The degree to which the type of Webdevelopment is integrated into a singletool can help provide productivity for adeveloper.

How will a team developmentenvironment be supported?

The development tools should support ateam environment providing integrity forapplication code.

Will the code be developed onone platform and deployed onanother?

The development tools should allowdevelopment of code on the platform thatis most productive for developers and thenassist in deployment to other platforms.


In Table 20, we list comments about the classes of tools you are likely to needto create and maintain your applications and site contents.

Table 20. Types of development tools

Should the tools beextendable?

Most tools provide extensions to assist inthe development process. Polices andprocedures should be developedconcerning the use of extensions.Considerations would be:

• To what degree does the extensionlock you into a specific vendor?

• Does the extension generate code thatis non-standard or uses non-standardAPIs, thus, making it less portable?

Tool Type Uses Comments

Applicationcreation

Createbusiness logicon applicationserver

Web application creation tools shouldprovide programmer productivity features,such as visual programming, aproject-based team developmentenvironment, and support for JavaBeans.

Content authoring

Although it is very easy to display a fewpages on the Web, you will probably want totreat your company’s pages on the Internetjust like any other external publication. Thatis to say, they should be reviewed beforepublication for content as well asconformance to your company’s corporateimage, typefaces, colors, and page layout.Editorial rules must be defined andenforced.

Page creationIf it is not included with your applicationdevelopment toolset, you may wish to use avisual page creation tool, such asNetObjects Fusion.

Graphicdesign

Graphic design tools are outside the scopeof this document. However, the importanceof good, consistent, and professional pagedesign should not be underestimated.



5.4.7 Connectors building blockTable 21 lists some of the important criteria for selecting connectors.

Table 21. Connectors decision points

Contentmanagement

Contentpublishing andmanagement,navigationtools

Some content creation tools also support thepublication process and provide sitenavigation aids. If the tools you select do notprovide this support, you may have to devisemanual procedures.


What enterprise systems,applications, and data does mye-business application need toaccess?

See Section 4.5.4, “Understand the currentenvironment” on page 60, for a discussion of theconsiderations. The type of data, application,platform, and network may influence thetechnologies that may need to be considered indifferent architectural alternatives.

How should data be transferredbetween different systems?

Relational database systems provide ways ofaccessing distributed data that handle the datatypes and data conversion requirements. Forother transfer mechanisms, you should determinethe complexity level of the data. From this, youshould determine whether a self-describingmessage format, such as that provided by theXML technology, is needed. XML can provideadvantages in dealing with different data types.For example, there are reusable componentsavailable that will parse XML messages, thus,improving programmer productivity.

How current does theinformation have to be?

If the information does not have to be updated inreal-time, you may be able to use local extracts orcaches to improve performance.

Tool Type Uses Comments


Will I require synchronous orasynchronous access?

The use of an asynchronous messagingtechnology with assured message delivery cansimplify the application programming task. Theapplication can continue operating even if thenetwork connection or remote application isunavailable. Asynchronous messaging does notpreclude using it in a synchronous mode.Synchronous technology will require a connectionto be available whenever the application isavailable. Because a connection is known toexist, handling commit processing may be easier.

Will I require access to differentoperating systems, networkprotocols, and applicationenvironments?

Although TCP/IP is the standard network protocolof the Web, your back-end systems may be usingother protocols. Also, applications may be usingstandard or non-standard APIs. Theseconsiderations will help you evaluate the differentconnector technologies described in Table 22 onpage 102. If protocol conversion is needed, youwill have to decide on the best place to do theconversion.

Is a new user interface (UI)required? If so, what kind?

If you are accessing enterprise data or applicationlogic that currently has a defined user interface, aredesign of that interface allowing programaccess may be needed. Alternatively, the use oftechnologies allowing access to the logic and datamay need to be employed.

Will I require additional securitypolicies?

Enterprise data and applications may have theirown access security policies controlled andadministered separately from those in place forthe Internet environment. If access to enterprisedata and applications is needed, how will securitypolicies be enforced? Can the application serveract as a proxy to the enterprise data andapplications (this implies trust of the applicationserver’s security policies)? If not, you will need towork out how user IDs and passwords are to bemapped from the Web server to the enterpriseservers. With this type of information, you need tostudy how the different connector technologiessupport security when connecting to enterprisedata. Some research with potential products maybe needed.



As part of the connectors building block, you should try to decide whichattributes you will look for when interfacing into enterprise data andapplications as shown in Table 22.

Table 22. Connector types

Can I predict what scalabilityand performance I will require?

Careful consideration should be taken concerningperformance when designing the application. Ifyou choose to go with a prototype, you shouldallow time to review the design for performancebefore going into production.

Connector Type Uses Comments

MessagingAsynchronousaccess toenterpriseservers

Messaging middleware can simplify theapplication programming task by handlingqueueing, timeout, and recovery/restartconditions. You can also use messagingmiddleware in a pseudo-synchronous mode.Typically, messaging technology cansupport large message sizes. Some RPCapproaches may be limited in message sizerequiring additional programming to handlelarge messages.

JDBC/ODBC Databasecalls

These are database-independent interfacesfor Java servlets or application programs tomake calls to databases that may be on thesame or another server.

Native interfaces Databasecalls

Many database vendors have implementednative application program interfaces to theirown databases that offer a performanceadvantage over ODBC at the expense ofapplication portability.

Remote ProcedureCall

To callprograms onremoteservers

You may not need to program at the RPClevel if you have an application builder thattakes care of this for you.

ConversationalLittle used ine-businessapplications

This is, typically, low-levelprogram-to-program communication usingprotocols, such as APPC or Sockets.



5.4.8 Enterprise data and application building blocksIt is very likely that the company already has one (or possibly more)databases holding enterprise data. If so, the design and implementation ofthe enterprise data repository may be predetermined.

Table 23 lists some questions about data access that you should consider inyour design.

Table 23. Enterprise data access decision points


Do the service hours for theenterprise data repositorymatch the e-businessapplication targets?

You may have to take some policy decisionsabout how to treat requests that cannot behandled immediately: Options include asking theuser to resubmit or placing the request on a queuefor later handling, with possible confirmation bye-mail.

How will you map the accessauthorization rules for thecorporate database to youre-business user identification?

This will be an important question if you intend toenable a controlled ability for certain Web users toupdate corporate database records.

Is your e-business applicationusing the corporate data forreference (that is, read-onlyaccess)?

There may be performance or other advantagesto working with a local extract of the database ifthe requirement for data currency permits.

Is the data in a format easilyaccessed by distributedsystems?

Enterprise Data may be held in EBCDIC andrequire translation to ASCII for presentation onthe browser. Implications that may (or may not)affect your design include different sortingsequences and number formats.

If additional code is needed togain access to data (forexample, non-relational data),how will this code bedeveloped?

If your enterprise data is located on a mainframe,you may need to develop additional CICStransactions or MQ Series Triggered transactionsto interface to existing data or application logic.You will need to decide how this code will bedeveloped and if there are resources available todevelop this additional interface code.


Table 24 gives brief generic comments about ways to access back-endsystems.

Table 24. Enterprise data and applications

If access is to relationaldatabases, can the SQL bestructured to minimize networktraffic?

When enterprise data can be accessed with SQLcalls, you should review the number of callsneeded to satisfy a request. Since issuing SQLcalls can be simple, it is sometimes tempting torely on this when designing the architecturalalternatives. Be careful that your architecturedoes not force you into issuing too many SQLcalls, thus, reducing performance because ofnetwork traffic. Consolidating SQL calls with theappropriate use of joins can reduce networktraffic. Using stored procedures to consolidateSQL calls can also reduce network traffic. Using atransaction monitor can also provide a way ofreducing server-to-enterprise server interactions.Also, resist the temptation to design businesslogic into the stored procedure because you willlose flexibility in your design.

What are the commit androllback requirements of theapplication?

For Web applications, you need to pay particularattention to incomplete or cancelled transactions.At times of slow network response, the user isvery likely to press the Stop button on the browserand immediately retry the transaction. Yourapplication design must allow for this.

Data Type Uses Comments

RelationalDataBaseManagementSystem (RDBMS)

EnterpriseData

RDBMSs are now the standard datarepository: Most products offer one or moreoptions for Web-enablement.

TransactionalSystems Monitor

High volumetransactionalaccess toenterprisedata

Special-purpose transaction monitors, suchas CICS and ENCINA, can often handlelarger volumes of transactions than Webservers.



5.5 IBM intellectual capital

IBM has participated in the design of hundreds of e-business solutions. Thiscollection of experience is a very valuable resource, and IBM strategy is touse the results of this experience in future engagements. If you are an IBMcustomer, it would be beneficial for you to engage the IBM Global servicesgroup to benefit from their vast experiences.

If IBM has this collection of known-to-work solutions, why spend time with thisredbook? Because you will find that no two customers are exactly alike, andno two e-business opportunities are exactly alike. At this point in thee-business solution design approach discussed in this book, you should havecompleted three very important tasks:

1. You should have collected business requirements and other requirementsfrom the customer. Moreover, you should have worked to get agreementfrom the customer that the requirements are correct, complete, and maybe used to build the solution.

2. You should have developed a business scenario that represents thebusiness processes that your design will support.

3. You should have started the process of developing several architecturalalternatives that might apply to the business situation presented by thecustomer, as defined by the requirements they have provided you.

You could design the architectural alternatives without utilizing any of thiscollective experience from IBM solution designers. However, this may resultin overlooking things that you had not thought of but others had; so, it wouldbe best to utilize, wherever possible, this IBM intellectual capital.

5.5.1 How to get access to existing IBM solutionsIf you need IBM intellectual capital information, contact an IBM representativeto engage IBM Global Services.

Packagedsolutions

Standardapplications

Your client may have standard packagesthat need to be included in your solution.Examples include Enterprise ResourcePlanning (ERP) packages from variousvendors or business software fromcompanies, such as SAP.

Data Type Uses Comments


5.5.2 IBM intellectual capital and our building blocksIn Figure 9 on page 26, we introduced the diagram that we have usedthroughout this redbook to represent some essential building blocks of ane-business solution. That diagram was intentionally simple in design. Itspurpose was to remove some of the complex details of an e-business designso that you could focus on the fundamental concepts.

As illustrated by the diagram in Figure 22, the e-business designs that youwill find in the collection of IBM intellectual capital may be more complex.

Figure 22. Example of IBM intellectual capital design

As you can see, more detail is provided in this diagram. Now, we illustratehow our original building block diagram still applies.

In doing so, we make three points:

• The process of developing a solution involves more than simply taking apreviously-designed solution and applying it to a new situation. No twosituations are alike, and no two customers are alike. Nothing takes theplace of hard work and experience.

• The fundamental concept, as shown in our building block diagram (Figure9 on page 26), remains a useful guide through this process of solutionbuilding.

• Real e-business solutions are often complex and rich in detail. You shouldnot be lulled into the false expectation that an easy, quick, and simpledesign will always apply.

Outside world Demilitarized Zone (DMZ) Internal network

Internet

FirewallNode (1)

FirewallNode (2)

Non-secureProtocol

SecureProtocolRetail

Customer

Public KeyInfrastructure

Domain NameServer

InternetProtocol (P)

Web ServerNode

(Transactional)

Web ServerNode

(Information)

Security Node(Authentication)

IntegrationNode

ApplicationNode

Data FlowSecurity Flow


First, we simplify the design shown in Figure 22 on page 106 without reducingits content. This is shown in Figure 23.

Figure 23. Simplified version of IBM intellectual capital design

Finally, we map this simplified diagram onto our building block diagram. Thisis shown in Figure 24:

Figure 24. IBM intellectual capital design mapped to building block diagram


FirewallNode (1)

FirewallNode (2)

RetailCustomer Integration

NodeLAN LAN

ApplicationNode


Web ServerNode

(Transactional)

Web ServerNode

(Informational)

Internet

DomainName Server

Internet InfrastructurePublic Key

Infrastructure

Security

System Management


EnterpriseData and

Application


FirewallNode (1)

FirewallNode (2)

RetailCustomer Integration

NodeLAN LAN

ApplicationNode


Web ServerNode

(Transactional)

Web ServerNode

(Informational)

Internet

DomainName Server

Internet InfrastructurePublic Key

Infrastructure


The first thing you will note is that the match is not perfect. That is to beexpected. However, as you study this diagram, you will see how aspects ofthe simplified design map back to our building blocks.

5.6 Creating architectural alternatives

Using the requirements gathered in Chapter 4, “Gather requirements” onpage 49, and the information in this chapter, you are now ready to build somearchitectural alternatives. We recommend that you keep the number ofalternatives to a minimum. In practice, three or four alternatives seems towork best. Keep in mind that the architectural alternatives are based on thebuilding blocks we are using throughout this redbook. Your alternatives will bevariations of this basic concept. The variations can be as simple asdifferences in the technologies used. For example, one alternative may havethe selection of a CICS connector versus an MQ connector as its onlyvariation. Section 6.3.2.1, “Example architectural alternatives to be graded”on page 116, gives examples of the architectural options that you might havecreated.

Prior to beginning this step, you should become familiar with IBM intellectualassets as described in Section 5.5, “IBM intellectual capital” on page 105.These assets can help you determine the direction that the solution for yourcustomer may follow and give you ideas on how to best illustrate thealternatives. You should be able to relate the architectural components of IBMintellectual assets to the building blocks. An example of this mapping isdescribed in Section 5.5.2, “IBM intellectual capital and our building blocks”on page 106. Keeping the diagrams simple can help you better position thealternatives and facilitate the discussion with the customer. The key is toclearly document your alternatives so that they are easily understood as youpresent them to your customer.

To ensure your architectural alternatives are capable of satisfying thebusiness problem, you should use your business scenario to validate them.

Once documented and validated, you should present your alternatives to yourcustomer. It is helpful if you develop a short list of pros and cons for each of thealternatives utilizing your team's knowledge and experience, informationgathered from this redbook, and information available from various vendors(references are given throughout this redbook). At this point, it is important tokeep the discussion focused on the technologies offered by the alternatives.Avoid the temptation to talk about products. The development and discussion ofpros and cons can help position your alternatives and is excellent preparation forselecting the best architectural alternative as described in this chapter.



At this point, you should have created architectural alternatives, documentedand validated these alternatives, and presented them to your company. Youare now ready to select the best architectural alternative, but, beforeproceeding, ask yourself the following questions:

• Have you utilized IBM Intellectual Assets to help reduce the riskassociated with the alternatives?

• Have you reviewed your alternatives with appropriate specialists orarchitects?

• Have you developed and discussed a short list of pros and cons for eachof the alternatives?

• Have you clearly documented and validated the architectural alternatives?

• Have you gained commitment from your customer on the alternatives andtechnologies presented?

• Have the appropriate action items with assigned owners been put intoplace for any unresolved issues?

If you can answer yes to each question, you should now have somearchitectural alternatives agreed to by your customer that you can use inChapter 6, “Choose an architectural alternative” on page 111, to arrive at thebest architecture to meet your customer's requirements.

If you have answered no to any of the questions, or if additional requirementsconcerning the business problem surfaced during the discussion of thealternatives, you may need to go back and repeat some of the steps in earlierphases, which are shown in Figure 25 on page 110.


Figure 25. Checkpoint: Develop architectural alternatives

Gather Requirements


Choose Architectural Alternative

Select Technologies

Develop Proposal

You are here


Chapter 6. Choose an architectural alternative

The purpose of this phase is to arrive at a decision about which alternative toimplement. We do this by providing a technique for matching therequirements determined in Chapter 4, “Gather requirements” on page 49 tothe architectural alternatives derived in Chapter 5, “Developing architecturalalternatives” on page 71.

It is recommended that this process be conducted in the same workshopenvironment that was used to select architectural alternatives. This keeps thecustomer involved in the process and ensures concurrence with the processand outcome.

The idea is to keep the process simple and to the point. While manytechniques could be used to determine the architecture for your e-businesssolution, the approach given in this phase has proven to be successful timeafter time.

Experience has shown that, if you have reached this phase, very fewadditional issues will be raised because most issues will have come out of thearchitectural alternatives and will have been resolved during that phase.However, if additional issues do surface, they will need to be resolved.Ideally, these issues should be resolved during the session by the technicalexperts present or, at a minimum, they should be clearly understood anddocumented. Follow-up should be accomplished as soon as possible. In thiscase, the final selection may be made with a contingency on the finalresolution of an issue.

6.1 Overview of choosing an architectural alternative phase

Figure 26 on page 112 illustrates the high-level approach presented in thischapter.


Figure 26. Overview of the choose architectural alternative phase

6.2 Building a matrix of requirements to alternatives

A matrix that matches high-priority requirements (as defined in Section 4.6.5,“Prioritize requirements” on page 67) against the architectural alternatives (asdefined in Chapter 5, “Developing architectural alternatives” on page 71)creates a tool by which an alternative can be chosen. It is important to focuson just the high-priority requirements (and perhaps a few of medium priorityones), rather than permitting dozens of requirements to obscure the process.

Perhaps studying an example of a Requirements to Architectural Alternativesmatrix is the best way to understand this process. Table 25 on page 113shows an example of how this might be presented to the customer. Note that

Building a Matrix of Requirementsto Alternatives

Grading the ArchitecturalAlternatives

Selecting the Best Alternative

Insuring Customer Commitment


Architectural Alternatives IdentifiedGather

Requirements

DevelopAlternatives

ChooseAlternative

SelectComponents


the requirements shown are hypothetical; you would use the requirements listyou generated.

Table 25. Requirements to architectural alternatives

6.3 Grading the architectural alternatives

The process of grading the alternatives involves making an assessment ofhow well it meets each requirement. This grading process is best kept simpleby using a plus (+), neutral (o), or minus (-) symbol for each cell in the matrix.

Table 26 provides a definition of the suggested symbols used during thegrading process.

Table 26. Definition of grading symbols

Keeping the process simple has proven to be an effective approach. This iswhy the simple plus, neutral, and minus system was recommended in Table26. Other techniques for grading, such as a weighting scheme (for example, 1

Requirements Arch.Alt. 1

Arch.Alt. 2

Arch.Alt. 3

An aggressive production deliverable date

Maintain or improve performance

Construct for growth and scalability

Allow for platform independence (useindustry standard interfaces/protocols)

Lower product ownership costs

Front-end redesign

Reduce dependencies on currentmiddleware product sets

Transfer skills and train customer people

Position for Internet

Symbol Description

+ This indicates that the requirement is met and exceeded in some ways.

o This indicates that the requirement is met.

- This indicates that some aspect of the requirement may not be met.

Choose an architectural alternative 113

to 10), have been tried. However, the simple approach has proven moresuccessful. Customers can usually make or accept decisions between +, 0, or- without too much trouble. A weighting system tends to generate much morediscussion without much additional benefit.

6.3.1 Weighing alternatives against requirementsYour team must look at each of the requirements and determine the degree towhich each requirement can be achieved by the architectural alternatives.This process depends on the collective experience of your team in thearchitectures being considered and the technologies involved. Theinformation provided in Chapter 5, “Developing architectural alternatives” onpage 71, is a basis for making some of these assessments. This is a complexarena; seek out skilled technical people to assist you.

Table 27 gives examples of how you might weigh the architecturalalternatives against the hypothetical requirements we have provided. Itshows considerations that must be taken into account.

Table 27. Examples of what to look for in architectural alternatives

Requirements Then look for an alternative that...

An aggressive productiondeliverable date

• Takes advantage of reusable components.• Possesses technologies that are proven.• Provides easy integration to enterprise data and

applications.

Maintain or improveperformance

• Meets your end-to-end response time budget (forexample, HTTP protocols are not efficient forhigh-volume interactive activity).

• Does not result in a great deal of network traffic tocommunicate with a client (remember, you have nocontrol over Internet performance).

• Will work within the physical limits of the clienthardware that is present (a customer with a largeinstalled base of 486 processor machines with 16 MBof memory is not a candidate for a large and complexJava application).

Construct for growth andscalability

• Scales vertically and horizontally allowing for maximumgrowth if needed (you may wish to consider the costand difficulty of accomplishing this scaling).

Allow for platformindependence (useindustry standardinterfaces/protocols)

• Minimizes the use of proprietary technologies.• Minimizes the use of non-standard protocols and

interfaces.• Uses a programming language that will allow the

greatest amount of platform portability.


6.3.2 Grading sessionNow comes one of the more exciting phases of the process: Trying to narrowthe architectural alternatives to one that best meets the businessrequirements.

At this point, it might be helpful to quickly review each of the requirementswith the customer. It is important that you continue to maintain consensuswith the business requirements throughout this process. One of the mosteffective ways of accomplishing this is to take every opportunity to reviewinformation that has been gathered to make sure everyone is still inagreement.

Likewise, reviewing the architectural alternatives provides an opportunity toensure that the customer is familiar with the approach being proposed andunderstands the technologies being explored. If issues or concerns areraised, they need to be addressed.

Lower product ownershipcosts

• Allows for easy maintenance.• Permits new functions to be easily added without

disrupting other functions.• Facilitates the easy distribution of code to users.• Accommodates an easy migration from one release to

the next.• Allows for the easy management of operations.

Front-end redesign

• Provides sufficient widgets available to design thedesired user interface (in an e-business solution, it issometimes difficult to match capabilities found in someof the client/server power tools).

• Has the capacity to provide new capabilities not used orimagined before.

Reduce dependencies oncurrent middlewareproduct sets

• Provides an alternate way of accessing enterprise dataand logic without relying on existing middleware to beutilized.

Transfer skills and traincustomer people

• Takes advantage of existing customer skill sets.• Has concepts and features that are easier to learn than

other alternatives.

Position for Internet• Works equally well over Internet versus intranet (for

example, RMI may require special considerations whengoing through a firewall).

• Best supports the security requirements.

Requirements Then look for an alternative that...


Although the grading process should take place rather quickly, there is anopportunity for discussion of particular requirements or architecturalalternatives. While the workshop leader should keep this discussion to aminimum, it does provide the opportunity to further understand thecustomer’s view of a requirement, which may result in reprioritizing or eveneliminating the requirement.

6.3.2.1 Example architectural alternatives to be gradedTo illustrate the process of grading a set of architectural alternatives, assumethat you have a customer who wishes to provide his or her customers with away of accessing enterprise data. Your customer wishes to do this because itwill help generate more business. The requirements gathered in the SolutionWorkshop are those presented in Table 25 on page 113.

As shown in the following figures, let us say that three alternatives wereconstructed to address this set of customer requirements.

Figure 27. Example: Architectural alternative 1

In Figure 27, a Java application is developed and installed on each clientworkstation. This Java application performs all of the business logic as wellas the presentation logic. It only passes information on the data it wishes (forexample, SQL statements) to the server.

Client Network Server ConnectorsEnterpriseData and

Application

Standalone Javaapplication (nobrowser)Presentation Logic andBusiness Logicco-resident on clientworkstation

Simple retrieve andforward datasystem

Data housed indatabase suchas DB2



In Figure 28, a standard browser is the only additional code added to theclient workstation. Servlets on the server perform all the business logic, andthe servlet generates the HTML that is sent to the browser. All of theinteraction between client and server is performed via HTML.


Figure 29 illustrates a form of hybrid between the two. A browser on the clientworkstation is used along with applets that perform the presentation logic.Java Application Code on the server receives data sent from the applet,performs whatever business logic is called for, and then performs the dataretrieval. The information is sent back to the applet on the client using theprotocol selected for distributed object communication.

Client Network Server Appl.Logic Connectors

EnterpriseData and

Application

Browser only (noresident Java codeon workstation

Servlet performsbusiness logicServlet initiatesdata retrievalServlet generatesHTML


Client Network Server Appl.Logic Connectors

EnterpriseData and

Application

BrowserApplets to performpresentation logic

Server sends Applet tobrowserSerlet performs business logicServlet initiates data retrievalServlet passes results toApplet on browser



6.3.2.2 Example of grading the alternativesTable 28 provides an illustration of this grading process.

Table 28. Customer grading of requirements to architectural alternatives

6.3.2.3 Explanation of the grades assignedTo illustrate this process more fully, Table 29 on page 119 explains thethinking that went into the grades that were assigned to each alternative foreach requirement.

Requirements Arch.Alt. 1

Arch.Alt. 2

Arch.Alt. 3

An aggressive production deliverable date - + o

Maintain or improve performance + - o

Construct for growth and scalability + + +

Allow for platform independence (useindustry standard interfaces/protocols)

+ + +

Lower product ownership costs - + +

Front-end redesign + - +


+ + +

Transfer skills and train customer people - o +

Position for Internet - + +


Table 29. Explanation of grades assigned to example alternatives

Requirements Comments

An aggressive productiondeliverable date

Alternative 1 was graded a minus rating because ofthe time required to deploy the code to all of thecustomer site, plus a slight lack of experience incoding Java applications.Alternative 2 received a plus rating because ofexisting HTML skills, along with the centralizeddesign.Alternative 3 was given a neutral rating because ofa lack of strong Java programming skills, but thecentralized design offset that to produce a neutralscore.

Maintain or improve performance

Alternative 1 received a plus rating because aclient-side application can be developed tooptimize the network traffic and provide aresponsive interface.Performance in this scenario might be an issue ifthe workstation is limited in its capacity to run theapplication. The customer allowed an assumptionto be made that the workstations would be ofsufficient capacity.Alternative 2 received a minus rating becauseHTML can prove to be a heavy network protocol,particularly when a feature-rich interface is desired,as was the case with this customer.Alternative 3 received a neutral rating becausealthough it uses a client-side application (anapplet), it takes time to download that applet at thestart of the session.

This example is based upon a real customer’s experience. Many of thedetails of the customer environment have been omitted for the sake ofbrevity, although such details were used in the design process. When youwork with a real customer on an e-business solution, you will factor inhundreds of small details, just as we did on this design.

Note


Construct for growth andscalability

All three received a plus rating, although alternative1 might very well have received a minus were it notfor the assumption that client workstations will be ofsufficient capacity to run the application. Becausealternative 1 has its business and presentationlogic located in the application, that applicationcould grow quite large. Older workstations, orworkstations with limited memory or processingpower, might pose a problem as to how far theapplication on the client can scale.Alternatives 2 and 3 have presentation logic andbusiness logic separated. This permits the serverside to scale vertically to the limits of the platformon which it runs, and then horizontally by addingmore servers.

Allow for platform independence(use industry standardinterfaces/protocols)

All three alternatives employ non-proprietaryprotocols (IP) and interfaces (Java); so, all threereceived plus ratings.

Lower product ownership costs

Alternative 1 received a minus rating on this simplybecause of the cost of deploying and maintainingthe code on all of the remote workstations.Alternatives 2 and 3, which employ a centralizeddesign, eliminate this concern.

Front-end redesign

The customer’s desire was to present a very usefulgraphical interface. Alternative 2 was given aminus because it is based on HTML. Highlyinteractive and rich graphical features are difficultto provide with HTML. Therefore, alternatives 1and 3, which use a client-side application, canachieve better results for this requirement.


All three alternatives provide a way of reducing thedependency on the current middleware products.Therefore, all were given a plus rating.



6.4 Selecting the best alternative

Once the grading exercise has been completed, experience shows that it israther easy to select a “winner”. The process is not scientific; rather, by thetime the customer has graded the alternatives, one alternative tends tosuggest itself.

In the example provided in Table 28 on page 118, the three hypotheticalalternatives come out like this: Alternative 1 received five positive marks,alternative 2 received six, and alternative 3 received seven. That wouldsuggest alternative 3 is the winner.

Sometimes, it is useful to weigh the negatives against the positives and comeup with a net assessment for the alternative. For example, if a negative markoffsets a positive one, and a neutral mark has no value, alternative 1 ends upwith a net +1, alternative 2 with a net +4, and alternative 3 with a net +7. Thisreinforces the selection of alternative 3.

Finally, though we have not suggested that you prioritize requirements withinthe categories previously described (high, medium, and low), it is sometimesuseful to go back and determine which requirements, if any, carry the most

Skills transfer and train customerpeople

Alternative 1 received a minus rating because theinstallation of the application on the customerworkstations would have required some training,as well as training on how to use the application.Alternative 2 received a neutral rating because,although it has the benefit of a centralized designand utilizes an industry standard browser, it usesHTML, which restricts the ability to make theinterface as intuitive as possible.Alternative 3 received a plus because the interfacecould be made easy and intuitive due to the appletdesign. In addition, it was a centralized architectureand used the industry standard browser makingupdates and installation the easiest.

Position for Internet

Alternative 1 was given a minus rating because,apart from its use of IP as its transport protocol, itdoes very little to position the solution for theInternet.The other two alternatives make use of a browserand Java technologies (servlets and applets) thatdo a better job of meeting this requirement.



weight. For example, the requirement for a rich front-end design might havebeen the most important factor in the mind of the customer. The negativegrade for that on alternative 2 might outweigh several of the other positives.

6.5 Ensuring commitment

Following the approach outlined in this chapter should ensure commitment tothe final architecture selection by the team. If there are still outstandingissues, these should be listed and specific action items developed to addressthem. Commitment to the selected architecture is essential before continuing.If this requires refinement of requirements or of the architectural alternatives,repeating some previous steps may be necessary.

Perhaps it bears repeating: Designing e-business solutions is an iterativeprocess.


At this point, you should have selected an architecture for your e-businesssolution, documented the architecture, and gained customer commitment tothe selected architecture.

• Have the requirements changed by the customer since you havecompleted this phase? If they have, you must make the appropriateupdates and validations.

• Have you completely documented the selection process and agreed-toselection?

• Have you made any assumptions that have not been agreed to by thesponsors? If so, you must gain sponsor agreement on those assumptions.Based on results, you may need to go back to previous phases.

• Do all open issues have agreed-to owners, action plans, and dates forresolution assigned?

• Is the sponsor committed to the selected architecture?

If you can answer yes to each question, move on to Chapter 7, “Selectingtechnologies” on page 125; otherwise, you may need to go back and repeatsome of the steps in earlier phases.

Figure 30 on page 123 illustrates the process steps.


Figure 30. Checkpoint: Choosing architectural alternatives

Develop Proposal

Gather Requirements



Select Technologies

You are here


Chapter 7. Selecting technologies

For a successful technology, reality must take precedence over publicrelations, for Nature cannot be fooled.- Richard P. Feynman

This chapter will direct you in selecting the technologies to be used indeveloping an e-business solution. The following set of starting assumptionsis being made:

• The requirements being addressed by the existing application areunderstood and have been validated as being applicable for currentbusiness needs.

• Migration to an e-business solution is appropriate.

• An application-specific architecture has been or is in the process of beingchosen.

This chapter classifies the technologies according to the IBM ApplicationFramework for e-business. For each category, there is a descriptive sectionfollowed by a table identifying some representative products and thetechnologies they support.

In any category, the particular selections and details should be treated asbeing for illustrative purposes only. Since this is a rapidly-changing area,details get out of date very quickly. The reader should consult the relatedWeb-site or product literature from the relevant vendors.

7.1 The framework and the application topology

For the purposes of this chapter, we used both the IBM ApplicationFramework for e-business architecture diagram and the building blockdiagram shown in Figure 31 on page 126. Some of the categories are morevisible in the building block diagram than in the application frameworkdiagram. Refer to Chapter 2, “Solutions architecture” on page 15, for moredetails on the concepts and figures.


Figure 31. IBM Application Framework for e-business architecture

7.2 Classifying technologies

We have chosen to use the IBM Application Framework for e-business as theframework for this book. This section describes the framework categories andthe key influencing factors.

7.2.1 Framework categoriesThe IBM Application Framework for e-business provides the following set ofcategories within which the technologies can be classified.

Client

The e-business client is based on a thin client, Web browser/Java appletmodel that enables universal access to Framework services, and on-demanddelivery of application functionality.

Web application server

Security

System Management


EnterpriseData and

Application

Web Application Server Architecture

DevTools

e-business Application Services

Web Application ProgrammingEnvironment

System Management

Application ServerSoftware

ApplicationIntegration

Network Infrastructure


This server provides a platform for e-business applications. At a minimum, itincludes Web services and an execution environment for server sideelements of the application.

Network-based infrastructure services

This identifies core infrastructure services. This ranges from base networkservices, such as TCP/IP, to directory and security services whosecapabilities can be accessed via open standard interfaces and protocols.

Application integration services

These are services providing access to existing data and applications.

Web application programming model

The programming model is provided by the Enterprise Java programmingenvironment.

e-business application services

These are services that provide higher-level application domain-specificfunctionality to facilitate the creation of e-business solutions.

Systems management

These services accommodate the unique management requirements ofnetwork computing across all elements of the system including users,applications, services, infrastructure, and hardware.

Development tools

A set of tools to create, assemble, deploy, and manage applications.

7.2.2 Identifying key technology selection influencesIn the development of any specific architecture, there will be a number of keyfactors that have an overall effect on the selection of technologies. Thesemust be identified and the combined impact assessed before the selectionprocess begins.

Three relevant examples are shown below:

• Non-functional requirements: For example, a requirement for platformindependence and standards-based infrastructure services

Selecting technologies 127

• The existing technical environment: How this is leveraged is particularlyimportant in the context of a migration.

• Technical architecture goals for the target architecture: A key decision thatmust be made early is the choice of the component model, for example,Sun’s Enterprise Java Beans, OMG CORBA, Microsoft COM, etc. In somecircumstances, there may be more than one component model involved. Inthis case, it may also be necessary to select bridging technologies.

Such factors act as global filters on the selection of candidate technologies.This filtering, in turn, flows on to the choices of products that implement thesetechnologies, the application development model, the choice of developmenttools, etc.

7.3 Client

From the perspective of client technology choices, the IBM ApplicationFramework for e-business has two significant features that distinguish it fromthe client technologies in a traditional client/server architecture.

• The server-centric nature of the architecture and the role of the network asthe primary delivery mechanism for most application services. Thee-business framework can be considered an evolution of a distributedmulti-tier client/server model.

• The thin-client model with its potential for major reductions in clientsoftware management efforts.

At this point in time, the most common e-business client platform is aWeb-browser.

However, in any specific business context, the process of choosinge-business client technologies should involve the consideration of applicationclient requirements, the capabilities of the device(s) presenting the userinterface, and the supporting network infrastructure.

7.3.1 Choosing the client technologiesThe final client technology decisions will be based on a complex set ofinteracting factors. In many cases, a browser-based solution may be the bestchoice, but trade-offs may be involved. These factors are summarized below:

• Client Device Capabilities

• Presentation

• Computing resources, such as CPU/Memory/Disk


• Client Device Type

• Pervasive devices (PDA, Mobile Phones, etc.)

• PC (Desktop/Laptop)

• Network Computers

• Supporting Software Requirements

• Standard platform software

• Pre-installed third party

• Dynamically downloaded components/software

• Application client side persistence requirements

• Client Application Type

• Internet-enabled GUI Applications - These can use the Internet andmay utilize browser technologies, but a permanent connection is notrequired. A Microsoft Office-based application is one example of thicksoftware and hardware.

• Network GUI Applications - This is a network-dependent but clientplatform independent application with thin-medium hardware and,typically, thick client in the software sense. An example is the classicJava Network Computer vision.

• Browser based - This is network dependent but markup languagedriven. Such applications may be browser-specific or browser-neutraland may or may not involve downloadable components. For example,Microsoft Internet Explorer and Netscape Navigator.

• Specialized, such as Palm Pilot, Mobile Phones, and PDET - Theseapplications specifically target devices that are relativelyresource-constrained, usually involve proprietary platforms, and arefrequently wireless in operation.

7.3.2 Markup-based clientsAs an e-business client, the browser-based solution is, in principle, an idealtechnology. In practice, however, the limitations of HTML, browser differenceswith respect to the interpretation of HTML and related standards, and generalInternet performance problems have restricted the richness of a userinterface that can realistically be developed

The success of Extensible Markup Language (XML) has led to the creation ofa series of related standards and many proposed standards.

These recent standards have introduced the following possibilities:


• An extensible form of HTML with the potential for more powerful userinterface capabilities

• A clear separation of presentation and data based on standard definitions

• The ability to develop user interfaces that are device-independent

• Applications that can dynamically adapt the user interface to thecapabilities of the presentation device

• The ability to perform this processing at either the client or the server orboth

As a consequence, the browser itself is becoming a more general mark-uplanguage-rendering mechanism. Specialized forms are starting to be usedwithin devices, such as Personal Digital Assistants (PDA) and mobile phones.

7.3.3 Illustrative examplesTable 30. Client technology examples

Product TechnologiesSupported

Notes

StandardDesktopPC/Laptop

Any

This product has been included forcompleteness. In an enterprise context,Desktop PCs are usually physically fixed andpermanently LAN connected.Laptops are typically mobile, requiredisconnected operation, and need both LANand dial-up networking. They are usually lesspowerful than the equivalent desktop.In the context of this discussion, both classesof client can support the technology forvirtually any e-business client requirement.

IBM - NetworkStation

HTML,HTTP,Java 1.1 SDK,JavaScript

The IBM Network Station is a family of low-costcomputers that provides simultaneous accessto applications throughout the enterprise aswell as on the Internet, intranets, andextranets. Other names used to describe thisclass of computer are Network Computer andJava station.


Netscape -Navigator

HTML,HTTP,HTTPS,Java 1.1 SDK ,JavaScript(ECMA 262),IIOP,IMAP4,MIME

Between the two, Netscape Navigator andMicrosoft Internet Explorer commandapproximately 80 percent of the Web browsermarket share.Both browsers run on multiple platforms. Bothbrowsers are distributed free with a bundle ofInternet-related or capable products. Forexample, e-mail, HTML Editor, News reader,Multi-media support, etc.Microsoft -

Internet Explorer

HTML,HTTP,HTTPS,Java 1.1 SDK,JScript (ECMA262),VBScript,XML/DOM/XSL,ActiveX

3Com - PalmPilot

e-mail,HTML3.2(subset),HTTP,WML

The Palm Pilot is a wireless electronicorganizer. Sometimes called a Personal DigitalAssistant (PDA) .This is an example of an emerging class ofspecialized wireless-based computingdevices.There are many business scenarios from thestock market floor to warehouse inventorycollection where such a device has a role toplay as an e-business client.

Nokia - 7110 e-mail,WAP/WML

A recent Gartner Group report observed thatthe adoption rate of mobile phones is currentlythree times that of the Internet (itselfconsidered an example of phenomenalgrowth).Given the significance of the phone inbusiness terms, the introduction of Internettechnologies in the form of specializedbrowsers, email support, etc. makes themobile phone an e-business client contenderthat should not be ignored.


Notes


7.4 Web application server

The emerging model of a Web application server is remarkably similarbetween the various vendors. These models usually involve five mainarchitectural elements.

• Internet/Web Services

• Application Services

• Integration Services

• Management Services

• Application Development Services

In the IBM Application Framework for e-business, the Web Application Serveris generally described as including Internet/Web Services and ApplicationServices. The other elements are shown as separate architectural layers. Forconsistency with the framework, these other elements are covered in theirown sections.

7.4.1 Internet/Web servicesThese services allow any form of client software to make requests forapplication services over the Internet. This form of client does not requireadditional middleware, software, etc. other than that normally associated withInternet usage. The main protocol that must be supported is HTTP.

Some application servers provide built-in Web services, that is, they workstand-alone. Many also provide Web server connectors that allow integrationwith existing Web Server environments.

There are pros and cons to this approach. It probably keeps more optionsopen to keep the two as separate servers. This allows for separate tuning andindependent evolution, recognizes that there are a large number of existingWeb-server products in use, and allows non-Internet clients to be handleddirectly by the application server.

7.4.1.1 Standard Internet servicesSupport for the basic Internet protocols, such as HTTP, FTP, e-mail, SSL, etc.

7.4.1.2 Web server connectorsProvision of components that allow seamless integration with common WebServers, such as Microsoft, Netscape, and Apache. The product may alsocome bundled with its own Web server and/or support multiple proprietaryWeb Server APIs, such as Microsoft’s ISAPI or Netscape’s NSAPI.


7.4.1.3 Transactive content supportTransactive content is a term coined by the Forrester Group. It describes aWeb application involving transaction processing, interactivity, and richcontent linked by a high level of personalization based on profile informationkept about each user.

Such an application requires support for features, such as personalization,collaboration, search engines, media streaming, content push, etc.

7.4.1.4 Additional featuresThese include vendor-specific features, such as Content Management, LogFile Analysis, etc.

7.4.2 Application servicesApplication services can be considered to be a set of cooperating softwareprocesses that act as an execution or execution management environment forthe server side elements of application systems. The focus is onperformance, robustness, scalability, etc. at mainframe-quality service levels.

7.4.2.1 Component modelMost application servers will be based on component models, such asCORBA, Enterprise JavaBeans, or COM. Servers based on a componentmodel are more valuable than those that merely support such a model.

7.4.2.2 Standards-based infrastructure servicesThe application server commonly requires the existence of standards-basedinfrastructure services to support features, such as transactions etc. SeeSection 7.5, “Network-based infrastructure services” on page 136.

7.4.2.3 Scalability and reliability featuresFeatures, such as multi-threaded operation, support for the clustering ofservers, pooling of connections and threads, load balancing and fail-over,caching, state management, etc. are vital to scalability, reliability, andperformance.


7.4.3 Illustrative examplesTable 31 shows examples of Web application server technology.

Table 31. Web application server technology examples


Notes

IBM - HTTPServer

HTTP,HTTPS,SSL,Servlets,MIMS

This product is included as a base product.This is an instance of a standard Web server.Such a server represents the bare minimumrequirements for an e-business server.This product is based on Apache, acollaborative open source project

Microsoft -InternetInformationServer

HTTP,HTTPS,SSL,ASP,ISAPI,MIME

Microsoft IIS and Netscape Enterpriserepresent typical enterprise-level commercialWeb servers.This class of server usually comes bundledwith many additional features over and abovethose provided in a basic Web Server.They support an extensive but vendor-specificserver API for dynamic HTML generation.These servers are usually part of a family ofInternet server products. Additional supportingservers, such as Proxy servers and Indexservers, are some examples.

iPlanet,Netscape -EnterpriseServer

HTTP,HTTPS,SSL,LDAP,Servlets,MIME


IBM -WebSphere

HTTP,HTTPS,SSL,HTML,XMLServlets,JSP,Corba,Java Devt.,EJB,XA Support,Tivoli Support,MQSeries The four products from IBM, Sun, Inprise, and

BEA represent the current state of the art inWeb Application Servers.Each of these products is based on one ormore of the standards-based Componentmodels (Sun EJB, OMG Corba).These products provide (at least) enterpriseapplication execution support in addition tohighly-tuned Web and Internet services.Each product is usually released in threeflavors. For example, Standard, Advanced,and Enterprise.Most of these products also providemanagement, application development, andintegration services.

iPlanet,Sun -NetDynamics

HTTP,HTTPS,SSL,HTML,Servlets,CORBA,Java Devt,EJB

Inprise -ApplicationServer

HTTP,HTTPS,SSL,HTML,XML,Servlets,JSP,CORBA,Java Devt,EJB,JTS/OTS

BEA - WebLogic

HTTP,HTTPS,SSL,HTML,Java 2 Enterprise,Tuxedo


Notes


7.5 Network-based infrastructure services

Most application servers adopt or support one or more component models.For example, Enterprise Java Beans, CORBA, or COM.

Each of the component models defines, supports, or assumes a specific setof standard services is available from the network. The most important ofthese are Naming and Directory services, Distributed Transaction services,and Security services. Event/Notification services are also important in somekinds of applications.

The application server makes use of these services to provide anenterprise-class execution environment.

As with the component model, application services built on the standardservices of a component model are more valuable than those that merelysupport such services.

7.5.1 Illustrative examplesTable 32 shows some network-based infrastructure technology examples.

Table 32. Network-based infrastructure technology examples


Notes

IBM - e-NetworkSoftware

LDAP,DMTF CIMExtensionSchema,Browser-basedTerminalEmulation,Certificates andPublic KeyInfrastructure,VPN

IBM Networking and Communicationse-Network software products providenetworking infrastructure that can be used tobuild corporate intranets and extranets andprovide secure access to the Internet.- Host integration- Mobile and wireless solutions- Security services- Personalization and service accessadministrationThese services heavily leverage the IBMSecureWay suite of products.


7.6 Integration services

A core requirement of most e-business applications is to be able to integratewith existing enterprise applications and data sources.

This set of services allows the processes running under control of theapplication server to access data and the functionality of other systems.Adapter and connector are other terms used to describe an individualinstance of such a service. These services allow the application server tointegrate disparate sources of data.

These services are built-in to some application server products. In othercases, they constitute a product in their own right.

7.6.1 Database connectivityDirect database access is important. There should be support for at least oneof the following: ODBC, JDBC, or native database drivers.

Visigenic -VisiBroker

CORBA Orb,OTS,Naming, Events,Trader,SSL,GateKeeper,COM-CORBABridge

Visigenic (now part of Inprise) and IONA aretwo major Object Request Broker (ORB)software vendors. Both companies provideCORBA 2-compliant ORBS andimplementations of many of the standardservices defined by OMG.IBM Component Broker is an equivalentproduct, now considered part of theWebSphere Family of products.

Iona - Orbix

CORBA Orb,OTM,Naming, Events,Notification,Trader, Security,WonderWall,COM-CORBABridge

IBM -ComponentBroker

CORBA ORB,LIfeCycle,Naming, Events,Security,Transactions,Persistence,Connectors


Notes


7.6.2 Packaged application API integrationPackaged applications, such as SAP, JD Edwards, and PeopleSoft, provide aprogramming API. Some application servers have already built connectors tothe most common of these applications, such as Pre-built SAP. PeopleSoftadapter components can be purchased for NetDynamics and Sapphire/Webas part of these products.

7.6.3 Middleware integrationProducts, such as Tuxedo, MQSeries, CICS, Notes, Mail, and so on, providesupport for connectivity.

7.6.4 Component model integrationComponent models, such as Enterprise JavaBeans, CORBA, and COM,provide support for communication with alternative models.

7.6.5 Custom integration service development kitMost products provide a program development kit/environment that allows thedevelopment of custom integration services. Custom integration connectorscould be any of the types described previously or some hybrid form.

7.6.6 Application integration approachesThe previous section described the kinds of integration technologies that arecommonly provided in a Web Application server. In selecting an appropriatetechnology, a number of key questions must be addressed:

• At what level is integration of the e-business application with existingexternal data and applications to take place? This might be dictated by thearchitecture or technologies of the existing system and/or by therequirements of the e-business application.

• How will the external data and applications be represented within thee-business application programming model?

• How much additional development effort is required to bridge therepresentation introduced by the integration technology and therepresentation required by the e-business application?

For example, from a technical perspective, the use of messaging may be theonly practical solution to a specific integration requirement. However, if thee-business server developer is expected to be working with Enterprise JavaBeans representing business objects, the level of abstraction involved inmarshalling and unmarshalling message data is very low. In this case, it ishighly likely that some form of abstraction layer will need to be developed in


order to hide this low-level activity. This could be a significant developmenteffort in its own right.

The IBM Application Framework for e-business has identified a set ofcategories that present the alternative approaches. These are presented inorder of increasing isolation from the underlying integration technologies andtheir ability to support higher levels of abstraction.

Figure 32 shows application integration approaches.

Figure 32. Application integration approaches

• Connectors are gateway software elements that provide linkage betweenthe Web application server and services that are reached through the useof application-specific protocols.

• Application messaging services provide message-based communicationbetween applications with assured delivery of messages.

• Business process integration and workflow services extend the basemessaging services with message brokering, intelligent message routing,and message translation.

• Component integration services enable object wrapping of existingapplication logic written in any language. As a result, existing applicationlogic is extended to object-oriented environments.

ApplicationMessaging

Connectors

Business ProcessIntegration/

App. W orkflow

ComponentIntegration

Integration

Connection


7.6.7 Illustrative examplesTable 33 shows integration technology examples.

Table 33. Integration technology examples

7.7 Web application programming model

The application programming model describes the conceptual frameworks,classes of objects, services, and features that form the environment withinwhich the developer works during the course of application development.

7.7.1 Influence of the component modelThe choice of a component model has a major impact on the applicationprogramming model.

In order to manage execution, the Application Server may also require thatapplication objects be developed within a framework specific to that server.This server framework is built upon features provided by the componentmodel.


Notes

IBM - WebSphereEnterprise

RDBMS,CICS, Encina,CORBA, IMS

The major Web Application server vendorsprovide a suite of integration capabilities. IBM- WebSphere calls these Connectors, Sun -NetDynamics calls them Platform AdapterComponents (PAC), while BlueStone -Sapphire/Web calls them System IntegrationModules (SIM)

Sun -NetDynamics

RDBMS,PeopleSoft,SAP,PAC SDK

BlueStone -Sapphire/Web

Native, ODBCRDBMS,SAP,Tuxedo,MQSeries

IBM - MQSeries JMS,XML

While these two products are completelydifferent, they both aim to present a unifyinginfrastructure layer that targets integrationacross multiple kinds of data sources orsystems.MQSeries uses a generic messaging model.OleDB provides a series of COM interfacesrepresenting a generic data source.

Microsoft -OleDB COM, ADO


The combination can create a significant initial learning curve for a developerand a dependency of a vendor-specific framework. The trade-offs betweenlearning curve, vendor dependency, and productivity gains have to beconsidered. The decisions made here directly influence the choice ofdevelopment tools.

7.7.2 Influence of architectural design patternsA specific technical architecture usually establishes patterns of assembly ofthe elements in the component model and any vendor-supplied frameworks.While these decisions are more about architecture design than selectingtechnologies, they do further shape the application programming model asthe developer sees it.

For example, a design might utilize a Model-View-Controller patternimplemented by particular combinations of the Servlet (Controller) and theJSP (View) elements on the Web Server. These elements communicate withbusiness objects implemented using Enterprise Java Beans via anabstraction layer based on the Command design pattern implemented asJavaBeans.


7.7.3 Illustrative examplesTable 34 shows some programming model technology examples.

Table 34. Programming model technology examples

7.8 e-business application services

These services provide application domain-specific functionality thatfacilitates the development of e-business applications. Examples of suchservices range from IBM San Francisco, where these are implemented aslayers within the architectural framework, to standards proposed byindustry-specific consortiums, such as Open Applications Group, where thegoal is to facilitate integration between organizations.


Notes

OMG - Corba

ORB 2.0,IIOP,OTS,Naming,Security,Events

Each of these retransmissions has produced amajor technology software platform.These platforms will shape the very core ofsoftware development, particularly e-businessapplications, for many years to come.It is not possible or appropriate to attempt todescribe the scope of these platforms in thisbrief summary table.OMG is a standards-based effort with its rootsin the distributed object programming model.Microsoft is a component-based approach withits roots in Windows-based clients.The SUN Java 2 Enterprise is aplatform-independent component modelexplicitly developed for network-basedapplications.

Microsoft - COM

COM,Automation,ActiveX Controls,OleDocuments,Active ServerPages, OleDB,MTS

Sun - Java 2Enterprise

Java 1.2 SDK,Enterprise JavaBeans 1.0,JNDI, JMS, JTA,JDBC, RMI/IIOP


7.8.1 Illustrative examplesTable 35 shows e-business application service technology examples.

Table 35. e-business application service technology examples

7.9 Systems management

Systems Management services have three main objectives

• To reduce operations costs

• To increase availability, and improve performance and quality of service

• To manage risks resulting from operational failures


Notes

IBM - SanFrancisco

Java Frameworks

San Francisco is a heavily layered softwareproduct.The upper two layers of this product are aimedat application domains.The Common Business Objects layerintroduces extensible objects, such asCompany, Business Partner, and Address,which are common across business domains.The Core Business Process Layer providesbase implementations of behavior for specificbusiness domains, such as General Ledgerprocesses.The primary goal of these layers is developerproductivity through reuse.

OpenApplicationsGroup - OAGIS

OAGIS,XML

The Open Applications Group is a non-profitconsortium that aims at cost-effectiveintegration of key business applicationsoftware components for enterprise andsupply chain functions for end-userorganizations.To this end, the group has developed a modelof application integration points for commonbusiness processes. It has also defined theprotocol and data definitions for participants insuch a process. XML is the basis for one of theformats supported.The goal here is to facilitate integrationbetween applications.


The e-business approach has addressed a key problem in client/serversolutions - client application software management. However, it has asignificantly-increased dependency on the network. As a consequence,system management for e-business requires an extra focus on the followingareas:

• Managing the increased security risk

• Increased demands with respect to availability and scalability

• Ensuring adequate application performance

• Greatly reduced costs. Compared with a typical enterprise client/serverapplication, an e-business application must, potentially, cater to a largeInternet audience. Most Internet users expect applications to cost nothing.

7.9.1 System management modelThe Frameworks systems management model defines a set of managementfunctions to be applied at each layer of the application stack. As shown inFigure 33, the application stack consists of four layers, each of which need tosupport the broad set of management functions shown on the right side of thefigure.

Figure 33. System management model

Although these management requirements existed for client/server systems,e-business applications add a new dimension to many of the problems. Asmentioned previously, most of these management functions are due to thefact that e-business puts much more focus on the network and the server.This is a result of the need to ensure application availability anywhere as wellas the interdependence between organizations.

Applica tion"Stack"

M anagem entFunctions

Deploym ent

A va ilab ility

Opera tions &Adm in is tra tion

Security

Application

M iddleware

S ystem

N etwork


For example, when deploying an Internet e-business application, pieces ofthe application are distributed to multiple locations; components may bedeployed not only at the hosting site but also on customers’ and suppliers’sites. Due to this distribution of function, availability is hard to manage sincethe connection to partners and customers is through the Internet.Performance problems due to bandwidth bottlenecks or availability problemsdue to improper server configuration or node failure can bring business to astandstill.

Operations and administration requires a collaborative effort betweendisparate organizations that may or may not have any formal relationships.The security model changes the most between client/server and thee-business model. It is not only critical to safeguard information assets butalso the privacy of all parties.

7.9.2 Cross-enterprise systems managementAs described in the preceding paragraphs, there is a definite need to manageresources between organizations. Companies are forced to rely on systems,networks, and people that they do not control and that do not necessarilyfunction together.The application framework extends the integratedenterprise systems management environment to span company boundariesacross the Internet. This is termed Cross-Enterprise Systems Management.


7.9.3 Illustrative examplesTable 36 shows systems management technology examples.

Table 36. Systems management technology examples


Notes

Tivoli Systems-Tivoli

WBEM standards,CIM, DMIAMS, ARM,SNMP and others

The Distributed Management Task Force(DMTF) is the industry organization that isleading the development, adoption, andunification of management standards andinitiatives for desktop, enterprise, and Internetenvironments.Over the last year, the DMTF has taken onenterprise-focused industry initiatives andstandards, such as the Web Based EnterpriseManagement (WBEM) initiative and theDirectory Enabled Networks (DEN) initiative,and pioneered the use of eXtensible markuplanguage (XML) as the transport encoding forWBEM. The basis for this collaboration andintegration is, in large part, due to the DMTF'sCIM standard, which facilitates the commonunderstanding of management data acrossdifferent management systems. CIM is animplementation-neutral schema for describingoverall management information.

See http://www.dtmf.org for moreinformation.

The Computer Measurement Group,commonly called CMG, is a non-profit,worldwide organization of data processingprofessionals committed to the measurementand management of computer systems. CMGmembers are primarily concerned withperformance evaluations of existing systemsto maximize performance (for example,response time, throughput, etc.) and capacitymanagement, where planned enhancementsto existing systems or the design of newsystems are evaluated to find the resourcesnecessary to provide adequate performance ata reasonable cost.

ComputerAssociates -Unicenter

SNMP, DMI,Some DMTF andOMG standards


7.10 The development environment

This section identifies development tools and associated softwarecomponents. There are a number of non-technical factors involved in theselection of these technologies.

For any organization contemplating migration to a new architecture, thefollowing non-technology factors must be considered.

• The current development environment, the available resources, and theassociated skill sets

• An understanding of the development roles associated with the e-businessapplication development

• The ratio of internal development to out-sourced development.

7.10.1 e-business application development team rolesThe roles being described in this section take an active part in the actualimplementation process. Roles associated with organizational Webstrategies, product decision-making, project management, and so on are notincluded.

It is important to decide whether new skill sets must be introduced into theorganization or whether various parts of development will be outsourced. Ifsuch an approach is taken, the different tools must be able to convenientlysupport the lossless two-way interchange of information necessary foriterative development.

For many of these roles, the implied skills and associated tools may not befound in the current client/server development environment. Migrating toe-business may also mean migrating a development environment anddeveloper skills.


The tables that follow give a brief description of common roles. Table 37 listscontent authoring roles.

Table 37. Content authoring roles

Role Description

Site designer

This role is responsible, at the logical level, for thecontent and functionality and how they are to berepresented by the Web site structure, thepage/hyperlink navigation design decisions, etc.The term Web site is being used in this context todescribe a set of content-related pages probablyequivalent to an application (or multiple smallrelated applications). A Web-site is a recursivestructure and can contain other Web-sites.This role is approximately equivalent to theapplication architect but must take into account thedesign differences between a Web site and a GUI orcharacter screen application. Another term used todescribe this role is Information Architect.

Page design

Responsible for page layout, visual representationof interface actions, etc.Equivalent to the role of a GUI screen designer withnew design elements introduced by the ability ofHTML to present rich linked content.The design metaphor is more like that required of anewspaper or magazine layout than forms-basedapplications (actually, a mix between the two).It is possible that Page and Graphics design rolesare played by the same person.

Graphics design

The graphics design should define the identity orlook of a Web site. The graphics elements in a Webpage play two very important roles.The visual presentation aspects are obvious. MostWeb pages use more colors, font sizes, andgraphical layout elements than a typical client/serverapplication.Not so obvious is the fact that graphic elements playthe role of navigation type features normally found instandard Windows applications (for example, atabbed notebook, menus, etc.). This is because theset of intrinsic HTML controls is very limited.There is a close interaction between the PageDesigner, Content Creation, and Graphics Designroles under the general direction of the InformationArchitect role.


Table 38. Application programming roles

Content creation

These are the people creating (primarily) textualelements of the page content. It is likely that theHTML page layouts are something more thanone-to-one mappings to client/server GUI formlayouts.Web page content also includes non-textual contentsuch as graphics, sound, etc.

Role Description

HTML programming

This role involves coding in scripting languages tomanipulate HTML elements and/or to dynamicallygenerate the page. While there is a possible overlapin skills with respect to the scripting language, thegoals of client side scripting and server sidescripting are quite different.

HTML programming (client)

Client Side Scripting aims at implementinginteractivity, logic, etc. in a Web page.It involves scripting, which manipulates the HTMLafter it has been delivered to the browser to createpresentation effects. These effects are oftendynamically driven by the user’s action but do notinvolve server side interaction.Typically, this is a specialist role. The specialist skillis not usually about using the scripting language assuch. It is more about achieving the desiredbehavior in a browser-neutral manner.

HTML programming (server)

This role primarily involves scripting, which takesdata from components, data sources, etc. and usesit to dynamically generate part or all of the HTMLpage. This page is then sent to the browser.The programmer has to understand HTTP protocolbasics and the proprietary generation process inaddition to the actual scripting language. Thisscripting language may or may not be the same asthat used for client-side scripting.

Role Description


Component developer

The use of components, such as COM/ActiveX,CORBA, Enterprise, and standard JavaBeans, isbecoming the cornerstone of contemporaryapplications development, and the benefits applyequally in e-business applications. Components canbe used to implement black-box chunks of visualand non-visual functionality on both the client andthe server side.

Component developer (client)

It is possible to bring an HTML-based user interfaceto the level of sophistication of a typical client/serverapplication using component, such as ActiveXcontrols or Java Applets.These components can be visual or non-visual, butthey represent functionality that executes in theclient environment.Such components also provide a way of providingfunctionality to tools used by non-programmers,such as page designers.At present, heavy use of client-side components forthis purpose is usually avoided.This is primarily a result of concerns over downloadperformance, lack of a cross platform capability,and/or the difficulty of ensuring the appropriate levelof support in client/browser platforms.

Role Description


Table 39 lists application assembly and management roles.

Table 39. Application assembly and management roles

Component developer (server)

The use/development of server-side components isa major growth area within e-business applicationdevelopment.These components can represent businessfunctionality or can be used to dynamically generateHTML at the server.There is a special class of server-side componentscalled design time components. These componentsallow visual composition at design time in thedevelopment environment in a manner similar tocurrent GUI development tools.At run time, they emit a combination of script andHTML to achieve the desired application behavior.The development of server-side componentsrequires OO design and programming skills.These might be Microsoft COM components orplatform-independent counterparts, such as JavaBeans, Enterprise JavaBeans, or CORBAcomponents.It is also possible to using COM/Java orCOM/CORBA bridging technologies to enable thecombined use of such components where this isappropriate.

Role Description

Content management

This is an emerging role.Internet and Web applications will introduce a largeamount of additional content. This content will differin form from the traditional business data that isusually stored in a database.This data will need to be named, stored, cataloged,and maintained by someone.This will also include the management of links andcontent shared between and across applicationparts.

Role Description


7.10.2 Choose the right tool for the roleIt must also be decided whether the development tasks are to be partitionedby role. The tools must be appropriate to the role.

For example, Visual Age for Java supports HTML page design, but, as a pagedesign tool, it is not as capable as, say, Net Objects Fusion. Furthermore, aWeb page designer is likely to find Visual Age for Java daunting, while aprogrammer will find Fusion inappropriate.

The intent of Figure 34 on page 153 is to show how the nature of the rolesaffects the choice of development tool. The specific products used in thisdiagram should only be taken as an indication of the type of tool.

Assembly/deployment

This is an emerging role.As the server side elements evolve, an approach isemerging in which the contract between the servercomponent and its execution environment(container) is expressed in some form of descriptor.An application may be assembled, described,customized, and configured after developmentusing this approach. Understanding and using thisprocess is likely to become a specialist role.This may cover a range of components, fromdynamic HTML components to server side businesscomponents based on technologies, such asEnterprise Java Beans

Application/server management

This role is will be an expansion of the role currentlyknown as Web Master.At present, the Web Master is generally responsiblefor managing Internet access services and the Webserver processes.This role can be expected to expand in scope asapplications servers expand the scope of traditionalWeb servers.

Role Description


Figure 34. Matching development tools with roles

7.10.3 Illustrative examplesTable 40 lists examples of Web application development technology.

Table 40. Web application development technology examples


Notes

NetObjects-Fusion

HTML,DownloadableClientComponents,Page Layout,Site Design andManagement

Content authoring activities are the primaryfocus of these products. The emphasis is onpage design, Web-site creation, and basicmanagement of Web sites and Webapplication assets.

Microsoft - FrontPage

HTML,DownloadableClientComponents,Page Layout,Site Design andManagement

Content AuthoringContent Assembly

& Management Applications Development

NetObjects Fusion / MS Front Page

WebSphere Studio/MS Interdev

Visual Age / JBuilder

InformationArchitect

PageDesigner

GraphicsDesigner

ContentCreation

Corel Draw

InformationArchitect

ContentManagement

Assembly/Deployment

Application/ServerManagement

HTMLScripting(Client)

HTMLScripting(Server)

ServerComponents

ClientComponents

Dephi / VB


IBM -WebSphereStudio

HTML,DownloadableClientComponentsCSS,XML,JavaScript,Servlets,JSP,Page Design,Site Design andManagement

These products support both client and serverside HTML development. They also introducemore production strength Web site publishingand management capabilities.

Microsoft -Visual Interdev

HTML,DownloadableClientComponentsCSS,VBScript,JScript,Design TimeControls,Active ServerPages,OleDB,Page Design,Site Design, andManagement

IBM - Visual AgeFor Java

Java SDK 1.1,EJB,Servlets,JSP,Page Layout,Design TimeControls,

These two products represent high-endenterprise-level Java developmentenvironments.The development of Server side componentsand full GUI Java applications is the mainfocus of these tools.While there is some Web page design orgeneration support, it is relatively simple inrelation to the previous products.Inprise - JBuilder

Java SDK 1.2,CORBA,EJB,Servlets


Notes


Part 3. Exploring design considerations

This part of the book describes our experiences with migrating the OS/2Finder application, a client/server application. This part uses the approachdescribed in part two to develop and select alternative migration approaches.We then select and explore two alternative approaches. Our intent is todescribe our experiences implementing our alternative solutions and todevelop some guidelines based on this experience.

Chapter 8, “Finder application experiences” on page 157, describes ourapplication and our design options. It also goes on to describe what wedecided to do as well as why we chose those options.

Chapters 9 through 11 describe the options, decisions, and issues we werefaced with during migration. The chapters are split along the lines of theapplication topology diagram used in Chapter 2, “Solutions architecture” onpage 15. Chapter 9, “The e-business client” on page 177, describes the clientcomponent; Chapter 10, “The Web and application server” on page 203,describes the Web/application server component, and Chapter 11,“Accessing enterprise applications and data” on page 245, describes the dataand application connectivity.


Chapter 8. Finder application experiences

This chapter describes what the selected client/server application is and thedecisions made in migrating this application. These decisions cover businessrequirements, migration, architecture, and technology selection.

The application to be migrated was a directory inquiry application called theFinder application.

The purpose of this section is to answer the following questions:

• What is the Finder application?

• What are the requirements, and what are the options for migration,architecture, and technology selection?

• What did we choose for the Finder application and why?

8.1 Why the Finder application?

The Finder application is an OS/2 client and server application. AnOS/2-based application was intentionally selected to demonstrate how it canbe effectively ported to a platform-independent application - today! IBM hasstated that it intends for their OS/2 customers to achieve platformindependence from the existing client/server environment through IBMApplication Framework for e-business. To help with this transition, IBMrecommends solutions that exploit all or most of the key technologies of theApplication Framework for e-business:

• Java for program portability

• XML for data portability

• Internet protocols for data transmission and communication control

• Browsers for the user interface

This section is structured to be aligned with the approach described in Part2 of this book. An additional subsection on migration decisions has beenincluded to increase the focus on this area.

Note


8.2 The Finder application design

The Finder application is a client/server application written in the C languageto run on OS/2 systems. The client and the server communicate using eithera TCP/IP or NetBIOS protocol. The application functionality and architectureare described in subsequent sections. The discussion is limited to thefunctions that were relevant to this project, and the low-level implementationdetails are not discussed because they would only serve to divert from thereal discussion. Figure 35 is a simple view of the Finder application.

Figure 35. Finder application

8.2.1 Application functionalityThe Finder application allows a user to create a query and execute a searchagainst organizational directory information. It is a non-update application.

These directories contain organizational details for each employee, such asname, phone number, and e-mail address. They also contain basicmanagement reporting hierarchy information. For example, details of allpeople who work for a given person, who manages a given person, etc.

Once a search has been performed, the user can zoom in on the details of aparticular person or inquire about reports to type details. Multiple consecutivequeries can be initiated, and the application supports the concurrentpresentation of multiple modeless windows, one for each result set.

This directory information is geographically distributed. There may be morethan one physical directory per geographical location, and each geographicallocation may contain different fields. For example, a directory located in SouthAfrica may have a field for motor car registration number; this field may notexist for directories in the USA. Therefore, each type of directory has its own

FindLaceyJade


set of possible search fields, and this information is retrieved from the Finderserver to the client upon client logon to the server. A query can span multipledirectories of the same type.

The directory content is maintained by a separate mainframe-basedmaintenance application.

The application also provides a form of user profile support. This allowsrecently-used settings and simple application customization details to besaved on a per-user basis.

8.2.2 Application architectureThe application is a three-tier client/server application.

• The client part of the application provides presentation, queryconstruction, and result set display.

• The server accepts a query, resolves directory names, executes the queryagainst a database server, and returns a result set.

• A third server maintains the master directories. These databases aresynchronized with local copies to improve performance and distribute theworkload; for the purposes of this exercise, this functionality is not takeninto account.

In addition to the actual directory data, the database also contains a set ofspecial tables that, essentially, contain distributed directory meta-data. Thisinformation is used to map the logical query as it is received from the client toone or more physical database tables.

Using the categorization established by the Gartner Group, the Finderapplication is classified as having a Distributed Function topology, that is, inthe (small) business domain of the Finder application, the business logic issplit between the client and the server.

The core functionality provided by the server can be summarized with threefunctions:

Connect - This validates a user against a network domain server and, if valid,establishes a connection. A significant amount of the directory metadatainformation is transferred to the client as part of a successful connection. Thisdata is transferred to the client in a proprietary binary format.

Execute Search - This takes an SQL-like string as input from the requestingclient. The server performs some mapping activity to determine the physicaldatabase table(s) involved and then dynamically builds, prepares, and

Finder application experiences 159

executes an SQL Select statement. The result set is returned in a proprietarybinary format. This format is based on the IBM DB2 SQLDA C structure.

Disconnect - This ends the session for the current user.

8.2.3 Technical architectureTechnically, the Finder application is an IBM OS/2-based clientcommunicating via TCP/IP or NetBIOS with an IBM OS/2 server process.

This server process is capable of supporting multiple concurrent clients andimplements a home-grown form of database connection pooling and themultithreading of database queries.

The server process accesses an IBM Database Manager database for thedirectory data. The data in this database is refreshed by an overnight orperiodic batch download process.

The application and technical architecture details are summarized in Figure36.

Figure 36. Existing Finder application architecture

Application

Data

Presentation

BuildQuery

GUI Logic

Request/ResponseProcessing

IBM - OS/2 /Client

ManageResults

ConfigureApplication

ConnectionManagement

IBM - OS/2 /Server

Request/ResponseProcessing

ConnectionManagement

Execute QueryPackageResult

Database Server

IBM - Database Manager

Application


8.3 Business requirements for the new application

The decisions made in this section and the sections that follow weredeliberate. They were made with the aim of illustrating certain design anddecision points rather than simply resolving the problems at hand. We havemade every attempt to keep this as true-to-life as possible.

Although the business requirements are fictitious, they represent commonreal-life situations. Many customers follow this pattern of e-business adoptionas described in Section 1.2, “Business transformation” on page 4. In ourbusiness requirements, we establish a Web presence and move on tocreating parts of a new process.

Table 41 represents a summarized form of the requirements for thee-business form of the Finder applications. These were developed using asimulated form of the Gather requirements phase of the design approachdescribed in Part 2. For more details, see Appendix C, “Applying thee-business design approach” on page 299.

Table 41. Ranked business requirements

Requirement Rank

Business requirements

BR1 - Make directory information available on the intranet and theInternet to employees and the general public.

High

BR2 - Reduce the administrative burden on HR staff by allowing usersto update their own details.

Medium

BR3 - Evolve to a platform-independent e-business infrastructure witha higher priority for the client. In the future, the server should also beplatform-independent to allow for scalability.

High

BR4 - Provide a browser-based user interface using only HTML. Medium

BR5 - Provide the user with facilities to create and save named queriesand the ability to create and maintain a personal directory list.

Low

BR6 - Support an aggressive production deliverable date. High

Other requirements

OR1 - Access must be dialup as well as LAN. High

OR2 - Migration strategy should be incremental, that is, the initial set ofbusiness requirements must be able to be met without requiring acomplete rewrite or new technical infrastructure to purchased.

High


8.3.1 RationaleThe rationale for each requirement is summarized below. An overall goal wasto show that the migration of core business functionality to an e-businessplatform should be justified by the potential for increased businessopportunity, cost savings, market share, etc. rather than simply being aresponse to a technology push.

Requirements designed to expand the scope of the application are markedwith an asterisk.

• BR1 - Make directory information available on the intranet and Internet (*).This is the core business function of the original application.

• BR2 - Allow users to update their own details (*). Introduce the concept ofself-service and enterprise data update functionality.

• BR3 - Platform-independent e-business infrastructureIllustrate a cornerstone of the IBM Application framework for e-business.This was selected to allow maximum potential for future migration of acurrent application’s server side elements and platform. Specifically, manyOS/2 customers wish to move their application to a platform-independentinfrastructure.

• BR4 - A browser-based user interface using HTML only(*).This trades off some loss of user interface functionality to support anexpanded customer base and to provide a reduction in client softwaremanagement costs.

• BR5 - Facilities to create and save named queries and personaldirectories (*).This introduces user productivity and customization features not providedin the original application. It also introduces issues, such as privacy,managing user profile information, and potentially off-line capabilities.

• BR6 - Support an aggressive production deliverable date.This is a standard requirement of all projects!

• OR1 - Dialup and LAN Access.Ensure that the application is accessible outside the organization. It alsointroduces issues, such as performance and security.

OR3 - Access control should be provided based on user ID and role. Medium

OR4 - Construct for growth and scalability. Medium

Requirement Rank


• OR2 - Incremental Migration StrategyThis is selected because a common scenario involves leveraging existingnon-e-business-oriented application software and technical infrastructure.A single-step migration strategy is not usually practical.

• OR3 - Access control should be provided based on user ID and role.A requirement of making information and functionality, which is normallyinternal to the corporation, publicly accessible via the Internet.

• OR4 - Construct for growth and scalability.The proposed target architecture must be capable of evolution to supportgrowth and scalability, that is, a strategic approach to design will probablybe of more value than a tactical approach.

8.4 Application migration strategy

The design approach described in Part 2 considers the existing applicationand technical environment as part of the Gather Requirements phase. Sincemigration is the main theme of this book, this section elaborates the migrationaspects in more detail than it might otherwise be discussed.

8.4.1 Migration approachesThree broad approaches were considered for our migration:

• Rewrite the application.

• Incrementally introduce a new architecture via a wrappering approach thatleverages the existing application.

• Evolve the capabilities of the current application.

The first approach was excluded as not being appropriate for the goal of thebook. The third approach was also excluded because the architecture of theexisting Finder application could not be evolved to an architecture based onthe IBM Application Framework for e-business, thus, the incrementalapproach was taken as the starting point for migrating the Finder application.

8.4.1.1 Incremental approachEarly in the project, the team decided that the six week schedule would notpermit a significant coding effort. Adopting a phased approach to migrationand reducing the functional requirements to be met in the first phase in orderto satisfy time constraints are facts of life in many software developmentprojects.


The functionality to be implemented during the first stage of the migrationstrategy was that of the basic directory inquiry functionality needed to satisfyrequirement BR1. As part of this stage, the basic e-business frameworktechnical infrastructure was put in place.

In a phased migration strategy, a fundamental goal is to ensure that theactivities and architecture decisions of one phase are such that the remainingrequirements can be addressed in subsequent phases without involvingsignificant changes to functionality or the infrastructure developed in previousphases.

A side effect of a phased incremental approach is that it is usually possible forboth forms of the application to coexist right up to the final migration phase.

Having decided on the migration approach, the starting point becameidentifying points where the e-business version of the application couldleverage the existing code. The team came to call these points leveragepoints.

8.4.2 Migration leverage pointsThe leverage points are discussed in more detail in Section 3.2.3,“Application leverage points” on page 40, but part of the discussion isrepeated here for completeness.

The diagram shown in Figure 37 on page 165 is a slight adaptation of theGartner Group topology diagram for client/server applications. It describes,from left to right, four typical client/server application types. The dotted lineshows the split between the client and the server. The ability to leverageexisting functionality and data depends on the topology. The main leveragepoints for the Finder application are in the figure.

The Gartner Group used the term Distributed Function to describe anapplication, such as Finder. The Finder application topology is explicitlyidentified in the diagram.


Figure 37. Finder application leverage points

For the Finder application type, the team identified three leverage points.From these three leverage points, the team identified four possibleapproaches. It was determined that the presentation-related parts of theexisting client could not be reused. This applied to all strategies.

8.4.2.1 Approach 1: Wrap part of the client application logicIn the Finder application, the client application was sufficiently well-structuredto be able to identify and separate useful functionality that could be reused.This was functionality involving interaction with the server side of theapplication. It included network-related code, query building code, etc.

Architecturally, this new element becomes a form of domain abstractionlayer, that is, a kind of application-specific server API.

Thus, it would be possible to reuse some of the original client C librariesusing something similar to the Java JNI (Java Native Interface) approach. Itshould be noted that such an approach introduces a platform dependency.The original C libraries must be compiled to target a specific server platform.

This code would then execute as part of a Web/application server process.

8.4.2.2 Approaches 2 and 3: Rewrite client to access existing serverThere were two approaches here. Both involved rewriting the client code thatinteracted with the server side of the application in a new language. Therewould be no reuse of existing client code.

Application

Data

Presentation

Data

Presentation

Application

Data

Presentation

Application

Data

Presentation

Finder Application

Client

Server

Reuse business logic

2 ,3

4

Application

Share database Retarget rendering

1


Architecturally, this new element would then act as a custom connector.

This new code had to be capable of satisfying the protocol and wire formatrequirements of the existing server. This code would then execute as part of aWeb/application server process.

Another strategy or specialization of the second approach involved writing anadditional server side element. This was a form of protocol adapter server tohide the proprietary protocol/wire format aspects of the existing server.

This meant that the new client could communicate natively with this serverusing whatever mechanism was appropriate to the new language. Thisprotocol adapter server would execute in the same environment as the Finderapplication server.

This strategy would still require the development of the connector elementdescribed in Strategy 2.

8.4.2.3 Approach 4: Directly access the databaseAlthough this is a valid strategy, it was excluded for this project since, apartfrom managing concurrent access and integrity issues, there were no realissues to illustrate. Such an approach is virtually a rewrite. However, in theworst case, such as a poorly-structured two-tier (Remote Data) application,this may be the only option.

8.4.3 Migration strategy decisions for Phase 1Of the four approaches just described, approach 1 and approach 2 wereselected for further exploration. For the rest of this book, approach 1 isreferred to as the tactical solution and approach 2 is referred to as thestrategic solution.

8.4.3.1 Tactical solution: Wrap part of the client application logicThis would reuse some of the original client C libraries using an approachsimilar to the Java JNI (Java Native Interface) approach.

This code would then execute as part of a Web/application server process.

8.4.3.2 Strategic solution: Rewrite client and reuse existing serverThis strategy would rewrite the client code that interacted with the server sideof the application in a new language. This code would then execute as part ofa Web/application server process.


Approach 3, the idea of a protocol adapter server to hide the proprietaryprotocol/wire aspects, was not explored further. This was, primarily, a timeconstraint-based decision. In hindsight, it may have been better thanApproach 2. It would have factored out much low-level logic dealing with wireformats etc. into a separate server, thus, greatly simplifying connector design.

8.4.4 Subsequent migration phasesA plausible set of phases needed to address the remaining requirements ofthe Finder application follow:

1. BR3/OR4 - Transform the server side elements to be portable and, thus,independent of OS/2, thereby supporting a wider range of serverplatforms. This would enable the server to be platform-independent and toprovide more scalability options. For the Finder application, the selectionof the Web application server in the first phase is critical to satisfyingthese requirements. This server must be (relatively) platform-independentand must support OS/2.

2. BR3/OR4 - Introduction of a business objects layer based on a componenttechnology, such as Enterprise Java Beans. This moves major issues,such as transaction and persistence, to a separate application server andprepares the ground for an increased role by e-business in the enterpriseenvironment.

3. BR2 - Support for update of directory details by a user. This requirementhas more significance than it might appear. The wrapped server accessesreplicated off-line data in a read-only mode. Support for update wouldpotentially require direct update access to the directories or someasynchronous update process.

4. BR5 - Support for facilities to create/save named queries and personaldirectory lists. This requirement is a luxury. It could be included with orprecede any of the other phases.

8.5 Architecture alternatives/selection

This section summarizes the architectural decisions we made for the Finderapplication.

8.5.1 Architectural basisThe building block diagram has been used throughout this book to present asimple visual representation of the elements that comprise an e-businessapplication. At the end of Chapter 5, “Developing architectural alternatives”on page 71, there was a discussion that mapped this simple model to some


more complex e-business models. These models present what may betermed a network node view of the architecture.

Network Node View

Figure 38 shows mapping of the building block diagram to the Finderapplication architecture. Shaded nodes would not be required in Phase 1 butwould probably be required in a version where users could update their owndetails.

Figure 38. Network node view of Finder application

Note that the concept of an integration node is slightly contrived for the Finderapplication.

In order to describe the basis for Finder application architecture decisions, itis first necessary to zoom-in on the Server/Application Logic building block.The internal architecture of this block is evolving over time as the featuresand capabilities of a Web application server start to stabilize. This internalarchitecture is described in Figure 39 on page 169.

Security

System Management


EnterpriseData and

Application


Internet

FirewallNode (1)

FirewallNode (2)

FinderApplication

User

IntegrationNodeLAN LAN

GroupApplication

Server Node

DatabaseNode

Web ServerNode

(Transactional)

Web ServerNode

(Informational)


Figure 39. Internal structuring of the server/application logic building block

The most significant feature is the separation of the Web/application serverinto presentation-related aspects and business logic aspects. Typically, thereis some kind of abstraction layer separating the implementation of these partsof the e-business application. The term Domain Abstraction Layer was usedbecause it creates an abstract view of each of the connecting domains, thatis, the Server-side Presentation Logic and the Business Logic Domains. Thearchitecture is positioned to support a distributed objects implementation.

This view recognizes differences in skill sets and implementationtechnologies associated with each side of the abstraction layer and supportsthe independent evolution of both. It also allows business objects to bedesigned independently of specific application requirements. This increasesreusability.

This general approach became the architectural basis for the Web/applicationbuilding block of the Finder application.

8.5.2 Architecture design decisionsFor the Finder application, two forms of architecture were planned. Theserepresent examples of a tactical and a strategic approach to architecturedesign. The two architectures are shown in the diagram in Figure 40 on page170. They will be explained in more detail in subsequent chapters.


Server-sidePresentationLogic

Business Logic

DomainAbstraction

Layer


CoreServices

e-businessclient

EnterpriseData and

ApplicationsConnectors


Figure 40. Architectural alternatives

8.5.2.1 Tactical approach - Design decisionsFigure 41 shows the tactical approach.

Figure 41. Finder application (tactical approach)


Web Servers

DomainAbstraction

Layer


(NotImplemented)

CoreServices

(Not Applicable)

EnterpriseData and

Applications

Application Servers

BasicServlet/JSPApproach

VisualServlet

Approach

FinderApp

Server

GeneralCommand

ServerConnector

e-businessClient

VisualServletClient

FusionClient

DomainInterface

Connectors

2 22

1 1

1

1

1

strategicapproach

tacticalapproach

In Figure 40, Fusion Client means the browser client that only utilizesHTML files created by the NetObject Fusion development tool. VisualServlet Client means the browser client that only utilizes HTML datacreated by the servlet written using the VisualAge for Java developmenttool.

Note


Web Services

DomainAbstraction

Layer

CoreServices

(Not Applicable)

EnterpriseData and

Applications

Application Services

VisualServlet

Approach

FinderApp

Server

e-businessClient

VisualServletClient

DomainInterface

Connectors

1 1 1


The tactical approach is focused on examining the design issues given thefollowing decisions:

• Here, the approach was to access the existing server based on a layerwrapping part of the client application logic.

• The Development tool exploitation approach would exploit the visualcomposition features of Visual Age for Java wherever possible.

• A direct implementation. The architecture represented an instance of ageneral but less layered architecture than that of Alternative 2. Theseparation of presentation from business logic focus does not support adistributed approach to server-side functionality. The domain abstractionlayer and the concept of a connector would merge to directly access theexisting Finder application server.

8.5.2.2 Strategic approach - Design decisions

Figure 42. Finder application (strategic approach)

This alternative (Figure 42) focused on examining the design issues given thefollowing decisions:

• Here, the approach was to access the existing server based on a layerrepresenting a rewrite of client application logic.

• Development tool independence - No tool-specific features, vendor classlibraries, etc. were used. This meant the code would only exploit featuresof the relevant standard or API. For example, HTML or the Java API.

• Domain Abstraction layer based on the use of Commands - A Command isan object that represents an action. In our case, a command represents aspecific Finder application task. For example, Execute Search. The user ofa command, usually a programmer, knows what action the command is


Web Services

DomainAbstraction

Layer


(NotImplemented)

CoreServices

(Not Applicable)

EnterpriseData and

Applications

Application Services


FinderApp

Server

GeneralCommand

ServerConnector

e-businessClient

FusionClient

Connectors

2

2

2

2

2


designed to perform, the parameter requirements, and how to invoke thecommand. The user does not know how or where this action is carried out.

• Explicitly designed to evolve to use Business Objects based on distributedcomponent technologies - In particular, this architecture was targeting afuture implementation of business logic based on the Enterprise JavaBeans specification.

The Choose Architectural Alternatives step of the approach in Part 2describes a method of ranking architectural alternatives according to theirability to support the business requirements. The team’s ranking ofarchitectural alternatives with respect to the Finder application requirementsis shown in Table 42. See Appendix C, “Applying the e-business designapproach” on page 299 for more details.

Table 42. Grading of requirements to architectural alternatives

Requirement TacticalSolution

StrategicSolution

Business requirements

BR1 - Make directory information available on the intranetand the Internet to both employees and the general public.

+ +

BR2 - Reduce the administrative burden on HR staff byallowing users to update their own details.

+ +

BR3 - Evolve to a platform-independent e-businessinfrastructure.

- +

BR4 - Provide a browser-based user interface. + +

BR5 - Provide users with facilities to create and savenamed queries and the ability to create and maintain apersonal directory list.

+ +

BR6 - An aggressive production deliverable date. + 0

Other Requirements

OR1 - Access must be dialup as well as LAN. + +

OR2 - Migration strategy should be incremental. 0 +

OR3 - Access control should be provided based on user IDand role.

0 0

OR4 - Construct for growth and scalability. - +


8.6 Technology selection

The decisions about requirements, migration strategy, and architectureinteract to influence technology choices. This section lists the choices foreach of the two approaches that were selected for further exploration.

There are basically two paths to be explored. For brevity, these have beenlabelled the Tactical Approach and the Strategic Approach.

8.6.1 Technology impact of requirementsEssentially, the requirements for platform independence (BR3) require aJava-based solution.

Incremental migration strategy (OR4) dictates that the Web application servermust be Java-based and capable of running on a suitable range of platforms.OS/2 must be a supported platform.

8.6.2 SkillsetsAll team members had a background in programming/technical architecture.

8.6.3 Tactical approachThis approach involved phased incremental migration and is built using theTactical Architecture. Table 43 shows the technology selection for the tacticalmigration approach.

Table 43. Technology selection for the tactical migration approach

Building Block Technology Selection

Client

Browser All Browsers(Netscape Communicator 4.5)

Page Creation IBM - Visual Age For Java 2.0 (Enterprise)Visual Page Composer

Network

Protocol HTTP

Web/application server

Web Server IBM - HTTP Server

Application server IBM - WebSphere 2.0 (Standard)


8.6.4 Strategic approachThis approach involved phased incremental migration and is built using theStrategic architecture.

Table 44. Technology selection for the strategic migration approach

Appplication Logic

Servlet Development IBM - Visual Age For Java 2.0 (Enterprise)Visual Servlet Editor

Component Development IBM - Visual Age For Java 2.0 (Enterprise)

Connectors

Custom Finder Connector IBM - Visual Age For Java 2.0 (Enterprise)IBM - Visual Age For C++Other software

Enterprise Applications and Data

Application server Finder Application server

Server Operating System IBM - OS/2

Database IBM - Database Manager 1.0


Client

Browser All Browsers(Netscape Communicator 4.5)

Page Creation NetObjects - Fusion 4.0Microsoft - Front Page 98

Client Side Scripting Microsoft - Visual Interdev 6.0(JavaScript - ECMA 262)

Network

Protocol HTTP

Web/application server

Web Server IBM - HTTP Server

Application server IBM - WebSphere 2.0 (Standard)

Appplication Logic



8.7 What was accomplished

The primary objective of this project was to explore the design considerationsfor moving an application from the client/server application model to thee-business application model by using a real live application. Time andresources were the most limiting factor. Although we had these restrictions,two alternative approaches were selected for further investigation, and wecould get the essential issues and directions for the solution to migrate thiskind of application from an old style C/S application to a Web-enabledapplication. For each of the two approaches, there could also have beensubsequent phases.

This was a six-week project with four persons. The members of the teamwere also responsible for documenting their findings as they progressed.During the six weeks, the team was able to complete the following:

• Solution design and technology selection for the first migration phase

• Application design for the first migration phase

• Concept implementation for the first migration phase

Time permitting, the following tasks would have been extremely useful todetermine exactly which migration choice would have been the most feasible

Servlet Development IBM - Visual Age For Java 2.0 (Enterprise)Standard Servlet Programming

Java Server Pages Standard Text Editor

Component Development IBM - Visual Age For Java 2.0 (Enterprise)

Domain Abstraction Layer

Command Components IBM - Visual Age For Java 2.0 (Enterprise)

Connectors

Custom Finder Connector IBM - Visual Age For Java 2.0 (Enterprise)

Enterprise Applications and Data

Application server Finder application server

Server Operating System IBM - OS/2

Database IBM - Database Manager 1.0IBM - Universal Data Base 5.2



approach. They would also have added to the list of design considerations forfuture growth.

• Explore other alternatives

• Concept implementation for at least the next migration stage

• Concept enterprise implementation for subsequent migration stages

• Performance tests

• Add Security and systems management

8.8 Chapter layout

The remaining chapters discuss the design decisions, issues, andimplementation details that were made for both the tactical solution and thestrategic solution. They are divided into the sections shown in Figure 43.Each of the application topology components is described in the context ofthe selected application and the selected migration approaches.

Figure 43. Chapter breakdown.

Chapter 9, “The e-business client” on page 177, describes the developmentof the e-business client for the selected solutions; Chapter 10, “The Web andapplication server” on page 203, describes the Web/application servercomponent for the selected solutions, and Chapter 11, “Accessing enterpriseapplications and data” on page 245, describes the components needed toconnect to the enterprise datasources and applications.


Web Servers

DomainAbstraction

Layer

Application Servers


VisualServlet

Approach

GeneralCommand

ServerConnector

e-businessClient

VisualServletClient

FusionClient

DomainInterface

Connectors2

2

2

2

1 1 1

EnterpriseData and

Applications

FinderApp

Server


(NotImplemented)

CoreServices

(Not Applicable)

2

The e-business client

Web/Application Server Accessing Enterprise Application and Data


Chapter 9. The e-business client

In the most typical client/server application, the focus is on presentingbusiness data in a graphical user interface to an end-user on a personalcomputer. The data is usually stored in a relational database.

An equivalent e-business application would need to provide access to thesame data and business functionality for a network-based client device. Thisdevice will typically be a Web browser.

It may also need to provide access to data and business functionality foranother e-business application, for example, in a virtual supply chain process.

This chapter will focus on the issues associated with migrating the client partof a client/server application to an e-business application where the clientdevice is a Web browser. The part that this chapter will focus on is shown inFigure 44.

Figure 44. The e-business client

9.1 Before we start

It is important to ensure that expectations for e-business client functionalityare realistic. This is especially true if the user’s of the existing client/serverapplication will also be using the e-business version.

e-businessClient

VisualServletClient

FusionClient

2

1

e-businessClient

VisualServletClient

FusionClient

2

1

Web Servers

DomainAbstraction

Layer

Application Servers


VisualServlet

Approach

GeneralCommand

DomainInterface

2

2

1 1


(NotImplemented)

CoreServices

(Not Applicable)

2

ServerConnector

Connectors2

EnterpriseData and

Applications

FinderApp

Server


9.1.1 Visit successful e-business Web sitesThere is no substitute for understanding a medium through experience. Someorganizations with highly-successful Web sites are listed below. In mostcases, these sites are driving e-business client design by virtue of theirsuccess.

Examination of these sites will yield many insights into e-business applicationinterface design. Where possible, it is valuable to actually use the facilitiesprovided - especially those involving financial transactions. It is usuallypossible to cancel a process before the last step! (It is a bad sign if youcannot.)

Some examples of organizations with excellent e-business sites are:

• IBM (www.ibm.com)

• Sun (www.sun.com)

• Microsoft (www.microsoft.com)

• Amazon (www.amazon.com)

• CDNow (www.cdnow.com)

• ETrade (www.etrade.com)

• Cisco (www.cisco.com)

9.1.2 Is a browser-based interface the correct choice?At present, a browser-based user interface is not likely to provide a betteruser experience than the equivalent graphical user interface of a client/serverapplication. The main reasons for this are:

• Differences in application model - Browsers use a page model and havetraditionally focussed on presenting relatively static content. Client/serverapplications use a forms model with the primary focus on transactions.Differences in these models can lead to significant differences in the wayapplication behaviors are exposed in the user interface. This is especiallytrue with respect to navigation and screen (page) flow.

• Browser differences - Browser differences force a lowest commondenominator approach to interface design. This greatly reduces theoptions for user interface functionality.

Using the most up-to-date Web standards (HTML 4, CSS1/CSS2,XML/XSL etc.) it should be possible to approach at least 70 percent of therichness of a typical client/server user interface. If downloadablecomponents are used, it should be possible to design virtually equivalentinterfaces.


However, given the current differences between the browsers with respectto support for these standards, it is not likely that this problem will beresolved in the near future.

• Performance - As soon as the application is placed on the public Internet,performance becomes an issue. Most access to these applications will beat modem speeds. The interpreted nature of markup-based presentationsalso has a performance impact.

These factors mean that achieving acceptable performance will almostcertainly apply constraints to the design of the user interface.

This potential loss of functionality must be factored into the planning anddesign stages of the user interface. The design must focus on the strengths ofthe browser.

Any such loss has to be justified in terms of gains in other areas. Twosignificant justifications are the potential for increased audience reach andthe reduction in client software management efforts.

9.1.3 Review application type and device combinationsThe technology choices for the client have been discussed in Chapter 7,“Selecting technologies” on page 125. These options need to be examinedfrom the perspective of user interface design.

The approach to the implementation of the migrated client functionality andthe decisions as to which client devices need to be supported will have asignificant impact on the user interface capabilities.

9.1.3.1 e-business application typesThe following is a list of e-business application types:

• Internet-enabled - In this application type, there are no user interfacerestrictions, but it is mainly suited to intranet usage or to places whereclient software management procedures are already in place.

• Browser-based - This application type is a significant restriction forpublic Internet usage. In an intranet context, it is possible to exploitdownloadable client components to enhance presentation capabilities.This has the potential to degrade performance. Downloadablecomponents usually require specific software support to be present,which requires some degree of client software management.

• GUI network applications - There are no user interface restrictionswith this application type. In some ways, this represents the extremecase of the downloadable components approach. Either most or all of

The e-business client 179

the application functionality is downloaded on demand, or the softwareneeds to be installed on the client.

9.1.3.2 e-business client devicesA list of e-business client devices follows:

• Pervasive devices (PDA, Mobile Phones, etc.) - These devices havesignificant user interface restrictions.

• PC (Desktop/Laptop) - These devices have no restrictions.

• Network Computers - These devices have no restrictions.

9.2 Designing e-business client interface

It is not the intent of this chapter to provide detailed user interface designguidelines for Web applications. There are many Web sites and a growingbody of publications devoted to this topic. Some Web user interface designlinks are listed below:

• IBM Ease Of Use Site (http://www.ibm.com/ibm/easy/index.html)

• Ivor Jacobsen’s Site (http://www.useit.com/)

• AskTog (http://www.asktog.com)

This section works through a series of steps to establish a basic applicationdesign and the user interface required to support that design. Thepresentation sequence draws loosely from the material at the IBM Ease OfUse Site. However, the content has been drawn from a number of userinterface design sources. This includes graphical user interface and Web userinterface design guidelines.

The goals are to partially complete some relatively-ordered design process,create a first cut of a browser-based user interface, and examine designconsiderations for the client.

9.2.1 Examining the existing Finder application user interfaceThis chapter focuses on migrating the user interface for core functionality ofthe Finder application. This functionality allows a user to create a directorysearch query, execute it, and browse the results.

The main user interface elements of the existing Finder application thatsupport this functionality are presented in Figure 45.


Figure 45. The client/server Finder application - Create query

The user must enter a value in at least one Search Criteria entry field. The setof search criteria fields varies with the Directory Type. Clicking on the Searchbutton initiates a search.

Each search result set is displayed in its own modeless secondary window asshown in Figure 46 on page 182.


Figure 46. The client/server Finder application - Browse query result set

The user can double click on a row to see further details.

The details of the selected employee are displayed in Figure 47.

Figure 47. The client/server Finder application - Display full details


Organizational hierarchy information can be displayed by clicking on theappropriate button.

9.2.2 Understanding the users and the tasksAs part of the design approach in Part 2 of the book, a set of simple businessscenarios were developed to describe the requirements of the e-businessversion of the Finder application. For further details, see Appendix C,“Applying the e-business design approach” on page 299.

9.2.2.1 Business scenariosThree types of user were identified for the e-business version of the Finderapplication.

• An Anonymous user should be assumed to be a member of the generalpublic accessing the Internet over a dial-up connection, visiting the Website of the organization, and using the Finder application searchfunctionality to obtain contact information. This user may or may not becomputer literate, is probably Web-savvy, but is a casual user as far as theapplication is concerned.

• An Employee is a member of the organization and usuallycomputer-literate. Such a user will frequently access this applicationduring the course of his or her work. Typically, the application will beaccessed from within the organization’s intranet. A small but increasingnumber of employees will be off-site and will require Internet access overa dial-up connection.

• An HR staff member is both an employee and a special kind of user. Sucha user will usually access the application via an intranet. This personcreates and manages the directory content - possibly using otherapplications for this purpose.

The set of simple scenario descriptions grouped by user type follows.

Anonymous user (Any user not logged in)

• Search and retrieve a restricted subset of information as a result set

Employee

• Perform all the actions of an anonymous user.

• Log in to the application as a registered user. (A registered user has arecord in the directory.)

• Search and retrieve all available directory record information about allemployees.


• Create named queries.

• Create a personal directory list and add selected result set records to thislist.

• Update his or her own record information.

• Can specify whether details are available to anonymous users.

HR Staff Member

• Can perform all the actions of an employee

• Create/delete employee records

• Update any employee record

9.2.3 Examining the competitionEvaluating competing applications on the Internet for strengths, weaknesses,and potential future development can help clarify design ideas. For thisproject, we used two different versions of the directory application developedafter the original client/server application. One was a browser-based intranetsolution and the second was a Java application.

Compared to the original client/server version, a number of simplifyingassumptions have been made for both versions. For example, the user canonly search on a single directory and use a single set of search filter terms offixed limit. The concept of directory type is not present.

9.2.3.1 Blue Pages - IBM intranetA browser-based version of the original application is currently deployed onthe IBM intranet.

A browser-neutral, pure HTML, form-based implementation is shown inFigure 48 on page 185.


Figure 48. IBM intranet Blue Pages - Create a query

There is minimal client side scripting and no use of downloadablecomponents. There are no security features because the application wasintended for intranet use only.

There is a Simple Search form (not shown) that is embedded as a small areaon the home page. The page shown above is the Advanced search page

Simple search switches to the Advanced page to perform a search anddisplay the results. The Advanced Search part of the page is built using aframeset consisting of two frames: Search criteria are in the top frame, andresults are in the bottom frame.

This frameset is itself embedded within the standard three-frameframeset-based page representing the site navigation layout.

A Simple search:

• Searches all the directories.

• Uses the name attribute only.

• The simple search form has an Advanced link and a link to a Search Tipspage.

In an Advanced search:

• The directory is selectable.

• The search attribute is selectable from a list.


• A Fuzzy search option is available.

The results of a search appear in the lower frame shown in Figure 49.

Figure 49. IBM intranet Blue Pages - Browse query result set

All results are returned to the client on a single page. A number of quick linksare provided to allow further details to be presented.

Figure 50 on page 187 shows the details page.


Figure 50. IBM intranet Blue Pages - Display full details

On the details page, a set of links allows specific sets of details to bedisplayed. The way in which this information is presented varies and is notshown by the links. For example, in a new browser window, replace thecurrent details, the current page, etc.

9.2.3.2 Blue Pages - JavaThe Java Application version of the application is a fully-redeveloped userinterface. The style has something of a browser look and feel but is a fullgraphical user interface. It does not follow the typical Windows/CUA look andfeel.


Figure 51. Simple search and result set limiting

There are two search modes: Simple (shown in Figure 51) and advanced(shown in Figure 52 on page 189). The advanced search part of the formdynamically generates graphical user interface elements for each additionalsearch filter term input, that is, the region expands, and the lower scrollregions are contracted. There is a limit of three filter terms.

Because the application is not constrained by HTML limitations, theapplication makes better use of screen real estate. All information can bepresented within a single window.

While this is a relatively easy design task for GUI developers withcontemporary development tools, producing this level of user interfacefunctionality with HTML would involve on the order of six frames, a significantamount of client/side scripting, and dynamic manipulation of HTML styles.

The application is more economical with respect to network data transfers.The total number of rows that can be returned is limited to 100. The searchresult initially returns just the list of names and sufficient key information toretrieve the full details of a selected row. This retrieval only occurs if the rowsare selected in the left scroll region.


Figure 52. Advanced search and result set/details display

A Simple search:

• Can select directories from a list or ALL

• Can search using a single attribute (Name)

• Yields the most recently-used list of name values

An Advanced search:

• Cannot specify the directory. It is assumed to be ALL.

• Can search using one to three attributes. Selection of each attribute isfrom a drop-down list.

• Has a fuzzy option with a relationship operator expressed in colloquialterms, such as Starts with, Is, Isn’t, etc.

9.2.4 Determining content and structureA simple user object model for the e-business version of the Finderapplication can be created by examining the business scenarios and thefunctionality of the existing application.

Although expressed in object modeling notation in this document, a userobject should not be confused with a programming language class in theimplementation. The intent of a user object model is to identify what the user


sees (possibly only conceptually) in the application domain and manipulatesin the user interface of the application during the performance of his or hertasks.

For those familiar with object model diagrams, Figure 53 shows the userObject model for the Finder application. The user object model identifiesthese objects and the relationships between them. It can be made as detailedas is useful for the design process.

Figure 53. User object model for the e-business Finder application

The User Object model can be considered both the broad categorization ofthe content and the deep structure of that content as it is to be presented bythe e-business client.

The content of a client/server application is usually transactional datapresented as a series of forms. The term Transactive Content, a term coinedby the Forrester Group, was introduced in an earlier chapter.


It describes a Web application involving transaction processing, interactivity,and rich content linked by a high level of personalization based on profileinformation kept about each user.

To achieve a successful blend of these elements requires input from Webdesigners, domain experts, and end-users throughout the development of theapplication. However, a User Object model can be used, as it is being usedhere, to identify the data and tasks and as a starting point for designingoverall application navigation flow.

Figure 54 shows the initial e-business Finder application navigation structure.

Figure 54. The initial e-business Finder application navigation structure

The functionality enclosed in the rectangle created with a broken linerepresents core functionality and the minimum home page, that is, this iswhat the user sees first for the Finder application (see Figure 54).

It is assumed that the migrated Finder application functionality will be addedto an existing organizational Web site. This is expected to be a commonscenario. Many aspects of the style and some of the navigation features willbe dictated by the existing site.

The existing Web site for this project will be a template Web site generatedusing NetObjects Fusion 4.0.

9.2.5 Selecting development tools and technologyFor this project, the tools and technologies were selected for a number ofreasons. The selections were made to illustrate some typical development

Application

AdvancedSearch

Login

SimpleSearch

Results

Record

SavedQueries

DirectoryList

Update


team arrangements and were influenced by the target architecture. For moredetails, see Chapter 7, “Selecting technologies” on page 125.

9.2.6 Start with a low-fidelity prototypeThe intent of this prototype is to bring together the initial findings aboutcontent and structure as a working prototype that embodies preliminary userinterface design ideas. The goal of this prototype is to allow prospective usersa chance to interact with the application as soon as possible in thedevelopment cycle. The rationale behind a low-fidelity version is to preventtoo many detailed interface decisions from being made before obtaining userfeedback.

An iterative development process involving all team roles, from graphicsdesigners to programmers and user representatives, is recommended. Figure55 shows the low-fidelity prototype home page.

Figure 55. Low-fidelity prototype - Home page


The simple search is represented approximately as it is in the intranet andJava versions. The use of a small embedded Simple search form in the homepage (see Figure 55 on page 192) or the top or left site navigation areas iscommon in most Web sites that support some form of search.

Blending new features into an existing site is also a common requirement. Forthis project, the existing site is represented by a site generated from aNetObjects Fusion Web site template.

Figure 56 shows the Advanced search page.

Figure 56. Low-fidelity prototype - People search page

Practically speaking, the People search page represents the initial design forthe migrated Finder application functionality. The e-business application tasksare represented in a horizontal menu bar. The tasks are arranged left to rightby decreasing frequency of use.


There are two frames: A frameset containing this menu and a client frame.Each menu option targets this client frame. The Advanced Search page hereis itself a dual frame frameset similar to the intranet version (see Figure 56 onpage 193).

The search criteria frame has been designed to provide the samefunctionality as the Java version but without requiring client side scripting ordynamic HTML.

The only requirement for the browser is that it support HTML tables andframes.

9.3 Migration issues

This sections describes some of the key issues that were confronted whenmigrating the client/server Finder application interface to a browser-basedversion.

9.3.1 Native GUI interface & Web interface are different paradigmsGUIs, while still evolving, are relatively standard. The dominant metaphor is asophisticated forms-based view. Web browsers are page-based. Certaincommon GUI application behaviors are not appropriate. Standards(expectations) for Web page layout are starting to converge.

The Menu and toolbarsThe Finder application user interface was designed at a point in time whenuser interface design was less standardized. In particular, the menu designand the placement of functionality would probably be laid out quite differentlythan for a contemporary Windows application. This problem is compoundedwhen transferring the design to a Web interface.

The application menus and toolbars must be handled carefully in the Webpage design. There is the potential for action control overload. There is alsopotential for a clash between site menus, page menus, browser menus, andbrowser navigation controls.

Multi-window and secondary window usageThe Finder application exploits a number of modal dialogs and secondarymodeless windows.

Non-standard GUI design featuresThere are some questionable GUI design decisions associated with keywindows. For example, there is a single search criteria window for a multiple


non-modal results window. If a number of queries have been performed, it isnot (easily) possible to determine what criteria produced a given result set.

Command button placementIn a GUI application, particularly in modal dialogs, many command buttoncontrols are placed at the bottom (or the right hand side) of the window.Because of the dynamic length of a page and original application of abrowser, the positioning of such controls varies widely.

9.3.1.1 DecisionsMenus were represented as a horizontal bar of links implemented as a singleHTML table. In a more developed prototype, HTML styles and color could beused to create something more visually pleasing without requiring graphics.

As with later implementations, the multi-window approach of the originalapplication was avoided. Search and results were presented together asframes of a single page. (It is possible to use multiple browser windows, butcontrol is limited.)

Command buttons were kept in fixed positions at or near the top of the page.

9.3.2 HTML presentation limitationsThis section describes some significant HTML limitations.

9.3.2.1 Intrinsic controlsThe set of intrinsic controls is very limited. As a GUI application, the Finderapplication is very simple. Contemporary GUI applications commonly employmuch more complex container type controls, such as a Tree View,sophisticated Grid, Tabbed Notebook, etc.

9.3.2.2 FramesThe Finder application supports dynamic input search criteria.The set of input fields is dynamically created and driven by the selection ofdirectory type. This list is presented in a scrolling region within the form. SeeFigure 73 on page 259.

This seemingly simple GUI feature is quite difficult to reproduce in standardHTML. The best approximation involves the IFRAME HTML element. Thiselement is not supported by Netscape; so, a much more complexarrangement of pages using the FRAME tag is required.


9.3.2.3 DecisionsOnly intrinsic controls were used. Precise control of layout and sizing is aproblem stemming from the nature of HTML. Layout did not exploit CSSsizing and positioning features to maximize browser independence. Even withthe smarts of NetObjects Fusion, where layout is controlled by the use oftables, it was difficult get the kind of pixel-perfect layout expected in anequivalent GUI application.

GUI functionality was reduced. The query criteria functionality was reducedfrom the original application but extended from the intranet application. Thelayout was borrowed from the Java application but did not exploit dynamicHTML.

A full prototype version could use graphics and styles to created a tabbednotebook presentation without requiring downloadable components.

Frames were used extensively. With the exception of being able to scroll theresults frame, the goal was to create the perception of single dynamic pageregions rather than to add user-driven navigation features. Most frames arefixed, without borders or scroll bars.

9.3.3 Browser differencesThis is currently the most significant implementation issue. Differences inparadigms and HTML limitations can be factored into the initial design.Differences between browsers involve non-functional design and code. This isa problem that will continue to require attention after the application isdeployed.

Currently, many interactive features are produced through dynamicmanipulation of HTML style elements. These styles are defined in twostandards known as Cascading Style Sheets. If an attempt is made to useCSS, significant browser differences emerge.

9.3.3.1 DecisionsThe initial plan was to develop a lowest common denominator solution. Theplanned second stage was then to attempt to see how close an approximationto the interface Java version of the application could be obtained by targetingonly the most recent versions of Netscape and Internet Explorer.

Even then, without a major effort in developing (or using third party) crossbrowser libraries, success was limited. There was insufficient time to explorethis further.


There are a number of possible approaches:

• The lowest common denominator approach.

• Client side browser detection and conditional client scripting. Essentially,this involves parallel paths within the JavaScript code.

• Server detection of browser capabilities and generation of specific pagestargeting the browser.

• Target a specific browser.

Targeting a specific browser is not considered good Web practice. Theunfortunate reality is that most large Web sites use a combination or mix ofeach of the first three techniques.

9.3.4 Client/server apps may involve significant client processingExploiting the computing power of the client machine was at least onemotivation behind the push to client/server computing in the 1980’s.Consequently, it is to be expected that functionality will be present on theclient in many client/server applications.

It could also be the result of poor multitiered design using a two-tier approachor just poor quality code.

Although the Finder application did not really involve significant processing, itdoes present a useful illustrative example. The application was well-tiered,and, within each tier, there was some degree of tier separation. Queryconstruction and the handling of result sets at the client were two processingissues that needed to be addressed.

Query constructionThe following options were considered:

• Build and ship a search request as SQL using JavaScript within thebrowser. This parallels the approach of the existing application.

• Ship Name Value (NV) pairs as FORM data in the standard HTML fashion,process the form data to build SQL on the Web server. Then pass this tothe application server.

• Build and ship a request in XML using JavaScript within the browser. Forexample, create an XML representation of an LDAP search filter. Thenpass this to the application server.

• Ship NV pairs as FORM data in the standard HTML fashion, and buildXML on the Web server. Then, pass this to the application server.


Handling of large result setsThe following options were considered:

• A server-based governer places a limit on the maximum number of rowsthat can be returned.

• Ship the entire result set to the client, all at once.

• Use partial result set shipping. The client and server shuttle the state as,say, a cookie that is passed back to the server on a get next request. Onlya single page of data is sent to the client at any one time. This implies thatthe server knows how to restart the search.

• In partial result set shipping, the client maintains the state and a cache ofreturned result set rows. The client and server shuttle state as, forexample, a cookie that is passed back to the server on a get next request.The client cache grows until some user action within the client interfaceindicates that a new query is being performed.

9.3.4.1 DecisionsThe following decisions were made:

Query constructionThe decision was made to use option 2 and ship NV pairs as FORM data inthe standard HTML fashion, process the form data to build SQL on the Webserver, and pass it to the application server. In a strategic approach, buildingXML on the server offers more potential for flexibility. SQL was only used inthe original application because the directory information was stored in arelational database. In reality, a directory should not be considered in thismanner.

Handling of large result setsFor simplicity, option 2 was used, and the entire result set was returned. Amore sophisticated solution involving client caching is worth exploring in thefuture.

9.3.5 Intermingled business logic and presentation logicA significant proportion of existing client/server applications may not havebeen successfully architected as three-tier applications. Many Client/serverRAD tools greatly simplify two-tier development.

Depending on the design and coding discipline of the application developers,this might mean that much business logic is intertwined with user interfacemanipulation logic.


This exacerbates the previous problems of client-side logic. Leveraging thiscode as part of the migration may be very difficult.

9.3.5.1 DecisionsThis was the case with the Finder application. This was an older GUIapplication coded directly to the Presentation Manager API. Although theapplication was partitioned, the mix of this style of code and business logicwas present and made understanding the code difficult.

Two approaches were taken as described in Chapter 8, “Finder applicationexperiences” on page 157. One approach did wrap as much client code aswas possible. The other rewrote the client. No real presentation logic wasreusable in either approach.

9.3.6 A development environment technical issueTo create the Web site for this project, a template project generated usingNetObjects Fusion 4.0 was used. This illustrated another challenge: MixingNetObjects-managed pages and dynamically-generated HTML pages, suchas Java Server Pages (JSP)-based pages.

Currently, development tool support for JSP is limited. Development of suchpages requires a server-side HTML programmer, thus, it is currently simplerto code such pages using a text editor.

NetObjects Fusion stores pages in a proprietary format. This allows a site tobe generated to target different browser types and generations. A fusionenvironment targets content developer roles. The WYSIWYG environmentsometimes restricts certain HTML techniques or makes them counterintuitive.Support for frames is weak, and specifying the target frame for an action isdifficult.

Furthermore, it is not possible to have two-way lossless exchanges of thepage as it undergoes development. Fusion does not accept JSP type tags orhand-coded HTML tags.

Thus, for our development, we had to develop a close approximation for thestatic layout elements of dynamically-generated pages (the content developerrole) using Fusion, generate the HTML, and, from that point, manuallymaintain the Web pages.

9.3.7 Some other issuesOur experience only touched on the issues with which this applicationbrought us into contact. Some issues that might be relevant follow:


• Intellectual Property issues via source code exposure

• Application to client device mismatch

• Support for disconnected users

• Support for profile-driven user experience

9.4 Thin client development suggestions

Table 45 lists a starting set of guidelines for specific areas of thin clientdevelopment. They should not be considered as complete or final. Thesehave been drawn from best practice views of analysts, such as Gartner, WebDevelopment sites, and the experiences of the development team.

Table 45. Markup language-based client

Technology Area Description

Web Browser

The safest path is still the lowest common denominatorapproach.Settle on the lowest level of browser to be supported. Designappropriate response pages for non-conforming browsers.This level should be such that approximately equivalent corefunctionality is available in both Microsoft IE and NetscapeNavigator.

HTML

All HTML must be able to pass the appropriate W3C HTMLvalidation suite.HTML 3.2 should be the lowest common denominator.All HTML must display the same (with minor acceptablevariations) in both browsers.

ScriptingUse only ECMA 262 (JavaScript/JScript)-compliant features.Keep executable logic and presentation as separate as possibleby using external script links.


Table 46. Internet/Web Server

Components

Design time components must only insert browser neutralcode that meets all other Browser side run-timerecommendations.Run Time Components use a minimal number ofdownloadable components for non-visual functionality orsmall scale visual functionality only.Use 100 percent pure applets compliant with Java 1.1 SDK. Onlyuse them if it is absolutely necessary and assuming overallperformance impact is justified.Do not use ActiveX.For non-intrinsic visual elements, such as a tabbed-notebookmetaphor, normally provided as components in a GUIdevelopment environment, use graphics, HTML styles, andscripting in preference to components or applets if possible.

Dynamic HTML

Use only standard HTML style mechanisms.Keep style and content as separate as possible using cascadingstyle sheets (CSS1/2) and external style sheet links if possible.This is the area requiring the most care because this is wherethe most significant browser differences occur.

DOM/XML/XSL

Many DOM (Level 0) features are available in version 4 browsers(more commonly called Scripting Object Model). Only script tofeatures common to both browsers.The use of DOM (Level 1), XML, XSL, and CSS2 holds greatpromise for user-interface development but is restricted toversion 5 browsers.


Web ServerKeep the Web server separate from the application server. Usea common commercial Web server, such as Netscape,MIcrosoft, or Apache, for static and simple page services.

CGI/FastCGIAvoid this unless there are existing CGI scripts/programs in Unixcontexts. FastCGI is an unknown quantity in terms of futures andsupport. Where appropriate, test whether Java servlets are anacceptable replacement.



Web Server APIs

Heavily exploit dynamic server page generation.If using Microsoft ISAPIOnly use RAD tools, such as Delphi or VisualBasic, for IIS DLLfunctionality if performance and robustness are verified;otherwise, use C/C++ for performance. If performance is not amajor issue, use scripting.If using Java ServletsExploit the platform independence of Java, and use Servlet/JSP.This second approach is subject to stabilization of the JavaServer SDK APIs and verification of performance/scalability etc.

Scripting

Exploit dynamic server page generation. In both the followingapproaches, separate script and HTML statements wherepossible.Exploit components in place of significant blocks of code wherepossible.Consider documenting component interfaces in XML to allow thegeneration of COM/Java/CORBA-equivalent definitions.Consider COM wrappers around Java Beans/CORBA clients ifthey are available, performance is acceptable, and an MSenvironment is required.For Microsoft Active Server Pages(ASP):Use JScript as the scripting language. Use MS extensions onlywhen COM-specific tasks are required; otherwise, only useECMA 262-compliant features.Isolate Microsoft COM-specific scripting elements intoprocedures where possible.For Java Servlets/JSP:Use Model-View-Controller pattern to influence JSP-Servlet andJSP-JSP combinations.Selectively use Java and JavaScript

DOM/XML/XSLIf production strength implementations of tools supporting thesestandards are available, explore the use of these standards togenerate HTML in place of or as a supplement to other serverside techniques.



Chapter 10. The Web and application server

This chapter describes the design and implementation details relating to theWeb/application server aspects of the migrated Finder application. The focusis on answering the following questions:

• What were the design considerations with respect to the server sideelements of the e-business application?

• What did we choose for the Finder application and why?

• What implementation problems and issues were encountered?

The components that this chapter will focus on are shown in Figure 57.

Figure 57. The Web and application server

10.1 From Web server to Web/application server

As the Internet was opened up to general use and the Web introduced, thesurge of interest caused a change in the role of the Web HyperText TransferProtocol (HTTP) server. The Web server had to evolve from serving staticHTML pages to hosting Web applications serving live (dynamic) content.

From a static content model to a transactive modelThe use of the WWW has moved from a basic static publishing model to aninteractive application model.

Web Servers

DomainAbstraction

Layer

Application Servers


VisualServlet

Approach

GeneralCommand

DomainInterface

2

2

1 1


(NotImplemented)

CoreServices

(Not Applicable)

2

ServerConnector

Connectors

2

EnterpriseData and

Applications

FinderApp

Server

e-businessClient

VisualServletClient

FusionClient

2

1

Web Servers

DomainAbstraction

Layer

Application Servers


VisualServlet

Approach

GeneralCommand

DomainInterface

2

2

1 1


(NotImplemented)

CoreServices

(Not Applicable)

2


The e-business trends, starting with business-to-consumer use andcontinuing with business-to-business use, have resulted in expectations ofWeb applications that are usually associated with enterprise client/serverapplications. The interactive model is now evolving into a transactive model.

Extend the Web server or use separate application server?Since e-business applications are primarily server driven, this transactivemodel has resulted in the requirement that the Web server take on at leastsome of the role of a Web application server.

There are a number of divergent views on the role of the Web server versusapplication server. Some companies bulk up existing Web server products;others believe in the strict separation of Web and application server roles.Some vendors have added HTTP services to the application server.

However, the predominant view is that, while the Web server needs tobecome more sophisticated and robust, the use of a separate applicationserver provides the most flexibility. The Web server acts more like a userinterface server and a dispatcher for the application service requests.

Regardless of the physical arrangement of these servers and services, thereis reasonable consensus that, at least architecturally, Web services andapplication services should be considered separate elements.

10.2 Application architectural view

The application topology diagram shown in Figure 58 on page 205 positionsthe role of the Web/application server within the IBM Application Frameworkfor e-business.


Figure 58. Architectural roles of the Web/application server

This diagram adopts a viewpoint that sees the role of the Web/applicationserver as satisfying the requirements of three architectural layers, namely, aUser Interface Logic layer and a Business Logic layer separated by anabstraction layer.

The diagram shows the two approaches selected in Chapter 8, “Finderapplication experiences” on page 157. These approaches were described asthe Tactical Approach (1) and the Strategic Approach (2). The relevantelements in each approach are indicated with the appropriate number.

This chapter will focus on the part indicated in the diagram above.

For further reading, the reader is referred to a number of recent publicationsthat also propose this general architectural shape, albeit with differentterminologies, approaches, and emphasis:

• Developing an e-Business Application for the WebSphere ApplicationServer, SG24-5423, IBM, 1999

• Application Architectures with Enterprise Java Beans, ComponentStrategies, Chip Wilson, August 1999


Web Servers

DomainAbstraction

Layer


(NotImplemented)

CoreServices

(Not Applicable)

EnterpriseData and

Applications

Application Servers


VisualServlet

Approach

FinderApp

Server

CommandLayer

ServerConnector

e-businessClient

VisualServletClient

FusionClient

DomainInterface

Connectors

2 22

1 1

1

1

1

Static HTML pagesDynamic HTML TemplatesWeb ServerPrograms/ComponentsClient Scripts/ComponentsPage Content etc.

Transaction StateApplication StateMetadataBusiness Data

The Web and application server 205

• The J2EE Application Programming Model, Version 1, Sun Microsystems,September 1999

• IBM Application Framework for e-business: Structuring e-businessapplications, White Paper, Mike Conner, IBM Web Site, 1999

10.3 User Interface Logic design considerations

This section describes and highlights the design considerations and issuesfor elements within the User Interface Logic component of theWeb/application server part of the application.

Chapter 9, “The e-business client” on page 177, focused on the design of theapplication user interface from a presentation and client device perspective.This section focuses on the design of the server side user interface logic andthe technical infrastructure required to support these presentationrequirements.

In an e-business application, the Web server plays a major role as the userinterface server. In response to a client request, the Web server invokes aprogram that dynamically generates HTML or some other form of markuplanguage representing the user interface. Based on data contained in therequest, the program generates HTML. This may only involve program logic,but, more typically, it involves access to an enterprise system. The programmay also adjust the response using information about the client device.

10.3.1 Java-based dynamic HTML generation technologies

Java servlets and Java Server Pages (JSP) were the Web server technologiesselected to implement dynamic HTML processing for this project. Before describ-ing how these technologies were used to support user interface logic, a briefintroduction to these technologies is necessary.

10.3.1.1 Java servletsServlets are server-side Java programs that run inside a Java-enabled Webserver or application server. Java servlets are to a Web server what Javaapplets are to Web browsers. Servlets are loaded and executed within a Webserver and applets are loaded and executed within a Web browser. Servletsare defined by the Java Servlet API. This API defines a standard interfacebetween a servlet and a Java-enabled server. This makes them portableacross these servers.

10.3.1.2 Accessing servletsServlets are accessed from a Web browser in several ways:


• HTML forms - Servlets are commonly the target of the Submit button inHTML forms. User input is passed to the servlet using the HTML formPOST or GET methods. A servlet wishing to respond to these methods willimplement a doGet and/or a doPost method.

• Hypertext links - Servlets can be the target of a hypertext link in thesame way as any other URL. The service or doGet method of the servlet isinvoked. Servlets can also be invoked using other requests, such as PUTand DELETE.

• SERVLET tag - Some Web servers support the HTML SERVLET tag orsupport servlets as server-side includes. The servlet’s service or doGetmethod is invoked, and the output is placed in the HTML page replacingthe SERVLET tag.

• Other servlets - Servlets can access other loaded servlets. Themechanisms for doing this vary with the Servlet API version. This is anevolving area within the Servlet API. A subsequent section will discuss theoptions in more detail.

10.3.1.3 JavaServer pagesJavaServer pages are based on a server side scripting technology that allowsfor dynamic generation of the response on the server. Using JavaServerpages, scripting language can be directly embedded inside an HTML pagebetween special markup tags. Java is the only scripting language supportedat the moment. This means that the page can access business logic throughJava and/or JavaBeans.

A traditional servlet uses an output stream to write HTML code to the Webserver for display in a browser. However, programmers who write servlet codein Java are not always the most appropriate people to design the userinterface. The use of JavaServer pages can separate the task ofprogramming servlets from that of designing HTML pages.

A number of classes of JSP-specific markup tags are provided. An importantset of tags are those available to access properties of JavaBeans.

The set of JSP tags and their format change with each version of the JSPAPI. The most recent direction for these tags is to use an XMLrepresentation. This accommodates extensions to the set of tags moresmoothly, is a platform independent approach, and is convergent with thedirection of HTML.


How JavaServer pages workThe first time a Java Server Page is invoked (or whenever it is changed), it isparsed into a Java source file containing a servlet, then compiled andinitialized. Once the servlet is initialized, the service method is invoked. Forall subsequent requests, the service method of the existing servlet is invoked,and the output of the servlet, the combination of the static and dynamicelements (created through JSP elements), is sent to the browser as shown inFigure 59. A Java server page has an extension of .jsp in order for it to beidentified by the server as a JSP file.

Figure 59. JavaServer pages compilation process

10.3.2 Using an approach based on design patternsThe team also made the decision to adopt a certain pattern of usage ofJava-based dynamic HTML generation technologies. The use of patterns is ageneral design strategy and is not limited to User Interface Logic. Furtherexamples of the use of patterns will be introduced in subsequent sections.

10.3.2.1 Defining a design patternDesign patterns are commonly recurring structures of communicatingcomponents that solve a general design problem in a particular context.

The Model-View-Controller pattern described below is an example of such apattern. This is one of the earliest examples of a design pattern. It arose outof a user interface class library design for the Smalltalk language. There aremany variations on this pattern.

For further reading, the book Design Patterns - Elements of ReusableObject-Oriented Software, by Gamma, Helm, Johnson, and Vlissides, is thedefinitive introduction and reference book. This book is already considered aclassic in the field of software development.

JavaServerPage

TemporaryJava

Source

Web PageLoadedServlet

HTML

Compiled

Parsed

HTTP Requestor

callPage

WebBrowser


The IBM San Francisco project is a good example of a large Java-basedsoftware architecture that makes heavy use of design patterns.

10.3.3 The Model-View-Controller (MVC) patternThe MVC pattern divides an interactive application into three components.The Model contains the core functionality and data. Views display informationto the user. Controllers handle user input. Views and controllers togethercomprise the user interface. A change-propagation mechanism ensuresconsistency between the user interface and the model.

ModelThe Model is the core data representation stripped of any user-interfaceconcerns. Other descriptions of the model include application and businessfunctionality as well as data. In our usage, the model is being treated as if itwas a business data object. It may or may not directly expose business logicas methods.

The model is usually capable of generating an event when its data ischanged. This allows all connected views to be advised that a change hastaken place and that they should update their presentation to reflect thechange.

ViewThe view represents the presentation of the data to the user. There may bemany different kinds of views, such as tabular, report, and bar-chart, on thesame data.

ControllerThe Controller processes user-actions on a view and updates the model inresponse to these actions.


10.3.4 Applying the MVC patternThe Model-View-Controller pattern can be used to structure the usage ofJava servlets and JavaServer pages. This section discusses the rationale forthe selection of JSP or Servlet to support each specific element within thispattern.

10.3.4.1 View design considerations: JSP or Servlet?In servlet only applications, the servlet is both the controller and the view(HTML is coded in Java or read from a file). This has disadvantages. If theServlet is used to generate dynamic content, any changes made to the formatof the output also require that the Servlet be recompiled. This makes theapplication more difficult to maintain, particularly if there are frequentchanges to the format of the output.

There are frequent references to the MVC pattern in documents describing thestructuring of user interface logic elements of a Web application. In research-ing the original pattern and its evolution, it will be found that the MVC is actu-ally a slightly fuzzy arrangement of these elements involving a number ofsub-patterns. It actually proved difficult to find a consistent model/diagram.

There are many variants and much on-going discussion as to the relative mer-its of these variants. Many descriptions focus mainly on the interaction patternbetween the Model and the View.

The role of the controller is less clearly documented. In the original usage, thecontroller represented the user interface Input mechanism. This is typically notthe same role as is ascribed to the controller in Web server application archi-tecture documents.

In the context of this book, this pattern is used more as a structuring mecha-nism. Certain sub-patterns, such as model change-propagation, are not beingused, and some elements are used in a different role, for example, the Control-ler, thus, it is probably more correct to say that the design is influenced by theMVC.

However, the key feature of the pattern, the division into Model, View, andController responsibilities with specific rules defining their interaction is main-tained.

Note


Given the previous point and the close association between the JSP pageand the HTML page as it is returned to the client, the JSP page is a morenatural choice for the View.

Using Java and Java Beans in JSPA Java Server Page can contain Java code and/or bean tags to represent

dynamic content.

In the first approach, the Java code is embedded directly inside the HTMLdocument. Having any more than a trivial amount of programming logicmingled with HTML/JSP markup in a single document can make forunreadable code. It also makes it difficult to separate roles in a developmentteam. The HTML and Java code are tightly-coupled.

In the second approach, the bulk of the programming logic resides in JavaBean components. JSP bean tags are used to request information from thesecomponents. This information is then inserted into the HTML document. Thisapproach has the advantage in that it facilitates a cleaner separation of rolesin a development team. The programming logic is contained insidecomponents that would be the responsibility of a Java programmer. There isalso an increased potential for reuse of these components in multiple pages.

Supporting multiple client devicesExtending the discussion slightly, for the e-business application, it is possibleto see the View as being split between the server and the client. The JSP canbe considered as a View server or constructor and the client device as theView renderer.

This interpretation has relevance in a situation where a markup-basedapplication must support multiple classes of client device. Each device mayhave significantly different presentation capabilities. For example, ane-business application may be required to simultaneously support a browserclient and PDA or mobile phone clients.

It seems highly likely that Extensible Markup Language (XML), ExtensibleStylesheet Language (XSL), and Cascading Style Sheets (CSS) standardswill play a significant role in this area.

XML can represent both the interface definition and the data in an abstractand platform-independent fashion. XSL can be used to transform XML data tosuit the capabilities of the device. XSL and CSS can be used to transform theXML into the markup (or other representation) representing the presentationappropriate to the device.


Any form of dynamic device adaptation requires information about the deviceto be present in the incoming request. Given this information, it may also bepossible for the server side logic to decide that the device is itself capable oftransforming the data into the presentation and provide only the data or thedata and presentation instructions as XML or XML and XSL responses. Thisallows the server to selectively off-load processing. This is an area for furtherresearch.

10.3.4.2 Controller design considerationsAll applications need a point of control to mange the flow of the application. Inthis MVC usage, the role of the controller is slightly extended from the originaldesign pattern to become the controller of the flow of the application.

Use JSP or Servlet to implement the controller?In a JSP/Servlet based Web application, the controller can be implementeddirectly in JavaServer Pages or in servlets that then invoke JavaServerPages.

If JavaServer Pages are used as the controller, browsers make requestsdirectly to a Java Server Page. After receiving the client request, the JSPrequests information from server components. These perform any necessarycomputation and encapsulate the business logic. The JSP processing theninserts the results of the computation into the HTML that is rendered andinterpreted by the Browser as normal.

In this case, controller code and view code are mixed in the same component.This may make maintenance of the application more difficult. In addition, thetools currently available for Java development do not have strong support forJSP/HTML development and vice-versa.

If servlets are used as the controller, browsers invoke servlets that theninvoke JavaServer Pages. The Java Server pages would access only theinformation needed to display results.

Using the Servlets as the controller has the following benefits:

• The view and controller code are logically separated.

• The best tools for Java and HTML/JSP can be used without trying tocombine them.

• Java developers and HTML developers are not working on the same code.

A JSP/JSP approachA hybrid approach has emerged in which both the view and the controller areimplemented as JSP, but the separation of roles is strictly maintained. A


Controller JSP contains only Java, while the View JSP contains only HTML,JSP-specific tags referencing Java beans and minimal glue code. There aresome advantages to this approach to the controller:

• The Java developer does not need to know about servlet classes (the JSPwill automatically be converted to a servlet upon compilation).

• There is automatic recompilation by the Web-server when a change isdetected in the code

10.3.4.3 Model design considerationsThere were two key elements to the model as it was introduced in theprevious section:

• It represents pure business data stripped of any presentation details.

• It has the ability to notify listeners of change. This second feature is noteasily exploited in a Web context since the client always initiates theapplication actions. The client is also essentially anonymous to the servermaking it impractical for the server to advise clients of a change.

In our usage, the focus is on the model as a data representation.

The Controller (Servlet) and the View (JSP) share update access to themodel data. The Controller manages the life-cycle aspects of the model, thatis, it is responsible for creation, deletion, etc. In a Java environment, themodel is likely to be a standard Java Class instance, an Interface or a JavaBean. The Model can be seen as being populated as a result of a call to anapplication service or being something returned by that service.

The sharing of the Model between a Servlet and a JSP page can take placeat the session level. This means that the data is available to all participatingelements in the current session. In this case, decisions need to be madeabout the lifetime of the data. Alternatively, model data can be shared at theresponse level. In this case, the data is only available to the specific JSPinvocation with the Model data that is usually only retained for the lifetime ofthe JSP page.

Using View BeansThere are two options with respect to the representation of this shared data. Itis possible to share the actual Model instance or a specialized Java Bean thatis created and populated by the Controller from the Model and made availableas a Java Bean (a View Bean).

While creating a specialized View Bean adds another layer of abstraction, ithas the following advantages:


• The View is not coupled to a specific Model.

• The View Bean can be designed for efficient processing with JSP tags.

10.3.5 The Interaction controllerThe controller is a critical element of the design. It controls the flow of theapplication as the end-user perceives it. This is especially true as theapplication complexity increases.

It is being called the Interaction Controller to emphasize the increased scopein the role of the controller. The Interaction Controller must address twosignificant problems:

• The problem of hard-coded control flow

In a conventional Web site, static URLs in each page control the flow. Thisintroduces both a maintenance problem (keeping the links valid) and areuse problem (the application flow is hard coded into the page); it isdifficult to control the reuse of a page in another context.

This is a not a new problem. It has plagued developers of large applicationsystems from the outset of computing.

• The problem of complexity introduced by the hypertext model

Compounding the above problem is the navigation complexity introducedby the hypertext model. Any page can contain any number of links to anyother page. The target page of this link may not be within the application.The same mechanism makes it possible for a Web user to navigatedirectly into an application at some arbitrary point in the applicationprocessing. This has serious implications for security and for maintainingthe integrity of business processes.

This is a relatively new problem, especially to client/server developers.

10.3.5.1 Servlet/JSP control flow mechanismsThis section describes the available control flow mechanisms in more detail.The aim is to highlight those mechanisms that offer the most potential fordesigns that reduce the impact of the described problems. This decision ismade more complicated by the differences between Servlet/JSP APIversions. Table 47 shows JSP to servlet flow control.

Table 47. JSP to servlet flow control

From To Mechanism API

HTML ServletLink (GET) Servlet (All)

Form (POST) Servlet (All)


Comments: The Web server can invoke a servlet in response to a clicking link or formaction button on an HTML page in the same manner for any other form of Web serveractivated program. These mechanisms have been included here for completeness. Thetarget URL is static.

HTML Servlet <servlet> Tag Servlet (All)

Note: Also called a server-side include. The file usually requires an .shtml extension forthe server to process the tag. The servlet named in the tag is invoked, and the outputreplaces the tags in the response. The target URL is static.

Servlet Servlet sendRedirect() Servlet (All)

Note: This is a method on the HttpServletResponse object. The response is sent withheader/content settings to cause the browser to redirect a request for a new URL. Thiseffectively transfers control to a new URL.Fully qualified URL. The target URL can be static or dynamic.

Servlet Servlet forward() Servlet (2.1)

Note: This is a method of the Request Dispatcher object. It dispatches the request to aJSP or servlet. Control is transferred to the named page.With a relative URL, the target URL can be static or dynamic.

Servlet JSP callPage JSP (0.9*)

Note: This is not available in JSP 1.0/JSDK 2.1.It requires type casting the response to a com.sun.server.http.HttpServiceResponseobject. Control is transferred to the named page.With a fully-qualified URL, the target URL can be static or dynamic.

Servlet Servlet include() Servlet (2.1)

Note: This is a method of the Request Dispatcher object. Includes the content of a staticobject, such as HTML, or a dynamic object, such as Servlet or JSP. Control returns tothe calling Page after the include call.With a relative URL, the target URL can be static or dynamic.

HTML JSPLink (GET) JSP (All)

Form (POST) JSP (All)

Note: The Web server can invoke a JSP in response to a clicking link or form actionbutton on an HTML page in the same manner for any other form of Web server-activatedprogram.These mechanisms have been included here for completeness.The target URL is static.

JSP JSP, Servlet,HTML?

forward (Action) JSP (1.0)



As shown in Table 47, there is basically one set of pre-JSDK2.1/JSP1.0capabilities and a different set for JSDK 2.1/JSP 1.0 or later. It should also beclear that the include() and forward() methods of the more recent APIsrepresent the best mechanisms (of those currently available) upon which tobase Interaction Controller design. They are also consistent in usage andnaming between Servlet and JSP.

10.3.5.2 An illustrative exampleThe diagram below is from an application design in the redbook Developingan e-business Application for the WebSphere Application Server, SG24-5423.As an illustration of the problem (and a quite realistic scenario) consider thatthe migrated Finder application is to be incorporated into the same Web site

Note: <jsp:forward page=…/>This dispatches the request to a JSP or servlet. Control is transferred to the namedpage. With a relative URL, the target URL can be static or dynamic. It is evaluated atrequest time, thus, the value of the file attribute can be a JSP expression.<jsp:forward page=’<%=nextPage %>’/> OR pageContext.forward(NextPage);

JSP JSP callPage JSP (0.9*)

Note: This is not available in JSP 1.0/JSDK 2.1.It requires type casting the response to a com.sun.server.http.HttpServiceResponseobject.

JSP include (Directive) JSP (All)

Note: <%@include file=..%> This is intended for including static resources, such asgraphics or HTML, but these files may include JSP elements. Content is parsed by theJSP processor.Relative URL.The target URL is static.Evaluated at translation time, thus, the value of the file attribute cannot be anexpression.

JSP JSP, Servlet,HTML?

include (Action) JSP (1.0)

Note: <jsp:include page=…/> This includes the content of a static object , such asHTML, or a dynamic object, such as Servlet or JSP. The JSP processor does not parsecontent.Control returns to the calling Page after the include call.Relative URL.The target URL can be static or dynamic. It is evaluated at request time, thus, the valueof the file attribute can be a JSP expression.<jsp:include page=’<%=header %>’/> OR pageContext.include(header);



as the bank application and that the Login functionality is to be reused. Thefunctionality to be reused is shaded in Figure 60.

Figure 60. How would we reuse the Login functionality for our application?

• The model may need to be changed. The original application maintained aCustomerView bean stored in the session. This bean is created by theLogin servlet upon successful login and updated with user details. Thisbean acts as a model for global information. As the scope of a systemincreases, it may be preferable to create a specialized Authentication ViewBean purely for authentication purposes. The Interaction Controller couldcreate this bean from the model.

• The authorization check in the LoginServlet presumes the existence of aspecific class of object, the Bank object. From a reuse perspective, itmight be advantageous to provide methods on the AuthenticationViewBean to validate the user and hide the identity of the authorizer. TheInteraction Controller could then delegate calls to the authorizing class.

• The control transfer upon successful Login is hard coded to always flow tothe Accounts JSP. This is not appropriate for the Finder application. Itwould be preferable if the decision regarding the next action weredelegated to an Interaction Controller.

10.3.5.3 Design goalsThe previous discussions suggest the following points as goals or, at least,desirable traits for the interaction controller:

Login ServletLogin.jsp

UnsuccessfulLogin.html

Bank

CustomerView

account.jsp

unsuccessful

successful

Session

storeCustomerView

submitlogin

getCustomer


• It should manage control transfer between a set of sub-servlets. Forexample, it could exploit a mechanism, such as the include() using theseservlets to build up the response. Such servlets are designed to emitHTML and do not have any control transfer statements. Alternatively, theforward() mechanism could be used, but each secondary servlet alwaystransfers control back to the controller.

• Only the interaction controller has knowledge of control transferinformation.

• The interaction controller should only use methods that do not requirehard-coded control transfer target information.

• The interaction controller is responsible for the life-cycle of models and/orview beans.

10.3.6 User Interface Logic issuesFrom the migration perspective, the client logic of the Finder application hadto be reimplemented using the new architectural elements introduced by theuse of Web/Application. For the first migration stage, this covered the logic tosupport basic search functionality.

10.3.6.1 JSP development tools are limitedThere is currently a lack of JSP development environments. IBM Web SphereStudio 3 showed potential but was not released at the time. The beta versionpreviewed briefly only seemed to support JSP 0.9* or IBM-specific JSPmarkup.

A selling point of JSP is that it supports the separation of roles. However, thisrequires that there be a suite of development tools that are trulycomplementary with respect to the different aspects of development or thatthere is an integrated development environment suited to both roles.

Tools that support round-trip lossless interchange and an environment thatsupports end-to-end debugging are required. Round-trip debugging isespecially important in this environment.

DecisionsThe Tactical migration strategy adopted the approach to fully exploit IBMVisualAge for Java. The Visual Servlet Composition editor was used toconstruct all aspects of a basic user interface.

However, this environment currently does not provide an interface suited to aWeb page developer, provides only basic page layout capabilities, and doesnot support the addition of JSP elements.


The Strategic migration strategy adopted the approach of tool independence.The Web pages were designed using NetObjects Fusion 4.0. These pageswere then published in HTML form. The HTML was then manually convertedto JSP using a simple Windows text editor. Once this change was performed,it was not possible to reimport these pages back into Fusion.

10.3.6.2 Servlet/JSP API stabilityThe Interaction Controller section highlighted some of the differencesbetween different levels of the Servlet/JSP API with respect to control transfermechanisms. The variation in markup tags between JSP tags for each of thereleases was more severe.

These APIs are going through rapid evolution, and the development andWeb/application server products have to play catch-up. It can be difficult tofind products that are at the same level of current release of the Servlet/JSPAPIs.

DecisionsFor our particular project, the level of development was quite low.Consequently, API limitations were not a problem. Most development tookplace at 0.9* levels, although the later APIs were investigated. It isrecommended that any planned development move to JSDK 2.1/JSP 1.0 levelor later as soon as possible. The choice of an earlier version of these APIscan negatively influence design decisions.

This may require the interim use of basic development tools, such as texteditors, basic HTML layout designers, and free servlet runners, such asAllaire, JRUN, or the Sun Java Server, supplied with the referenceimplementation in order to start development at the desired level.

10.3.6.3 Usage of servlets and JSPThe use of Java servlets and JSP to build Web-applications is relatively new.Best practices have yet to fully emerge. In a large e-business application, anyconsistent and valid logical structure is preferable to ad hoc design during theimplementation phase. The use of the Model-View-Controller pattern as anapproach to structuring Servlet/JSP is one emergent practice.

DecisionsThe Servlet (Controller)/JSP (View) combination was used for the Strategicmigration strategy. The Tactical strategy used a Servlet (Controller)/Servlet(View).

Both strategic and tactical approaches shared the actual model. In thetactical approach, the model was a single Data Object bean managed by the


Interaction controller and stored in the Session. It contained all applicationinformation and was common to all subsidiary servlets to the Interactioncontroller.

The Strategic approach used a very basic MVC implementation. Thecontrolling servlet treated the Query as the Model and shared it with the JSPview at the page level.

The View Bean approach allows a finer degree of control over data visibilityand coupling and is probably a better approach in situations where theapplication model is complex.

10.3.6.4 The Interaction controllerThe main issues associated with managing e-business application flow arerelated to the hard coding of links and the increased navigational complexityintroduced by the hypertext model. This leads to increased responsibility forthe Controller in the MVC pattern usage.

The control transfer options available when using Servlets/JSP and thepossible approaches and issues have been described in a previous section.

Some issues remain to be resolved. These decisions will need to be made ona per-application/system basis. It may be that some hybrid arrangement isneeded. From a coding and maintenance perspective, it would certainly bepreferable if the approach to interaction control were consistent across anyspecific system.

• Is the controller role transferred to each servlet (distributed flow control),in which case the Interaction control mechanism must be accessed fromor included in each page/servlet, or is there one Interaction controllerservlet acting as a kind of central dispatcher of Views?

• If there is one interaction controller, how many servlet/JSP items should itmanage (this is a span-of-control issue)

• In a large application system and assuming one Interaction Controller foreach single business task represents a typical approach, will a stage bereached where a set of Interaction Controllers are themselves managedby an Interaction Controller?

DecisionsThe Strategic migration approach only implemented a basic static controltransfer mechanism. This was due to a lack of time and is not arecommended approach.


The Tactical migration approach implemented an advanced approach to theinteraction controller. This approach exploited the capabilities of the VisualServlet Bean class provided by Visual Age for Java. This design has thefollowing features:

• The Interaction Controller acts as a dispatcher for a set of subsidiaryservlets. Each of the subsidiary servlets implements a processing step inthat task. To the client, this controller servlet appears to implement asingle business task.

• Security and business logic integrity are improved since all the e-businessclient ever sees is a single URL. It is not possible to directly navigate oraccess the subsidiary servlets via a URL.

• Control flow is not coded into the subsidiary servlets. Each servlet is alsoa bean and, as such, can generate events. These can be used todetermine the outcome of that particular processing step. The Interactioncontroller supplies listeners to any events of interest. These listenersmake the control transfer decisions. This decouples the subsidiary servletfrom the Interaction controller and any specific control flow. This greatlyimproves reuse.

• The Interaction controller manages a single Data object that acts as acommon model object for all subsidiary servlets.

However, this approach does not use JSP, and the mechanism is tied not onlyto IBM Class Java Libraries but also to Visual Age IDE/VisualComposition-related classes. It is not clear how a Web content developercould be incorporated into the development process using this approach.

10.4 Domain Abstraction Layer design considerations

This section describes design considerations and highlights issues forelements within the Domain Abstraction Layer of the Web/application serverpart of the application

This section describes the domain abstraction layer. This layer separates theApplication User Interface-related elements from the Business Logicelements.

The name of this layer should only be considered as a working title. A numberof similar approaches have occurred in various documents (each author hasused a different name). Over time, a consensus may be reached. It is moreimportant to consider the rationale for including such a layer, its intendedpurpose, and design considerations and issues.


The reasons for including such a layer were briefly introduced in Chapter 8,“Finder application experiences” on page 157. These are revisited in moredetail in the following section.

10.4.1 Separation of roles and skillsThe separation of the Web server parts of the application into interactioncontroller (controller), page construction (view), and content and businessdata (model) allows the people with the most appropriate skills to work on therelevant parts of the application.

This principle can also be applied at another level. In most enterprisesystems, changes to core business logic and the associated data structuresoccur at a significantly lower rate than the requirements for changes toapplications. It is also a common requirement for an application to need topresent different views on the same data or to have multiple applicationsshare common business logic or data.

There is also a different set of developer skills required when developingserver component technologies (especially when this involves distributedtechnologies) than when developing client applications.

The use of an abstraction layer that cleanly separates these elements allowsthem to evolve relatively independently on different schedules, and this cancontribute to a shortening of the overall development time. This is veryimportant in an Internet environment where changes to the user interface andthe client facing parts of the application must be carried out quickly inresponse to market forces.

10.4.2 Separation of distributed and non-distributed technologiesIt is rare to find a complimentary suite of development tools (and almostimpossible to find a single integrated development environment) that fullysupports the entire range of development in such a way as to be acceptableto the different classes of developers involved. For example, many client RADdevelopment tools do not yet incorporate distributed components into the IDEwith anywhere near the same facility that they can incorporate Java Beans

An abstraction layer can be used to hide distributed technologies from clientapplication developers. This allows the developer (and the development tool)to deal with local components, such as Java Beans. However, thesecomponents are actually clients of distributed components, such as EJB.


10.4.3 Independent evolution of technologies and platformsThis point follows from the previous two points. The rate of change ofe-business technologies is very high. This is especially true for the Javaplatform. An abstraction layer should provide some isolation to Webapplication developers from changes to server component technologies andplatforms and vice versa.

10.4.4 Performance and scalability in a distributed environmentScalability is a major requirement of an e-business application and one of themain reasons for adopting a multi-tier architecture. However, thenetwork-dependant nature of such a solution and the introduction ofdistributed processing require careful design to achieve acceptableend-to-end performance.

The key to success is to minimize the number of round trip messages thatflow across the tiers in a distributed application and to exploit caching atevery point in the architecture where this is practical and appropriate.

10.4.4.1 Minimizing network trafficA good object oriented design for a business domain is likely produce a largenumber of fine-grained business objects. In such a model, the interactionsbetween these objects may involve a large number of method invocations andfrequent transfers of small amounts of data to achieve a business task.

A direct implementation of such a fine-grained model may perform acceptablywhile all objects are interacting in the same address space. However, as soonas these calls cross a network boundary, the communication overhead has adramatic impact on performance.

A major rationale for the introduction of the domain abstraction layer is toaddress this issue. It is an approach that trades off design granularity atcertain points in the architecture to achieve a reduction in round tripmessages. The challenge is to provide an abstraction that is still meaningfulin business terms for interactions that must cross network or processboundaries while still allowing the interaction of fine-grained objects within aparticular tier.

From a performance perspective, the ideal Web server/application serverinteraction supports a complete business transaction in a single networkrequest.

Many of the lessons learned about performance in distributed environmentscome from experience with the Corba ORB-based applications. Some tips on


improving the performance of Corba can be found athttp://www-4.ibm.com/software/developer/web/patterns/ebusiness-performance

-customer-v2.pdf

These will apply equally well to any distributed environment.

10.4.4.2 Support for cachingThe domain abstraction layer is a software layer. It is designed to straddle thenetwork boundary between the Web server and the application server andhas software elements on both sides of the network. Most interactions will beinitiated from the e-business client. These will be processed by theWeb-server, and any requests for business logic services will have to passthrough the domain abstraction layer. The client side of this layer is an idealposition to place caching mechanisms.

10.4.5 Some design approachesThis section gives a brief overview of some of the approaches to the design ofthe Domain Abstraction Layer.

10.4.5.1 Facade approachThe design patterns book by Gamma et al describes a Facade pattern as“providing single, simplified interface to the more general facilities of asubsystem”.

An example of the use of the facade approach is documented in the IBMRedbook, Developing an e-Business application for the WebSphereApplication Server, SG24-5423.

In this book, the term Domain Firewall is used to describe this layer (seeFigure 61). All interaction with the domain is channeled through the firewall,and the client application is isolated from any changes in the implementationof the business logic.

The implementation of the firewall consists of a set of Java interfaces andclasses. These types provide access to all the necessary functionality of theapplication (a home banking application), thus, the layer provides a clientapplication view of the business object model expressed in domain terms,such as BankAccount.getBalance or Customer.changeLoginPassword. Themain rationale for the abstraction layer was isolation from changes in theimplementation of the business model.


Figure 61. The concept of domain firewall

10.4.5.2 Controller approachIn this approach, a controller is used to manage interactions between theuser interface layer and the business logic. The role of the controller as amediator of interaction is the same in this context as it is in theModel-View-Controller usage.

Application model layerThis approach is advocated by Chip Wilson in the article,”ApplicationArchitectures with Enterprise Java Beans”, in the August 1999 edition of theComponent Strategies magazine.

This article proposes a four-tier architecture: A View layer (user interfacelogic), an Application Model layer (abstraction domain), a Domain layer(Business Logic), and a Persistence layer.

The Application Model mediates between the View and Domain layers. Themain rationale for this layer was to abstract application specific behavior frombusiness logic.

This layer contains three elements:

• View controllers - These are the equivalent of the Interaction controller.

• Use Case controllers - These act as dispatchers of requests forserver-side services associated with specific use cases

Domain FirewallWeb Application Business Model


• Model adapters - These are responsible for adapting the interfaces ofdomain classes to interfaces required by view layer classes.

Thus, in this architecture, the abstraction layer also contains some of theModel-View-Controller functionality. This layer is something of a hybrid of thefacade approach and the controller approach.

View controllers and model adaptors were implemented as Java Beans. UseCase controllers were implemented as stateful Session Enterprise beans. It isthe Use Case controller mechanism that best maps to the architecturalfeature being addressed in this section.

Logic controllerThis is the design described in the Sun document, The J2EE ApplicationProgramming Model, Version 1, Sun Microsystems, September 1999. In thisarchitecture, an object called the Logic Controller manages interactionbetween the User Interface layer and the Business Logic layer. The role ofthis controller is virtually identical to that of the Use Case controller describedin the previous example.

This document is currently marked as a beta draft. The design describes theLogic Controller as a representative of a server side controller component inthe Web tier. It is not completely clear whether this is a separate object orsimply an alias for the client reference to this server-side controller. Theserver-side controller component is implemented as a stateful SessionEnterprise bean.

10.4.5.3 Command approachThe final design approach to be described is based on the Command pattern.This approach is presented in an IBM white paper entitled “IBM ApplicationFramework for e-business: Structuring e-business applications”, White Paper,IBM Web Site, 1999 and written by Mike Conner.

A command is an object that represents an action. In this context, eachbusiness logic interaction is represented as a command. In its most basicform, a command supports a set of input and output parameters and anexecute method, thus, in this approach, the Domain Abstraction layer isrepresented by a set of commands.

In this white paper, the rationale for the use of the command pattern was asan isolation layer and mechanism for reducing network traffic.

For our project, the tactical migration strategy adopted a facade approach. Athin layer was implemented to isolate the Web server logic from the connector


implementation. The strategic migration strategy implemented a commandlayer influenced by the aforementioned IBM White paper.

10.4.6 Command layerThis section describes the command layer.

10.4.6.1 The basic command patternAs stated previously, a command is an object that represents an action. It iswell-suited to represent a business transaction. The Command patterndecouples the object that invokes the operation from the one that knows howto perform it. As an abstraction layer mechanism, the Command pattern isuseful. New commands can be added without impacting a client application.There is no change to the interface or the semantics.

An object model of the participating objects in the basic command pattern isshown in Figure 62. A brief explanation of the role of each participating objectfollows.

Figure 62. The standard basic command pattern

CommandA command is an abstract class defining an interface for executing acommand.

ConcreteCommandThis represents a binding between a CommandTarget object and an action.


It is a particular class of command, such as a searchDirectory, thatimplements execute() to perform the appropriate action by invoking thecorresponding action on the command target.

CommandTargetThis object knows how to perform the operation.

ClientThis object is responsible for creating the ConcreteCommand instance andbinding this command to a particular CommandTarget. The term Client shouldnot be confused with e-business client.

InvokerThis is the object that wishes to perform the action. This object will usuallyknow about an appropriate set of commands for its purposes.

10.4.6.2 The project command pattern implementationOne of the explicit objectives of the strategic migration strategy was to set inplace an abstraction layer that would support the introduction of a separatebusiness logic layer without impacting the User Interface layer. The commandpattern was used for this purpose. The goal was also to explore someaspects of the command approach described in the aforementioned IBMwhite paper by Mike Conner.

Figure 63 on page 229 illustrates the incorporation of the command managerinto the command model.


Figure 63. Incorporating the Command Manager into the Command Model

Some differences and extensions from the basic command pattern areevident. There are also differences from the white paper.

Command, TargetableCommandThese are defined using interfaces instead of classes. Interfaces can providemore implementation flexibility since any class can implement an interface.However, within this particular model, explicit (but abstract) implementationsof the Command classes were required.

The creation of a separate TargetableCommand interface allowed for theoptional use of a CommandTarget. For example, for simple actions, it may bemore direct to execute the logic within the command by using the Commandclass.

CommandManagerThis object acts as a factory for commands. The Invoker requests a particularclass of command by a simple descriptive name. The CommandManagercreates an instance of a class of command associated with this name, bindsto the CommandTarget, and returns this instance to the Invoker. TheCommandManager knows the details of the command it creates by loading aset of CommandDescriptors. This is an extension of the white paper model(see Figure 63).


CommandDescriptorThis object describes the key details of a concrete command class. It definesa simple descriptive name, the name of the concrete command class,optionally, the class name of a concrete CommandTarget class, anExternalizationPolicy class, and a flag indicating whether the command is tobe executed remotely or locally.

The issue of remote execution was an area being examined. This was a corefeature in the white paper. The aim was to address performance problems byallowing commands to be shipped to a remote location for execution.

This descriptor represented a placeholder for a more detailed approach. Theintention was that the set of descriptors would be defined in XML format.(Currently, the data for the set of descriptors is hardcoded in theCommandManager class.)

CommandImpl, TargetableCommandImplThese classes represent generalized (but abstract) implementations tosupport the Command and TargetableCommand interfaces respectively.These classes were provided to allow an efficient factory mechanism and toallow the sharing of common internal logic across all concrete commandclasses.

CommandExternalizationPolicyThis object is an example of a Policy or Strategy object. It implements thedefault methods for serialization of Commands. Actually, the externalizationinterface was implemented. Making this a separate object allowsCommandDescriptor to specify an alternate class for externalizationpurposes. Commands had to be serializable to allow them to be shippedacross the network, reconstituted for remote execution, reserialized, andshipped back to the original invoker so that the results of command executioncould be accessed.

CommandParameterAn obvious omission from the basic pattern model was consideration of the

need to supply inputs and to receive outputs as part of command execution.The CommandImpl class supports dynamic creation of Input and Outputparameters. The CommandParameter class effectively represents ameta-data description of a parameter and an Object type field to hold itscurrent value.

The intent was to provide a consistent mechanism for concrete commandimplementations to internally define and represent their inputs and outputs.The implementer of the concrete command is free to express these Inputs


and Outputs in the class definition in as strongly a typed fashion and in asmeaningful a way as desirable.

This generalized mechanism (essentially a name value list representation)allows for shareable approaches for future additional logic, such as basicvalidation or management of default values.

CommandManagerServerThis is the interface to the distributed component that ships serializedcommands to a remote location for execution. The (local) CommandManagerhas a reference to this component. When a command is executed, and theCommandDescriptor indicates that the command is to be executed remotely,the CommandManager is invoked to hand off the transfer to theCammandManagerServer.

Only a preliminary prototype of this server was implemented.

CommandManagerServerStub, CommandManagerServerSkelThese represent client and server-side classes of theCommandManagerServer component. The distributed componentcompilation process usually generates these classes. These classes handlenetwork marshalling of parameters associated with remote methodinvocations.

CommandManagerServerImplThis class represents the distributed component implementing theCommandManagerServer interface. Only a preliminary prototype of thisserver was implemented as an RMI server.

10.4.7 Comparing approachesTable 48 on page 232 compares the different approaches; it initially appearedin the IBM Redbook Developing an e-Business application for the WebSphereApplication Server, SG24-5423. It compared the Domain Firewall andCommand approaches. It has been updated to include the Controller


approach. The Domain Firewall has been categorized as the Facadeapproach.

Table 48. Comparing design approaches

10.5 Business logic design considerations

This section describes the design considerations and highlights issues forelements within the Business logic component of the Web/application serverpart of the application.

There was insufficient time within the schedule for the team to do more thanexplore the issues associated with implementing a separate business logic

Facade Controller Command

Pros

Object OrientedInterface

One point of entry One point of entry

Expressed indomain terms

Matches well totransactionalsystems

Matches well totransactionalsystems

Client not impactedby additive typechanges

Client not impactedby additive typechanges

Assists consistentimplementation ofcaching strategies

Easily extended

Easy to implementlogging and undofunctions

Cons

May be complex toimplement

Lose objectoriented interface

Lose objectoriented interface

Many points ofentry

A span of controlissue exists

Client is potentiallyimpacted byadditive typechanges

May involvemanaging complexstate transitiongraphs

Not easy to supportparameters


tier. The main focus was how a multi-tier architecture might influence both themigration strategy and the design of the e-business version of the Finderapplication.

The approach to the implementation of business logic was one distinguishingfactor between the Tactical and Strategic migration strategies developed inChapter 8, “Finder application experiences” on page 157. An analogy couldbe made to the decision in client/server application design to implement atwo-tier and multitiered solution.

There is no single correct solution to the design of an e-business applicationwith respect to this decision. Such a decision is not made purely onarchitectural and technical merit. It is just as likely to be influenced by factors,such as the nature of the application, its expected lifetime, its importance tothe company, the delivery schedule, budget, risk, etc.

In any contemporary multi-tier e-business application, the development ofnew business functionality (as opposed to the development of mechanisms toaccess existing enterprise data and applications) will almost certainly bebased on server component model technologies.

10.5.1 Server component modelsServer component models have evolved out of distributed computing anddistributed object architectures. The component architectures have a greatlyincreased focus on the view of a component as a deployable unit offunctionality, the execution environment (commonly called a container orsometimes just an application server), the interfaces provided by each, andthe relationships between them.

Three main technology contenders are listed in Table 49. These were brieflyintroduced in Chapter 7, “Selecting technologies” on page 125.

Table 49. Component models

Component Model Openess Notes

OMG Corba 3 Language- andplatform-independent

Most current distributed object systemscurrently in production are based on OMGCorba II architecture. The CorbaComponent specification is part of CorbaIII. This specification has not yetcompleted the standardization process.


10.5.2 Enterprise Java BeansFrom an architectural perspective, each of these component models issimilar. From the perspective of the IBM Application framework for e-businessand for our project s requirements, Enterprise Java Beans was selected asthe most appropriate technology upon which to build the Business Logic tier.

The following paragraphs, adapted from the Sun document, The J2EEApplication Programming Model, Version 1, September 1999, provide a briefintroduction to Enterprise Java Beans. The reader is referred to the Java 2Enterprise Edition specification, and the Enterprise Java Beans Specificationfor further details. The IBM publication, "Enterprise Java Beans By Example",by Henri Jubin and Jurgen Friedrichs et al is also recommended as a goodpractical introduction to Enterprise Java Beans.

Enterprise Java Beans are server-side components and a core element of theJava 2 Enterprise Edition architecture. Components written using the EJBspecification are reusable units that contain business logic. Thesecomponents are scalable, transactional, and multi-user secure.

10.5.2.1 Servers and containersEnterprise beans are hosted by an EJB container (see Figure 64 on page235). The services provided by the EJB container, such as transaction andpersistence support, can be declaratively customized for an enterprise beanat deployment time. A distinction is made between the server and thecontainer. The server hosts the container. The server is also required to hostthe implementation of the set of standards services provided to the container.

To support portability of Enterprise beans between the containers of differentvendors, the EJB specification also specifies the mechanism and formats fordeployment (a Deployment Descriptor) and packaging (a Java Archive file).

Sun Enterprise JavaBeans

Platform-independent

Virtually all significant application servervendors, with the exception of Microsoft,have committed to support for EnterpriseJava Beans and the Java 2 EnterpriseEdition of which EJB is a core element

Microsoft COM+ Language-independentMicrosoft COM+ represents an evolutionof COM/DCOM, and a final form willprobably not stabilize until after therelease of Windows 2000.

Component Model Openess Notes


Figure 64. Servers and containers

There are two types of enterprise beans: Session beans and Entity beans.

Session beansA Session bean is created on behalf of a client and usually exists only for theduration of a single client-server session. A session bean performsoperations, such as calculations or accessing a database, for the client.Session beans can either be stateless or they can maintain state acrossmethod invocations and transactions. If they maintain state, the EJBcontainer manages this state if the object must be removed from memory.

Entity beansAn entity bean is a persistent object that represents data maintained in a datastore or delivered by an enterprise application. An entity bean can manage itsown persistence (bean-managed persistence) or it can delegate this functionto its container (Container Managed persistence). In the latter case, the EJBspecification provides a programming model for managing persistence. Incontrast to Session Beans, Entity beans can be shared by multiple clients.

The actual mapping of entity bean data to the data store is not fully specified.At present, the exact mechanism varies with the container provider. An entitybean exists as long as the data it represents exists in the data store. An entitybean is identified by a primary key.

10.5.2.2 EJB interfacesAn important feature of the EJB architecture is that the client never accessesthe EJB class directly. Access is always via interfaces implemented byintermediate remote objects created by the container as part of the

EJB Containerlife cycle managementimplicit transaction controlpersistence management

EJB

EJB EJBEJB

EJB EJB

EJB Serverprovides servicesfor the containerdistributedtransactionmanagement

Naming andDirectory

Transitions

Persistence

...


deployment process. This allows the container to maintain control of theinteraction.

The EJB specification defines two types of interfaces that must beimplemented by an Enterprise bean. The first is called a remote interface.This interface specifies the business functionality that the bean offers. Thesecond interface is called the home interface. This interface is used by theclient to locate, create, and delete instances of a specific EJB class. Theseinterfaces are also implemented by the remote wrapper objects generatedduring the deployment process.

10.5.3 Reexamining the migration process: Subsequent phasesThis section describes how the introduction of a separate business logic tiermight affect (and possibly assist) in the migration of a client/serverapplication.

10.5.3.1 Migration (Phase 1)The initial migration step of both approaches introduced the basic searchfunctionality (see Figure 65 on page 237). There was no introduction of newbusiness functionality other than that already provided by the existing Finderapplication server, thus, the business logic tier was empty. This step alsointroduced the following technical infrastructure elements:

• A browser-based client user interface

• Web server

• A connector layer that accessed the existing Finder application server

• An abstraction layer between the Web server elements and this connectorlayer


Figure 65. Strategic migration (Step 1)

10.5.3.2 Migration (Phase 2)In this stage, the existing Finder application services can be represented asreal server components (see Figure 66 on page 238). At this point in theevolution, each of these components is a facade, that is, the domainabstraction layer or any application server client sees a component interface.Internally, this component is simply using the connectors to access theexisting Finder application server as was being done in the previous step.

Web Servers

DomainAbstraction

Layer

Business LogicComponents

Core ServicesJNDI, JTS,

JDBC

EnterpriseData and

Applications

Application Servers

FinderApp

ServerProprietary

CommandJava Beans

EJB

Socket,JDBC

e-businessClient

BrowserHTML

Connectors



ControllerServlet

User InterfaceLogic

EJB

ModelJava

Beans

ViewServerJSP



At this stage, a further design decision needs to be made about how andwhen the domain abstraction layer interface should evolve to reflect thecomponentization of the Finder application server.

A command-style layer is relatively unaffected. The impact of the change islikely to result in additional commands. However, from the Web-server’sperspective, there is no change to the interface or the semantics. An object orinterface style layer may need to introduce new objects or change the existinginterfaces. This may have more impact on Web-server code.

In either case, the infrastructure for the business logic tier is now in place.The Connector layer and the Domain Abstraction layer are no longer coupled.

10.5.3.3 Migration (Phase 3)At this point, it becomes possible to progressively redevelop the existingFinder application services, integrate other services, or to develop newbusiness functionality as pure components as time and resources permit(see Figure 67 on page 239). These new components are no longer facades.They can coexist with facade objects, and the client cannot distinguish thedifference.

Web Servers

DomainAbstraction

Layer



JDBC

EnterpriseData and

Applications

Application Servers

FinderApp

ServerProprietary

CommandJava Beans

EJB

Socket,JDBC

e-businessClient

BrowserHTML

Connectors



ControllerServlet

User InterfaceLogic

ComponentsEJB

Java BeansModelJava

Beans

ViewServerJSP



10.5.4 Preliminary EJB-based designSome preliminary design notes for Business Logic implementation of theFinder application are included in Figure 68 on page 240. These should notbe considered as proven or final. The aim was to provide a starting point forthe first iteration of the second migration step. This would be aprototyping/proof of concept stage.

Web Servers

DomainAbstraction

Layer



JDBC

EnterpriseData and

Applications

Application Servers

CommandJava Beans

EJB

e-businessClient

BrowserHTML

Connectors



ControllerServlet

User InterfaceLogic

ComponentsEJB,

Java BeansModelJava

Beans

ViewServerJSP


Figure 68. Prelimary EJB-based business logic design

10.5.4.1 CommandManagerServerThis component is part of the command implementation of the DomainAbstraction layer. Its role is to ship commands at the request of aCommandManager in the User Interface logic to a CommandManager in theBusiness Logic layer for execution. There is more work to be done in thedesign of this component.

At this point in the design, there is a need for this component to beremoteable, but there is no requirement for persistence and no state involved.This component will be implemented as a stateless Session bean.

10.5.4.2 CommandManagerThis is an instance of the CommandManager to which the command is beingshipped. The responsibility of the CommandManager is to hand off executionto the CommandTarget.

This will be implemented as a Java Bean. Its life cycle will be managed by theCommandManagerServer implementation. Currently, the only staterequirement of the CommandManager is the internal list ofCommandDescriptors to support its role as a Command factory. Thisinformation is initially loaded from disk, thus, the CommandManager could bea shareable component. If there is an overhead issue, it may be appropriateto implement a read-only Entity bean wrapper object. This is the arrangement

DomainAbstraction

User InterfaceLogic

SearchResultModel

SearchResultView

BusinessLogic

Web Servers Application Servers

SearchController

CommandManager

connectsearch

disconnect

CommandManagerServer

DirectoryServiceManager

DirectorySession

EnterpriseCommandManagerCommandManager

connect

search

disconnect

Connectors


shown in the diagram. The wrapper Entity bean has been given the workingname of EnterpriseCommandManager.

10.5.4.3 CommandThe description and role of this component is unchanged from the descriptionin Section 10.4.6, “Command layer” on page 227. It is implemented as a JavaBean. For the initial iteration of the first migration stage, there would be threeconcrete command classes representing application tasks along the lines ofthe functionality shown below:

• Connect (IN UserAuthDetails, OUT DirectorySession)

• Search (IN DirectorySession, IN Query, OUT Result)

• Disconnect (IN DirectorySession)

The descriptor for these commands would specify these as RemoteExecutionand specify a CommandTarget class.

It will also be necessary to create commands to get lists of directory namesand search fields in a user-friendly format. This will support the population oflists on the view during dynamic HTML generation. Such commands can alsoact as Web Server side caches of this relatively static information. These areomitted from the diagram for clarity.

10.5.4.4 CommandTargetThe description and role of this component is unchanged from the descriptionin Section 10.4.6, “Command layer” on page 227. It is implemented as a JavaBean. For the initial iteration of the second migration step, there would be aCommandTarget for each of the three concrete command classes.

10.5.4.5 DirectoryServiceManagerThe role of this component is to provide shared access to the directoryschema information used by the Finder application. This information identifiesthe names of directories, directory types, searchable fields, etc. In theclient/server Finder application, this information is downloaded and cached atthe client at login time. See Chapter 8, “Finder application experiences” onpage 157, for an overview of the original Finder application and Chapter 11,“Accessing enterprise applications and data” on page 245, for full details.

This is not appropriate behavior for the e-business version. Instead, this beanacts as a kind of intelligent shareable cache. As the application functionalityis extended, other shareable functionality and data might also be appropriate.


This will be implemented as an Entity bean. Bean-managed persistence willbe used initially since the persistent data actually represents an internal stateand will need to be accessed through the proprietary Finder applicationserver.

This component is essentially hidden from the User Interface logic layer. Itcan be created at application server startup or first application access and isessentially a singleton.

10.5.4.6 DirectorySessionThis component represents the business logic aspect of the applicationsession of a single user. It is the counterpart of the session in the WebServer. It provides Command Target interface references for search anddisconnect commands. The connect logic has yet to be considered more fully.It may be that the DirectoryServiceManager provides the Command Target forthe connect command.

This component accesses the DirectoryServiceManager for any cachedschema information and, initially, delegates all other functionality to theconnector layer. This component will involve state, and an instance isrequired on a per-user basis. Initially, this will be implemented as a statefulSession bean. Later stages may require some persistence support, such asuser customization information, such as SavedQueries, etc.

10.5.4.7 ConnectorsThe integration of the connector layer into the EJB-based application serverenvironment poses some interesting design issues that require furtherresearch. This situation will occur quite frequently when attempting tointegrate existing proprietary server applications into an EJB environment.

In this initial design, the Finder connector essentially represents a proprietarymechanism based on a TCP/IP socket connection implemented as a standardJava class. The DirectoryServiceManager and DirectorySession will bothneed to create an instance of this class to access the Finder server. An EJBcontainer may periodically passivate (swap out) EJB instances. This hassignificance for the open socket connection. It is clearly undesirable to haveto manage the reestablishment of such a connection.

This is likely to be a common problem when attempting to integrate existingproprietary server applications into an EJB environment.

The current Java2 Enterprise Edition has made initial steps to address thisissue with connectors. A framework is being developed. The JDBC


specification is being cited as an example of the direction this framework willtake. At present, this framework is not completed.


Chapter 11. Accessing enterprise applications and data

Enterprise data and applications are the heart of business processing andhave been deployed by organizations for decades. These systems meet theorganization’s requirements for reliability, scalability, security, interoperability,and performance. With Web applications having become the preferred modeof online information retrieval, it is extremely important, from a businessperspective, to integrate enterprise applications and data with the Webtechnology, thereby, allowing clients to conduct business through Webapplications. The technology or solution used to tie the two componentstogether is known as the connector.

Specifically, connectors enable Web access to the following:

• Relational and hierarchical data as stored in IBM and other vendors’databases

• Application programs that run in transactional environments, such asCICS, IMS, and Encina

• Applications written for object-oriented programming environments, suchas the OMG CORBA and IBM San Francisco projects

• Industry applications from vendors, such as SAP, Baan, and PeopleSoft

• Services outside the enterprise, such as payment system clearing housesand security key registry services

This chapter will focus on the issues associated with access to enterpriseapplications and data.

A fundamental principle of the IBM Application Framework for e-business is toprotect investments in existing applications and systems so that businessescan more quickly realize the competitive advantages of the Web. Asdescribed earlier, at a minimum, the data or the data source from an existingapplication can be leveraged. The components that this chapter will focus onare shown in Figure 69 on page 246.


Figure 69. Accessing enterprise data and applications

11.1 Decision points

There are many factors that need to be considered when deciding on whichoption would be the best to connect to exiting applications or data. Vendorsprovide generic connectors to their middleware or transactionalenvironments. If the need is to connect to an in-house-developed application,the choice is dependent on the interfaces supported by the application. If theneed is to only connect to data, the number of options is reduced.

Some of the issues that you would need to consider are:

• What legacy systems, applications, or data will be involved?

• Will I require access to different OS, network protocols, and applicationenvironments?

• Is a new interface required? If so, what kind?

• Will my architecture be two-tier or three-tier?

• Will I require additional Security Policies?

• Will I require synchronous/asynchronous access?

• What scalability and performance will I require?

WebServers

DomainAbstraction

Layer

ApplicationServers


VisualServlet

Approach

GeneralCommand

DomainInterface

2

2

1 1

BusinessDomainObjects

(NotImplemented)

CoreServices

(NotApplicable)

2e-businessClient

VisualServletClient

FusionClient

2

1

ServerConnector

Connectors

2

EnterpriseDataand

Applications

FinderApp

Server

ServerConnector

Connectors

2

EnterpriseDataand

Applications

FinderApp

Server


Once you have evaluated all your requirements, you will be able to matchthem against the solutions that are available and evaluate your choices.

11.2 Accessing the Finder application and data

For the Finder application, a number of alternatives were available. In Section8.4, “Application migration strategy” on page 163, two approaches wereselected for further exploration. Several alternatives were available for use asconnectors, and one could argue that other options could be considered moreelegant and workable. Due to the limited time available, the decision wasmade to only pursue the two approaches presented in Figure 70.

Figure 70. Two solutions chosen for further exploration

11.2.1 The tactical approachFor the connector, this approach would reuse some of the original client Clibraries. These libraries would then execute as part of a Web/applicationserver process and connect natively into the legacy interface.

The new client would connect to the legacy client code, which would act as aproxy to the data source.

This is a short-term strategy with a development cycle that is executed once.No iterations or increments were planned after the first. The architecture is


WebServers

DomainAbstraction

Layer


(NotImplemented)

CoreServices

(Not Applicable)

EnterpriseData and

Applications

Application Servers


VisualServlet

Approach

FinderApp

Server

GeneralCommand

ServerConnector

e-businessClient

VisualServletClient

FusionClient

DomainInterface

Connectors

2 22

1 1

1

1

1

Accessing enterprise applications and data 247

not designed to evolve over time. The aim is to Web-enable the enterpriseapplication with as little impact as possible, maximum reuse of existing code,and minimum redevelopment.

11.2.2 The strategic approachThis strategy would be to rewrite the server connector. This connector wouldbe a proprietary connector that would talk to the middle tier and directly to thedatabase.

This solution was designed to be developed in an economical fashionenabling it to be resilient to change and adaption. It is organized into distinctlayers and partitions. The structure of the application needs to beunderstandable so that it could be extended and reorganized. As with allother applications, it needs to be maintainable and testable.

This solution is intended to be developed in an iterative and incrementalfashion. The first and initial increment (or phase) will Web-enable the Finderserver leveraging the existing Finder server. Subsequent phases will movethe application logic resident in the server into the application server, thereby,leveraging the data.

11.3 Issues

This section describes the main issues (or problems) we encountered whendesigning and implementing the migration of the Finder application.

The first set of issues are not related to e-business, but to the project anddevelopment in general. There is nothing new in what we say, but the issuesare still worthy of mention so that you do not forget the unforeseeable.

11.3.1 Lack of design documentationThere was no design documentation. Many of the original team memberswere no longer available making it impossible for a complete handover. Aswith many other projects, design documentation could not be found or wasnot available.

This makes the possible e-business leverage points, which are critical inorder to access legacy enterprise applications and data, difficult to identify.

The only option available was to reverse engineer the design by looking at thesource code and experimenting with the application. It seriously impacted allphases of the project.


In the real world, there are cases where the only design available is thesource code. You might have a design document, but how up-to-date is it?The tendency to rewrite the unknown rather than reuse it often seems easier.In fact, it ends up being more time-consuming, usually resulting in functionsbeing redeveloped or defective.

11.3.2 Multiple versions of source codeFrom the time the original project ended to the time the code was handedover, a maintenance phase had been implemented with no disciplines inplace. There ended up being two versions of the code; so, it would be best tomake sure you have the latest version of the correct source code before youbegin.

11.3.3 Inability to rebuild an existing systemThe application’s source code is vital if you intend to reuse part of it or even toaid in the understanding of the functionality provided by the application. Itneeds to be the complete correct version.

If the source code is incomplete, the options available for reuse may belimited. It may be impossible to rebuild the system even without a largeamount of effort.

The Finder source code provided to us was incomplete and the incorrectversion. We were unable to rebuild the Finder application because some ofthe source code files were missing. This limited our ability to reuse sourcecode.

11.3.4 Non-object-oriented applicationsAn implicit non-functional requirement of any e-business solutionimplemented using Java is that it must be object-oriented and evencomponent-based. By migrating from a non-object-oriented environment toone that needs to be object-oriented, there is a significant amount ofadditional effort needed.

11.3.5 No JDBC driver for databaseIf you intend to use JDBC to access data in a relational database, ensure thata driver exists for the RDBMS. If you do not have one, you have two options.

• Migrate the data to a database that has a JDBC driver.

• Use another mechanism to access the database. This might not beportable.


We encountered this problem as the Finder data was held in the DatabaseManager V1.0 database. A JDBC driver does not exist for this database; so,we chose to implement both options. Both of the solutions (tactical andstrategic) access the database via the Finder server, which is option 2.However, in a subsequent phase, the strategic solution required direct accessto the data. As a result, we needed to migrate the data to a RDBMS for whichwe had a JDBC driver. However, this was not the only reason for migrating thedata. Migrating the data is not a trivial exercise. Many of the backup andrecovery procedures had changed between versions. The original versionhad also been installed using a different codepage, which further complicatedthe process.

11.3.6 TransactionalityTransactionality is an issue with most applications that access databases;there is an enormous amount of information available about these problemsand how the solve them. We only mention this in passing as something toremember when developing an application that accesses a database. In ourcase, all of the transactions are read-only; so, transactionality is not an issue.

If you intend to use JDBC, all new JDBC connections are in auto-commitmode, which means that each statement is executed as a separatetransaction. To create a transaction that consists of several statements, youmust disable the auto-commit mode by using theConnection.setAutoCommit(false) method. Then, the connection will set animplicit transaction up to the point where Connection.Commit orConnection.Rollback is issued. Commit or Rollback also set a new implicittransaction.

Conn. = DriverManager.getConnection(“jdbc.db2:SAMPLE”);// Disable the Auto-Commit modeconn.setAutoCommit(false);// A new transaction begins......... Some SQL statements are executed here.......// The end of the first transactionConnection.commit();// A new transaction begins...

The Database Manager (V1.0) was also not Y2K compliant, and this couldbe another reason for requiring a migration strategy.

Note


...// The end of the second transactionConnection.rollback();

11.3.7 Connection poolingConnecting and disconnecting from a database every time a datamanipulation language (DML) statement is executed can be very costly interms of response time. Here are two options:

• Create a pool of processes with each process permanently connected tothe database and where each process is responsible for executing a DMLstatement. Allocate these processes for DML statement execution asdemand requires.

• Create a pool of connections that are allocated on as demand requires.These connections can be pooled in the following ways:

• Manually - implement your own connection pool, or

• Using the provided connection pooling facility. For example, the JDBC2.0 API provides connection pooling to pool and share a set ofdatabase connections between a large set of end-users.

The Finder server addresses the issue of connection pooling by running ahundred processes that are permanently connected to the database. When aquery request is received by the server, it uses one of the free processes.

Neither of our solutions directly addressed this issue. However, reusing theserver avoided the connection pooling problem because we used the originalmechanism provided by the Finder server - that of process pooling. However,since the application logic is redeveloped and migrated from the databaseserver to the application server, the issue needs to be addressed. We wouldprobably use the connection pooling mechanism provided by JDBC since weplan to use JDBC to access the Finder data.

11.3.8 Dynamic vs. static SQLDynamic SQL requires the RDBMS to compile the SQL (parse it) every time itis executed. Static SQL does not require recompilation every time thestatement is executed. Obviously, there is a performance impact when theSQL is compiled; so, wherever possible, use static SQL. However, there willbe cases where the only option is dynamic SQL.

11.3.9 Proprietary SQL extensionsAll RDBMSs (DB2, Oracle, and Sybase) have added proprietary extensions tothe SQL language. Be aware that if you use these extensions, you will


encounter problems if the database needs to be migrated to a differentRDBMS that does not support the extension used.

11.3.10 Object serialization and non-Java programsJava object serialization allows objects to be easily written to and read fromstreams, such as file streams or socket data streams. This givesprogrammers a quick way of saving individual objects or large structures ofobjects to files or sending them over network connections. However, onedrawback to serialization is that you cannot read an object from a streamusing serialization if that object was not written to a stream usingserialization.

Unfortunately, this meant that serialization could not be used to constructobjects returned from the Finder server as a stream of bytes via TCP/IP and asocket because the server did not serialize them.

11.3.11 Primitive types and compatibility with legacy applicationsWhen integrating a Java program with a non-Java program, you need to beaware of the differences in the primitive types provided by the twoprogramming languages:

• Numbers - The size (in bytes) of the numeric primitive types may differbetween languages. For example, a long in C is equivalent to an int inJava. In addition, the byte ordering of the numeric types might differ. SeeSection 11.3.12, “Handling little-endian data” on page 253, for moreinformation.

• Characters - The size of the char type may differ between languages. Forexample, a char in C is one byte in size and a char in Java is two bytes.

Table 50 lists the Java primitives and their sizes in terms of bytes, which isuseful information for resolving the different sizes of the primitive typesbetween Java and non-Java programs

Table 50. Java primitive types

Type Size/Format Description

byte 1-byte signed two's complement Byte-length integer

short 2-byte signed two’s complement Short integer

int 4-byte signed two’s complement Integer

long 8-byte signed two’s complement Long integer


11.3.12 Handling little-endian dataAt the binary level, data can be either big-endian or little-endian or, in somecases, a combination of both. The following note describes the differencebetween little-endian and big-endian data.

Everything in Java binary format is stored as big-endian, which is sometimesreferred to as network order. This can cause a problem if data is beingsupplied from a non-Java program that stores character and numeric types aslittle-endian.

Java provides two classes for reading in and writing out data on a stream.They are DataInputStream and DataOutputStream, and they only handlebig-endian data; so, what do you have to do to handle little-endian data?When dealing with the problem of reading little-endian data into Java, youhave three options:

• Rewrite the program that provides the data to provide the data inbig-endian format.

• Write a separate translator program that reads an rearranges the bytes.

float 4-byte IEEE 754 Single-precision floatingpoint

double 8-byte IEEE 754 Double-precision floatingpoint

char 2-byte unsigned Unicode character A single character

boolean true or false A boolean value (true orfalse)

Type Size/Format Description

Big-endian and little-endian are terms that describe the order in which asequence of bytes is stored in computer memory. Big-endian is an order inwhich the big end (the most significant value in the sequence) is stored first(at the lowest storage address). Little-endian is an order in which the littleend (the least significant value in the sequence) is stored first. Forexample, in a big-endian computer, the two bytes required for thehexadecimal number 4F52 would be stored as 4F52 in storage (if, forexample, 4F is stored at storage address 1000, 52 will be at address 1001).In a little-endian system, it would be stored as 524F (52 at address 1000and 4F at 1001).

Note


• Read the data as bytes and rearrange them on the fly.

We encountered the little-endian problem with the data returned from theFinder server in packets. What was worse was that the data was acombination of little-endian and big-endian.

We could not rewrite the server, but we could translate the data using aseparate program because of the way the client and server communicate; so,we decided to write two classes that adapt DataInputStream andDataOutputStream called LEDataInputStream and LEDataOutputStream,respectively.

11.3.12.1 Reading little-endian dataThe LEDataInputStream class uses object adaption to adapt those methodsaffected by the little-endian byte format. All the methods that read in data thatcan be affected by the little-endian problem need to be reimplemented toreverse the order of bytes that are read in in order to construct the correctprimitive type. All other methods are just passed through to the correspondingmethod in the adapted object, in this case, the DataInputStream object.Figure 71 on page 255 shows the LEDataInputStream class and therelationships with the DataInput and DataInputStream classes.

So, when we want to read data in as little-endian, we useLEDataInputStream; otherwise, we use DataInputStream. For example:

DataInputStream in = new DataInputStream(socket.getInputStream());int bigEndianInt = in.readInt();

Or, for little-endian, we use:

LEDataInputStream in = new LEDataInputStream(socket.getInputStream());int bigEndianInt = in.readInt();

DataInputStream and DataOutputStream needed to be wrapped ratherthan extended because they only have final methods.

Note


Figure 71. LEDataInputStream class and relationships

Writing little-endian dataThe LEDataOutputStream class uses object adaption to adapt those methodsaffected by the little-endian byte format. All the methods that write out datathat can be affected by the little-endian problem need to be reimplemented toreverse the order of bytes that are written out. All other methods are justpassed through to the corresponding method in the adapted object, in thiscase, the DataOutputStream object. Figure 72 on page 256 shows theLEDataOutputStream class and the relationships with the DataOutput andDataOutputStream classes.

So, when we want to write data out as little-endian we useLEDataOutputStream; otherwise, we use DataOutputStream. For example:

DataInput(from java.io)

LEDataInputStream

w : byte []

readInt()

0..*

1

0..*

-in1

uses

DataInputStream

readInt ()

(from java.io)

0..*

1

0..*

1

uses

11 11

adapts

in t readInt() {

d.readFul ly(w, 0, 4);return (w[3]&0xff) << 24 | (w[2]&0xff) << 16 | (w[1]&0xff) << 8 | (w[0]&0xff);

}

* only one m ethod is shown. Al l m ethods would need to re im plem ented


int i = 10;DataOutputStream out = new DataOutputStream(socket.getOutputStream());out.writeInt(i);

Or, for little-endian, we use:

int i = 10;LEDataOutputStream out = new LEDataOutputStream(socket.getOutputStream());out.writeInt(i);

Figure 72. LEDataOutputStream class and relationships

11.4 Implementation details

The following section describes some of the implementation details that werecompleted as part of this project.

* o n l y o n e m e th o d is sh o w n . A l l m e th o d s w o u ld n e e d to re i m p le m e n te d

v o i d wr i te Int (int v ) {w[0 ] = (b y te ) v ;

w[1 ] = (b y te )(v >> 8 );

w[2 ] = (b y te )(v >> 1 6 );w[3 ] = (b y te )(v >> 2 4 );

d .wri te (w, 0 , 4 );

}

Da taO utpu tS tream

w ri teInt ()

(fro m j a va .i o )

LE DataO utpu tS tream

w : by te []

writeInt ()11 11

ad apts

DataO utput(fro m j a va . i o )

1

0. .*

1

0. .*

us e s

0. .*

1

0. . *

-out1

us es


11.4.1 Strategic approachBy analyzing of the business domain of the Finder application and thefunctionality provided to users, we were able to identify three main businessobjects:

• Directory - This is responsible for providing the user with an entity thatcan be inquired upon using a user-definable query. A directory has a name(or alias), a type, and its table name in the Finder database. In addition, adirectory has a collection of fields that can be searched.

• Query - This is responsible for providing the user with the ability toconstruct a query based on a set of search conditions and a directory.Once executed, the query object can be interrogated for the results of thequery.

• Connector - This is responsible for allowing access to the enterpriseapplications and data. We will need two connectors: One to access theFinder server and another to access the Finder data.

Redeveloping the application logic on the client that is responsible for usingTCP/IP to make a request for information and handling the response to therequest requires a socket. It will use the current socket mechanismimplemented by the Finder server and format the requests in line with theapplication-specific protocol. The responses will be encapsulated in businessobjects that can be interrogated by the presentation logic. Java will be usedas the enabling language allowing platform independence.

11.4.1.1 What is a socket?TCP provides a reliable point-to-point communication channel that client andserver applications can use to communicate with each other. To communicateover TCP, a client application and a sever application establish a connectionto one another. Each application binds a socket to its end of the connection.To communicate, the client and server each read from and write to the socketbound to the connection.


Java provides Socket classes that can be used to handle the communicationbetween the client and server programs:

Socket - This implements the client-side connection between the Java clientand another program on the network. By using the Socket class instead ofrelying on native code, the Java program is platform-independent.

ServerSocket - This implements the server-side connection and can be usedto listen and accept connections from clients.

Figure 73 on page 259 shows a simple example of how socket API works.Normally, the server program is on a different machine than the clientprogram and has a socket bound to a specific port number. When the serverruns, it waits listening to the socket for a client to make a request. Uponreceiving a request, the server accepts the connection and gets a new socketbound to a different port. It needs a new socket (and port number) so that itcan continue to listen on the original socket while processing the clientrequest.

On the client, if the connection is accepted by the server-side program, asocket is successfully created and can be used to communicate with theclient. In order for a client to connect to a server, it needs to know the locationof the server and the port number on which the server is listening. Note thatthis client-side socket is not bound to the port number used to connect to theserver-side program. Instead, it is assigned a local port number. The clientand server can now communicate by writing to and reading from theirrespective sockets.

Sockets is a method of communication between a client program and aserver program in a network. A socket is defined as the endpoint in aconnection. Sockets are created and used with a set of programmingrequests or function calls, sometimes called the sockets applicationprogramming interface (API). Sockets can also be used for communicationbetween processes within the same computer.

This is the typical sequence of sockets requests from a server applicationin the connectionless context of the Internet in which a server handlesmany client requests and does not maintain a connection longer than theserving of the immediate request.

Note


Figure 73. Socket communication

11.4.1.2 Writing to and reading from a socketData is sent to and received from the server as a structured packet of bytes.In fact, the client always sends one packet of data per request, but the serverreturns zero or more packets depending on the type of request (see Table 50on page 252). The packets can be variable in length. The data is formatted inline with the following C structure:

struct {unsigned long DataSize;char * data; // an array of chars

};

In order to send and receive data to and from the server through the Javasocket, the OutputStream or InputStream classes (or their sub-classes) mustbe used. However, the client object processing the streams must know whatprimitive types make up the stream of bytes and their order. In the case of theFinder application, we know that all transmitted data is written and read aspackets. A packet contains an integer followed by a variable number of bytes.The data itself is formatted differently depending on the request.

In addition, the server can return multiple packets of data to the client; so, tomake our lives easier, we created a Reader and a Writer whose soleresponsibilities were to write and read packets from the streams attached tothe socket. The SocketWriter class accepts packets of data and writes themout on a socket’s output stream. The following is a source code snippet for theSocketWriter:

ApplLogic

ApplLogic

1. Connect

2. Send

3. Receive

4. Disconnect

1. Connect

2. Receive*3. Process4. Send

5. Disconnect

Soc

ket S

ocket

*waits for the request before proceeding


public class SocketWriter {private Socket socket;private DataOutputStream streamOut;

public void setSocket(Socket newSocket) {try {

socket = newSocket;if (null != streamOut) {

streamOut.close();}BufferedOutputStream b = new BufferedOutputStream(socket.getOutputStream());streamOut = new DataOutputStream(b);

} catch (Exception e) {....

}}

public void write(TcpPacket packet) throws IOException {/** @pre ensure a stream must be exist */PreCondition.ensure((streamOut != null),"a output stream must exist");streamOut.writeInt(packet.size);streamOut.write(packet.data);streamOut.flush();

}}

The SocketReader is attached to socket’s input stream; the client can use thisclass to read one packet at a time from the stream and then process the dataaccording to the request. The following is a source code snippet for theSocketReader:

public class SocketReader {private Socket socket;private DataInputStream streamIn;

// Reads data being streamed from the socket and// packages up into packets (TcpPackets) that// match the structure being sent from the server.// Reads one pack at a time.// Returns null when finished.public TcpPacket read() throw IOException {

try {int size = streamIn.readInt();// Must individually read in the bytes,// because the read(byte[],int,int) method// does not correctly buffer.byte [] data = new byte[size];for (int i = 0; i < size; i++) {

data[i] = streamIn.readByte();}

return new TcpPacket(data,size);

} catch (EOFException e) {// finished reading stream so return nullreturn null;

}}


public void setSocket(Socket s) {try {

socket = s;if (null != streamIn) {

streamIn.close();}// Must be buffered otherwise whole packet// will not be read properly.BufferedInputStream b = new BufferedInputStream(s.getInputStream());streamIn = new DataInputStream(b);

} catch (IOException e) {....}

}}

When a client sends a request to the server, the server returns zero or moredata packets. The data inside of the packets is formatted based on therequest issued. This means that only the request knows what to expect andhow to process it. For example, the query request will receive a number ofpackets back that are made up of a combination of SQLDA and SQLCAinformation. However, a logon request will receive a number of packetscontaining data formatted as a complex linked list of directory information.

11.4.1.3 Accessing the enterprise application to perform queryWe will use the Socket, SocketReader, and SocketWriter to create aSocketConnector class that allows the application server to communicatewith the legacy Finder server.

The SocketConnector is responsible for executing a communication requestusing a socket and returns a SocketReader object that can be used to readthe one or more packets of data returned from the Finder server. In our case,the communicate request is a simple formatted string, which will berecognized by the server. Figure 74 on page 263 describes theSocketConnector class and its relationships.

The Finder server responds to several different types of request. Theresponses are also different depending on the request; so, how do we get theSocketConnector to execute the different requests and return differentresults. We have two options:

• We could expand the SocketConnector class to handle all the knowrequests by providing a method for each type of request. The individualmethods would then know what to expect from the server and have theability to process the response and return a meaningful result. The resultcould then be different for each request. The main problem with this is that


the responsibilities of the SocketConnector become blurred, and its reuseis limited.

• A better option is to create a Query abstract class and then specialize it touse the SocketConnector. This SocketQuery class would then provide astandard interface for defining, executing, and processing the result of aquery. The benefits are that the SocketConnector’s responsibility is clearlyand simply defined and allows it to be reused more easily. Also,specializing the Query by adapting the SocketConnector allows theSocketQuery to be replaced by a query that uses a different mechanism.For example, a database query (see Section 11.4.1.5, “Accessingenterprise data to perform a query” on page 266).

We chose the second option. The classes and relationships required toperform a query via a socket using the Finder server are described in Figure74 on page 263.

So, the Query object will be responsible for executing the request andprocessing the results. The results will be loaded into the query allowing it tobe interrogated by other classes. The query object corresponds to a Model inthe Model-View-Controller pattern. It is also a business object.

Unfortunately, it is not as simple as that. We need to remember that one ofthe objectives of the design was phased migration, which means that theapplication logic that resides in the Finder server will be incrementallyredeveloped and migrated to the application server. For example, the queryexecution logic will need to be moved from the Finder server to theapplication server where JDBC will be used to access the database; so, thequery will need to process different responses with data provided in differentformats. For example, the Finder server returns SQLDA structured data, andJDBC returns a ResultSet.

This means that the Query class needs to be specialized to handle thedifferent communications (or mechanisms). Figure 74 on page 263 shows theclasses and their relationships for executing a query using the Finder serverusing sockets as the communication mechanism.

There are a couple of important points to note:

• The Query class is an abstract class and has been specialized to producea SocketQuery. It is a model and contains statements about the query,which include the search conditions and results of the query execution. Itprovides a consistent interface, or contract, between the application logicand the presentation logic. Regardless of the mechanism used to executeand load the query, the properties can always be set in the same way.


• The SocketQuery uses the SocketConnector to communicate the queryrequest to the Finder server and processes the returned data. This is doneby implementing the execute method.

Figure 74. SocketQuery class and associations

Putting is all togetherYou have seen the class diagram; now, let us look at how it works in practice.The following code snippet shows how to construct and execute a query to beexecuted by the Finder server and how to process the results:

try {// 1. Create a directory object to query.Directory directory = new Directory("=AUSTIN","AUSTIN","DIR");

Query

rowCount : int

colum nCount : int

colum ns : String []

types : String []

data : Vector

searchConditions : Vector

addSearchCondition()

execute( )

(from

<<m odel>>

Connector

connect()execute()

disconnect()isConnected( )

loadProper ties()

(from com.ibm.redbook.sg245503. ch12.connector)

Socket

(f rom jav a.net)

SocketW r iter

w ri te( )

writes to

So cketReader

read()

reads from

SocketQuery

processedM etadata : boolean

execute()processTcpPacket()processM etadata()

SocketConnector

host :Stringport : int

connect()disconnect()is Co nn ected()loadPro perti es( )

im plem ents

1 11

+socket

1adapts

1

1

1

-wr iter1

reques t

1

1

1

-reader

1

response

0..*

1

0..*

1

uses

Directory

alias : String = "default"table : Stringtype : String

(from com. ibm. redbook.sg245503.ch12)

<<m odel>>

extends

0..*

1

0..*

-directory 1

searches


// 2. Create a connector to communicate with the server (Findercs.ibm.com)// on port number 1295.SocketConnector c = new SocketConnector("Findercs.ibm.com",1295);

// 3. Create a query that uses the socket connectorSocketQuery query = new SocketQuery(c);

// 4. Create a search conditionLikeCondition condition = new LikeCondition("#F#NAME","AB%");

// 5. add the search condition to the queryquery.addSearchCondition(condition);

// 6. execute and load results into query.query.execute();

// 7. process results.for (int r = 0; r < query.getRowCount(); r++) {

// Process row...for (int c = 0; c < query.getColumnCount(); c++) {

// Process column...

}}

} catch (Exception e) {// Horrible exception...

}

11.4.1.4 DB2 Java supportFor Windows NT and AIX, DB2 Java support is available in DB2 UDB, CAE,and SDK. The minimum requirements for Java support are DB2 UDB Version5.0 and IBM JDK 1.1.6. To use JDBC and SQLJ, you need to properly set upyour DB2 environment.

DB2 JDBC driversThe main uses of DB2 JDBC are for executing dynamic SQL statements andfor supporting upper data layers, such as SQLJ and IBM DataAccess beans.DB2 provides two JDBC drivers: A native API Type 2 driver and a net protocolType 3 driver. In DB2 UDB 5.2, DB2 delivers a set of JDBC 1.1 drivers andanother set of JDBC 2.0 drivers. The Java class libraries are in db2java.zip.The native API library is in db2java.dll (NT) or libdb2java.so (AIX).

• The native API driver is for server-side applications that run on theapplication server. The driver consists of Java parts and a C native APIinterface (DB2 CLI). The driver translates JDBC calls into DB2 CLI calls. Itthen gives the calls to the DB2 Client component, which passes them tothe DB2 Server. After that, the driver returns the result back to theapplication. The class name for this JDBC driver isCOM.ibm.db2.jdbc.app.DB2Driver, which is in db2java.zip.

• The net protocol driver is for creating an application using the Java appletmodel. The driver is a 100 percent Java program that is downloaded to theclient browser along with the applet. The driver exchanges messages by


using the TCP socket protocol with a JDBC Applet Server in theapplication server machine. The JDBC Applet Server translates appletmessages into DB2 CLI calls. It sends the calls into the DB2 Clientcomponent, which passes them to the DB2 Server. Then, the JDBC AppletServer passes the results back to the applet. The class name for thisJDBC driver is COM.ibm.db2.jdbc.net.DB2Driver, which is in db2java.zip.

The JDBC Applet Server is a stand-alone socket server application. Toactivate the JDBC Applet Server on OS/2 systems, enter the followingcommand:

db2jstrt <port>

This will activate the JDBC Applet Server listening on port <port>.

Connection URL syntaxTo open a database connection, the program should supply a connectionURL, database owner, logon user ID, and password. A DB2 JDBC connectionURL has the following formats:

• Using DB2 native API driver:

jdbc:db2:<database_name>

• Using DB2 net protocol driver:

jdbc:db2://<jdbc_applet_server_hostname>:<port>/<database_name>

For example, to open a connection to the Finder Application database usingthe DB2 native API driver, the connection URL is:

String urlString = "jdbc:db2:FINDERCS";

Or, using the DB2 net protocol driver with JDBC Applet Server listening onfindercs.ibm.com port 8888, the connection URL would be:

String urlString = "jdbc:db2://findercs.ibm.com:8888/FINDERCS";

Other information can be supplied as Java properties to theDriverManager.getConnection method. For example, to open a connectionusing the sDB2 native API to the FINDERCS database owned by findercs, logon as user auser, with password letmein:

Properties infoProp = new Properties;infoProp.set("owner","findercs");infoProp.set("userid","auser");infoProp.set("password","letmein");Connection aConnection = DriverManager.getConnection(urlString,infoProp);


When accessing a database in a remote data server, DB2 Client maps thegiven database name <database_name> into a remote database using itsremote interface configuration. To do this, you should configure a remoteinterface. Alternatively, you can supply the data server host name and portnumber directly to the connection URL:

"jdbc:db2://data_server_name:data_server_port/<database_name>"

For example, to access the FinderCS database on findercs.ibm.com usingport 8888, the connection URL becomes:

String urlString = "jdbc:db2://findercs.ibm.com:8888/FINDERCS"

11.4.1.5 Accessing enterprise data to perform a queryThe design is intended to evolve allowing us to move the application logicfrom the Finder server to the application server with minimum impact on therest of the system. To give you an example of this, we will redesign the queryfunction to access the Finder data directly, instead of through the Finderserver. This design is shown in Figure 75 on page 267.

The solution looks very similar to the SocketQuery, which was the intension.By implementing a connector that adapts a JDBC connection object, we areable to use this connector to communicate with any database that has aJDBC Driver. The execution of a communication request, for example, asimple select query, will result in the database and then the connection objectreturning a ResultSet object.

The result object needs to be processed and Query properties set so thepresentation logic can interrogate the query and ultimately present the resultto the user. Again, as with the SocketConnector, the database connectordoes not know what function it is performing; so, we need to extend the queryand add the functionality to execute and process the results from aDBConnector object and marshall the results to set the properties in theQuery base class.

The Query base class is used as the model to contain the responsibilitiescommon to both a query executed by the server and a query executed by thedatabase. It provides a common query model (or interface) that the

The syntax for the native API JDBC driver accessing a remote database isthe same as the net protocol JDBC driver syntax.

Note


presentation logic can rely on and will not change when the functionality usedto implement it changes.

Figure 75. DBQuery class and associations

Putting it all togetherYou have seen the class diagram; now, let us look at how it would work inpractice. The following code example shows how to construct and execute aquery to be executed by the Finder server and how to process the results:

try {// 1. Create a directory object to query.Directory directory = new Directory("=AUSTIN","AUSTIN","DIR");

// 2. Create a connector to communicate with the server

Connection(f rom java.sql)

DBQuery

execute()processM etaData()processResultSet()

DBConnector

driver : Stringurl : Stringuser : Str ingpassword : Str ing

connect()execute()disconnect( )isConnected()loadProperties()

1 11 1

adapts

0..*

1

0..*

-connector 1

com municates via

Connector

connect( )execute( )

disconnect()isConnected()

loadP roperti es( )

(f rom com.ibm. redbook. sg245503.ch12. connector )

D irectory

alias : String = "default"table : Stringtype : String

(from com.ibm.redbook. sg245503. ch12)

< <m odel> >

Query

rowCount : intcolumnCount : int

columns : String []

types : Str ing []

data : Vector

searchConditions : Vector

addSearchCondition()

execute()

(from com. ibm.red book.sg245503. ch12)

< <m odel> >

extends

0..*

1

0..*

-directory1

searches

im plem ents


DBConnector c = new DBConnector("COM.ibm.","jdbc:db2:FINDERCS);

// 3. Create a query that uses the socket connectorDBQuery query = new DBQuery(c);

// 4. Create a search conditionLikeCondition condition = new LikeCondition("#F#NAME","AB%");

// 5. add the search condition to the queryquery.addSearchCondition(condition);

// 6. execute and load results into query.query.execute();

// 7. process results.for (int r = 0; r < query.getRowCount(); r++) {

// Process row...for (int c = 0; c < query.getColumnCount(); c++) {

// Process column...

}}

} catch (Exception e) {// Horrible exception...

}

Notice that we only had to change steps 2 and 3 replacing theSocketConnector and the SocketQuery with a DBConnector and a DBQuery.All the rest stayed the same including the construction of the searchcondition, how the query was executed and, most importantly, how the resultswere processed. We have just plugged-in a different connector withoutimpacting the presentation logic.

11.4.2 Tactical solutionThe tactical solution had to wrapper the existing client interface so that it ranon the existing OS/2 server. A new interface was developed to communicatewith the new client application and Web/application server. The structure ofthis proprietary connector is shown in Figure 76 on page 269.


Figure 76. Proprietary connector

The encapsulated functions for the proprietary connector were taken from theNETAPI.C module. It provides an interface for general TCP/IP support withthe following functions:

NetMakePacket (ULONG Size)NetSetPacketData (PACKET Packet, PVOID Buffer, ULONG Size)

Also included was a function from CLUTILS.C

UINT TcpSend(PIPE *pPipe,PVOID Buffer,USHORT BufferSize)

For more information about TCP/IP sockets, refer to the productdocumentation.

11.4.2.1 ITSOCallUpSocketJavaThis interface shown in Figure 76 implements the socket protocol.

The ITSOSocketJava has an instance object CallUpSrv from a Socket class.The listenSocket(String host, int port) method first creates a CallUpSrv objectwith the computer name (host) and port number (port) where the serverprogram listens for client connection requests. Next, it instantiates aPrintWriter object to send data over the socket connection to the serverprogram. It also creates a new BufferedReader object to read the text sent bythe server back to the client.

ExistingFinder Server

NETAPI.C

CallupConn.dll

Java Interface(ITSOCallupSocket.java)

ITSOCallupSocket.cpp


protected void listenSocket(String host, int port){//Create socket connectiontry{this.setCallUpSrv(new Socket(host, port));this.setOutStream(new PrintWriter(getCallUpSrv().getOutputStream(), true));this.setInStream(new BufferedReader(newInputStreamReader(getCallUpSrv().getInputStream())));}catch (UnknownHostException e) {System.out.println("Unknown host:"+host);System.exit(1);} catch (IOException e) {System.out.println("No I/O");System.exit(1);}}

This method was invoked from the connect() interface.

The following is the sendMsg(String msgText) method. This method sends astring to the socket server:

protected void sendMsg(String msgText){getOutStream().println(msgText);}

The receive() method is implemented as follows:

protected String receiveMsg(){try{String line = getInStream().readLine();return(line);} catch (IOException e){return("Read failed");}}

The previous methods are used by the getQuery(String theQuery) interface

11.4.2.2 ITSOCallUpSocketCppTo create an interface between the C code and the Java classes, an objectmust be created in C++ to provide the required functions. That object needsto provide a Java interface that calls the C function from the original clientcomponent of the server application. The C function also used the socketprotocol. These functions are in the TCPCLIW.c. This module provides asimple socket support. In the TCPCLIW.c module, the following functionswere defined:

Table 51. TCPCLIW.c functions

Name Returntype

Parameter Remarks

callSocket int - Start the socket support with theserver. It returns the socket ID.


All this code was used to generate a library called CallUpConn.dll. The classCallUpConn has the following types:

#ifndef _CALLUPCONN_#define _CALLUPCONN_

#define NB_MAX_BUFFER_SIZE 65535#define SQLDA_SIZE 3140

#include <winsock.h>#include <io.h>#include <stdio.h>#include <stdlib.h>#include <string.h>#include <ctype.h>#include <sys\types.h>#include <windows.h>#include "sqlda.h"

// C++ include part#include <iostream.h>

class CallUpConn {

char bufIn[NB_MAX_BUFFER_SIZE]; /* data buffer for receiving data */char bufOut[1000]; /* data buffer for sending data */

char buf2Sqlda[SQLDA_SIZE+1];int buf2Pos,bufInPos;int rcl;int clientSocket;

public :CallUpConn() {} ;int initConnect(char * , unsigned short);int execQuery(char * );int getRow(char *);int closeConnect();

};

#endif

startConnect intchar * ,short,int

Start the connection with the serverusing the TCP/IP info in the parameter(ipAddress,socket port,socketId)It returns the status of the serverconnection

releaseConnect int intClose the socket connection andrelease the TCP/IP resources. Itreturns the status of the releasedresources.

releaseSocket int int Release the socket id. It returns thestatus of the released resources.

Name Returntype

Parameter Remarks


In this class, we defined the instance variables listed in Table 52.

Table 52. Instances variable in CallUpConn object

The interface available to the Java classes is listed in Table 53.

Table 53. Java interface for the application

11.4.2.3 Testing the CallUpConn classBefore including the CallUpConn interface with the Java code, we created asimple program to test the functions defined in the class. The following codeuses the class CallUpConn to run on the server. A query reads from a file(tcpini) and put the result rows in another file (tcpOut). For these examples,the Finder server is running on the 9.3.240.203 IP address on the 1295socket port .

Name Type Remarks

bufIn char * The buffer received from the server

bufOut char * The buffer to send to a server

buf2Sqlda char * The buffer that contains a SQLDA structure

bufInPos int The last byte read in bufIn buffer

rcl int The number of bytes received from the server

clientSocket int The socket ID number

buf2Pos int The last byte write in buf2Sqlda buffer

Name ReturnType

Parameter Remarks

initConnect int char *short

Start the connect with the server usingthe TCP/IP info in the parameter. Itreturns the socketId

execQuery int char *Receive the query to send to theFinder server. It also read from theserver the first packet data. Its returnthe status of the server connection

getRow int char *Receive a buffer that will contain thenext row from the server buffer. Itsreturns the length of the row string

closeConnect int -Close the socket connection andrelease the TCP/IP resources. Itreturns the status of the releasedresources.


main(int argc,char *argv[]){ int check;

CallUpConn callConn;if ( (infnum = fopen(infile,"r")) == 0){

return(1);}if ( (outfnum = fopen(outfile,"w")) == 0){

return(1);}

check=callConn.initConnect("9.3.240.203",1295);fgets (bufOut,sizeof(bufOut),infnum);check=callConn.execQuery(bufOut);while (callConn.getRow(testcpp)!=0) {

fputs (testcpp,outfnum);fputs ("\n",outfnum);callConn.getRow(testcpp);}

callConn.closeConnect();fclose (infnum);fclose (outfnum);

}

11.4.2.4 Generating the C++ beansTo generate the C++ Access beans and the wrapped files inside Java, thefollowing steps need to be completed:

1. Select the package and click mouse button 2. From the pop-up menu,select [Tools — C++ Access-Create Access Beans.] The C++ headerfiles page of the C++ Access Builder SmartGuide opens.

2. Beside the Add C++ header files box, click Add to open the Load filesdialog box.

3. Select the CallUpConn.hpp file and click Open. The C++ header file isadded to the box. Click Next. The C++ Code Generation page opens.

4. In the Library name field type CallUpConn, the name CallUpConn will begiven to the generate makefile and shared library. Click Next. The C++Compiler page opens.

5. From the Select desired compiler pull-down menu, select the C++ compileryou want to use to preprocess the definition file. In the Preprocessorcommand field, enter the commands required by your C++ compiler. ClickNext. The C++ Implementation files page opens.

6. Beside the Add libraries box, click Add... to open the Load files dialog box.Browse the cpp directory where the CallUpConn.lib is located. This is theexisting library that the Java application will access. Click Finish.

7. The C++ Access Builder generates access beans and wrapper files intothe package.


More information about the connection between C++ code and Java may beretrieved from the VisualAge for Java help sample Accessing a C++ library.

11.4.2.5 Creating the shared libraryTo create the shared library, create a project as shown in Figure 77. For moredetail about the Compiler/Linker options, refer to the Visualage C++documentation.

Figure 77. The CallUpConn project inside Visualage C++

11.4.2.6 The Java Class interfaceIn the previous step, the preprocessor generated a class inside your package.The following is the class definition for the CallUpConn interface:

/** This file was generated by the IVJ2CPP tool.* DO NOT EDIT THIS FILE.*/import com.ibm.ivj.eab.j2cppaccess.*;import java.io.UnsupportedEncodingException;

public class CallUpConn extends __J2CPP_ {static {System.loadLibrary("CallUp");fixFloat();}}


For the CallUpConn class interface method, two Java class methods weredefined. The following is the interface for the execQuery method:

private native int execQuery_ppC(PCHAR arg0);

public int execQuery(PCHAR arg0) throws IVJJException {

int ret_val = execQuery_ppC(arg0);

return ret_val;}

To call the interface, the execQuery method must be used.

The ITSOSocketCpp has an instance object callUpConnCpp from aCallUpConn class. The listenSocket(String host, int port) method firstcreates a CallUpConn object with the computer name (host) and port number(port) where the server program is listening for client connection requests.The following method was invoked from the connect() interface.

protected void listenSocket(String host, int port){try{this.setCallUpConnCpp(new CallUpConn)this.getCallUpConnCpp.initConnect(host, port));}catch (UnknownHostException e) {System.out.println("Unknown host:"+host);System.exit(1);} catch (IOException e) {System.out.println("No I/O");System.exit(1);}}

We implement the extRunQuery to build a vector using the C++ beans

public Vector extRunQuery(String query){int i;Vector result= new Vector();StringBuffer stringRow= new StringBuffer (150)

i=execQuery(query);for(i=1;i>0;) {i=this.getCallUpConnCpp().getRow(stringRow);result.addElement(stringRow);}return result;}}

11.5 JDBC and SQLJ

Two standards-based Java programming APIs are available for databaseaccess: Java Database Connectivity (JDBC) and embedded SQL for Java(SQLJ). This section provides an overview of JDBC and SQLJ.


11.5.1 JDBCJDBC is a Java data interface standard that provides access to a wide rangeof relational databases. To deliver database-independent access in Javalanguage, Java has included JDBC as a standard part of the Java platform.JDBC is a set of interfaces that are implemented by the database vendor, andthe vendor implementation of these interfaces is called the JDBC driver forthat vendor. The latest JDBC level is JDBC 2.0, which is available as aseparate package from Sun, or as a part of the Java 2 platform. Virtually alldatabase vendors have adapted the JDBC specification into their databaseproducts. However, the vendor may not have implemented the latest JDBCversion and does not have all driver types as specified in the specification.Contact your database vendor for specific information about its JDBC drivers.

JDBC enables Java programs to create sessions to databases, execute SQLstatements, and retrieve the results. The JDBC specification delivers acall-level SQL interface for Java based on the X/Open SQL call level interfacespecification. To confine SQL syntax and semantic diversities acrossdatabase platforms, JDBC also sets minimum SQL conformance to theSQL92 entry-level SQL standard. This guarantees wide portability forapplications designed to run on many platforms.

The call-level interface limits operations to executing only raw SQLstatements and retrieving the results. A Java program can issue an SQLstring to be processed by a database server at runtime. This mechanism alsomeans dynamic compilation, privilege, and authorization checks. It allowsflexibility for the program to construct variable queries that are defined at runtime. This model is also known as the dynamic SQL model.

The JDBC specifies four major components: JDBC drivers, connections,statements, and a result set. The database vendors deliver only the driver,which should comply with JDBC specifications. Other components are in theJDBC API package, which is the java.sql package. The JDBC API providesinterface classes for working with the following components:

• The java.sql.Driver and java.sql.DriverManager for managing JDBCdrivers

• The java.sql.Connection for using connections

• The java.sql.Statement for constructing and executing SQL statements

• The Java.sql.ResultSet for processing the results

11.5.1.1 JDBC driverJDBC defines standard API calls to a specified JDBC driver. A JDBC driver isa piece of software that performs the actual data interface commands. It is


also considered the lower level JDBC API. This driver has interfaces in theform of database client calls or database network protocol commands thatare serviced by a database server.

Depending on the interface type, there are four types of JDBC drivers:

• Type 1 - This is a JDBC-ODBC bridge. The Type 1 driver translates JDBCAPI calls into ODBC API calls.

• Type 2 - This is a native-API driver. The Type 2 driver translates JDBC APIcalls into database-native API calls. Because the driver uses native APIs,a Type 2 driver is vendor-dependent. The driver consists of two parts: AJava language part that performs the translation and a set of native APIlibraries.

• Type 3 - This is a Net-Protocol. The Type 3 driver translates JDBC APIcalls into DBMS-independent network protocol calls. The database serverinterprets these network protocol calls into specific DBMS operations.

• Type 4 - This is a Native-Protocol. The Type 4 driver translates JDBC APIcalls into DBMS native network protocol calls. These native protocol callsare then converted into DBMS operations by the database server.

A Java program can create several connections to several different databasesusing different drivers. To manage driver operations, JDBC provides a drivermanager class, the java.sql.DriverManager, which is responsible for loadingdrivers and creating new database connections.

The DriverManager registers any JDBC driver that is going to be used. If aJava program issues a JDBC operation on a non-registered driver, JDBC willraise a No Suitable Driver exception. There are several ways of registering adriver:

• Register the driver explicitly by using:

DriverManager.registerDriver(<driver-instance>)

where <driver-instance> is an instance of the JDBC driver class.

• Load the driver class by using:

Class.forName(<driver-class>)

where <driver-class> is the JDBC driver class.

This will load the driver into the Java Virtual Machine. When loaded, eachdriver must register itself implicitly by using theDriverManager.registerDriver method.


For example, to register the DB2 JDBC Type 2 driver, which is in theCOM.ibm.db2.jdbc.app package, you can use either:

DriverManager.registerDriver(new COM.ibm.db2.jdbc.app.DB2Driver());

or

Class.forName("COM.ibm.db2.jdbc.app.DB2Driver");

11.5.1.2 JDBC connectionWhen a program accesses a database, the program should create a sessionin the database. This session holds a context for executing SQL statementsand returning the results. In the JDBC specification, the session isrepresented by a connection; therefore, a JDBC connection is a session froma Java program to a database.

A connection is identified by a URL, which has the following format:

"jdbc:<subprotocol>:<subname>"

where <subprotocol> specifies a particular database connectivity mechanism,as supported by a particular driver. <subname> is a specific parameter of thesubprotocol or driver, and it is dependent on the selected subprotocol. Forexample, to define a connection to the FINDERCS database:

String urlString = String("jdbc:db2:FINDERCS");

To open a connection, a Java program should ask the DriverManager to opena connection using a specified protocol and database:

Connection aConnection = DriverManager.getConnection(urlString);

The DriverManager will ask each driver in its driver list to support thespecified protocol. The first driver that can support the protocol is selectedand used to open a connection to the specified database. By specifyingdifferent connection URLs, a Java program can simultaneously create severalconnections to several databases, even with different drivers.

When a driver has a native API part and Java cannot find the native APIlibrary, JDBC will raise a No Suitable Driver condition - even when theDriverManager has registered the driver. In WebSphere, you should alsoinclude the native library directory path into the user libpath in the JavaEngine setup.

Note


11.5.1.3 JDBC SQL statementJDBC allows you to create and execute SQL statements. The SQLstatements being used should comply with the SQL92 entry-level standard,which is reasonably powerful. The program creates SQL statements andsends them to the database server to be executed in the session context.

The JDBC has three interface classes for SQL statements: java.sql.Statementand its two sub-interfaces: java.sql.PreparedStatement and thejava.sql.CallableStatement. Based on these interfaces, there are threealternatives for creating SQL statements:

• Create a statement object by instantiating the java.sql.Statement class.This object initially does not represent any SQL statement. It can constructand execute an SQL statement by calling one of its execute methods. Forevery execute method call, the JDBC driver sends the SQL statement forrun-time compilation and execution in the database server. For example:

Statement stmt = aConnection.createStatement();

ResultSet rs = stmt.executeQuery("SELECT * FROM DIR.AUSTIN");

• Create a prepared statement object for executing precompiled SQLstatement by instantiating the java.sql.PreparedStatement class.

When created, the object sends the SQL statement for compilation. Thecompilation result is stored for use in the subsequent execute methods.This mechanism provides more efficient SQL execution than using astatement object would. A prepared statement allows parameterized SQLstatements. The parameter is passed by a value (as an IN parameter) andidentified by ? tokens inside the SQL statement. There are several setmethods: set<DataType> (DataType is one of the common SQL datatypes) is used to set a parameter based on its relative position amongother parameters in the SQL statement. The statement is executed whenthe program calls an execute method on the object. For example:

// Select all names which have name like ’AB%’PreparedStatement stmt = aConnection.prepareStatement("SELECT * FROM DIR.AUSTIN WHERE #F#NAME LIKE ?");stmt.setString("AB%");ResultSet rs = stmt.executeQuery();

• Create a callable statement object for executing database-storedprocedures by instantiating the java.sql.CallableStatement class. Acallable statement is a type of prepared statement that is used for handlinga stored procedure call statement. Its interface is a class that extends thePreparedStatement class. When created, the object sends the callstatement to the database server for compilation. The compilation result is


stored for use in the subsequent execute methods. A callable statementalso allows parameterized stored procedures. In addition to IN parameterpassing, the interface also handles OUT parameter passing. TheCallableStatement.registerOutputParameter method registers the type ofparameter in the statement. After execution, use a getter method with thesame data type to retrieve the parameter. For example:

// Calculate, update and retrieve the new salary// Call GetNewSalary(name,salary)// name is IN parameter, salary is OUT parameterCallableStatement stmt = aConnection.prepareCall("CALLGetNewSalary(?,?)");stmt.setString(1,"Dilbert");stmt.registerOutputParameter(2,java.sql.Types.DECIMAL,0);stmt.executeUpdate();BigDecimal newSalary = stmt.getBigDecimal(2,0);

The statement, prepared statement, and callable statement have severalexecute methods:

• executeQuery(String aSQLStatement), for executing a query that returns asingle result set.

• executeUpdate(String aSQLStatement) - This is for executing a statementthat returns no row, such as UPDATE, DELETE, and INSERT statements.

• execute() or execute(String aSQLStatement) - This is for executingcomplex or multiple SQL statements altogether, which may return severalresult sets. Use getResultSet and getMoreResults methods to obtain thenext result set.

11.5.1.4 JDBC result setThe JDBC result set contains a set of rows from the results of executing aquery. The java.sql.ResultSet interface class implements the result set. Acolumn in a row is specified by a positional index or by a column name. Toretrieve a column value, the ResultSet class provides several getter methodsin the form of get<DataType> (where DataType is one of the common SQLdata types). The getter method accepts column position or column name asits parameter. The ResultSet.next method advances at the next row. It returnstrue if the next row exists; otherwise, it returns false. For example:

Statement stmt = aConnection.createStatement();ResultSet rs = stmt.executeQuery("SELECT * FROM DIR.AUSTIN");while (rs.next()) { // Retrieve next recordString name = rs.getString("1");String dept = rs.getString("DEPT");


System.outl.println("Name: " + name + " Dept: " + dept);}

11.5.2 SQLJSQLJ is the embedded SQL in Java language. SQLJ statements are similar tothe embedded SQL statements in ordinary programming languages, whichare precompiled and bound into the database. SQLJ statements are staticand based on the ANSI standard SQLJ language syntax. The SQLJ staticSQL model is designed to complement the JDBC dynamic SQL model. In astatic SQL environment, a program that contains SQL statements cannotchange SQL statements during run time. The program undergoesprecompilation, which checks SQL syntax, verifies SQL consistency againstdatabase schema, and checks data transformation between Java data typesand SQL data types. For more information about SQLJ, visit the Web site athttp://www.sqlj.org.

SQLJ has two components: The translator and the run-time components.Both are written in pure Java. The SQLJ translator performs precompilationand translates embedded SQL statements into SQLJ run-time calls. TheSQLJ specification allows the run-time component to perform SQL operationsdirectly into the database or to issue JDBC calls to the database via theJDBC layer.

Developers create embedded SQL programs by creating Java programs withthe .sqlj extension. SQLJ programs embed SQL statements among Javastatements. A #sql token in the beginning of a statement identifies an SQLJstatement. The SQLJ translator precompiles .sqlj files into .java files and thenautomatically calls the Java compiler to produce the .class files. When theprogram runs, it automatically invokes SQLJ run-time components that callJDBC drivers or call native database operations.

11.5.3 SQLJ and JDBC comparisonSQLJ contains static SQL statements; JDBC supports dynamic SQLstatements. In a dynamic SQL model, an application may change any SQLstatement during run time, thus, it is more flexible. Nevertheless, dynamicSQL statements require run-time compilation, which may catch somerun-time errors. SQLJ precompiles SQL statements before the programexecutes. It enforces strong type checking between Java data types and SQLdata types. The precompiled static statements will ensure that all SQLstatements are verified against the database and will run, thus, reducingapplication maintenance costs.


SQLJ syntax is more concise than JDBC. SQLJ can embed Java variablesinto SQL statements. JDBC requires separate statements to bind variablesusing their position or column name. Developers will find it more convenientto use SQLJ statements. Therefore, it may reduce the development costs.SQLJ binds static statements into a database. The bind process providesprivilege and authorization checking. SQLJ separates the package ownerfrom the package runner providing better data manageability. JDBC programscannot check user privileges until run time. Most applications require morestatic statements than dynamic statements. Yet, to exploit JDBC dynamicSQL features, you can combine SQLJ and JDBC inside one program. SinceSQLJ includes JDBC support, the program can create a JDBC connectionand use the connection for JDBC dynamic SQL statement. It can use thesame connection to set a connection context for SQLJ static SQL statements.

11.5.3.1 SQLJ statement constructSQLJ programs embed SQL statements among Java statements. SQLJstatements are not Java statements. To identify SQL statements inside aprogram, SQLJ statements always begin with #sql. In the precompilation, theSQLJ translator will convert each statement that starts with #sql intocorresponding Java statements. The syntax of an SQLJ statement is:

#sql <sqlj-clauses>;

The semicolon (;) ends the SQLJ statement.

There are two SQLJ statement main constructs: SQLJ declarations andexecutable statements.

11.5.3.2 SQLJ declarationSQLJ implementations use several Java classes. In developing SQLJprograms, you do not write these classes using Java statements directly.Instead, SQLJ allows you to write a concise description of the classes usingan SQLJ declaration clause. Since a declaration represents a class, the rulesfor placing a declaration are the same as those of Java classes.

Now, there are only two types of SQLJ classes: The connection contextclasses and the iterator classes. The syntax of a connection contextdeclaration is:

#sql <modifier> context <context_class_name>implements <interface_class>with (var1=val1,..);

where <modifier> can be any Java class modifier, such as abstract, final,and public. The implements clause is optional and is used to derive some


interfaces from interface classes. The with clause is optional and is used toinitialize variables with constants.

The syntax of iterator declaration is:

#sql <modifier> iterator <iterator_class_name>implements <interface_class>with (var1=val1,..)(<type_declaration>);

where <type_declaration> contains class parameter type declaration.

11.5.3.3 SQLJ executable statementAn SQLJ executable statement represents a block of Java statements. Theembedded SQL statement will be translated into a block of correspondingJava statements that perform the actual database calls. In the executablestatement, embedded SQL is enclosed with curly brackets. Depending on theSQL statement, an executable statement may or may not return rows ofrecords. An assignment clause has a result expression for returning the resultset. The syntax of the executable statements is either in the form of astatement clause:

#sql [<context>] { <embedded-sql-statements> };

which returns no result, or an assignment clause:

#sql [<context>] <result> = { <embedded-sql-statements> };

which has the <result> variable to hold the resulting rows or operationcounts. The <context> is optional and specifies either a connection context oran execution context.

11.5.3.4 Java Host Variable and host expressionSQLJ allows Java variables to be included inside SQLJ statements. Suchvariables are known as host variables. You can also create Java expressionsusing Host Variables inside SQLJ statements, to form Java host expressions.A host variable or a host expression begins with a colon (:). The syntax for aJava host expression is:

:<mode><a-java-variable>

or

:<mode>(<a-java-expression>)

where <mode> is optional and can be IN, OUT, or INOUT (default).


11.5.3.5 SQLJ contextAn SQLJ context holds the state information for processing and retrieving theresult of SQL statements. There are two types of SQLJ contexts: Theconnection context and the execution context.

1. A connection context represents a session into a database. One programmay access several databases by using multiple connection contexts. Youcan use a connection context to perform SQL operations on thecorresponding database session. To create a connection context, youshould create a new connection context class by using the SQLJconnection context declaration. Then, you create a new instance of thecreated class.

2. An execution context represents an instance of the SQLJ run-timecomponent. By specifying execution contexts, you can use multiplethreads, with each execution context using a thread; or, you can usedifferent SQL execution flows with separate status information for eachexecution context. Each connection context has its own default. Therefore,you do not need to specify the execution context for newly-createdconnections. To create a new execution context, create a new instance ofthe sqlj.runtime.ExecutionContext class. Then, you can combine thisexecution context with any connection context in the <context> clause ofSQLJ-executable statements.

11.5.3.6 Result set iteratorThe Result Set Iterator is the cursor equivalent in SQLJ. To retrieve resultingrows from a query, use a result set iterator object. To create an iterator, createthe iterator class using the iterator declaration statement, then declare anobject of the class. Use this object to hold the result of the SQLJ assignmentclause. This operation, in effect, populates the iterator with the resulting rowsfrom the query. You can then retrieve column values from the iterator object.

To access a column in a row, SQLJ allows an iterator to specify columns bydata type or by name and data type. Based on this criteria, SQLJdifferentiates two types of iterator:

• A Positioned Iterator specifies a column by its relative position in the queryand its data type. To retrieve a row, use the FETCH executable statementwith the iterator as the cursor. The INTO clause in the FETCH statementretrieves column values into Java host variables. The column position inthe INTO clause is the same as what is defined in the iterator declaration.

For example:

#sql public iterator PosIter (String, String);...


class People{...public void getPeopleInfo() {...String name = String("");String dept = String("");PosIter peopleCursor = null;

...

#sql peopleCursor ={SELECT NAME, DEPT FROM DIR.AUSTIN };

...

while (true) {

#sql {FETCH :peopleCursor INTO :name, :dept};if( peopleCursor.endFetch() ) break;System.out.println("name:" + name + " dept:" + salary);

}...peopleCursor.close();}}

• The Named Interator specifies a column by its name and data type. Toretrieve the next row, use the next() method of iterator class. To access acolumn in a row, use the corresponding accessor method. SQLJ translatorautomatically adds an accessor method for each column into the iteratorclass. The accessor method has the same name as the column name andreturns the same data type as the column data type. For example:

#sql public iterator NamedIter (String name, String dept);class People{

...public void getPeopleInfo() {...NamedIter peopleCursor = null;...#sql peopleCursor ={SELECT name, dept FROM DIR.AUSTIN };...while (peopleCursor.next()) {

System.out.println( "name:" + peopleCursor.name()+ " dept:" + peopleCursor.dept() );...

}

peopleCursor.close();

...

}

}


11.5.4 SQLJ JDBC InteroperabilityIn some cases, a Java program may require both static and dynamic SQLstatements. The program should contain both SQLJ and JDBC statements.To do this, SQLJ provides some JDBC support that performs conversionsbetween a connection context and a connection, and between an iterator anda result set. Using this mechanism, the JDBC connection and thecorresponding SQLJ connection context will refer to the same databasesession.

• To convert an SQLJ connection context into a JDBC connection, use thegetConnection method of the connection context class:

Connection jdbcConn = sqljContext.getConnection();

• To convert a JDBC connection into an SQLJ connection context, use aconnection context constructor that takes a JDBC connection as its inputparameter and returns the corresponding SQLJ connection context:

#sql context SQLJContext;

SQLJContext sqljContext = new SQLJContext(jdbcConn);

• To convert an SQLJ iterator into a JDBC result set, use the getResultSetmethod of iterator class to return a JDBC result set:

SQLJIterator sqljIterator;ResultSet jdbcResultSet = sqljIterator.getResultSet();

• To convert a JDBC result set into an SQLJ iterator, use a CAST executablestatement to populate a named or positional iterator object by result setdata:

ResultSet jdbcResultSet;

...

jdbcResultSet = jdbcStatement.executeQuery("SELECT * FROM

DIR.AUSTIN);

...

SQLJIterator sqljIterator;

#sql sqljIterator = { CAST :jdbcResultSet };

...

11.6 Conclusion

This part of any project is probably the most important. A few generalguidelines are:

• Avoid proprietary middleware.

• A design assessment is a good start.


• A Proof of Concept (POC) will show how selected connectors andapplications work together.

• A preliminary test for indicators of performance can show designbottlenecks.

Some additional items to note:

• A connector solution should be object-oriented in nature and fit into aiterative and incremental development cycle. When migrating, it iscommon to have the interface change over time.

• Most enterprise solutions need to be JavaBean oriented. If more time wasavailable, this would have been a follow-up to the steps defined above. Forexample, the Query, Connector, and Directory (include their subclasses)were good candidates for JavaBeans.

• If the application logic is coded in a language other than Java and iscomplex, wrapping (reusing) it is probably the best solution initially. Forexample, if the application logic has been coded in C++, reusing it using acombination of RMI and Corba is probably a better solution thanredeveloping it in Java. It is less likely to introduce defects into thefunction, and the time-to-market will probably be shorter.

• If direct access to a relational database is required and the associatedapplication logic is relatively simple, JDBC is probably the best bet.

• If you intend to use JDBC, if possible, use SQLJ where static sql existsrather than JDBC and dynamic sql. This will provide performance gains.

• If the e-business solution requires application-to-applicationcommunication or seamless access to separate enterprise applications, amessaging mechanism might be the best option. IBM MQSeries productrange is geared to this type of integration.

• If access to legacy enterprise applications is required, a specific connectormight be the easiest and most efficient mechanism for integrating theapplication into an e-business solution. IBM provides a wide range ofconnectors specifically geared towards accessing legacy applications


Appendix A. e-business application performance

Designing performance solutions is imperative. Although this is not a newconcept, it has a new dimension because the computing model defined by theIBM Application Framework for e-business is based on several new andexciting technologies, such as the Enterprise Java Bean (EJB) distributedobject architecture. Also, while value-added networks and the Web have beenaround for decades and years, the explosion of e-business and e-commerceis fairly recent. New metrics, bottlenecks, and demands for performanceabound.

It was beyond the scope of this project to address e-business applicationperformance. This appendix introduces the approach taken in an excellentwhite paper available at the following Web site:http://www-4.ibm.com/software/developer/web/patterns/ebusiness-performance

-customer-v2.pdf

The paper discusses architecture, design, development, and deploymentissues that affect the performance of e-business solutions. The paperaddresess performance questions by sharing real life experiences withprojects and products across IBM, from experiments conducted by IBMResearch to the stress testing of real Web-based applications, such as theNagano Olympics Info'98 (intranet) application.

A.1 When to consider performance

You need to include performance considerations at the architecture anddesign phase for all e-business development projects. Without clearperformance objectives during initial architecture definition and high-leveldesign, performance becomes an afterthought - something to be dealt withafter hardware and software products have been selected and applicationcode developed. Now, there is enough data and experience to know thatthese projects often fail when they are deployed - not because they cannotdeliver the required business function, but because they cannot service thedemand generated by their customer community in a satisfactory way. Thetechnology and tools may be too new for reliable performance and scalingestimates and projections to be made. Some of the most important questionsare:

• How do you predict the performance of Web-based applications?

• How do you understand the potential performance and scalability issues ofbuilding your applications in an environment that has an effective life-spanof a Web year?


• And, finally, how do you measure end-to-end performance?

A.2 Other performance factors

Even if the required products and technologies have world-classperformance, scaling, and other related capabilities, you must still designyour application with performance in mind. When evaluating performance inthe e-business environment, you will need to collect other performanceinformation, such as:

1. Absolute performance and throughput of a specific product (for example,Web server X can serve up 3000 pages a second).

2. Specific tuning information of a specific product (for example, the XYZparameter must be set to ON when using Java).

3. The relative performance among technologies (for example, the sameprogram written in Java will run 87.34 percent as fast as the same programwritten in ADA).

4. Competitive performance (an entity bean will initialize 13 percent faster onan IBM processor than on a SUN Microsystems Model QQQ).

A.3 End-to-end performance

A key concept used in part two of this book is to use nodes or building blocksto define/delineate the solution. This concept is used here. In the diagrambelow, the highest-level building blocks include:

• Client

• Internet network

• Web Servers

• Integration Servers

• Application Servers

• Database Servers

290 From Client/Server Applications to e-business Applications

Figure 78. Web-based transaction flow

The performance metric of an e-business solution is typically defined as theresponse time for the end user; so, the performance problem is often definedas slow response time when the user takes an action or series of actionswhen using the application. This request may be for information or to have theapplication store or analyze information on their behalf. The user, quite rightly,has no concept of how much work and how many systems are actuallyinvolved.

Unfortunately, many application developers and systems support teams alsolack a concept of what work and systems are involved in these transactions. Asimple transaction may turn out to be a very complex series of data flowsinvolving multiple systems in multiple locations. It may cause events tocascade through multiple systems before the summarized result is presentedto the user.

The building block approach allows us to move from the response time is slowdescription of performance to decomposing the solution into meaningfulnodes and analyzing each node in turn. In addition, there are system-wideconsiderations, such as security and load balancing, that span nodes.

A.4 A few general guidelines

There are many specific performance guidelines, hints, tips, and other helpfulinformation in each chapter. There are also a few macro-level guidelines forperformance design that apply to all components of an end-to-end e-businesssolution. You should keep these in mind as you evaluate the architecture,design, and deployment.

Clients

IntegrationServers

WebServers Application

ServersDatabaseServers

Load Balancing

Network

Security

Internet

e-business application performance 291

• An e-business solution will have good performance if, and only if, attentionis paid to each node: The client, the network, the servers, etc.

• You must understand the detailed data flows and systems implications upfront in your initial design. This analysis, when combined with refinementsin understanding during the application’s development cycle, will allow youto correctly set expectations and structure your applications and systemsfor success.

• Plan for growth in your initial design. The Application Framework fore-business is based on technology that is open, industry-standard, andavailable on many platforms including those from IBM and other vendors.One of the benefits of Java is WORA (write once, run anywhere). Asolution that is designed to be 100 percent platform-agnostic and modularcan, if required due to growth, be distributed. A solution that usesproprietary interfaces, system utilities, tools, extensions , etc. may end upstuck on a platform that does not scale. Since developers often chooseproprietary implementations in the belief that closed systems performbetter than open systems, a plan for future growth requires a goodunderstanding of the longer term performance and scalability needsversus the short term performance optimizations derived from proprietarytechnology.

• Use the latest releases of infrastructure and system software. Eachrelease of e-business software and related infrastructure and systemsoftware provides faster performance than the prior one. In some cases,such as the IBM JDK 1.1.7 for Windows and OS/2 2 , the latest release isdramatically better. Using the latest release of software, whether it is theJava JVM, Web server, TCP/IP network stack, etc., is a key considerationfor achieving good performance. You should pay particular attention tosoftware prerequisites and corequisites, especially if your solutionincludes existing systems in the enterprise.

• Cache. Cache information anywhere and everywhere possible. We willdiscuss how caching is done in many of the following specific sections, butthe macro-level guideline is cache, cache, cache!

Now that we have documented this short list of general guidelines, we willdefine a general methodology for assigning a performance budget to eachlogical node or segment of an e-business solution. After that, we will considereach part of the schematic in turn and provide more specific hints, tips,guidelines, tools, and a discussion of some of the trade-offs that may beapplicable.


A.5 The budget

How can you define the expected performance of an Internet application?The Internet is a vast interconnected network with over 5 million domainnames ! You cannot define the performance of the Internet, but you candefine the performance objectives for your solution. A common performancemetric is interactive response time as perceived by the end user. You candivide your solution up into three buckets and assign a percentage to eachbucket:

• Time spent in the client - some percentage

• Time spent in the network - some percentage

• Time spent in servers - some percentage

For example, if your goal is two-second interactive response time, you mightassign the percentages as:

• Client - 5 percent (100 ms)

• Network - 30 percent (600 ms)

• Servers - 65 percent (1300 ms)

You can then apply the target number (for example, one 300 millisecond totalfor the servers) to the detailed data flows you defined during your initialdesign using the building blocks. Based on the total work required by eachserver, the inherent network latency of the enterprise network, and the totalnumber of trips between server systems, you can evaluate how close to yourtarget you are. The response time goal, and the ratio of that goal assigned toeach bucket, can be used during the initial design and data flow definitionphase. The allocation of response time should continue through each step inthe development process up to and including production deployment. Theassignment of ratios among client, network, and server may require aniteration or two as well. The GEI performance team found that developmentteams initially assigned a very low percentage (about 5 percent) to the client,only to find this time to be in the 20-40 percent range of total time. This hasusually been a surprise to the enterprise for which the investigation is beingconducted.

The following chart provides an example budget for e-business solutions. Thebudget you develop for your application may be quite different based on userrequirements, the complexity of the application, the ability to define thenetwork infrastructure (that is, for an intranet solution), etc.

e-business application performance 293

Figure 79. Response time budget

A.6 Additional information

For the complete discussion, see the Web site:http://www-4.ibm.com/software/developer/web/patterns/ebusiness-performance

-customer-v2.pdf

Server Time

55.0%

Response Network Latency20.0%

Client Response Processing15.0%

Client Request5.0%

Request Network Latency

5.0%


Appendix B. IBM software and development tools

IBM has the most significant product portfolio in the industry. This sectiondescribes some IBM software and development tool offerings.

B.1 IBM product portfolio

The following diagram describes some IBM software offerings and how theyfit into the application topology diagram. This is not meant to be acomprehensive index of product offerings. Rather it is meant to place theseofferings in the perspective we have used throughout this publication. Figure80 maps the IBM software product families.

Figure 80. IBM software product families mapped

WebSphere Application Server combines the control and portability ofserver applications with Java performance and manageability to offer acomprehensive Web application platform. It helps companies manage thetransition from simple Web publishing to advanced e-business applications,integrating a wide variety of enterprise software including CICS, IMS,

DB2 UDB

HT

TP

Ser

ver

Inte

rnet

Dis

patc

her

Web

Sph

ere

Per

form

ance

Pac

k Web/Application ServerClient

ExistingApps and Data

WebSphereApplication Server

Lotus DominoApplication Server C

onne

ctor

sT

XS

erie

sM

QS

erie

s

Directory & Security Services

Secureway

IBM

eNet

wor

kF

irew

all

System Management: Tivoli


MQSeries, DB2, and SAP. IBM industry-leading transactional applicationsserver technologies TXSeries, Component Broker, Net.Commerce, andWebSphere Application Server are now in the WebSphere family (seehttp://www.software.ibm.com/webservers/appserv).

The Lotus Domino Application Server is optimized for collaborativeapplications, supports Web-serving and WebSphere servlets, and is tightlyintegrated with workflow services for secure interactive business applications(see http://www.lotus.com/home.nsf/tabs/domino).

DB2 Universal Database powers industry, business intelligence, and contentmanagement e-business applications, easily integrating traditionaloperational data with images, sound, and video to add new and excitingapplication dimensions. DB2 runs on NT and UNIX systems as well as S/390and AS/400 (see http://www.software.ibm.com/data).

TXSeries is a distributed transaction management system that integratesindustry-leading transaction software to enable new e-business applicationsthat use the reach of the Web and existing transaction systems (seehttp://www.software.ibm.com/ts/txseries).

MQSeries message software simplifies the task of connecting yourapplications across dissimilar environments allowing information exchangeacross more than 25 different operating platforms in a way that is easy forprogrammers to implement (see http://www.software.ibm.com/ts/mqseries).

WebSphere Performance Pack enhances the availability, scalability, andperformance of Web sites by providing caching, server load balancing, andWeb site content replication components (seehttp://www.software.ibm.com/webservers).

SecureWay Software provides integrated directory, connectivity, and securitybetween users and applications for e-business in a networked world.

Tivoli Enterprise provides management solutions that make it easier forlarge organizations worldwide to centrally manage computing resources,thus, giving them the power to manage e-business applications. Tivoli ITDirector brings similar solutions to small and medium-size businesses (seehttp://www.tivoli.com). Tivoli Cross-Site manages critical e-businessactivities across the extended enterprise. It is a collaborative managementtool that enables trading partners to collectively manage their e-commercee-business environment (see http://www.cross-site.com).

The eNetwork Firewall controls external access to enterprise resources,selectively restricts access to the enterprise by knowing the source of access


requests, and facilitates secure communication with selected partners bysetting up virtual private networks (seehttp://www.ibm.com/Security/html/prod_fire).

B.2 IBM development tools classification

Tool selection is usually partitioned by the roles performed. Figure 81 showsthe three broad categories (roles) and the tools available to each of themfrom IBM.

Figure 81. IBM tool classification

Domino Designer R5 is the fastest most cost-effective way of creatinghigh-value business solutions. This world-class development environmentincludes WYSIWYG HTML authoring, site/page and frameset design, andclient and server-side scripting (see http://www.lotus.com).

The following are the key features of Domino Designer:

• It contains everything you need to create secure end-to-end Websolutions.

• It connects Web applications to live data in relational databases, ERPapplications, and Transaction Processing Systems.

• It gives you the power to build locally and deploy globally.

Content AuthoringContent Assembly

& Management ApplicationsDevelopment

Lotus Notes Designer for Domino

Visual Age

NetObjects Fusion

NetObjects FusionBuilder

Visual Age (limited)

WebSphereStudio

IBM software and development tools 297

The VisualAge family of application development environments allowsdevelopers to easily build, test, and deploy e-business applications based onJavaBeans, Java applets, servlets, and Enterprise JavaBeans. The familyincludes: VisualAge for Java, Enterprise Edition, which is an integrateddevelopment environment for Java programmers, VisualAge Generator,which is rapid application development for traditionally-skilled programmers,and VisualAge TeamConnection Enterprise Server, which isrepository-based software configuration management (SCM) to manage andcontrol development projects, increase team productivity, and improvesoftware quality (see http://www.software.ibm.com/ad).

WebSphere Studio, V3.0 offers easy-to-use tools for creating Webapplications that include server-side logic with little or no programming.Experienced Java programmers can also use the tools to tailor applications totheir needs (see http://www.software.ibm.com/webservers/studio). The toolsare:

• A new integrated visual JSP/HTML page designer

• A new integrated remote debugger. Requires WebSphere ApplicationServer Standard or Advanced Edition, V3.0

• Improved Web project workbench

• Improved servlet and database Wizards

• Newly-integrated applet creation tool

• Improved integration with VisualAge for Java

• New integrated graphics tools


Appendix C. Applying the e-business design approach

This appendix follows the approach outlined in part two of this book. It is asummary of the details used to input into the solution selection anddevelopment process.

Figure 82. Flowchart of the e-business design approach

There is one key difference for this project. In this project, the fact that we aremigrating from an existing application to an e-business application is a givenstarting point.

C.1 Gathering requirements

The requirements you gather serve as the foundation upon which the rest ofyour solution will be constructed. It is these requirements that you map yourarchitectural alternatives to, and it is these requirements that are the basis forthe selection criteria used when choosing an architecture.

For this project, the outcomes of some of these steps are taken as given, butsome key points have been noted for completeness.

Implement

Gather Requirements



Select Technologies


C.1.1 Requirements that indicate an e-business solution

This was taken as a given by virtue of the definition of the project. The needto have universal access to directory data using a Web browser indicates ane-business solution.

C.1.2 Assessing readiness for an e-business solution

This step was also taken as a given by the projects definition. It is animportant area though, particularly with respect to skills, resources, riskaversion, new technologies, etc. Many projects fail because they do notadequately assess an enterprise’s ability to support such a project with itscurrent infrastructure.

C.1.3 Understanding business drivers

We created the following business drivers for our project.

The business context for migrating this application is that it serves as a firststep towards the Human Resources department establishing an EmployeeSelf Service site. Of secondary significance is that the IT department hopedto use this project to gain experience with e-business technologies andinfrastructure while executing this process.

By making the information and resources available on the Self Service site,Human resources will free up valuable personnel that could be deployedelsewhere. It will reduce the number of sporadic calls from frustratedemployees. It will further empower employees to maintain and accessinformation from any point in the Internet.

C.1.4 Proposing a solution workshop

For the purposes of this project, the workshop was an intra-team discussion.It included a number of conference calls with one of the original developersand the project sponsor. The project sponsor can be thought of as theexecutive sponsor in the business situation.

We spent most of our time defining the current environment. That is:

• The network infrastructure

• The integration requirements

• The target client environment

Our goal was to ensure that each member of the team clearly understood thecurrent and future requirements.


Some of the issues we encountered were:

• Lack of a design document.

Many of the original team members were no longer available making itimpossible for a complete handover. As with many other projects, designdocumentation could not be found or was not available.

This makes the possible e-business leverage points, which are critical inorder to access legacy enterprise applications and data, difficult toidentify.

The only option available was to reverse-engineer the design by looking atthe source code and experimenting with the application. This seriouslyimpacted all phases of the project.

In the real world, there are cases where the only design available is thesource code. You might have a design document, but how up-to-date is it?The tendency to rewrite the unknown rather than reuse it often seemseasier. In fact, it ends up being more time-consuming, usually resulting infunctions being redeveloped or defective.

• Multiple versions of source code

From the time the original project ended to the time the code was handedover, a maintenance phase with no disciplines in place had beenimplemented. There ended up being two versions of the code.

So, it would be best to make sure you have the latest correct version ofsource code before you begin.

• Inability to rebuild an existing system

The application’s source code is vital if you intend to reuse part of it oreven to aid in the understanding of the functionality provided by theapplication. It needs to be complete and be the correct version.

If the source code is incomplete, the options available for reuse may belimited. Even with a large amount of effort, it may be impossible to rebuildthe system.

The Finder source code provided to us was incomplete and the incorrectversion. We were unable to rebuild the Finder application because someof the source code files were missing. This limited our ability to reusesource code.

C.1.5 Finder application requirements

Based on our need for useful examples to illustrate some of the issues wewanted to highlight, we developed the following application requirements

Applying the e-business design approach 301

shown in Table 54, which represents our general ranked requirements. Theywere made as realistic as possible.

Table 54. Ranked business requirements

C.2 Develop architectural alternatives

Some business problems can be solved using well-understood designpatterns. More often, several architectural alternatives will be technicallypossible. Presenting multiple alternatives is valuable because it provides aforum in which to discuss the technologies relative to the requirements. It isusually at this point that additional requirements or issues arise.

For this project, the outcomes of certain of these steps are taken as given,but some key points have been noted for completeness.

C.2.1 Is a simple e-business solution applicable?

Actually, for this project, since our objective was to illustrate certain issues,we answered no to this question.

Requirement Rank


BR1 - Make directory information available to employees and thegeneral public on the intranet and the Internet.

High

BR2 - Reduce the administrative burden on HR staff by allowing usersto update their own details.

Medium

BR3 - Evolve to a platform-independent e-business infrastructure. High

BR4 - Provide a browser-based user interface using HTML only. Medium

BR5 - Provide the user with facilities to create and save named queriesand the ability to create and maintain a personal directory list.

Low

BR6 - Support an aggressive production deliverable date. High

Other Requirements

OR1 - Access must be dialup as well as LAN. High

OR2 - Migration strategy should be incremental, that is, the initial set ofbusiness requirements must be able to be met without requiring acomplete rewrite or new technical infrastructure to purchased.

High

OR3 - Access control should be provided based on user ID and role. Medium

OR4 - Construct for growth and scalability Medium


C.2.2 Developing business scenarios

For simplicity, three types of user have been defined for the e-businessversion of the Finder application. A simple set of one-line scenarios havebeen created as shown below. They are grouped by user type. This user typealso defines the security requirements.

An Anonymous user (Any user not logged in) can search and retrieve arestricted subset of information.

An employee can:

• Perform all the actions of an anonymous user.

• Log in to the application as a registered user (a registered user has arecord in the directory).

• Search and retrieve all available directory information about all employees.

• Create named queries.

• Create a personal directory list and add selected result set recordscontaining selected resultset rec (offline option).

• Update his or her own record information.

• Specify whether details are available to anonymous users.

A human resources staff member can:

• Perform all actions of an employee

• Create/delete employee records

• Update any employee record

A simple user object model has been created for the e-business form of theFinder application. Although expressed in object modelling notation, a userobject should not be confused with a programming object or class.

The intent of a user object model is to identify the things in the applicationdomain that a user sees (possibly only conceptually) and manipulates in theuser interface of the application.

Table 55 identifies which users can perform which actions on which userobjects.

Table 55. Application objects (user view) and user rights

User object Action Anonymous Employee HRStaff

Directory Execute Search Yes Yes Yes


C.2.2.1 Additional user interface design informationHere are some topics we discussed to design a user interface for the Finderapplication.

Options for entering query criteria

Directory List

Add Yes Yes Yes

Remove Yes Yes Yes

Find Yes Yes Yes

QueryAdd Search Criteria Yes Yes Yes

Remove Search Criteria Yes Yes Yes

Named Query

Create No Yes Yes

Set/Get Search Criteria No Yes Yes

Set/Get Display Fields No Yes Yes

Named QueryList

Add No Yes Yes

Remove No Yes Yes

Find No Yes Yes

Query Result

Clear Yes Yes Yes

Copy To Yes Yes Yes

Get Record Yes Yes Yes

Record

View No Yes Yes

Create No No Yes

Delete No No Yes

Update No Yes Yes

PersonalDirectory

Add Record No Yes Yes

PersonalDirectory Entry

View No Yes Yes

ApplicationLogin No Yes Yes

Logout No Yes Yes

User object Action Anonymous Employee HRStaff


This section first considers the query functionality provided by threeimplementations. It then makes some tentative design decisions as to how toincorporate the best features into the e-business version.

Client/server Finder application

This application has a single modeless search form with multiple modelessresults windows.

• Specify directory type

• Specify directories to search (can select 1 to N)

• Can search using multiple attributes (attribute fields dynamically displayedbased on directory type)

• Fuzzy search option (unexplained)

BluePages - Java

This application has a combined search and results form, two search mode(Simple and Advanced), and dynamic screen modification.

Simple

• Can select directories to search. Select one from a list or ALL


• MRU list on name

Advanced

• Directory is assumed to be all.

• Can search using one to three attributes. Select each attribute from thelist.

• Relationship Operator (Starts With, Is, Isn’t).

BluePages - Intranet

This application has a combined search and results page for the Advancedsearch. A simple search is usually at the top of all Intranet pages combinedwith a link to the Advanced page. Simple search switches to Advanced pageto perform searches and display results. Advanced page is built using frames.Search criteria are in a fixed region at the top.

Simple

• Directory is assumed to be all



Advanced

• Can select directories to search. (Select one from a list or ALL).

• Can search using one single attribute name. This attribute is selected froma list.

• Fuzzy search option.

C.2.3 Using e-business building blocks

The decisions regarding the application are broken down into the e-businessbuilding block components. The tables that follow briefly describe thosedecisions. The building block diagram is shown below.

Figure 83. e-business building blocks

Security and Systems Management layers are considered first since they areend-to-end architectural elements. Decisions in these layers will impact allother elements.

C.2.3.1 SecurityTable 56 includes the information we discussed and the decisions we madefor the security building block.

Table 56. Security decisions

Decision points Decision

Do transactions need to be encrypted? Login only, potentially server response.

If clients or servers will be outside theU.S., is 40-bit encryption acceptable?

Yes (because it is not financial).

System Management



Security


Table 57 shows user authentication considerations.

Table 57. User identification

How will users be identified?User ID and Password.The role is to be determined from the userID once it is verified.

Is there an existing customer databasethat should be used to identify onlinevisitors to the site?

It should be possible to use the directory toverify valid employees.

Does your customer need to restrictaccess to parts of the site?

Yes. Anonymous users (those not loggedon) can perform queries, but the level ofdetail is restricted. Any user can performan inquiry but needs a login to update.

What privacy rules should be applied toinformation provided by users?

Standard company privacy rules. PersonalDirectory Lists and Named Queries willnormally be stored on the server andsubject to these rules.

What are the legal requirements andcompany policies for auditing contentchanges and transactions?

Logging of all updates to information(Time/date, user ID, and client IP).

Does the company already have a secureDMZ into which the Web server can beplaced?

Yes


Basic Authentication No.

Client Certificates No.

Application Specific Yes.

Cookies Yes, they might be used for illustrativepurposes.



C.2.3.2 Systems managementTable 58 includes the information that we discussed and the decisions wemade for the systems management building block.

Table 58. System management decision points


Does the company have the infrastructureto install and run its own e-businessserver?

Yes

What hours of service should beavailable?

23x7 (23 hours a day seven days a week)

Is it acceptable to have any scheduleddowntime for maintenance?

Yes, but it should be scheduled to impactthe least number of people during workinghours.

How important is it that the service neverbe interrupted, even for unscheduledcomponent failures?

The application is not mission-critical.

If interruptions do occur, what should bethe target time for restoring the service

For this application, the target time shouldbe within one business day.

How should partial or total failures bemonitored an handled?

There is no mechanism in place other thanthe existing company support process forinternal applications.

What are the response time targets?Within reasonable limits of the existingClient/Server version. Exact requirementsfor each transaction should be calculatedwith the user community.

Do you need a recovery plan for thise-business system or will it be covered byyour organization’s existing processes?

It will be covered by existing processes.

How should the architecture support theprocess of problem reporting, tracking,and fixing?

This decision is vital but was not covereddue to time constraints.

What statistics do you need to keep aboutthe site, and how will they be analyzed?

This decision is vital but was not covereddue to time constraints. At a minimum,statistics for scalability would be kept.

What instrumentation should be includedin the design to measure performance,response times, and availability?

Probably not feasible due to timeconstraints.


C.2.3.3 ClientTable 59 includes the information that we discussed and the decisions wemade for the client building block.

Table 59. Client decision points

C.2.3.4 NetworkTable 60 includes the information that we discussed and the decisions wemade for the network building block.

Table 60. Network decision points

Should the architecture include arepository for statistical data?

Probably not necessary or feasible due totime constraints.


Who is the customer (Internet orintranet)?

Internet

What is the level of the user’s skill? Basic browser user

What languages should the site support? First phase English

What are the user’s usage patterns? Direct searching

Is there a need to distribute applicationcode and, if so, how will it be done?

HTML only

How will the application maintain state? Web server feature

How will the choice of client affectend-to-end response?

HTML

Is the browser the only user interface(UI)?

Yes


Will my solution involve the Internet? Yes.

What protocols will I use? HTTP.

What about data, object and applicationplacement?

Our decision is to simply return all theresults. This might impact network traffic.

What security functions arerequired/provided by this building block?

We only use HTML. No security protocol orFirewall will be used.



C.2.3.5 ServerTable 61 includes the information that we discussed and the decisions wemade for the server building block.

Table 61. Server decision points

Will my existing network function asrequired?

Yes.

How does the network affect myend-to-end response time?

Slow network slow response.


Is this an end-user client-to-server model,or will remote server-to-servercommunications be required?

For this project, it is only an end-userclient-to-server model. The real applicationrequires server-to-server communications.

Does this design call for a single server ormultiple servers?

Yes.

Does my choice of client options affectthe server design?

Yes (we decided to use HTML).

How will I implement my applicationserver business logic?

Using servlets and JSP.

Will I use applet gateways? No.

Do I need to provide mail orconferencing facilities?

No.

Do I have workflow requirements? No.

Should the server provide indexing andsearching or other site navigation aids?

No.

Is distributed object support needed? Not for the initial phase.

What security functions are required inthis building block?

Security functions are needed, but this isoutside the scope of this project.

How can I estimate the servercomponent of end-to-end responsetime?

This needs to be decided but is outside thescope of this project.



C.2.3.6 Application logicTable 62 includes the information that we discussed and the decisions wemade for the application logic building block.

Table 62. Application logic/development decision points

C.2.3.7 ToolsTable 63 includes the information that we discussed and the decisions wemade for the tools building block.

Table 63. Tool selection questions


Is this a logical two-, three- or n-tiersolution?

N-tier (3).

Has it been determined whether to useObject Technology, traditionalprogramming development, or integratedpackages?

OO.

Is application control needed todetermine what information the end-usercan print or save to disk?

No.

Is normal HTML presentation adequateor should the user interface be enhancedthrough the use of Java Applets?

HTML is sufficient for the functions wehave defined.

Is client-side scripting needed? At whatlevel?

Yes.

Will the site use proprietary scripts, tags,or plug-ins?

Not on the client.

Will the site use Java applets? What aretheir connectivity requirement?

No, only pure HTML.

How will the application be split betweenclient-side logic and server-side logic?

Two methods were selected forinvestigation. See Chapter 10, “The Weband application server” on page 203.


How will the applications be built: Usingapplication generation tools, prebuiltpackages, or a combination of the two?

Application Generation Tools.

Will content authoring tools be used? Yes.


C.2.3.8 ConnectorsTable 64 includes the information that we discussed and the decisions wemade for the connectors building block.

Table 64. Connectors decision points

What content management tools areneeded to control the site?

This is not within the scope of this project.

How much integration is provided by theapplication development tool?

This is not within the scope of this projec.

How will a team developmentenvironment be supported?

This is not within the scope of this project.

Will the code be developed on oneplatform and deployed on another?

Yes.

Should the tools be extendable? No.


What enterprise systems, applicationsand data does my e-business applicationneed to access?

Finder application and Finder directorydata source.

How should data be transferred betweendifferent systems?

This is beyond the scope of this project.

How current does the information have tobe?

It does not have to be real-time; local DBcan be used.

Will I require synchronous orasynchronous access?

Synchronous.

Will I require access to different operatingsystem, network protocols, applicationenvironment?

Yes.

Is a new user interface (UI) required? Ifso, what kind?

Yes - HTML.

Will I require additional security policies? This is beyond the scope of this project.

Can I predict what scalability andperformance I will require?

Yes.



C.2.3.9 Enterprise data and applicationsTable 65 includes the information that we discussed and the decisions wemade for the enterprise data and application building block.

Table 65. Enterprise data access decision points

C.2.4 Creating architectural alternatives

Based on the decisions and criteria described above, two architecturalalternatives were selected. This process is fully described in Section 8.5,“Architecture alternatives/selection” on page 167.

C.3 Selecting architectural alternatives

Once a set of architectural alternatives has been developed, the next phaseis to decide which alternative is best suited to your environment. This is done


Do the service hours for the enterprise data repository matchthe e-business application target?

Yes.

How will you map the access authorization rules for thecorporate database to your e-business?

The server uses its ownuser ID to have accessto the enterprisedatabase.

Is your e-business application using the corporate data forreference?

Yes.

Is the data in a format that is easily accessed by distributedsystems?

It is not in the easyformat; the data itselfhas a difficult format(Endian problem).

If additional code is needed to gain access to data (forexample, non-relational data), how will this code bedeveloped?

Special applications.

If access is to relational databases, can the SQL bestructured to minimize network traffic?

Yes

What are the commit and rollback requirements of theapplication?

No


by reviewing each of the requirements gathered. This is summarized in Table66.

Table 66. Business requirements decisions

C.4 Summary

Migrating an existing system in line with an e-business strategy is fraught withmany issues and challenges. We are unable to cover all of these becausemost off them relate to migration of the specifics of an application’sarchitecture.

Like any complex design project, some form of process is needed to go fromthe first idea to the completed design. That process might be completelysubjective, as it might be when you prepare a meal, or it may be very complexand require formal project management. However, some processes alwaystake place.

Requirement Arch.Alt.1

Arch.Alt.2


BR1 - Make directory information available on the intranetand the Internet to employees and the general public

+ +

BR2 - Reduce the administrative burden on HR staff byallowing users to update their own details.

+ +

BR3 - Evolve to a platform-independent e-businessinfrastructure.

- +

BR4 - Provide a browser-based user interface. + +

BR5 - Provide the user with facilities to create and savenamed queries and the ability to create and maintain apersonal directory list.

+ +

BR6 - An aggressive production deliverable date. + 0

Other Requirements

OR1 - Access must be dialup as well as LAN. + +

OR2 - Migration strategy should be incremental. 0 +

OR3 - Access control should be provided based on user IDand role.

0 0

OR4 - Construct for growth and scalability - +


We are very deliberate in our use of the term approach rather thanmethodology. A methodology implies a formalized process with fairlywell-defined entry and exit criteria at each step of the process. They tend tobe very thorough, complex, and well-suited for what they are intended to do,but well beyond the scope of this document.

Instead, we borrowed some of the key concepts from these existingmethodologies to create a simpler less-formalized approach.

The approach we used could consume a considerable amount of time andresources. That is why it is important to balance the value of the solutionagainst the time and effort you will put into it. Many times, the complexity of asolution is related to the business problem, not to its scale.


Appendix D. Special notices

The objective of this book is to describe process and design considerationswhen migrating an application from the client/server to the e-businessapplication model. The intended audience for this book includes projectmanagers, IT architects, systems designers, and programmers interested ine-business.

Most migration projects may require advanced skills. IBM Global Services (IGS)professionals are trained to provide all types of customers with a consistentapproach to applying the process and building e-business solutions.

References in this publication to IBM products, programs, or services do notimply that IBM intends to make these available in all countries in which IBMoperates. Any reference to an IBM product, program, or service is notintended to state or imply that only IBM products, programs, or services maybe used. Any functionally-equivalent program that does not infringe any IBMintellectual property rights may be used instead of the IBM product, program,or service.

Information in this book was developed in conjunction with use of theequipment specified and is limited in application to those specific hardwareand software products and levels.

IBM may have patents or pending patent applications covering subject matterin this document. The furnishing of this document does not give you anylicense to these patents. You can send license inquiries, in writing, to the IBMDirector of Licensing, IBM Corporation, North Castle Drive, Armonk, NY10504-1785.

Licensees of this program who wish to have information about it for thepurpose of enabling: (i) the exchange of information betweenindependently-created programs and other programs (including this one) and(ii) the mutual use of the information that has been exchanged should contactIBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.

Such information may be available, subject to appropriate terms andconditions including, in some cases, payment of a fee.

The information contained in this document has not been submitted to anyformal IBM test and is distributed AS IS. The information about non-IBM(vendor) products in this manual has been supplied by the vendor, and IBMassumes no responsibility for its accuracy or completeness. The use of thisinformation or the implementation of any of these techniques is a customer


responsibility and depends on the customer's ability to evaluate and integratethem into the customer's operational environment. While each item may havebeen reviewed by IBM for accuracy in a specific situation, there is noguarantee that the same or similar results will be obtained elsewhere.Customers attempting to adapt these techniques to their own environmentsdo so at their own risk.

Any pointers in this publication to external Web sites are provided forconvenience only and do not in any manner serve as an endorsement ofthese Web sites.

Any performance data contained in this document was determined in acontrolled environment, and therefore, the results that may be obtained inother operating environments may vary significantly. Users of this documentshould verify the applicable data for their specific environment.

This document contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examplescontain the names of individuals, companies, brands, and products. All ofthese names are fictitious and any similarity to the names and addressesused by an actual business enterprise is entirely coincidental.

Reference to PTF numbers that have not been released through the normaldistribution process does not imply general availability. The purpose ofincluding these reference numbers is to alert IBM customers to specificinformation relative to the implementation of the PTF when it becomesavailable to each customer according to the normal IBM PTF distributionprocess.

The following terms are trademarks of the International Business MachinesCorporation in the United States and/or other countries:

The following terms are trademarks of other companies:

OpenEdition Operating System/2OS/2 OS/390Presentation Manager RACFRS/6000 S/390SecureWay SPSP1 System/36System/360 System/390TeamConnection TXSeriesVisualAge VTAMWebSphere 400


Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything.Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, PlanetTivoli, and Tivoli Enterprise are trademarks or registered trademarks of TivoliSystems Inc., an IBM company, in the United States, other countries, or both.In Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer - TivoliA/S.

C-bus is a trademark of Corollary, Inc. in the United States and/or othercountries.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States and/or othercountries.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States and/or other countries.

PC Direct is a trademark of Ziff Communications Company in the UnitedStates and/or other countries and is used by IBM Corporation under license.

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of IntelCorporation in the United States and/or other countries.

UNIX is a registered trademark in the United States and other countrieslicensed exclusively through The Open Group.

SET and the SET logo are trademarks owned by SET Secure ElectronicTransaction LLC.

Other company, product, and service names may be trademarks or servicemarks of others.

Special notices 319

Appendix E. Related publications

The publications listed in this section are considered particularly suitable for amore detailed discussion of the topics covered in this redbook.

E.1 IBM Redbooks publications

For information on ordering these ITSO publications see “How to get IBMRedbooks” on page 325.

• Programming with VisualAge for Java Version 2, SG24-5264

• Developing an e-Business Application for the WebSphere ApplicationServer, SG24-5423

• From Client/Server to Network Computing A Migration to Java, SG24-2247

E.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMsbutton at http://www.redbooks.ibm.com/ for information about all the CD-ROMsoffered, updates, and formats.

E.3 Other resources

These publications are also relevant as further information sources:

• IBM Systems Journal Vol 38, No 1 - Enterprise Solutions Structure,Technical Reference Architectures by P.T.L. Loyd and G.M. Galambos, Oct8 1998

CD-ROM Title Collection KitNumber

System/390 Redbooks Collection SK2T-2177Networking and Systems Management Redbooks Collection SK2T-6022Transaction Processing and Data Management Redbooks Collection SK2T-8038Lotus Redbooks Collection SK2T-8039

Tivoli Redbooks Collection SK2T-8044AS/400 Redbooks Collection SK2T-2849Netfinity Hardware and Software Redbooks Collection SK2T-8046RS/6000 Redbooks Collection (BkMgr Format) SK2T-8040RS/6000 Redbooks Collection (PDF Format) SK2T-8043Application Development Redbooks Collection SK2T-8037

IBM Enterprise Storage and Systems Management Solutions SK3T-3694


• Antipatterns: Refactoring Software, Architectures, and Projects in Crisis byW. J. Brown, R. C. Molveau, H. W. McCormick, and T. J. Mowbray, JohnWiley & Sons, Inc., New York (1998).

• Architecture and Planning for Modern Application Styles by R. Schulte,Gartner Group Strategic Analysis Report SSA: R-ARCH-104 (April 28,1997).

• Software Reuse: Architecture, Process and Organization for BusinessSuccess by I. Jacobson, M. Griss, and P. Jonsson, Addison-WesleyPublishing Co., Reading, MA (1997).

• Software Architecture in Practice, by L. Bass, P. Clements, and R.Kazman, , Addison-Wesley Publishing Co., Reading, MA (1998).

• Engineering Context, First International Workshop on Architecture forSoftware Systems, by B. Boehm, April 1995, Seattle, WA.

• Design Patterns: Elements of Reusable Object-Oriented Software, by E.Gamma, R. Helm, R. Johnson, and J. Vlissides, Addison-WesleyPublishing Co., Reading, MA (1995).

• Architecture of the San Francisco Frameworks, by K. A. Bohrer, IBMSystems Journal 37, No. 2, 156N169 (1998).

• Experiences in Reusing Technical Reference Architectures, by T. Harris, J.W. Rothwell, and P. T. L. Lloyd, IBM Systems Journal 38, No. 1, 98N117(1999, this issue). Accepted for publication October 9, 1998.

• Application Architectures with Enterprise Java Beans, ComponentStrategies, Chip Wilson, August 1999

• The J2EE Application Programming Model, Version 1, Sun Microsystems,September 1999

• The IBM Application Programming Model, Version 1, White Paper, by MikeConner

• Enterprise Java Beans By Example by Henri Jubin and Jurgen Friedrichset al

• Frontiers of Electronic Commerce by Ravi Kalakota, Andrew B. Whinston(Contributor), Tom Stone (Editor)

• E-Business : Roadmap for Success (Addison-Wesley InformationTechnology Series) by Ravi Kalakota, Marcia Robinson, Don Tapscott

E.4 Referenced Web sites

These Web sites are also relevant as further information sources:


• http://www.software.ibm.com/ad/cb.

• http://www.omg.org for link to UML specifications

• http://www-4.ibm.com/software/developer/services/java/ncs.html

• http://www.software.ibm.com/ebusiness/sysmodel.html

• http://www.ibm.com.security

• http://www.specbench.org

• http://www.dtmf.org

• http://www.ibm.com

• http://www.sun.com

• http://www.amazon.com

• http://www.cdnow.com

• http://www.etrade.com

• http://www.cisco.com

• http://www.ibm.com/ibm/easy/index.html

• http://www.useit.com

• http://www.asktog.com

• http://www.sqlj.org

• http://www.software.ibm.com/webservers/appserv

• http://www.lotus.com/home.nsf/tabs/domino

• http://www.software.ibm.com/data

• http://www.software.ibm.com/ts/txseries

• http://www.software.ibm.com/webservers

• http://www.tivoli.com

• http://www.cross-site.com

• http://www.ibm.com/security/html/prod_fire

• http://www.lotus.com

• http://www.software.ibm.com/ad

• http://www.software.ibm.com/webservers/studio

Related publications 323

How to get IBM Redbooks

This section explains how both customers and IBM employees can find out about IBM Redbooks,redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.

• Redbooks Web Site http://www.redbooks.ibm.com/

Search for, view, download, or order hardcopy/CD-ROM Redbooks from the Redbooks Web site.Also read redpieces and download additional materials (code samples or diskette/CD-ROM images)from this Redbooks site.

Redpieces are Redbooks in progress; not all Redbooks become redpieces and sometimes just a fewchapters will be published this way. The intent is to get the information out much quicker than theformal publishing process allows.

• E-mail Orders

Send orders by e-mail including information from the IBM Redbooks fax order form to:

• Telephone Orders

• Fax Orders

This information was current at the time of publication, but is continually subject to change. The latestinformation may be found at the Redbooks Web site.

In United StatesOutside North America

e-mail [email protected] information is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

United States (toll free)Canada (toll free)Outside North America

1-800-879-27551-800-IBM-4YOUCountry coordinator phone number is in the “How to Order”section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

United States (toll free)CanadaOutside North America

1-800-445-92691-403-267-4455Fax phone number is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

IBM employees may register for information on workshops, residencies, and Redbooks by accessingthe IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button.Look in the Materials repository for workshops, presentations, papers, and Web pages developedand written by the ITSO technical professionals; click the Additional Materials button. Employees mayaccess MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.

IBM Intranet for Employees


http://www.elink.ibmlink.ibm.com/pbl/pbl



http://w3.itso.ibm.com/

http://w3.ibm.com/

http://www.redbooks.ibm.com




mailto:[email protected]




IBM Redbooks fax order form

Please send me the following:

We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card notavailable in all countries. Signature mandatory for credit card payment.

Title Order Number Quantity

First name Last name

Company

Address

City Postal code

Telephone number Telefax number VAT number

Invoice to customer number

Country

Credit card number

Credit card expiration date SignatureCard issued to


Glossary

ACL. Access Control List.

AD/SI. IBM Application Development/SystemsIntegration Method Group within WSDDM.

API. Application Programming Interface.

APPC. Advanced Program-to-ProgramCommunication.

applet. A Java program designed to run within aWeb browser. Contrast with application.

application. In Java programming, aself-contained, stand-alone Java program thatincludes main() method. Contrast with applet.

ASCII. American Standard Code for InformationInterchange. The 8-bit character encodingscheme used by most PCs and UNIX systems. Itsupersedes an earlier 7-bit ASCII standard.

ASP. Microsoft’s Active Server Pages

AVM. Accelerated Value Method. This is a rapiddeployment method based on iterativeprototyping, used by Lotus Consulting.

Bamba. Bamba is a brandname for IBMtechnology used to develop network-enabledmultimedia applications. One function of thetechnology is streaming audio and video (bothlive and stored) across the Internet and overintranets via modem or LAN connections.

BB. Building Block. Many IBM design anddevelopment methods, including the onedescribed in this redbook, construct a designfrom building blocks that are generally defined inmore detail as the design evolves.

Bean. This is a small component that can beused to build applications. See JavaBean.

Browser. An Internet-based tool that lets usersbrowse Web sites.

Call Level Interface (CLI). This is a callableapplication program interface (API) for databaseaccess that is an alternative to an embeddedSQL application program interface. In contrastto embedded SQL, CLI does not requireprecompiling or binding by the user, but instead

© Copyright IBM Corp. 1999

provides a standard set of functions to processSQL statements and related services at runtime.

Customer Information Control System(CICS). This is a distributed online transactionprocessing system designed to support anetwork of many terminals. The CICS family ofproducts is available for a variety of platformsranging from a single workstation to the largestmainframe.

CICS Access Build. This is a VisualAge forJava Enterprise tool that generates beans toaccess CICS transactions through the CICSGateway for Java and CICS Client.

CICS Client. This is a server program thatprocesses CICS ECI calls, forwardingtransaction requests to a CICS program runningon a host.

CICS Gateway for Java. This is a serverprogram that processes Java ECI calls andforwards CICS ECI calls to the CICS Client.

Class. This is an aggregate that definesproperties, operations, and behavior for allinstances of that aggregate.

Client. As in client/server computing, this is theapplication that makes requests to the serverand, often, handles the necessary interactionwith the user.

Client/server. This is a form of distributedprocessing in which the task required to beprocessed is accomplished by a client portionthat requests services and a server portion thatfulfills those requests. The client and serverremain transparent to each other in terms oflocation and platform.

COBOL. Common Business OrientedLanguage.

Commit. The operation that ends a unit of workto make permanent the changes it has made toresources (transaction or data).

Common Gateway Interface (CGI). A standardprotocol through which a Web server can

327

execute programs running on the server machine.CGI programs are executed in response torequests from Web client browsers.

CGI. Common Gateway Interface.

CICS. Customer Information Control System.

COM. Microsoft’s Component Object Model.

Common Object Request Broker Architecture(CORBA). A middleware specification thatdefines a software bus – the Object RequestBroker (ORB) – that provides the infrastructure.

Communications area (COMMAREA). In aCICS transaction program, this is a group ofrecords that describes both the format andvolume of data used.

Conversational. A communication model wheretwo distributed applications exchange informationby way of a conversation; typically oneapplication starts (or allocates) the conversation,sends some data, and allows the otherapplication to send some data. Both applicationscontinue in turn until one decides to finish (ordeallocate). The conversational model is asynchronous form of communication.

CORBA. Common Object Request BrokerArchitecture.

Data Access Builder. A VisualAge for JavaEnterprise tool that generates beans to accessand manipulate the content ofJDBC/ODBC-compliant relational databases.

Database. (1) A collection of related data storedtogether with controlled redundancy according toa scheme to serve one or more applications. (2)All data files stored in the system. (3) A set ofdata stored together and managed by a databasemanagement system.

Database Management System (DBMS). Acomputer program that manages data byproviding the services of centralized control, dataindependence, and complex physical structuresfor efficient access, integrity, recovery,concurrency control, privacy, and security.

DB2 Call Level Interface (CLI). The DB2 calllevel interface is an alternative SQL interface forthe DB2 family of products and takes full

advantage of DB2 capability. This implementationclosely follows industry standards, such asX/OPEN, to enhance application portability.Currently, the DB2 Call Level Interface functionsare compatible with ODBC 2.0, and containDB2-specific APIs to help exploit DB2 capability.

DB2 for MVS/ESA. An IBM relational databasemanagement system for the MVS operatingsystem.

DCE. Distributed Computing Environment.Adopted by the computer industry as a de factostandard for distributed computing. DCE allowscomputers from a variety of vendors tocommunicate transparently and share resources,such as computing power, files, printers, andother objects in the network.

DB2. IBM Relational Database Family.

DCOM. Microsoft’s Distributed Object Model.

DECS. Domino Enterprise Connection Services.A standard component of Domino 4.6.3 andDomino 5 that provides connectivity from Dominoto back end relational data base servers. Thisconnectivity is table-driven and requires noprogramming.

DMZ. DeMilitarized Zone. This term is nowcommonly used in the industry to describe asubnetwork, typically used for Web servers, thatis protected by firewalls from both the externalinternet and a company’s internal network.

DNS. Domain Name Services.

Distributed Processing. Distributed processingis an application or systems model in whichfunction and data can be distributed acrossmultiple computing resources connected on aLAN or WAN. See client/server computing.

Distributed Program Link (DPL). This enablesan application program executing in one CICSsystem to link (pass control) to a program in adifferent CICS system. The linked-to programexecutes and returns a result to the linkingprogram. This process is equivalent to remoteprocedure calls (RPCs). You can writeapplications that issue RPCs that can be receivedby members of the CICS family.


Dynamic Link Library (DLL). This is a filecontaining executable code and data bound to aprogram at run time rather than at link time. TheC++ Access Builder generates beans and C++wrappers that let your Java programs access C++DLLs.

E2E. IBM End-to-End System Design Method.See ISD.

EBCDIC. Extended Binary Coded DataInterchange Code. EBCDIC is the 8-bit characterencoding scheme used by IBM and compatiblemainframes since the introduction of System/360in the mid 1960s.

ECI. External Call Interface is a way of interfacingwith CICS at a program-to-program level.

EJB. Enterprise JavaBean. An EJB is anon-visual, remote object designed to run on aserver and be invoked by clients. An EJB can bebuilt out of multiple non-visual JavaBeans. EJBsare intended to live on one machine and beinvoked remotely from another machine. They areplatform-independent. Once a bean is written, itcan be used on any client or server platform thatsupports Java.

e-business. This is a either (a) the transaction ofbusiness over an electronic medium, such as theInternet, or (b) a business that uses Internettechnologies and network computing in theirinternal business processes (via intranets), theirbusiness relationships (via extranets), and thebuying and selling of goods, services, andinformation (via electronic commerce).

External Call Interface (ECI). This is an API thatenables a non-CICS client application to call aCICS program as a subroutine. The clientapplication communicates with the server CICSprogram using a data area called a COMMAREA.

External Presentation Interface (EPI). An APIthat allows a non-CICS application program toappear to the CICS system as one or morestandard 3270 terminals. The non-CICSapplication can start CICS transactions and sendand receive standard 3270 data streams to thosetransactions.

Enterprise Access Builders (EAB). InVisualAge for Java Enterprise, this is a set ofcode-generation tools. See also CICS AccessBuilder and Data Access Builder.

EPI. External Presentation Interface is a way ofinterfacing with CICS at a program to 3270 level.

ERP. Enterprise Resource Planning.

EXCI. External CICS Interface allows programswithin MVS (including UNIX Services) tocommunicate with CICS programs.

Firewall. A computer (or programmable device)with associated software that can be used torestrict traffic passing through it according todefined rules. Controls would typically be appliedbased on the origin or destination address andthe TCP/IP port number.

FTP. File Transfer Protocol

File Transfer Protocol (FTP). This is the basicInternet function that enables files to betransferred between computers. You can use it todownload files from a remote host computer aswell as to upload files from your computer to aremote host computer. See Anonymous FTP.

Gateway. This is a host computer that connectsnetworks that communicate in differentlanguages. For example, a gateway connects acompany’s LAN to the Internet.

Graphical User Interface (GUI). This is a type ofinterface that enables users to communicate witha program by manipulating graphical featuresrather than entering commands. Typically, agraphical user interface includes a combination ofgraphics, pointing devices, menu bars and othermenus, overlapping windows, and icons.

HotJava. This is a Java-enabled Web andintranet browser developed by SunMicrosystems, Inc. HotJava is written in Java.

Hypertext Markup Language (HTML). This isthe basic language that is used to build hypertextdocuments on the World Wide Web. It is used inbasic plain ASCII-text documents, but, whenthose documents are interpreted (calledrendering) by a Web browser, such as Netscape,the document can display formatted text, color, a

Glossary 329

variety of fonts, graphic images, special effects,hypertext jumps to other Internet locations, andinformation forms.

HTTP. HyperText Transport Protocol

Hypertext Transfer Protocol (HTTP). Theprotocol for moving hypertext files across theInternet. Requires an HTTP client program onone end, and an HTTP server program on theother end. HTTP is the most important protocolused in the World Wide Web (WWW). See alsoClient, Server, WWW.

HTTP request. A transaction initiated by a Webbrowser and adhering to HTTP. The serverusually responds with HTML data, but can sendother kinds of objects as well.

Hypertext. Text in a document that contains ahidden link to other text. You can click a mouseon a hypertext word and it will take you to the textdesignated in the link. Hypertext is used inWindows help programs and CD encyclopediasto jump to related references elsewhere withinthe same document. The wonderful thing abouthypertext, however, is its ability to link—usingHTTP over the Web—to any Web document inthe world, yet still require only a single mouseclick to jump clear around the world.

IBM. International Business Machines

IEC. The IBM International Education Centre inLa Hulpe, Belgium.

IE. Microsoft’s Internet Explorer.

IGS. IBM Global Services.

IIOP. Internet Inter-ORB Protocol

Internet Inter-ORB Protocol (IIOP). An industrystandard protocol that defines how GeneralInter-ORB Protocol (GIOP) messages areexchanged over a TCP/IP network. The IIOPmakes it possible to use the Internet itself as abackbone ORB through which other ORBs canbridge.

Integrated Development Environment (IDE). Asoftware program comprising an editor, acompiler, and a debugger. IBM's VisualAge forJava is an example of an IDE.

Interface. A set of methods that can be accessedby any class in the class hierarchy. The Interfacepage in the Workbench lists all interfaces in theworkspace.

Internet. The vast collection of interconnectednetworks that all use the TCP/IP protocols andthat evolved from the ARPANET of the late 1960’sand early 1970’s.

Intranet. A private network inside a company ororganization that uses the same kinds of softwarethat you would find on the public Internet, but thatis only for internal use. As the Internet hasbecome more popular, many of the tools used onthe Internet are being used in private networks.For example, many companies have Web serversthat are available only to employees.

IMAP4. Internet Message Access Protocol -Version 4.

IMS. Information Management System.

IP. Internet Protocol.

IPSec. IP Security Protocol. Providescryptographic security services at the networklayer.

ISAPI. Internet Server API.

ISC. The Installation Support Centre. Based inHursley in the UK the EMEA ISC provides earlyeducation and support for new technologies.

ISD. InfraStructure Design. IBM ISD is a path ofthe AD/SI method component of WSDDM. ISD isused to design the delivery platform supportingan application. ISD phases are Requirements,Architecture, Infrastructure Specification, andComponent Specification and Selection. ISD isbased on the original E2E method that provided aformal way of designing complex systems.

ISD. The Integrated Service OfferingDevelopment process of IBM Global Services.

ISP. Internet Server Provider.

I/T. Information Technology.

ITSO. International Technical SupportOrganization


Java. Java is a new programming languageinvented by Sun Microsystems that is specificallydesigned for writing programs that can be safelydownloaded to your computer through theInternet and immediately run without fear ofviruses or other harm to your computer or files.Using small Java programs called applets, Webpages can include functions, such as animations,calculators, and other fancy tricks. We can expectto see a huge variety of features added to theWeb using Java, since you can write a Javaprogram to do almost anything a regularcomputer program can do, and then include thatJava program in a Web page.

Java archive (JAR). A platform-independent fileformat that groups many files into one. JAR filesare used for compression, reduced downloadtime, and security. Because the JAR format iswritten in Java, JAR files are fully extensible.

JavaBeans. In JDK 1.1, the specification thatdefines the platform-neutral component modelused to represent parts. Instances of JavaBeans(often called beans) may have methods,properties, and events.

Java Database Connectivity (JDBC). In JDK1.1, the specification that defines an API thatenables programs to access databases thatcomply with this standard.

Java Development Kit (JDK). The JavaDevelopment Kit 1.1 is the latest set of Javatechnologies made available to licenseddevelopers by Sun Microsystems. Each releaseof the JDK contains the following: the JavaCompiler, Java Virtual Machine, Java ClassLibraries, Java Applet Viewer, Java Debugger,and other tools.

Java Foundation Classes (JFC). Developed byNetscape, Sun, and IBM, JFCs are buildingblocks that are helpful in developing interfaces toJava applications. They allow Java applications tointeract more completely with the existingoperating systems.

JavaBean. A JavaBean is a component that canbe integrated into an application with other beansthat were developed separately. This singleapplication can be used stand-alone, within a

browser, and as an ActiveX component.JavaBeans are intended to be local to a singleprocess, and they are often visible at runtime.This visual component may be, for example, abutton, list box, graphic, or chart.

JDBC. This is a trademark, often referred to asJava DataBase Connectivity.

JDK. Java Developer’s Kit.

JFC. Java Foundation Class.

JIT. Just In Time.

JVM. Java Virtual Machine.

Local Area Network (LAN). This is a computernetwork located at a user’s establishment within alimited geographical area. A LAN typicallyconsists of one or more server machinesproviding services to a number of clientworkstations.

LDAP. Lightweight Directory Access Protocol.

LEI. Lotus Enterprise Integration. This is theproduct formerly known as NotesPump.

LSX. Lotus Script Extensions.

LU type 6.2 (LU 6.2). A type of logical unit usedfor CICS intersystem communication (ISC). LU6.2 architecture supports CICShost-to-system-level products and CICShost-to-device-level products. APPC is theprotocol boundary of the LU 6.2 architecture.

Logical unit of work (LUW). An update thatdurably transforms a resource from oneconsistent state to another consistent state. Asequence of processing actions (for example,database changes) that must be completedbefore any of the individual actions can beregarded as committed. When changes arecommitted (by successful completion of the LUWand recording of the synch point on the systemlog), they do not need to be backed out after asubsequent error within the task or region. Theend of an LUW is marked in a transaction by asynch point that is issued by either the userprogram or the CICS server, at the end of task. Ifthere are no user synch points, the entire task isan LUW.

Glossary 331

Messaging. A communication model wherebythe distributed applications communicate bysending messages to each other. A message istypically a short packet of information that doesnot necessarily require a reply. Messagingimplements asynchronous communications.

Method. A fragment of Java code within a classthat can be invoked and passed a set ofparameters to perform a specific task.

Multipurpose Internet Mail Extension (MIME).The Internet standard for mail that supports text,images, audio, and video.

MIB. Management Information Base.

MIME. Multipurpose Internet Mail Extensions.

MOM. Message-Oriented Middleware.

MQ. Message Queue.

MVS. Multiple Virtual Storage. For many yearsthe flagship operating system for IBM largeEnterprise Servers. In its latest releases, it isformally known as OS/390, although the termMVS is still used unofficially.

NC. Network Computer or Network Computing.

NCF. Network Computing Framework.

NNTP. Network News Transfer Protocol.

NSAPI. Netscape Server API.

NSF. Notes database file extension.

NT. Windows NT (New Technology).

Online Transaction Processing (OLTP). A styleof computing that supports interactiveapplications in which requests submitted byterminal users are processed as soon as they arereceived. Results are returned to the requester ina relatively short period of time. An onlinetransaction-processing system supervises thesharing of resources to allow efficient processingof multiple transactions at the same time.

Object. (1) A computer representation ofsomething that a user can work with to perform atask. An object can appear as text or an icon. (2)A collection of data and methods that operate onthat data, which together represent a logicalentity in the system. In object-oriented

programming, objects are grouped into classesthat share common data definitions and methods.Each object in the class is said to be an instanceof the class. (3) An instance of an object classconsisting of attributes, a data structure, andoperational methods. It can represent a person,place, thing, event, or concept. Each instance hasthe same properties, attributes, and methods asother instances of the object class, although ithas unique values assigned to its attributes.

ODBC Driver. An ODBC driver is a dynamicallylinked library (DLL) that implements ODBCfunction calls and interacts with a data source.

ODBC Driver Manager. The ODBC drivermanager, provided by Microsoft, is a DLL with animport library. The primary purpose of the DriverManager is to load ODBC drivers. The DriverManager also provides entry points to ODBCfunctions for each driver and parameter validationand sequence validation for ODBC calls.

Open Database Connectivity (ODBC). AMicrosoft-developed C database applicationprogramming interface (API) that allows accessto database management systems callingcallable SQL, which does not require the use of aSQL preprocessor. In addition, ODBC providesan architecture that allows users to add modulescalled database drivers that link the application totheir choice of database management systems atrun time. This means applications no longer needto be directly linked to the modules of all thedatabase management systems that aresupported.

Object Request Broker (ORB). A CORBA termdesignating the means by which objectstransparently make requests and receiveresponses from other objects, whether they arelocal or remote.

OS/390. The latest version of MVS. OS/390’sstandard OpenEdition function provides certifiedPOSIX compliant interfaces in addition toenhanced support for its traditional programminginterfaces.

ODBC. Open DataBase Connectivity

OMG. Object Management Group.


PERL. Practical Extraction and ReportingLanguage.

PGP. Pretty Good Privacy

PKI. Public Key Infrastructure.

POP3. Post Office Protocol 3

Port. A TCP/IP terminology; a port is aseparately-addressable point to which anapplication can connect. For example, by default,HTTP uses port 80 and Secure HTTP (HTTPS)uses port 443.

Protocol. (1) The set of all messages to which anobject will respond. (2) Specification of thestructure and meaning (the semantics) ofmessages that are exchanged between a clientand a server. (3) Computer rules that provideuniform specifications so that computer hardwareand operating systems can communicate. It’ssimilar to the way that mail in countries aroundthe world is addressed in the same basic formatso that postal workers know where to find therecipient’s address, the sender’s return address,and the postage stamp. Regardless of theunderlying language, the basic protocols remainthe same.

Proxy. This is an application gateway from onenetwork to another for a specific networkapplication, such as Telnet of FTP, for example,where a firewall’s proxy Telnet server performsauthentication of the user and then allows thetraffic to flow through the proxy as if it were notthere. Function is performed in the firewall andnot in the client workstation causing more load inthe firewall. Compare with socks.

RACF. Resource Access Control Facility.

RDMS. Relational Database ManagementSystem.

RFC. Request For Comment. Internet Standardsare defined in documents known as RFCs.

Remote Method Invocation (RMI). In JDK 1.1,the API that allows you to write distributed Javaprograms allowing methods of remote Javaobjects to be accessed from other Java virtualmachines.

Remote Procedure Call (RPC). Acommunication model where requests are madeby function calls to distributed procedureelsewhere. The location of the procedures istransparent to the calling application.

RSA. Rivest-Shamir-Adleman algorithm.

Sandbox. A restricted environment provided bythe Web browser in which Java applets run. Thesandbox offers them services and prevents themfrom doing anything naughty, such as doing fileI/O or talking to strangers (servers other than theone from which the applet was loaded). Theanalogy of applets to children led to calling theenvironment in which they run the sandbox.

SAP. Originally “Systemanalyse undProgrammentwicklung” and now named Systems,Applications, and Products in Data Processing,SAP supplies widely-used software for integratedbusiness solutions.

Schema. In the Data Access Builder, therepresentation of the database that will bemapped. In the Data Access Builder, the mappingcontains a set of definitions for all attributesmatching all the columns for your database table,view, or SQL statement, as well as informationrequired to generate Java classes.

Server. A computer that provides services tomultiple users or workstations in a network; forexample, a file server, a print server, or a mailserver.

SES/workbench. A simulation product forbehavioral and performance modeling of complexclient/server, network, software, and hardwaresystems.

SET. Secure Electronic Transaction.

SHTTP. Secure Hypertext Transfer Protocol.

SI. Systems Integration. One of the sixcompetency areas of IBM Global Services.

SI/AD. Systems Integration/ApplicationDevelopment. One of the six competency areasannounced by IBM Global Services in May 1998,later renamed simply SI.

SMTP. Simple Mail Transport Protocol

Glossary 333

SNMP. Simple Network Management Protocol

Socket Secure (SOCKS). The gateway thatallows compliant client code (client code madesocket secure) to establish a session with aremote host.

SQL. Structured Query Language.

SSL. Secure Sockets Layer.

S/MIME. Secure MIME.

Telnet. U.S. Dept. of Defense virtual terminalprotocol.

TME. Tivoli Management Environment.

Transmission Control Protocol/InternetProtocol (TCP/IP). This is the basicprogramming foundation that carries computermessages around the globe via the Internet. It isthe suite of protocols that defines the Internet.Originally designed for the UNIX operatingsystem, TCP/IP software is now available forevery major kind of computer operating system.To be truly on the Internet, your computer musthave TCP/IP software.

Thin client. Thin client usually refers to a systemthat runs on a resource-constrained machine orthat runs a small operating system. Thin clientsdo not require local system administration, andthey execute Java applications delivered over thenetwork.

Transaction. This is a unit of processingconsisting of one or more application programsinitiated by a single request. A transaction canrequire the initiation of one or more tasks for itsexecution.

Transaction Processing. This is a style ofcomputing that supports interactive applicationsin which requests submitted by users areprocessed as soon as they are received. Resultsare returned to the requester in a relatively shortperiod of time. A transaction processing systemsupervises the sharing of resources forprocessing multiple transactions at the sametime.

UDB. Universal Data Base. The latest release ofIBM DB2.

Uniform Resource Locator (URL). This is thestandard to identify resources on the World WideWeb.

VA. Visual Age.

VAJ. Visual Age for Java.

VB. Visual Basic.

Virtual Machine (VM). A software program thatexecutes other computer programs. It allows aphysical machine, a computer, to behave as if itwere another physical machine.

VM. Virtual Machine.

VPN. Virtual Private network.

VTAM. Virtual Telecommunications AccessMethod.

Web server. This is the server component of theWorld Wide Web. It is responsible for servicingrequests for information from Web browsers. Theinformation can be a file retrieved from theserver's local disk or generated by a programcalled by the server to perform a specificapplication function.

Widget. In this context, it is a generic term forsomething that can be put on a window, such as abutton, scrollbar, label, listbox, menu, orcheckbox.

Workstation. This is a configuration ofinput/output equipment at which an operatorworks. A terminal or microcomputer, usually onethat is connected to a mainframe or a network, atwhich a user can perform applications.

World Wide Web (WWW or Web). A graphichypertextual multimedia Internet service.

WSDDM. IBM WorldWide Solution Design andDelivery Methods. WSDDM is a collection ofgeneric plans and methods representing IBMbest practices for planning, managing, anddelivering projects.

WYSIWYG. What You See is What You Get.

XML. Extensible Markup Language.


List of Abbreviations

API Application ProgramInterface

ARM Application RequestManager

ASCII American NationalStandard Code forInformationInterchange

AWT Abstract WindowingToolkit

CA Certification Authority

CAB Cabinet (Microsoft)

CAE Client ApplicationEnabler

CGI Common GatewayInterface

CICS Customer InformationControl System

CICS TS CICS TransactionServer for OS/390

CLI Call Level Interface

COMMAREA Communication Area(CICS)

CORBA Common ObjectRequest BrokerArchitecture

DBMS Database ManagementSystem

DB2 Database 2

DCE Distributed ComputingEnvironment

DDCS/2 Distributed DatabaseConnection Servives/2

DLL Dynamic Link Library

DPL Distributed ProgramLink (CICS)

DRDA Distributed RelationalDatabase Architecture


EBCDIC Extended Binary CodedDecimal InterchangeCode

ECI External Call Interface(CICS)

EPI External PresentationInterface (CICS)

ESA Enterprise SystemsArchitecture

EXCI External CICS Interface

FTP File Transfer Protocol

GUI Graphical UserInterface

HTML Hypertext MarkupLanguage

HTTP Hypertext TransferProtocol

IBM International BusinessMachines Corporation

IDE IntegratedDevelopmentEnvironment

IIOP Internet Inter-ORBProtocol

IMS InformationManagement System

IS Information System

ITSO International TechnicalSupport Organization

JAR Java Archive

JDBC Java DatabaseConnectivity

JDK Java Development Kit

JFC Java FoundationClasses

JVM Java Virtual Machine

LAN Local Area Network

335

LDAP Lightweight DirectoryAccess Protocol

LUW Logical Unit of Work

MIME Multipurpose InternetMail Extensions

MVS Multiple Virtual Storage

NC Network Computer

NCF Network ComputingFramework

NetBIOS Network BasicInput/Output System

NNTP NetNews TransferProtocol

NT Microsoft Windows NT(New Technology)

ODBC Open DatabaseConnectivity

OLTP Online TransactionProcessing

ORB Object Request Broker

OS/2 Operating System/2

OSF Open SoftwareFoundation

PC Personal Computer

POP Post Office Protocol

RACF Resource AccessControl Facility

RAD Rapid ApplicationDevelopment

RMI Remote MethodInvocation

SDK Software Developer'sKit

SET Secure ElectronicTransaction

SHTTP Secure HypertextTransport Protocol

SIT System InitializationTable

SMTP Simple Mail TransferProtocol

SNA Systems NetworkArchitecture

SNMP Simple NetworkManagement Protocol

SQL Structured QueryLanguage

SSL Secure Sockets Layer

TCP/IP Transmission ControlProtocol/InternetProtocol

TSO Time Sharing Option

URL Uniform ResourceLocator

XA Extended Architecture


Index

Numerics3270 273Com 1315250 27

AAbsolute performance 290abstract windowing toolkit, See AWTabstraction 17access 51, 79

real-time 62access control 77Access protocol 136accomplishments 175accountability 80action control overload 194ActiveX 64, 131adoption 6Advanced search 185AFS 27agendas 45agreement 58, 122AIX, 264alternatives 59

architectural 116AMI-J 27AMS 28Animation 96Apache 132, 201API 26, 206Appletalk 88application

request manager, See ARMapplication architecture 159application content 189application leverage points 34application life-span 289application logic 311application model 18, 178application programming model 23Application reuse 191Application Server 22, 24, 203

architectural view 204design patterns 208dynamic HTML 206


Extend 204from Webserver 203static model 203transactive model 203UI design considerations 204

Application server 204Application services 133application structure 189application topology 23, 25application types 179application-specific 125architects 16architectural alternatives 45, 116, 313architectural diagram 25architectural elements 306architectural model 1architecture 16, 17, 21, 47

abstraction 17benefits 17communication 17design decisions 17elements 22selection 17stakeholders 17

artists 192ASP 97, 202asset-based 15, 17

engineering 15asynchronous messaging 101attribute 189auditability 77authorize 5Availability 33, 51average 20

Bbandwidth 61Basic authentication 79BEA 135big-endian 253Blue pages

advanced search 185fuzzy search 186simple search 185

Blue pages(java)attributes 189filter terms 188

337

frames 188real estate 188search modes 188

boolean 253bottlenecks 289Browser 21, 129browser choice 178Browser differences 179, 196Browser-based 180browser-based interface 178browser-neutral 129budget 293building block 125

application 103application logic 94, 311client 83, 309connectors 100, 312enterprise data 103, 313network 87, 309security 77, 307server 89, 310systems management 81, 308tools 311

building blocks 25, 26, 306business data 52business drivers 54, 55Business Flow 74business intelligence 34, 296business logic 21, 23, 24, 198, 205business models 3business processes 3, 21business requirements 49, 161business scenario 46, 73, 183business sense 3business survival 4business value 5Business-to-business 42, 204Business-to-consumer 43, 204business-transformation 1buying 3buying patterns 34byte 252

CC/C++ 202Cache 292cache 133

support 224

CAP 27capacity 83capacity plans 83Cascading Style Sheet 196CDSA 27certificates 79CGI 90, 97change 1char 253characteristics

e-business 5Characters 252check 65Checkpoint 65CICS 104, 295client 22, 126, 128, 177client control 64client devices 18, 211

multiple 211XML 212XSL 212

client environment 64client technology 128client/server 3, 18, 197

Applications 39architectures 35characteristics 19Data 39Distributed function 35Infrastructure 39model 19Remote data 35Remote presentation 35Systems Management 40topologies 35topology diagram 41

clustering 89, 133CMI-J 27coax 53code distribution 84, 309Collaboration 27collaboration 51, 55, 86, 296COM 128, 202command 171Command button 195command pattern 228Commerce 27commit 104commitment 122


common gateway interface, See CGIcommon user access 187communication 5, 17communication area, See COMMAREAcommunities 5Community 27competition 5, 184Component Broker 296Component Model 27component models

servercomponent models 233

conceptual 1conduct workshop 64conferencing 90, 310Confidentiality 80Configuration-dependent 19conflict 7connection pooling 133, 251Connectors

decision points 246connectors 137, 242, 312

connection pooling 251data types 252definition 245design documentation 248endian handling 253Finder Application 247Implementation details 256issues 246

e-business connectorsissues 248

object serialization 252original source code 249proprietary extensions 251SLQ dynamic and static 251SQL 251strategic approach 248tactical approach 247tactical solution 268transactionality 250

consensus 58containers 234Content 11, 178, 189

Authoring 99management 100

content management 98, 133, 296control 295control flow

JSP 214Servlet 214

control flow mechanism 214Controller 209

design considerations 212Controller approach 225controls 195Cookies 77, 80cookies 93CORBA 27, 128, 202costs 55CRM 18cryptography 77CSS1 179CSS2 179CUA 187customer communities 5Customer Relationship Management 32customer service 55

Ddata flow 292Data usage 63data visualization 96Data, Object and Application Placement 87Database 27, 54database 11, 296Database Manager 250date delivery 118DB2 Universal Database 296decision makers 54decisions 54, 166DECNET 88defining roles 222deliverable date 118Delphi 202Demilitarized Zone 78demographics 34deployment 19design 16, 17design approach

comparison 231design approaches 224

controller approach 225facade approach 224

design considerationsbusiness logic 232

design decisions 17

Index 339

design document 248design pattern

definition 208design patterns 208, 212, 213, 214, 224

applying MVC 210command 228comparison 231Controller 209controller approach 225Domain Abstraction 221domain abstraction 221facade 224facade approach 224Model 209Model-View-Controller 209MVC 210View 209

design problems 19Design time components 201Desktop 180desktop computer 180developers 192development 19development environment 199development process 192Development tools 127development tools 218, 297DFS 27dialogs 195digital 3digital certificates 51, 79digital medium 3digital signatures 77Direct support 20Directory 27, 136directory inquiry 157Directory services 136disparate initiatives 7dispatcher 204, 221Distributed function 38distributed technology 222

separation 222DMTF-CIM 28DMZ 78DNS 61documentation 59

application 59databases 59existing environment 59

network 59operational parameters 60organization charts 60security 60standards 60

DOM 131domain 4Domain Abstraction 171, 221

design considerations 221domain experts 191Domino Designer R5 297double 253down 52downloadable components 179downtime 52, 82DRDA 27dynamic content 52dynamic HTML 203dynamic length 195Dynamic SQL 251

Ee-business 3

adoption 6adoption phases 6application characteristics 19assessment 53browser differences 196business drivers 54business transformation 4business value 4business-to-business 10business-to-consumer 9categories 8characteristics 5cycle 31definition 3development environment 199domain 4e-commerce 3evolution 6examples 4Intra-company 11journey 6model 19models 4phases 6readiness 53


solutions 26transformation 31vision 7

e-business client 177application model 178browser based 178browser differences 179business logic 198business scenario 183client side processing 197competitive interfaces 184content 189decisions 195development tools 191Finder application interface 181GUI comparison 194GUI features 194interface design 180interfaces 184large results set 198low-fidelity prototype 192menus 194migration issues 194multi-window 194navigation 191Network Computers 180organization 191other issues 199PC 180performance 179pervasive devices 180presentation logic 198query construction 197structure 189suggestions 199tasks 183technology 191toolbars 194users 183

e-business client window usage 194e-business connectors 245

access to 245connection pooling 251data types 252decision points 246design documentation 248endian handling 253Implementation details 256interoperability 245

issues 246object serialization 252original source code 249performance 245proprietary extensions 251registry access 245reliability 245scalability 245security 245SQL 251SQL dynamic and static 251strategic approach 248tactical approach 247tactical solution 268transactionality 250

e-business cyclebuild 33leverage 34run 33transform 32

ECMA 262 202ECMAScript 27, 95e-commerce 3, 32, 52

requirements 51EDI 27education 58, 121EJB 27electronic business 4Electronic Commerce 32electronic mail 51, 131electronic organizer 131e-mail 51, 131employees 3, 11empower 5ENCINA 104encryption 77end-to-end

response time budget 114end-users 191eNetwork Firewall 296enterprise 43enterprise beans 235

entity beans 235session beans 235

enterprise data 313Enterprise Java Beans 234enterprise servers 20Entity beans 235Events 28

Index 341

evolution 5platforms 223technologies 223

executive 55executive sponsor 55, 56experience 34Explicit knowledge 34external call interface, See ECIexternal CICS interface, See EXCIexternal presentation interface, See EPIexternal services 19, 25Extranets 3

FFacade 224Facade approach 224fact-based strategies 34fail-over 133failure 82

handling 82single points of 82unscheduled 82

File 27filter terms 188filtering 128filtering technologies 128Finder

access to data 247accomplishments 175application architecture 159business requirements 161decisions 166directory inquiry 157incremental approach 163leverage points 164migration approaches 163migration phase 2 237migration phase 3 238migration strategy 163prototype 192rationale 162skillsets 173strategic solution 166tactical solution 166technical architecture 160user interface 181wrapping 171

firewall 64, 77, 80

float 253frames 188, 195framework 15, 17, 20, 21, 125, 126, 128

application 17benefits 18concepts 21definition 17nature 128programming model 23

front-end 23FTP 27functional 66Functional requirements 66fuzzy 210Fuzzy search 186

GGET 207grade 113, 116, 118, 121Graphic design 99graphical user interface, See GUIgraphics designers 192GUI 180

Hhackers 24Handcrafting 15high-level architectures 46Homogeneous 19Host Access 27HTML 24, 27, 130, 131, 206

decisions 196dynamic 203, 206frames 195Intrinsic controls 195presentation limitations 195static 203

HTML 4 179HTTP 24, 27, 64, 131, 203HTTPS 131Hypertext 207HyperText Transfer Protocol

See HTTP

IIBM Application Framework for e-business 15, 17,18, 19, 20, 21, 125, 126, 128, 245


definition 20IBM Network Station 130IBM WorkSpace On-Demand 19IDC 4IDE 222IFRAME 195IIOP 27, 84, 131IMAP4 26IMAP4, 131imperative 4IMS 295Incremental approach 163indexing 90, 310influences 127information 3, 83infrastructure 63, 127infrastructure services 24initial understanding 65initiative 4Inprise 135input validation 24insight. 34int 252integration 52, 127integration requirements 61, 300Integration services 137integrity 80intellectual capital 105Interaction controller 214, 220interaction controller 221interface 187Internet 3, 20, 24Internet Explorer 131Internet Information Server 134Internet services 132Internet-enabled 179interoperability 245Intra-company 43intranet 3, 24, 289Intrinsic controls 195intuition 34inventory 55Iona 137IOTP 27iPlanet 134, 135IPP 27IPSec 27IRC 27ISAPI 97, 132

Issues 248iterative development 192iterative process 44

JJava 53, 64

Applets 96Java applet 21Java archive, See JARJava Beans 222Java Database Connectivity , See JDBCJava development kit , See JDKJava Server Pages 206

understanding 208Java servlets 202, 206Java station 130Java virtual machine , See JVMJavaBeans 27JavaScript 64, 95, 96, 197JCE 27JDBC 27, 137, 250, 275

Interoperability 286SQL comparison 281

JDBC drivers 264types 277

JDBC/ODBC 102JDK 27JMS 27JNDI 27JScrip 202JScript 95JSP 27, 97, 206

API stability 219control flow mechanisms 214development tools 218java 211Java Beans 211Servlet comparison 210understanding 208

JSSL 27JTA 27JTS 27

Kknowledge 3

Index 343

LLanguage 84, 233Laptop 180large result sets 198LDAP 27, 136legacy 4, 5, 16legacy applications 252legacy systems 246Leverage points 34, 40, 164list 112little-endian 253load balancing 89, 133logic 21, 226Logic controller 226

controller 226logical steps 59long 252long-term objectives 59Lotus Domino 296low-cost 130low-fidelity prototype 192LPD 27LPR 27

MMail 92Mail client 86Mainframe 63Maintaining state 54manageability 33, 295management 296markup-based 179matrix 112meeting facilitator 58Menu 194menubars 194messaging 26, 101, 102, 296method of payment 52methodology 43, 315metrics 289Microsoft 128, 131, 132

COM 128Internet Information Server 134ISAPI 132

Microsoft Active Server Pages 202Microsoft ISAPI 202Migration 237, 238migration approaches 163

migration phases 236migration strategy 163MIME 131MIMS 134mission-critical 25Mobile 136Mobile phones 129, 131modal dialogs 195Model 209

design considerations 213modeless 181models 4MQSeries 27, 296Multimedia 92multi-threaded 133multi-tier 20multi-window 194, 195MVC pattern 220

Nname value pairs 197Naming services 136national language support 63Native interfaces 102navigation 191Navigator 131Net.Commerce 296NetBIOS 158Netscape 131, 132

iPlanet 134NSAPI 132

network 27, 87, 309network baseline 61Network Computers 180network infrastructure 22, 61, 127, 300network layer 43Network Station 130network topology 61network traffic

minimizing 223News 92NLS 63, 84NNTP 27Nokia 131non-distributed technology 222

separation 222Non-standard GUI 194NSAPI 97, 132


Numbers 252

OOBI 27object model 189object modeling notation 189Object placement 61object request broker, See ORBobject serialization 252Object technology 53object-oriented 16, 17obstacles 49, 66ODBC 27, 137old order 5Olympics 289OMG 128on-demand 126online transaction processing , See OLTPOO 16open standards 33operating costs 55operating platforms 296Operational hours 51operational plan 82optimization 19Oracle 49Orbix 137Organization charts 60OTS 27out of action 52overload 194

PPage creation 99Palm Pilot 131parameters 43passwords 101patterns 202, 209, 212, 213, 214, 224

applying MVC 210comparison 231Controller 209controller approach 225Domain Abstraction 221domain abstraction 171facade approach 224Model 209Model-View-Controller 209MVC 210

View 209payment methods 52PC 180PDA 129, 131peak 20perfect 122performance 53, 83, 118, 133, 179, 245, 289, 295

absolute 290bottlenecks 289budget 293Cache 292competitive 290distributed environment 223end-to-end 290general guidelines 291metrics 289other factors 290when 289

performance metric 291persistence 129, 137personal computer 180Personal Digital Assistant 131personnel 3pervasive 96, 129

e-business client 180Pervasive Computing 27Pervasive devices 129, 180PKI 136plan 4platform agnostic 113, 114platform independence 18, 113, 114, 120Platform selection 93platform-agnostic 292plug-and-play 21Plug-ins 95political 45POP3 26population 20portability 18, 295POST 207post-sale 52pre-sale 52presentation limitations 195presentation logic 198Primitive types 252Print 27privacy 78problem reporting 82processes 3

Index 345

processor 53product portfolio 295productivity 19programmers 192programming languages 17Programming skills 63progression 5Proprietary 88proprietary 129proprietary interfaces 292protocols 87, 127prototypes 192Public Key Infrastructure 136publications 11purchase 3

Qquality 19Query construction 197, 198

RRAD tools 198rank 113, 116, 118, 121rapid application development, See RADrationale 162RDBMS 104real 25real estate 188real-time 6real-time access 62real-world 25reconsider 4recovery plan 82redesigning 4redo 42redundancy 89refinement 122registry 245relational database 49reliability 133, 245Remote Data 35Remote presentation 37Requirements 45requirements 49

collaboration 51e-commerce 51electronic mail 51e-mail 51

hypothetical 113integration 61list 113matrix 113priority 49questions 49Web application server 52

response timeend-to-end 114

response time targets 82rethinking 4reuse 19, 191revenue 55review 58rewrite 42risk 16, 54RMI 27roles 222

separation 222rollback 104RosettaNet 27routers 80Run Time Components 201

SS/390 63safe 33SAP 296Scalability 33scalability 53, 102, 114, 120, 133, 245

distributed environment 223scalable 33scenario 73SCM 18scope 43score 113, 116, 118, 121screen design 83scripting 27, 95Scripting Object Model 201SDK 202search modes 188searching 90, 310secondary window 194secure electronic transaction, See SETSecure Socket Layer 77SecureWay Software 136, 296Security 27, 33

Policies 101


security 20, 24, 51, 54, 61, 77, 87, 91, 137, 185,245, 307Select components 47selecting technologies 125selling 3server 126, 128, 310Server Socket 258server-centric 128servers 20

containers 234service 55service hours 103Services

Application 132Application Development 132Integration 132Internet 132Management 132

ServletAPI stability 219control flow mechanisms 214JSP comparison 210

Servlets 27Session and State Management 93Session beans 235session management 53SET 27, 52, 77short 252short-term objectives 59silos 16Simple search 185Site navigation 100skills 63

separations 222skills transfer 121skillsets 173SMTP 26SNA 53, 88SNMP 28socket 257

description 257reading 259writing 259

solution providers 26solution workshop 55, 56, 300

description 56documentation 59duration 56goals 56, 58

integration requirements 61network infrastructure information 61participants 57preparation 57rationale 56skills required 58target client environment 64

sophisticated grid 195sound 296source code 249specialized devices 129SQL 251

proprietary extensions 251SQL92 276SQLDA 262SQLJ 27, 275, 281

Interoperability 286JDBC comparison 281

SSI 97SSL 27, 77SSL3 79stakeholders 17standard APIs 26standard interfaces 127standard protocols 26standards 26, 54state information 54State Management

Applet 94Cookies 93Hidden fields 93

state management 133static HTML 203static pages 53Static SQL 251statistics 83stock 55Strategic solution 166strategy 34strengths 184structure 189sub-architecture 35Submit 207subnetworks 88Sun 128Sun EJB 128, 135supply chain 177Supply Chain Management 32support 52

Index 347

survival 4symbolic 4symbolic initiative 4synchronous messaging 101system management 84system utilities 292systems management 81, 127, 308

TTabbed notebook 195Tacit knowledge 34Tactical solution 166target client environment 64tasks 183TeamConnection 298teaming 51TEC 28technical architecture 160technical failure 16technological solutions 54technologies

platforms 223technology influences 127technology selection 125text-only 83thin client 20, 86, 128, 200threads 133three-tier 21three-tier applications 198tier 21, 94Tivoli Cross-Site 296Tivoli Enterprise 296token initiative 4toolbars 194tools 292, 311traditional 4traffic 88training 121transaction 3Transactionality 250transactions 3, 27Transactive Content 190transformation 4Tree View 195trust 20TXSeries 296

UUML 27, 189understanding 65uniform resource locator , See URLuniversal 20, 51usage patterns 84use 19user 53, 126

interface, See GUIuser accesses 51user identification 103user identify 53user interface 83, 205User interface logic 206user-driven navigation 196users 11, 183, 191

Vvalidate input 24value chain 4VBScript 131vendor 21vendors 4, 26video 296View 195, 209Virtual Private Network 136Virtual Private Networks 297Visigenic 137vision 31VisualAge family 298VisualBasic 202volume 20VPN 61, 88, 136VxML 27

WWalkthrough 74WAP 27weaknesses 184Web 3Web application server 126Web browser 177Web designers 191web paradigms 20Web Server 24, 203

design patterns 208dynamic HTML 206Extend 204


static model 203to application server 203transactive model 203UI design considerations 204

Web server 53Web year 289WebDAV 27WebSphere Application Server 295WebSphere Performance Pack 296WebSphere Studio, V3.0 298Windows 187Windows 95 49Windows NT 264wireless 129, 131WML 27, 131Workflow 27workflow 90, 296, 310workshop 56

agenda 64conducting 64description 56documentation 59goals 56, 58outline 45participants 57, 58preparation 57rationale 56

worldwide 51wrapping 171WYSIWYG HTML 297

XX.509 79X/Open SQL 276XMI 27XML 27, 131, 179

client devices 212XSL 131, 179

client devices 212

Index 349


IBM Redbooks evaluation

Design Considerations: From Client/Server Applications to e-business ApplicationsSG24-5503-00

Your feedback is very important to help us maintain the quality of IBM Redbooks. Please complete thisquestionnaire and return it using one of the following methods:

• Use the online evaluation form found at http://www.redbooks.ibm.com/• Fax this form to: USA International Access Code + 1 914 432 8264• Send your comments in an Internet note to [email protected]

Which of the following best describes you?_ Customer _ Business Partner _ Solution Developer _ IBM employee_ None of the above

Please rate your overall satisfaction with this book using the scale:(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)

Overall Satisfaction __________

Please answer the following questions:

Was this redbook published in time for your needs? Yes___ No___

If no, please explain:

What other Redbooks would you like to see published?

Comments/Suggestions: (THANK YOU FOR YOUR FEEDBACK!)

http://www.redbooks.ibm.com/contacts.html



Printed in the U.S.A.

SG24-5503-00

Design

Considerations:

From

Client/Server

App

licationsto

e-businessA

pplicationsS

G24-5503-00

®

Design Considerations: From Client/Server Applications to e...

Documents

Transcript of Design Considerations: From Client/Server Applications to e...