Building Application Servers (SIGS: Advances in Object Technology)

Building Application Servers

Advances in Object Technology Series Dr. Richard S. Wiener, Series Editor and Editor-in-Chief of Journal of Object-Oriented Programming SIGS Publications, Inc. New York, New York and Department of Computer Science University of Colorado Colorado Springs, Colorado 1. Object Lessons: Lessons Learned in Object-Oriented Development Projects • Tom Love 2. Objectifying Real-Time Systems • John R. Ellis 3. Object Development Methods • edited by Andy Carmichael 4. Inside the Object Model: The Sensible Use of C++ • David M. Papurt 5. Using Motif with C++ • Daniel J. Bernstein 6. Using CRC Cards: An Informal Approach to Object-Oriented Development • Nancy M. Wilkinson 7. Rapid Software Development with Smalltalk • Mark Lorenz 8. Applying OMT: A Practical Step-By Step Guide to Using the Object Modeling Technique • Kurt W. Derr 9. The Smalltalk Developer's Guide to VisualWorks • Tim Howard 10. Objectifying Motif • Charles F. Bowman 11. Reliable Object-Oriented Software: Applying Analysis & Design • Ed Seidewitz & Mike Stark 12. Developing Visual Programming Applications Using Smalltalk • Michael Linderman 13. Object-Oriented COBOL • Edmund C. Arranga & Frank P. Coyle 14. Visual Object-Oriented Programming Using Delphi • Richard Wiener & Claude Wiatrowski 15. Object Modeling and Design Strategies: Tips and Techniques • Sanjiv Gossain 16. The VisualAge for Smalltalk Primer • Liwu Li 17. Java Programming by Example • Rajiv Sharma & Vivek Sharma 18. Rethinking Smart Objects: Building Artificial Intelligence with Objects • Daniel W. Rasmus 19. The Distributed Smalltalk Survival Guide • Terry Montlick 20. Java for the COBOL Programmer • E. Reed Doke, Ph.D. and Bill C. Hardgrave, Ph.D. 21. Building Application Servers • Rick Leander

Additional Volumes in Preparation

Building Application Servers Rick Leander

|CAMBRIDGE 1

UNIVERSITY PRESS

M S I GS TtBk B O O K S

I PUBLISHED BY THE PRESS SYNDICATE OF THE UNIVERSITY OF CAMBRIDGE

The Pitt Building, Trumpington Street, Cambridge, United Kingdom CAMBRIDGE UNIVERSITY PRESS

The Edinburgh Building, Cambridge CB2 2RU, UK 40 West 20th Street, New York, NY 10011-4211, USA 10 Stamford Road, Oakleigh, Melbourne 3166, Australia

www.cup.cam.ac.uk www.cup.org

Ruiz de Alarcon 13, 28014 Madrid, Spain Published in association with SIGS Books © 2000 Cambridge University Press All rights reserved. This book is in copyright. Subject to statutory exception and to the provisions of the relevant collective licensing agreements, no reproduction of any part may take place without the written permission of Cambridge University Press. Any product mentioned in this book may be a trademark of its company. First published in 2000 Design and composition by Andrea Cammarata Cover design by Andrea Cammarata Printed in the United States of America A catalog record for this book is available from the British Library. Library of Congress Cataloging-in-Publication Data is on record with the publisher.

ISBN 0 521 77849 2 paperback

To Barb

Contents

Acknowlegments

xix

Introduction Who Should Read This Book Organization Part 1—Architecture Part 2—Design Part 3—Programming How to Get the Program Code

xxi xxi xxii xxii xxiii xxiii xxiii

PARTI • ARCHITECTURE

l

Chapter 1: What Is an Application Server and Why Do I Need One? Two-Tiered vs. Multi-Tiered Computing Why I Chose Multi-Tiered Client/Server What Can an Application Server Do? Scalability Distributed processing Reusable business objects Business rule processing Cross-platform integration Costs and Disadvantages of Application Servers Long-term commitment Middleware acquisition New ways to twist the brain The end of the coding cowboy Software reuse Moving from Traditional Client/Server to N-Tier Computing vii

3 3 4 6 7 7 8 8 9 9 10 10 11 11 12 12

viii

Building Application Servers Summary References

13 14

Chapter 2: Anatomy of an Application Server Overview of the Application Server Architecture Middleware: The Glue That Holds It Together Middleware Categories Remote database protocols Remote procedure calls Distributed objects Transaction processing monitors Message brokers Commercial application servers Applying Middleware to the Application Server Architecture Your best face forward: presenting a clean application interface Business objects: modeling your business in software Persistence: talking to the database Alternative Application Server Architectures The fourth layer Data-centric application servers Web server-based approaches Putting It All Together Summary References

15 16 18 19 21 21 23 26 27 27 28 29 30 32 34 34 34 37 38 38 39

PART 2 • DESIGN

41

Chapter 3: Designing Application Servers Joint Application Design Business Object Design Modeling business processes Reuse Design standards Iterative Development Why combine design and programming?

43 44 45 46 46 47 47 48

Contents

Self-directed technical review Design Constraints Layered design Middleware matters Integrating existing applications A Brief Introduction to UML Notation Diagrams and symbols Use case diagrams Class diagrams Sequence diagrams Meeting the End User's Needs Summary References Chapter 4: Service Interface Design What Is a Service Interface? Design by Interface More on JAD: Developing Use Cases Describe the context Describe the actors Describe the procedure Describe exceptions Use common language Iterate and refine A brief example Making use cases work Turning Use Cases into Services The service is application-specific The service is self-contained The service handles all exceptions The service hides the business object layer The service conforms to standards Bundling services into interfaces Handling Errors and Exceptions User interface errors

48 49 49 50 51 51 52 53 53 58 61 62 63 65 66 66 68 69 71 71 72 73 73 74 76 76 78 79 80 81 82 83 84 85

ix

Building Application Servers Application errors System and network errors Exceptions and interface design Summary References Further Reading Chapter 5: Designing Business Objects Moving from Interfaces to Objects From data models to business objects Choosing a design approach What Exactly Is a Business Object? Finding the Objects in Your Business Defining the Objects Designing the Objects Attributes Methods States Events Business object specifications Object Interaction Aggregation Generalization and specialization Association Collections Creating the class diagram Application Server Issues and Constraints Short business cycles Reuse Concurrency and synchronization Repositories Persistence Linking Business Objects to the Service Interface Developing sequence diagrams Creating new business objects

86 87 87 88 89 89 91 92 92 93 94 95 98 101 101 102 103 104 105 107 107 109 112 114 115 116 116 117 119 119 120 120 121 122

Contents Implementing services Business Object Architecture Summary References Further Reading

123 125 126 127 127

Chapter 6: Designing the Persistent Object Layer The Role of the Persistence Layer Relational Database Principles Database history The relational data model Structured query language (SQL) Database middleware Designing a Persistent Object Layer Persistence layer example Generalized object servers Tracking the objects Objects and relational databases Scalability Using Object-Oriented Databases Using Objects to Represent External Applications Summary References Further Reading

129 130 132 132 133 134 136 137 138 140 143 144 149 152 154 154 155 155

Chapter 7: Integrating Existing Systems and Legacy Software Design Issues for Application Integration What Do We Have—Application Mining Turning Subroutines into Services Proxy Objects How to access remote software Input and Output Streams Message-oriented middleware Advanced sneaker net Accessing Application Databases

157 158 159 160 160 162 164 165 167 168

xi

xii

Building Application Servers Direct database access Replication Synchronizing Transactions Fun with Punch Cards: What to Do with Legacy Software Summary References Further Reading

168 169 170 171 172 173 173

PART 3 • PROGRAMMING

175

Chapter 8: Implementing an Application Server Framework The Application Server Framework Initializing the framework Processing service requests Commercial frameworks Choosing a framework strategy Additional Framework Requirements Scalability Concurrency Security Fault tolerance Development Strategies Communications support Development environment Tools Training Metrics Summary References

177 178 178 180 182 182 183 183 184 184 185 185 186 187 188 192 194 194 195

Chapter 9: Using Java to Build Business Objects Using Java to Illustrate Programming Principles Overview of the Distributed Java Architecture Object-Oriented Programming in Java Java class definitions

197 198 198 201 201

Contents

Class composition in Java Class association in Java Class generalization in Java Coding Guidelines in Java Using Interfaces to Package Objects Distributing Java Objects with RMI Creating the remote interface Creating a remote object Creating the stub and skeleton Registering the remote object Accessing the remote object Comparing Distributed Java with Other Middleware Architectures Distributed objects in CORBA Microsoft's DCOM Summary References Further Reading Chapter 10: Persistent Objects: Communicating with Databases An Overview of JDBC JDBC architecture SQL basics Basic JDBC programming Other database middleware Creating a Persistent Object Framework A Simple Persistent Object Server Joining business objects with relational databases Tracking business objects Serving up customer objects Extending the Simple Object Server Adding more objects Serving up multiple objects from the same query Serving up complex objects Optimizing the Persistence Layer Capacity planning

203 203 206 206 207 211 211 212 214 214 217 219 219 221 223 224 224 227 228 228 230 233 238 238 239 240 245 248 250 250 251 255 258 259

xiii

xiv

Building Application Servers Minimizing database connections Distributing business objects Concurrency and synchronization Optimizing throughput Summary References Further Reading

259 262 263 266 266 267 267

Chapter 11: Interfaces and Client-Side Communication Client/Server Communication Establishing remote communication Processing remote communication Server-side communication Requesting services Creating a Service Interface Defining the service interface Implementing the interface Registering the service interface Using the Service Interface Accessing the services Locating the data Storing the data Releasing the remote object Passing Data, Objects and Properties Primitives Objects Properties Returning errors Messages, events, and asynchronous communication Summary References Further Reading

269 270 271 272 272 274 274 275 276 279 280 281 282 284 285 286 286 286 288 290 294 295 295 296

Chapter 12: Enforcing Business Rules What is a Business Rule?

297 298

Contents Turning Business Rules into Code Structure-based rules Rules in code Rules in data Classification Maintaining rule and classification tables Where to Put the Code User interface Service interface Business objects Persistence Database server Standardized Error Handling Standardized messages Exception objects Message handling Error logs Commercial Business Rule Engines Security and Authorization Strategies Organizing security rules Where to implement security Summary References Further Reading Chapter 13: Multiprocessing, Concurrency, and Transactions The Trouble with Multiprocessing Multi-tasking Multi-threading Multiple objects Multiple, synchronized data Multiple data sources Multiprocessing Within the Application Server User interfaces Service interfaces

299 300 301 306 313 316 317 318 319 320 321 321 322 322 322 323 324 325 326 327 328 329 330 330 331 332 333 334 335 336 336 337 338 338

xv

xvi

Building Application Servers Business objects Persistent objects Database servers The Class Factory Model Applying the class factory model Creating the class factory object Using the class factory When to use the class factory Multi-Threading Implementing multi-threading Synchronizing execution Synchronizing Objects and Data Locking at the database level Locking at the object level Locking at the persistence level Resolving deadlocks Transactions Transaction basics Implementing transaction objects Commit or rollback Two-phase commit Commercial transaction monitors Summary References Further Reading Chapter 14: The Next Generation of Business Applications Clues from the Past Increased automation Ease of use Business intelligence Communications How much farther can we go? Emerging Component Standards Microsoft's Distributed Internet Architecture

338 339 339 340 341 342 345 346 346 347 353 353 354 355 357 358 360 360 361 363 365 366 367 368 368 369 371 372 373 374 375 376 376 377

Contents

Enterprise JavaBeans CORBA object monitors Other contenders The Application Software Marketplace Off the shelf applications The component marketplace The open source bazaar The Emerging Business Platform Cheap computers Palm-tops and cell phones Pervasive computing Where is it all going? Final Thoughts References

379 380 380 382 383 384 385 387 387 388 389 390 390 392

Appendix: Setting up a Development Environment Development Using a Single Computer Hardware requirements Software requirements Development on the Network Network hardware Software Compiling and Testing Java and RMI Step 1: set up a project directory Step 2: compile the server and applet Step 3: use rmic to create the stub and skeleton classes Step 4: start the Web server and RMI registry Step 5: start the application server Step 6: run the applet Running on a network Where to get help Setting up JDBC Summary Sources for Software

393 394 395 395 396 396 397 398 398 399 399 400 400 401 401 402 402 403 403

Index

405

xvii

Acknowledgments

Many thanks to Lothlorien Hornet and the people at SIGS and Cambridge University Press for all of their guidance and help in making this book possible. Thanks also to technical editor Lisa McCumber for her many insights and to copy editor Matt Lusher, who transformed my ramblings into readable prose. Thanks also to Dr. James Gerlach at the University of Colorado at Denver for his excellent course, Distributed Object Computing, that sparked my interest in middleware and distributed processing. Thanks also to RFB&D for quickly providing reference materials. Finally, special thanks to Barb, my wonderful wife, for her encouragement, support, and assistance.

XIX

Introduction

You've read everything you can find about middleware, CORBA, transaction monitors, message brokers, enterprise JavaBeans, and other distributed technologies. Now it's time to put them to work. Time to build your company's first multi-tiered application. But where do you start? How do you structure the programs? How do you distribute the code? What about integrating existing applications and databases? This was the problem that I faced as I began working with multi-tiered development. There was plenty of information on the tools and technologies, but little on how to make them work in a business setting. Application servers and related technologies offer great promise and potential for solving the issues that trouble corporate computing. Problems like scalability, application integration and code reuse. But before we can solve these grand problems, we have to figure out how to use the technology. How do we process orders, ship products, bill customers, approve loan applications and pay insurance claims. My hope is that this book will offer some guidelines to start you on your way. Instead of focusing on middleware, the emphasis is on the design issues and programming techniques necessary to create an overall business application framework. The approach is user-centric, relying on joint development between developers and business people, using short, iterative design-program-review cycles. Object-oriented development is also stressed using designs illustrated with UML and programming examples written for the Java platform. Although Java and RMI are used, the framework will work with almost any language or distributed object platform.

Who Should Read This Book This book is primarily intended for software developers, the designers and programmers who have to take these new technologies and turn them into business solutions. It is written at a moderate technical level XXI

xxii

Building Application Servers and assumes that you, the reader, are familiar with client/server or mainframe development in a business environment. You do not need to understand middleware, object-oriented programming, or be a Java programming wizard, but you should be familiar with relational databases, user interface design and be able to read and understand program code. For those not familiar with some of the more technical topics, such as UML and distributed processing, the book provides enough background to get you started, then suggests additional references to fill in the details that are beyond the scope of this book. Although the book is intended for software developers, the first two sections will be useful to business people working in a joint development team environment. These sections offer background on the development process and introduce the tools needed to create an effective design. Joint application design, use cases, and iterative development are concepts that must be understood by all team members. Managers can also read through these chapters to gain a better understanding of the benefits of the technology and the overall design process. Other information technology workers, such as network and database administrators, can also benefit from this book by gaining an understanding of these new technologies and processes.

Organization To fully understand application server technology, it must be examined from several different perspectives, first from a high level view, on to the user's perspective and finally to the programmer's vantage point. Not only does each perspective show different aspects of the technology, the three separate perspectives allow you, the reader, to ease into the many details that must be considered before you can understand how to make the technology work.

Part 1—Architecture The book begins by examining what an application server is and how it can benefit the business. Benefits and drawbacks are listed, followed by a general overview of the technology. Once these are understood, the three layers of the application framework, the service interface, business objects and persistent layer, are discussed in general terms.

Introduction

Part 2—Design The design view looks at the application framework from a user-centric view, examining how the layers perform business functions. The emphasis in this section is on specifying the business requirements through use cases and then creating a software design that will meet these needs.

Part 3—Programming Once these layers are examined from a user-centric business perspective, the programming section examines each layer in even greater detail, offering techniques that can be used to create the program code that will perform the tasks specified during software design.

How to Get the Program Code The source code for the program examples, as well as the full implementation of each program, can be downloaded from the Cambridge University Press site: http://www.cup.org/Titles/77/0521778492.html In addition to this site, the files can also be obtained from my personal Website at: http://pages.prodigy.net/rleander Once expanded, the files are distributed into directories by chapter, with program listings in the main directory and additional program code included in subdirectories underneath each chapter directory. Check the readme.txt file included in the primary directory for additional information.

xxiii

Part 1

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

Chapter 1

What Is an Application Server and Why Do I Need One? Over the past year or so, quite a few software vendors have released packages they call application servers. Inprise, Oracle, BEA, and a number of others all have jumped onto the application server bandwagon, extending their product lines with products that target enterprise computing. So, what exactly is an application server? This chapter will explore the reasons why application server technology will play an important role in the next generation of enterprise computing. Topics include: • Two-tiered vs. multi-tiered computing • Why I chose multi-tiered client/server • What can an application server do? • Costs and disadvantages of application servers • Moving from traditional client/server to n-tier computing

Two-Tiered vs. Multi-Tiered Computing There are quite a few advantages to traditional two-tiered client/server. The database products are very mature with heavy competition to constantly

Building Application Servers improve performance and features. Client-side development tools like Microsoft Access, Borland Delphi, and C++ Builder have become so easy to use that much of the code writes itself. Even the networks are easier to install and maintain. But as most client/server developers soon discover, it is almost too easy. New applications multiply on the server and, with the constantly plunging price of computers, more clients keep coming on board. In no time at all, the server is overloaded. Even after all of the memory slots have been filled, more CPUs have been added, and thousands of dollars have been spent to upgrade the network, the users still complain that response time is too slow. To solve this problem, the industry is now touting three-tier and n-tier (multi-tiered) client/server. The server itself becomes a network of computers that can grow to meet the increasing client demands. Instead of the client software communicating directly with the database server, a middle layer of software, called an application server, provides services to the client (see Figure 1-1). This minimizes the number of connections to the database server and spreads the processing over several computers. It also allows the client software to shrink, because much of the processing is passed to the application server. The client software can now become as simple as a form running on a Web page. Since so much of the processing moves to the middle layer, building an application server can be a difficult, complex process requiring a whole new set of tools and skills. Every software vendor in the business is rushing to sell middleware tools, but the techniques to use these tools are still in the early stages of development. Many sources of information are available on how the tools have been implemented, their architecture, services, protocols, and how to get them running. But even now, little practical knowledge exists on how to build the software. This book will look at some of the principles and practices that can help software developers make middleware tools solve these business problems.

Why I Chose Multi-Tiered Client/Server Most of my consulting work revolves around managed healthcare, an industry where large volumes of information are scrutinized against a constantly changing set of business rules. The software must handle large

What Is an Application Server and Why Do I Need One? Database Server

Client

Two-Tier Client/Server

Client

Application Server

Database Server

Three-Tier Client/Server

Figure 1-1. Two tier vs. threetierclient/server

amounts of data efficiently, yet be flexible, because the industry tries to balance ever-increasing costs with demands for quality care while fielding an ever-increasing barrage of government regulations. My work began with mainframe-based systems, but several years ago, I began creating two-tiered client/server systems for small start-ups and medical specialty groups. As the client/server software began to grow, I found several problems. The first was that response time started to bog down with the number of workstations in use. Upgrading the database server helped, but only until more workstations were added. Next, I found that the development tools worked well for interactive, screen-oriented software development, but lacked the ability to do mainframe style batch processing, working with large amounts of data quickly. Tools like Crystal Reports helped, but these did not provide the flexibility in calculations that were necessary for the application.

Building Application Servers The problem that finally led me to investigate multi-tiered computing was business rule processing. As a claim is submitted into the database, a few critical pieces of information (for example, patient, doctor, diagnosis, date of service and medical procedure code) must be checked against a large set of business rules such as: • Is the member eligible for services? • Has the service been authorized? • Is this an appropriate service for the diagnosis? • Is the doctor allowed to perform these services? • Is this an appropriate service for the age and gender of the patient? There are often two or three hundred rules that must be verified before a claim can be paid. Once these rules are checked, the appropriate fee and benefit schedules must be matched to determine how much the doctor should receive, and what portion must be paid by the patient. Try coding this in Visual BASIC or Delphi. It can be done (we've done it), but without some form of back-end processing, there is no way it can be done within the limits of reasonable response time. Our solution was to process the rules off-hours in batch mode, but this limited the ability of the claims processors to get their work done. With multi-tiered computing, I can begin to offload business rule processing to a separate server and test these business rules as claim information is entered. Many of the data tables can be loaded into streamlined business objects in memory, which will speed up processing. The more complex checks can be run in the background at a lower priority. Batch processing for decision support and reporting can be moved to separate machines where the data can be replicated into a data warehouse application.

What Can an Application Server Do? In addition to the issues described above, an application server can also solve many other weaknesses of traditional two-tiered client/server computing and provide many new benefits as well. An application server

What Is an Application Server and Why Do I Need One?

helps the system administrator by providing scalable software that can be spread over multiple machines for better system performance. It helps the software designer by providing clearly defined logical boundaries that enable the designers to create business objects that model the business closely. In some ways, software development is also easier, because the code is broken up into smaller, more granular modules and services that are much easier to reuse. Application integration is also much easier, using middleware services to translate data formats and simplify communication between different vendor's machines.

Scalability The most apparent benefit of multi-tiered client/server is scalability, because the workload is spread among several computers. No matter how much is spent on the latest leading-edge mega-server, there is a finite amount of processing power that any one computer can produce. Spending the same amount of money on several medium-grade servers will generate more computing horsepower and may even cost less. Where the savings really show is in the incremental costs of upgrades. The mega-server may have some limited upgrade capabilities, but when it maxes out, it has to be replaced with an even more expensive supermega-server. Not only does the company have to absorb the cost of a new server, it has to write off the old one. With distributed servers, the only cost is the incremental cost of an additional medium-grade server.

Distributed processing Another advantage is that the databases and application servers can be distributed closest to where the work needs to be done. If order entry is done in San Francisco and production and inventory are done in Atlanta, it makes sense to keep the databases where the majority of the work is done instead of keeping all the data at the corporate office in Chicago. Network traffic will be minimized, because order entry will be done locally in San Francisco, with a much smaller amount of traffic routed between San Francisco and Atlanta to check inventory levels. If Chicago wants management reporting, data can be summarized in San Francisco and Atlanta, then sent in summary form to Chicago.

8

Building Application Servers Distributed processing can also be used to hold local instances of remote data. This will minimize network traffic even more and allow processing even when the remote connection goes down. An inventory item object residing in San Francisco could hold the current number of items in stock and the number reserved by recent orders. Periodically, it would send a message to its counterpart in Atlanta to reserve the items and get a new update of the number actually in stock. If the network goes down, order entry does not have to stop, because the local computer has a close approximation of how many items are available. Once the network comes back up, the update message can correct any discrepancies.

Reusable business objects An application server is a repository of services and objects that reflect business processes. Since these processes can be described in business language, rather than computer language, it is much easier for the developer to translate business requirements into effective software design. With clearer communication between software developers and business people, the design will come closer to reflecting the real business needs. This results in software that is delivered sooner and costs less to produce. Once the application server is in place, the objects and services already developed are available for reuse in other applications. Instead of a tightly integrated, closed application, much of the functionality is exposed to the development team. Just as Visual Basic provides a set of GUI components that are used over and over again, most middleware implementations require a common, standardized interface and component model that makes reuse much easier and more cost effective.

Business rule processing Most two-tiered client/server tools emphasized a data-centric view of software design in which the client software provided a user interface to manipulate information stored on a database server. Almost all processing had to be done on the client side away from the database; this arrangement required additional network traffic. Some processing could be moved to the database server, but this required proprietary stored-procedure languages that were limited to each particular database server vendor.

What Is an Application Server and Why Do I Need One?

Application server development stresses business object construction rather than data storage. Each component contains services as well as data, which allows a much wider range of data integrity checks as well as the ability to derive additional information from the data contained in the object. The services can also encapsulate business rules and processes that model the actual business. When an invoice is entered, the invoice object has the intelligence to check the customer object to ensure that credit can be authorized. These rules and processes are performed automatically when a service is requested to store the data.

Cross-platform integration Since most organizations already have a large inventory of applications in place, the middleware vendors have invested much of their effort into cross-platform integration. The developer does not have to be concerned with translating low-level data formats, byte-order representations or other vendor-specific data. The middleware can also bridge multiple programming languages by using a high level interface definition language (IDL). Once the functions are declared in this language, the IDL compiler will generate translation code in a variety of programming languages. This allows programs in one language to call functions or access objects written in another language even when they are located on a different computer.

Costs and Disadvantages of Application Servers Although there are many advantages to implementing an application server, the technology is not appropriate for every application. Multitiered development requires a substantial up-front commitment that may not immediately show results. The application server is a complex piece of software that requires a whole new set of skills and tools. Most middleware packages are based on object-oriented design and programming concepts that require a higher level of abstraction and have higher learning curves. Many also rely on component architectures that must conform to rigid new programming standards. Components and modules must also be general enough to allow later reuse. The technology solves many problems but also brings its own set of difficulties.

10

Building Application Servers

Long-term commitment Implementing an application server architecture is a long-term, enterprise scale commitment. This is not the appropriate choice for a project that must be developed in "Internet time" or for a single, limited use application. This is an enterprise architecture that requires new hardware configurations, middleware, programming models, administrative tools, and, most of all, a new way of looking at software development. The first application will not be easy. Much time will be spent in trial and error, evaluating tools, learning the idiosyncrasies of middleware, and creating infrastructure instead of applications. Viewed as a single application, it will definitely not be cost-effective. This technology can only be justified when seen as the first step in building the foundation to a new enterprise architecture.

Middleware acquisition One or more middleware packages are probably already sitting on your hard disk. Microsoft bundles its Component Object Model architecture (COM and DCOM) with its most recent versions of Windows. Microsoft Transaction Server (MTS) is also making its way onto the Windows NT platform with the release of SQL Server 7. Java development packages provide a simple object request broker (ORB) called RMI (Remote Method Invocation) that is included with the Java Software Developers Kit (SDK) version 1.1 or higher. So why pay for another middleware solution? Most of these middleware packages are bound to one proprietary platform, but a comprehensive middleware solution must span a variety of computer platforms, programming languages and databases. The choice of middleware depends on current hardware and programming languages that are already in place, as well as future expansion requirements. COM, MTS and RMI are each vendor-, language-, or platform-specific. This may not be a problem if the organization is already standardized on Microsoft or Java platforms, but each may limit future scaleability and growth. The initial purchase price is also just the beginning of the middleware cost. Any choice must also take into account staff training, hardware and network acquisition, programming, and administration costs. Training and start-up costs can often eclipse the purchase price of even the most expensive middleware package.

What Is an Application Server and Why Do I Need One?

New ways to twist the brain Multi-tiered client/server also requires new ways of thinking about software. Although programming is a fairly abstract ability, object-oriented software design and programming require an even higher level of abstraction. Instead of a single sequential flow of execution, object orientation requires visualizing the interaction of multiple processes running in parallel on several computers at the same time. Consultants are available to act as guides through the project and to provide training, but at a very high cost. Many tools are also available to help manage the transition, but each of these add acquisition and training costs to the project. Money spent wisely in this area can greatly increase the chances of success, but costs can quickly mount with little benefit if spent in the wrong direction.

The end of the coding cowboy In "Coding Cowboys and Interdependent Systems," Warren Keuffel and Bryce Carey (Keuffel 1998) make an analogy to the Old West. The cowboys out on the range worked on their own, independent, untroubled by the rest of the world. When the day came that the railroads ran tracks across the range, that independent spirit suddenly changed. If the cowboys could not coordinate their track-crossing schedule with the railroad's standard of time, the cows would be caught on the cowcatcher. Until recently, programmers could make up their own rules, too; but with the advent of the Internet and electronic commerce, software developers must now adhere to common standards or the bits they herd will be roadkill too. Components and middleware architectures require much more discipline and standardization. Objects and components must conform to rigid standards and implement tightly defined interface methods. Much of this is provided by the programming tools, but design and structure must conform to these standards or the application will not run. Developers must also work closely together to ensure that interfaces and communication paths match and that objects and modules are coordinated to each other.

11

12

Building Application Servers

Software reuse Software reuse can be as much a problem as it can be a benefit. Not only do the components have to meet the current objectives, they also have to anticipate future needs. The time required to implement and test reusable software will take longer and development costs will increase significantly; however, in most cases the benefits will outweigh the additional costs. The additional costs and difficulties will be offset by the flexibility and scaleability of the software. Also, future costs will be reduced when application services are exposed to the development team and components are available for reuse.

Moving from Traditional Client/Server to N-Tier Computing The move from traditional client/server to a multi-tiered architecture takes time and planning. Management must support the transition and be willing to absorb the additional front-end costs. Architecture, middleware, and development tools must be evaluated and selected, and then servers and networks must be purchased and installed to support development. A comprehensive training strategy must be structured to get the development staff productive with these new tools quickly. And, of course, all of this must be done while supporting the current computing environment (Mowbray 1997). Often the best approach is to choose a small, highly visible trial project. Since much of the time will be spent determining architectural issues and learning new software tools, a small project will minimize the development time. At the same time, the project must also produce tangible, visible benefits to prove the technology and justify spending the resources and time required to make the remaining transition. A workflow tracking application will often provide a good initial project—something like customer inquiries, call tracking, work scheduling, software problem tracking, or another similar application. These applications have a limited amount of data entry, require business logic to move objects from one state to another (route a question to the appropriate person, change the status from open to completed, etc.), and do

What Is an Application Server and Why Do I Need One?

not require large or complex data storage. At the same time, the application logic includes a few wrinkles that will force the designers to consider more than just data storage and retrieval. A trial project like this also minimizes the initial cost of entry. Development machines can be reconfigured to accommodate new architectures. Evaluation versions of software tools and middleware can often be obtained for free from the vendor's Internet site for 30 to 90 days. Developers usually jump at the chance to play with new technology. Just remember to emphasize that the development effort must produce tangible results in a short period of time, or the developers will be going back to their old jobs. Once the test project is implemented and the technology is sold to management, it is time to firm up architectural and middleware decisions. Document the overall client/server architecture strategy and begin to develop interface and development standards. Train the development team and determine server and network needs. Also, remember to purchase the licenses for the middleware and tools that were downloaded from the Internet; once these tools expire, development comes to a screeching halt. Finally, develop a plan to periodically review the architecture and development standards. Determine relevant measurements and metrics to support process improvement. Be receptive to new development tools and methodologies and evaluate products and processes that look promising. Provide training and make sure that the initial architecture and development documents stay up to date (McConnell 1997). Everything should now be in place to begin serious multi-tiered client/server software development.

Summary Application servers and multi-tiered computing are emerging technologies that can provide many benefits to business. This is a technology that should not be approached lightly; but with the strong commitment of the organization, it can solve many problems inherent with traditional mainframe and two-tiered client/server. As the technology matures, it will play a key role in the evolution of software development.

13

14

Building Application Servers • Application servers are built by networking a number of computers together to provide an expandable, scalable application platform. • Two-tiered client/server is a mature technology that can address basic business problems but has difficulty addressing complex business logic and high user volume. • Application server technology enhances the two-tiered model by adding a middle application layer to isolates the business processing. • The distributed platform can provide better throughput by delegating tasks among many computers and can easily expand to accommodate growth. • Software development is enhanced by separating development into smaller tasks and by providing a framework for code reuse. • Application servers do require additional tools and costs that must be absorbed before these benefits are attained. • Approach application server development using a trial project to make sure that the platform meets the business environment.

References Keuffel, Warren, and Bryce Carey. "Coding Cowboys and Interdependent Systems." Software Development Magazine, April 1998: 31, 32. McConnell, Stephen. Software Project Survival Guide. Redmond, Washington: Microsoft Press, 1997. Mowbray, Thomas J., and William A. Ruh. Inside CORBA—Distributed Object Standards and Applications. Reading, Massachusetts: Addison Wesley Longman, 1997.

Chapter 2

Anatomy of an Application Server According to the vendor literature, it appears that moving to multitiered client/server computing is as simple as buying a few products, creating a few Web pages, and writing a little bit of application code. In a recent Microsoft presentation, a company representative created a simple three-tiered application in less than ten minutes (Microsoft, Inc. 1998). He built a Web page with a couple extra lines of VBScript code, displayed about twenty lines of Visual Basic code that was already installed on the transaction server, and then with a few mouse clicks, showed how easy it was to validate a customer number. Too bad the transaction server code only returned "credit OK" if the customer number was 123456789. Microsoft is not the only vendor using this approach to sell middleware products. Although the vendors make the development process look easy, these products are complex pieces of software. Just learning the programming conventions and protocols can take weeks, while producing industrial-strength code could take months. Tools like the Microsoft Transaction Server can make programming somewhat easier for developers by providing communications protocols and development frameworks, but even the simplest service will take far more than twenty lines of code. This chapter will examine the application server from an architectural viewpoint and will also examine the major categories of middleware software. Topics will include: 15

16

Building Application Servers • Overview of the application server architecture • Middleware—the glue that holds it together • Middleware categories • Applying middleware to the application server architecture • Alternative application server architectures • Putting it all together

Overview of the Application Server Architecture An application server contains the middle layers of the client/server software solution. The user interface programs request services from the application server, and these services then store and retrieve data from databases or other application servers. In between lies a collection of business objects that perform the services and enforce business rules. This is illustrated in Figure 2-1. The service interface layer is the "front door" to the application server. Each user interface program is granted a set of services, or remote procedures, that hide all of the details of the business objects and persistent data that reside on the application server. A service may be a request to get customer data or post a bank deposit to a customer's account. These services are then packaged into a service interface object that gives the user interface programmer one simple object that handles all interaction with the application server. The business object layer is a collection of many software objects that encapsulate the processes and rules of the business. A well-designed business object should be described in business terms, not programming language, and should be generalized so it can be reused by several different applications. The service interface layer is application-dependent, servicing specific applications, whereas the business object layer is approached functionally, modeling business processes. The persistence layer acts as an object broker that creates and stores business objects from permanent storage or interfaces with other legacy

Anatomy of an Application Server

Interface Layer Business Object Layer Persistence Layer

0

0

Database Servers

0

Figure 2-1. Application server layers

systems. When business objects are needed, the persistence layer is called upon to retrieve the data from a relational database or other permanent storage then use this data to create a new business object. Once the object is no longer needed, the persistence layer is responsible for storing the data before removing the object from memory. The design of the persistence layer is heavily dependent on existing data structures and the needs of the business object layer. Binding all of these layers together is one or more middleware products that allow programs on one computer to call functions or pass data to programs running on another computer. Middleware comes in many different flavors with a variety of programming models, communication architectures, built-in services, and administration tools. Choosing the best middleware architecture will greatly increase the chance for a successful implementation.

17

18

Building Application Servers

Middleware: The Glue That Holds It Together Before getting into the details of each application server layer, you need to understand the concept of middleware and its role in application server architecture. Briefly stated, middleware is a category of software that provides program-to-program communication across multiple computers. An application server uses middleware to communicate between the client software and the service interface, between the persistence layer and the databases, and often between objects to provide scalability across multiple server computers. Middleware provides communication across multiple computers, programming languages and data representations. To the programmer, there are few differences between calling a function within the same program or calling a function on a remote computer. Middleware can enable a Java program running on a Web browser to access functions written in COBOL residing on an IBM mainframe just as if it were another Java object method. Some additional setup is usually needed to access the remote objects, but once the setup is complete, the location of the objects becomes relatively transparent to the programmer. Though programming becomes transparent, the support that middleware provides for distributed processing can be complex and difficult. There may be differences in data representations, byte orders, floatingpoint standards and parameter passing conventions. Most middleware solutions provide services to solve many of these problems. These services include marshaling, which converts differences between data formats and provides consistent protocols for parameter passing between different programming languages. Directory and naming services are provided to locate functions on computers connected to the network. Life cycle management and load balancing functions are often available to ensure that the remote programs are in memory when needed and that the programs are distributed efficiently between computers. Because of the need for transparency, many of the middleware architectures are joint development efforts that have become industry standards. Computer manufacturers have formed cooperative groups such as the Open Software Foundation (OSF) and the Object Management Group

Anatomy of an Application Server

(OMG) to create standards and specifications that ensure interoperability between hardware platforms and software implementations. Standards such as OSF's Distributed Computing Environment (DCE) and OMG's Common Object Request Broker Architecture (CORBA) have become the foundation for many middleware implementations. With the broad base of industry support, these architectures can solve application server requirements and provide tools for legacy system integration. In its attempt to overcome industry standards, Microsoft has released the Distributed Component Object Model, or DCOM, an extension of Microsoft's original COM (This will be superseded in Windows 2000 by C0M+). DCOM is a component-based distributed object standard that is primarily limited to Microsoft Windows platforms, as well as some limited third-party support on other platforms. Related technologies include ActiveX, DNA, and OLE. A major advantage to the architecture is that the support software is integrated into the Windows operating system, so the middleware software is already resident on most desktop machines. Microsoft also provides a variety of architectural choices that include distributed objects, transaction servers, and message queues. Drawbacks include platform limitations and the complexity of the component model. Although not as broad-based as DCE or CORBA, the Microsoft architectures may be a good choice for organizations that have standardized on Microsoft products.

Middleware Categories The middleware market is still evolving, but several standard architectures have begun to gain dominance. Each addresses specific architectural problems and conforms to different programming models. Although there are overlaps between categories and some vendors provide a combination of approaches, most middleware architectures fall under one or more of the following categories: • Remote database protocols • Remote procedure calls • Distributed objects • Transaction processing monitors

19

20

Building Application Servers

Middleware Services just as an operating system provides functions to support file systems, serial communications, printer spooling, dates and windowing, middleware products provide a range of services that support the needs of middleware programmers. These services do not directly contribute to interprocess communication, but they offer support to make middleware programming and administration much easier. Some of the most common services are listed below. • Naming: The most common service provides an association between a text string (the name) and a remote object or process. Remote IDs are usually illegible bit strings (something like 67474-932-8209943-21002) that are difficult to work with and almost impossible to type. By providing a network-wide handle for each process, naming services provide programmers much easier access to remote procedures or objects. • Directory: Linked closely to naming (many standards combine the two services together), directory services provide a centralized list of all remote processes or objects currently active on the network. A call to the directory service will provide a programmer with the location of any remote process. • Life Cycle: This service provides tools for creating, activating, stopping, and deleting processes from memory. Services are also available to copy or move processes from one machine to another. • Persistence: In addition to handling the remote object's life cycle, persistence enables objects to be stored on disk when they are not needed, yet still maintain their attributes when they are loaded back into memory. • Concurrency: Since many programs often use the same remote procedures or objects, services must be provided that control concurrent access. Critical code segments may not be able to run concurrently without corrupting local variables or losing state information. Concurrency services let the programmer specify how concurrent access is managed within each remote process. • Security: Remote processes are often subject to the same type of access restrictions as programs or databases. Incorporating security within the middleware product allows a consistent standard manner of restricting access. • Time: Maintaining a consistent time reference among all machines may be necessary to insure that objects interact correctly. This can be difficult when remote machines are located in other time zones. Time services provide a standardized time reference as well as conversion to local time zones.

Anatomy of an Application Server

• Message brokers • Commercial application servers As each category is described below, specific vendors and products are mentioned only as examples. All were chosen because they come from established companies and are products that have name recognition.

Remote database protocols Remote database protocols are probably the most familiar of all middleware implementations. These have been around since the inception of client/server databases and are familiar to most client/server developers. The protocols allow a client computer on a network to communicate with the server database without having to be concerned about low-level programming details. These packages include Microsoft's ODBC (Open Database Connectivity) and Data Access Objects (DAO) as well as database gateways and the call-level interfaces provided by database vendors. Their primary purpose is to hide the details of network calls and communication protocols behind a set of simple objects or function calls. They provide naming and location services to easily locate remote databases and provide marshaling services to translate data into multiple programming language and machine formats. Most also enable invocation of remote procedure calls for database-oriented distributed processing using SQL, Java, or other proprietary languages.

Remote procedure calls The OSF Distributed Computing Environment (DCE) was one of the first industry-wide initiatives to develop standards for distributed computing. Companies like IBM, Hewlett/Packard, Digital Equipment, and many others met and agreed on standards that enabled programs running on their computers to call software functions residing on other remote machines. The DCE specification includes standards for remote procedure calls, security, directory services, time services, threads and distributed file services (The Open Group n.d.). In DCE or other remote procedure call architectures, a remote procedure call between two computers requires the calling program to have

21

Building Application Servers

22

some identifier that can be used to locate the procedure on the remote computer. These names or identifiers are then stored in a directory service or naming service. When a remote procedure is created, it is registered in some type of directory or repository on a specific computer; then, when the calling program wants to access the procedure, a text string is passed to the directory or naming service to retrieve this information. The calling program then receives a pointer that identifies the network location of the remote computer and the address of the remote procedure. Once this address is known, the calling program then calls a function located on the local machine that translates the remote procedure information into a common format, then sends this information over the network to the remote computer. The remote computer marshals the data into the remote machine's format and runs the procedure. The results of the procedure call are then passed back to the local computer (where the calling program resides), and the results are marshaled back into the local computer format before being passed back to the calling program (see Figure 2-2). Most remote procedure architectures require that procedures remain stateless. That is, the remote procedure cannot be relied upon to remember data between procedure calls. Memory variables must be reinitialized

Global Directory Remote Function Library

Local Program Data Translation

Figure 2-2. Remote procedure call

Network Connection

Data Translation

Anatomy of an Application Server

before each remote procedure call to ensure that they run correctly. This is both an advantage and disadvantage to the programmer. The programmer does not have to be concerned with the interaction of multiple users, but at the same time, any state variables must be held by the calling program and managed by the programmer. Although most of the current interest is in distributed objects, remote procedure call architectures do have their place. DCE has been an industry standard for over ten years; it is stable, and DCE experience is easy to find. It is available on most mainframe and minicomputer platforms, and it is an excellent choice when integrating legacy software into an application server.

Distributed objects As programmers moved towards object-oriented technology, the distributed programming initiatives moved towards distributing objects instead of distributing function libraries. Like remote procedure calls, distributed objects have been in development for quite a while and several standards are in place to provide interoperability between computer platforms. In a manner similar to the OSF, the Object Management Group (OMG) was formed to create a set of standards and specifications for distributed objects called CORBA (Common Object Request Broker Architecture). The CORBA standard has the broadest industry support and is the most extensive of the distributed object standards. The standard provides cross-platform support from PCs to mainframes, and CORBA compliant software can be written in almost any language. Sun Microsystems provides extensive support for CORBA within the Java platform and recently released new class libraries that simplify CORBA access in release 1.2 of the Java SDK. The Java platform also supports a simpler distributed object model called RMI (Remote Method Invocation). RMI can only be used within the Java runtime environment but provides a simple method of distributing objects over a LAN or internetwork. Microsoft has been slow to adopt CORBA technology, since they have invested heavily in their own distributed object model, the Distributed Component Object Model (DCOM). DCOM is based on the Component

23

24

Building Application Servers Object Model (COM), a programming model that arose out of the need to create compound documents and provide a consistent programming model for the Windows operating system. DCOM is limited primarily to the Windows operating systems, but also has some limited third-party support on other platforms. Each standard has its advantages and drawbacks, but a detailed discussion is beyond the scope of this book. The references listed at the end of this chapter supply detailed analysis, and one or more of these references will be extremely helpful in selecting a distributed object architecture. Although each distributed object standard approaches the task differently, there are many similarities between them. Like remote procedure calls, each provides naming services to locate the objects and provide marshaling to convert data representations across multiple programming languages or machines. Each also provides life cycle and load balancing, but these tasks are complicated by the need to maintain attributes or states within the objects. Also, since these standards work with objects rather than procedure calls, additional services are required to externalize or transform the object representation into a stream of bits that can be sent over the network. All three distributed object standards use some form of interface definition language (IDL) to specify an object's definition to the distributed object system. Using a standard ASCII text file or existing program code, a compiler (IDL for CORBA, MIDL for DCOM, or RMIC for RMI) converts this definition into program modules that provide communication between the calling program and the remote object (see Figure 2-3). The IDL compiler also can generate language header files (such as a C++ header file) that are used by the programming language (C++, or Java for RMI) compiler to resolve object names within the local program. The IDL compiler also generates stub and skeleton program files, which provide communication between the two computers. The stub program contains an object definition that looks, to the local program, just like the object being accessed on the remote computer. It contains method names and attributes that are identical to the remote object, but the stub's methods only contain code that passes arguments to the remote object. The skeleton program on the remote computer acts as the receiver of these network messages, calling the methods of the remote object with the parameters sent over the network.

Anatomy of an Application Server

The IDL generates static object references where object definitions are compiled directly into the program. In addition to accessing static objects, the distributed object architectures also provide access to dynamic objects. These are objects that are not known at compile time but can be discovered and instantiated as the program runs. Once the object is selected, it can be queried to obtain its method names and arguments; then methods can be called using a generalized protocol. Dynamic objects enable tools like Visual Basic or JavaBeans to discover new components as they are added into the distributed architecture. Another technology that has risen from distributed objects are component models. To make dynamic objects easy to use, each object must have a standardized interface which is then used to discover their methods and attributes. Microsoft's DCOM uses COM, a complex component model that requires each component to implement certain standardized interfaces and methods. Sun has created the JavaBean standard, which requires strict naming conventions within each component. The

Network connection

Figure 2-3. Defining a distributed object

25

26

Building Application Servers JavaBean framework then uses a language feature called introspection to retrieve these standardized names and interpret them within the component framework. Component architectures make programming somewhat more difficult with their rigid standards and additional interfaces, but as the technology continues to grow, the tools to create these components will become more sophisticated and component-based development will become the standard way of building software.

Transaction processing monitors Transaction monitors, like IBM's CICS or BEA's Tuxedo products, extend the remote procedure call architecture with a transaction processing layer. This layer takes the database concept of a transaction and applies it to distributed processing. A series of operations can be bound together into a transaction; then, if an operation fails anywhere during the process, all operations that have occurred since the beginning of the transaction are rolled back. This ensures consistent, reliable data no matter what kind of error occurs. The BEA sales literature (Bea Systems, Inc. n.d.) uses the example of an automated teller deposit. When a customer submits a deposit for $500, a message is sent from the ATM machine to the bank's computer. The computer processes the deposit and sends back a message saying that the operation completed successfully. If the status message gets lost somewhere between the bank and the ATM, the ATM has no idea whether the message was processed by the bank's computer or not. The message may have been received by the computer, posting the $500 deposit, and the response lost on the way back to the ATM; or the computer may never have received the posting message. If the ATM machine tries to resend the message, the $500 may be posted twice, or not at all. The transaction monitor ensures that a failure on either side of the message will undo whatever work was done by the bank's computer. With the growing interest in distributed objects, both CICS and Tuxedo are now implementing distributed objects within their transaction monitors. Microsoft, Inprise, and several other client/server tool vendors are also getting into the transaction monitor business, and the OMG has implemented a transaction specification for the CORBA architecture. With all of the possible errors that can occur between client

Anatomy of an Application Server

computers, networks, middleware, and application servers, transaction processing is an important consideration when selecting a middleware architecture.

Message brokers While other middleware architectures rely on transfer of program execution from one computer to another, a message broker uses data (messages) to communicate service requests. The primary advantage of this technology is that once a message is sent, the calling program can continue execution without having to wait for a response. If the network or remote computer is down, the message is retained in a message queue, waiting for the network or computer to come back on line. This is an ideal solution for legacy integration or intermittent communication processes like dial-up modems. The process is often referred to as "fire and forget" since the calling program can continue, knowing that the service will be performed at some time in the future. It is not a good approach for interactive processing, wherein a dialog must be established between the computer and the user, but it is gaining popularity for system integration to share information between a variety of applications and platforms. Message broker products are available from a variety of vendors, including IBM (MQ-Series) and Microsoft (MSMQ). As with the other middleware architectures, message brokers provide marshaling services to convert data representations across a variety of platforms and often include transaction services to provide data integrity (messages are not lost or processed more than once). The products also provide multiple message queues distributed on several computers with routing to ensure message delivery when parts of the network are down.

Commercial application servers With the push for enterprise-wide distributed processing, many of the software vendors are now marketing shrink-wrapped application servers. These vary in content, but each is an attempt to provide one-stop shopping for multi-tiered client/server. These packages include middleware, Web servers, programming tools, administration utilities, and, in some

27

28

Building Application Servers cases, database products. In the best of these packages, companies have either acquired or partnered with other vendors to provide a comprehensive set of tools. In other cases, vendors try to breathe new life into dying products by repackaging them into client/server bundles. Examine these products carefully before selecting a shrink-wrapped application server, since content and price vary greatly between products. Make sure that the tools will fit both the current project and future development plans. Much of the marketing material for these products emphasizes business benefits with many broad promises and few specific details. A major advantage of these products is that they are single-vendor solutions. All services are provided through one software vendor, so much of the finger-pointing is eliminated. Integrating software from a variety of vendors can be difficult, so a single-vendor solution does have its advantages. Just remember that a commitment to a commercial application server package is also a commitment to the vendor.

Applying Middleware to the Application Server Architecture Choosing the best middleware architecture is a difficult task and more than one product may be required. The application server foundation usually relies on a distributed object model, although remote procedure calls can be used if much of the code resides on legacy systems. Service interfaces also require distributed objects or remote procedure calls, while integration with legacy software can be made through any number of middleware options. The interface between the persistence layer and the database is usually provided by the database vendor, but if data integrity is a concern, a transaction monitor may be useful. Within the category of distributed objects, the choice depends on platforms and services needed. Most CORBA implementations provide a wide range of services that simplify the programmer's job. Look closely at the specifications, though, since many services may either not be available or may be sold separately. DCOM is also a viable alternative if the organization uses only Microsoft-based systems. Although this book uses RMI for its examples, RMI is usually not a good choice since it is limited to the Java programming language and

Anatomy of an Application Server

has very few prebuilt services. Version 1.2 of the Java SDK provides similar APIs for CORBA and this will provide a much more scalable architecture while requiring about the same level of programming difficulty. Nevertheless, RMI is a good platform for studying application server development. All of the tools are included within the Java SDK and force the programmer to learn the intricacies of distributed objects without relying on prebuilt services. Once a programmer understands RMI, moving to CORBA is not difficult, and the programmer will have a better understanding of what is going on under the hood.

Your best face forward: presenting a clean application interface The application or service interface layer encapsulates all of the services required to implement a user interface for one specific application. Although the user interface program could access the business objects directly, this would add complexity to both the user interface and the business objects. The user interface would have to track each separate business object connection and would need additional logic to integrate the objects. Each business object would also have to implement methods to support external user interface requirements, which would bloat the objects and limit reusability. A separate application interface layer enables the user interface to concentrate on presentation logic and enables the business objects to concentrate on business requirements. Figure 2-4 shows a block diagram of the service interface. The user interface program makes a single connection to the application interface object, where it can request services to perform each task described in the use cases. Each service then performs the application logic that coordinates the activities of one or more business objects to perform the requested service. Application logic should be kept to a minimum, instantiating new business objects, calling these object's methods to perform the work, and coordinating the exception handling when error conditions occur. The communication between the user interface and the service interface is usually provided by either distributed object or remote procedure call middleware (message brokers may also be used, but are more likely used for integrating external applications). The services are described in an IDL; then the IDL compiler creates stubs and skeleton code to perform

29

30

Building Application Servers the communication. The user interface programmer can then use a set of language-specific files (either header or class files) that act as proxies for each of the services provided by the service interface. The application server programmer must then take the skeleton files and implement the domain-specific code to perform each service.

Business objects: modeling your business in software The business object layer is a repository for all of the business objects used by any application. Each business object is a package of properties and methods that perform a specific business function. These should be described in business language. Examples of business objects are customers, orders, inventory items, and so on. Business objects are often

Business Object A Interface Object Stub

Skeleton

User Interface

Service A Service B Service C Service D

/ Business Object B

X Business Object C

Figure 2-4. The service interface layer

Anatomy of an Application Server

built by first creating fine-grained objects, such as customers and product items, that are then combined to create larger domain objects, such as orders and invoices (see Figure 2-5). In addition to the business design issues, each business object should conform to a standard object model. Naming conventions, standard methods, error handling procedures, documentation and other standards should be agreed upon before the first object is created. This will make programming easier over time and aid in object reuse. Component models such as Enterprise JavaBeans or ActiveX can help enforce these standards and make interfacing to middleware much easier. The choice of middleware across the business object layer is usually limited to distributed objects or a transaction monitor that has been augmented with object technology. Although business objects can be created

Business Object C

Interface Object Service Service Service Service

A B C D

Persistent Object E

High Level Business Object A Business Object D

High Level Business Object B

Figure 2-5. The business object layer

Persistent Object F

31

32

Building Application Servers from procedural code, an object-oriented programming language will make life easier for both the designers and programmers. The idea is to encapsulate all of the functionality of a business entity into a software entity. This is difficult using non—object-oriented software tools. Another consideration is how to distribute business objects across the network. The tradeoff is between efficiency and scalability. Keeping related objects on the same computer will keep network communication down, but limit scalability. A recent article in Component Strategies Magazine described how a distributed object application quickly grew to almost two billion objects (Shelton 1998). Although this sounds incredible, consider that a single invoice object may be composed of a customer object, two or more address objects, many product objects, and so on. Several hundred invoices can easily contain several thousand objects. Scalability must be considered when deciding both the middleware architecture and distribution strategy for the business object layer.

Persistence: talking to the database At the other end of the application server is the persistence layer that interfaces to databases and external applications (see Figure 2-6). Since most business applications rely on database management systems to store data, the attributes of business objects must be loaded and stored in this format. Mapping objects to their data can be done directly in each business object, but this would bloat these objects and add quite a bit of code, as well as additional attributes, making business object construction much more difficult. A better solution is to create a separate persistence layer that is specifically built to load and store business objects. When the service interface needs to locate a business object, it sends a request to the persistence layer to locate and return a reference to the object. If the object is not in memory, the persistence layer locates the data, creates a new instance of the object, loads the data into the object instance, then returns the reference back to the service interface. Once the object is no longer needed, the data can be stored back into the database by sending the object back to the persistence layer. Once a business object is placed in memory, it can be used by any number of different service interfaces or other business objects. When the persistence layer receives a request for a business object, it will know

33

Anatomy of an Application Server

Request Objects

Retrieve Data to Create Objects

Figure 2-6. The persistence layer

if the object is already in memory and will not have to load another instance of the same object. Instead, it can simply return a reference to the existing object. As you can see, the job of the persistence layer is quite a bit like that of an object broker, creating, removing, locating, and tracking objects across the entire application server. Communication between the persistent objects and the database is handled using traditional database middleware such as ODBC, JDBC, or some other protocol provided by the database vendor. If data integrity is a requirement, a transaction monitor can be introduced to provide commit and rollback within the persistence layer. Object databases can also be used to handle all of the persistence chores, but since most companies rely on relational databases for existing applications, selling an object database solution can be difficult. Since the persistence layer also acts as the object broker for the application server, building this layer will be much easier using distributed object middleware to handle the naming and life cycle chores.

Database Server

34

Building Application Servers

Alternative Application Server Architectures The three-layer approach described above with service interface, business object, and persistence layers is only one approach to application server architectures. Some authors suggest a fourth layer inserting a transaction layer between the persistence layer and the database. Others use the traditional two-tiered client server approach but move the data access objects from the user interface onto a middle-tier server. Internet tool vendors are also joining the multi-tiered market with Web serverbased application servers. All of these approaches are worth examining and have merits and drawbacks over the approach described above.

The fourth layer One alternative to the three-layer architecture is to insert a transaction processing layer underneath the persistence layer (see Figure 2-7). This will ensure the integrity of the database when errors occur and prevent the posting of partial transactions. Before the databases are updated, a boundary is set that marks the beginning of the transaction. Each database or remote application is updated, and when all updates have completed successfully, the transactions are committed to the databases and the transaction is closed. If an error occurs, all transactions are rolled back. This may be a good approach in the few cases where applications are highly sensitive and data integrity is extremely critical. Otherwise there is little reason to create a separate layer of code when there are a variety of middleware products that easily manage these functions automatically. If transaction processing is critical, it makes more sense to implement it as a separate service of the persistence layer, offering transaction control as part of the service interface logic.

Data-centric application servers Another approach to application server architecture is to eliminate the business object layer and just create a pool of persistent objects that are directly available to the user interface (see Figure 2-8). This architecture

Anatomy of an Application Server

User Interfaces

Interface Layer Business Object Layer Persistence Layer - ' Tfansac1

8

Q

Database Servers

Figure 2-7. The four-layer architecture

extends the data-centric approach of the classic two-tiered architecture onto additional servers to provide connection pooling and data caching. The user interface program is then still responsible for the business logic, but performance is enhanced by adding the scalability of the distributed architecture. This is the approach taken by many of the RAD (Rapid Application Development) tool vendors to move their products into the application server market. It works well for this form of software development, creating highly efficient multi-tiered software. The best of these tools automatically create the remote data objects through programming wizards that generate highly efficient objects and all of the CORBA code required

35

36

Building Application Servers

User Interface

o

-o

Network Persistence Objects

Q

Q

Database Servers

Q

Figure 2-8. A data-centric architecture

to interface them with the user interface. For applications that have little business logic but high transaction loads and tight development timeframes, these are excellent tools. Unfortunately, this approach has many of the same drawbacks as the two-tiered client/server applications. It produces highly data-centric applications with little ability to handle complex business logic, and the software is fairly inflexible and sometimes difficult to maintain. Other than the data objects, which are programmatically generated, it is also difficult to reuse program code. Finally, since there is no common service interface layer, each user interface program must be built independently.

Anatomy of an Application Server

Web server-based approaches Not to be outdone by the database and RAD tool vendors, Web server-based tools are also appearing that provide multi-tiered applications. The Web server becomes the service interface, serving up Web pages and forms that interface directly with a relational database (see Figure 2-9). Additional business logic can be added through plug-ins or servlets, exposing functions available to the HTML scripts that define the Web pages. This approach works well for Internet- or intranet-based applications but are difficult to expand. Forms must be defined in some version of HTML and must be based on simple table views or SQL queries. Business logic is limited to simple function calls while integration with existing applications can be difficult. This architecture works well for high-volume Internet applications but cannot support the breadth of application requirements needed to support an enterprise architecture.

o

Internet or Intranet

Web Server

Add-lns or Servlets

9

9

Database Servers

Figure 2-9. A Web server-based approach

-o

37

38

Building Application Servers

Putting It All Together An application server is a combination of client computers, servers, networks, middleware, databases, legacy applications, and application code. Without a well-planned, organized architecture, this collection will quickly become a disorganized mess. The application may work, but enhancements and maintenance will be almost impossible. When problems arise, there will be any number of vendors and consultants each pointing their fingers at each other, and the project will become a black hole sucking up the organization's resources and your career. Middleware and program tool selection should be done carefully. Small trial projects can often show weaknesses quickly without large expense. Most software vendors are willing to provide trial software at little or no cost and even provide some sales support and training to ensure that your trial goes smoothly. Bundled commercial application server toolkits and single vendor solutions can also keep the vendor list down. As software is evaluated, you should include training costs and administration as part of the total cost of ownership, these are often complex, difficult tools to learn and manage. A note on trial projects: Be willing to throw away things that do not work. It is easy to look at the cost invested and want to hold on to work already completed. This is always a mistake. Application server technology is still new and there are many products and technologies that are either underdeveloped or just do not work. Find the right products that solve the relevant problems in a way that works for the business, programmers and end users. Do not waste time and resources trying to make bad products fit where they do not belong.

Summary The application server architecture can best be viewed as a number of layers connected by a variety of middleware tools. This book uses a three-layered approach with service interface, business objects, and persistence services, but other architectures can be used. • The user interfaces running on the client computers use distributed object or remote procedure middleware to communicate with the service interface, the front door of the application server.

Anatomy of an Application Server

• The service interface calls on a host of business objects to perform the business logic. • The persistence layer acts as an object broker for the business objects, creating and storing the objects, retrieving their attributes from the database servers through database middleware. • Middleware is a class of software that simplifies communication from a program running on one computer to a program running on another computer. • Remote database middleware enables programs to access data easily residing on separate database servers. • Remote procedure call middleware allows a program on one computer to call a function on another computer. • Distributed object middleware allows programs to access objects located on other computers. • Transaction monitors ensure fail-safe execution of a set of procedures or database operations by providing roll-back capabilities when any step of the transaction fails. • Message-oriented middleware routes data in the form of messages from one computer to another, storing data in message queues when the other computer is inaccessible.

References BEA Systems, Inc. "Programming a Distributed Application: The BEA Tuxedo Approach" n.d. Available from http://www.beasys.com/products/tuxedo/tuxwp_pda/tuxwp_pda.htm Microsoft, Inc. "Developer Briefing." Denver, Colorado: Presented at Denver Southeast Holiday Inn, July 21, 1998. The Open Group. "DCE Distributed Computing Environment Overview." n.d. Available from http://www.opengroup.org/dce/info/ papers/tog-dce-pd-1296.htm

39

40

Building Application Servers Shelton, John H. Ill, and Scott E. Nelson. "Managing a Billion Object System." Component Strategies. September 1998: 44-53.

Part 2

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

41

Chapter 3

Designing Application Servers The goal of business software design is to create information tools that support the organization's business activities. The software developer has to work closely with the end users and be able to communicate in business language as well as computer language. At the same time, the end users have to become educated to understand the computer's capabilities and limitations. Business needs change quickly, so an effective design methodology must be flexible and adapt easily to changing business requirements. N-tier computing complicates the design process even more. While traditional two-tiered client/server emphasized applications and user interfaces, n-tier design requires both application-oriented software design as well as process-oriented business object design. The pressure is on to produce applications in shorter timeframes while creating more robust, reusable business objects. The days of the coding cowboy are over. Fortunately, there are methodologies and tools to support these requirements. The joint application development GAD) team approach brings software developers and end users together to design software jointly. Iterative, incremental development provides shorter design and programming cycles to ensure that the project stays on track and meets the end user's needs. The Unified Modeling Language (UML) can be used by both software developers and end users to communicate design ideas. Computer-aided software engineering (CASE) tools such as Rational Rose can streamline this process by creating UML diagrams, generate skeleton code and then update the UML models as the design progresses. 43

44

Building Application Servers Application server design is still in its infancy. Methodologies are evolving and vendors are constantly introducing new tools. This chapter will provide an overview of the application server design process and will include the following topics: • Joint application design • Business object design • Iterative development • Design constraints • A brief introduction to UML notation • Meeting the user's needs

Joint Application Design For many years, the accepted method for software design was the waterfall method. This was a long, sequential process that started with business analysis, followed by design, programming, testing, and documentation. Each step was followed meticulously. Once one phase of the process was completed, changes were not allowed. This led to long rigid development projects that were measured in man-years, and the software was often obsolete before it was implemented. The process may have worked well for NASA or compiler projects, but quickly broke down when applied to constantly changing business applications. Although the waterfall method still has its adherents, iterative or cyclical approaches have become more prominent in the last few years. The software developers and end users form a joint development team that works together through the entire process. The team drafts rough narratives called use cases that describe how the software will be used to solve a variety of business problems. Once the use cases are agreed upon, the software developers quickly (within a few days) create design specifications and a software prototype to address each use case. This prototype is then brought back to the team for refinement. As the team reviews the prototype and suggests change, they discover additional requirements that either extend the existing use cases or trigger addi-

Designing Application Servers

tional requirements that become new use cases. This process continues as long as necessary. Since the software is constantly refined, it comes much closer to meeting the actual needs of the business. Projects show tangible results almost immediately, not months or years later. Fewer projects get canceled along the way, since visible results can be demonstrated. Projects also cost less because the true requirements are isolated sooner and less time is spent on nonproductive bells and whistles. The process also has advantages for organizational development. End users see that their input makes a difference and feel that others are supporting their work. Management gets quick, tangible results from their investment and, over time, will be willing to commit more resources to information technology. Even the software developers benefit, receiving more recognition for their efforts. The projects often move beyond software development and become a chance to improve business processes. At the same time, some drawbacks exist which you must monitor and manage. You must set boundaries at the beginning of the project to limit both scope and timeframes. An open-ended project can develop a life of its own and never be completed. Projects can easily become sidetracked or steered into wrong directions, resulting in a failure to solve the original problem. Putting software developers and end users together can also cause communication difficulties and personality conflicts, but effective team leadership and management oversight should prevent these problems.

Business Object Design While the joint design team spends its time developing use cases and user interfaces, the application server designers must also focus on the business objects that will support the application. Business object design is a bottom-up process starting with low-level objects that describe business entities. These low-level objects are then aggregated together into objects wherein the entities can work together to perform business functions. Finally, these higher-level objects are packaged into one or more interface objects that will perform all of the functionality of the application.

45

46

Building Application Servers

Modeling business processes Early in the process, while the use cases are being developed, the application server designers must begin to isolate the business objects that will support the use cases. Low-level objects will appear as nouns in the use cases. When a use case includes "a new customer is added," the designer knows that a customer object will be required. "The invoice will be checked to see that each item is in stock" indicates that invoice and item objects must be built. In most cases, the objects will be easy to identify, and many may already exist in the object repository. Defining the methods and properties of each new business object will also become clearer as the use cases are refined. You can often derive properties from user interface screens. For instance, you can assume the "add new customer" screen will show many of the properties of a customer object. A sample invoice will contain the properties of invoice and item objects. You can also extract methods from the use cases by looking at the verbs acting on the objects. "The new customer is added" can indicate the customer object's constructor, or it could indicate an add or insert method within a customer collection. "The invoice will be checked to see that an item is in stock" can imply that an isInStock method is needed in the item object that returns true if the object is in stock. Once each business object is defined, it should be documented so it can be presented to the joint design team. Higher-level objects should be translated back into business language so they can be understood by the nontechnical members of the team. The narrative should include the name and the purpose of the object, followed by its properties and methods. Objects should also be laid out on a class diagram using UML or some other object notation. This diagram will show the relationships among the objects and keep them organized in a logical manner.

Reuse Reuse is the key to effective business object design. Low-level objects like customers or product items often act in many different roles, while larger aggregate objects such as orders or bills flow through several applications. Even the interface object may be referenced by several different user interface applications. But reuse is not something that can be enforced by the software police. Incentives and repositories may help,

Designing Application Servers

but real reuse will only occur as the core objects become familiar to the developers and make sense within the business framework. In addition to reusability, the business objects must perform the services required by the application. This is often where reusability breaks down. An invoice item must know how to create itself, sending errors back to the application when an item is not in stock or a customer does not have sufficient credit. The error mechanism must be flexible enough to communicate consistently with other objects, enabling errors to be passed back to any application that uses the object.

Design standards To make all of these objects work consistently, you need a set of comprehensive yet flexible standards. In many cases the middleware will require adherence to component architecture standards or will generate skeleton code to force compliance. In other cases, the development team must agree to a set of standards that can evolve as the application server grows. Standards must include naming conventions, consistent data formats, class hierarchies, exception objects, documentation formats, and a host of other considerations.

Iterative Development Just as you need a constant flow of communication between the software designers and the end users, you also need similar communication between the designers and programmers (if they are not the same people). A large, complex class diagram can be a pretty sight. It can be aesthetically balanced and logically oriented, with lines flowing between big boxes with little diamonds and triangles. It may be a work of art—but can someone translate this artistic masterpiece into down-and-dirty code? The only way to find out is to let the programmers start programming as soon as possible. The key to success is short, small design (code) review cycles. A programmer can often discover design flaws, inconsistencies, and awkward programming problems that are easily overlooked by the designer. A difficult programming construct can be cleaned up easily if caught early, but after other objects have begun to depend on this construct, the problems will be far more difficult to repair.

47

48

Building Application Servers

Why combine design and programming? Design and programming are really two different views of the same process. Design is a high-level view using symbolic abstractions such as charts, diagrams, and textual narratives. Programming simply translates these notations into a form that the computer understands. In the early days of programming, the process of translation was a highly specialized, technical skill requiring thousands of lines of detailed assembly or compiler code. The task was time-consuming and it made logical sense to divide the labor. The most experienced developers worked out the software design while coding was delegated to a large number of programmers. Today, most programming is done at a much higher level of abstraction using GUI builders, code wizards, and CASE tools that integrate design and programming. These tasks are so tightly integrated that it makes sense to let the same people perform both tasks. In spite of all the coding wizards and GUI builders, programming is still difficult work. Just because the appropriate charts are drawn in the CASE tool and the screens are laid out with the GUI builder, that does not mean programming is complete. Object-oriented programming still requires technical skills, careful attention to detail, and long hours of testing. But programming is easier today than it was when writing assembly language was necessary, and as a result, the distribution of time for each task has shifted dramatically. Iterative design also changes the sequence of these tasks, interweaving short repetitive cycles of design and programming. These tasks each have their own purpose but are integrated so tightly that it makes sense to assign both to the same person.

Self-directed technical review The emphasis in iterative development is on shortening the cycles between design and coding. Instead of trying to work out the entire system design, start with a single use case; then throw together a rough design. Specify a few critical classes and determine their relationships, then start programming. If something does not work or is difficult to program, go back and revise the design to solve the problem. Continue to bounce back and forth between design and programming until the code meets the requirements of the use case.

Designing Application Servers

By using shorter iterative cycles, programming will quickly determine if the design will work. The process acts as a self-directed technical review. Programming will quickly isolate design flaws and often reveal alternative design constructs that may have been overlooked when laying out the class diagrams. Programming can also reveal constraints of language or middleware that couldn't be detected while working out the design. Conversely, the experience gained in programming will speed up design on subsequent use cases. The designer will remember constructs that did not work, and presumably he will not make the same mistake a second time. The capabilities and limitations of the individual objects will be known, helping to isolate changes and enhancements that address the new requirements. Reuse will also be enhanced by knowledge of the objects already available.

Design Constraints Another reason for iterative development is that the application server model requires several new skills that will be new to traditional client/server and mainframe programmers. As seen in the last chapter, the software is designed using a layered approach. Each layer has its own tasks, and much of the work involves communication and interface between layers. New tools and middleware products also impose constraints and new programming techniques to be mastered, and these will influence the way the application is designed. Finally, since most programs must communicate with other systems, application integration also places restrictions on the design.

Layered design Multi-tiered, layered software design is both a blessing and a curse. Since each layer has its own responsibility, the developer can concentrate efforts on that one task and disregard the others. When developers consider user interfaces, they do not have to be concerned with how to access the data from the relational database. For new developers, this concept can be a difficult one to master. Two-tiered, client/server development was based on mapping the user interface to the database, and all functionality resided in the same place. This new development approach splits out these func-

49

50

Building Application Servers tions into separate layers, and it can be difficult for someone not familiar with this approach to envision these pieces separately. Another difficulty lies in developing the interfaces between the layers. A large portion of the design effort now involves isolating the interfaces and determining how they should be structured. Instead of thinking about how to access data from a relational database table, the developers must now consider what services will be required from the application server to retrieve the data needed on the user interface screen. Once the service is designed, the developers must also consider how the middleware can be used to communicate this service request.

Middleware matters The middleware architecture also complements and constrains the design process. Middleware choices are often restricted to the package that management already purchased or the few packages that run on the existing mix of hardware and network. In most cases, a good object-oriented design will work no matter which middleware architecture is chosen; it just has to be translated to an alternate physical design. While working on the design, use the middleware services to their full advantage. Naming, life cycle, persistence, and transactions can save quite a bit of programming time and create a far more robust application. Also try to find out as much as possible about the architecture and internals of the middleware to get the best performance possible. Middleware relies on network communication, which is much slower than local processing. Keep communications between machines to a minimum and use concurrent processing as much as possible. One major constraint in most middleware architectures is the object or component model requirements. Restrictions may include lack of state variables, a remote procedure model instead of object orientation, limited support for certain data formats, or other similar restrictions. You should catalog these and add them to the design standards prior to starting the object design. Disregarding these requirements in the design phase will quickly lead to programmer revolt.

Designing Application Servers

Integrating existing applications Interfacing to existing applications can be difficult. Documentation and source code may be difficult to locate or may not even exist. The guy who wrote the original software may have moved to a better climate without leaving a forwarding address, or the code may have been written by an outside vendor who is no longer in business. Even if the problem was caused by none of the above, the code will seldom work within the middleware architecture. Before spending a lot of time on integration, determine if the interface is really needed. If the users request changes ("it would be nice to..."), determine the costs and benefits of doing the integration. Look at the amount of data transferred; it may be easier to let someone occasionally key the data into the other system. Find out how much time is currently spent on this particular operation and how much time and money would be saved by automating the process. If the interface is necessary, determine the easiest way to access the data. Try to keep the interface as small as possible. If the data is coming from a legacy application, set up a persistent object to retrieve the data directly from the data source, or set up some form of replication. If data must be entered, try to find some existing input process that can be redirected to accept data.

A Brief Introduction to UML Notation Effective software design requires both conceptualization and communication. Conceptualization is the ability to visualize part or all of the design, from the big picture down to the minute details. Communication, in this context, is the ability to replicate at least part of this conceptualization into someone else's head. Neither is an easy task, because object-oriented technology adds several additional levels of abstraction as well as much finer granularity. N-tiered client/server makes this even more difficult, because the processes are synchronized across many different computers. Since the mid-1980s, gurus of object-oriented software design have been developing graphic notation methods to make it easier to conceptualize object-oriented design. For many, it is much easier to visualize a picture or diagram; so graphic notations were chosen over text or program

51

52

Building Application Servers code. Unfortunately, each used different symbols for the same concepts, and, unless everyone understood the specific notation, the methods helped individual conceptualization but got in the way of effective communication. Finally, over the past few years, three industry leaders in object-oriented software design, Grady Booch, James Rumbaugh, and Ivar Jacobson, joined forces to standardize the notation into the Unified Modeling Language (UML). This has quickly become a standard notation for object-oriented modeling and has been adopted by industry groups such as the Object Management Group (OMG), the same group responsible for the CORBA specification. In addition to the standards organizations, the UML has also been incorporated into several (CASE) tools. With these tools, the software designer creates the diagrams, then the tool automatically generates skeleton program files in C++, Java, IDL or other language. Many also provide "round-trip" engineering features that read changes made to the program files, then update the graphical diagrams. This ensures the model stays up-to-date with the software without tedious revisions to the diagrams. Throughout this book, UML will be used to communicate software design concepts. The rest of this section is a quick overview of the UML diagrams and notation. UML is a powerful notation language, and a complete discussion is far beyond the scope of this book. For a detailed yet readable discussion, see UML Distilled by Fowler and Scott (Fowler and Scott 1997).

Diagrams and symbols UML is a notation, not a design methodology. It is a language of diagrams and symbols that describe a detailed software design. Similar to construction blueprints, it can be used by both technical and nontechnical people to communicate design ideas in a graphical manner. A building tenant may not understand all the symbols and underlying technical information represented by a blueprint, but he can still visualize the building layout. In the same way, an effective set of UML diagrams will convey the general complexity, structure, and usage of a software application. A UML model begins with use case diagrams that describe how the

Designing Application Servers

software interacts with the outside world. This is followed by one or more class diagrams that show the class definitions and their relationships and associations. Sequence diagrams describe the flow of information between objects and ensure the appropriate methods have been assigned to the correct objects. UML also includes many other useful tools including collaboration, state transitions, activity, and deployment diagrams, but these will not be included in this discussion.

Use case diagrams Use case diagrams graphically illustrate the interaction between the actors and use cases. An actor, represented by a stick figure, is any person or external software system that receives value from the use case. Each use case, represented by an oval, is a short description of a use case that can be performed by or interacts with the actor. Figure 3-1 shows a typical use case diagram. The actor called customer receives value by placing an order. The « u s e s » arrow indicates that the "place order" use case will rely on the "check credit" use case to check the customer's credit. The «extends» arrow shows that the "credit denied" use case will extend the "place order" use case when the customer's credit is insufficient to place the order. The "place order" use case also relies on the "check inventory" use case. The use case diagram helps visualize and organize the use cases but does not provide any information other than the name of the use cases. Each use case on the diagram should be followed up with a narrative description listing procedures, exceptions, and results. Use cases will be covered in much more detail in Chapter 5.

Class diagrams The class diagram shows each object or class definition in visual form with a variety of different arrows indicating relations and associations between objects. Each class is represented by a box divided into three sections listing the class name, its properties and its methods (see Figure 3-2). The class Customer has properties name, address, city, state, zip, phone, and creditLimit. Notice that the constructor and destructor methods are not included in the class diagram, because these are implied with each

S3

54

Building Application Servers

Customer

Figure 3-1. Use case diagram

Customer name address city

state zip phone creditLimit CheckCredit Display

class Customer { private String name; private String address; private String city; private String state; private String zip; private float creditLimit; public boolean CheckCredit (float n); public void Display ();

Figure 3-2. Class diagram and Java representations of a single object

Designing Application Servers

class. The CheckCredit and Display methods are listed below the attributes. Type information is optional and can be omitted unless there is a logical reason for clarifying the details. Parameter lists are often omitted for methods unless there is a critical parameter that needs to be emphasized. Standard notations are also available to indicate the access level of properties and methods (public, private, or protected), but these will not be used in this book. An association is a logical link between two classes, usually through a key value that points to another object, or through an address pointer in languages like C++. Association provides navigation from one object to another. The association may be either one-to-one or, using a table or list, one-to-many. Figure 3-3 shows a Customer object associated with an Order object. The Customer object points to many Order objects. The 1 next to the Customer indicates that there is only one Customer object per Order, and the * next to the Order indicates that each Customer can be associated with many Orders. The arrow pointing toward the Customer indicates that the Order object has a logical pointer that can locate the Customer, but the Customer object has no knowledge of the Order objects.

Order orderlD date ShipOrder CheckStatus

Customer

1

name address city state zip phone creditLimit CheckCredit Display

Figure 3-3. Class association

55

56

Building Application Servers Composition, often called a whole-part relationship, is a way to show that one class is an attribute of another class. Composition is indicated using a line with a solid diamond next to the composite object. In Figure 3-4, an Order object contains a Shipping Address object. A class definition for the Order object would include a shipAddress property of type Shipping Address. Aggregation is somewhat between association and composition. It is stronger that association, but can be implemented programmatically the same way. Figure 3-5 shows the aggregation of contacts for a customer. There may be many contact events for a customer, but the information within the contact would not be relevant to any other customer. Generalization, or inheritance (in C++ and Java terms), is the process of extending one class to make a new, more specific class. All of the public or protected properties and methods of the superclass are available to the subclass, but the subclass either adds new properties or methods and/or redefines one or more methods to change the superclass's behavior. In Figure 3-6, the Corporate Customer class is derived from the Customer class, with the addition of a contactName property and a revised authorizeCredit method (this method may allow a 10% overrun on the

Order orderlD date ShipOrder CheckStatus

Shipping Address name address city state zip phone Display

Figure 3-4. Class composition

Designing Application Servers

credit limit for corporate customers only). The Corporate Customer class now has all the functionality of the Customer class plus the contactName and a more lenient credit authorization method. The class diagram can illustrate design concepts in a simple, readable manner. Figure 3-7 shows a class diagram that illustrates an order. The Order object shows a composition relation with the Customer object and an association with a collection of Item objects. In simpler terms, the Order object contains a Customer object and a list of Item objects. The Order object provides methods to add (addltem), drop (dropltem), and navigate (findFirst, getNext) among the list of Item objects. There are also methods to print or display the entire order. Note that although the diagram appears relatively simple, this is a moderately difficult programming task. The diagram indicates that the Order object will contain a list of Item objects that can be accessed using sequential navigation. Logical order is not specified in the class diagram, but some ordering key is very likely, and the add and drop methods will have to accommodate this logical order. Figure 3-7 is a simple diagram with only three objects, but most class

Customer Contact name address city state zip phone creditLimit AuthorizeCredit Display

Figure 3-5. Class aggregation

o

date notes Display

57

58

Building Application Servers

Customer name address city state zip phone creditLimit AuthorizeCredit Display

Corporate Customer contactName AuthorizeCredit Display

Figure 3-6. Class generalization

diagrams will have more objects than can fit on a page. A diagram can be subdivided into several sub-diagrams, each showing one portion of the system that represents one or more logical subsystems. When this occurs, the same class may be displayed on several diagrams, showing only the class name with no properties or methods on subsequent pages.

Sequence diagrams The sequence diagram shows how the methods of several objects interact to perform one or more use cases. This diagram is an excellent tool for checking the completeness of an object design and can help discover missing methods and incomplete or poorly designed objects. Although any number of drawing programs can be used to create sequence diagrams, a UML-based CASE tool such as Rational Rose will make the process much easier. These tools do not allow inconsistencies between diagrams, such as method calls in a sequence diagram that are not listed in the class diagram.

Designing Application Servers

Item

Order orderlD orderDate shipDate totalPrice

Customer name address city state zip phone

addltem dropltem findFirst getNext printlnvoice display

1

prodictID name description unitPrice units getPrice print display

Print Display

Figure 3-7. Composite class diagram

A sequence diagram is constructed by listing the objects as blocks across the top of the page with broken lines descending from each object. Bars are then drawn between the broken lines to represent method calls from one object to another. The front of the line represents the object that is calling the method, the arrow end of the line is the object that implements the method. Parameters may be included to help convey object flow, but are usually left off to simplify the diagram. Iteration is represented by an asterisk (*) preceding the method call. Figure 3-8 is a simple sequence diagram that implements the "Place Order" use case. See Figure 3-1 for the use case diagram and Figure 3-7 for the corresponding class diagram. The user interface begins by creating a new order, which causes the Order object to create a new Customer object. As each item is ordered, the User Interface object first creates the Item object, then uses the addltem method to insert it into the list inside the Order object. A comment is placed above the new method to indicate that this process will be repeated for each new item, and the asterisk (*) also indicates which methods are repeated.

59

60

Building Application Servers User Interface

Order

new()

Item

new()

w W

Places Order

Customer

»

for each item entered: * new() * addltem(item)

display() display() 1 findFirst() for each item in list: ^

I * item=getNext() * display(item) I

Figure 3-8. Sequence diagram

Once all new items are added, the user interface calls the Order object's display method which displays the entire order. When the display method is called, the Order object first calls the Customer object's display method, then calls its own findFirst method to locate the first item in the list. Note that the arrow for the findFirst and getNext methods turn back towards the Order object line. This indicates that the Order object is calling its own methods. Once findFirst points to the first item, getNext can retrieve each Item object in sequence and then call the Item's display method. This is repeated for each item. Once all items are displayed, the Order object's display method may display totals or other information,

Designing Application Servers

but since this is performed within the display method and does not require a separate method call, it is not shown on the sequence diagram. Use sequence diagrams to test how well an object design can perform a use case. Building a sequence diagram will often locate missing methods and clear up relationships between objects. As the diagram is built, make sure that there is a navigation path between the objects. In the above example, there is an aggregation relationship between the Order object and the Customer object. If this relationship did not exist, the Order would not be allowed to call the Customer's display method since the Order object could not reference the Customer object. As with all UML diagrams, the sequence diagram is time-consuming and can easily bog down in too much detail. The diagrams are tools to visualize and communicate, so do not expect to diagram the entire system. A lot of pretty pictures may look nice and put a smile on the auditor's face, but users want working software, not pretty pictures. Use the diagrams to rough out the design, and then let the programmers start writing code. As problems arise, use the diagrams to focus the discussion and revise and redraw them as needed. The emphasis should be on getting the code right, rather than the pictures. If pictures are needed, use the round-trip feature of the CASE tool to generate pictures once the code is finalized.

Meeting the End User's Needs It may be easy to get caught up in the technology, but the goal of application server design is to create information tools that meet the end user's needs. These people have a job to get done and they often do not share your enthusiasm for distributed objects, transaction servers, or message queues. They will, however, show their hostility if the transactions fail or the messages stop queuing. Make sure the technology selected supports both the software developer's and the end user's needs transparently. The JAD process will go a long way towards meeting this goal. Make sure the people who really know the application are involved with this team. These are the people who actually do the work; the supervisors are sometimes not familiar with the application. Get users on the team whenever possible. If this is not possible, make sure to get their input and let them review the use cases in which they are the actors. Also

61

62

Building Application Servers remember that these users have their own jobs to do; work with the company's supervisors to balance the users' time so they do not get behind in their own work. Remember that this is a business process that goes far beyond the Information Technology department. Also, make sure from the beginning to structure the project in such a way that changing requirements do not slow down or stop development. Just as new features are added incrementally, allow time for requirement changes to be implemented incrementally. In a recent interview, Grady Booch, one of the designers of UML, said: "Our view of the world is, we guarantee you won't get your analysis right. This is a given. Plan on it. You need a process that allows you to manage the risk of failure and incrementally improve your understanding of the world over time" (Zamir 1998).

Finally, throughout the project, try to keep things in perspective. There is more to life than software design. Using the JAD team approach will produce better software, but as with any team approach, time will be spent in compromising and resolving conflicts. Be willing to fight for and defend your ideas, but also be ready to compromise and listen to others. Keep the focus on building good software.

Summary Application server design is best approached as an iterative process, beginning with a simple concept, then adding refinements and extensions to meet all of the business needs. The following are some guidelines that can be used to approach application server design: • Form a joint application design QAD) team, consisting of both software developers and end users, that can work together through the life of the project. This approach keeps the project focused on the needs of the users. • Develop use cases that define interactions between the users and the application. • Design business objects that model the business entities and processes.

Designing Application Servers

• Use iterative development. Quickly build prototypes based on each use case then review them with the JAD team, refining them until they meet the needs of the users. • Make sure that all constraints are known before beginning design. Middleware and application integration issues can have serious implications on the way software is built. • The UML modeling language, a graphical notation for object oriented design, can greatly enhance conceptualization and communication. • Focus on meeting the needs of the business and the end users.

References Fowler, Martin, and Kendall Scott. UML Distilled. Reading, Massachusetts: Addison Wesley Longman, 1997. Zamir, Saba. "Interview with Grady Booch—Taking UML from Innovation to Usage." Component Strategies, August 1998: 15-20.

63

Chapter 4

Service Interface Design To those outside the application server team, an application server is just a set of services that support the user interface programs. The user interface collects data and then sends it to the application server, where the data is processed. Depending on the result, the application server returns either the requested data or an error message. The user interface programmers do not need to know how the service interface does its job— only that it works according to the specifications. This is the goal of a good service interface design. The implementation details should be irrelevant to those working with the services. The services are well defined and documented and the results are understood, but only the application server programmers need to know how the results are obtained. This chapter will examine how the service interfaces are designed, from use case analysis through design specifications. The topics covered will include: • What is a service interface? • Design by interface • More on JAD: developing use cases • Turning use cases into services • Building services out of business objects 65

66

Building Application Servers

What Is a Service Interface? A service interface is more than just a list of function calls specified by the user interface programmers. Each interface should contain a set of standardized services that not only make sense within the context of a single application, but conform to an organization's standard application architecture. This requires each service to conform to standard naming conventions and use consistent parameter-passing and exceptionhandling protocols. The user interface programmer should be able to take a new service interface and quickly and easily integrate it into an application with a minimum of research and testing. The advantage of utilizing interface design is that it has little to do with program code. An interface object does not contain any program code; it only specifies services and protocols. The interface object describes what can be done, not how it is implemented. As such, an interface is defined in documentation, not in program code. The documentation should specify each service, the task that the service will perform, the parameters passed to the service, what data or object is returned and any errors that may be passed back as exceptions. Figure 4-1 shows a sample format to document an interface definition. This form includes the name of the interface, a short one- or twosentence summary describing the purpose of the interface and a summary of each of the services. In addition to the overview, each service should be listed in detail, describing the function, the calling protocol, the return value, the parameters, and any exception handling. Optimally, this information will be stored in some form of interface repository accessible online with multiple search capabilities.

Design by Interface Designing a good service interface is a fairly straightforward process. Once use cases are developed, you can specify the forms, reports, and processes to support these requirements. The forms and reports become the basis for designing user interface programs, and the processes dictate the services that must be called by the user interface. Once you design the user interface, the service requirements will become readily apparent.

Service Interface Design

Loan Calculator Interface Definition Interface:

LoanCalc

Description: Loan calculation routines to determine monthly payment amounts and maximum loan amounts. Uses simple calculations for customer inquiries. Used by:

Customer inquiry Web page

Services: 1. getPayment—Calculate loan payment from principal, interest and years. 2. getPrincipal—Calculate maximum principal from monthly payment, interest and years. getPayment Protocol:

pmt = getPayment (prin, intr, years)

Returns:

Payment amount in dollars (double)

Parameters: prin—Principal amount in dollars (double) intr —Interest rate in percent (double, 6.5 = 6.5%) years—Time in years (double) Exceptions: Throws remote exceptions Returns 0 if intr or years = 0 Use cases:

Customer Loan Inquiry ...

Also in interfaces: ARMLoanCalc ... (repeats for getPrincipal service) ... Figure 4-1. Sample interface definition

67

68

Building Application Servers One of the primary advantages of design by services and interfaces is that the implementation can remain fairly abstract. At this point, the task is to determine the services needed, not how the services will be performed. Sketches of the user interface form will indicate the data items available; then the use cases will describe what actions must be performed using this data. When a user interface program receives a command request, a service request is passed on to the application server. These command requests make up the list of services that must be specified in the service interface. This list of services is now the starting point for the design of an integrated service interface. Because the same services are often required in more than one application, you can combine similar services into common groups shared by several applications. Once you define the services, you can then aggregate them into application-specific service interfaces.

More on JAD: Developing Use Cases A use case, in its simplest form, is a step-by-step description of how a person interacts with a computer. It explains the context of the interaction, i.e., why the person is performing this task and the steps involved from start to finish. It will also describe exception conditions and what happens when the exception occurs. It is written in business language, understandable by both the business users and the software developers. Ivar Jacobson, one of the codevelopers of UML, has advanced the concept of use cases as a foundation for software development (along with iterative development and tight version control). In an article in Component Strategies (Jacobson 1998) he shows how use cases can replace most requirements specifications, drive the design process, and be used to create test cases once programming is completed. By approaching requirements analysis within the context of job tasks, you isolate the most important features while minimizing all of the blue sky requirements that are not actually needed. You can then develop incrementally, building and refining a few use cases at a time. Once you've collected the complete set of use cases, they provide an easy-to-use, yet comprehensive, set of software specifications. The techniques involved in deriving use cases and gathering requirements are far beyond the scope of this book, and many good references are available (see Further Reading at the end of the chapter). Here are

Service Interface Design

some of the characteristics of good use cases that will aid in the development of application servers: • Describe the context • Describe the actors • Describe the procedure • Describe exceptions • Use common language • Iterate and refine

Describe the context As work becomes fragmented across an organization, employees sometimes lose focus and the reasons for doing a task sometimes become obscured. Managers look at the overall process without worrying about the details, while the employees perform detailed tasks without quite knowing how their actions fit into the process. This same problem can occur when approaching use cases. Without the context or big picture, important details may be omitted or ignored. Back in the days of mainframes, an employee at a managed care organization used to get a report once a month listing people who were within three months of reaching age 65. The employee would get out colored highlighters and color each line either pink, yellow or blue based on the birth date. She would spend three to four hours each month coloring the ten- to fifteen-page report. She even told her friends that this was one of her favorite jobs. As we were beginning to review Medicare processing for this organization, we found this job task and were somewhat surprised. The reason for all the coloring was that she was responsible for sending out three separate mailings to remind people to enroll in Medicare before their 65th birthday. This involved an initial mailing and two follow-up letters. By changing the sort order of this report by birth date (a change to a couple lines of a MARK IV program, an early database language), we eliminated a half day of coloring and manual sorting. When the report was originally created, an enhancement form was passed to a programmer asking for a report listing people approaching

69

70

Building Application Servers age 65 who were not enrolled in Medicare. Since the programmers were always backlogged, the report was quickly thrown together and passed back to the Medicare department. Had someone spent the time to investigate why the report was needed (the business context), countless hours of coloring and sorting could have been saved. In this example, an understanding of the underlying process would have revealed the need to order the report by letter type. In addition to process context, the business context and workflow context can also be helpful. Use cases examine individual job processes, but to understand these processes fully, developers need to know how the use cases relate to each other and how they relate to the way the company does business. Before they examine any use cases, the JAD team should discuss how the application fits into the overall structure of the business. In many cases this may appear obvious, but by spending a few minutes focusing on the "big picture," you can eliminate false assumptions before they cause problems. Discuss the role of the department, how it supports the overall business process, whether it directly supports the customer or whether it supports other business units, what products or services are delivered, and so on. Depending on the formality of the project, these functions may need to be documented. Once you've examined the business context, move on to how the application fits into this context. How does the application support the responsibilities of the department? If this is a workflow process, itemize the steps that are performed. Define the participants. Who initiates the task? Who performs the work? Are there additional people that must be contacted? Does the work pass from one person to another? Who receives the finished product? Examine what flow of information exists between steps, what questions are asked of the customer, and what documents are sent or received. Often, workflow analysis tools or flowcharts can be used to help document the process. Once this is drawn out, isolate the steps that will be performed by the new application; this will point you towards the use cases that need to be developed. Once the JAD team understands the context, it is much easier to begin to develop the individual use cases. Reference the workflow steps in the use case narratives and add a brief description at the beginning of each use case to describe how it fits into this overall flow.

Service Interface Design

Describe the actors Like the business context, knowing the people or actors who perform these activities will make the process much more understandable. Employees, customers, even external computer systems all have roles and responsibilities that either empower or limit the actions to be performed. Each employee has certain job domains, responsibilities, and authorities and can be expected to act within these constraints. Moving outside of these boundaries can cause serious problems. In addition to roles and responsibilities, each actor has to have some motivation for performing these tasks. In use case terminology, the actor must gain value from the use case. When the Medicare clerk colored the report, she gained value from the color coding because it helped her collate the letters. When a customer places an order on the Internet, she gains value from exchanging her money for merchandise and also gets the added premium of convenience. Whatever the motivation or value, this should be documented in the use case. Begin by isolating the actors and give them names to describe each one's role within the process. Mary may be the person who sends out the Medicare letters, so list Mary as the actor; but also describe her role as the letter collator. Once the actors are isolated, describe each actor's role in the use case and describe why each performs her job.

Describe the procedure Every use case needs to present a logical, sequential description of how the task is performed from start to finish. As the use case is first developed, this description may have some ambiguities and may miss some details, but as it is refined, these items can be clarified. As already stated, it is impossible to get it right the first time, but since everyone on the development team knows that this is an iterative process (keep reminding them), the initial use cases are still useful tools for software design, and the programmers can begin to develop the initial prototypes. As the prototypes begins to take shape, the JAD team must review them to ensure that they match the use case requirements. Step through the procedure with the prototype to test both the software and the procedures and revise both in parallel. It is important that the use cases reflect the procedures.

71

72

Building Application Servers The software developers will use the use cases as the basis for software requirements, program specifications and test plans, so if there are inaccuracies in the procedures, the software will not meet the business needs. When describing the procedure, itemize the steps in a sequential, logical manner. State who the actor is, each step performed, any decisions that have to be made, the source of each one's information, and so on. In the case of the Medicare letters, the steps may include how Mary requests the report, what information is included on the list, the criteria for each letter, who receives the letters and what messages are communicated, how Mary addresses the letters, and what the desired result of each letter will be.

Describe exceptions While developing the procedures, you may discover a variety of exception conditions. A customer may have insufficient credit to complete a purchase, or a network connection from San Francisco to Atlanta may not always be available. All common exceptions must be listed and procedures must specify how to handle these problems. The procedures and exceptions are the foundation for the business rules that will be coded into the software, so exceptions relating to each use case should be documented. Once the basic procedure is itemized, each step should be examined to determine where errors and exceptions may occur. Some exceptions may be trivial and may be annotated directly in the procedure. Others may be serious enough to warrant an extension that can be examined as a separate use case (the « e x t e n d s » notation in the UML use case diagram). Examine each exception to determine how it will impact the procedure narrative. Remember that it is impossible to anticipate all of the exceptions. Spending too much time in exception analysis will be counterproductive. It is important to specify only the common exceptions, since it is easy to overload a use case with rare and exotic problems that may never occur. Also, as new use cases are developed, the JAD team will discover exceptions that were not addressed in previous use cases. As these are found, determine if these errors could occur in other use cases, then revise those use cases to include the exceptions. Document exceptions as separate steps in the use case procedure. In the above example, Mary requests the report. Insert an additional step after this to have Mary check that the report printed. If it did not print,

Service Interface Design

have her consult the "Printer errors" use case that describes how to resolve a printer error. This would be a new use case that would extend any use case that creates a printed report.

Use common language The goal of the JAD process is to create software that solves business problems. There is always a tendency to get wrapped up in the technology, and soon even the business people involved in the JAD team will be speaking in acronyms and buzzwords. This is fine as long as it does not overrun the use case descriptions. A use case must define a business process, so use business terminology. The technical language belongs in the program code, not in the use cases. At the same time, make sure that the technical people understand the business language. Just as the business people will adopt technical terms without really understanding their meaning, the technical people will begin to use the business terminology without full comprehension of what these words mean in the business context. Often, a project glossary can help clarify both business and technical terms. Just be careful that developing the glossary does not overshadow the development of use cases.

Iterate and refine Again, there is no way that anyone can get the business requirements right the first time. Create the use cases based on what is currently known, then quickly create software that reflects the use cases. Review the software and use cases in parallel and continue to refine both. How many times have you heard a user say "I'll know what I want when I see it"? This may be frustrating to a developer, but without experience and training in software design, the end users do not have the knowledge base to envision their needs. A simple prototype will often solve this problem. With constant refinement comes the need for revision tracking and change management. Just making sure that everyone has the most current version of every use case may be a project in itself. You must address revision tracking early in the JAD process and establish procedures to ensure that everyone stays current. Revision tracking can also provide quick recovery when a revision has moved in the wrong direction.

73

74

Building Application Servers

A brief example To illustrate these principles, Figure 4-2 documents a sample use case for the Medicare report described throughout this section. The use case begins by describing the context, stating that Medicare requires each member who is approaching age 65 to apply for Medicare benefits. It then explains why the letters are needed, describes the value gained by both the company (and indirectly the person collating the letters) as well as the members, and specifies the procedure used to generate the report and the contents of each mailing. Next, the use case lists the actors as well as the value gained by each. The company receives a monthly payment from Medicare while the member has to pay a much lower premium. Next, the use case describes the procedure step by step, starting with how to request the report, followed by the steps used to select letters for each member. The use case also briefly mentions what happens to the letter when it is returned by the member, referencing the use case that describes this process in detail (this is part context, part procedure). Since the process is relatively straightforward, the only exception described occurs when a member has already passed their 65th birthday (code 0). Additional exceptions could be included to describe printer errors, but these can be handled through an extended use case that could be shared by any use case that performs printing functions. Notice, too, that the use case is written primarily in business language, understandable by the person performing the work. A use case can always be refined, and a couple of iterations would ensure that the use case follows the actual procedure. The first iteration would be a review by Mary and other people in the Medicare department. Since they perform the task, they will best know the procedures. Once this is done, it would be a good idea to spend some time discussing process improvement. If Mary is hand-addressing the envelopes, it may make sense to also print mailing labels or, depending on the volume, print the letters themselves in a format that can be easily stuffed into a window envelope. A quick check of the number of members who receive follow-up letters and calls could also determine how effective the letters are and if there is a need to revise them.

Service Interface Design

USE CASE Medicare Reminder Letters Within three months prior to each member's 65th birthday, the federal government requires that each member submits an application for Medicare coverage. Since our organization receives a substantial monthly payment to cover the member's benefits, it is to our advantage to do what we can to remind the members to fill out these forms. Since the member's premiums are also greatly reduced, it is to their advantage as well. At the beginning of each month, someone from the Medicare Services Department (usually Mary) requests the Members Approaching Age 65 report from the reports menu of the Medicare menu of the membership program. The report will list all members who are within three months of turning age 65 and who have not yet applied for Medicare. Each line is annotated with numbers 1, 2, or 3, indicating how many months until their 65th birthday. Members who have already turned 65 are annotated with 0. Depending on the number 1, 2, or 3, the member will receive a mailing that includes one of the following three letters as well as a membership application form. Members who are three months prior to age 65 will receive an initial letter stating the advantages of signing up for Medicare. Members annotated with a 2 (2 months before their 65th birthday) will receive a second notice reminding them to fill out the letter, emphasizing the reasons for submitting the form. Members annotated with the number 1 will receive a more harshly worded letter reminding them to submit the form. The few members annotated with 0 are contacted by phone to remind them that they must complete their application. Once the form is filled out by the member, it is mailed back to the Medicare Services department where it is entered into the computer, then forwarded to HCFA (Medicare). These steps are covered under the Receive Medicare Application use case.

Figure 4-2. Medicare Reminder Letters use case

75

76

Building Application Servers

Making use cases work A strong foundation of use cases will go a long ways towards good software development and make the JAD process effective and efficient. Start with the context, addressing both the business and the actors. Make sure everyone is speaking the same language, then define the procedures and exceptions. Constantly revise the use cases to reflect changes in both business requirements and to parallel the software prototypes. Continue to develop new use cases until they completely solve the business problem.

Turning Use Cases into Services Since each use case will describe an interaction between actors and the computer, the JAD team's next task is to design user interface screens. Interactions usually follow a pattern in which the user enters some information, requests a service, then receives a result or an exception. The JAD team must determine what data items are needed to perform each service request and how to prompt for these items. The team must also determine the actions that will trigger each request and specify the information displayed after the request occurs. Services can often be categorized as data retrieval, locating and displaying information; or as transactions, performing a series of data transformations. In both cases, the request is augmented with data that specifies or refines the scope of the request. A customer enters both a vendor and product name to request pricing and availability, or a bank teller enters a customer's account number and the amount before posting a deposit. The screen layout design specifies the service request options and the data used to define the request. The user interface designers must also specify the results and how they will be presented to the user. For transaction requests, a simple message box summarizing the actions performed lets the user know that the request completed successfully. For data retrieval operations, the specifications should list each data item, as well as the order of presentation when multiple items are selected. While considering the results of a retrieval, keep in mind that one retrieval request will often produce data that must be acted on, triggering a subsequent request. A request that looks up a customer by last

Service Interface Design

name will, in most cases, return more than one customer matching this last name, so the next step in the procedure will be to have the user select a specific customer. Once the use selects the correct customer, an additional retrieval request may occur, or a transaction may be posted against this customer's account. Each of these operations will invoke additional service requests. Once the user interface is specified, make a list of all of the required services specifying the input parameters from the user interface, the operations required, the results that must be returned, and a list of possible exception conditions. Although the descriptions should be written in business language, these are program specifications and some computer terminology will be required. While the use case is aimed at the business people, the interface design should be targeted towards the software developers. Also remember that interface design is not the place to worry about implementation details. The process should be specified in functional terms, describing the outcome of the service request, not the procedural details needed to produce the outcome. The service request at the beginning of the chapter (Figure 4-3) used to calculate the loan payments illustrates these concepts. The input parameters are the principle amount, the interest rate, and the length of the loan. The process is to calculate the monthly payment amount. The returned result is the monthly payment amount. Exceptions will occur when either the interest rate or the time period is zero. Notice that there is no description of how the calculation is made. The specific formula does not matter at this point, since the user interface's responsibility is only to provide the payment amount, given the information about the loan. Later, when it is time to specify the business objects, a loan calculator object will be specified that will include specific calculation formulas. In addition to specifying the input parameters, the process, the results, and the exceptions, services should follow a number of standards. These guidelines make services more accessible to user interface programmers and make design and coding easier for application server developers. By providing standardized names and parameter lists, user interface programmers do not need to spend as much time looking up and researching the services. At the same time, standardizing services will allow more consistency for the server-side developers. The following

77

78

Building Application Servers

getPayment Protocol:

pmt = getPayment (prin, intr, years)

Returns:

Payment amount in dollars (double)

Parameters: prin—Principal amount in dollars (double) intr—Interest rate in percent (double, 6.5 = 6.5%) years—Time in years (double) Exceptions: Throws remote exceptions Returns 0 if intr or years = 0 Use cases:

Customer Loan Inquiry...

Also in interfaces: ARMLoanCalc

Figure 4-3. getPayment Interface Specification

are a few guidelines when designing services: • The service is application-specific • The service is self-contained • The service handles all exceptions • The service hides the business object layer • The service conforms to standards

The service is application-specific While business objects are built for reuse, the services within an application's interface are intended to provide services for specific tasks within the context of one user interface screen or application. Although

Service Interface Design

reuse may sound appealing at this point, subtle differences may exist between the requirements of this service and a similar service in another module. Trying to force reuse during this phase of design may cause details to be ignored and result in complex, difficult-to-use interfaces. As you develop an order processing system, several use cases may indicate that a selection screen is required to locate an order. In the first use case, the customer calls and requests the status of his order. The customer service representative enters the customer's name or phone number and receives a list of orders that match this criteria. The resulting list includes the order number, customer name, phone number, sales content, and a brief indication of the order status, such as "received 9/15" or "shipped 9/25." A second use case may also require an order lookup screen, used by the sales representative to review a customer's purchases prior to a sales call. The sales representative will enter the customer's name or phone number along with the number of months of history desired. A summary list of orders will then be displayed showing the order date, the content and amount of the sale, and the sales representative's commission. It would be tempting to set up a generic getSalesOrders service that would return orders by customer, phone, date range, and order status and then provide all of the information to satisfy both requests. This service could also be extended to handle many other sales order requests by customer and eliminate a lot of server-side programming. The problem is that the requirements for the service become far too complex and changes made to accommodate sales representatives' inquiries may cause problems in order status lookup. Also, the generic service will produce at least twice as much network traffic as application-specific requests would generate. Although the same data tables may be retrieved using similar access paths, the data requirements and results have little in common.

The service is self-contained A service should be a single procedure call giving results that are generated from the data supplied in the parameter list. Services will be called by many different users concurrently, so the service cannot rely on data from prior service calls. By providing self-contained, often called stateless services, you eliminate the need to propagate separate instances of the

79

80

Building Application Servers object on other machines, tying up system resources or adding additional overhead to manage object life cycles. There will be times when this rule must be broken and a state-based service object will be needed, but these should be kept to a minimum. Life cycle and concurrency management can take far more resources than the application itself. Any additional overhead will result in slower response times and larger server requirements. In the order status inquiry example described above, a customer may ask follow-up questions after learning more about his order status. When a customer learns that his order was shipped two weeks ago, the customer may want to know which carrier was used, in order to determine why he has not received it. To follow up on this inquiry, the customer service representative will need to know the carrier and the tracking number. In designing this sequence of services, a stateless getShippinglnfo service must receive the customer and order number again before supplying the information. A state-based service can simply return the information based on the customer and order information retained from the getSalesOrder service request. In determining the best design for this service, the stateless version is almost always the better choice. A stateless service can be handled by a single service object, processing each request independently without having to retain data between calls. A state-based service will require a separate service object for each sales inquiry to retain information between service calls, creating the object at the beginning of the inquiry stream and then deleting it when the inquiry process is complete. This requires a much higher level of application server complexity to save a small bit of network bandwidth. Since the customer and order number are still on the user interface screen, the software will be much simpler if this data is simply sent back to the next service request.

The service handles all exceptions As I described above in "More on JAD: Developing Use Cases," all reasonable error conditions should be anticipated and procedures for exception handling should be specified. In addition to those described in the use case specification, exception handling should also be extended to software-specific problems. These will include testing input parameters for

Service Interface Design

bad data, checking for referential integrity and other similar issues. Each error unique to this service should be listed as possible exception results. The service interface specification is not the place to list every possible error condition. Many of the exceptions are common to all services, and a general purpose error handler can be specified to handle these errors. This is within the domain of programming standards, not service design. General error handling should include program faults, middleware exceptions, and network errors. Another issue that must be addressed in exception handling is the location of the error checking. Many simple checks can be made by the user interface programs. Empty fields, correct data formats and other local data checks can easily be performed by the user interface. Other checks that are within the domain of business rules, or to ensure referential integrity, such as verifying that a customer number exists in the customer database, must be done on the server side. Two exceptions to this rule are when a new object is created or an object's attributes are modified. In these cases, the service should always check the validity of the data being accepted because this data will be retained and bad data can cause subsequent errors. Once an error is detected by the service interface, a standardized process should be used to communicate the error back to the user interface program. Most programming languages, as well as middleware interface definition languages, provide standardized exception handling that can be used or extended. Once the error is thrown back to the user interface program, it must then be reported back to the user with sufficient prompting to let the user know what has gone wrong and how to fix it. Nothing is more aggravating to the users than getting an incomprehensible error message without any clues describing how to resolve it.

The service hides the business object layer Just as a well-designed object hides its attributes and protects them with get and set methods, a service should not allow business objects to be exposed outside the application server. It is tempting to pass objects directly to the user interface program, but by doing so, you permit the objects to be corrupted either by network errors or by malicious programmers. They may discover and call additional methods that may

81

82

Building Application Servers breach security, extend access authority, or violate business rules. Instead, you should use service-based container objects to pass parameters and results to application domain objects, which can then validate the data prior to altering business objects. In the inquiry screens above, another subsequent action may be to revise the customer information. The order status may indicate that the order could not be delivered because the address was incorrect. The customer service rep will request a delivery address correction. The data to be corrected comes directly from the customer object, so at first glance it makes sense to have the service pass a copy of the customer object to the update screen. Unfortunately, the customer object also has methods that set credit limits and discount rates. If the customer object is exposed directly, an unethical employee or an Internet hacker may be able to use features such as Java's object introspection to discover these methods and invoke them. A better alternative is to create a separate customer data object that only holds the data attributes. Instead of passing the entire customer object with its additional attributes and methods, a customer data object will only carry the data that is used within the customer update screen. An initial service called getCustomerData can retrieve the necessary data, load it into the customer data object, and send it to the user interface program. When all of the changes are made, the data can then be loaded back into the customer data object and the user interface program can call updateCustomerData to request that the changes be made. By using separate container objects, you hide the business objects inside the application server from the user interface program. You can validate the data items to prevent missing data or incorrect values from being placed inside the object, and isolate methods so they can only be accessed through service interface requests. This may add more work for you, the service interface programmer, but it also protects and secures the integrity of both the business objects and the company's data.

The service conforms to standards Early on, the design team should standardize naming conventions, parameter sequences, and exception handling, then make sure that these standards are enforced for all service definitions. Although the standards

Service Interface Design

can be difficult to adopt at first, once the developers adapt to them, programming becomes much easier because all calls conform to these standards. Services can be composed of a common set of verb-noun combinations, such as addCustomer or getPrincipal. Parameter lists can be ordered in similar manner, using container classes to encapsulate multiple data items entered on a screen. Results can also be encapsulated in container objects that conform to specific standards. Standards are often set by the middleware vendor, with service interfaces defined according to the vendor's interface definition language. In addition to these standards, most development groups have naming standards in place that can be adapted to address the needs of the application server environment. As an example, Microsoft shops often use some form of Hungarian notation for naming conventions. Do not put a lot of effort into standards, adapt those already in place or try to find standards that others have used successfully.

Bundling services into interfaces By packaging services into service interfaces, you enable a user interface programmer to access all necessary services by obtaining only one handle. This simplifies programming and lowers the overhead cost of accessing the application server. The service interface can then be viewed by the user interface programmer as a single object, providing a logical collection of application services. Once most or all of the services are defined for a use case, the services should be refined and documented in fairly detailed form. Before aggregating services into an interface, you should review of all the services, along with those services defined in earlier use cases, to locate duplicate services that perform the same basic functions. These can be examined to determine if they are candidates for reuse. Service reuse should not be forced when it is not appropriate, but many occasions for reuse will appear throughout the project. If standardized names and parameter passing are used, duplicates can be merged and shared. Once reuse analysis is complete, services are packaged into interfaces, aggregating services by user interface program, user capabilities, or applications. The scope of a service interface depends on the size of the project and can vary depending on the number of different user interface

83

84

Building Application Servers modules and the level of integration across different applications. A simple application server that has one or two user interface modules and has no interaction with other systems may only require a single service interface. A large, mission-critical application server that supports several departments or several locations may require separate service interfaces for each user interface application as well as additional interfaces to support system integration and external access. When determining the aggregation of service interfaces, remember that each service can be accessed from several interfaces using interface inheritance. Many user interface programs will need many of the same common services. Distributing these services across multiple interfaces will provide common functions to the programmers and promote software reuse across the project. At the same time, a service interface does not need to expose all of the services within a particular implementation. Use service interfaces to expose only the services needed. This feature can be used to limit access and enhance application security. Service interface packaging is a fairly simple, intuitive process. Since each user interface requires a certain set of services, start by specifying a separate service interface for each user interface. Once this is done, it will become apparent that some service interfaces share common services or a subset of another service interface. The services required by the customer inquiry program will be a subset of the customer maintenance service interface. When this is the case, the two service interfaces can be merged together or interface inheritance can be used to simplify the interface design. Do not spend a lot of time agonizing about how to distribute services within an interface, the proper distribution will occur naturally and intuitively.

Handling Errors and Exceptions One of the most critical pieces of the service interface design is how to handle errors and exceptions. C++, Java, Visual Basic, and IDL all provide standard mechanisms for exception handling and recovering from errors, but using these features requires some forethought and planning. Standardize message formats to make errors readable and understandable. Standardize program recovery so each service or object will react to errors in the same way. Establish standard error handlers incorporating

Service Interface Design

logging and alarms to notify the software developers when application errors occur. The primary goal of error handling is to isolate problems and provide suggestions to fix the errors. When an error condition occurs, the user must first be informed, then prompted to correct the problem. The message should be in language that makes sense to the user and suggests an action that will correct the problem. Most user frustration occurs when error messages do not make sense or are phrased in indecipherable technical terms or accusation language. These types of messages do not provide the information required to understand the problem or correct the error, and often intimidate the user. When developing error handling strategies, consider different approaches based on the source of the errors. The most common are user interface errors; these arise from incorrect keystrokes or undefined data. More difficult to handle are the application errors—those caused by software bugs, bad design assumptions, or corrupted data. Finally, those errors caused by system or network problems cannot be easily recovered by the user or programmer, but error handlers must be in place to prevent data corruption.

User interface errors The easiest and most common errors will occur when data is miskeyed or when items are entered that are unknown to the application. These errors will usually stop the application's processing and the user will be prompted to correct the problem. For unknown data, such as a new customer or a discontinued product, you should provide a cancel option to void the operation and start over. Standardize across an application the process of distributing error checking between the user interface program and the application services. In most cases, the user interface program can quickly check to ensure that required data is supplied and that entries conform to required patterns (for example, a Social Security number entered must contain 9 digits). You can also delegate other coding checks to the user interface program by populating pull-down or list boxes. Pass any other data validation to the application server. Each service should begin by checking for parameter errors before

85

86

Building Application Servers processing begins. Required parameters must not be empty and all parameters must conform to proper data types within specified ranges and conform to business rules. Referential integrity should also be checked at this time. If any errors occur, processing should stop, throwing an exception specifying the data item in error and the type of error that has occurred. It is then the responsibility of the user interface program to inform the user of the error and prompt for corrections. In those cases when a data exception occurs during processing, the transaction must be aborted and the data transformations must be rolled back to the state that existed prior to the request. Usually, you can use the transaction processing capabilities of the database to roll back changes. For more complex systems, you can add transaction middleware to insure data integrity.

Application errors While most user errors are caught and intercepted prior to processing, application errors can occur any time during the service request. These errors must be intercepted, logged, recovered when possible, and then the user must be informed that an error occurred. Much of this can be accomplished through exception handling processes provided by development tools, extended with application-specific, standardized error handling methods. When an application error occurs, the error handler will catch the error and divert program flow to an error-handling process. This can be a catch block in C++ or Java, or an On-Error label in Visual Basic. Once the exception occurs, a separate error handler should be called that logs the errors into an application error database, then locates and formats standardized error messages. Depending on the severity of the error, the application can either continue processing, display a message to the user, or raise an alarm that the software must be fixed immediately. Hopefully, few errors will cause alarms, but these should be built into the program to ensure that critical errors are corrected quickly before data can be corrupted or operations are stopped. For those errors that stop the application's processing but are not critical, the application should send an error message back to the user, informing him that processing did not complete, and then describe

Service Interface Design

what needs to be done to correct the error. As with any error that stops the application's processing, corrective measures must be in place to roll the data back to its state before the service request began.

System and network errors The most frustrating and difficult errors to recover are those that are outside of programmer control. Network failures, middleware problems, and computer crashes all have the capability to corrupt data. The errorhandling routines will catch the errors, but often, it is impossible to request rollbacks or do anything to recover the error. Much of the work in standardizing error handling revolves around these types of errors. When a network connection goes down, the user interface program will continue to run, but service requests will either fail or time out. When this occurs, the application must inform the user of the problem but must also assure the user that no data was corrupted. At the same time, the application must raise alarms to let the network administrator know that a problem has occurred so that network communication can be restored. Fortunately, the middleware products provide retry and recovery capabilities, and the programmer only has to handle the final failure message. Network administrators already have tools to monitor and manage the networks, and database vendors have built in rollback and recovery when system failures occur. Still, the application software must catch the errors and inform the users.

Exceptions and interface design Although the primary rule of interface design is to focus on services, not processes, determining interface exceptions does require some thought about the processes involved in performing the service. Procedures such as data validation and referential integrity must be considered while listing the possible exceptions. Even so, most of these can be considered in general terms and specified without a detailed knowledge of the implementation. Many of the exceptions will also be program-specific and cannot be known while specifying the service interface. By standardizing the error handling processes and providing a general purpose error handler, you can incorporate these errors without changes to the interface design.

87

88

Building Application Servers

Summary This chapter examined how to design use cases as well as how to use them to determine the services and interfaces provided by the application server. Use cases describe in procedural fashion how the users interact with the computer. Once these use cases are specified, user interfaces can be designed to support this interaction and service interfaces can be designed that describe how the user interfaces access services from the application server. • A service interface is a group of services that provide the functionality needed by one or more user interface programs. • Each service describes an action that can be requested by a user interface program, listing the data items that restrict the action as well as the results that are provided. • Service interface design focuses on what the services do, not how they do it. • When designing use cases, use the following rules: • Describe the context • Describe the actors • Describe the procedure • Describe exceptions • Use common language • Iterate and refine • When designing service interfaces, use the following guidelines: • The service is application-specific • The service is self-contained • The service handles all exceptions • The service hides the business object layer • The service conforms to standards

Service Interface Design

• Develop standardized error and exception handling procedures, passing messages back to the user that describe the problem as well as explain how to resolve it. • When application and system errors occur, make sure that data is not corrupted.

References Jacobson, Ivar. "Use Cases and Architecture in Objectory." Component Strategies, August 1998: 70-72.

Further Reading Interface Design Coad, Peter, and Mark Mayfield. Java Design-Building Better Apps and Applets. Upper Saddle River, New Jersey: Yourdon Press, 1997.

Use Cases Ambler, Scott W. The Object Primer: The Application Developer's Guide to Object-Orientation. Managing Object Technology Series, no. 3. New York: SIGS/Cambridge University Press, 1998. Jacobson, Ivar, Grady Booch, and James Rumbaugh. Unified Software Development Process. Object Technology Series. Reading, Massachusetts: Addison Wesley Longman, 1999. Schneider, Geri, Jason P. Winters, and Ivar Jacobson. Applying Use Cases: A Practical Guide. Object Technology Series. Reading, Massachusetts: Addison Wesley Longman, 1998.

89

Chapter 5

Designing Business Objects The goal of business object design is to create a collection of reusable software objects that model your business. While interface design is a bottom-up approach, used to determine application requirements, business object design is a top-down analysis of the entire business, identifying roles and functions. Business objects are formed by specifying properties and services that reflect the real-world objects they model. As with real-world objects, software objects often combine and collaborate to perform tasks that they cannot perform individually. Object design requires a global view of the organization, determining not only the needs of the current task, but the functions required for the entire business. Objects must be designed for reuse across both the current application and be ready for use in the next project, even if the project is for another department or a different line of business. Although not a simple task, it is not as difficult as it seems. Business objects mirror people, forms, and other objects that have already been integrated into the business. As such, when the objects simulate these functions, they also fit inside the same business context. The object designer cannot possibly know all of the business requirements, so designing all functionality from the beginning is an impossible task. Business requirements are constantly changing and today's needs may not be relevant tomorrow. Business objects must be designed as open, dynamic components that can easily be changed without impact on other functions. 91

92

Building Application Servers With all of these requirements, business object design is still a difficult task, but no more difficult than most other business functions. Business is a competitive, dynamic process that must be flexible and shift to constant market changes. Managing change is an important part of any successful organization, and business objects that mirror these functions must also be flexible and able to manage changing requirements. This chapter gives an overview of business object design as it relates to application server development. Topics include: • Moving from interfaces to objects • What exactly is a business object? • Finding the objects in your business • Designing the objects • Linking business objects to the service interface • Business object architecture

Moving from Interfaces to Objects Chapter 4 looked at how to design the service interfaces that provide functionality to user interface programs. One of the most important pieces of service interface design was to get a written description of the software requirements in a sequential, narrative form. These narratives (use cases) were developed jointly using a team of both business users and software developers to ensure that each case met the business needs. This chapter looks at how to deliver this functionality and, at the same time, design software objects that can be reused throughout the organization. Again, the information needed to design the objects is located in the use case documents. By defining the actors, objects and tasks, a comprehensive set of business objects can be defined.

From data models to business objects In traditional two-tiered client/server development, software design started with the data model. User interfaces and paper forms were examined to determine what data had to be stored; then a data model was

Designing Business Objects

designed that met the requirements. Once the data model was complete, the developers created the physical database and user interface programs that accessed and modified the database. All processes were embedded within the user interface programs. In object-oriented design, the emphasis shifts from a data-centric view to a business object view, creating a model in software that mirrors the activities of the organization. Data is encapsulated in objects that also contain the processes to manipulate the data. These objects then interact in the same way that business people interact, processing and transferring information between themselves. Object modeling looks similar to data modeling, but there are many subtle differences. Those who have spent years doing data modeling will find the transition difficult and confusing. Data structures are physical, persistent organizations of bits that sit on disk drives. Once the columns and tables are defined, they stay there as long as the database is in use. Objects are transient, dynamic, memory-resident entities with short life cycles. They are created, transformed and deleted in finite periods of time, sometimes within milliseconds. It takes experience and practice to really see the differences and adapt to the realities of object design.

Choosing a design approach Object design is an art, not a science. Every designer will look at the same problem and come up with a different object design. According to one source, there are at least 30 different object design methodologies and notations (Carmichael 1998), so, depending on training, background and personal preferences, each designer will approach the task in a different manner. Most likely, the reader has already been exposed to one or more of these design methodologies and has developed a personal approach that produces good software design. The techniques described here reflect my own personal approach and should be used to augment your own experience. Determining the business object layer of the application server is not much different than any other object-oriented (OO) design approach, since good software design spans all languages and architectures. As with other design topics in this book, the intent is to point towards practices that will produce efficient, flexible application server designs that meet

93

94

Building Application Servers the needs of the organization. For those not familiar with object-oriented design, there are many excellent references explaining and comparing the leading methodologies. See the list of Further Reading at the end of this chapter. In addition to design methodologies, there has been quite a bit of work done in the past few years on design patterns (Gamma et al. 1998). This is the concept that most software design elements can be classified into a collection of common patterns, tailored to meet specific business problems. By categorizing and documenting these patterns, people new to software design can gain the experience of previous designers and not have to reinvent these processes themselves. Experienced designers can also use these patterns to share design ideas and learn from each other. This text will present a variety of approaches, but will emphasize object design using the UML notation and an amalgam of several design methodologies. These combine use cases as defined by Ivar Jacobson, object-oriented design according to Grady Booch, and the traditional structured analysis and design of Coad and Yourdon. The goal is not to produce a unified design methodology (we can leave that to the UML guys), but to find tools and techniques that provide cost-effective solutions to meet the needs of the business quickly. Remember that the goal is to produce effective business software implemented as program code, not stacks of binders full of charts and pretty pictures.

What Exactly Is a Business Object? A business object, within the context of application server design, is a computer representation of a physical business entity. These entities can be physical objects such as business forms, inventory items, shipped products, or the trucks that carry them. They can be classes of people like customers, employees, loan processors, or even a single person like George Smith, the only guy in the company who can approve loan amounts over $10,000,000. A business object should almost always represent a physical object (or person) that can be seen or touched. A business object should also be defined in business terms. If computer terminology is needed to describe it, then the object needs further refinement or it may not be a proper candidate for inclusion as a business object. The design should also be understandable by everyone on

Designing Business Objects

the JAD team. This means that, in addition to lack of computer terminology, the business language should be simple enough to be understood by the computer people. Every group of people, whether technical- or business-oriented, uses terms and expressions that are only fully understood by those in the group. Since the JAD team is made up of both business and technical people, the language used in the specifications should be understandable by everyone on the team.

Finding the Objects in Your Business The first step in locating the objects from a use case is to determine who the actors are. Actors are usually people, business entities or other computer systems. The actors work with the objects to perform business tasks, adding value either for themselves or the business. Once the actors are located, it is often easy to determine their associated objects. Since this is a business simulation process, the actors also become objects, passing messages between themselves and manipulating the objects around them. A list of the actors and the objects they use becomes the starting point for the object model.

Objects vs. Classes Object-oriented technology distinguishes between objects and classes. An object is a specific instance, containing a set of data and the methods to process the data. A class is a generalized description of a group of objects that have the same data item(s) and method organization. In object-oriented programming, class definitions are created using the programming language, and then any number of specific objects can be created using the class definition. In this discussion of object design, the term object is used to denote both classes and objects. Although not technically correct, the word object is more effective in communicating the concept to those not familiar with object-oriented development. Also, the distinction between classes and specific objects is often not clear during the design phase, and keeping the terminology correct will get in the way of doing the design work.B

95

96

Building Application Servers In addition to the actors, many business objects will model physical objects and forms (including computer screens and computer-generated reports) currently used in the business. Billing forms, inventory items, raw materials, even the warehouse itself can exist in the computer as a business object. In addition to listing the actors, include any physical objects that may be relevant to the project. Throughout this chapter, a set of loan application use cases will be used to illustrate object design. The first use case is the loan application process summarized below. Loan Application: A customer wants to purchase a new home and has contacted our company to request a loan application. The customer service representative asks the customer to fill out a loan application. This application form requests information about the customer and the property that the customer wants to purchase, including the location and purchase price. The form also requests the customer's employer, monthly salary, other monthly bills, credit card information, bank accounts, and other financial information. After the customer fills out this form, the customer service representative enters the form into her computer. The computer assigns a loan number and makes a quick check to ensure that the information is complete, notifying the customer service representative if any problems are found. After the information is in the computer, the loan number is written on the form; then the form is forwarded to a loan processor.

In this first use case, the actors are the customer, customer service representative and loan processor. Possible objects include the property to be purchased, the financial information, bills, credit cards, bank accounts, and the loan application form. The employer may either be an actor or may just be an attribute of the customer or financial information, but, since little is known at this point, it will be added to the list of actors. Figure 5-1 summarizes the actors and objects derived from the first use case.

Designing Business Objects

Looking at the second use case helps to refine this list: Initial Loan Approval: For each loan application form, the loan processor first pulls up the loan application on the computer and selects the "create application documents" button. The computer generates a cover page that lists the loan number, customer name, address and phone, loan-to-debt ratios, and checkboxes for each approval requirement (credit report, appraisal, etc.). The computer also generates several verification letters for employers, banks, credit cards, and bills, each verifying the information submitted on the application. After these documents are printed, the loan processor checks the loan-to-debt ratios; then, if these ratios do not meet current requirements, the loan is rejected. Otherwise, a credit report is initiated by phone, the verification letters are put in the mail, and then all of the paper documents including cover page, loan application, and copies of the verification requests are placed in a paper file. As each of these verification forms return, they are entered into the computer, the cover page is annotated, then the form is placed in the file. When all verification forms have returned, the file is passed on to a loan officer who then approves or rejects the loan.

Actors

Objects

Customer Customer Representative Loan Processor Employer

Property Financial Information Bills Credit Cards Bank Accounts Loan Application Form

Figure 5-1. Actors and objects found in the first use case

97

98

Building Application Servers This use case is highly simplified, but still enables us to refine our list of actors and objects. The loan officer is added to the list of actors and the object list now expands to include a loan file, cover page, income verification, bank verification, and credit report. Adding these new items produces the list shown in Figure 5-2. This list will grow quickly, and many of the actors and objects will not be needed in the final model. Even so, starting with an exhaustive list will ensure that all of the objects are at least considered. Listing these items may also remind the designer of additional actors and objects that may have been specified in earlier use cases. Remember that this is an iterative process and that the design does not have to be complete or correct on the first pass. The list of objects, as well as the use cases and every other part of the design, will be corrected and refined as new information is discovered.

Defining the Objects Each business object begins with a name, such as those given in the first two use cases we've examined. The name should be something fairly Actors

Objects

Customer Customer Representative Loan Processor Employer

Property Financial Information Bills Credit Cards Bank Accounts Loan Application Form Loan File Cover Page Income Verification Bank Verification Credit Report

Figure 5-2. Actors and objects found in both use cases

Designing Business Objects

short, but still readable and comprehensible. A name such as Loan Application works well since it describes the object, yet is still fairly brief. The name LoanAppContainer may describe the same object, but it does not make sense to the business people. George Smith, as it was described above, would also be a poor choice for an object name since the realworld George Smith may later move to a different job function. The business people would understand who George is and what his position is, but the contract guy brought in to write the code will have no clue. Senior Loan Manager may be a better name. In addition to its name, each object should be defined in a short, oneparagraph narrative description, listing what the object represents along with its purpose and function. This must be written in business terms understandable by everyone on the JAD team and, just like the use cases, everyone should agree to the basic concepts laid out in this description. These object definitions will be changed and revised during development, but understanding the basic assumptions is critical to meeting the business requirements successfully. In the loan application example, the software designer now begins to look for potential business objects from the list of actors and objects. The easiest object to identify is the loan application object. This is a physical document that contains the information entered into the user interface and initiates the loan application process. The software developer begins by creating a simple narrative describing the Loan Application object: The Loan Application object contains all of the information received from the loan application form filled out by the customer. The object holds information about the customer, the property, and the customer's financial information: employer, bank accounts, credit cards, bills, and other sources of income. Once stored, the financial information can be summarized by monthly income, monthly payments, current assets, and current total debt.

This description is short and concise, describing the purpose of the object and its function within the software system. The description is most likely not complete, but gives enough information to communicate the basic idea to the rest of the JAD team. The object holds data and the data is grouped into several categories and subcategories: customer, property, and financial information. Once stored, the object has the capability to summarize information, giving aggregate totals.

99

100

Building Application Servers Although each item of the loan application form (his name, her name, address, employer name, monthly salary, etc.) could be listed individually, this would make for a large, unmanageable object with hundreds of attributes. Since the information is already described as a set of categories, it makes sense to turn each of these categories into a set of separate lower-level objects, then aggregate these objects together to form a higher-level business object: the Loan Application object. The following narratives describe each of these lower-level objects. Customer The customer object represents the customer who applies for the loan and lists his or her name, mailing address, phone numbers, Social Security number, and other relevant information.

Property The property object represents the residence or land that secures the loan and includes a short description of the property, a street address including city, state and zip, the legal property description, and the purchase price.

Employer An employer object describes the customer's place of work and level of income. It includes the name and address of the employer, the job position, the length of employment, and the monthly income.

Bank Account A bank account object lists the customer's bank account number, the name and address of the bank, the date the account was opened, and the current balance.

Additional object specifications are needed to describe the credit cards, bills, assets, and other sources of income that are listed on the application form. Each of these would be similar to the objects already specified, describing the other items listed on the loan application form. Note that at this point, the design looks a lot like a data model. There are few methods defined and each of the objects will be stored in persistent storage. As the design progresses, the objects will be enhanced with additional attributes and methods that act on these attributes.

Designing Business Objects

Designing the Objects Once the object descriptions are all written and revised, the software developers can begin to formalize the object definitions. This includes determining the following items for each object: • Attributes—what the object knows • Methods—what the object does • States—the changes that occur due to process flow • Events—responses to the outside world The object definitions should be annotated with these items. This will provide the beginnings of a detailed specification document. In addition, each object should be put into a UML diagram, since this helps summarize the information into small, tight representations of each object. Later, these diagrams will be transformed into a class diagram that represents the relationship between the objects—kind of like a blueprint for the structure of the business objects.

Attributes Attributes, often called properties or instance variables, are data items stored inside the object. Specifying the attributes may look similar to database design, but remember, these are transient items, not persistent data. The data items specified within the object provide storage between method calls. Much of the data may be passed on to the persistent object layer where it is stored in a relational database, but until then, each attribute is only a memory variable, placed there to provide functionality for the object. Each attribute should be described in both business and computer terms. In business terms, describe what each attribute represents, what its purpose is, where the data comes from and where it will be used. In computer terms, describe the data type and size. For lists and arrays, also indicate the minimum and maximum number of items. Specify enough detail to communicate the reason for the attribute, but do not get too detailed. There can be hundreds or thousands of attributes in the busi-

101

102

Building Application Servers ness object layer, and a detailed specification of all attributes could take thousands of pages. The purpose of the specification is to communicate design ideas, not to fill notebooks and kill trees.

Methods Methods are the functions and processes that give life to an object. Each method acts on the attributes stored within the object to either manipulate the attributes or communicate results to other objects. Methods can be thought of as messages sent to an object, either sending information to be saved for later use, requesting information that the object knows, or asking an object to perform a specific action. Methods are written in program code, but they represent messages and activities that the object has the ability to understand. Often it is difficult to determine the methods for each object early in the design process. Some methods will be apparent right away, but many can only be determined after the relationships are specified. Testing the use cases against the design will also reveal additional methods, so do not waste a lot of time trying to come up with an exhaustive list at this phase in the design. Methods also must be documented in the object specification, describing their function in business terms. Methods can be described either in terms of messages or actions. The verification received method is used to let the Loan Application object know that a verification document has been returned. When the message is received, the object locates the appropriate bank account, credit card, or other item and forwards the message on to this object. Other methods are requests to perform an action, such as getName that returns the name from a Customer object. Inputs and outputs should also be documented for each method. When the verification received message is sent to the Loan Application, the message must include which document was received, the VISA credit card or the employment verification. When the getName method is called, the method must return the customer's name. These must be described in business as well as computer terms.

Designing Business Objects

States As objects move through a series of processes, they may take on several different forms or states. Each state affects the behavior of the methods, and exceptions may occur when certain methods are requested when an object is not in the correct state. Each loan application object described above will move through the following states: • New—the loan application has been received but no action has been performed • In review—data is complete but not yet processed • In verification—waiting for verifications to be returned from banks and creditors • In approval—verification received, waiting for approval or rejection • Approved—loan application was approved • Rejected—loan application was rejected When the object is in different states, it will perform its actions in different manners. A loan application just submitted cannot be instantly approved, but it may be immediately rejected. A loan application that is awaiting verification likewise cannot be approved until the verification forms have returned. Once all verifications are back, the loan application moves to the awaiting approval state and can then be approved. Few objects move through state transitions, and those that do will be recognized early in the design. When an object does have several states, it is helpful to specify one or more methods that return the current state of the object. A state attribute within the object also helps to quickly identify the state of the object. In the loan application example, methods like isNew, isInReview, isInVerify, isInApproval, isApproved, and isRejected will simplify state checking. An alternative would be a getState method that returns an integer that represents a specific state value. In either case, a state attribute, set by the methods, can identify the current state of the object. When describing the object, include a detailed description of the possible object states. Describe what triggers a state change, and how the object's attributes change as the state changes occur. Document the

103

104

Building Application Servers methods that can be used to determine the present state of the object and describe any state attributes that are used by the object to track the current state. Also, document the methods that behave differently depending on the state of the object noting how state affects these methods, and list state-related exceptions that may occur.

Events Events are external occurrences that cause objects to react, either by a state change, by triggering a method, or by sending messages to other objects. In the application server environment, events are most often related to state transitions. In our loan example, receiving a credit verification may cause the Loan Application object to change states from "in verification" to "in approval" if all other verifications have been received. A Loan Approval event will move the object from "in approval" to "loan approved" state. Events are represented in a varieties of ways. Often, the event will be represented as a message sent from the service interface to an object using an "event occurred" message. In the loan application example, the loan officer will click a button indicating that the loan was approved. This will cause the user interface to call the Loan Approved service from the service interface, which then calls the Loan Approved method of the Loan Application object. Another approach is to encapsulate the event itself into an object. This event object is passed to the business objects that need to know that the event occurred. An example of this would be a "credit verification received" message. The information from the verification form would be entered and stored in a Verification object. This object would be passed to the Loan Application object by calling a Loan Approved method. The Loan Application object will respond to this message by locating the corresponding Bill or Credit Card object, then send a "verification received" message along with the Verification object (see Figure 5-3). Event handling can be generalized even more by creating a "handle event" method, then passing all of the event objects to every business object within the hierarchy. The "credit verification received" message would be passed to the Loan Application object, where it would be checked to determine if any response was needed. Once this response is complete, the event would be passed to every Employer, Bank Account, and Credit Card object in turn. Each would check the event to determine if it need-

Designing Business Objects

Loan Application Verification Received

Verification Received

Figure 5-3. Passing an event between objects

ed to respond. Since this event was intended for a specific credit card, the Credit Card object would be the only object to respond to the event.

Business object specifications As the object analysis continues, the object descriptions should be updated to include descriptions of attributes, methods, states, and events. This does not have to be comprehensive, but should contain enough information to communicate the design concepts and goals to both the business and technical people. Figure 5-4 shows an example of the Bank Account object specification. Do not spend too much time creating these specifications. Simply list the items that seem appropriate and keep the process moving. These are still rough drafts and will be updated as the project moves along. Consider one of the object-oriented CASE tools if the project is large. These tools make finding and managing large collections of objects much easier.

105

106

Building Application Servers

Object Specifications Object Name: Bank Account Description: A bank account object lists the customer's bank account number, the name and address of the bank, the date the account was opened and the current balance. Attributes: Bank Name—the name of the bank Bank Address—the mailing address for the bank Bank Account—the account number for this account Current Balance—the account balance on or near the application date Verification Sent—date that the verification form was sent Verification Received—date that the verification form was returned Verified—yes/no, indication that the account exists Methods: Send Verification—sets the Verification Sent date and returns the Bank name, address and account number Receive Verification—sets the verification received date and the account verified indicator is New—returns yes if no verification has been sent is Sent—returns yes if verification has been sent but has not received is Verified—returns yes if verification has been received and account exists is Rejected—returns yes if verification has been received but account does not exist States: New—Verification not sent Sent—Verification sent but not yet returned Verified—Verification has returned and account exists Rejected—Verification has returned but account does not exist Events: Verification Sent—the form is sent to the bank Verification Received—the form is returned by the bank and indicates if the account exists or not. Figure 5-4. Bank Account object specification

Designing Business Objects

Object Interaction For an object to do useful work, it must communicate and interact with other objects. The Bank Account object specified above has a method that sends a verification letter. As it gathers the data to send the letter, it knows the bank name and address and it knows the account number. A verification letter could be sent out at this point, but there is no way to verify that the account is owned by the customer who has applied for the loan. The customer could have written down someone else's account number; then, if an account exists, the verification would pass. What the bank really wants to know is if this customer has an account at this bank. To make this work correctly, the Bank Account object must have some form of interaction or communication with the Customer object that was submitted on the loan application. Once this connection is established, the letter can include the name and address of the customer. Without these connections and communication paths, the objects will not have the information necessary to perform useful work. Objects communicate through a variety of methods and relationships. Some objects are aggregated to form larger objects, and this new higher-level business object provides the communication paths between the objects. Other objects have a looser relation, knowing each other through association, but are not as tightly coupled as when they are aggregated. Quite often, objects will be brought together into collections, pulling together similar objects into a common group where they can be sorted and compared. Object relations are most easily documented using UML diagrams. A few class diagrams can quickly summarize the relations and communicate the design concepts to both the programmers and business people. Once the relations are determined, sequence diagrams can be created that describe each use case using these objects and relations. Creating the sequence diagrams will quickly locate missing methods and test object relationships.

Aggregation The simplest and easiest object relation is aggregation, when several lowlevel objects are combined to create a new higher-level business object.

107

108

Building Application Servers This new object uses each of the lower level objects as instance variables (attributes) in the same manner as it would if these objects were dates or strings. These new attributes are then used within the higher-level object's methods to perform business functions that simulate real world processes. Since the lower-level objects are now attributes of the higher-level business object, the low-level object is encapsulated, or hidden, within the new business object. This makes the low-level objects accessible only to the business object, hidden from access except through the aggregated object. This protects the low-level objects from corruption, but it also restricts the design when other objects need to access the object independently. The specification for the Loan Application object states that it contains information about the customer, property, and financial information. This could be represented as an aggregation. A Customer object, a Property object, and a Financial Information object could all be aggregated into the Loan Application object (see Figure 5-5).

Loan Application Loan Amount Approve Reject

Customer Name Addres Work Phone Home Phone

Property Short Description Legal Description Address Purchase Price

Figure 5-5. Aggregated Loan Application object

Financial Information Name Address Phone Contact

Designing Business Objects

This new Loan Application object now has the responsibility to manage the Customer, Property, and Financial Information objects. The only access to each of the lower-level objects is through Loan Application methods. As long as all the work involving the customer or property resides inside the Loan Application object, this is acceptable, but if the customer can have multiple loan applications or the property needs to be tracked separately, this may be a problem. In the loan application example, this is not a problem since the customer and property are part of the loan application form. Later on, after the loan has been approved, the Loan Application object can give up its customer and property information to create true Customer and Property objects that stand separate from the loan. Until then, the customer embedded in the Loan Application object is not a true customer, since a rejection of the application will terminate business with the customer. It would probably make more sense to call the object an applicant instead of a customer, but for this example, the term customer is easier to understand.

Generalization and specialization The Customer and Property objects fit well within an aggregation relationship, but there is no Financial Information object included in the specification. The financial information referenced in the loan application specification is a set of objects that include bank accounts, credit cards, bills, and employers. Each has some similar information that includes a name, address, phone number, and a monthly amount that either adds or subtracts from the customer's cash flow. All but the Employer object has an account number and an amount that contributes to the customer's net worth. One of the foundations of object-oriented technology is the concept of inheritance or specialization. A generalized, or parent, object is defined that specifies the attributes and methods that all objects have in common. Specialized objects can then be created that inherit these attributes and methods. Within these new objects, methods are either replaced or added to give new functionality, and additional attributes are added to support these new methods. Although generalization and inheritance look like a great opportunity to share code, this should be avoided. Inheritance should be restricted to likeminded objects, each representing a more specialized subset of its parent.

109

no

Building Application Servers Otherwise, a change to a parent object not well related to a derived object may cause failures when the other object expects the original functionality. Inheritance should be used sparingly in business object construction, since derived objects are tightly bound to their parents. Often, aggregation or association is a much better choice, putting the needed functionality inside the object instead of inheriting it (Coad and Mayfield 1997). The financial information example does show a situation where inheritance is appropriate. Figure 5-6 shows the hierarchy for the financial information objects. The parent object, called Verification, holds the common attributes and methods for all of the financial information objects. The name Verification was selected to indicate that the primary function of these objects is to send and receive verifications for all of the

Employer Hire Date Monthly Salary Verification Name Address Phone Verification Sent Verification Received Verified Send Verification Receive Verification is New is Sent is Verified is Rejected

Send Verification

Bank Account Date Opened Current Balance Send Verification

Credit Card Current Balance Monthly Payment Send Verification

Figure 5-6. Financial Information object hierarchy

Loan Application Loan Amount Send Verification

Designing Business Objects

financial information. Attributes for the Verification object include a name, address, phone, the date the verification was sent, the date when it returns, and an indicator of a positive or negative verification. Methods include Send Verification, Receive Verification, and a set of state

indicators representing each state the object may be in. Note that the Verification object is never used by itself; it is just there to allow other objects to derive their functionality from this object or class. The Employer, Bank Account, and Credit Card objects are all derived

from the Verification object. Each of these objects inherit the methods and attributes from the Verification object, so each object also has a name and address attribute and the Send Verification and Receive Verification

methods. Each derived object also adds attributes and methods unique to its own requirements. The Employer needs to know the date the employee was hired and the monthly salary. The Bank Account object needs to know when the account was opened and the current balance. Since each object now has its own attributes in addition to the ones derived from the Verification object, and each verification letter will be worded in a different manner, each object will also have to replace the Send Verification method with a new method that performs the appropriate action. When a verification is sent to the employer, the letter must request employment information including the hire date and monthly salary reported on the loan application. When sent to a credit card company, the letter must request credit information including the total balance and monthly payments. The same is true for every derived object, so each must implement its own Send Verification method to handle these differences. Since each derived object has to implement its own Send Verification method, the Verification object would not even have to implement the method. This is an example of a virtual method. By specifying the method in the parent object, you force each derived object to implement the method using the same name and force consistency between the methods. Most object-oriented languages allow a virtual method to be declared, but not implemented, in the parent object. While the Send Verification method is declared virtual and implemented in every object, the Receive Verification method is only implemented for the parent object. It performs the same operations for all of the objects. When a verification letter is returned, the method updates the verification received and the verified attributes. The Receive

111

112

Building Application Servers Verification method does not have to act on additional information like hire date or credit card balance, and does not have to perform different functions based on the type of financial information; so it can be implemented in the parent object, inherited by each derived object. Finally, the Installment Loan object is derived from the Credit Card object. This allows the Installment Loan object to inherit all of the functionality of the Credit Card object, but also carry an initial loan amount. Again, the Installment Loan object must implement its own Send Verification method, since it carries additional information, but it can inherit the Receive Verification and state methods. Inheritance is a powerful feature of object-oriented design, but it should be used only when objects have a relationship that can be summarized as a "this is like a...but" relationship. In this example, an Installment Loan is like a Credit Card, but it has an initial loan amount. If this "kind of" relationship can be stated, inheritance is a good choice for the object relationship.

Association In the aggregation example, the Customer object was aggregated into the Loan Application object. Suppose a customer could have more than one loan application in process at the same time (not likely, but it makes a good example). If this were the case, a loan officer would have a difficult time locating all of the applications for one customer, since every loan application would have to be checked. In this case, the Customer object should be independent of the Loan Application objects, but a relationship must still exist to know which loan applications are associated with each customer. Where aggregation put one object inside another object, association lets each object stand on its own, but it also allows each object to know about the other object. Instead of embedding one object in the other, each object has a pointer or reference to the other object. This can be done using a unique identifier, such as a customer number or a loan application number, or by using an object pointer or reference such as a memory address or C++ pointers. No matter how the reference is implemented, the object has a communication path to the other object. This association can be one-way or two-way, and can be one-to-one or one-to-many (see Figure 5-7). A one-way association is a relation where object A knows about B, but B does not know about A. In a two-way rela-

Designing Business Objects

B

A One Way Association

Two Way Association

LJ_

E

D

c

1

One to One Association

1..*

H

One to Many Association

Figure 5-7. Types of association

tion, both objects know about each other. Likewise, in a one-to-one association, each object E is associated with only one object F. In a one-tomany association, one object G is associated with many object Hs. In the loan application example, each Loan Application object is associated with at least one Employer object. This can be specified as a one-way relationship, since each Loan Application must communicate with the Employer objects, but access will never be required independently from the Employer back to the Loan Application. In the same way, the association is one-to-many, since each Loan Application may have one or more Employers. Associations are the most common object relationships since each object stands on its own but has communication paths with other objects. As more objects and relationships are specified, each object will have a number of relationships. The primary goal in determining relationships is to make sure that each object can communicate with every object with which it will have to interact. An object cannot call another object's methods unless that object has access to the other object through some form of relation. At the same time, associations should not be specified unless there is a need for communication, since each association does create additional overhead and programming effort.

113

114

Building Application Servers

Collections Where the other relations connect objects of different types, a collection is a grouping of objects either from the same class, or from objects derived through inheritance from the same class. Collections often form one side of the one-to-many associations or are aggregated inside another object. Collections can also be formed from primitive types, such as strings or integers; but for this discussion on class relationships, only collections of classes will be considered. Most object-oriented programming languages provide a variety of collections including arrays, vectors, lists, maps, and other, more complex data structures. Each allows a set of objects with a common base class to be inserted or deleted from the list, then, depending on the type of list, allows access sequentially from top to bottom or by an identifying value. In the loan application example, each Loan Application will have a collection of Verification objects (see Figure 5-8). These objects can include Employers, Bank Accounts, Credit Cards, or Loans. Since each loan applica-

Figure 5-8. The loan verification list

Designing Business Objects

tion will have a different number of each type of verification objects, a collection is an excellent method for handling this relation. Once the Verification objects are stored in the collection, the Loan Application object can determine the total monthly income and total monthly payments by accessing each object, checking whether it is an employer or bill, then accumulating the totals for each. Likewise, total assets and total debt can be accumulated in a similar manner.

Creating the class diagram The final class diagram shows the relations between all of the objects needed to meet the requirements of the use cases. Figure 5-9 shows all of the relations described throughout this section. This diagram forms a blueprint of the business object layer. Later, the persistence and interface objects will be added. Once completed, this diagram becomes the roadmap for the software designers and a communication tool to use with the business people.

Loan Application

Verification 1..*

Employer

Bank Account

Credit Card

Installmen Loan

Figure 5-9. Loan application business object layer

115

116

Building Application Servers

Application Server Issues and Constraints When designing business objects for an application server, you must consider additional issues and constraints. Some are business constraints, such as short development cycles and the ability to reuse objects from one development cycle to the next. Others are technical issues, such as handling concurrent processing and setting up object repositories. Each of these factors constrain the choices available as the business object layer is designed.

Short business cycles Years ago, the standard development cycle was measured in man-years. Business processes were relatively stable, requirements were set at the beginning of the project, and development moved at a leisurely pace (at least that's the myth that everyone seems to remember). Today, business requirements change quickly and software must be flexible, open, and configurable. At the same time, development cycles must be shortened to meet these rapidly changing business demands. Business objects must also be able to change and reshape themselves quickly and efficiently. When determining functionality, the object must implement the current requirements and also be ready to meet future needs. This is not as difficult as it seems. Most business processes evolve and, as such, the methods to implement these processes are extensions of the current functionality. The business members of the design team will usually have some idea of where their processes are moving, and upper management should have long term strategies in place and understand the market needs (if they don't, start looking for another job). Once these trends are determined, make sure that the object design will accommodate these changes easily, but also make sure that the system meets the current needs first. The short business cycles complicate the software requirements, but also tighten the development schedule. Balancing the need for flexibility and quick delivery is a difficult task.

Designing Business Objects

Reuse Reuse has long been one of the holy grails of software development. The model of the integrated circuit is often cited to illustrate how prepackaged designs can be reused over and over again. Unfortunately, reuse has seldom been effective in the business programming environment and, when it finally is achieved, the cost savings will never be as large as everyone assumes. Often we forget that software reuse is already happening on a large scale within every organization. The Windows or Mac operating systems are huge repositories of reusable software. Every program written relies on these reusable functions for a large portion of the work being done. Programming languages also rely on large sets of software libraries and application frameworks like MFC to provide faster software development. Finally, component frameworks like Visual Basic and JavaBeans also have a growing base of reusable components. Imagine the costs of having to reinvent these basic software building blocks every time a new application had to be built. The reason that these forms of reuse are so effective is that each has a wide range of uses. A Visual Basic list box can be used in any program that needs to present a set of options; the printer services in Windows are used constantly to send data to the printers. In each case, the function is something that is widely needed, so it is cost-effective to write a very customizable, general-purpose function. In the case of Windows, millions of dollars can be spent to develop these reusable functions because they can be sold to every PC user in the world. In the case of business software reuse, these economies of scale do not exist. Within the business programming environment, object reuse has just as many costs as it does benefits. Objects must be designed to have a much wider breadth than when they are written for one specific use. Repositories and documentation must be kept up to date and be quickly accessible to the programmers. Often it takes more time to locate and research how to use a reusable object then it does to rewrite it from scratch. Change management is also far more difficult when a single object is being used in a variety of different applications. To make software reuse effective, Paul Bassett suggests that a development group must have its process, infrastructure, and culture oriented

117

118

Building Application Servers towards reuse (Bassett 1999). An application server architecture provides some of the process and infrastructure, but culture is something that must be built over a long period of time. Process The application server design process is one of creating business objects that are models of business entities and processes. These are created within the context of an application, but are not intended to be application-specific. If these objects are designed correctly, they will be just as effective for the next application as they were for the current development effort. Additional functionality may be required, but the core processes will not change.

Infrastructure In addition to the application server environment, additional pieces must be in place to support reuse. These include object repositories, upto-date documentation, coding standards, and development tools that support reuse. During both design and programming phases, the developers must be able to quickly retrieve information about the business objects already in place and be able to incorporate them into their design. Reusing an object has to be easier than redesigning the same object. This can only happen when the information and objects are standardized, easy to access, and easy to use. Culture Reorienting culture towards reuse is difficult and can only occur over a much longer period of time. Most discussions of reuse include incentives and rewards to move the culture towards reuse; but rewards must be based on metrics, and metrics are difficult to determine when trying to encourage reuse. When reuse is first addressed, there is no code base or prior experience in place, so it is difficult to determine how reusable a particular object or piece of code will be. Also, the culture is already oriented towards other values such as meeting the user's needs within tight schedules. The pressure to get the project out the door will override the need to spend time making the objects reusable.

Designing Business Objects

Reorienting the culture towards reuse will be a multi-phased process. In the first stage, enforcing naming conventions, standardizing documentation, and building an object repository will begin to lay a foundation for reuse. In the next phase, the foundation for reuse will begin to appear, but current cultural pressures like technical elegance and customer service will cause conflicts and "culture clash" that will be difficult to resolve. Finally, as the process and infrastructure mature, reuse will become easier and will enhance instead of conflict with these other cultural pressures. Only then will reuse succeed.

Concurrency and synchronization One of the difficulties of the application server architecture is how to manage concurrency, accessing the same objects at the same time. In some cases, the same object may be accessed concurrently by hundreds of other processes. In other cases, each of these same processes may spawn a host of unique objects, resulting in thousands of objects active at the same time. Remember, too, that this is happening over a network of computers, not just one computer. Tracking and synchronizing all of these objects can become a nightmare. Fortunately, this is the job middleware is designed to perform. It can keep track of all of these objects and route messages between them transparent to all other programs. Or can it? The middleware may do the job, but it is much easier to design an efficient business object layer than it is to wait and hope that the middleware can handle the load. Efficiency and throughput come from good design, not software tuning. Minimizing the number of objects will help minimize the load placed on the hardware, and minimizing network traffic will increase throughput. Locating and eliminating bottlenecks during design is far easier than waiting until the users complain about slow response time.

Repositories In addition to concurrency and synchronization, many middleware products also provide repositories that allow objects to be stored and retrieved in a structured, organized manner. There are also a variety of

119

120

Building Application Servers other commercial repositories that work alongside the middleware architecture to perform this same task. No matter which repository is chosen, it will place restrictions on the form objects take and the way objects are built. Although much of this is technical in nature, it does affect and restrict object design choices. Many repositories and middleware packages require objects to conform to a specific component form. Some, like the JavaBean specification, have little impact on object design. Others, like ActiveX, require very tight naming requirements and a host of additional interfaces and functions that restrict the implementation of the objects. If you don't know these restrictions at design time, programming can become very difficult.

Persistence Although persistence is the topic of the next chapter, it also impacts the design of the business object layer. Data is almost always stored in relational databases, and, just like middleware and repositories, database management software will work better if the data is accessed in a manner that is consistent with the rules of the relational databases. As objects are aggregated and relationships are formed between objects, these relationships will determine how data is retrieved. Very few organizations do not use relational databases. Many of these databases have existed for a long period of time and may not have the most efficient, logical designs. These structures may have migrated from legacy systems, or tradeoffs were made to gain efficiency from older, more primitive database systems. The data may exist in denormalized forms or may make no logical sense whatsoever. Just as there is bad code and bad software, there are also a lot of bad databases out there. Knowing how this data is organized leads to more compatible object design and will help in the long-term success of the project.

Linking Business Objects to the Service Interface The business object layer is a collection of business objects, each modeling a part of the business in software. It is the responsibility of the service

Designing Business Objects

interface to link these objects together to perform useful work. Chapter 4 examined how to determine the functions and services provided by the service interface. Now that the business objects are available, they can be attached to the service interface to perform the services. The UML sequence diagram is one of the best tools for determining how the business objects will perform the services specified by the service interface. Each service is diagrammed, showing the connection between the objects and what method calls are needed to perform the service. This exercise will often reveal problems with the object relationships and quickly locate methods that have not been specified. Again, do not sequence every service; just do enough to prove the object design.

Developing sequence diagrams When developing sequence diagrams, begin with the application service interface object. This will be placed at the top left of the diagram, followed by the business objects needed to perform the services. Next, list the services down the left side of the page in the approximate order the user interface will call them. For each service, start with the service interface object and decide how it will communicate with the first business object. In most cases, it must either create a new instance of the object or use the persistence layer to create the object from the relational database. Once this link is established, each additional object must also have a similar communication path. Once the communication paths have been established, the service interface object will send a message to the business object to perform one of the object's methods. This object will then do the steps listed in the method, calling methods from other objects. Each of these method calls is indicated by an arrow from the calling object to the called object. To make the diagram readable, the objects should be ordered in approximately the same order as the sequence of method calls. The service interface requests a method from object A, which then requests methods from objects B and C, and so on. The easiest way to see how a sequence diagram is constructed is to go back to the loan application example and begin to lay out the services that will be required to accomplish the use cases. Figure 5-10 is a sequence diagram that illustrates how to enter a new loan application. The service interface object is where each process begins. The user interface program will request a method from the service interface, then

121

122

Building Application Servers Service Interface

: Customer

: Loan Application

: Property

: Employer

: Bank Account

: Credit Card

new

Create Loan Application

new n

1 1

m

L

J

n,

Add Employer

-

Add BEink Account

1 1 1

I

add verificaticjn (

new add verilicaticjn (bank

)

!

1 Add Credit Card

nev add verification credit

Send Verification Letters

send

i

•send

)

•se id "send

r

)

I

'V

1

Figure 5-10. Sequence diagram for loan application entry

the service interface establishes the links between objects before calling methods that implement the service.

Creating new business objects The first task is to initiate a new loan application (create loan application). The service interface uses the new operator to create a new Loan Application object, then the information from the user interface screen is passed through the service interface into this new object. Once the new

Designing Business Objects

Loan Application object is created, the Loan Application constructor creates Customer and Property objects and passes the relevant information to each of these new objects. There is a large amount of data required to create these objects, but the data can be encapsulated into a data structure to limit the number of parameters that must be passed between objects. Once the loan application is entered, the loan processor will also have to enter the employer, bank accounts, credit cards, and bills. Since there may be multiple instances of each, the user interface program is set up to add these separately. Each of these functions is listed on the sequence diagram, using the service interface to manage the work. For each of these functions, the service interface first creates a new instance of the Employer, Bank Account, or Credit Card object. Once the object is created, the add verification method is called to insert the new object into the Loan Application object's collection.

Implementing services After all of the information is entered into the computer, the operator can send a request to print the verification letters. The user interface will request the send verification letters service from the service interface. This request will be passed on to the Loan Application object, which will find each Verification object and request that it print its letter. This will continue for each Employee, Bank Account, or Credit Card. Notice the asterisk before each send method; this is the notation for a repeated operation. When the verification letters return, each must be logged into the computer to indicate whether the data was verified. These services can be generalized into a common receive verification report method (see Figure 5-11). The processor first locates the loan application and specific employee, bank, or credit card, then clicks a button indicating that the verification has been returned. This calls a service that sends the same message to the Loan Application object. The Loan Application object locates the corresponding Verification object and calls its "verification received" message. While creating this sequence diagram, it was apparent there were several problems with the object design. There is a broad assumption that the user interface and service interface can locate loan applications. This may be true, but there is no collection object specified to track the Loan Application objects and no services specified to perform this task (this was omitted to simplify the illustration).

123

124

Building Application Servers : Loan Application

Service Interface

Receive Verification Report

: Verification

receive verification I find verification (

receive verification (i

V Check Application Status

check approval ( I *is verified ( is verified = false, *is rejected (

T I

u get monthly income ( f get monthly bills ( get total assets ( M get total debt (

approve ( Approve

Reject

V reject (

V

Figure 5-11. Receive verification and loan approval

Designing Business Objects

Another problem found by this service was that there are methods to add and delete Verification objects, but there were no navigation methods specified. Methods like find first, find next, find by key, and others will be needed to provide access to the Verification objects. Laying out the association between the Loan Application object and the Verification objects is easy, but remembering to add all of the methods to support the relationship is often more difficult. The sequence diagram makes these omissions easy to find. Figure 5-11 also shows the sequence required to check a loan application for approval. It checks that all verifications have been received and approved, then returns the result back to the user interface program. At that time, the loan officer can approve or deny the loan.

Business Object Architecture Depending on the number of objects and the volume of activity, you have a number of choices for how the business object layer can be distributed and accessed. This is not really a design issue, but the consideration does affect how the business object layer is designed. The goal is to maximize throughput by keeping related objects close together with a minimum of network and system overhead. At the same time, the architecture must be flexible and allow for growth and redistribution of objects over multiple servers as the system demands increase. Often, the best choice is to use middleware to bind the service interface to the high-level business objects, then place all objects with relations onto the same machine and link them together into tightly integrated program modules. These high-level business objects then become the partitions where object groups can be distributed as resources begin to fill up. Other partitions may be by geographical location or by business function. As the design progresses, these logical boundaries will become apparent and the objects can be distributed accordingly.

125

126

Building Application Servers

Summary Business object design is a difficult, complex topic that cannot possibly be covered in sufficient depth in one chapter. Use the guidelines listed here as a framework for additional study using the Further Reading list at the end of this chapter. Some guidelines to follow include: • A business object is a computer representation of a physical business entity. • Approach business object design from the bottom up, selecting relevant actors and objects that participate in the use cases. • Begin with a written narrative of the objects in business terms, describing each object's role and activities. • As the objects begin to take shape, augment the description with the following characteristics: • Attributes—what the object knows • Methods—what the object does • States—the changes that occur due to process flow • Events—responses to the outside world • Use class diagrams to define relations between the objects. These relations include aggregation, generalization, and association. Collections can also be useful when aggregating or associating many similar objects. • When designing business objects in an application server environment, remember that reuse, concurrency, synchronization, repositories, and persistence all add further restrictions and constraints. • Use sequence diagrams to outline how the service interface will use the business objects to perform its services.

Designing Business Objects

References Bassett, Paul. "Is Reuse a Transient Issue?" Component Strategies, January 1999: 64. Carmichael, Andy, et al. Developing Business Objects. New York: Cambridge University Press, 1998. Coad, Peter, and Mark Mayfield. Java Design—Building Better Apps & Applets. Upper Saddle River, New Jersey: Prentice Hall, 1997. Gamma, Erich, Richard Helms, Ralph Johnson, and John Vlissedes. Design Patterns—Elements of Reusable Object-Oriented Software. Reading, Massachusetts: Addison Wesley Longman, 1998.

Further Reading Booch, Grady. Object-Oriented Analysis and Design With Applications. Reading, Massachusetts: Addison Wesley Longman, 1994. Fowler, Martin, and Kendall Scott. UML Distilled. Reading, Massachusetts: Addison Wesley Longman, 1997. Jacobson, Ivar, Grady Booch, and James Rumbaugh. Unified Software Development Process. Object Technology Series. Reading, Massachusetts: Addison Wesley Longman, 1999. Liberty, Jesse. Beginning Object Oriented Analysis and Design. Chicago, Illinois: WROX Press Ltd., 1998.

127

Chapter 6

Designing the Persistent Object Layer Just as the service interface layer connects the application server to user interface programs, the persistent object layer connects the application server to databases, object stores, and other external applications. Once the business objects perform the processes requested by the service interface, the resulting data must be stored for later use. The persistent object layer routes this data to relational databases or other forms of long-term storage. In the business environment, data is most often stored in relational databases. Although there are other persistence alternatives, such as object database management systems (ODBMS) that directly store and retrieve objects, these are products that are just now starting to move into the mainstream. Relational database is a mature technology that has been refined over 25 years, and business data processing relies heavily on this technology. For the application server to fit into the business environment effectively, the persistence layer must bridge application server objects with the relational data model. A number of methods can be used to implement persistent objects, and many of these will be explored in this chapter. Depending on the size and scope of the application server project, these methods can range from a simple set of collections, each representing similar business objects, all the way to a comprehensive persistence service that acts as an object broker, handling persistence, life cycle, and directory services for the entire application server. When data integrity is an important requirement, transaction objects can also be created that sit between the 129

130

Building Application Servers business objects and the persistent layer. The design choices are almost endless. This chapter will explore the considerations and constraints necessary to design the persistence layer of the application server. We will examine the following topics: • The role of the persistence layer • Relational database principles • Designing a persistent object layer • Using object-oriented databases • Using objects to represent external systems

The Role of the Persistence Layer The persistent object layer is a group of low-level objects and collections that retrieve and store business objects from relational databases, data warehouses, bulk storage devices, or external applications. When a business object is needed, the persistence layer must first locate the data or attributes of the object, then create a new instance using the data retrieved. For this to occur, the persistent objects must know both the structure of the particular business object and the structure and location of the data. This requires a large number of special-purpose objects that bridge the business object layer and the storage devices. A good way to understand the role of the persistent object layer is to step through the process of retrieving and updating an invoice. A customer service representative enters invoice number 1234 into a user interface program, which then sends a "get invoice" request to the service interface. The service interface must locate the invoice object for invoice 1234 and send all relevant information back to the user interface program when the invoice object for this number cannot be located among the business objects currently in memory. To get the invoice object back into memory on the application server, the service interface must first send a request to a persistent object to create an invoice object for invoice number 1234. The persistence service requests the information for the specific invoice from the database server.

Designing the Persistent Object Layer

It then creates a new invoice object that encapsulates this information. Once this is complete, a reference to the invoice object is sent back to the service interface, which can request the methods from the invoice object. Invoice object 1234 is now back in memory. After the service representative enters the changes to the invoice, the user interface program sends the invoice data back to the service interface in the form of an "update invoice" request. The service interface then calls invoice object 1234's methods to update the data. Once the invoice object is updated, it must be sent back to the persistence layer, where its data can be stored into the database. If the invoice object is no longer needed, it is deleted. Now suppose, in the midst of this process, someone else wants to look at the same invoice. It would be convenient if the persistence layer could simply create a second object representing the same invoice, then send this information to the second computer screen. This will not work, however, since the second object would not know about changes that have been made by the customer service representative. Instead, the persistence layer must return a reference to the same invoice object so the data displayed remains consistent for both users. Since there are now two separate processes using the same invoice object, life cycle management becomes an important issue. When the customer service representative saves the changes to the invoice, the invoice must be sent back to the persistent layer to store the changes; but it must also remain in memory until the second user no longer needs the object. Once the second user is finished, the object representing invoice 1234 can be removed from memory. As the example illustrates, the persistence layer has many complex tasks, including object creation and tracking, database communication, concurrency, life cycle management, and garbage collection. Notice that many of these functions are the same as those provided by most distributed object middleware. Life cycle management can track object creation, concurrent usage, and garbage collection. Locating specific object instances is the function of naming and directory services, and synchronization can be handled by transaction services. The only piece missing is access to the database.

131

132

Building Application Servers

Relational Database Principles The relational database is a mature technology that has become the foundation of most business data processing. Because of its maturity (note that The Relational Model of Data, by E. F. Codd, was first drafted in 1969), there are a wide variety of relational database products that all conform to a set of unified industry standards (Date 1998). Database vendors compete in a mature market with products that are highly optimized, secure, and reliable, and sold at competitive prices. For large volumes of data, it would be difficult to build a business case for using anything other than a relational database. Since relational databases are common and most developers are familiar with the technology, this brief overview will concentrate on the basics of the data model and how it relates to object-oriented software design. For those not familiar with relational databases, see the references at the end of the chapter.

Database history The relational data model was originally developed in the early 1970s as an alternative to traditional file-oriented data processing. At that time, most processing was done in batch mode, merging changes punched on paper cards with large "master files" often stored on magnetic tape, since disk space was prohibitively expensive. Once the merges were completed, the information was distributed throughout the company using paper reports that often consumed several cases of paper. As online systems began to appear, it was apparent that the information had to be organized in a form that was easier to access. A variety of database models began to appear that organized information into more efficient, logical structures. The advantage of the database was that all of the company's data was now stored in a few logical structures. A customer's name was now stored in one location that kept data consistent between applications. Data was also accessible randomly, by multiple key values, without having to read the entire file. Instead of running long batch updates, data could now be updated online so changes could appear immediately throughout the company.

Designing the Persistent Object Layer

133

The relational data model The foundation of the relational data model is the concept that data can be broken into sets of small, independent tables (much like a large spreadsheet) each representing a set of related information. Each instance of data in the table is represented as a row of data items, while the columns separate all rows consistently by attribute type. In object terms, each row is an instance of an object of type table, with each column storing a specific attribute. Figure 6-1 illustrates a simple customer table listing a customer number, first name, last name, address, city, state, zip, and phone number. Any set of information can be organized into similar tables. As additional tables are created, the number of attributes can be minimized by replacing redundant information with a reference to another table using a unique identifier common to both tables (such as a customer ID). This reduces the amount of redundant data stored in the database and provides a navigable network of relations between the tables. Figure 6-2 illustrates a simple relationship between an invoice table and the customer table. The invoice table carries a unique identifier (the invoice number) followed by attributes listing the customer, the order date, and the total amount. Each customer can have multiple invoices, but there is no need to store the customer name, address, or phone number in each invoice, since they can be quickly retrieved from the customer table. In relational terminology, this is called a join operation.

Last Name Smith

Address

City

State

Zip

Phone

1001

First Name John

1234 S. Main

Denver

CO

80101

123-1234

1002

Fred

Jones

1500 Lincoln

Denver

CO

80101

123-1111

1003

Mary

Lamb

110 Main

New York

NY

10001

111-1111

Customer

Figure 6-1. Simple customer table

134

Building Application Servers

Invoices

Customers Customer 1001

First Name John

Last Name Smith

Invoice

Order Date Customer Amount

90001

06/15/1999

1001

$5,325.47

90002

06/17/1999

1001

$5,100.00

1002

Fred

Jones

90003

06/17/1999

1002

$742.69

1003

Mary

Lamb

90004

06/18/1999

1003

$3,750.00

90005

06/20/1999

1003

$2,949.95

90006

06/22/1999

1003

$1,000.00

Figure 6-2. Relation between customer and invoice tables

Structured query language (SQL) Over time the Structured Query Language (SQL) has emerged as the standard tool to access and manipulate the information in relational tables. This language provides a standard set of commands to store, update, delete, retrieve, and aggregate data. Information from one or more tables can be retrieved using the select command which then creates a temporary table based on the criteria in the command. The SQL command: SELECT customer, first_name, last_name, address. city, state, zip, phone FROM Customers WHERE state = "CO" gives a sales representative a list of customers to contact when he makes his monthly sales trip to Colorado. The resulting table is shown in Figure 6-3.

Designing the Persistent Object Layer

135

Last Name Smith

Address

City

State

Zip

Phone

1001

First Name John

1234 S. Main

Denver

CO

80101

123-1234

1002

Fred

Jones

1500 Lincoln

Denver

CO

80101 123-1111

Customer

Figure 6-3. Customers who live in Colorado

Data can also be joined using a similar SQL command: SELECT invoice, order_date, customer, first_name, last_name FROM invoices, customers WHERE invoices.customer = customers.customer AND order_date >= '06/17/1999' AND order_date <= '06/20/1999' which will show the name of customers who placed orders between June 17th and June 20th of 1999. This produces the table shown in Figure 6-4. In addition to selects and joins, the SQL language provides commands

Invoice

Order Date Customer

90002

06/17/1999

90003

First Name

Last Name

1001

John

Smith

06/17/1999

1002

Fred

Jones

90004

06/18/1999

1003

Mary

Lamb

90005

06/20/1999

1003

Mary

Lamb

Figure 6-4. Results of table join

136

Building Application Servers to add, modify and delete table entries, create, modify and delete table structures, and optimize data access by specifying index and sort sequences. Depending on the implementation, some relational database packages also provide functions to check references between tables, raising errors when, for example, a customer is added to an invoice that cannot be found in the customer table. Other extensions include stored procedures that can precompile frequently used processes and triggers that automatically call stored procedures when data is added to or deleted from a table. Relational databases are powerful tools optimized to manage large quantities of data.

Database middleware One of the earliest applications of middleware was to connect diverse platforms and programming languages to database servers. In the early days before middleware, databases were usually accessed through a set of simple API calls from COBOL or other languages. Some vendors included preprocessors that translated language extensions into API calls to make programming easier and the code more readable. As time went on, SQL became the standard language of data access, replacing the proprietary command languages of the APIs and preprocessors. Finally, as client/server became more common, database middleware had to take over network chores as well as provide access to the database server. In addition to accessing the databases, this middleware had to marshal data into different data representations for a variety of development platforms and provide network services to transfer data between machines. Today many database middleware choices are available. Although there are still some vendor-specific middleware implementations, most vendors have moved to a number of common industry standards. On the desktop platforms, ODBC (open database connectivity) is the most common, although Microsoft is moving towards Data Access Objects (DAO, formerly ADO) using their COM component model to encapsulate database functionality. In the Java world, JDBC (Java database connectivity) is now the most common database middleware choice. All of these standards are based on SQL, passing commands as text strings and then receiving the resulting data set as an array of data. These middleware APIs are not difficult to use, but there is little reason to work

Designing the Persistent Object Layer

even at this level, since most programming tools provide their own support for database access. These tools provide frameworks that encapsulate database access and wizards that automatically generate the objects that represent queries, tables and result sets. Most C++ development tools provide wizards to build database objects while visual development environments like Microsoft Visual Basic and Inprise's C++Builder and JBuilder all come with drag-and-drop components that encapsulate database objects. If these are not sufficient there are also third party tools that provide similar enhanced functionality.

Designing a Persistent Object Layer The persistence layer must recreate objects from relational data whenever an object is needed. It must also keep track of the objects once they are created so that these objects are not duplicated and data remains consistent. When attributes change, the relational data must be updated to reflect the changes; then, when the objects are no longer needed, they must be removed to optimize memory. If this were all that the persistence layer had to perform, it would be easy to create a simple general-purpose tool that loads and stores objects. Much of this functionality does exist in most middleware frameworks. Unfortunately, the persistence layer must also understand the structure of the business objects and how each object relates to the database structure. It is this requirement that complicates the task of building the persistence layer and requires a customized solution for each application server. A simple solution would be to implement persistence within each object. This is an acceptable option for small applications with a limited number of classes and object instances. The problem is that each object now has the added overhead of persistence, which, as the number of objects grows, quickly eats up system resources. Also, the application server must still implement some type of application-wide directory service to locate specific instances of each object. This is why a separate layer with a separate set of objects and services must be implemented to serve up and track all of the business objects. Business objects are then not cluttered with extraneous persistence overhead. They can be located and retrieved by a single service request, even when they are stored offline in the database. This layer can also synchronize

137

138

Building Application Servers the objects with their database representations and distribute objects across multiple machines as system resources begin to diminish.

Persistence layer example To get a feeling for the requirements and design tradeoffs that must be addressed, this section will describe a simple persistence service that serves up customer objects. The customers can be from almost any business application, each having a customer identifier, name, address, city, state, zip code, and phone number. In addition to the customer objects, the corporate database also contains a customer table with all of this information plus other information not relevant to this application. Figure 6-5 shows a class diagram showing the classes used to implement the customer object server. The Customer Server object interfaces with the service interface or other business objects when any persistence service is needed. To load a Customer object, the find method is called to locate and return a reference to a specific Customer object. The service interface can make any changes needed to the Customer object by using the Customer object's methods. When the service no longer needs the object, the release method is called to store the data back into the database and release memory if there are no other references in use. Methods are also available to create new instances of the Customer object and to delete both the objects and their database entries. There are two other objects that support the Customer Server object, both representing collections of customers. The Customer Collection object holds references to the Customer objects in memory while the Customer Table object provides access to the customer entries in the database. Both have similar methods (find, add, and delete) to manage the collections. The Customer Table, which relies on the database server to manage the collection of objects, also has an update method to post changes to the database. The find method of the Customer Server object (the server) is called by passing the customer ID number to specify which customer is needed. The first step is to call the find method of the Customer Collection object (the collection) to see if this Customer object is already in memory. If it is, the reference counter is incremented and the Customer object reference is returned. If the customer is not in memory, the find method of

Designing the Persistent Object Layer Customer

Customer Collection refCount find add delete

0..*

customer name address city state zip phone

Customer Table customer name address city state zip phone find add update delete

Figure 6-5. Customer object server

the Customer Table object (the table) is called. If the entry is found in the database, a new Customer object is created and initialized with the information from the table. This object is then added to the collection, the reference counter is incremented, and the reference is returned. If the customer is not in the database, an exception is returned. When the service no longer needs the Customer object, it must call the release method to indicate that it has finished using the object. The release method will decrement the reference counter, then call the update method of the table object to post the changes back to the database. If the reference counter is zero, the Customer object is deleted from the collection and removed from memory. New Customer objects can be built using the server's create method. The service interface creates the Customer object, then the create method

139

140

Building Application Servers adds the new customer to the database. If the customer is already on file, an exception is raised. Once the customer information is stored, there is no reason to place the Customer object in the collection, since processing of the customer record is already complete. A more difficult task is deleting a Customer object. This can only be done if the reference is held exclusively by one user, since deletion by one process will cause program errors when the second process tries to access a now-nonexistent object. Once the reference count is verified, the object is removed from the collection and the entry is deleted from the table. The design shown above is simplified, but still illustrates many of the issues that must be considered when designing the persistence layer. There is always more than one class of objects used throughout the application, and many of these objects are complex objects formed by aggregation and association. Creating and locating objects will never be as easy as what was described above. At the same time, database structures seldom match the object structures, so loading and storing objects can be a difficult task.

Generalized object servers One major design problem is managing the creation of new business objects. Few objects stand on their own and most rely on aggregation, association, and inheritance to perform useful work. Depending on the business object design, some objects aggregated into one object structure may stand alone in another set of relations. While a property object may be aggregated into a loan application, it may also be part of a collection in the property management portion of the application. These relations must be considered when creating and managing objects in the persistence layer. The first step is to generalize the object server to handle a variety of classes. Instead of having a large number of different object servers managing each individual object class, one object server can serve up a variety of classes. This can be done by tying together many object servers or by generalizing a single object server to handle a variety of object classes. Figure 6-6 shows how several servers can be combined using a frontend object server to route the requests to the appropriate object server. This is effective when there are a limited number of independent object classes with only one or two complex objects.

Designing the Persistent Object Layer

Ubject Server

Collect. A

Class A

Collect. B

Class B

Server B Table B

Collect. C

Class C

Figure 6-6. Horizontally structured object server

Figure 6-7 shows another alternative using inheritance to consolidate the object servers, collections, and table classes together. This approach requires that all of the collections and tables implement the same methods and that all business objects are derived from a common parent that can be referenced in the collection. Most object frameworks, including Java's standard class library and Microsoft's Foundation Classes (MFC), provide a base class that can be used as a parent to all of the business objects. The more difficult issue occurs when complex business objects are created from lower-level objects. Although the high-level objects are handled as independent objects, the low-level objects encapsulated within these business objects must also be handled independently, since each can be used concurrently in any number of different objects. When the service interface requests an invoice, the invoice may aggregate a Customer object

141

142

Building Application Servers

Collect. A

Class

Class A

Table

Class C

Class B Table C

Table B

Figure 6-7. Inheritance-based object server

and a Sales Rep object, while associations exist with several order items that associate with their corresponding product items. Most likely, a second invoice accessed by another user will also associate the same sales representative and associate several of the same product items. These associations are not a problem, since they are loosely held relations that are not directly integrated into the Invoice object. Each can be created independently with references used to represent the associations. The difficulty lies in the aggregations, since these are encapsulated in the Invoice object and not exposed outside of a specific Invoice object. There are a couple of options for solving this problem. The first is to re-evaluate the business object design and change aggregations to associations. If this is not possible, a second option is to handle them as independent attributes of the larger object, not as shared objects. Changes made would then not be recognized by the other processes until the higher-level business object is released and the attributes are

Designing the Persistent Object Layer

stored back into the database. This simplifies object management, but slows down communication of changes, because the database is now responsible for tracking them. The first option should be used when data has a large number of changes that must be propagated throughout the system; the second option should be used for more static, informational data like names and descriptions. When the object server receives a request to find or create a complex object, the server must break down the request and call additional find requests to locate each lower-level object. Once each object is found, its references can be assembled into the complex object and, as changes occur to any lower-level object, they will be instantly reflected to other objects that reference the same instances.

Tracking the objects Once all of these objects are created, they must be tracked in some form of collection so they can be located and referenced quickly when other services need them. Several design decisions and tradeoffs must be considered when structuring these object collections, including the number and organization of each collection, the structure of the collection, and how objects can be organized and indexed to locate them quickly. Most programming environments have several collection classes that can be used to store references to objects. As each new object is created, it will have a reference pointer that can be shared between the collection, the service interfaces and any other number of business objects floating around the application server. Objects can be structured as lists, tables, maps, or other data structures. Selecting the best data structure will be determined by the number of objects stored, the need to access objects either sequentially or randomly, and the number of different access paths needed to locate the objects quickly. In the case of most business objects, the object server will have to locate each object by both object class and a unique identifier, such as customer number 1234 (class Customer, unique identifier 1234). Within the MFC architecture, there is a collection called MapStringToObject that implements an indexed list. A data structure similar to this often provides the fastest access, because the class name and the identifier can be aggregated to form a character string that then acts as the access key to

143

144

Building Application Servers each specific object. This string is then hashed to provide quick access to the associated object. As the object collection grows, another option is to distribute the objects using distributed object middleware. The naming service can then be used to locate each object by class name and identifier. The middleware can take over much of the object server role. There are some tradeoffs with this approach, since the middleware will require more system overhead and it will increase network traffic. At the same time, the application server gains scalability and additional servers can be added as the application server continues to grow. Using this approach, the only programming task remaining is mapping the objects to the relational database.

Objects and relational databases In the quest to move to object-oriented software development, there has always been the nagging problem of how to match object technology to relational data. The trade literature talks of the incompatibilities, or, in object-speak, the impedance mismatches between the two technologies. To some extent, this is a valid issue. Relational databases rely on small, independent, flat, two-dimensional tables, while object technology provides a wealth of complex data structures and object relations. Flattening these structures into two-dimensional data representations, then later reassembling the flat data back into these multi-dimensional objects can be a difficult task. When creating a purely object-oriented application, persistence is a nasty side issue you must consider, since the objects must be reloaded when the application stops and starts. Mapping this type of an application to relational data can be a very difficult task. In the business-oriented application server environment, this mismatch is usually not as difficult, since the application is oriented more towards data management and the relational data probably existed long before the application server was designed. This design may not have been based on the relational model, but the forms and business processes that drive the application were originally based on some previous form of the current data model. This limits the mismatch and will make interfacing between objects and relational data much easier to handle.

Designing the Persistent Object Layer

Objects from databases In most cases, the relational data to create the objects will be well established. This is both a blessing and a curse. Since the data is already there, there is no need to design table structures to support the objects. Unfortunately, the data is often structured in a way that is not compatible with the object design and, in the case of older, legacy systems may be in very strange haphazard forms, requiring access to a number of different data sources to retrieve the information needed to create one specific object. As shown in our simple object server above, each business object has a corresponding table object that represents the data as it is stored in relational form. Often the source of each object's data does not reside in a single table, but is accessible by one or more SQL commands that can locate, join, and retrieve the data. Once the data is located, it can be combined to form a new instance of the requested business object. After the object is no longer needed, the object is released. This operation calls the update method of the table object, which unloads the data from the object and updates the appropriate information using one or more SQL commands. The delete command also acts in a similar manner, deleting the data from the database that was represented by the object. Examining the process used to retrieve an invoice will illustrate the complexities involved in retrieving data and creating complex objects. Figure 6-8 shows a simple data model of the tables that hold the invoice information. The figure uses a variant of the entity-relation notation (as created by Sybase's Star Designer product), with each table represented as a box listing the table name at the top, followed by the data items contained in each table. Primary keys are underlined and relationships are indicated as lines drawn from one table to another, annotated by the item relations. See C. J. Date's Introduction to Database Systems for more information on database design and modeling notation. The primary table is the Invoice table. The primary key is the invoice number, followed by a customer number, shipping information, order date, and other related items. The relation between the Invoice table and the Customer table can be used to retrieve the customer's name, address, and other demographics, using the customer number to join the two tables. For each order, there are a number of order items, indexed by the invoice number combined with a sequence number (line 1, 2, 3, etc.), that include the

145

146

Building Application Servers Invoices

Order Items

invoice

invoice

customer

invoice = invoice

sequence

ship_contact

product

ship_address

quantity

Products product product =;product description shipping_weight

unit_price

ship_city ship_state ship_zip_code

customer = customer

order_date

Customers

ship_date shipping_weight

customer

shipping_charge salesjax discount totaLbilled

name address city

Customer Classes

state zip_code phone class

class = I class

class description standard credit limit

Figure 6-8. Database design for invoice example

product number and the quantity ordered. To obtain information about the product by product number, the relationship between the order items, and the Products table, can be used to access the description, shipping weight and other information. Note that this database design is simplified, limiting the number of items and tables within the database. Given this existing database structure, it makes sense to design the objects to reflect their corresponding database structures. An Invoice object can encapsulate most of the same information as the Invoice table. The same will be true of customers, order items and products. Figure 6-9 shows a compatible object design that reflects the relational database structure. In the Invoice object there are some slight differences from the Invoice table. The Invoice table has a couple of poor design choices that must be addressed in the object design. The shipping weight and the total billed items can both be derived from the order items and products table, so

Designing the Persistent Object Layer

Invoices invoice shipName shipAddress shipCity shipState shipZip orderDate shippingWeight shippingCharge salesTax discount totalBilled

Order Items Products

1..*

sequence product quantity description shippingWeight unitPrice totalPrice

product description shippingWeight unitPrice

Customers customer name address city state zipCode phone class

CustomerClasses class description creditLimil

classDescription

Figure 6-9. Object designfromInvoice database

these are redundant fields and there is a possibility of incorrect data if these are not computed correctly. These have been replaced by methods that calculate the correct amounts. A good case could also be argued that the shipping charge, sales tax, and discount in the order items should be placed in the order entry table, since these are line items on the invoice. Depending on the specific application, treating them as line items could create a cleaner design and simplify programming. Nevertheless, the Invoice object retains this design choice, keeping the shipping charge, sales tax and discount in the Invoice object. Also, since the customer is now aggregated into the Invoice object, there is no reason to carry the customer number inside the Invoice object. There are many reasons for poor database design. Sometimes they are just that, poor design choices, in which case they should be ignored and the object should be designed independent of the database design. In other cases, there are deficiencies in the database software that have to

147

148

Building Application Servers be accommodated. In earlier database management systems, tables were often denormalized to speed data access. Totals, like those illustrated in the above example, were added to provide quick access without waiting for calculations. Again, if this is the case, correct it in the object design, then remember to update these data items as they are stored back into the database. The remaining cases for what may appear to be poor database design could reflect business processes or requirements that are not yet known and may impact object design. In the example above, the total shipping weight may differ from the sum of the individual shipping weights because of repackaging or special handling requirements. If the vendor is selling computers, the invoice may include a case, motherboard, hard disk, CD-ROM, video and network cards, and so on. Each of these products shipped separately would include additional packaging, but when assembled, the packaging is thrown away. Once the computer is built and packaged, it is then weighed and a new shipping weight and charge are entered. The individual product shipping weights are only on file for use when shipping the product independently. If this is the case, both shipping weights are needed, but the total weight may be overridden by the computer assembly staff.

Databases from objects In other cases, the database tables do not exist and new tables must be designed. Since there are no legacy data structures, the tables can closely reflect the object design, but must also fit the rules and requirements of the relational model. If possible, one-to-one mappings between the objects and the tables can often eliminate quite a bit of work when creating the persistent object layer. At the same time, good database design should not be ignored just to simplify object mapping. Report writers and other external systems will also need to access this data. Object design is never completely compatible with data modeling, so follow best practices for each, justify the reasons for breaking the rules, and make sure that they do not cause difficulties later.

Designing the Persistent Object Layer

Scalability Scalability is the ability of a software product to easily adapt and grow as the volume of transactions, objects, and data increases. What works well in a small system will often overwhelm system resources as the workload increases. It seems that no matter how much growth is expected, the ultimate needs of the software will always grow to exceed its capability; so the more scalability the better. Scalability can be achieved in a number of different ways, meeting different growth requirements. Since one of the main advantages of the application server environment is the ability to use multiple computers, distributed object support at the business object level is an excellent approach. In parallel with distributed processing is multi-threading, allowing processes to run simultaneously on one or more computers. Finally, transaction support protects the integrity of the data even when objects are distributed across multiple computers. Each of these will allow the application server to grow as business needs increase.

Distributed object support The level and partition of distributing objects across multiple machines is a very tough call. Too little distribution and the system will max out server capacity and the distribution strategy will have to be reworked. Too much distribution and the system will bog down from excessive network traffic. This decision will be one of the toughest choices and should be approached carefully. Ideally, all objects can be distributed across all machines. This quickly solves all of the problems and allows total flexibility in load balancing and scalability. If only distributed systems were that simple! Distributed objects communicate by way of network traffic, even when both objects are on the same machine. This quickly overloads the network and slows object communication to unusable levels. The best solution is to partition objects into groups, then create distributed interfaces to communicate between the partitions. There are several ways to partition the application server without adding too much complexity. The first is to partition the application server vertically, breaking up the server into several smaller functionally based

149

150

Building Application Servers servers. An accounting application server may be broken into general ledger, payables, receivables, inventory, and so on. Although some objects may be duplicated and exist concurrently on several servers, the database server will synchronize the data while still ensuring data integrity. A second approach is to use the vertical partitions, but send service requests between servers to eliminate duplication. Using the same example, the payables, receivables, inventory, and other application servers send service requests to the general ledger application server when it comes time to post journal entries. This way, fewer objects will have to be duplicated between servers, and the servers communicate through the same service interfaces that are already available to the user interfaces. Within the application server itself, there may also be some need to distribute objects. When this need occurs, the less distribution, the better. The best option is to distribute high-level business objects, allowing lowerlevel objects to be encapsulated within the higher-level objects. This is very application-dependent since, as we saw earlier, lower-level objects often are encapsulated in many different higher-level business objects. Object distribution is still a difficult task that must be approached with caution. Thorough understanding of the inner workings of the middleware implementation will help you to create an efficient distributed object design.

Multi-threading Another consideration that can help improve the efficiency of the persistence layer is multi-threading. Most operating systems and programming languages now provide the ability to have multiple processes running concurrently within the same program. This allows objects to act in the background on their own without requiring an external method call. Within the persistence layer, the task of synchronizing data between the objects and the database can be done during otherwise idle time. A thread can sit in the background and periodically check each object stored in the persistent collection to see if any changes have been made to the attributes. If a change has occurred, the thread can send an update to the database so the change can be reflected on the server. This thread can be tuned to perform an object check every certain number of milliseconds, balancing computer time between services and data operations. There are

Designing the Persistent Object Layer

many ways to implement this process. One of the simplest is through change flags that are set when an attribute changes, then cleared when the database is updated. As long as the method is standardized across all objects, the thread can detect changes and synchronize the database in a timely manner. In addition to persistence, multi-threading can be used by business objects to perform process intensive activities in the background, outside of the control of the service interface. Allowing multiple computers to all execute code simultaneously will greatly speed the throughput of the application and improve response time. Learning how to harness this power takes time, but provides great benefits. Transactions

Finally, the persistence layer must also protect the integrity of the data. Good business object design will go a long way towards ensuring data integrity, but often, a disruption in the program flow will allow incomplete data to be stored back into the database. Another step in protecting the data is to set transaction boundaries, requiring all related changes to be grouped into a single update that is rolled back if any errors occur. Most relational databases provide transaction facilities, and these are usually all that are needed to ensure consistent data. A single "begin transaction" operation will mark the beginning of the sequence, then either a "commit" or "roll back" operation can be requested to store or cancel the set of updates consistently. When more than one database is involved, additional transaction capabilities can be added by either including transaction server middleware or programmatically controlling several different database transactions. Within the persistence layer, there are several ways to implement transactions. The approach selected will depend on other design factors. The simplest approach is to add transaction boundaries within the persistent object server. When a complex object is released, a "begin transaction" operation is posted, then each lower-level object is released and written to the database. After all lower-level objects are released and stored, the transaction is completed by issuing the "commit" operation.

151

152

Building Application Servers For more complex objects or objects that span multiple databases, the object server can serve up transaction objects that can be used by either highlevel business objects or service interface code. When the transaction object is created, it sends the "begin transaction" command to the databases; then, when the object is released, it commits the transaction. If an error occurs, the object is either discarded or lost and the transaction does not commit. Finally, for the most complex transaction requirements, the application server can be built using transaction middleware such as Tuxedo or MTS. These middleware products provide transaction-based distributed objects so transaction capabilities are built directly into the middleware. Complex transaction boundaries then become part of the business object implementation. Transactions, threads and distributed objects all can add scalability to the persistence layer. Chapter 13 will examine many of these techniques in far greater detail.

Using Object-Oriented Databases Since most business data already resides in relational databases, it makes good business sense to continue using the relational data model. But this technology does have some drawbacks. All data must conform to a set of predefined rows and columns. Data must also fit within the limited set of predefined data types defined by the DBMS vendor. Often, object models have difficulty fitting within these bounds. To solve this problem, a new data model has emerged based on object technology. This model, the object-oriented database management system (ODBMS), stores objects instead of data. Each object is derived from a persistent base class that can automatically load and store itself. The ODBMS provides its own naming, persistence, and life cycle services so that when an object is needed, it is automatically swapped into memory. The ODBMS monitors object usage, and when memory is needed or the object has not been used for a predetermined amount of time, the object is written back into the ODBMS and is removed from memory. In addition to naming, persistence, and life cycle services, most ODBMS packages can also distribute objects across multiple machines, and many provide transaction services to roll back changes when exceptions occur. Some even provide "pipelines" that act as gateways between

Designing the Persistent Object Layer

the ODBMS and relational databases so that existing relational data can be accessed and updated automatically (Saljoughy 1997). As these products mature, they may eventually become the logical choice for handling persistence and object distribution for application servers. Until then, there are issues that should be considered before adopting ODBMS technology. The first issue, already addressed, is product maturity. The relational model has become almost a commodity with standard interfaces and functionality. If there are problems with a relational implementation or the database must be moved from one platform to another, there is little difficulty making the transition between vendors. This is not the case with the ODBMS market. Many products are still language-specific with marked differences in implementations. These standards for implementations and terminology are still maturing. Another issue is scalability. As the application server gains new functionality, as the number of classes and instances of classes grow, and as the transaction volumes increase, will the ODBMS have the horsepower to maintain response time and throughput? Remember that in an ODBMS, each customer, invoice, and order item will become a distinct object that will have to be managed by the ODBMS. Just as relational databases quickly grow from thousands to millions of entries, the ODBMS must have the capacity to manage this same, growing volume of distinct objects. Finally, an issue that has already been addressed several times is that of application integration and compatibility. Unless the ODBMS can also present its data as a relational model, there is no backwards compatibility for existing applications. All applications will have to be replaced, or redundant data will have to be managed in a separate relational database. Report writers and other tools already in use throughout the organization will have to be replaced, causing new learning cycles, confusion, and difficulty. All of these issues have to be addressed before ODBMSs will be widely adopted in the business environment. Many vendors are currently working on ODBMS implementations that will solve these problems, and over the next few years, this technology should mature. If they succeed, there will be little need to design a separate persistence layer, since all of the functionality will be provided by the ODBMS.

153

154

Building Application Servers

Using Objects to Represent External Applications In addition to relational or object-oriented databases, data will often come from other external systems. These sources can still be represented in the persistent object layer using the same methods as table objects, but these translation objects will retrieve and store information either through external services or through other network requests. Chapter 7 looks at how to interface the application server to external systems and the issues of accessing legacy data.

Summary The persistence layer is responsible for storing and retrieving data between business objects and databases. It also acts as object broker, creating and removing business objects and managing their life cycles. When designing the persistent layer, use the following guidelines: • Review database design documents as well as the database structure to understand how the existing data is stored. • Create mappings between the business objects and the existing databases. • Design new tables to accommodate new data that will be stored and handled by the business objects. • Design persistence server objects that can be used to request and store business objects. • Design mapping objects, used by the persistence server objects, that can create and store each business object or object structure from the database objects. • Consider using middleware to manage the life cycle and directory services required by the persistence objects. • Consider multi-threading to optimize persistent services. • Consider implementing transactions if data integrity is critical.

Designing the Persistent Object Layer

References Date, C. J. "The Birth of the Relational Model." Intelligent Enterprise, October 1998: 61-63. Saljoughy, Arsalan. "Object Persistence and Java." Java World, May 1997. Available from http://www.javaworld.com/javaworld/jw-05-1997/jw05-persistence.html

Further Reading Date, C. J. Introduction to Database Systems. Reading, Massachusetts: Addison Wesley Longman, 1990.

155

Chapter 7

Integrating Existing Systems and Legacy Software Legacy software—the words conjure up images of glass-walled rooms, guys with crew cuts, lab coats, and horned-rimmed glasses, COBOL, FORTRAN, RPG, ISAM, line printers, tape drives, and maybe even punch cards: everything that's ancient and evil, old and obsolete. This is the image that vendors want their customers to see as they show off their latest client/server tools. But in reality, legacy software is a core resource. Those ancient COBOL programs are the tools that keep the business running smoothly. If this were not true, the Y2K problem would never have been an issue and all of this ancient software would have been replaced long ago. It is a tribute to those old COBOL programmers that the code still plays an important part in their organizations 15 or 25 years later. This chapter will examine how to integrate application server technology into the existing information system environment. Topics will include: • Design issues for application integration • Application mining • Turning subroutines into services • Input and output streams 157

158

Building Application Servers • Accessing application databases • Synchronizing transactions

Design Issues for Application Integration When approaching application integration, remember that there is no one best solution. Integration tasks will vary depending on the hardware and software platforms, system architecture, communication links, data models, and a host of other factors. The level of integration may also vary based on the amount of information needed and the directions of data flow. A task may require a simple data transfer, or it may need to share procedural code. What worked when linking to the general ledger system may not work when accessing inventory. The first question to ask is, how necessary is this link? Any integration effort will take time and resources away from other development tasks. If the only need is to populate a list box or to look up static data, it makes more sense to have someone key the information or routinely copy the table onto the local database server. Another option is to periodically replicate data between the two databases. These simple, less sophisticated processes will often solve the problem without impacting tight development schedules. If a simple replication process is not sufficient, then you must perform analysis to determine how to link the external applications. Here are some of the design issues you must address when considering application integration: • Take inventory of the existing applications and determine the functionality that is already available. This is often referred to as system mining or application mining. • Determine the level of integration required. Data transfer is often easier than remote procedure calls, but there are tradeoffs and application needs that will determine which approach is better. • Consider architecture and networking. The difficulty in accessing older, legacy systems often makes data transfer a better option, but if high-speed network connections are available, access to external services may make more sense.

Integrating Existing Systems and Legacy Software

• Examine the design of the external programs. This will often limit the amount of code sharing you can accomplish. Many systems tightly integrate the business functions with the presentation code. If integration is too tight, it will be very difficult to extract business logic. All of these issues must be considered when choosing an integration strategy.

What Do We Have—Application Mining Before you can design an integration strategy, you must study the external systems to determine what functionality can be exposed to the application server. You can do this by examining design documentation, program code and database models. In addition to the actual code, there will also be business policies and security issues that you must investigate. Each employee's monthly salary amount could be used to assign priorities within an email system, but it is highly unlikely that the human resource manager would release these numbers. When approaching application mining, start by determining the best, yet simplest level of integration desired. A remote procedure call is often advantageous when posting transactions into an external system because the procedure will encapsulate logic to validate the data and protect the integrity of the database. When you need lookups, direct database access will often be a better choice. Make sure that the access is as simple as possible, but choose an access strategy that matches the needs of the application. See the guidelines listed in the Summary for help with assessing your needs. Once you've chosen an ideal level of access, examine the application to determine the least invasive approach that produces this level of access. Minimize changes to the external application and use existing code when possible. Program changes incur a high level of risk and add the possibility of introducing errors in the external system. This is even more risky when attempting to modify older, legacy code, since software development models have changed and it may be difficult to understand what the original code was supposed to accomplish. Often, middleware tools can be used to isolate an interface that will expose existing code. Remote procedure calls or distributed objects can

159

160

Building Application Servers isolate the code and enforce access security. Message queues and message brokers can provide pipelines that will route data and store requests even when network connections are intermittent. You can also use transaction monitors to coordinate activity between a variety of external applications.

Turning Subroutines into Services The safest, but usually the most difficult and expensive, approach to application integration is to execute program code from the external application directly. This ensures that the proper sequence of events occur, and error checking and exception handling can protect the integrity of the data. You can perform execution through remote procedure calls, distributed object architectures, or other more direct approaches. Each service is exposed to the application server using IDL or some other custom interface. You can then call this interface through a proxy object, located in the business object layer of the application server, that implements methods representing these external services. The proxy object can also route exceptions and errors back from the external services if a problem occurs. One difficult restriction of direct program execution is that the external system must be available at the same time that the application server performs its activities. If the external system is down or communication cannot be established, the application server will either wait indefinitely or crash. Relying on two separate systems doubles the probability that the system will not be available, and this may not be an acceptable option. If the application server performs mission-critical services, the design must accommodate any possible loss of communication and continue to work in spite of these problems. An alternative design using message passing or replicated data may be a better solution.

Proxy Objects To isolate the external legacy or existing system effectively, you should represent each within the application server by one or more proxy objects. Although these objects expose the external services to the application server, they should still conform to the same rules and guidelines as any other business or persistent object. Each proxy object should rep-

Integrating Existing Systems and Legacy Software

resent a business entity that models business activities, not just external software functions. Once this is accomplished, these new business or persistent objects can seamlessly interact with the service interface and other business objects to perform the services needed by the user interface programs. The only difference is that they call external software to perform their methods. In an Internet electronic commerce application, the order entry services will need to check inventory availability and reserve the number of items ordered. If the inventory system resides on an IBM mainframe, the reserve inventory function can be exposed as a remote procedure call. Once you've exposed the function, there are many different ways to call it from the application server. The first option is to execute the check inventory and reserve inventory methods inline within the order item objects. The remote functions to check and reserve inventory are called each time a new order item is created. The main problem with this approach is that these functions are integrated too tightly into the application server. The initialization procedures required to set up the remote procedure calls will either require complex linkages when creating new order items or will add a high level of overhead into each order item object. Since the remote procedures aren't isolated, locating the links between systems will be difficult when changes are made to the inventory system. This is not a good design choice. A second option is to create either an object or an interface called Inventory System that exposes the two methods and enables them to be called. This solves the initialization problems because the linkage can be set up during the constructor. Methods that mirror the remote functions can send the item numbers and quantities on to the remote procedure calls. This is better than the first option, and may be adequate for seldomused functions, but is still not ideal. It does not conform to the same level of abstraction as the other business objects, being described in software terms, not business terms. This approach can be used, but a separate business object would fit better in the application server framework. The best option is to create a separate persistent inventory object that represents the legacy inventory system. When a customer chooses an item on the Web page, a message is sent to the service interface to add the item to the order. The service interface first requests a new order item from the inventory using a getlnventory method, then adds this item to

161

162

Building Application Servers the order. The getinventory method first calls the remote lookup function to retrieve the item number, descriptions, and quantity on hand. If the quantity on hand is sufficient to fill the order, a new order item is created and a remote reserve inventory call is sent to the inventory system. Once the inventory is reserved, the inventory object returns a new order item object which can be added to the order. If there is insufficient inventory, an exception can be sent back and the customer can choose to change the order or select another item. By conforming to the same requirements as other business or persistent objects, the programmer does not have to take time to research how the object will be used. A final consideration in proxy object design is to determine its life cycle and how that matches the availability of the external system. Since the remote system may not have the same availability as the application server, you must put processes into place to determine when the proxy object should be created, how long it should remain in memory, and when it should be removed. In the case of the inventory object described above, it must have the same availability as the application server; otherwise, the order entry operation will fail. If the inventory system is not available at the same time, the remote procedure call design will not work and you may need to explore other design alternatives. Message passing or other less timely methods may be required to verify inventory availability.

How to access remote software There are any number of ways to transfer execution from one machine to another. The most common, remote procedure calls and distributed objects, were described in Chapter 2, but will be briefly recapped here. In addition to middleware solutions, there are other more complex solutions, such as screen scraping and socket monitors that can be implemented to integrate different software platforms. There are also a number of proprietary options that work well for access to mainframe and legacy systems but, because these options address only a single platform, it would be impossible to cover them in any detail in this section. Remote procedure calls A common solution available on almost any mainframe platform is the

Integrating Existing Systems and Legacy Software

remote procedure call. The Distributed Computing Environment (DCE) described in Chapter 2 is a stable industry standard that has gained widespread acceptance throughout the industry. Any subroutine written in almost any programming language can be defined through IDL and then be exposed to the network. In addition to DCE, some mainframe vendors also provide proprietary remote procedure architectures.

Distributed objects Most mainframe vendors also support the OMG's CORBA standard for access to distributed objects. CORBA, also described in Chapter 2, is an industry standard that defines protocols and services that enable objects to be accessed over a variety of programming and computer platforms. Microsoft's DCOM standard for distributed objects is also gaining some support on mainframe platforms and can be used as a common distributed object architecture. CORBA also has facilities that allow legacy code modules to be packaged within an interface so they appears as distributed objects. Often a package of related procedures can be linked together in this manner to transform a legacy system into something that resembles a distributed object. This new legacy object now acts as if it were any other distributed object. Since distributed objects are the foundation of most application server architectures, a distributed object standard will greatly simplify application integration. Depending on the design approach used in the external system, accessing remote objects may be no different than using the application server's business objects. This is the ideal option.

Screen scraping, sockets, and other custom solutions When remote procedure or distributed object support is not available, you must investigate other alternatives. At this point, reevaluate the integration requirements. Database access or replication will most often be a better choice, since custom remote access strategies will involve complex, difficult technical skills, which translates into a much higher development cost and takes time away from more productive activities. If remote execution is still an absolute necessity, there are several alternative "hacks" that may solve these difficult problems.

163

164

Building Application Servers One alternative is to use approaches such as "screen scraping" (Pageno and Komides 1998). This method uses terminal emulation software (such as that provided by IBM 3270 emulation packages) to replace human input from a computer terminal with a communication stream from another software program. Coding can be difficult, requiring knowledge of terminal emulation and an intimate knowledge of how the user interface program will react to every different input possibility. Alternatively, the same results can be obtained by replacing the mainframe terminal handling logic with a new interface that accepts input as parameters. Many mainframe user interface programs rely on input streams from products like IBM's CICS or HP's VIEW communication utilities. These load a COBOL record structure with fields entered from the computer terminal. Of course, there are now two separate sets of code to maintain, the original user interface and one modified for remote procedure calls, but since most of these COBOL programs have matured over many years, maintenance should be fairly limited (if not, try something else). Another solution is to program at the network level, using socket APIs that provide direct communication between the application server and the mainframe (see The Legacy Continues—Using the HP 3000 with HP-UX and Windows NT by Yawn, Stachnik, and Sellars for an interesting approach to client/server implementation). The software can be structured so the mainframe acts as a remote server monitoring the socket and responding to requests sent from the application server. Each request, submitted through a programmer-defined protocol, calls a subroutine on the mainframe. Remember that the programmer is responsible for marshaling data formats and interfacing between the multiple programming languages. Each of these solutions will incur complex technical programming tasks that take resources away from application server development or other projects. These solutions also involve a much higher level of technical risk and future maintenance support. Make sure that the application requirements are absolutely essential before implementing these integration solutions. There usually is a much simpler design alternative available.

Input and Output Streams Not all application integration tasks require the complexities of remote procedure calls. In fact, remote access has many pitfalls and problems.

Integrating Existing Systems and Legacy Software

As mentioned above, both applications and the network must all be running before remote procedure calls can be processed. This can be a problem if the two computers are located at opposite ends of the country or if one of the systems has limited capacity for additional work. An alternative integration approach is to route data streams between the two applications. These can be done continuously using message-oriented middleware or by periodic replication or file transfers. No matter how the data is transmitted, the purpose of a data stream is to send information from one application to another. This stream can contain almost anything. It can be a list of orders sent from an order entry system to an external billing system, or it can be a mailing list sent from one company to another. Data is most often transmitted in only one direction, but, as with credit card verification, it can also be bidirectional. Transmission can be over modem, message broker, email, or even sneaker net, carried on floppy from one workstation to another. Handling a data stream inside the application server is no different than any other persistence process. To create an output stream, business objects are sent to a persistent object which extracts the necessary information then adds it to the output stream. Input streams are handled in a similar manner, creating business objects derived from the data then generating events to trigger processing of the data.

Message-oriented middleware Message-Oriented middleware (MOM), including message queues and message brokers, is a technology that allows asynchronous, one-way message passing (Nance 1998). These messages can be either events, triggering remote program execution, or data messages, sharing information between two programs. Messages can be persistent, held on disk to prevent data loss in case of system crashes, and can have transaction boundaries, allowing messages to be rolled back when errors occur. This technology is an ideal solution for application integration in environments where computers and networks are not always connected. Each message has an origin and a destination, using network addresses and naming conventions set up by the message administrator. When a program sends a message, it is sent to a central message server where it is held until the destination machine is available to receive messages.

165

166

Building Application Servers Within the application server, message middleware can be used either to route data streams or to trigger events. Data streams can be handled within the persistence layer, acting as if it were loading or storing local data. Events can be handled from either the service interface or the persistence layer, depending on the type of event. When an event is sent from another application, the service interface can often handle it in the same manner as a button-pressed event would be sent from a user interface program. It does not matter whether a user presses a "shipment received" button or whether the receiving system sends a "shipment received" event; both are handled by the application server using the same service interface process. To see how message brokers can be used to link applications, consider a large, national organization with customer service centers taking orders by phone in Atlanta and Seattle (see Figure 7-1). Their shipping facility is in Memphis and their corporate offices are in Chicago. When an order is taken, it is entered into the local customer service system in either Atlanta or Seattle. Each order is then sent to Memphis for fulfillment. Once the order arrives in Memphis, the local inventory system is updated and the product is shipped. Messages are sent back to the customer service center to indicate the order was shipped, and to the Chicago office to trigger a bill and to update inventory levels within the corporate general ledger system. Each message is queued into a local message server; then, when the network connection is available, it is routed to the message server at the remote site. The remote message servers forward the message to the appropriate application when the application signals that it is ready to receive messages. For orders taken in Atlanta and Seattle, these messages will be very data-intensive, carrying all of the information needed to fulfill the order. Other messages, such as the "order filled" message, will represent an event with little data other than an invoice number. To minimize wide-area networking costs, the customer service centers may want to use dial-up connections to transmit orders each night. The message servers will hold the orders throughout the day; then, in the evening when phone costs are lower, the customer service center message servers will call the Memphis message server and send the orders queued up during the day. At the same time, the "order filled" messages can be sent back to the customer service centers. Message-oriented middleware is still a complex technology, but it does provide a more reliable approach to application integration than

Integrating Existing Systems and Legacy Software

Chicago Corporate Reporting General Ledger

Memphis Shipping Inventory

Atlanta Order Entry

Figure 7-1. Electronic commerce example

remote procedure calls. For applications that must communicate across wide-area networks that require fail-safe communication, this may be the most appropriate technology. Before committing to the expense, though, see if other, simpler data transmission options are available.

Advanced sneaker net In the early days of PCs when networks were still beyond the reach of most organizations, much of the data sent between PCs was done by carrying floppy disks from one desk to another. This "sneaker net" technology is still a viable option for data transmission. Someone once suggested that the cheapest bandwidth is a tractor-trailer filled to capacity with 4mm DAT tapes: it may not be fast, but it sure has a large data capacity. For periodic, high-volume data transmissions, a tape cartridge sent by overnight mail or an email attachment may be an effective solution.

167

168

Building Application Servers For programming simplicity and interoperability, there is no communication protocol simpler than a flat ASCII data file. It can be sent by diskette or tape cartridge, sent across the Internet using email or FTP, sent across networks, or sent by modem using a variety of communication protocols. It can be read by any programming language and can be directly imported into databases. It serves the same functions as a message queue, but with far less software overhead and expense. For any process that is not time-sensitive, ASCII files are probably the simplest and most effective application integration tool.

Accessing Application Databases A convenient, yet somewhat risky approach to application integration is to access the external system's database tables directly. This is an effective approach for lookups and to read external data, but should be approached cautiously when it is necessary to write data into the external database. Writing or updating data will most likely breach database security and may cause problems with the integrity of the external data. There are times when remote database access can be an effective means of communication. It is an effective approach for validating identifiers such as customer codes or product items to maintain consistency between systems. It can also be used as a message repository without adding the complexities of message middleware. Database replication is also a valuable technique that can be used to synchronize and distribute databases located in different geographic areas.

Direct database access Direct external database access is usually safe as long is it is limited to reading, but not modifying external databases. Most applications use pulldown boxes that must be populated with standard codes, or use name and address lookups that validate customer or inventory identifiers. These external reads should not affect database integrity and will ensure that the application server data remains consistent throughout the enterprise. Take care when writing data into an external system. In most cases, you should pass remote procedure calls or messages instead, allowing the other system to validate the data before placing it in the database. In

Integrating Existing Systems and Legacy Software

rare cases when data must be written directly to application tables, you must build the same validation rules into the local application server's persistence layer to enforce data integrity. One place where remote data access does work effectively is when a table is used as a message repository. Instead of setting up message servers or calling remote procedures, it is often simpler and more effective to write the message data directly into a remote database. These messages can then be processed when convenient using the existing software to validate the integrity of the data.

Replication Most database vendors provide replication facilities that allow changes written to a central database to be replicated or synchronized into mirrored databases on other servers. This is an effective tool for providing database access across a wide geographic area without the expense of maintaining continuous network connections. Changes are logged throughout the day and periodically a replication process is run to synchronize the data between the two databases. An example of this would be in the customer service sites described above. Each maintains its own order entry database with customer service representatives entering orders throughout the day. If there is a necessity to have all orders accessible in both offices, one of the databases servers could connect and replicate changes each night, synchronizing the data between the two databases. In the morning, the databases at each customer service site would contain exactly the same data. As with direct database access, use caution to ensure that the same verification logic is used in both locations, or the data may become corrupted. Also, you will need additional logic to assign unique identifiers when new entries are added at each site to prevent data collisions. If the Seattle customer service site adds invoice number 1005 and the Atlanta site also adds an invoice 1005, one of the two invoices will be lost. The application logic must know that the application is running in Seattle and that an invoice in Seattle is assigned a number with a pattern different from those created in Atlanta. Another use for replication is for lookup tables. Most organizations set up standard codes that are used across the enterprise. These codes seldom

169

170

Building Application Servers change. These may be geographic region codes, general ledger account codes, or order status codes. They are used by many different applications and only change when a new region is entered or the accounting system is replaced. A similar, yet more volatile, set of information consists of the customer, vendor and product codes. These change more often, but are still have relatively little maintenance. None of these tables change often enough to justify paying for a continuous network connection across the country just to validate the codes. These tables are excellent candidates for replication. You can store a copy of the tables on the database server, then periodically run a replication process to synchronize the data. This ensures that the data is available locally, yet still stays relatively timely using daily or weekly replication cycles. Replication does have its own set of pitfalls. It is not an effective solution when high volumes of changes are made, causing large periodic transfers that can take many hours to accomplish. Also, most replication processes have a hard time synchronizing multiple changes, especially when changes are made to the same table entries at different sites. Resolving these replication conflicts often requires manual intervention that can make this process very difficult. Replication works best when there are relatively few changes and ownership can be established between sites so that replication conflicts do not occur. Carefully examine how and where changes occur and determine the volatility before adopting replication. It can be a powerful application integration tool, but it has its place.

Synchronizing Transactions Finally, no matter what technology or middleware architecture is selected for integrating external applications, you must put mechanisms in place to ensure the integrity of the data across all applications. For some simple application integration tasks this may not be a problem, but as the number of external applications grows or the complexity of the interfaces increase, there will come a time when transaction management will become an issue. Many of the middleware tools described in this chapter have built-in transaction capabilities. Even many of the legacy systems such as CICS provide transaction monitor capabilities. If this is not sufficient, the application server can implement its own transaction capabilities, or a transaction monitor or server can be used to manage these tasks.

Integrating Existing Systems and Legacy Software

Fun with Punch Cards: What to Do with Legacy Software When I began my career in the early 1970s, both my undergraduate computer science program and my first programming job used punch cards. All program code and data was submitted to the computer on paper cards that contained up to 80 columns of data per card. I'm still amazed that we got any work done, considering the deck of cards was submitted to the computer center. Several hours later, the cards and a stack of paper would be returned listing the results of the computer run. Any errors in the cards would cause the entire run to be rejected. The errors had to be corrected and the process would be repeated again. A couple years later at another company, we used a minicomputer and remote job entry (RJE) software connected to an IBM mainframe. Even though we now worked with online terminals and had the ability to store data in primitive databases, the data still had to be structured in the same 80-column record formats so the RJE software could treat it as if it were a punched card. In the early 1970s, we were making the shift from punch card-based software development to online software. Today we are making another architectural shift from mainframe and client/server-based development into object-oriented, distributed enterprise computing. As the punch cards went the way of the dinosaur, we slowly moved away from the 80-column record structures. As we move closer towards distributed enterprise computing, integration will become easier and new standards will emerge to allow tighter interoperability. Until then, every application integration task will have to be approached as a different puzzle, requiring different design approaches, programming models, and integration tools. Determining the integration approach requires careful thought and evaluation of design requirements. A project can quickly bog down when the wrong integration choices or tools are chosen. Each choice has a certain amount of technical risk that must be traded against the tightness of the integration. Table 7-1 gives a summary of these choices and gives some general guidelines for choosing an appropriate integration strategy. Balancing these risks and benefits is the key to successful application integration.

171

172

Building Application Servers

Table 7-1. Selecting an integration strategy Network Application integration connection

Administration Support

Cost

Risk

RPCs: DCE

High

Concurrent

Moderate

Moderate

Moderate

Moderate

Custom

High

Concurrent

High

High

High

High

CORBA

High

Concurrent

Moderate

Moderate

Moderate

Moderate

DCOM

High

Concurrent

Moderate

Moderate

Moderate

Moderate

Custom

High

Concurrent

High

High

High

High

Messaging

Moderate to High

Intermittent

Moderate to High

Moderate

Moderate

Moderate to High

Database Access

Low to Moderate

Intermittent

Low

Low

Low

Moderate to High

Intermittent or None

Moderate

Low

Low

Low

Distributee Objects:

File Sharing

Low

Summary Application integration has always been a difficult part of any software design and still is difficult in the application server environment. Distributed processing makes integration a little easier, but choosing the best approach is often difficult. Here are some guidelines to follow when considering external application integration: • Begin by taking inventory of the existing applications. Determine what functions are available and how they can be accessed. • Choose the lowest level of integration that will solve the problem. • Use remote procedures or objects only when direct online access is needed. • Use messaging when system access is intermittent and when online access is not needed.

Integrating Existing Systems and Legacy Software

• Consider file sharing for simple data transfers. • Limit remote database access to reading existing data or as a repository for message passing. • Limit database replication to cases where few changes are made or where ownership of the data can be established. • Stay away from custom solutions unless there is absolutely no other way to integrate the systems.

References Pageno, Dennis, and George Komides. "Integrating Internet Applications with Legacy Systems." Component Strategies, September 1998: 32. Nance, Barry. "MOM Implementation Issues." Network Computing, July 15, 1998. Available from http://www.techweb.com/se/directlink.cgi? NWC19980715S0025

Further Reading Yawn, Mike, George Stachnik, and Perry Sellars. The Legacy Continues— Using the HP 3000 with HP-UX and Windows NT. Upper Saddle River, New Jersey: Prentice Hall, 1997.

173

Part 3

Programming Part 3 describes tools and processes that can be used to transform the user requirements into working program code. These chapters examine how to implement the business objects and place them into a framework that services the user interface programs.

175

Chapter 8

Implementing an Application Server Framework Up to now, this book has looked at application servers as abstract concepts—first from an architectural view, then from the designer's vantage point. It's almost time to roll up our sleeves and start the real work: translating the abstractions into program code. But before we can start programming, we need to establish a general framework that can hold the service interfaces, business objects, and persistent objects that implement the server. This chapter bridges the discussion between design and programming, describing how to establish this framework. In addition to the program framework, we must also create an organizational framework that manages and structures the development process. This includes communication channels, programming tools, testing strategies and other administrative details. Although the emphasis of this book is on the technical side of application server development, these topics will also be discussed in this chapter. This chapter will examine the following topics: • The application server framework • Additional application server requirements • Development strategies 177

178

Building Application Servers

The Application Server Framework In the previous chapters, we examined each of the different application server layers as separate entities, each having different responsibilities and requirements. This is the advantage of using a layered architecture: each layer can be examined on its own, viewed independently. Business object design can focus on the needs of the application. Service interface design can implement services for the user interface. The persistence layer design can focus on mapping business objects to their representation inside databases or persistent storage. By focusing on a single layer at a time, it is easier to manage the complex requirements of the application server design. But before the design can be completed, you need an integration phase, drawing the layers back together. You must design a framework that enables the service interface to locate the business objects and determine when to load and store objects from databases to memory and back. Although this is still design work, it is detailed, low-level design that is highly dependent on architecture, middleware, and programming language choices. Each has a strong impact on how the framework is created. In some cases (like Microsoft's Transaction Server), the framework is provided as part of the middleware so there is little framework design. In other cases, the complexity of the operating environment and the limitations of the programming language dictate a unique, custom inhouse solution.

Initializing the framework To start the application server, there must be one executable program that can be launched from the command line or program manager. This program is simply called the application server, since it contains links to every object specified in the design. It has the responsibility of setting up the framework in memory. This includes loading the service interfaces and registering them with the middleware naming service so that the user interfaces can begin to request services. Figure 8-1 shows a block diagram of the basic application server program. When the program begins, it first creates an instance of one or more persistence objects. Next, one or more service interfaces are start-

Implementing an Application Server Framework

ed, each receiving a reference to the appropriate persistence objects. Each service interface object is then registered with the middleware, making them available to any authorized user interface attached to the network. Once the service interfaces are registered, they are ready to begin processing service requests. Examining this in more detail, the application server program must perform the following steps: 1. The executable program is launched from a command line or operating system interface. 2. Persistent objects are loaded into memory and references to these objects are stored in the executable program. Once the persistence layer is started, it can launch threads in the background processes that preload frequently used business objects, such as lookup tables and business rule objects.

Middleware

Step 4

Step 3

Step 1

Serviice Interfaces

Application Server

Business Objects

Step 2

Figure 8-1. The basic application server program

Persistence Layer

179

180

Building Application Servers 3. The objects that implement the service interfaces are loaded into memory, each receiving references to the persistent objects. 4. Each service interface object is registered to the middleware naming service. This way, the user interface programs can gain access through the middleware to these services. 5. The executable program now waits for service requests from the user interface programs. Note that this sequence assumes that the middleware naming service or object monitor is already running and accessible by the application server.

Processing service requests Once the application server is running, it can begin to process services for the user interfaces. Figure 8-2 illustrates the sequence of events that occur when a service request is processed. When a request is received, the service interface first requests business objects from the persistence layer. The persistence layer either locates the objects in memory or loads them from persistent storage. Once all of the objects are available, the service interface calls the appropriate business object methods, then returns the results requested by the user interface. For each service request, the following steps are performed: 1. At startup, the user interface uses a middleware API to obtain a reference to the service interface. 2. Using this reference, the user interface can request services from the service interface. 3. The service interface sends a request to the persistence layer to obtain references to the business objects that will be needed to process the request. 4. The persistence layer first tries to locate the business objects in memory. If they already exist, the persistence layer returns a reference to the existing object. 5. If the object does not reside in memory, the persistence layer retrieves the object from persistent storage, loading the object's

Implementing an Application Server Framework

Middleware

Step 3 User Interface

Step 2 Step 4

Step 6

Step 10

Service Interface < - >

Business Objrcts

Step 7

<

Step 9

Step 5 Persistence Layer

Database

Step 8

Figure 8-2. Processing a service request

attributes from the database, then it creates the object in memory. Once created, it returns the reference to the new object back to the service interface. 6. The service interface calls business object methods to process the request. 7. Once processing completes, the service interface informs the persistence layer that it is done using the business objects. 8. Changes made to the business objects are stored back to the database. 9. If the business objects are not in use by other processes, the persistence layer removes the business objects from memory. 10. The service interface returns the results of the request back to the user interface program. Although most of these tasks are performed by the service interface, business object or persistence layers, it is the responsibility of the frame-

181

182

Building Application Servers work to make sure that the layers are in memory and can communicate with each other. This is why the application server must pass references for the persistence layer to the service interfaces. It is also why the persistence layer passes references to the business objects when an object request is made. Without these communication paths, the service interface would not be able to call the necessary methods.

Commercial frameworks Although the following chapters will present detailed explanations of how to programmatically implement the application server framework, it usually makes more sense to buy part or all of it. Products like the Microsoft Transaction Server, BEA's M3, or the Inprise Application Server implement the basic framework, allowing the programmers to concentrate on the application logic, not the infrastructure. These products also provide middleware and other application development tools, offering a single vendor solution. The main advantage of the commercial frameworks is that the application objects are simply placed into the framework, usually registered using a GUI-based administration tool. Once registered, objects can be called by user interface programs to request services (just like service interface objects). These objects can call any other objects (business objects) to perform the business logic needed to process the request. Since the framework is responsible for objects storage and life cycles, the programmer no longer needs to worry about how the objects are loaded and whether they are in memory. The persistent objects now only have to be concerned with the interface to the corporate database.

Choosing a framework strategy In most cases, the middleware and programming languages will dictate the type of framework necessary and how much will be built or bought. Most commercial application servers provide a robust application framework, but also require that objects conform to fairly rigid component standards. Other middleware products, such as CORBA, require that the development team creates their own framework. This allows more latitude and flexibility, but also requires more work on the part of the developers.

Implementing an Application Server Framework

The choice depends on the size and scope of the project and the amount of flexibility needed. Simple projects can get by with a simple, home-grown framework. Larger projects will probably need the scalability and administration capabilities of a commercial framework. Enterprise-scale projects will need a hybrid, using commercial frameworks tied together with custom integration logic. The choice will depend on the factors described in the next section.

Additional Framework Requirements Developing the framework isn't difficult, but it does require a number of design choices and trade offs. When evaluating commercial application server frameworks, or when designing one to support the application server project, the following requirements should be considered. This framework will be the foundation for the application server that, once implemented, will be difficult to change. These functions include: • Scalability • Concurrency • Security • Fault tolerance

Scalability One of the main reasons for choosing a multi-tiered client/server framework is scalability. As more users and connections are added to the application, the server will run out of resources. With load balancing, another server can be rolled in and attached to the network and the objects will begin to be migrated over to the new server, freeing up resources on the other servers. Although load balancing is built into many middleware products, you need to partition the interfaces and objects ahead of time to provide efficient load balancing once migration occurs. Related objects should be deployed within the same server programs, and migration should be controlled in an orderly fashion. Future expansion and growth should also be considered when determining object distribution across servers.

183

184

Building Application Servers In addition to load balancing, metrics play a large part in providing scalability. Measurement tools must include the number of objects on each server, the amount of memory in use, how often each object is accessed, number of objects created and destroyed, and many others. These numbers can be used to tune the application server during development and to monitor system resources after deployment.

Concurrency In a multi-user, object-intensive system, objects can often be accessed by different users at the same time. Most languages provide tools to manage concurrency and synchronize execution, but an overall strategy (similar to database locking strategies) is needed to insure efficient throughput. Concurrency and synchronization are important considerations in the application server environment and an entire chapter will be devoted to these topics.

Security Although it seems easier to wait and implement security as a final addon after the rest of the software is complete, you should define a comprehensive security strategy from the very beginning. Security should encompass access control, network security, data integrity and external security. Access control is usually the central issue and should extend from user interface access through service interface, business objects, and data access. Passwords, location, or even biological markers (voice, fingerprints, etc.) can be used to validate a user's identity. Network security can include secure sockets or other encryption schemes when sensitive data is passed over the network. Data integrity is another security issue that can encompass a variety of approaches. You should consider transaction processing strategies to provide rollback of data when exceptions occur and, depending on the complexity of data manipulation, transaction processing middleware may be necessary. You also need to implement database techniques such as referential integrity, and have audit methods available to periodically check the data for inconsistencies. Although it's not a programming issue, you should address physical security to ensure that the computer hardware is protected from theft or vandalism.

Implementing an Application Server Framework

It is easy to forget that the development system placed in the programmer's cubicle may contain sensitive data and that software residing on these machines are valuable corporate resources. Make sure all developer machines are backed up often and that sensitive data is not left out in the open.

Fault tolerance A final consideration is a comprehensive strategy for error handling. As each new server is added, the number of communication paths increase exponentially. Both communication and software errors will occur, including power failures, system crashes, lost network connections, and many other unexpected problems. Gracefully recovering all possible errors can be difficult, and communicating them back to the user interface requires a consistent error handling protocol.

Development Strategies Another framework that may be even more important than the program framework involves the organizational structure that will support application server development. Most organizations already have solid software development strategies in place that include organization structures, methodologies, and a comprehensive suite of tools for traditional software development. These strategies have evolved over time and are tailored to meet the needs and culture of the organization. When considering strategies for multi-tiered software development, you have to examine the current development strategies and revise them to meet these new needs, but radical changes are usually not necessary. You may implement new methodologies to address object-oriented development and purchase new tools to support middleware or component architectures, but the development processes must still match the needs and culture of the organization. At the same time, moving to a new architecture is a good time to reevaluate the development strategy. The rapid rate of business and market changes do alter the needs and culture of every organization and it may be time to examine the software development process. Take time to develop a comprehensive strategy, not just a few quick fixes. In response to recent needs to respond quickly to business pressures, the trade press has offered articles like "Web Time Software

185

186

Building Application Servers Development" (Thomas and Constantine 1998). The authors do offer a few new techniques, but then suggest changes that either enforce longer hours or set up separate evening or night shifts. The referenced article even suggests allowing Mom to bring the kids and dog into the office so they can visit Daddy while he's chained to his desk. This is no way to run a railroad (or a software project). Do you really want your business to have to depend on software written by a bunch of social degenerates who last saw the sun shine six months ago? Instead of the short-sighted approach given by the trade journals, it makes sense to take the time to set up a development framework that can be sustained effectively over time. Iterative, incremental development strategies and joint design teams can produce tangible results in short timeframes, yet generate solid software products that will have the flexibility to serve the company for many years. The following issues and standards should be considered when organizing the application server development process: • communications support • development environment • tools • training • metrics

Communications support To have any chance for success, the developers must communicate with the project managers, other developers, JAD team members, and the user community. This communication will not just happen on its own, since software developers are not always known for their social skills. Instead, the exchange of ideas and information must be facilitated through both structured and unstructured channels set in place before the project begins. Structured channels such as formal meetings, interviews, memos and published documentation disseminate information consistently to all team members and move the project in the right direction. Unstructured channels including informal conversations, phone calls and email allow questions and problems to be resolved quickly.

Implementing an Application Server Framework

Many of these communication channels can be supported or facilitated with technology tools such as groupware, intranets, teleconferencing and email. Most groupware products, such as Lotus Notes, include tools that support meeting agendas, remote conferencing, document archives, message boards, and group scheduling as well as email, workflow, and other communication tools (Bock and Applegate 1995). With the growth of intranet technology, many of these same tools are now available in Web browser-based packages. Using these tools, team members can participate in discussions and collaborate without having to be at the same location or in the same time zone. Time and distance are no longer limitations, since each person can contribute their ideas whenever or wherever they are. Communication is more than just discussing issues and solving problems. It is about getting to know the other person, his experiences, his interests, the way he thinks. By cultivating acquaintances and friendships with people throughout the organization, you make it easier for the team to work together when the need arises. Spend a few minutes talking to the people in the break room. Bring a sack lunch and eat in the lunch room; get to know people throughout the business. Then, when the time comes to chase down some piece of business knowledge, it will be much easier to find it.

Development environment A separate development environment (servers, computers, networks, etc.) has long been an accepted practice in corporate software development. It allows programmers to test and experiment without the worry of data corruption or stealing resources from the business users. Application server development must have the same isolation, but may run into problems when integrating legacy software, since it is difficult to duplicate legacy hardware in a cost-effective manner. You will have to consider these issues. Fortunately, most of the requirements for a development network can be easily built from low-cost hardware. With the scalability inherent in application server design, two or three Pentium 100s can easily support the server requirements for 5 to 10 developers. Add some spare Ethernet cards and a cheap hub, and the development environment is up and running. Usually, the highest cost will be the operating systems, middleware, and database software.

187

188

Building Application Servers

Tools Approach tool selection with care, taking into consideration the preferences of the people who will be using the tools. Most software development tools are complex pieces of software, requiring time and effort before they can be used effectively. This breeds an emotional attachment that develops over time. Taking away a programmer's favorite IDE or language will probably be almost as traumatic as taking away your child's favorite teddy bear. Approach with caution. Nevertheless, a project must standardize on a common set of tools. Reaching this consensus may be difficult, but it is necessary. In many cases, the company will have already standardized on certain tools, and these products will limit the selection of other tools. Standardizing on a particular CORBA middleware may restrict the languages and development tools available. Selecting DCOM will probably limit the tools to Microsoft's Visual Studio IDE and a limited set of programming languages. Programming tools are often expensive, but investing in the right tools and providing the proper training will lower the development costs in the long run. Leverage the development team's existing knowledge and use their experience to select tools that will do the job. Project management Depending on the complexity of the development effort, project management software can either speed up the process or get in the way. For complex projects, this software can coordinate resources, such as people and development machines, and locate critical processes that can delay other parts of the project. In the hands of an effective project manager these tools are a great resource. CASE and modeling tools CASE (Computer Aided Software Engineering) tools have often promised much more than they deliver, but, just like project management tools, do have their place. Both data and object modeling can be well supported with the proper design tools. Each provides graphic representations of complex ideas that can be understood both by the software developers and the end users. Just as a blueprint is used to represent an

Implementing an Application Server Framework

office floorplan, a data model or class diagram can go a long way towards representing the final product. The typical business person may not understand all of the symbols on a floorplan, but he can still visualize the final layout of the new building. In the same way, an entity-relation model may not be completely understood by the end user, but it does offer a tool for communicating the overall design of the database. Most case tools will generate at least part of the source code from the graphical model. This eliminates much of the tedious detailed coding and can eliminate several days of programming time. Most tools also offer some form of round-trip engineering to update the model as changes are made to the code, synchronizing the model with the code automatically. CASE tools are some of the most expensive software development products, most costing several thousand dollars. Evaluate each tool carefully to make sure that it meets both current and future project needs. Make sure it is compatible with the programming tools already in use. Also, evaluate the learning curve and how the code generated by the tools fits with the current development methodologies and strategies. A CASE tool should do more than just generate pretty pictures; it must integrate directly into the project to be effective. For a lower-cost alternative, look at some of the graphics products that are emerging to support software design. These are not as tightly integrated to software development as CASE, but do provide many of the same tools to support data and object modeling. Graphics programs like Visio can be tailored to support software modeling, and many of the older traditional flowcharting tools have been extended to perform data and object modeling tasks. These are far less expensive and will communicate the same ideas. Version control A necessary support tool for iterative development is version control. As each iteration of the prototype is developed, changes must be tracked and isolated so that poor design choices can be quickly retracted. The tools also provide coordination of program code among a number of people so that changes are not lost as the code moves between developers. In addition to software changes, version control can also be used to track all of the other documents that are generated as part of the development process. These include design documents, test plans and user man-

189

190

Building Application Servers uals. Each of these documents also goes through a constant flow of changes, and it is much easier to isolate these changes when version control is in use. Another benefit is that the tool itself provides a trail of change documentation, tracking the progress of the development process. Programming languages and tools At the heart of the development process are the programming languages and tools that turn the design concepts into program code. Almost any modern compiler will generate clean, fast, optimized code, so benchmarking these factors should be considered, but should not be a primary concern. The main criteria for selecting a language should be the "teddy bear" factor described above, along with suitability to the task. If at all possible, let the programmers keep their teddy bears—the languages and IDE's that they are comfortable with. At the same time, select the proper level of support that will meet the needs of the project. Most language vendors now provide "enterprise" editions of their language products. In addition to the compiler and IDE (integrated development environment), they provide a wide range of development tools including CASE, version control, testing and many of the other tools listed in this section. Most also provide limited editions of their middleware products and database servers along with the additional development aids and debugging utilities needed to support their products. These enterprise editions are not cheap, but do provide one-stop shopping and integration between all of the tools. RAD tools Complementing traditional programming languages, rapid application development (RAD) tools such as Microsoft's Visual Basic, Borland's C++ Builder and JBuilder, and Powersoft's Powerbuilder provide excellent tools for creating both user interfaces and back-end components. Even Microsoft's Visual C++ now provides wizards to create COM objects and ActiveX controls. These tools speed program development by automating many of the programming tasks that used to take up so much of the developer's time. When these products first arrived, many generated bloated, inefficient code, but as these products have matured, they are now excellent alterna-

Implementing an Application Server Framework

tives to traditional third-generation languages. When using these tools, make sure that they integrate with the version control software, since changes can often be difficult to back out or redo. Programming wizards perform many useful tasks, but many of the wizards and agents do not have the ability to go back and change selections made up front. Make sure to checkpoint the changes prior to invoking these one-way wizards.

Debuggers Debugging distributed objects is still a difficult chore. Many of the debugging products are just beginning to address this problem, so make sure that any aftermarket debugger is compatible with your distributed computing platform. The debuggers included in the enterprise editions of the languages do support these requirements, but are tied very close to the specific language and IDE, so may not fulfill all of the requirements. Download several different vendors' trial versions and see which will support the development needs of the project.

Testing tools Methodologies and tools for testing software are now available for almost every phase of software development (Kit 1998). Test plan software can manage and monitor every aspect of the test plan. Code inspectors and analyzers can move beyond the errors generated by compilers and point out possible problems and deviations from accepted programming practices. Data generators and scripting tools can take much of the tedium out of testing by automating user interface testing, rerunning tests and comparing results between each testing run. Debuggers, bounds checkers, and profilers can track code execution and isolate problems. There is a wealth of testing tools that will engineer quality through all phases of software development. Testing and debugging tools are often tied closely to the development environment, so make sure that the tools chosen are compatible with the platforms and languages selected. In an application server environment, testing is complicated by distributed processing, and many tools are just beginning to support this development model. Nevertheless, traditional testing and debugging tools can support distributed processing, and careful planning can make this task much easier.

191

192

Building Application Servers

Bug tracking and reporting You need to set up bug tracking and defect management tools to monitor and resolve problems from the time the code is written until long after it has gone into production. As problems occur, the tracking software should provide ample space to document the problem, categorize it by function or module, then track it as it moves through multiple stages of resolution. Problem tracking software can either be purchased or developed inhouse. The tracking program's requirements are relatively simple and often need to be tailored to the organization. Testers and end users should be able to enter problems directly from their workstations, monitor their progress and be notified when the problem is resolved. Those responsible for fixing the problems should also be able to view related problem reports, annotate them with status information, and either indicate that the problems are resolved or hand them off to other developers.

Other support tools In addition to programming tools, most developers also need to have standard office applications, groupware, email and Internet access. Developers have to write reports and documentation, make presentations, use spreadsheets to verify calculations, and perform other routine office tasks. An office suite such as Microsoft Office or Corel's WordPerfect Suite should be included on every workstation. If the company is using groupware or an intranet to facilitate communication, these tools must also be available from the programmer's workstation as well as Internet email. Also, Internet access is a must, since there is a wealth of knowledge and tools available and these should be immediately accessible.

Training Many of the tools described in the previous section are large, complex, and difficult to learn. After investing thousands of dollars to put together the right set of tools, it is easy to throw away thousands more trying to train the staff to use them effectively. People learn in many different ways, so training that is effective for some may not be effective for others. Finding the best techniques for all members of the team is just as difficult as finding the tools to support the development effort.

Implementing an Application Server Framework

Classroom training, although effective, is the most costly solution. With costs often ranging from $1,200 to $1,500 for a three- or four-day course, classroom training will often be prohibitively expensive. Vendor-supplied courses are usually the best, but are higher-priced and the subject is usually limited to vendor-supplied products. If classroom training is absolutely necessary, rely on aftermarket training instead of the classes offered directly from the vendor. These classes are priced somewhat lower than the vendor's classes and will provide much of the same information. On-site training is also an option. If the team is large enough, the fixed price of bringing the trainer on-site will sometimes bring the per-person cost down. Video training programs are also available at a much more reasonable price, but since there is no interaction with the instructor, training is one-way. Consultants brought in to help set up and oversee a project are also a valuable resource for training. As part of their standard fee, they can tailor courses to address the tools and methodologies used in the project and can focus the training specifically to the needs of the project. Costs will be less than that of classroom training, and time will not be spent learning all the intricacies of the language or tool that may not apply to the developer's needs. For some, it is easier to just sit and experiment and learn by doing. There are a wealth of aftermarket books on every language, tool, and methodology, and their prices range from $30 to $70. Coupled with the tools themselves, or downloaded demos, these can provide cost-effective training if the learner has the motivation and ability to learn in this manner. Often, one or two people can spend a few days and learn enough to either prepare a course for the rest of the team or pass on the information in joint study groups. Other training resources include trade magazines, academic journals, user groups and vendor publications. These provide a wide range of information on current development issues that may not be available from other sources. Also, consider Internet searches for products, white papers and other information. Web searches can turn up a wealth of information and lead to technologies and products that are not well known and do not get the trade press that the larger vendors receive. Finally, as the project gets under way, set up procedures to disseminate tips and tricks throughout the group. This can be set up as a discussion group in Lotus Notes, a document repository on an intranet or server or as a distribution list within the email system. As people discover techniques or find solutions to difficult problems, encourage them

193

194

Building Application Servers to write a brief summary and post it to the repository. Then as others run into similar problems, they can use the experience gained by other team members to solve their problems.

Metrics Throughout the development process, you should include measurements and metrics to ensure quality and to manage both project and system resources. Metrics can be used to measure the breadth of the project, the quality of the design or program code, monitor defects and measure system performance. Within the application server environment, the metrics to focus on are the number of objects and the resources that they will require. A major reason for moving to application server technology is to allow scalability and better application performance. Since these are the primary goals, they must also be the primary measurements. Object counts and memory utilization should be built into the application framework so they can be monitored by the system administrators. These measurements then can be used to balance the application load among the servers. Network throughput and data access times are also important measurements. Keeping a close eye on these numbers will ensure continued application server performance and a more responsive application.

Summary The application server framework is the foundation where all application objects are placed. When developing this framework, use the following guidelines: • The framework is highly dependent on the middleware and programming languages used. • Carefully examine the trade-offs before deciding to build or buy the framework. • Make sure that the framework will be able to grow with the needs of the organization. It should provide scalability, concurrency, security and fault tolerance.

Implementing an Application Server Framework

• The organizational framework is just as important as the software framework. Develop strategies for the group's communications support, development environment, tools, training, and metrics.

References Bock, Geoff, and Lynda M. Applegate. Technology for Teams. Cambridge, Massachusetts: Harvard Business School Publishing, 1995. Kit, Edward. "Passing the Test." Software Development, March 1998: 34-42. Thomas, Dave, and Larry Constantine. "Web Time Software Development." Software Development, October 1998: 78-80.

195

Chapter 9

Using Java to Build Business Objects Creating business objects is a straightforward process in any object-oriented language. Just declare a class, list the attributes and methods, then fill in the business logic. This is basic object-oriented programming. The difficulty lies in linking these objects across a distributed network and getting them to perform useful work. This chapter will use the Java programming language to illustrate how business objects can be created and distributed across a network. The Java programming language, released by Sun Microsystems in the mid-1990s, was originally intended to be used in consumer electronic devices such as personal digital assistants, cable access boxes, television sets, and other devices that required simple user interfaces. The language was designed to be hardware-independent by compiling to an artificial byte-code instruction set that could be easily implemented in an interpreter on almost any microprocessor device. As the Internet and World Wide Web gained momentum, Web page authors wanted to add features like animation and interaction to their Websites. Since the Internet browsers had to run on a large variety of different computer platforms, the browser manufacturers found that the Java programming language, with its platform-neutral instruction set, was a good fit. The software could be compiled once, placed on a Web server, then run on any Java-enabled browser on a PC, Mac, UNIX, or other machine. Besides being platform-independent, the compiled files were small and moved quickly over the Internet. The Java language is loosely based on C++ but eliminates many of the 197

198

Building Application Servers most difficult aspects of C++ programming. It is purely object-oriented, with all data types other primitives (integers, floats, characters, etc.) implemented as classes. It also has the advantage of an extensive integrated class library. There are no pointer types in Java; all memory variables and objects are handled as references. Objects are created with the new operator, but Java provides a built-in garbage collector that automatically deletes objects when they go out of scope or are no longer needed. This eliminates the memory leak problems associated with C++.

Using Java to Illustrate Programming Principles This chapter will illustrate how to create and distribute business objects using the Java programming language and its simple object request broker, RMI (Remote Method Invocation). Any number of programming languages and middleware products could have been chosen. C++ and CORBA or Visual Basic and DCOM are also excellent choices, but Java and RMI were selected because they have been ported to a variety of platforms and are readily available, either free from the Internet (at Sun Microsystems's Website, see Further Reading) or from a variety of vendors at reasonable costs. The code is also a bit simpler, making it more readable than C++ with no pointers, simpler memory management, and integrated garbage collection. RMI is also included as part of the Java Software Developer's Kit (Java SDK), so there is no additional cost to obtain the middleware. Also, the code to implement RMI has less overhead than CORBA or DCOM and can be run on a single PC with little additional hardware or software. The Java programming language is well documented and the development kit is easy to obtain. For those not familiar with the language, check Further Reading at the end of this chapter. Also check the Appendix for an explanation of how to set up the Java and RMI programming environment on one or more Windows machines.

Overview of the Distributed Java Architecture Although Java is often thought of as just a programming language, the Java development and runtime environment, Java Virtual Machine

Using Java to Build Business Objects

(JVM), can be considered a separate computing platform. Being deviceindependent, it sits on top of the host operating system and provides a separate virtual computer platform that responds according to the rules of the Java Virtual Machine, not the host machine language or operating system. At the same time, it does rely on the host operating system for hardware-dependent functions like file processing, screen displays and network communication. A Java applet will look different running on a PC than it would on an X Windows display, but the underlying program logic will work the same. A Java program begins with a source file created using a program editor or IDE (integrated development environment) like JBuilder or SuperCede. Each Java source file is compiled by the javac compiler into an artificial machine language called byte-code, stored in a class file. This code was designed to be very compact to keep memory requirements low. The byte-code relies on class libraries that already reside on the target machine along with the Java runtime and browser, so that common operations like network communication and GUI objects do not have to be included when downloading code. The class files may be run either as standalone programs called applications or as applets embedded in a Web page. Applications are run inside the Java Virtual Machine (invoked by the java command), which executes the byte-code as if it were a separate computer machine language. This process, called interpretive execution, does impact execution speed. Each instruction must first be interpreted by the Java runtime, then executed on the host computer. For computationally intensive work where performance is a concern, a byte-code compiler can be used to convert the class files to native machine language. In addition to applications, Java allows class files to be inserted into Web pages and run within a Java-enabled browser such as Netscape or MS Internet Explorer. These classes, called applets, are also compiled into byte-code form and are then inserted into Web pages using the HTML tag. When the browser encounters the tag, it downloads the class file specified in the tag, then passes execution to the Java interpreter embedded in the Web browser. To maintain security, an applet is not allowed to access data from the client computer and cannot communicate with any computer other than the Web server. Again, performance is often a concern, so the browser vendors have implemented

199

200

Building Application Servers Just-in-Time (JIT) compilers that translate the applets into native machine language prior to execution. For Java to be accepted as a viable business platform, it needed to be able to access corporate databases. Although there are some alternatives, JDBC Gava Database Connectivity) is the most common data access protocol. JDBC is a set of Java classes that enable an application or applet to send SQL (Structured Query Language) commands to a relational database, then receive the resulting data tables. Each vendor must provide a JDBC driver for its database, which is installed either on each client machine or on the Web server. This driver is responsible for communication between the JDBC driver and the database, and is also responsible for marshaling data from the SQL database into standard Java data formats. In addition to the native drivers, Sun provides a JDBC-to-ODBC bridge that can be used to access any ODBC-compliant database (with a small performance penalty). Java also includes class libraries and utilities to create distributed objects through RMI. Objects to be distributed are described as interfaces, then run through the RMI compiler (rmic) to generate stub and skeleton classes that act as substitutes for the remote objects and provide communication across the network between objects. RMI also provides a registry utility (rmiregistry) that tracks the names and locations of objects across several networked computers. As Java continues to mature, a number of extensions and APIs have been added to provide additional capabilities. One that applies to application server development is the JavaBean standard, which includes language extensions and standards to create Java components. JavaBeans are components that can be placed in a framework where they can interact with other JavaBean components with little or no program code. Sun provides a framework called a BeanBox that acts similar to the Visual Basic or Delphi environment, where components can be dragged onto a form and then connected together using the mouse. JavaBean components are highly customizable through the use of property pages, which can be accessed and set by the programmer at design time or by other components at run time. They also respond to external events like mouse clicks or events generated by other JavaBeans. Although the JavaBean standard was originally created to package GUI components, it has been extended through the Enterprise JavaBean standard to implement server-side and distributed components. As this

Using Java to Build Business Objects

standard gains support and vendor implementations, the Enterprise JavaBean standard will, most likely, become the standard for Java serverside development.

Object-Oriented Programming in Java Objects are described in Java as classes using a syntax similar to C++. The class name is declared, then all attributes and methods are listed within braces {}. Each attribute or method can be declared private, accessible only within the class; protected, accessible within the class or derived classes; or public, accessible by any class. Attributes are preceded by their type, either a primitive such as an integer (int) or character (char), or by another class name to create an instance of that class. Methods are preceded by the returned parameter type followed by the method name and the parameter list. Parameters are passed by reference.

Java class definitions Listing 9-1 shows the class definition for a simple customer class. The first line declares the class name as Customer, then encloses the attribute and methods within braces. The attributes are name, address, and phone, of which the name and phone are Strings, the standard Java character string class, and the address is an instance of the user defined class Address (javac will look for the file Address.class to locate the definition and implementation of the Address class). All attributes are private and can only be accessed directly by the Customer class methods. Listing 9-1: A simple class definition class Customer { private String name; private Address address; private String phone; public Customer (String nm, Address adr, String ph)

201

202

Building Application Servers name = nm; address = adr; phone = ph;

public void setName (String nm) { name = nm; }

public String getName () { return name; } } / / end of class Customer The methods for the Customer class include the constructor Customer and two other methods, setName and getName. Each class must have at least one constructor method, which is automatically called when a Customer object is instantiated. This method will usually initialize the class attributes and may do some initial processing. This constructor method receives references to the three parameters nm, adr, and ph and stores them into the appropriate attributes name, address, and phone. The setName method accepts the string nm and stores it in the name attribute, while the getName method returns a string containing the attribute name. To create an instance of a Customer object, the programmer will first declare the new object either as an attribute of another class or as a variable within the body of a method. The new operator is then used to create the instance of the Customer object and call the constructor. Listing 9-2 shows an example of a Customer object used as an attribute of the Contact class. In the Customer class, client is declared as an attribute along with a date indicating when the client was contacted and a remark describing the contact. Within the constructor method, the new operator is used to create an instance of the Customer object, then store the reference in the client attribute. The new operator automatically calls the constructor method of the Customer object, passing the parameters name, addr, and phone to the constructor.

Using Java to Build Business Objects Listing 9-2: Creating an instance of the Customer object within a Contact object class Contact { private Customer client; private Date date; private String remarks; public Contact (String name, Address addr. String ph, Date dt, String rmks) { client = new Customer (name, addr, ph); date = dt; remarks = rmks; } } / / end of class Contact

Class composition in Java Composition, or whole-part relationship, was illustrated in the previous example. A class, in this case the Contact class, contains another class, the Customer class, as an attribute. Actually, the date attribute is also a composition relationship, since the Date type is also a Java class. Looking back at Listing 9-1, the Customer class also uses a composition relationship with the Address class. Figure 9-1 shows a UML diagram of these relationships.

Class association in Java Where class composition is a whole-part relationship with one class containing the other class, class association is a somewhat looser relationship. Each class stands on its own, but a reference exists in one class that points to the other class. It is difficult to distinguish association from composition in Java, since Java has no pointer types and classes are all stored as references within the container class. What usually distinguishes an association from composition in Java is the tightness of the

203

204

Building Application Servers Address Customer name phone

linei Iine2 city state zip

Class Contact

Class Customer

Class Address

private Customer client; private Date date;

private String name; private Address address; private String phone;

private String linei; private String Iine2; private String city; private String state; private String zipCode;

Figure 9-1. Java class composition

relation. A composition relationship represents containment; one object contains another. An association exists when each object can stand on its own, independent of the other object. An association may also relate an object of one type to multiple objects of the other type, showing a zero-to-many or one-to-many relationship between the container class and the associated class (see Figure 9-2) Listing 9-3 (using the code already shown in Listing 9-2) illustrates an association between one or more Contact class objects and a ContactList class. The ContactList class contains an array called cList that holds references to Contact objects. The constructor method initializes the array, specifying the maximum number of Contact objects that can be stored in the class. An add method will insert each new Contact object into the array. Note that the new operation in the constructor does not create any new Contact objects; it only allocates space to hold references to the objects. The program calling the add method must first create a new Contact object, then call the add method to insert the reference into the array.

Using Java to Build Business Objects

ContactList

Contact client date

o..n

Class ContactList { private Contact cList[]; II ...

r

Class Contact { private Customer client; private Date date;

Figure 9-2. Java class association

Listing 9-3: Associating a Contact with a ContactList in a one-to-many relationship class ContactList { private Contact cList []; public ContactList (int n) { cList = new Contact [n];

public boolean add (Contact c) { /'/ code to add contact to list } } / / end of class ContactList

205

206

Building Application Servers

Class generalization in Java Generalization or inheritance is one of the foundations of object-oriented programming. A new class can be derived from an existing class by either redefining methods or adding new attributes or methods. This enables programmers to extend or refine the functionality of an object without making changes to the original object. Figure 9-3 shows the UML representation for class generalization. Listing 9-4 (using the code shown in Listing 9-3) illustrates a very simple example of inheritance. The ContactList class shown in the Figure is extended for use as a sales contact list called SalesList. A new attribute, salesRep, is added, then a new constructor is defined to accept a String parameter in addition to the integer. Within the constructor, the ContactList constructor is called by referencing the superclass (super), then the String parameter is stored in the salesRep attribute. Listing 9-4: Deriving a SalesList from a ContactList using generalization class SalesList extends ContactList { private String salesRep; public SalesList (String rep, int n) { super (n); salesRep = rep; } } / / end of SalesList class

Coding Guidelines in Java Although the above examples are probably not the best design decisions for this particular problem, they do illustrate each of the Java programming constructs. Using these constructs, it should be fairly easy to create class definitions that match UML specifications. Several UML-based CASE tools will even build skeletons of these class files automatically. Over the years, many guidelines have been put together to standardize name selection for classes, variables and methods. In the Microsoft world,

Using Java to Build Business Objects

many programmers have adopted the Hungarian notation developed by Charles Simonyi and made popular by Charles Petzold in his classic text, Programming Windows (Petzold 1990). This naming convention uses short prefixes to indicate the data type associated with each memory variable. In the Java world, a simpler, more traditional approach is often taken. This is the approach that this book will use. Class names are usually nouns beginning with a capital letter, Customer or Invoice, for example. Attribute and method names begin with a lowercase letter, with additional qualifying words beginning in capital letters such as customerName or addCustomer. All attributes are declared as protected with

getter and setter methods similar to the JavaBean standard. For the attribute customerName, there would be two methods: getCustomerName to retrieve the name from the class, and setCustomerName to change the name attribute. For a comprehensive set of guidelines on Java naming and programming standards, see Scott Ambler's "Java Programming Standards," listed with Further Reading at the end of this chapter.

Using Interfaces to Package Objects Java defines an interface as an abstract class that only contains method declarations and static final variables (constants). As an abstract class, it

Class ContactList { private Contact cList[]; II ...

Figure 9-3. Java class generalization

Class SalesList extends ContactList // ....

207

208

Building Application Servers defines a class, but has no implementation code. The code to implement the methods is found in a separate class that "implements" the interface. In an application server environment, a Java interface is most often used to define a service interface on a remote machine. To show how an interface is defined, we will begin to present the code for a simple application server. The first use case for this application is to implement a simple loan calculator Web page. The customer enters the loan amount, interest rate, and length of the loan; then, when the customer clicks the calculate button, an estimated monthly payment is displayed. Later extensions to this use case could include loan qualification and access to a rate database, but this simple function will be adequate to illustrate how to access a remote object. Looking through the use case, it appears that the application will need an object that can perform loan calculations. This is a simple object that emulates the time value of money functions of a business-oriented calculator. The object LoanCalc is first defined as an interface (see Listing 9-5) that declares two methods, getPayment and getPrincipal. The getPayment

method calculates the monthly payment given the principal, years and rate. Conversely, the getPrincipal method calculates the principal amount that can be borrowed given the monthly payment, years, and rate. This function will not be needed for this application, but since it may be needed later and the math functions are so similar, it will be implemented now. Listing 9-5: Loan calculation interface public interface LoanCalc { public double getPayment (double princ, double years, double rate); public double getPrincipal (double pmt, double years, double rate);

The interface contains only the declarations of each public method getPayment and getPrincipal. There is no code associated with the methods. Also, this object does not require any class attributes (or class variables) since each method performs a simple, self-contained calculation. Interfaces make a good starting point for object design since there is no need to define the implementation at this time. Later, a separate object

Using Java to Build Business Objects

is created that provides the implementation of these methods plus any others needed by the loan calculator. The code to implement the loan calculation interface is located in a separate Loan Calculator Definition class called LoanCalcDef. This class, shown in Listing 9-6, looks similar to the LoanCalc interface but includes an empty constructor (this will be required later when it is implemented as a remote object) and the method implementations. The declaration for the class LoanCa/cDef indicates that it implements the interface LoanCalc. Listing 9-6: Implementation of the loan calculator interface import java.lang.Math; class LoanCalcDef implements LoanCalc { public LoanCalc () { / / note - constructor will be needed later

public double getPayment (double princ, double years, double rate) { double p = princ; / / convert units to years double n = years * 12.0; double r = rate / 1200.0; if ((n == 0.0) || (r == 0)) / / avoid divide by zero return 0.0; else return p * r / (1.0 - Math.pow((1.0 + r), (0 - n)));

public double getPrincipal (double pmt, double years, double rate) { / / ... similar code ... } }// end of class LoanCalc

209

210

Building Application Servers For those not familiar with Java, the first line tells the Java compiler to look to the Java class library to locate the java.lang.Math class definitions, which are needed to use the Math.pow function, which calculates exponentiation. Within the implementation, the arguments are adjusted to reflect months instead of years, and the interest percentage is adjusted two decimal places. Once this is completed, the time period and interest rates are checked for zero values. If either is zero, the function returns zero to prevent any math error exceptions (divide by zero). If the input parameters are correct, the getPayment method uses a simple compound interest calculation to determine the monthly payment rate. Similar code is required to implement the getPrincipal function. So why go to the trouble of using an interface? In this example, the interface will be used to define a remote object. Only the interface definition is sent to the remote computer, not the entire class definition. This shortens the download time of the Java applet and prevents anyone from decompiling the code to determine the company's loan calculation secrets. Security is not a serious issue in this instance, since the formula is public knowledge, but in applications in which different customers can receive different rates or in which proprietary code is used, this could be an issue. Another reason to use an interface is to only expose a limited set of methods to a remote application. Since several interfaces may be implemented by one class, methods can be hidden from those interfaces that do not need them. In the above example, the loan calculator object may also contain several other methods, such as getARMPayment for an adjustable rate mortgage, but the LoanCalc interface only exposes getPayment and getPrincipal, since the other methods are not needed by this application. A second interface, ARMLoanCalc, could expose these other methods. The concept of interfaces is a powerful tool for both design and software development. From its beginnings in the early days of object-oriented programming and distributed computing, it has spawned the whole new science of component technology. This is just a brief introduction and the development of interfaces will be covered in detail in Chapter 10.

Using Java to Build Business Objects

Distributing Java Objects with RMI The Java language includes a simple object request broker called RMI (Remote Method Invocation) that provides much of the functionality required to implement remote objects and simple application servers using Java. Although not as rich in services and administrative tools as most CORBA implementations, it still has enough functionality to illustrate the basic processes required to distribute objects. The implementation process is similar to CORBA but without the high purchase cost or administration overhead. RMI development requires only a single Windows 95 machine with enough memory to hold the RMI registry, a personal Web server, one or more copies of the Java virtual machine, and an applet viewer or Web browser (see the Appendix for instructions on setting up a development environment). A good approach to developing remote objects is to start by creating one or more business objects without regard to how they will be distributed. The loan calculator object shown above is a good example. Create the object and a simple test bed to verify that it is functioning properly. Once the object is tested, create an interface that exposes only the methods needed by the application. Now the object is ready for conversion to remote access. Transforming a Java object into a remote object is not simple, but it is relatively straightforward. First, modify each object and interface to inherit remote functionality from the RMI base classes. Next, pass the objects (class files) through the rmic compiler to create stub and skeleton classes that act as proxies on the local machines for the remote objects. Once these are created, build a server application that instantiates the object and notifies the RMI registry of its existence.

Creating the remote interface The first step in transforming a class for remote access is to modify the class and interface to inherit remote functionality from the RMI base classes. For you to modify the interface, the interface or its base class must inherit the functionality of the java.rmi.Remote class and be modified to handle remote exceptions. As you can see from Listing 9-7, the LoanCalc interface has been modified to import the java.rmi library (changes shown in bold), which

211

212

Building Application Servers contains the remote interface and remote exceptions. The interface is changed to extend the base interface Remote, which contains methods to access the RMI Registry and security. Finally each method has also been modified to throw any remote exceptions, which enables the programmer to handle a variety of new errors that can occur due to network or remote access problems. Listing 9-7: Creating the remote interface import java.rmi.*; public interface LoanCalc extends Remote { public double getPayment (double princ, double years, double rate) throws RemoteException; public double getPrincipal (double pmt, double years, double rate) throws RemoteException;

Creating a remote object Modifying the class definition is similar to modifying the interface. The class is modified to inherit remote functionality from an RMI base class (UnicastRemoteObject) and modified to throw exceptions. Additionally, the constructor class must call the UnicastRemoteObject constructor (superO) prior to initializing any class attributes. Listing 9-8 shows the changes required to transform LoanCalcDef into a remote class. Two new libraries, java.rmi and java.rmi.server, are imported and the class now extends UnicastRemoteObject in addition to implementing the LoanCalc interface. UnicastRemoteObject is a class that supports remote communication between the calling program and the remote objects so that parameters, including other objects, can be passed across the network. Finally, each method must be able to pass remote exceptions back to the calling program.

Using Java to Build Business Objects Listing 9-8: Creating the remote object import java.lang.Math; import java.rmi.*; import java.rmi.server.UnicastRemoteObject; class LoanCalcDef extends UnicastRemoteObject implements LoanCalc { public LoanCalcDef () throws RemoteException { super ();

public double getPayment (double princ, double years, double rate) throws RemoteException { double p = princ; double n = years * 12.0; double r = rate / 1200.0; if (n = 0.0) return 0.0; else return p * r / (1.0 - Math.pow((1.0 + r), (0 - n)));

public double getPrincipal (double pmt, double years, double rate) throws RemoteException { / / ... similar code ... } } / / end of class LoanCalcDef

213

214

Building Application Servers

Creating the stub and skeleton When the application program receives a reference to a remote object, it appears as if it is calling the remote methods and passing data directly between itself and the remote object. In actuality, the application has received a reference to a stub object that is pretending to be the remote object. When a method is called, the stub method creates a method request that includes the object and method names and the parameter data; then it sends this message across the network. When the result is received, the stub program passes it back to the application program. Similar activity occurs on the remote computer. The message is not received directly by the remote object, but is received by a skeleton object that acts as if it were the remote application. This skeleton receives the message from the network, stores the parameters in memory in the same form that it appeared in the application, and then calls the remote object method. Results are then formatted into a return message and sent back to the stub program. This is a fairly simple process when method parameters are primitives like integers or characters, but when an object is passed as a parameter (which is most often the case), the stub must flatten out the object into a flat stream of bits that can be sent across the network. Fortunately, Java provides this ability transparently through object serialization, and no additional programming is needed. Creating the stub and skeleton classes is a simple process performed by the rmic compiler. This compiler takes the file name of the remote class and creates two new class files, the stub and skeleton. To invoke the rmic compiler, simply type rmic followed by the class name from the command prompt. As with most Java tools, rmic performs the task without any response—just another command prompt. In the loan calculator example, the command line would be: rmic LoanCalcDef This will produce two new files, LoanCalcDef_Stub.class LoanCalcDef_Skel.class.

and

Registering the remote object For a remote object to be accessible on the network, it must first be active in memory and then registered into the RMI registry. The RMI reg-

Using Java to Build Business Objects

istry is a program supplied with the Java SDK that is similar to the CORBA naming service. It runs in parallel with a Web server and is responsible for tracking remote objects and routing messages between applications and remote objects. The program that instantiates the object and registers it is the remote object server. This program can be a very simple Java application, such as the one shown in this example, or it can be a complex program that creates and removes objects according to the needs of the programs it serves. A collection of remote object servers distributed across several machines becomes the implementation of an application server. Listing 9-9 shows a simple remote object server for the loan calculator example. Its basic function is to instantiate the LoanCakDef class, then register it with the RMI registry. Before discussing the code in detail, it should be noted that a couple of additional Java techniques are used here that have not been discussed. The first is the structure of a Java application. An application is a stand-alone program that can be run from the command line. When the program is started, the Java virtual machine looks for a method called main and, in effect, calls the main method. Parameters for the main method are one or more strings that may be entered on the command line. Listing 9-9: A simple remote object server import java.rmi.*; import java.rmi.server.*; class LoanCalcServer { public static void main (String args[]) { try { LoanCakDef calc = new LoanCakDef (); Naming.rebind ("LoanCalc", calc); } catch (Exception e) { System.out.println ("LoanCalc not initialized"); e.printStackTrace ();

215

216

Building Application Servers

} / / end of LoanCalcServer The other technique is Java exception handling. This is similar to C++ and uses try and catch blocks. A section of code is enclosed in braces and prefixed with the Java command try. If at any time an exception occurs, execution stops and control is transferred to the catch block that is coded after the brace. The catch command retrieves an exception object that contains information about the error that occurred, including a string description that can be printed when the exception is passed to System.out.println. Back to Listing 9-9. This is a simple stand-alone application called LoanCalcServer with only one method, main, that is called when the application is started. The program creates an instance of the LoanCalcDef object described in listing 9-8 by using the new operator. LoanCalcDef calc = new LoanCalcDef (); This is the usual method of creating a new object by first specifying the type (LoanCalcDef), giving it a name (calc) then using the new operator to create the object. Once the calc object is created, it is registered with the RMI naming service with the following statement: Naming.rebind ("LoanCalc", calc); Naming.rebind will bind the name "LoanCalc" to the object calc in the RMI registry. Any Java program can then provide a URL to the machine along with this name to obtain the reference to the calc object. Both of these statements are wrapped around exception handling code. Since any number of errors can occur when setting up a remote object, the RMI library requires exception handling when registering a remote object. If the RMI registry or the Internet server is not running, or if there is already an object registered with the same name, an exception will occur. The exception handling code shown here is not adequate for a real-world application, but is sufficient for illustrating the basic error handling concepts. To start the LoanCalcServer, enter the following commands (this is for the Windows NT or Windows 95 command window):

Using Java to Build Business Objects

start rmiregistry /min start Java LoanCalcServer /min Each will create a new minimized window and will run until the window is closed manually. Unless there is an error, no messages will be displayed.

Accessing the remote object Once the RMI registry and the LoanCalcServer are running, a computer connected to the network can request a reference to the calc object and use it to calculate loan payments. When the reference is obtained, it is cast to an interface definition that can be called as if it were a local object. The only restrictions are that the Naming.lookup and the remote call are wrapped with exception handling code to detect any networkrelated errors. The reference can be obtained with a single Java call to Naming.lookup by passing a URL in the form "rmi://IP_address/rmi_name". The IP address is either an alias such as winnt.rleander.com or a numeric IP address as shown in the example below. The rmi name is the name of the object registered with the Naming.rebind command—in this case, LoanCalc. Putting this together, the URL for the calc object is "rmi://101.101.1.1/LoanCalc". Listing 9-10 shows how a remote object reference is obtained. The object calc is defined as a local attribute of type ILoanCalc (ILoanCalc is the interface created in Listing 9-7). The init method is the initializer for a simple Java applet that accepts loan amount, rate, and time and calculates a loan payment. Within the init method, the reference to the remote object is obtained by passing the URL to the Naming.lookup method and casting the returned reference into the calc attribute. If any errors occur, a message is printed and the applet hangs (again, not the best error handling, but fine for this example). The final step of the init method calls the initForm method to specify the layout of the applet form.

217

218

Building Application Servers Listing 9-10: Accessing the remote object private ILoanCalc calc; public void init () { String url = "rmi://101.101.1.1/LoanCalc"; try { calc = (ILoanCalc) Naming.lookup (url); } catch (Exception e) { System.out.println ("Cannot open remote LoanCalc"); System.out.println (e); } initForm (); / / initialize applet controls

Calling the remote method is no different from calling any other object's method. As shown in Listing 9-11, the method calc.getPayment is called using prin (principal), year, and rate, returning the value pmt (payment). Once the payment is returned, it is formatted into a string, sent to the appropriate applet control, and the repaint method is called to update the display. Since this is a remote object, the call must be wrapped with exception handling. In this example, the error handling just prints error messages, then continues to run. Listing 9-11: Calling a remote method private void calcButtonClicked () { double pmt; / / .. code to convert input fields to Double .. try { pmt = calc.getPayment (prin, year, rate); pmtBox.setText (Double.toString (pmt)); } catch (Exception e)

Using Java to Build Business Objects

{ System.out.println ("Remote call exception"); System.out.println (e); } repaint();

To test the applet, run the LoanCalc.html file from the appletviewer using the following command (typed from the command window on Win NT/95): appletviewer LoanCalc.html By using the command window (or DOS Window for us older folks), you'll see any errors displayed after the command. Note that Microsoft Internet Explorer (at least version 4.0) does not support RMI directly out of the box, but patches are available from Microsoft's Website. To view or use the source files for the Loan Calculator application, see the note on where to obtain program listings at the beginning of the book.

Comparing Distributed Java with Other Middleware Architectures The basic concepts of distributed objects are similar across all of the middleware architectures. Although each uses different terminology, all require some form of interface definition and the code to implement the interface. Each also requires a directory or naming service, a way to register the object into the naming service, and some form of lookup or referencing process to allow programs to access the remote objects. Although there are many different middleware architectures to choose from, the two leading remote architectures are OMG's CORBA and Microsoft's DCOM.

Distributed objects in CORBA The CORBA architecture is quite similar to Java RMI, but with a far greater wealth of prebuilt services. Interfaces are created using an Interface Definition Language, but the implementation for the interface may be coded in any language supported by the CORBA product vendor. Languages typically supported include C, C++, Ada, Java, and COBOL.

219

220

Building Application Servers The interface definition language is a standard specified by the OMG that defines a remote interface by using a language-neutral description. Once the definition is coded, it is nan through one or more IDL compilers, which produce stub and skeleton files similar to what the rmic compiler produces. In addition, the IDL compilers can create language-specific header files that describe the interface in a format readable by the specified programming language, such as header files for C++ or include files for COBOL. Listing 9-12 shows a simple example of an IDL file describing the LoanCalc interface. The first line declares that this is an interface called LoanCalc. If necessary, the interface could inherit attributes and methods from another interface, but this is not required in this example. After the declaration, each method is listed describing the returned data type {double) and the method name (getPayment and getPrincipal) followed by the parameter lists. Note that each parameter is prefaced with the word "in". This indicates that these are input parameters not modified by the method. If the parameters were modified, they would be preceded with inout; output-only parameters would be preceded with "out". Listing 9-12: CORBA IDL for the LoanCalc class interface LoanCalc { double getPayment(in double prin, in double rate, in double year); double getPrincipal (in double prin, in double rate, in double year);

Passing the IDL through the IDL compiler produces header files, stubs, and skeleton code. As an example, Visibroker's IDL2CPP compiler produces C++ source code for each file, including both .cpp and .h files for each (the resulting files are included with the listings for this chapter). Each file must then be compiled to produce stub and skeleton object files. A second compiler, IDL2IR, compiles the IDL into an internal format that is saved into the interface repository. Just as with RMI, a server has to be created to start an instance of the object. Once instantiated, the object is registered to the CORBA Object Request Broker. Listing 9-13 is a short code segment showing how to reg-

Using Java to Build Business Objects

ister a LoanCalc object using Visibroker in C++. (Note: This is sample code only that has not been tested.) The process is similar, but with a little more overhead than with RMI. Listing 9-13: Registering a remote object in CORBA

C0RBA::0RB_ptr orb = C0RBA::0RB_init (argc, argv); C0RBA::B0A_ptr boa = orb->BOA_init (argc, argv); LoanCalc calc; / / create the LoanCalc object boa->object_is_ready (Scale); boa->impl_is_ready (); Once the object is registered, any other program on the network can obtain a pointer to the object and call its methods. This is done in a manner similar to registering the object. An ORB pointer is established, then a call to LoanCalc:-.Bind(part of the stub program) returns a pointer to the LoanCalc object. Of course, this is a very simple example of how CORBA is implemented in a C++ program. The procedure to register and call a remote object is implemented differently, but the basic concepts are similar. With the release of the Java SDK 1.2, Sun has provided better support for CORBA, including class libraries to encapsulate CORBA functions. RMI has also been enhanced to communicate using HOP, CORBA's communication protocol.

Microsoft's DCOM Microsoft's Distributed Component Object Model (DCOM) is the major competitor to CORBA and uses a slightly different approach to distributed objects. DCOM has gone through many different iterations and is still evolving. It uses a strict, rigidly defined set of standard interfaces to provide common functionality for any distributed object. This is both an advantage and a disadvantage. The advantage is that each object will contain a set of interfaces that can be relied upon to provide standardized information and perform standardized functions. The disadvantage is that the programmer must rely on Microsoft tools to add this functionality or take on a very difficult programming challenge.

221

222

Building Application Servers Interfaces are defined using Microsoft's Interface Definition Language (MIDL) that looks and acts similar to the CORBA IDL. Interfaces are usually created automatically by Microsoft's language products, but can be coded manually to define interfaces for legacy applications. One difference between CORBA and Microsoft's IDL is the inclusion of a Globally Unified Identifier (GUID) assigned to each interface. This is a sixteenbyte number that is permanently assigned to a specific release of an interface and becomes the network-wide identifier for the interface. Instead of a naming service, DCOM relies on the Windows registry of both the local and remote computers (remember, DCOM is primarily Windows-specific). The local registry contains names that point to the remote machines, then the registry on the remote machine contains class IDs that point to specific object files (usually .dll's) and interface IDs that are names that map to GUIDs. When a remote object is required, the calling program calls CoCreatelnstance with these ID's. Windows navigates through the various registries, locates the program file and, if it is not already loaded, loads the file into memory. Once loaded into memory, the object resides either in memory or in the swap file until the calling program releases the object. Once the object is released, the Windows operating system checks a counter inside the remote object and, if no other programs are using it, removes the object from memory. Most of the intelligence for life cycle management and managing persistent data is built into the object using DCOM's required interfaces. As DCOM evolves, much of the overhead now needed to handle the required interfaces will be moved to the Windows operating system. Microsoft's COM+ initiative is supposed to begin implementing features like object introspection (similar to JavaBeans) to simplify COM programming. DCOM-to-CORBA bridges are also available to provide interoperability, but at this time, the performance penalty is still prohibitive. If an organization is already committed to the Microsoft platform, DCOM is a viable alternative. The learning curve is steeper, but Microsoft tools like Visual Basic create DCOM-compliant objects much easier, since the gory details are hidden by the tools. In addition, the Microsoft Transaction Server and Microsoft Message Server provide a fairly easy implementation for distributed processing.

Using Java to Build Business Objects

Summary The Java programming environment, with its simple object broker RMI, provides an easy to learn platform for experimenting with distributed objects. Although not as rich in features and services as CORBA or DCOM, it is much easier to learn and will be used throughout the rest of this book to illustrate application server techniques. Some of the most important items to remember when using Java and RMI include: • Java is an object-oriented programming language released by Sun Microsystems that looks, on the surface, a lot like C++. By removing pointers and implementing its own garbage collection process, it eliminates many of the memory management problems encountered when using C++. • The Java specification also includes many APIs (application programming interfaces) that are useful in the application server environment. In addition to RMI (remote method invocation) described above, APIs are also available for database connectivity ODBC), CORBA (included in JDK 1.2) and Enterprise JavaBeans, a server side component standard. • A Java application is formed by creating one or more classes, each containing attributes and methods. When the application is started, the Java runtime environment searches for a method called main, then calls it to begin program execution. • Java applets are classes that can be run from within a Javaenabled Web browser. • The object-oriented features of Java can be used to implement all of the standard class relations including composition, association, and generalization (inheritance). • The following steps are used to create a remote object: 1. Modify the remote interface to inherit remote functions from the RMI base classes and add exception handling. 2. Modify the object implementation to inherit remote functions and add error handling.

223

224

Building Application Servers 3. Pass the class's object file through the rmic compiler to create stub and skeleton files. 4. Create a server application that instantiates the object and notifies the RMI registry of its existence. 5. Create a user interface program that accesses the remote object.

References Petzold, Charles. Programming Windows. Redmond, Washington: Microsoft Press, 1990.

Further Reading Java Programming Ambler, Scott W. "AmbySoft Inc. Java Coding Standards vl7.01b." Available from http://www.ambysoft.com/javaCodingStandards.html Flanagan, David. Java in a Nutshell. Sebastopol, California: O'Reilly & Associates, 1996. Jackson, Jerry R., and Alan L. McLellan. Java by Example. Upper Saddle River, New Jersey: Sunsoft Press, 1996. Sun Microsystems. "Java Software Development Kit (Java SDK)." Available from http://java.sun.com/

Remote Method Invocation Morrison, Michael, and Jerry Ablan. Teach Yourself More Java in 21 Days. Indianapolis, Indiana: Sams.net Publishing, 1997. Sun Microsystems. "Java Remote Method Invocation Specification." Available from http://java.sun.eom/products/jdk/l. 1/docs/guide/rmi/

Using Java to Build Business Objects

spec/rmiTOC.doc.html

CORBA Visigenics. VisiBroker Programmer's Reference for C++. Visigenics, 1998.

DCOM Chappel, David. Understanding ActiveX and OLE. Redmond, Washington: Microsoft Press, 1996.

225

Chapter 10

Persistent Objects: Communicating with Databases The persistent object layer forms the foundation of the application server. This layer is responsible for creating, initializing, and storing business objects derived from relational databases or other external applications. It also serves as the object broker for the application server, tracking and locating business objects already in memory. All of these tasks must be done quickly and efficiently to provide fast response time but must also work carefully to maintain the integrity of the data. When an object is requested, the persistence layer must know how to access the data from a storage medium such as a relational database, then create the requested object from the data. Once the object is created, the new object must be registered into a data structure where it can be quickly located when the same object is requested by another process. The persistence layer must also provide concurrency control and synchronization to ensure that the data remains consistent with the database and other processes and is not corrupted when more than one process attempts to modify the attributes at the same time. The objects must also be synchronized with changes that occur in the database from other external applications so that the database itself is not corrupted. This chapter will illustrate how to create a simple persistent object layer and discuss the implementation and programming issues involved. 227

228

Building Application Servers Although the Java language and JDBC will be used to illustrate the problems and tradeoffs that must be considered, the implementation could just as easily be done using C++ and ODBC. Java was chosen for its simplicity and brevity, not because it is a superior platform. This chapter will examine the following topics: • An overview of JDBC • Creating a persistent object framework • A simple persistent object server • Extending the simple object server • Optimizing the persistence layer

An Overview of JDBC Since the persistent object layer relies on a relational database to store and retrieve the object attributes, we must first examine the technologies available to store and retrieve relational data. Within the Java programming environment, the most common database access approach is through the Java Database Connectivity API (JDBC). This API supports a wide variety of relational database packages, either through custom drivers supplied by the database vendor or through the JDBC-ODBC (Microsoft's Open Database Connectivity) bridge supplied in the Java SDK. A Java program can use the JDBC classes to create a connection to a relational database, then pass commands through the class to the relational database.

JDBC architecture The JDBC uses a layered architecture to gain access to relational databases (see Figure 10-1). To access a database server, the Java program first imports the java.sql package that contains the JDBC classes. These classes include connections, statements, result sets, and the other core JDBC classes. Once the classes are imported, the program declares the JDBC driver to be used by the JDBC classes to interface to a specific database server. These drivers may be supplied by the database vendor or other third party vendors. In addition to vendor supplied drivers, Sun provides

Persistent Objects: Communicating with Databases

the JDBC-ODBC bridge driver, which allows JDBC calls to be passed on to ODBC drivers within the Microsoft Windows environment. Vendor-supplied drivers come in several different architectures, each described by a type number from 1 to 4 (Kara 1999). These are as follows: 1. JDBC-ODBC bridge 2. Native API drivers 3. Net Protocol drivers 4. Native Protocol drivers The type 1 driver, the JDBC-ODBC bridge, translates Java methods into ODBC calls that are then translated by an ODBC driver into database calls. This is a good general-purpose solution that allows easy interchange of back-end databases, but it can cause performance problems, since the call is translated three times: once through the JDBC-ODBC

Java Program

JDBC Classes

Vendor Supplied JDBC Drivers

ODBC-JDBC Driver

ODBC Drivers

Sybase

Oracle

Figure 10-1. JDBC architecture

SQL Server

dBase

229

230

Building Application Servers bridge, once through the ODBC driver, and once through the database server. Type 2 drivers reside on the client machine and rely on native, vendor-supplied drivers to perform network communication and to call database server functions. These are more efficient than the type 1 drivers but must be installed locally on every workstation. Type 3 and 4 drivers provide their own Java-based network communication protocols. Type 3 drivers use a three-tiered architecture that sends Java-based network communication to a separate JDBC server. This server then calls either ODBC or native vendor database drivers. This eliminates the need to install ODBC or vendor-specific drivers on each workstation. Instead, the JDBC driver is written in Java and can be downloaded along with the applet or application. Type 4 drivers use the Java language to implement vendor-specific database communication protocols and database interfaces directly into the JDBC driver. Like type 3 drivers, this allows the driver to be downloaded along with the applet or application; but it calls the database server directly, eliminating the middle tier. This solution is limited to vendor-specific solutions, since the database protocol is embedded directly into the driver. In the application server environment, workstations do not directly communicate with database servers, and all requests pass through the application server before any database activity is required. Type 3 drivers should be avoided, since they require an additional server layer between the application server and the database server. This adds processes and network traffic that are already provided by the application server. Type 2 or 4 drivers that rely on vendor-provided database drivers are usually the best, since they streamline communication directly from the application server to the database server. Type 1 and type 2 drivers that rely on ODBC for database communications are not as efficient as native drivers but do provide some advantages in a multi-vendor environment. Also, ODBC drivers are available for a variety of data sources that are not normally considered relational database servers such as dBase, Excel, and text files.

SQL basics SQL (Structured Query Language) is the standard command language for relational databases. This language is familiar to most client/server programmers, so I'll provide only a cursory examination of the language in

Persistent Objects: Communicating with Databases

this section. For more detail, consult the documentation provided by your database vendor or check the references at the end of this chapter. Although the language has many complexities, the basics of data manipulation are found in four statements: • Select—select rows from one or more tables • Insert—add rows to a table • Update—update rows from one or more tables • Delete—delete rows from one or more tables Select The select statement retrieves data from one or more tables and places them into a result set that most often resides in a temporary table held in memory. The following is a typical select command: SELECT Customer, Name, Phone FROM Customers WHERE State = 'CO' ORDER BY Name The columns Customer, Name and Phone are selected from the Customers table for those customers who reside in the state of Colorado (CO), then are sorted in alphabetical order by name. Note that in these examples, all SQL keywords are entered in uppercase letters. This is not a requirement of SQL (the language is not case-sensitive), but a convention to make the code easier to read. Insert The insert statement allows new data to be added into tables. Data can be either entered as data values or can be retrieved from other tables. The following example enters new data into a customer table: INSERT INTO Customers (Customer, Name, Phone, Add_Date) VALUES ('10001','Fred Smith','(123) 456-7890', '03/15/2000')

231

232

Building Application Servers This statement creates a new row in the Customers table with customer number 10001, name "Fred Smith" and phone number (123) 456-7890. If other columns exist in the table, they are initialized either to default values specified when the table was created or will be initialized to null values. Data can also be copied from one table to another using an alternate form of the insert statement. The following statement archives old data into a customer history table: INSERT INTO Customer_History (Customer, Name, Phone, Add_Date) SELECT Customer, Name, Phone, Add_Date FROM Customers WHERE Add_Date < '01/01/2000' This command finds a result set using a select statement that locates the name, phone, and add date from customer table rows that have an add date before January 1, 2000. Once this result set is found, each row is inserted into the Customer_History table. Note that this command only copies the data; nothing changes in the Customers table.

Update Columns in selected rows can be updated with either fixed values, columns from other tables, or calculated results by using the update command. The following command pulls inventory from order items: UPDATE Inventoryjtems SET LastJJpdate = '03/02/2000', 0n_Hand = 0n_Hand - 0rder_Quantity FROM Inventoryjtems, Orderjtems WHERE InventoryJtems.Product = OrderJtems.Product AND 0pen_0rder = TRUE AND 0n_Hand >= Order_Quantity This command gets a little more complex and is best understood by starting from the middle. The Inventoryjtems table will be updated based on the contents of the Orderjtems table by matching each order item to a corresponding inventory item by product number. When more than one table shares a common column name, each column name must be pre-

Persistent Objects: Communicating with Databases

ceded by the table name, followed by a period (InventoryJtems.Product). Additional qualifiers are required to ensure that each order item is from an open order (OpenjOrder = TRUE) and that the quantity on hand is sufficient to fill the order (On_Hand >= Order_Quantity). Once all of these criteria are met, the last update date is set to a specific date (03/02/2000) and the order quantity is subtracted from the quantity on hand. As can be seen, SQL can perform very powerful data transformations.

Delete The delete command is similar to the update command. Selected rows are removed based on a set of conditions listed in the where clause. The following command removes the customers that were archived in the second insert example: DELETE FROM Customers WHERE Add.Date < '01/01/2000' Any row in the Customers table that has an add date less than '01/01/2000' is removed from the table. SQL is a powerful language that has matured over many years. These examples are relatively simple and only show the basic operations that will be needed to create persistent objects. Commands are also available to manipulate table structures, implement complex security, and create stored procedures. Again, check the list of references at the end of this chapter for more information on SQL programming.

Basic JDBC programming JDBC is a relatively simple database API, relying on the SQL language to pass commands to a database server. Once a driver is declared and a connection is established, the programmer obtains a statement object that can be used to pass SQL commands to the database server. Results are returned in a ResultSet object that encapsulates a table structure containing the rows and columns of the result set. Data transformations are performed through SQL commands sent as ASCII strings. With a little knowledge of SQL and the basic API objects, it is relatively easy to access relational data.

233

234

Building Application Servers This section will again provide a simple example of how to access data using JDBC. It provides a cookbook approach to database access, focusing on how to use the API methods, with little theory describing what happens when each method is executed. See the list of references at the end of the chapter for much more detailed discussions on how to use JDBC. Listing 10-1 shows a simple Java application that connects to a Microsoft Access database using the JDBC-ODBC bridge. The database, named OrderEntry, contains a table called Customers that has columns Customer, Name and Phone, each text strings of various lengths. Before the database can be accessed by the ODBC driver, it must be registered into the ODBC data source administration program. The Appendix, "Setting up a Development Environment," describes the procedures for installing the JDBC-ODBC drivers and registering databases. Listing 10-1: Simple JDBC application import java.sql.*; public class JdbcExample { public static void main(String[] args) throws Exception { / / set driver name Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); / / open the connection Connection conn = DriverManager.getConnection ("jdbc:odbc:OrderEntry", "admin", "password"); / / create a statement Statement stmt = conn.createStatement(); try { / / execute SQL command stmt.execute ("SELECT Customer, Name, Phone FROM Customers"); / / get the result set ResultSet rs = stmt.getResultSet(); / / loop through result set and display data

Persistent Objects: Communicating with Databases

while (rs.next()) { System.out.print (rs.getString ("Customer")); System.out.print (","); System.out.print (rs.getString ("Name")); System.out.print (","); System.out.println (rs.getString ("Phone"));

catch (SQLException e) { System.err.println ("SQL Error: " + e.toString());

/ / close statement and connection stmt.close(); conn.close();

} / / end jdbc class The JDBC API resides in the java.sql package. The line import java.sql.* makes these objects accessible to the Java program. When the application starts the main method, the first step required is to establish the location of the JDBC driver library. In this example, the JDBC-ODBC bridge driver is selected using the declaration: Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); There are several other alternative methods for declaring an ODBC driver, either programmatically or through the Java runtime command line or browser initialization files, but the one shown here seems to be the most common method described in the literature. Notice that the main method has the throws Exception clause. JDBC relies heavily on exception handling to report error conditions. Most of these exception conditions will not occur if the program has been coded correctly, but since JDBC does rely on external database servers and networks, errors may occur. Each exception must be handled appropriately

235

236

Building Application Servers and either logged or reported back to the user. For the examples in this chapter, exception handling is either passed back to the runtime environment or is simply reported to the standard error display. Once the driver is declared, a Connection object is created that establishes a connection to the database. The Connection object is retrieved using the statement: Connection conn = DriverManager.getConnection ("jdbc:odbc:OrderEntry", "admin", "password"); In this case, the Connection object conn establishes a connection to the OrderEntry database with user name "admin" and password "password". The connection is retrieved using the getConnection method of the DriverManager class. The database name can be either a string, such as "jdbeodbcOrderEntry" shown in the example, or it can be an Internet URL if the database server resides on a remote machine. To execute a SQL command, a Statement object must first be retrieved from the Connection object using the connection's createStatement method. The Statement object can then be used to execute a SQL command that is stored in a string object. These SQL statements can include any SQL command supported by the database server, including selects, inserts, updates, deletes, or stored procedure calls. The Statement object has three separate execute commands. These are: • execute—execute a SQL query that returns multiple rows of data • executeQuery—execute a SQL query that returns a single row of data • executeUpdate—execute a SQL command that updates or deletes data In this example, the statement's execute method is called to retrieve several customer entries using the SQL command: SELECT Customer, Name, Phone FROM Customers This command will retrieve the customer number, name and phone number from the Customers table and does not specify the order in which the data is returned. After the execute method completes, the results are placed in a result set that can be obtained using the Statement object's getResultSet method.

Persistent Objects: Communicating with Databases

ResultSet rs = stmt.getResultSet(); The ResultSet object rs now contains the data returned from the database server as a result of sending this SQL command. A simple while loop is set up to retrieve and display the result set. This loop first calls the next method of the ResultSet object to move the record position pointer to the next entry, then uses the System.out.print method to send each column of data to the console display. The next method will return false after the last row is returned, and this will terminate the while loop. When a result set is retrieved with the getResultSet method, the initial position pointer is set prior to the first row so the next method must be called before any data will be accessible from the result set. Once the position pointer is set to a row of data, there are a number of different methods that can be used to retrieve the data, depending on the data type. In this example the getString method is used to retrieve string objects. There are also methods that include getlnt, getLong, getBoolean, getDate, getTime, and many more. Each returns the data in the type of object specified. Notice that the SQL processing is enclosed in a try/catch block from the time the statement is executed until the last row is displayed. This set of instructions provides a logical grouping around the data retrieval process. A failure at any point in this set of instructions will cause any subsequent code to fail. By wrapping a try/catch block around this sequence of code, any errors will be caught and execution will be terminated before there are any additional problems. When an error occurs, the text of the error is displayed on the standard error device and execution will continue at the close methods. Whether an error occurs or not, the close methods are called for both the Statement and Connection objects to release the resources and close the connection. Although this is a quick overview of JDBC, it covers much of the functionality available in the API. Additional features are available to gather information about existing table structures, column formats, and other structural information. The API also supports prepared statements—precompiling a SQL command, then repeatedly executing the same command with different parameter values. This is useful in the application server environment when storing a collection of objects back into a single table, and it will be illustrated later in this chapter.

237

238

Building Application Servers

Other database middleware Just because I've chosen JDBC to represent the programming issues inherent in application server design does not mean that it is the only choice available. Other database middleware choices include ODBC, IDAPI, database gateways, and proprietary APIs, as well as other database middleware. The choice depends on the database and development tools selected and the functionality desired in a database API. ODBC was one of the first Windows-based, general-purpose database middleware APIs, and it has gained general acceptance throughout the industry, (Whiting, Morgan, and Perkins 1996). Although it is based on the C programming language, it uses a similar programming model to JDBC, establishing connections, executing SQL commands, and receiving result sets. ODBC does provide some additional functionality in its ability to update result sets without having to execute additional SQL commands, but most of the functionality is similar to that provided by JDBC. JDBC and ODBC are both excellent platform-independent database access solutions, and both choices offer a variety of development tools and support products. Almost every PC-based programming platform supports one or the other APIs and provides wizards or class frameworks that encapsulate the API. This makes it even easier to write code that accesses these data sources. Much of the code to provide the persistence layer with database connectivity can be automatically generated, allowing clean, efficient access to the database.

Creating a Persistent Object Framework Chapter 6 gave an overview of the design issues involved in creating a persistence layer for an application server. Given this general design framework and the background in JDBC described above, we can investigate how to turn this general design into program code. You can take any number of approaches, and several will be explored in this section (Reference 10-3 shows an excellent alternative). Choosing the best approach depends on the number of objects, both classes and instances; the length of each object's life cycle; the amount of concurrency required; and the complexity of the class hierarchy. This section will explore a couple of different examples based on a simple order entry object structure with an invoice, customer and a collection

Persistent Objects: Communicating with Databases

239

of order items (see Figure 10-3 later in the chapter). The first example will show the basic structure of a persistent object server that serves up a single object class. The next will show how to expand this basic model to increase the number of object classes and also serve up complex objects. Both examples will be illustrated with small code sections describing particular classes or methods, and both full persistent object implementations are included in the program listings for this chapter. See the Introduction at the beginning of the book for instructions on obtaining these files.

A Simple Persistent Object Server Figure 10-2 shows the design of a simple persistent object layer. It is similar to the one described in Chapter 7, but has been augmented to be compatible with the Java language. The object server takes requests from either the service interface or other business objects through the find method. This method receives the name of the object and a unique identifier that can be used to locate the specific data needed to initialize the object.

Collectionltem

Hashtable 1 get put remove Customer Server

findCustomer releaseCustomer

CustomerTable connection find

save delete

Figure 10-2. Simple persistence layer design

0..*

Customer

refCount getCustomer addReference releaseReference

>

240

Building Application Servers As an example, the service interface may request customer 1001. The findCustomer method locates the data for customer 1001, creates a new Customer object that encapsulates this information, then returns a reference to this object. Once the service interface is finished with the Customer object, it uses the releaseCustomer method to indicate that it no longer needs this Customer object. The releaseCustomer method stores the data back into the database; then, if there are no other objects or interfaces using the object, removes it from memory. The object server provides two basic functions; it first creates and store objects from or to the relational data, then it tracks the objects currently in memory. By tracking the objects, there is no possibility that duplicate objects exist that may corrupt the data. Creating and storing objects is the responsibility of a set of table objects, each supporting creation and storage of a specific business object class. When a new object is required, the table object will gather the data from the database and create a new instance of the object. This is passed back to the object server where it is stored in a collection object that tracks all objects currently in memory.

joining business objects with relational databases Creating customer objects from the relational data is the job of the CustomerTable object. This object is modeled after a typical collection object with find, save, and delete methods. The difference between a typical memory-based object collection and the CustomerTable is that the table objects use JDBC to load and store the data in a relational database. Once the data is loaded from the database it is packaged into a customer object that can be passed back to the CustomerServer object. The class constructor is responsible for setting up the connection to the database (see Listing 10-2). This connection is stored in a private attribute called conn, which is initialized by the constructor and closed by the finalizer method. A finalizer method is similar to a C++ destructor and is executed when the class is removed, either by going out of scope or by the garbage collector. Note that in all of these examples, the exception handling code has been removed. To compile correctly, try/catch blocks must be placed around each method implementation.

Persistent Objects: Communicating with Databases Listing 10-2: CustomerTable class import java.sql.*; public class CustomerTable { private Connection conn; //

constructor

public CustomerTable() { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); conn = DriverManager.getConnection ("jdbc:odbc:OrderEntry", "admin", "password"); } / / finalizer - execute when class is removed from memory public void finalize() { conn.close(); } / / find a specific customer public Customer find (String cust) { Customer c; Statement stmt = conn.createStatement(); String sql = "SELECT * FROM Customers WHERE Customer = '" + cust + "'"; stmt.execute (sql); ResultSet rs = stmt.getResultSet(); if (rs.next()) { c = new Customer (rs.getString ("Customer"), rs.getString ("Name"), rs.getString ("Address"), rs.getString ("City"),

241

242

Building Application Servers rs.getString ("State"), rs.getString ("Zip_Code"), rs.getString ("Phone")); } else c = null; stmt.close(); return c;

/ / save the customer public void save (Customer c) Statement stmt = conn.createStatement(); String sql = "SELECT * FROM Customers WHERE Customer = '" + c.getCustomer() + "'"; stmt.execute (sql); ResultSet rs = stmt.getResultSet(); if (rs.next()) { sql = "UPDATE Customers SET " + "Name = '" + c.getName() + "', " + "Address = '" + c.getAddress() + "', " + "City = '" + c.getCity() + "', " + "State = "' + c.getState() + "', " + "Zip_Code = '" + c.getZip() + "', " + "Phone = "' + c.getPhone() + "' " + "WHERE Customer = '" + c.getCustomer() + '""; else { sql = "INSERT INTO Customers " + "(Customer, Name, Address, " + "City, State, Zip_Code, Phone) VALUES ('" + c.getCustomerO + "','" + c.getNameO + '",'" + c.getAddress() + "','" + c.getCity() + "', "'

Persistent Objects: Communicating with Databases c.getState() + "','" c.getZip() + "','" c.getPhone() +'")";

stmt.executeUpdate(sql); stmt.close();

/ / delete the customer object public void delete (Customer c) { Statement stmt = conn.createStatement(); String sql = "DELETE FROM Customers WHERE Customer = '" + c.getCustomer() + "'"; stmt.executeUpdate (sql); stmt.close(); } } / / end CustomerTable class The find method is called to retrieve new Customer objects derived from the data in the Customers table. A string containing the customer number is passed to the find method, which then returns a Customer object containing the data found in the database. If the customer number is not in the database, a null reference is returned. After a Statement object is returned from the createStatement method of the Connection object, a SQL command is built to retrieve the data for the customer number. Creating the SQL command is slightly confusing, since the customer number must be embedded in single quote ('1005') characters within SQL while at the same time string literals must be encased between double quotes ("string") within the Java language. If the customer number passed to the find method is customer 10001, the Java program line: "SELECT * FROM Customers WHERE Customer = '" + cust + "'"; will result in a SQL command that looks like:

243

244

Building Application Servers SELECT * FROM Customers WHERE Customer = '1000' Note that the asterisk (*) in the place of the column list indicates that all columns accessible from the table are requested. Once the SQL statement is executed and a result set is returned, the result set's next method can be called to see if any data was found. If no data was found, the null reference is stored into the Customer object; otherwise, a new Customer object is built using the result set's getString method to retrieve each data item. Once this is complete, the Statement object is closed and a reference to the Customer object is returned to the calling program. Saving a Customer object is somewhat the reverse of the find operation. Listing 10-3 shows how the customer information is formatted into a SQL statement that updates the customer data using a Statement object obtained from the connection. A similar command is formatted when a new customer is added (refer back to Listing 10-2). In this case the executeUpdate method is called to store the data into the customer table. Listing 10-3: Formatting a SQL update command sql = "UPDATE Customers SET " + "Name = '" + c.getName() + "', " + "Address = '" + c.getAddress() + "', " + "City = '" + c.getCityO + "', " + "State = '" + c.getState() + "', " + "Zip_Code = '" + c.getZip() + "', " + "Phone = '" + c.getPhoneO + ' " " + "WHERE Customer = '" + c.getCustomerQ + "'";

To simplify programming in the customer server implementation, the save method first checks to see if the customer entry exists. If it does, then an update command is built using the data found in the Customer data object. Assuming that the Customer object represents customer number 10001, this command will read something like: UPDATE Customers SET Name = 'Fred Jones', Address = '1234 S. Main', City = 'Denver', State = 'CO', Zip = '80123', Phone = '(123) 456-7890' WHERE Customer = '10001'

Persistent Objects: Communicating with Databases

This SQL command will store any changes that have been made to the Customer object's attributes back into the database. If the customer entry does not yet exist in the database, the method will create a SQL insert command such as: INSERT INTO Customers (Customer, Name, Address, City, State, Zip_Code, Phone) VALUES ('10001', 'Fred Smith', '1234 S. Main', 'Denver7, 'CO', '80123', '(123) 456-7890') Once the SQL string is formatted, it is executed using an executeUpdate method, then the Statement object is closed. A similar method is also available to delete customer entries from the table. This method from Listing 10-2, repeated in listing 10-4, simply creates a SQL delete statement then uses the executeUpdate method to execute the SQL command. Listing 10-4: Customer table delete method public void delete (Customer c) { Statement stmt = conn.createStatement(); String sql = "DELETE FROM Customers WHERE Customer = "' + c.getCustomer() + "'"; stmt.executeUpdate (sql); stmt.close();

Creating objects that map the relational data into business objects isn't difficult, just time-consuming. The framework shown above can easily be modified to handle most object to database mappings where a single object maps to a single table entry. Other object mappings will be explored later in this chapter.

Tracking business objects Once a Customer object is created, it must be stored in a collection so that subsequent requests for the same customer number can return a reference to the same object. This not only reduces memory requirements, but it

245

246

Building Application Servers also ensures consistency between multiple users. A change in an object is immediately available to any other service that references the same object. This example will rely on a Hashtable object to manage the collection. The hash table is included in the Java class library and implements an indexed list of objects. It is similar to the MapObjectToObject collection available in Microsoft's MFC, and provides an efficient way to store and retrieve objects by some type of key value. After each Customer object is retrieved from the database, it is stored, by customer number, into the hash table. When a subsequent request is made for the same customer number, the hash table can quickly locate the object and return its reference. The hash table provides many methods for accessing the collection, but only a few of the methods will be used here. These include: • put (string, object)—store an object into the collection, indexed by a string • object = get (string)—retrieve an object from the collection by the index string • remove (string)—remove the object from the collection by the index string Technically, the index is also an object, but for this example, a string containing the customer number is used. The put method stores an object into the collection using the string as an index. The string is run through a hashing algorithm that converts it into a numeric index that then becomes the table location where the object is stored. When the Customer object is retrieved from the collection, the get method uses the same hashing algorithm to find the location of the object, then return its reference back to the calling program. The remove method also uses the hashing algorithm to locate the object then remove it from the collection. As described earlier, you must maintain a reference counter that is incremented by each retrieval and decremented when the object is released. When the reference count returns to zero, the object is deleted from the hash table. The ideal way to implement this reference counter is to include it as part of the collection that stores the objects. Since this example relies on a prewritten hash table, this is not an option, so other alternatives must be explored. One option would be to require each Customer object to maintain its own reference counter, but this is the responsibility of the collection, not the Customer object. Another option

Persistent Objects: Communicating with Databases

is to implement the reference counter into a base class, then require all objects to inherit this functionality. This could be done in this simple example, but as the number of classes increase and complex objects are implemented, it restricts and complicates the object design. The solution used in this example is to create a wrapper that holds both the Customer object (or any other object) and also maintains the reference counter. This aggregation process enables each object to do its own job without having to worry about the requirements of the collection. Listing 10-5 shows the implementation of the Collectionltem wrapper. Listing 10-5: Collectionltem implementation public class Collectionltem { private Customer cust; private int refCount; public Collectionltem (Customer c) { cust = c; refCount = 1;

public Customer getCustomer () {return cust;

public int addReference () { refCount++; return refCount;

public int releaseReference () { if (refCount>0) refCount--; return refCount;

} / / end class Collectionltem

247

248

Building Application Servers The Collectionltem class is relatively straightforward. Each new instance stores a Customer object and sets the reference count to 1. Methods are available to retrieve the Customer object (getCustomer), add an additional reference (addReference) and to release a reference (releaseReference). When a reference is added or released, the method returns the resulting reference count. This is used in the release method of the persistent object server to determine when it is time to remove an object from memory.

Serving up customer objects Once the structures are in place, it is now relatively easy to serve up customer objects. The customer server class has two attributes, each initialized by the constructor method. The first is a hash table, custCollection, that holds Collectionltem objects, each containing a unique customer object. The second is the customer table object, custTable, used to map customer data from the database to the customer object. ThefindCustomermethod (Listing 10-6) locates a Customer object by its customer number and returns it back to the calling program. The method first attempts to locate the Customer object from the hash table using the hash table's get method. If it is found, the reference counter is incremented, then the Customer object is extracted from the collection item and is then passed back to the calling program. If it cannot be located from the hash table, a request is made to retrieve a new Customer object from the customer table. If found, it is placed into a new customer collection object and inserted into the hash table using the put method. Listing 10-6: Customer server findCustomer implementation public Customer findCustomer (String cust) { Customer c; Collectionltem cltm = (Collectionltem)custCollection.get(cust); if (cltm == null) { c = custTable.find (cust); if (c = null) return null; Collectionltem cltem = new Collectionltem();

Persistent Objects: Communicating with Databases custCollection.put(cust, cltem); } else { c = cItm.getCustomer(); cItm.addReference(); } return c;

Examining the code in more detail, we see that the get method is used to attempt to retrieve an object from the hash table custCoUection using the customer number passed by the calling program. If an object is found, it must first be cast to a collection item object, then the reference is placed in the collection object cltm. If a null value is found, this indicates that the customer was not in the collection. Skipping down past the else, we see that if it was found, the customer object is extracted and the reference count is incremented. If a null value is found (back up to the if null test), this indicates that the object was not found in the collection and must be retrieved instead using the find method of the customer table. Once the new Customer object is retrieved, it is inserted into a collection item object and is added to the hash table. The resulting Customer object is passed back to the calling program. The releaseCustomer method (Listing 10-7) is somewhat more straightforward. The customer data is stored back into the database using the customer table's store method. Once this is done, the collection item is retrieved by customer number and its releaseReference method is called. If there are no other references to this customer (the releaseReference method returns zero), the entry is removed from the hash table using the remove method. Listing 10-7: Customer server releaseCustomer implementation public void releaseCustomer (Customer c) { custTable.save(); Collectionltem cltm = (CollectionItem)custCollection.get(c.getCustomer()); if (cltm != null)

249

250

Building Application Servers { if (cItm.releaseReference() = 0) custCollection.remove (c.getCustomer());

Extending the Simple Object Server The customer server illustrates the basic techniques needed to load and store objects from a database as well as how to track them using a hash table. These are both relatively straightforward and require only a small amount of code to implement. Building a more comprehensive persistent object server will require serving up a variety of different object classes, often requiring multiple objects from a single database request and aggregating these objects into more complex relationships. Each of these requirements adds complexity to the object server and must be considered when building the persistence layer.

Adding more objects The first requirement is to serve up a variety of different object classes. This is relatively easy, since each additional class simply adds another table object to load and store objects from the database. The same collection object can store a variety of different object types with few additional changes. Adding additional table objects is relatively easy. Simply follow the same pattern that was used in the customer table implementation. You will need to move connection handling up to the object server, and you'll need a strategy for pooling and distributing database connections to optimize throughput. This will be discussed later in this chapter. Depending on the complexity of the database middleware, it may be advisable to create a base class that implements most of the database interface, then allow each table object to inherit this functionality from the base class. You could add private virtual methods to encapsulate the SQL statements and create the new classes, then generalize the remaining code so that it could be inherited from the base class. Since Java and JDBC are relatively straightforward, this is not really necessary; but for more complex applications, this may simplify the development process. Scott

Persistent Objects: Communicating with Databases

Ambler's "Robust Persistent Layer" series shows how to create a completely configurable, industrial-strength persistence layer (Ambler 1998). To track a variety of objects, you can store each in the same hash table, but you'll have to enhance the index key to represent both the class type and the data identifier. When a customer is stored, the key could read CUST10001 instead of just 10001. When an invoice is added, it could be indexed as INV591257567 or something similar. As long as you define a standard indexing identifier, you can store any number of different objects in the same collection. Finally, you'll have to modify the front end of the object server to serve up multiple classes. This can be done either through common findObject and releaseObject methods or by adding more unique methods such as findlnvoice and releaselnvoice. My preference is the second, since each method then implements only the code needed to serve up or release a single object. Designing one common service will add complexity and limit maintainability, as requests are either sorted and passed on to other methods or code is generalized to serve up a variety of different classes. The decision will depend on the number of classes that must be served up, the complexity of the objects, and the number of different data sources.

Serving up multiple objects from the same query Often, you'll need to retrieve more than one object at a time from a single query. This is necessary when gathering data to populate a pull-down list or when you need multiple related detail lines, such as invoice line items. The same code used to retrieve a single object can be easily enhanced to retrieve multiple rows. Each row can be encapsulated in an object, then all of the objects can be passed back as a single collection. Listing 10-8 illustrates these enhancements. Listing 10-8: Retrieving multiple objects public Vector find (String inv) { Vector orderList; orderList = new Vector();

251

252

Building Application Servers Statement stmt = conn.createStatement(); String sql = "SELECT * FROM OrderJtems " + "WHERE Invoice = "' + inv + '" ORDER BY Sequence"; stmt.execute (sql); ResultSet rs = stmt.getResultSet(); while (rs.next()) { orderList.addElement (new Orderltem (rs.getString ("Product"), rs.getlnt ("Quantity"), rs.getFloat ("Unit_Price"))); } stmt.close(); return orderList;

This is the find method for a class called OrderltemTable. The Orderlitem objects each contain a single product ordered within an invoice. To retrieve an invoice from the database, all related order items will have to be retrieved at the same time, then added into the Invoice object. One alternative would be to build a database interface object that would both create the invoice and then load the order items at the same time. This is a reasonable option, but it does produce a set of rather complex methods. By isolating the order item retrievals into a single method, you make all of the code to retrieve the invoice more readable. The method starts by obtaining a Statement object that will be used to retrieve all of the order item rows having the invoice number requested. Note that the SQL statement used includes the ORDER BY clause to sort the rows by sequence number. This ensures that the rows will appear in the same order that they were entered. Once the query is executed, the rows are retrieved by the getResultSet method. The while loop retrieves each row individually, creates a new Orderltem object, and stores it into a vector. Once all rows are retrieved, the vector containing all of the Orderltem objects is returned to the calling program. A vector is a collection object defined in the Java class library in the java.util package that implements an expandable array. There is no need to define the array type or size, since it can hold any Java object and expands as each new item is added. The addElement method expands the

Persistent Objects: Communicating with Databases

size of the vector, then adds the object to the end of the list. Once the vector is returned to the calling program, the number of objects can be retrieved using the vector's size method; each object can be extracted using the elementAt method, passing element numbers which start at 0. To store the data back into the database, the programmer can choose to either create methods that store each object individually (in this case using the invoice and sequence number) or create a method that receives a vector and update all items at the same time. Listing 10-9 illustrates a method that stores all of the items at once. Listing 10-9: Storing multiple objects public void save (String invoice, Vector orderList) { Statement stint = conn.createStatement(); String sql = "DELETE FROM Orderjtems WHERE Invoice = '" + invoice + "'"; stmt.executeUpdate(sql); stmt.close(); sql = "INSERT INTO Orderjtems " + "(Invoice, Sequence, Product, Quantity," + "Unit_Price)" + " VALUES (?, ?, ?, ?, ?)"; PreparedStatement pstmt = conn.prepareStatement(sql); for (int itm=0; itm < orderList.size(); itm++) { Orderltem o = (Orderltem) orderList.elementAt(itm); pstmt.setString(l, invoice); pstmt.setlnt (2, itm+1); pstmt.setString(3, o.getProduct()); pstmt.setlnt (4, o.getQuantity()); pstmt.setDouble(5, o.getUnitPrice()); pstmt.executeUpdate(); } pstmt.close();

253

254

Building Application Servers When modifying an invoice, some lines may be removed and new lines may be added. Since it is difficult to track these changes, the easiest approach is to delete all of the items then re-add them from the vector. The save method illustrated in Listing 10-9 uses this approach. The save method creates a SQL statement that first deletes all order items for the invoice number; the method then stores each item in the vector back into the database. At the same time, it assigns new sequence numbers starting with number 1. To store the vector of order items back into the Order Jtems table, the save method relies on JDBC's PreparedStatement object. A prepared statement enables the programmer to define a parameterized SQL statement that can be run multiple times, substituting new data values before each execution. As the program loops through the vector, the attributes of each order item are set into the prepared statement: then when all items are loaded, an executeUpdate method is called to store these values to the database. Setting up a prepared statement is done by creating a SQL statement that replaces each data value with a question mark, as this example illustrates: INSERT INTO Orderjtems (Invoice, Sequence, Product, Quantity, Unit_Price) VALUES (?, ?, ?, ?, ?) This statement is then passed to the prepareStatement method of the Connection object and returns a PreparedStatement object. This PreparedStatement object now contains the basic structure of the query and has methods that allow substitution of parameters before each executeUpdate method is called. Each parameter is given a number starting with 1. In this example, parameter 1 is the invoice number, parameter 2 is the sequence, and parameters continue, with parameter 5 being the unit price. Parameters are set using the set xx*methods such as setString for string objects, setlnt for integers, etc. Once all parameters are set, the executeUpdate method sends the SQL command to the database server. The save method repeats this process for each Orderltem object stored in the vector, using the vector's elementAt method to retrieve each item. The size method is used to determine the number of order items stored in the vector. Note that both the find and save methods have been simplified, removing exception handling to make the code more readable. To see the actual implementation of these methods, consult the full pro-

Persistent Objects: Communicating with Databases

gram listings. Instructions describing how to obtain these listings are included in the Introduction at the beginning of the book.

Serving up complex objects Most business objects are constructed by aggregations and relations. Reassembling complex business objects requires that each object is retrieved individually then assembled back together. When retrieving complex objects, it may take multiple passes, first issuing complex queries to determine the data needed and then using this information as a blueprint to retrieve the individual business objects. Once these are retrieved, the object hierarchy can be reassembled. As the lower-level objects are retrieved, many will have to be shared across multiple complex objects (such as customers or product objects) so each will have to be registered into the collection individually as well as assembled into the class hierarchy. Figure 10-3 shows a simplified class diagram for an Invoice object. This is a relatively simple business object, but it will illustrate the difficulties that arise when trying to load and store complex business objects. The high-level Invoice object aggregates a Customer object, which may also be used by other Invoice objects. The invoice also has an association with a collection of Orderlitems which are associated with their corresponding Product objects. In the program code below, the association to the Product objects will be ignored, but the issues involved in establishing this association will be discussed later. Assembling this object from the database begins by first retrieving the invoice data and creating a skeleton invoice. Next, the Customer object is located using a process similar to the findCustomer method illustrated above. Since the Customer object can be shared by multiple business objects, it must be tracked in the object collection independent of the Invoice object, while still being aggregated into the Invoice object. Once the Customer object is retrieved, either from the collection or from the database, it is stored as an attribute of the Invoice object. Finally, the order items must be retrieved from the database using the process shown in listing 10-9. Each Orderltem object is then copied from the vector into the Invoice object by using the addltem method of the Invoice object. Finally, the new invoice item is registered into the object collection.

255

256

Building Application Servers

1 Invoice

1..* Order Item

Customer ""Product I

Figure 10-3. Invoke business object structure

Listing 10-10 shows a Java implementation of this process. The method shown is part of the objectServer object, which can be accessed by the service interface (the entire objectServer implementation is included with the program listings for this chapter). The getinvoice method receives a string that contains an invoice number. The method begins by trying to locate the object in the objectltems collection (similar to the custCollection collection in the previous example). If it is found, the invoice already exists in memory and a reference to the object can be returned to the calling program. If the object is not currently in memory, it is retrieved from the database using the find method of the InvoiceTable object. The InvoiceTable is responsible for storing and retrieving invoices from the database. Its find method will locate and retrieve the data from the invoice table and create an Invoice object that contains everything but the customer and the order items. Listing 10-10: Loading the Invoice object public Invoice getinvoice (String inv) { Invoice invoice; Collectionltem invltem =

Persistent Objects: Communicating with Databases (CollectionItem)objectItems.get("INV" + inv); if (invltem == null) {invoice = invoiceTable.find(inv); if (invoice == null) return null; Customer cust = getCustomer(invoiceTable.findCustomer(inv)); invoice.setCustomer (cust); Vector orderltems = orderTable.find(inv); if(orderltems.size() > 0) { for (int i=0; i
invltem = new Collectionltem(invoice); objectltems.put ("INV" + inv, invltem); } else { invoice = (Invoice) invItem.getObject(); invItem.addReference(); } return invoice;

If the invoice is not on file, the method returns a null reference back to the calling program and quits. If it does find an invoice, it makes a second method call to retrieve the customer number, then passes it to the findCustomer method of the objectServer to retrieve the Customer object. The findCustomer method is the same one shown in Listing 10-7. The Customer object is then inserted into the invoice using its setCustomer method. Next, a vector called orderltems is loaded using the find method from the Orderltem object (Listing 10-8). If order items are found, they are each copied into the Invoice object using its addltem method. Now that the Invoice object has been reassembled, it is registered into the objectltem collection using the key value "INV" followed by the invoice number.

257

258

Building Application Servers As can be seen from the example shown above, assembling complex business objects can be a difficult process. Some objects, like the Customer, must be aggregated into the high-level object but must also be tracked independently, since the customer can also be shared by other Invoice objects. Other objects such as the Orderltem objects do not need to be registered, since they are unique to each invoice. When the objects are registered and shared, they must be retrieved using the corresponding objectServer method. When they are independent, they can be retrieved directly from the database. This example was relatively simple, with only three different classes. As the number of classes and objects grow, the process quickly grows in complexity. Suppose the Orderltem object aggregated a product item. Products are shared across multiple invoices, so each would have to be retrieved from the objectServer and then inserted into the Orderltem objects. When the Customer object is retrieved, thefindCustomermethod requests the customer number from the InvoiceTable. This is an easy task for the InvoiceTable, since the invoice has just been retrieved and can be saved between method calls. When the order items are retrieved, multiple entries are returned from the OrderltemTable, so multiple product numbers must also be retrieved. Once the product numbers are retrieved, each product must be requested from the objectServer and then aggregated into each Orderltem using a setProduct method. The releaselnvoice method will be far less complex than the findlnvoice method. The process can work from the bottom up, first creating a vector of Orderltem objects and then using the OrderltemTable's save method to store the order items. Next, the customer can be released using the objectServer's releaseCustomer method, then the Invoice object itself is

saved and code can be added to release the Invoice object from the objectltems collection. The program listings for this chapter include the code for the releaselnvoice method.

Optimizing the Persistence Layer The examples shown in this chapter have been relatively simple, serving up only a few different classes with little concern for concurrent users, distributing objects across multiple servers, or optimizing system performance. Since the persistence layer acts as the object broker for the appli-

Persistent Objects: Communicating with Databases

cation server, this is where these performance issues must be addressed. The persistence layer must manage database connections, distribute objects across multiple servers, synchronize data access, ensure data integrity, and provide efficient throughput.

Capacity planning To optimize the persistent object layer and provide the best response time possible, it is first necessary to determine the size and scope of the task. How many object classes are there? How many instances of each object will be in memory and on disk? How many users will be accessing the application server at the same time, and how many transactions will be coming through the application server? These capacity numbers must be determined for both current needs and for the future, since most application volumes begin at much lower rates than they will eventually have to handle. Getting a handle on these numbers can be difficult, but usually current user count and transaction volume are numbers you can roughly estimate. Find out how many transactions are currently being processed (a few queries of the database can often give a good estimate), then use this as the baseline for a detailed transaction analysis. Once you've determined the transaction volume, you can break each transaction down into its components and obtain rough estimates for transaction, data and object volumes. Once you've determined these volumes, you can document them and use them as references while making design and programming decisions as well as determining hardware and network requirements.

Minimizing database connections One of the reasons stated at the beginning of the book for moving to an application server environment was to minimize database connections and decrease the load on the database server. In the traditional two-tiered environment, each user establishes at least one connection to each database, quickly raising the connection count and using up the database server's resources. Within an application server, the users do not directly connect to the database server; instead, the connections are maintained within the persistence layer. This eliminates the massive number of connections, but now forms a bottleneck between the users and the database server.

259

260

Building Application Servers The responsibility of managing database connections falls on the persistent object layer. In the examples above, a single connection was established and used for all database communications. This is fine for a single user, but as the workload grows, more connections must be established. You can choose any of several strategies, including: • one connection per object server • one connection per complex business object • one connection per table • one connection per object request • sequential pooled connections The goal of the connection strategy is to widen the communication path to the database server and to balance the access load across the connections. Estimate the volume of activity for each database operation, then balance the access load across a number of connections.

One connection per object server A simple connection strategy is to establish one connection for the entire persistent object server and then pass this connection to each table object. Unless the application server will have a limited number of users and few database requests, this is not a good idea. The single connection will quickly become a bottleneck that will degrade performance, since all object requests will have to wait to share the same connection. This strategy should only be considered for simple proof-ofconcept projects.

One connection per complex business object Since establishing a single database connection for the entire object server is probably not a good idea, the next alternative is to establish a database connection for each complex business object. A set of connections are established when the object server constructor runs; then, as each table object is created, the connection objects are passed to each constructor by logical category. The tables that create the invoice object

Persistent Objects: Communicating with Databases

receive invoice connections; the tables that create the billing objects receive billing connections. This continues for all table objects. Assignment of objects can also be grouped by other categories or in a way that balances the work across the connections. This is a better choice than sharing one connection for all the table objects, but is still limited by an arbitrary number of database connections. As the workload grows, it will be difficult to adjust and balance the connection load. One connection per table Another easy-to-implement connection strategy is to establish a connection for each table object. Since these objects are instantiated during construction of the object server, each connection can be established when the table mapping object is constructed. This may be a good strategy if accesses across the different tables are somewhat balanced and will not lose balance as the number of users and transactions increase. It is not a good strategy for applications that have a high potential for growth or will have to support high transaction volumes. One connection per object request Moving to the other extreme, a connection could be established each time an object request is initiated, then closed when the object request is completed. This is usually a better solution than those listed above, since it is sensitive to volume and will balance the load among a large number of connections. The problem is that it takes time to establish each connection, and the additional overhead will slow down response time when new objects are loaded. This is a good option if there are a limited number of objects and most of the objects are shared among a large number of users. It also is a good strategy for loading start-up information, such as lookup tables and pull-down lists. It is not a good strategy for applications that require high transaction volume. Sequential pooled connections A much better strategy for high-volume applications is to manage a pool of connections. At startup, a predetermined number of connections can be created and stored in a vector or array. Before a table object's method is

261

262

Building Application Servers called, a request is made to get the next connection object; then this connection is passed to the table object along with the data request. As each subsequent request is made, the connections are continuously cycled, automatically balancing the load across the connections. If at any time a connection object fails, it can be discarded, allowing a limited form of automated recovery. Also, the number of connections can be raised or lowered through service requests passed to the object server, allowing scalability over time. Of course, this process requires more programming, but it does provide a high degree of scalability and server management.

Handling multiple database servers When more than one database server is accessed, the connection strategy will have to take this into account, since the data accesses must have connection objects that point to the proper database. Also, depending on the programming language, different access protocols or different APIs may also be required. Usually these requirements can be isolated in the table objects and are not a concern other than in connection management. Finally, when determining the connection strategy, it is often necessary to mix and match strategies to fit the requirements. The processes that initialize lookup tables and pull-down boxes can often establish and close their own connections. Very high-volume table objects may want to establish their own connection pools and, as objects are distributed across multiple machines, the distribution will also affect the choice of connection strategies. Be creative and find a strategy that works for the particular application.

Distributing business objects Another reason for choosing the application server environment is that the application can be distributed across multiple servers. Instead of using a collection object located on a single server, the collection can be implemented using the middleware naming service. After the objects are loaded from the database, they are registered into the middleware's naming service and can then be distributed across any number of servers. Depending on the middleware, this can add some significant overhead into the application server, but it will allow scalability across multiple machines. Often an effective strategy is to distribute the high-level

Persistent Objects: Communicating with Databases

business objects together with their aggregated objects. The lower-level objects can no longer be shared, so exercise care in keeping the objects synchronized. When distributing objects, the key concern is to minimize network traffic between the distributed objects.

Concurrency and synchronization As the number of users grow and the volume of transactions increase, it is critical that the multitasking environment does not corrupt data. Since each object is registered into either a collection or middleware naming service and several processes reference the same objects, eventually two different processes will try to make changes to the same object at the same time. Unless mechanisms are in place to synchronize the processes, data corruption will occur. In addition to object access collisions, data can be corrupted in other ways. Changes can be made to the database outside of the application server, and this can cause data held in memory-resident objects to become obsolete. Later, as the data is stored back into the database, the first set of changes will be lost. Similarly, a process cannot be allowed to delete an object if it is in use by another process. To ensure that these problems do not occur, there are several approaches you can take within the persistent object layer. These include: • object synchronization • locking strategies • precautions when deleting data • change notification • multi-threading to keep objects consistent with the database

Object synchronization Object and method synchronization will be discussed in much more depth later in the book, so it will only be mentioned briefly here. Most programming languages have tools for synchronizing multiple access and ensuring that concurrent execution threads do not cause data collisions. Declaring a

263

264

Building Application Servers method synchronized adds gatekeeping code to hold up execution for subsequent processes until the current method execution is complete. Locking

Sometimes additional code may be needed to lock out access to other processes until critical updates are complete. These can be accomplished either through locking and unlocking methods within the persistent object server or within the object itself. Instead of the simple find and release methods that were implemented in the object servers illustrated earlier in the chapter, the methods can include find, lock, unlock and release. The find method acts the same as implemented above, locating the object either in the registry or loaded from the database. A new lock method is implemented that must be called prior to updating the object. This checks to ensure that no other locks are issued, then either passes back a status indicator or suspends execution until the prior lock has been freed up. The unlock method updates the data back into the database and frees up the lock, then the release method only handles releasing and removing the object from the registry. By using these methods, the processes accessing the objects can be sure that the data remains consistent and that no other process will make changes to the data while the object is locked. If necessary, each object can also be enhanced with its own lock flag and each set method can be enhanced so that it refuses changes unless a lock was initiated by the current process. The locking process can also interact with the database server to ensure that the object is consistent with the database when the lock goes into effect by refreshing the data from the database. The lock can also be extended to include row-level locking within the database to restrict updates by other applications. Deleting object from the database When an object and its database representation are deleted, a check must be made to first ensure that there are no other processes referencing the object. Usually, checking the reference count is adequate, making sure that the current reference count is set to 1. Once this is determined, the object can be deleted without having problems with other processes carrying orphaned references.

Persistent Objects: Communicating with Databases

Notification and multi-threading When the database itself has a high transaction volume or objects are held in memory for a long period of time, it is often a good idea to implement processes to periodically refresh the data. Changes made from other applications should be periodically loaded into existing objects, and changes made to the objects must be sent back to the database. The locking mechanism described above is often adequate for transaction-oriented objects, but sometimes more intelligence is needed. Most applications carry a set of tables to look up rates or populate pull-down boxes. These objects are loaded at the beginning of the application and stay in memory until the application server is shut down. The tables have limited maintenance, but when changes are made, they need to be reflected on the application server. Often, these tables can be refreshed by adding a notification process between the maintenance process and the application server. When the save button is pressed on the code maintenance program, a notification can be sent to the application server that changes have occurred, then the table can be refreshed. This notification will trigger a reload message on the persistent object server that will force the associated object to be refreshed. Another option for notification can often be implemented within the database server itself. A change in the table can cause a trigger procedure to be run that sends a notification message to the application server. This message can be generated either through a call to external code or through Java code embedded in the database server. Check the documentation supplied by the database server vendor to determine how to best implement these notification processes. When notification cannot be implemented, multi-threading can be added within the persistent object server to refresh the data periodically. Depending on the programming environment, a thread or timer process can be implemented that periodically refreshes all of these memory resident tables. The time period can range from once everyfiveminutes to once or twice a day, depending on the volatility of the data. Of course, a timer or thread will only update the data when thetimergoes off, not when the data changes; so there will always be some lag between the time the data is changed in the database and when the memory-resident changes occur. As stated above, concurrency and transactions will be covered later in the book. Chapter 13 will examine many of these techniques in much clos-

265

266

Building Application Servers er detail, providing code examples and programming tips on how to implement these techniques. They have been mentioned here because it is critical that the persistent object layer be built with concurrent access in mind.

Optimizing throughput The goal of the persistence layer should be to provide clean, safe, efficient access to the database. Sometimes, assembling complex business objects will require some nasty-looking code, using complex queries to build multiple business objects concurrently. In other cases, large volumes of data may require message streams to get partial query results back to the user interface quickly. Many of the techniques required to serve up the data will have to be custom-built to meet specific program needs. As with any programming effort, it is sometimes necessary to break the rules to make the program work efficiently. Throughout the illustrations, the primary goal has been maintainability and isolation between the objects and the database. Sometimes this is not the best option. In highvolume, transaction-oriented applications, it may make more sense to allow certain business objects to directly access the database. This should be avoided, but to optimize response time, it may be the only alternative. Use whatever it takes to get the data to the user interface, but try to keep the processes logical and isolated. Otherwise, the application server built today will become the legacy problem of the future.

Summary The persistence layer provides the foundation of the application server, acting as the object broker for the business object layer as well as interfacing with the database. The following issues should be considered when implementing the persistent object server: • A persistent server creates and stores business objects from relational databases and other external applications. • The persistent server must be able to locate the business objects already in memory to prevent duplicate objects from corrupting persistent data.

Persistent Objects: Communicating with Databases

• The persistent server is also responsible for business object life cycles, releasing and deleting objects when they are no longer needed. • Object relations must be maintained when complex objects are loaded or stored. • Objects that have associative relationships must be created and tracked independently, but the relations must also be preserved when the objects are loaded from persistent storage. • Database connections can be minimized by creating a connection pool, cycling connections each time data is accessed. • Synchronization and locking are important considerations when updating and deleting business objects. • Multi-threading is also an effective approach for speeding up concurrent accesses.

References Ambler, Scott W. "Designing a Robust Persistence Layer." Software Development, January-April 1998. Kara, Dan. "The Four Faces of JDBC." Component Strategies, February 1999: 72. Whiting, Bill, Bryan Morgan, and Jeff Perkins. Teach Yourself ODBC Programming in 21 Days. Indianapolis, Indiana: Sams.net Publishing, 1996.

Further Reading SQL Rozenshtein, David, and Tom Bondur. The Essence of SQL: A Guide to Learning Most of SQL in the Least Amount of Time. Menlo Park,

267

268

Building Application Servers California: Peer to Peer Communications, 1998. Taylor, Allan. SQL for Dummies. Indianapolis, Indiana: IDG Books, 1997.

JDBC Horstmann, Cay S., and Gary Cornell. Advanced Features. Vol. II, Core Java. Upper Saddle River, New Jersey: Prentice Hall, 1998. Patel, Pratic, and Karl Moss. Java Database Programming with JDBC. Scottsdale, Arizona: Coriolis Group Books, 1997. Schneider, Jeff, and Rajeev Arora. Using Enterprise Java. Indianapolis, Indiana: Que Corporation, 1997.

Chapter 11

Interfaces and Client-Side Communication A service interface is a set of consistent, easy-to-use application services that can be called by user interface programmers to perform the tasks requested by the user. When the post transaction button is clicked, the user interface calls the post transaction service, supplying the relevant data items. The user interface programmers have no need to know how the transaction is posted; they simply need to know how to request the appropriate post transaction service. Once the data is supplied to the service interface, it is up to the application server programmer to ensure that the necessary business objects are retrieved by the persistent object layer and that methods are called to perform all of the tasks requested by the service interface specification. If the business objects are designed correctly and the persistence layer can correctly retrieve the business objects, programming the service interface should not be a difficult task. What complicates service interface programming is the additional layers of middleware managing objects distributed over a number of different computers. This restricts the amount of data that can be passed between the client and the service interface, since much of the data must be passed through network connections and be marshaled to meet the requirements of the remote machine's data format. The network also 269

270

Building Application Servers adds a multitude of new exception and error conditions that must be anticipated. As an added restriction, the same service may be executing simultaneously for a large number of different clients, each requesting services for any number of different sets of data. This chapter will examine these technical requirements and explore some of the programming techniques available to address these challenges. These will include: • client/server communication • creating a service interface • using the service interface • passing data, objects and properties

Client/Server Communication Not too many years ago, client/server communication entailed setting up pipes, sockets, or even lower-level system or hardware-level network communication processes (Nance 1990). Once the network connection was established, the programmer then had to issue NetWare or LAN Manager API calls to send data in a manner that conformed to the correct protocol. Today, most communication is handled at a higher level using either database or other middleware products, providing transparent access between the client computer and the server. Instead of thinking about each computer as a separate entity, the network can be seen as one large computer. In spite of this transparency, you must take some additional factors into consideration when using middleware tools. The calls are passed over the network and take far longer to complete than calls made on a single machine. Network interruptions, transmission errors, and loss of connections can happen, especially across wide-area and dial-up networks. When these errors occur, the programmer must handle them in an appropriate manner, first trying to recover automatically, or when recovery is not possible, reporting the error in a manner that is understandable to the end user.

Interfaces and Client-Side Communication

Establishing remote communication Each application program, or set of related programs, relies on services packaged together into a service interface. When the application is initialized, a naming or directory service is called to obtain a reference to the remote object that implements the service interface. Once this reference is obtained, all communication requests are routed through this service interface, and the programmer can treat the requests just as if they were methods of any other local object. Even though the service interface calls are transparent to the programmer, there is quite a bit more going on, and unless the programmer is aware of the process, the application's performance will suffer. Before the remote application can obtain this reference, a remote object server must create an instance of the object that implements the services, then register it with the naming service. This naming service registry, running on a separate server, tracks all remote objects currently residing in memory or, when resources are overloaded, provides persistence services so that remote objects not currently in use can be swapped to persistent storage. Once a reference to the remote object is obtained from the naming service, the program uses this object to invoke the service requests as if they were local object methods. Before calling these methods, the application program must know the names of the methods, the number of parameters, and their types; otherwise, calling the methods will result in program syntax errors. Two approaches are available to solve this problem. The first is to create stub programs that act as proxies to the remote objects, (note: stubs and skeletons were discussed in chapter 9.) These stubs are generated either from an interface definition language or by using utilities such as rmic that create the stubs using the information obtained from the object implementation. This method is known as static invocation and is the method discussed below. Alternately, dynamic invocation allows the programmer to locate remote objects and methods at run time using a separate API. By querying the registry, this API can locate the remote objects currently available and return information describing each method along with its parameter requirements. This information can then be used to create and send service requests without having to know the specific requirements at run time. Since all method calls are sent through standard API calls, there is no need to set up proxy objects, stubs, or interfaces to satisfy compiler requirements.

271

272

Building Application Servers Although dynamic invocation is far more flexible, the overhead required is higher and programming can be more error-prone, since method and parameter names are not checked until run time. Dynamic invocation has uses in telecommunication applications and for implementing intelligent agent technology, but in business applications, static invocation is often preferred. The overhead is lower and error checking can be done at compile time instead of run time.

Processing remote communication When a service interface method is called using static invocation, the application calls a stub program that acts as a proxy to the remote method (see Figure 11-1). This stub program must first serialize any objects called as parameters, flattening out the object's attributes into a long string of bits that can be sent over the network. If any of the attributes are objects, they must also be serialized recursively until all objects and attributes are flattened into a single string of bits. As can be imagined, a single object parameter can quickly turn into a large amount of data, resulting in quite a bit of network traffic. As these attributes are serialized, they must also be marshaled into a common platform-independent format specified by the middleware architecture. What began as a single reference to an object in a service interface call quickly grows in size and complexity. The same process is repeated for each parameter passed to the service interface. Once the parameters are serialized, the stub creates a network message that includes routing information such as the source and destination, the object that implements the service, the name of the method and the serialized parameter list. This message is passed on to the network services where it is broken into packets, then sent out onto the network. Once on the network, the packets go through hubs and routers until they reach their destination.

Server-side communication When the message is sent, it is routed to the object on the remote computer. This object is fronted by a skeleton that interfaces with the network software to receive the message and call the remote object's

Interfaces and Client-Side Communication

Application

273

Stub

A

ObjA..attrib1..attrib2..attrib3.. ObjA..attrib1 ..attrib2..attrib3..

>

B

Ob)B..altrib1..attrib2..attrib3..

j ObjB..attrib1 ..attrtb2..attrib3..

x = obj.method(A) C

ObjC..attrib1..attrib2.. ObjC..attrib1..attrlb2..

Serialize

Marshal

Network Services

Figure 11-1. Stub communication

method (see Figure 11-2). The skeleton receives the message and begins by marshaling the data into the format required by the remote object's computer. Once the data is marshaled, each object parameter is assembled back into its class hierarchy, reversing the object serialization process used by the stub. Once the parameters are assembled, the skeleton determines which method was requested and then calls the method using the parameters that have been reassembled. The results of the method call, along with any exceptions, are then serialized and marshaled, then formatted into a message that can be sent through the network back to the stub. The stub then interprets the message by marshaling and reassembling the serialized objects and returns them to the application.

Q

274

Building Application Servers _. , ,

Remore Object Server

Skeleton

ObjA..attrib1..attrib2..attrib3..

ClaSS O b j e c t

A

(

ObjA..attrib1..attrib2..attrib3..

<•

public int method(A) y

y

ObjB..attrib1..attrib2..attrib3..

From Network

0bjB..at.ribi..attrit>2..attrib3..

B

ObiC..attrib1..attrib2.. ObjC..atlrib1..attrib2..

Network Services

Marshal

C

Serialize

Figure 11-2: Skeleton communication

Requesting services After examining the process described above, it is easy to see that the number and type of objects passed and returned through the service interface should be kept as simple as possible. The distributed object architectures allow almost any type of object to be sent, but complex objects will quickly impact the application's performance. When possible, pass primitives and simple objects.

Creating a Service Interface Chapter 9 used a simple loan payment calculator to illustrate the basic techniques needed to establish a connection between a client applet and a Java RMI server. This example was relatively simple, sending three

Interfaces and Client-Side Communication

parameters to the service interface and then returning a single result. Most business applications are far more data intensive, requiring a much higher degree of interaction between the application and the server. Business applications also must load and store data from some form of persistent storage, usually a relational database. To illustrate some of the techniques needed to implement an application server interface, we will begin with a simple applet that maintains the customer information from the invoice example described in the last chapter. This applet will request a customer number, then either inform the user that this is a new customer number and request the information or display the information on file and allow the user to make any changes needed.

Defining the service interface Listing 11-1 is the interface description for the services needed by the applet. These services include findCustomer, addCustomer and saveCustomer. Each service uses an object called CustomerData to pass the information between the customer applet and the service interface. The findCustomer service receives a customer number stored in a string object, then locates the customer and returns a customer data object that contains the data needed to fill the screen. If no data is found, a null reference is returned instead. The addCustomer service takes the data stored in a customer data object and adds it into the database. The saveCustomer service does the same for a customer that is already on file. Listing 11-1: Customer service interface import java.rmi.*; public interface Customerlnterface extends Remote { public CustomerData findCustomer (String cust) throws RemoteException; public void addCustomer (CustomerData custData) throws RemoteException;

275

276

Building Application Servers public void saveCustomer (CustomerData custData) throws RemoteException;

The interface class Customerlnterface extends java.rmi.Remote, which

includes additional services that are called by the implementation to perform the remote method processes. These include marshaling, serialization and remote exceptions. Within the class, each service is listed with its type, parameters, and any exceptions that it can catch or throw.

Implementing the interface The interface definition defines the services, listing the names of the services, the parameters required, their return values and any exceptions that may be thrown. This interface can be used to define the services to the compiler when building the client program or applet. The interface does not include any procedural code, only the declarations so another class must be created that implements the methods. The CustomerServices class shown in listing 11-2 provides this implementation. Listing 11-2: CustomerServices implementation import java.rmi.*; import java.rmi.server.UnicastRemoteObject; public class CustomerServices extends UnicastRemoteObject implements Customerlnterface { private ObjectServer objsrv; public CustomerServices(ObjectServer os) throws RemoteException { super(); objsrv = os;

Interfaces and Client-Side Communication / / ... service methods listed below ....

This class uses many of the same features as the implementation of the loan calculator class shown in Chapter 9. The class extends java.rmi.remote.UnicastRemote, allowing it to inherit the functionality needed to act as a remote object. It implements the Customerlnterface listed above, implementing each of these services. It also has a single class attribute that holds a reference to the persistent object server, which is needed to obtain business object references stored in the relational database. The constructor begins by calling super (the constructor method for the UnicastRemote object), initializing the RMI superclass. Once this is done, it stores the reference to the object server passed to the constructor. To make the class definition readable, the service methods were removed and will be listed individually below. The first service listed in the interface definition was the findCustomer service. This service is implemented in Listing 11-3. It begins by retrieving a Customer object from the object server described in the last chapter. If a null reference is returned by the object server, the customer is not on file, so a null reference is returned to the calling program. If the customer is found, a new CustomerData object is created; then all attributes are transferred from the Customer object to the CustomerData object. The Customer object is then released from memory using the object server's releaseCustomer method, and the reference to the CustomerData object is returned to the calling program. Listing 11-3: findCustomer service implementation public CustomerData findCustomer (String cust) throws RemoteException { Customer custObj = objsrv.getCustomer(cust); if (custObj == null) return null; else { CustomerData custData = new CustomerData(); custData.customer = custObj.getCustomer();

277

278

Building Application Servers custData.name = custData.address = custData.city = custData.state = cnstData.zip = custData.phone =

custObj.getName(); cnstObj.getAddress(); custObj.getCity(); custObj.getState(); custObj.getZip(); custObj.getPhone();

objsrv.releaseCustomer (custObj); return custData;

It would be possible to pass the Customer object itself back to the applet, but this could cause several problems. First, it would create a higher amount of network traffic, sending data that may not be needed by the applet. Since the Customer object is not set up as a remote object, returning it to the applet would result in a copy being sent over the network, not the actual object. Changes made to this Customer object would not be reflected on the server until the object was returned, resulting in possible data losses. Also, sending the Customer object could possibly result in security breaches, such as releasing proprietary code or sensitive data over the network. Instead, a separate data structure is created that encapsulates only the data necessary to service the client program. When the data is sent back to the server, the changes can be merged with other changes that may have occurred. Listing 11-4 shows the implementation of the saveCustomer method. This service begins by locating the customer from the object server. If the Customer object is found, each attribute is copied from the CustomerData structure to the Customer object; then the customer is released, posting the data to the database. Note that in the findCustomer method, the release method was also used. This method is responsible for both saving the data and managing the object's life cycle. Listing 11-4: saveCustomer service implementation public void saveCustomer (CustomerData custData) throws RemoteException

Interfaces and Client-Side Communication

Customer custObj = objsrv.getCustomer(custData.customer); if (custObj == null) addCustomer (custData); else { custObj.setName (custData.name); custObj.setAddress (custData. address); custObj.setCity (custData.city) ; custObj.setState (custData.state); custObj.setZip (custData.zip); custObj.setPhone (custData.phone); objsrv.releaseCustomer (custObj);

If the customer is not found, saveCustomer calls the addCustomer service. This implementation is similar to the saveCustomer code listed above, but first creates a new, empty Customer object. Then, like the saveCustomer service, it updates the Customer object with the new information before releasing it back to the object server. The source files for the customer services implementation as well as the rest of the application server implementation are included with the program files for this chapter.

Registering the service interface Before the client applications or applets can begin to use the new service interface, the interface must be loaded into memory and registered with the middleware naming service. This process is done by the application server program, which first instantiates the persistent object server and then creates an instance of the service interface implementation object before registering it with the naming service. Listing 11-5 shows the implementation of this simple application server. Listing 11-5: Simple application server implementation import java.rmi.*;

279

280

Building Application Servers import java.rmi.server.*; public class AppServer { public static void main(String[] args) { ObjectServer objsrv = new ObjectServer(); try { CustomerServices custsvc = new CustomerServices (objsrv); Naming.rebind ("CustomerServices", custsvc); } catch (Exception e) { System.err.println ("Customer Services not initialized"); e.printStackTrace();

The server is structured as a Java console application with a main method that is run by the JVM when the program is invoked using the command: Java AppServer Once the server has imported the RMI packages, it begins by creating an instance of the object server, which will be used within the service interface to obtain references to business objects. These business objects can either be found in memory or retrieved from the relational database. Next, an instance of the CustomerServices object is created, passing the reference of the persistent object server (objsrv) through the CustomerServices constructor. Once the CustomerServices object is loaded into memory, it is registered using the rebind method of the RMI naming service API to register and bind the name "CustomerServices" with the instance of the object.

Using the Service Interface After the services are registered with the middleware naming service, they are available to any machine on the network. The client program simply obtains a reference from the naming service, casts it to a local object using the interface definition, then begins calling services using

Interfaces and Client-Side Communication

this reference. Once the client program is finished using the reference, it must inform the naming service that it no longer needs these services. This section will examine an applet that uses the customer services to add and modify customer information. The applet will first obtain a reference to the remote service interface, then use these services to load and store data. After the user enters a customer number, the applet will call thefindCustomerservice to locate and retrieve the customer data and then display this data within the applet. The user can then examine or change any of the fields on the screen (other than the customer number), then click the save button to update the data on the server. When the save button is clicked, the saveCustomer service is called to send the data back to the server, then the fields are cleared, awaiting the next customer number. A cancel button is also provided to release the data without making any changes.

Accessing the services The applet first locates a reference to the CustomerServkes object instance using the lookup method of the RMI naming service API. Once this reference is obtained, the applet can use it to request services from the CustomerServices object. Listing 11-6 shows how the applet obtains this reference. Listing 11-6: Obtaining the service interface reference private Customerlnterface custSvc; private String url; public void init() { if (System.getSecurityManager() = null) System.setSecurityManager (new RMISecurityManager()); url = " / / " + getCodeBase().getHost() + "/CustomerServices"; try { custSvc = (Customerlnterface) Naming.lookup (url);

281

282

Building Application Servers

catch (Exception e) { System.err.println ("Cannot open remote Customer Services"); e.printStackTrace();

/ / ... remainder of initialization logic ...

The init method of the applet includes any logic necessary to initialize the applet once it has been loaded into the browser or applet viewer. After setting up a security manager, the applet creates a URL containing the location of the remote service interface. The getCodeBaseO-getHostO method call retrieves a string containing the URL of the applet's host machine. This enables the applet to interrogate its own host instead of hardcoding a URL, allowing more flexibility when distributing the applet. Once the URL is created, it is passed to the naming service to obtain the remote object reference. This reference is then cast into a Customerlnterface object, which is stored into custSvc, a private attribute of the applet class. If a network or remote error occurs, the catch block retrieves the exception and prints it to the standard error device, then calls the printStackTrace method to list the call stack to allow easier tracing of the error.

Locating the data Once the applet is initialized, all text fields and controls are disabled except for the customer number and the cancel button. This keeps the user from accidentally typing data where it will be lost or cause program errors. When the user types in a customer number then hits the Tab key, the event handler senses a customer lost-focus event and calls the focusLost event handler shown in listing 11-7. Listing 11-7: Customer lost-focus event handler void customerText_focusLost(FocusEvent e)

Interfaces and Client-Side Communication

{ CustomerData cust; String custnumber = customerText.getText(); if (custnumber = null) return; try { cust = custSvc.findCustomer (custnumber); } catch (Exception er) { System.err.println (er.toString()); return;

nameText.enable(); addressText.enable(); cityText.enable(); stateText.enable(); zipText.enable(); phoneText.enable(); saveButton.enable(); if (cust != null) { customerText.setText(cust.customer); nameText.setText(cust.name); addressText.setText(cust.address); cityText.setText(cust.city); stateText.setText(cust.state); zipText.setlext(cust.zip); phoneText.setText(cust.phone);

repaint();

The event handler begins by retrieving the customer number entered in the customer text box. If there was no data found (null), the handler immediately exits. If a customer number is found, it is passed to the findCustomer service, which returns either a customer data structure filled with the data needed to load the screen, or a null reference if the cus-

283

284

Building Application Servers tomer is not found on the server. Either way, the handler next enables the text fields and the save button. If the findCustomer service returned data, this data is copied to the text fields. Finally the applet's repaint method is called to update the user interface screen. A status bar or pop-up window should be added to let the user know whether data is to be added or modified, but this was left out to simplify the program code.

Storing the data Once the user fills in the data and clicks the save button, the event handler sends the data back to the server using the saveCustomer service. Listing 11-8 shows the event handler for the save button-clicked event. A new CustomerData object is created and then filled with the data from the user interface screen. This data structure is then passed back to the server by calling the saveCustomer service. If a remote error occurs, it is handled by the catch block; otherwise, the newCustomer method is called (see the program listings for this method's implementation) which clears all of the text fields and disables all but the customer text field and the cancel button. Listing 11-8: Save button event handler void saveButton_actionPerformed(ActionEvent e) { CustomerData cust = new CustomerData(); cust.customer = customerText.getText(); cust.name = nameText.getText(); cust.address = addressText.getText(); cust.city = cityText.getText(); cust.state = stateText.getText(); cust.zip = zipText.getText(); cust.phone = phoneText.getText(); try { custSvc.saveCustomer (cust); } catch (Exception ex)

Interfaces and Client-Side Communication { System.err.println ("Error saving customer data"); ex.printStackTrace(); return; } newCustomer(); repaint();

The cancel button handler simply calls the newCustomer and repaint methods, clearing the screen without saving the data. See the source code listings for the implementation of both the cancel and newCustomer methods. All of the source files for the customer applet example are included with the source code for this chapter.

Releasing the remote object When the customer applet is closed, the last method called is the destroy method. Listing 11-9 shows the implementation of the destroy method, which calls naming.unbind to release the remote object. The remainder of the implementation provides routine error handling for possible remote errors. Listing 11-9: Releasing the remote object public void destroy() { try { Naming.unbind (url); } catch (Exception e) { System.err.println ("Error releasing remote object"); e.printStackTrace();

285

286

Building Application Servers

Passing Data, Objects and Properties Most object-based middleware architectures allow a variety of different methods for passing information between distributed objects. Parameters passed over the network can range from primitives, such as integers or floating point numbers, to the most complex object hierarchies. Many also provide predefined data structures, such as property sheets, and some architectures even allow message passing and event notification. Just remember that whatever gets passed must go through both network and marshaling processes, so the larger the data structure, the slower the interface call.

Primitives The loan calculator example in Chapter 9 illustrated how to pass primitive data items through the service interface. Primitives are passed by value, so there is little performance impact when the service is called. Each data item is marshaled into a machine-neutral format, then sent over the network as part of the service request. Once received by the remote object server, it is marshaled into the remote machine format, and the parameters are prepared according to the calling conventions required by the machine architecture and the program language.

Objects Passing objects is quite a bit more complex than passing primitive data types. The objects must be serialized, sent over the network, then reassembled back into objects on the remote machine. Both the local and remote machine must have knowledge of the object structures either through language headers, class definitions or interface definitions (IDL) to recreate the objects consistently. Objects can be passed both as parameters and as return values. In CORBA and DCOM, objects passed as parameters can also be modified as long as they are declared as both input and output within the IDL definitions. This provides the ability to modify parameters inside the service then send back the changes to the calling program. Parameters can also be declared as output only, allowing the service to send back multiple return values. When considering how to return results from the service interface, it is usually not a good idea to pass business objects back to the client

Interfaces and Client-Side Communication

machine. Languages such as Java can be decompiled to reveal proprietary business logic, and it would be relatively easy to invoke methods that could perform unauthorized operations before sending the object back to the calling program. If a client program receives a customer object, a creative programmer could modify the program to call the "increase credit limit" method or even the "post payment" method, even though the program only provides customer inquiry functions. A better choice is to create a separate data structure that contains the information needed specifically for the client program, then pass this structure back instead of the business object. This will ensure that critical business logic and methods are isolated inside the application server, and limit changes to those fields referenced on the user interface screen. You can use several approaches to create parameter objects or structures that isolate the client program from the application server. The easiest approach is to simply strip the methods from the business object. This is the approach used in the customer example shown above. The Customer object is copied, then all methods are removed, producing a new simple data structure called CustomerData. The resulting structure is shown in Listing 11-10. Listing 11-10: CustomerData structure

import java.io.*; public class CustomerData implements Serializable { public String customer; / / customer number public String name; / / customer name public String address; / / address public String city; / / city public String state; / / state public String zip; / / zip code public String phone; / / phone number

Note that the class implements the Serializable interface. When RMI passes the object across the network, the object must first be serialized into a bit stream. RMI uses the methods specified by the Serializable interface to accomplish this process.

287

288

Building Application Servers A second approach to creating interface objects is to again copy the object, but remove only those methods that could compromise security. This approach, illustrated in Chapter 12, moves some of the business logic, such as data validations, back to the client machine. The download time for the applet may increase, but some of the network traffic is eliminated, since more of the business logic resides on the client machine. Just make sure that the validation logic and business processes passed through the parameter objects do not expose sensitive business logic outside the application server. Passing complex objects through the service interface also raises a number of issues. Complex objects are far more difficult to serialize, requiring additional code to ensure that they are reassembled properly at their destination. Also, network traffic can easily be wasted when only part of the hierarchy is used. Often it makes more sense to provide services to retrieve only the portions of the hierarchy needed, breaking the objects down and accessing the lower-level objects one at a time as needed. When an entire object structure is needed, the parameter objects should be built with care, removing the methods that encapsulate business logic while leaving the methods that manage the hierarchy. Examine methods to manage the data structures carefully to ensure that the business logic is removed, while keeping the data management logic intact. Once this is done, you must add serialization code to ensure that the structures are torn down and reassembled correctly. Fortunately, the Java language can serialize most object hierarchies without additional code, but other platforms, such as Microsoft's MFC, require custom Serialize methods to reassemble complex object hierarchies. See Further Reading at the end of the chapter for more information on Java serialization and MFC serialization techniques.

Properties In most application server environments, the high level of concurrent access does not lend itself towards using local attributes to store staterelated information. Subsequently, properties and attributes are not often used in application server processing. When they are used, they are more likely to provide administrative services, changing processing variables such as load balancing or to retrieve and reset metrics.

Interfaces and Client-Side Communication

Even when the middleware allows direct access of properties or attributes, good programming practices dictate that attributes be accessed through method calls. Getter and setter methods can ensure that the data stored in the attributes are within valid ranges and match the correct data type, protecting the program from adverse results. Once these methods are defined, they can be exposed to the service interfaces that need this functionality. When it is necessary to track state information between service calls, there are a couple of approaches that can be used. The first is to implement a class factory, spawning new service objects for each client (Sun Microsystems n.d.). After the client program retrieves a reference to the service interface, it then calls a class factory method that creates a new instance of the desired service interface, registers it with the naming service, and then passes the name of the new service interface object back to the client program. The client program then makes a second call to the naming service, requesting the new remote object. This new service interface object is then held exclusively by this client program, so state attributes can be relied upon to stay constant between service calls. This approach should be restricted to those services that are extremely statedependent, since server overhead grows quickly as the number of clients and service objects grow. Class factories will be examined in more detail in Chapter 13, which covers concurrency and synchronization. A simpler approach than the class factory model is to create a data structure that holds the client's state attributes. This structure is passed between the client program and the service interface each time a service is requested, and the service uses this information instead of local attributes when state information is required. Using this information, subsequent service requests can respond according to the needs of the client program, acting as if the client had exclusive use of the service. This approach does pose some security risks, exposing attributes to the client program, but the types of information stored in these structures are usually limited to indexes, Boolean values and other control values which have little meaning outside the service interface. A final method for passing properties and attributes is through property pages. These are structures, provided by component architectures, that map names to object types that control the behavior of the component or service. Anyone familiar with Visual Basic or the Java RAD tools will recognize

289

290

Building Application Servers property pages. These list the properties for each screen object, controlling background color, text width, and other component attributes. When attributes must be exposed to the client program, the property object is an excellent tool, since each property can be set any time during program execution, then passed back and forth between the client and the service interface.

Returning errors Anyone who has spent any time writing business applications realizes that error checking and handling takes up a majority of the programming effort. Although the next chapter will be devoted to checking business rules and reporting error conditions, it is the responsibility of the service interface to report these errors and exceptions back to the client computer. This section will examine the mechanics of handling errors and exceptions in the Java RMI environment. Most object-oriented programming languages provide some form of exception handling, passing control to error handlers when exceptions occur. Java and C++ both provide the throw command, which, when an error occurs, throws an exception back to the calling program. The calling program wraps sections of code between try/catch blocks. Code within the try block executes sequentially until an exception occurs. At this point, execution is diverted to a catch block, which is responsible for handling or reporting the error. Many of the program listings included in this chapter implement exception handling using the try/catch blocks to intercept Remote exceptions. This same technique can be used to catch and handle application errors. A user-defined exception is created that extends the standard Exception class; then, this new exception is thrown by the service interface method to inform the client program that an application error occurred. By using this method of exception handling, the program does not have to interrogate the results of each return value. Instead, it can be coded as if every line of code will perform correctly; then when an error occurs, program execution will divert down to the catch block. A user-defined exception is created by subclassing the Java Exception class. You can create a number of exceptions to define a variety of different error conditions. Listing 11-11 shows the implementation of a DataException object. Each exception object must supply two construe-

Interfaces and Client-Side Communication

tors, one with an empty parameter list and one with a string parameter. Each constructor calls the method super to call the constructor for the Exception object. Additional attributes can also be added to report more detail back to the calling program, and these attributes could also be added to the constructor methods. Listing 11-11: DataException object class DataException extends Exception { DataException () { super();

DataException (String s) { super (s);

Once the exception is defined, it must be declared in each service interface method that throws the exception. Listing 11-1 showed the original service interface definition for the Customerlnterface. Each method declaration stated that it could throw a RemoteException. These declarations can be modified to include additional exceptions, including the new DataException. After modifying the saveData method declaration to handle the DataException, the declaration would appear as: public void saveCustomer (CustomerData custData) throws RemoteException, DataException; In addition to changing the interface definitions, the implementation must also be modified to generate the new exceptions when appropriate. Listing 11-12 shows the implementation of saveCustomer after it is modified to verify that both the customer number and the name are nonblank. The method declaration is modified to indicate that it can throw DataException^; then, within the code, the customer number and name passed through the CustomerData structure are checked for either null values or for string lengths of zero. If either occurs, a new DataException

291

292

Building Application Servers is created containing the text of the error message; then the exception is thrown. Since the throw command terminates execution of the method, there is no need to add a return command to stop the method execution. Listing 11-12: New saveCustomer implementation public void saveCustomer (CustomerData custData) throws RemoteException, DataException { if ((custData.customer == null) || (custData.customer.length() == 0)) throw new DataException ("Customer number is required"); if ((custData.name == null) || (custData.name.length() == 0)) throw new DataException ("Customer name is required"); Customer custObj = objsrv.getCustomer(custData.customer); if (custObj = null) addCustomer (custData); else { custObj.setName (custData.name); custObj.setAddress (custData.address); custObj.setCity (custData.city); custObj.setState (custData.state); custObj.setZip (custData.zip); custObj.setPhone (custData.phone); objsrv.releaseCustomer (custObj);

Finally, the applet must also be modified to catch this new data exception. The remote method call to saveCustomer already is wrapped in a try/catch block to catch any remote exceptions, so all that is needed is an additional catch block to catch data exceptions. This is illustrated in Listing 11-13.

Interfaces and Client-Side Communication Listing 11-13: Catching the DataException void saveButton_actionPerformed(ActionEvent e) { CustomerData cust = new CustomerData(); cust.customer = customerText.getText(); cust.name = nameText.getlext(); cust.address = addressText.getText(); cust.city = cityText.getText(); cust.state = stateText.getText(); cust.zip = zipText.getText(); cust.phone = phoneText.getText();

try { custSvc.saveCustomer (cust); } catch (RemoteException ex) { System.err.println ("Error saving customer data"); ex.printStackTrace(); return; } catch (DataException dx) { msgBox (dx.toString()); return; } newCustomer();

Note that the first catch block has been changed to only catch RemoteExceptions. This allows other exceptions, including the DataExceptions, to be ignored by this catch block. The next catch block catches the DataExceptions, extracting the error message from the exception. Once the error is extracted from the exception, it is passed to a messageBox method that creates a pop-up dialog box informing the user of the error condition (the messageBox method will be described in the next chapter). The Java exception model provides a powerful method for categorizing and communicating a variety of different error conditions back to

293

294

Building Application Servers the client computer. Return values can be reserved for passing results, not error conditions, and the programmer does not have to interrogate the return value to determine what type of error has occurred. Error handling code can also be kept at the bottom of the try/catch blocks instead of having it interspersed throughout the application code, making it difficult to read.

Messages, events, and asynchronous communication Communication between the client and the service interface is usually a two-way conversation. The client requests a service, then the service interface performs the service and returns the results. Since the service interface is optimized for fast performance, the wait time between the request and response is brief, within a second or two. There are times, however, when this processing model does not work. For services that require more time to process, some form of asynchronous message may work better, allowing the client to request the service, then move on to another task. In other cases, notifications may be needed, either to inform another process of an event that has occurred or to let a user know that a longer process has completed. Although this chapter has examined service interfaces implemented using distributed objects, a portion of the service interface could be based on a message broker architecture. Messages could be sent to request services, then an event listener would be implemented to receive messages when processes or events occur. Many CORBA implementations also now offer asynchronous services that allow one-way communication to a client or server machine (Visigenics 1998). Still, most service interfaces work better when the communication is two-way, allowing confirmation of each request, either by providing immediate results or by informing the user that the transaction has taken place. It is rather disconcerting to press the Enter key and not get any feedback. The message broker interface usually fits better into the persistence layer of the application server, where it can receive the request, invoke the message, and then send back a response informing the client that the message has been sent.

Interfaces and Client-Side Communication

Summary This chapter examined the techniques necessary to communicate data and exceptions between the client program and the application server. The following guidelines should be considered when implementing service interfaces: • The key to service interface performance is to minimize the network traffic. • Only send the data that is relevant to the service, and keep object structures as small as possible. • Do not pass business objects to the user interface; instead, create data containers that pass only the data necessary for the service request. • Use exception objects to communicate errors to the user interface. Try/catch blocks simplify programming, and the exception objects can be customized to classify error conditions and return additional information. • Asynchronous message passing and notification can be used to communicate requests when the application server will take a longer amount of time to process.

References Nance, Barry. Network Programming in C. Indianapolis, Indiana: Que, 1990. Sun Microsystems. "Applying the Factory Pattern to RMI." n.d. Available from http://java.sun.eom/products/jdk/l.2/docs/guide/rmi/Factory. html Visigenics. VisiBroker Programmer's Reference for C++. 1998.

295

296

Building Application Servers

Further Reading Morrison, Michael, and Jerry Ablan.Teach Yourself More Java in 21 Days. Indianapolis, Indiana: Sams.net Publishing, 1997. Liberty, Jesse. Beginning Object Oriented Analysis and Design with C++. Chicago, Illinois: Wrox Press, 1997.

Chapter 12

Enforcing Business Rules What initially drew me to application server technology was the need to support constantly changing, complex business rules. Traditional twotiered client/server worked well for data intensive applications, but as the processing requirements grew, it became difficult to create and manage large client-based programs that supported these complex requirements. Moving the business logic to centralized application servers simplified both software development and code distribution. Today's business applications are expected to move far beyond simple data management chores, performing business intelligence and decision support tasks for all levels of the company. Business requirements are also constantly changing, with new products and processes introduced in ever-shorter business cycles. Applications must not only encapsulate existing business logic, but be structured openly to allow quick response when rules change. Business rule processing takes on a variety of forms, from simple data validation to complex data classifications and business processing logic. Encapsulating these processes in program code that can respond to changing requirements is a challenging task. Often, implementing rule processing around data structures instead of program code enables more flexibility and ease of maintenance. Commercial business rule processors and languages can also make the task easier to manage. This chapter will examine how to incorporate complex business rules and processing into the application server environment. It will examine 297

298

Building Application Servers what a business rule is, how to implement the rules in program code, where to place the logic within the application architecture, and how to standardize error handling and reporting. Application security will also be examined, both as an application server issue and as a way of illustrating how to implement complex business rules. • What is a business rule? • Turning business rules into code • Where to put the code • Standardized error handling • Security and authorization strategies

What is a Business Rule? Business rules encompass every aspect of the organization, codifying the procedures and policies that keep the company running. Margaret Thorpe provides the following definition of a business rule: "A business rule is an atomic, explicit and well-formed expression that describes or constrains the business principles, guidelines and operations of a company using vocabulary and syntax that can be easily used and understood by the persons within the company who are responsible for defining and carrying out the business" (McClintock

1997). This definition emphasizes the need for rules to be defined in the language of the people who perform the job. This ensures that the rules can be verified to reflect the practices in use, not just abstract ideals. Rules are also atomic or fine-grained, defined at a deep level of detail to make sure that all aspects of the job are included. The definition also implies that the rules are explicit; the rules are documented and organized in a way that makes them accessible to those who need them. Some examples of business rules include: • No customer will be allowed a credit limit in excess of $1,000,000. • All employees are given 10 days of vacation each year.

Enforcing Business Rules

• We will not accept orders from customers with accounts more than 45 days past due. In many organizations, rules are not always formally documented. Critical rules may be found in policy statements or procedure manuals, but most evolve over time as workers perform their tasks, adapt to new situations or solve problems. These rules are often found in the heads of the people who perform the tasks, so much of the analysis process will revolve around finding the right people and then getting them to describe the rules. Interviews and walk-throughs are important to determine the current practices and business rules. In addition to those rules developed inside the organization, rules also come from a number of external sources in the form of laws, common business practices, vendor requirements and customer needs. Legislation can suddenly change existing rules as events occur or moods change, forcing strong influences on the way business is conducted. New customers or vendors can also place demands on the organization that force changes in procedures. Vendors may require adoption of new EDI (Electronic Data Interchange) processes to submit purchase requests or customers may have specific Just-in-Time order fulfillment requirements. With all of these external influences, the application framework must easily accommodate these constantly changing business rules.

Turning Business Rules into Code Implementing business rules involves trade-offs between ease of implementation and flexibility in maintenance. Some rules are relatively stable and can be implemented directly in the program code, but many rules must be implemented in a manner that is flexible, easily modified as requirements change. Often, a better solution is to encapsulate business rules into data structures, allowing easy maintenance by department managers or other authorized individuals. This allows faster response to changing conditions and eases the burden of program maintenance. Business rules vary from simple range checks and pattern matches on to complex interrelations between data sources. A payroll entry program may need to ensure that the number of hours worked does not exceed the number of hours in the time period, or that hours are not entered for

299

300

Building Application Servers future dates. A payables system must check to make sure that the same bill is not paid more than once. A billing system must locate the accounts that have balances that are more than 45 days past due. Each of these requirements are business rules that must be enforced by the program code. But business rules often extend past these simple, commonsense requirements into more complex areas, reflecting detailed knowledge of the business. The price of an airline ticket may depend on the date the ticket is ordered, the seating class, the distance traveled, the current cost of fuel, airport landing fees, current promotions, and a host of other variables. Just trying to understand the rules can be difficult. Transforming them into program code can be almost impossible. There are a variety of ways to implement business rules into program code, from simple range checks on through data validations to complex industry specific algorithms. These can be classified into the following approaches: • Structure based rules • Rules in code • Rules in data • Classifications

Structure-based rules The structure of the user interface program or database design will often assume or dictate certain business rules (USoft Corporation n.d.). The customer entry screen (and the corresponding customer table entry) has space for a mailing address, a billing address, and a shipping address. This implies that all orders will be shipped to a single address. Does this correspond to a similar business rule, or does the software design now dictate a new business rule? What happens when a new client wants shipments to several different locations? Is this a program problem or does this violate a basic company policy? Every application has to rely on a set of structural assumptions like the one listed above. No program can be designed to be totally open and configurable, so basic assumptions must be chosen and implemented. Nevertheless, the structural assumptions must be relatively stable; oth-

Enforcing Business Rules

erwise, the application will be too restrictive or will become a maintenance nightmare. As business rules are collected and formulated, each should be evaluated against the basic design decisions to ensure that the decisions do not conflict with the business rules. There will be times when tradeoffs must be made. Each should be carefully evaluated among the users and software developers. Often, the users may not understand the technical nature of the restrictions; but quantification into dollars and cents will often help move the decision along. The Y2K "problem" was a structural decision that is commonly seen as an example of shortsighted software development. Yet it does illustrate the decision process and the trade-offs necessary in any design. In the early 1960's data storage space was extremely expensive, technology was changing rapidly and most applications were replaced every five to ten years. In light of these basic assumptions, paying for additional disk space (if my memory serves me right, in the early 1980s, 400MB cost about $25,000) to store repeated occurrences of the digits "19" made little sense. No one foresaw the change in the economic environment with its emphasis on downsizing and cost reductions that prolonged the life of these applications. Every structural decision has similar trade-offs so make sure that they are compatible with the current business rules.

Rules in code The traditional approach to business rule enforcement is through program code. Early batch systems relied on separate front-end edit programs to validate the data and make sure it conformed to business rules before it was merged into master files. Online systems use similar gatekeeping code to validate keyed data. Databases also provide constraints, stored procedures and triggers to check data before it is stored in the database. Each of these approaches are effective for data validation, but suffer some of the same adverse effects as the structural assumptions listed above. Any time a business rule changes, the program code must be modified to reflect the new rule. These changes do not have the impact of structural decisions, but do require software changes that must be scheduled among the scarce resources of the technical staff. Each change requires a certain amount of time to respond and introduces risks to the integrity of the software. Like structural changes, business rules imple-

301

302

Building Application Servers mented as program code should be limited to relatively stable rules that will not change over time. When it is appropriate to implement rules as program code, a number of techniques can be used. Most are used for input validation, relying on range checking or pattern matching. Once each individual field is validated, comparisons are sometimes made to check interdependencies or to check derived results. Each of these checks is usually performed within the user interface or as data is first accepted by the service interface.

Simple field validations Most user interfaces begin with field validations: checking that required fields are nonblank, and that each value entered matches the correct data type, does not exceed the field length, and fits within a range of values. These requirements are usually derived from structural requirements specified in the database design, so they are permanent, global requirements that will not change over time. Because they are structural requirements, it is logical that they be hard-coded into the user interface. Most user interface development tools include field validation as part of their basic functionality. A text box is defined according to size, field length, data type, edit mask, and other properties that automatically validate the data as it is keyed. A numeric field will not respond to alphabetic characters, and a date field must conform to the standard date format. When incorrect data is entered, an error is automatically generated without requiring any additional code. Range checking is also provided by many of the GUI interface tools, either as properties or through field validation rules. Using these programming tools, the validation rules are embedded in the form design and little additional programming is necessary. Sometimes the GUI tools will have deficiencies that require additional validation code. As an example, the customer applet described in the previous chapter accepted a customer number. Suppose this customer number has the following requirements: • The customer number must be numeric • The customer number must be five digits long Since this is a structural requirement, it would make sense to embed this validation into the user interface program. In Visual Basic, these

Enforcing Business Rules

would be simple requirements that could be placed onto the form by using a masked edit field with a five-digit numeric input mask. In Java, using only the AWT interface objects, the validation would have to be implemented in code, and Listing 12-1 shows the implementation of a simple private method to perform this logic. Listing 12-1: Validating the Customer ID private boolean isValidCustomer (String cust) { if ((cust == null) || (cust.length() == 0)) { msgBox ("The Customer ID number is missing"); return false;

if (cust.length() != 5) { msgBox ("The Customer ID must be 5 digits long"); return false;

try { Integer i = new Integer (cust); } catch (NumberFormatException e) { msgBox ("The Customer ID must be all digits"); return false; } return true;

The method isValidCustomer receives a string containing the customer number entered on the user interface screen. If the string contains a valid customer number, it returns true; if not, it displays an error message onto the screen then returns false (alternate approaches could be used that would be less coupled, but this code provides a relatively easyto-read implementation). The first comparison checks to see if the string contains data and, if no data is found, displays a message stating that a

303

304

Building Application Servers customer number is missing. A second comparison checks to make sure that the field is five characters long. A third test attempts to convert the number into an Integer class. If this fails, the NumberFormatException is caught and an appropriate message is displayed. A call to this new method can be placed into the customerTextJbcusLost event handler (Listing 12-2) to ensure that the customer number was keyed correctly. If the method fails, the code uses the return statement to stop the event handler; otherwise, the handler continues to either create or locate the customer entry. Listing 12-2: Using the isValidateCustomer method void customerText_focusLost(FocusEvent e) { CustomerData cust; String custnumber = customerText.getText(); if (isValidCustomer(custnumber) == false) return; / / ... remaining code for method

Simple interdependencies Once each field is validated, you may need comparisons to ensure that data is consistent across the form. Selecting a check box may require an entry in a certain text field. When the user enters an end date, it cannot occur chronologically before the start date. These validation rules can often be entered as field properties within the GUI development tool. When this capability is not available, these checks can be done immediately after a field value changes or when the save button is pressed. To illustrate how these interdependencies can be implemented in code, our customer screen will be enhanced to include a class code indicating the customer's industry category and a credit limit amount. The following business rules describe the relationship between the class code and credit limit: • A manufacturer (class M) cannot have a credit limit greater than $20,000.

Enforcing Business Rules

• A retail store (class R) cannot have a credit limit greater than $ 10,000. • A food service company (class F) cannot have a credit limit greater than $5,000. These rules will be implemented using a variety of different techniques, but in this first example the rules will be implemented as declarative rules, embedded into the user interface. Listing 12-3 shows how this code can be implemented. Using a private method similar to the one implemented above, the class code and the credit amount are passed to the method. Each test determines if the credit limit is appropriate for the class code. If the credit limit exceeds the amount, the code displays an error; if not, the method returns true. Listing 12-3: Verifying the credit limit private boolean isValidCreditLimit (String classCode, long creditAmt) { if (classCode.equals("M") && (creditAmt > 20000)) { msgBox ("The credit limit for a manufacturing " + "client cannot exceed $20,000"); return false;

if (classCode.equals("R") && (creditAmt > 10000)) { msgBox ("The credit limit for a retail client " + "cannot exceed $10,000"); return false;

if (classCode.equalsfF") && (creditAmt > 5000)) { msgBox ("The credit limit for a food service " + "client cannot exceed $5,000"); return false; } return true;

305

306

Building Application Servers Implementing this method in code is probably not a good idea. Additional class codes could be defined or the credit limit rules could change. Implementing this code in the user interface is even a poorer decision, because any change will have to be distributed to every workstation. Derived results Often, validations depend on results derived from several fields entered on one or more of the user interface screens. In a loan approval application, the monthly loan payment cannot exceed the total monthly income less all other monthly bills. Other rules may involve the debt-toasset ratio or payment-to-income ratios. When the rules are structural, like checking that the payment does not exceed the difference of income and payments, the validation can be done inside the user interface.

Rules in data Rules embedded in the program code are initially easier to code, but cause more difficulty and cost over the life of the software. Unless documentation is kept up to date, the rules are not readily available to those outside the IT department. Changes must be made by programmers skilled in the appropriate programming language who are also familiar with the application. Even then, there is always a risk that additional program problems may be introduced. These changes must be scheduled into the programmer's workload, then tested and verified before the changes can be released back to the users. Unless the rules are extremely stable or are intimately related to the structure of the program, placing business rules in code is not a good idea. Often it makes more sense to place the rules in data structures where they are accessible by those outside the IT department. You can set up tables to hold important thresholds and rule criteria so that authorized managers can respond as business demands change or as new products or policies are introduced. The current status of a business rule can be quickly retrieved by requesting a report instead of waiting for a programmer to read through the data and write a memo. The flexibility of data-driven business rules also allows a greater range of latitude between products, suppliers or customers.

Enforcing Business Rules

Almost any business rule can be implemented in a table-driven manner. Rules are usually differentiated by line of business, customer, product, supplier, or other key business dimension. Within these dimensions, boolean (yes/no) fields can be created to establish which rules apply, while thresholds like credit limits or allowable turn-around periods can be stored and compared. These entries can be stored within the database, usually within some type of classification code table, then quickly retrieved to perform business rule validations. As an example, a business rule may state that all payments must be turned around within 15 days, but as cash flow pressures begin to appear, the turnaround must be altered to average around 20 days. The firm may need to pay certain critical suppliers sooner to ensure that supply chain sources are not cut off, while other vendors may not be as critical. Adding turnaround-day fields for each vendor would solve the problem, but would remove a critical business rule because each vendor's turnaround could be changed on the whim of the payables clerk. A better solution would be to set up a vendor class code to indicate how critical the vendor is to the supply chain. You could then build another table listing each class code, then assign turnaround days to each vendor class. Implementing rules as data structures is somewhat of a misnomer, since it usually requires more program code than if the rules were hardcoded. The data structures must be loaded into additional objects, which can then be accessed to check the data against the rules. You'll also need additional code to create user interfaces to allow authorized managers to change the rules. Even so, the added flexibility far outweighs the additional front-end programming and subsequent maintenance. Lookup tables Most applications use codes to standardize classifications and to streamline data entry. A region code classifies and standardizes a supplier's geographic location. A zip code can be keyed to retrieve the city and state where a customer lives, eliminating a large number of keystrokes and standardizing the text of the city and state. Most applications rely on a large number of lookup tables to standardize their data. You can use lookup tables to populate pull-down boxes, to fill textual descriptions, and to restrict field entries. You can also use them to reflect

307

308

Building Application Servers structural business rules, each stating that the field must contain one of a finite number of codes. These rules are not as tightly embedded in the software as the structural rules described above, since radical changes to the code definitions cannot be done without changing all other existing data. Where the flexibility arises is in the ability to add new categories and classifications easily. You can also use the classification codes to aggregate data and generalize business rules across groups of similar business entities. Usually, rules also exist outside of the application that determine how these classification codes are set, and reflect information that may not be available within the data structures. A customer classification code may reflect a number of factors not specified in the data that includes the types of products or services that the customer provides. A credit rating may represent the aggregate of a large amount of data that is only accessible to a credit bureau. What may appear to be a simple list of codes and descriptions often represents a large body of business rules both inside and outside the application. The lookup table provides a much better approach for the credit limit validation example shown above. A table can be set up to describe each code and also contain the maximum credit limit allowed for each class of customer. Figure 12-1 presents the table that represents the code implemented in listing 12-3. Once this table is established, you can create a rule object that holds the data and uses it to perform rule validation or derive credit limits by class code. Listing 12-4 is an implementation of the CreditRules object.

Class Code

Description

Credit Limit

M

Manufacturing

$20,000

R

Retail

$10,000

F

Food Service

$5,000

Figure 12-1. Credit validation table

Enforcing Business Rules

The object holds two arrays: one containing the class codes, the other holding the credit limits. The constructor initializes the arrays and sets the array counter to zero. When the object is created by the persistence layer, the credit limit table will be read from the database; then each row of data will be inserted into the CreditRules object using its add method. Each add method call inserts the class code and credit limit into the next entry of the array, then increments the array counter. Once all credit limit entries are added, the object is ready to be released to the business object layer. Listing 12-4: CreditRules object implementation public class CreditRules { private final int MAX_C0DES = 10; private String classCode []; private long creditLimitf]; private int classEntries; public CreditRules() { classCode = new String [MAX_C0DES]; creditLimit = new long[MAX_C0DES]; classEntries = 0;

public void add (String cl, long Im) { classCode [classEntries] = cl; creditLimit[classEntries] = Im; classEntries++;

public long getCreditLimit (String cl) { int i = 0; while (UclassEntries) { if (classCode[i].equals(cl)) return creditLimit [i];

309

310

Building Application Servers

return 0;

boolean isWithinLimit (String cl, long Im) { inti = O; while (kclassEntries) { if (classCode[i].equals(cl)) return (Im <= creditLimit [i]);

return false; } } / / end class CreditRules The CreditRules object implements methods to retrieve credit limits or validate them. The getCredxtLim.it method receives a string containing a customer class code. This class code is matched against the classCode array until either a match is found or the end of the array is reached. If a match is found, the method returns the creditLimit amount that corresponds to the class code. If the end of the array is reached, the method returns a credit limit of zero. The isWithinLimit method performs similar logic, but returns a boolean representing a comparison between the credit limit submitted against the creditLimit amount in the array. If the submitted amount is within the limit, the method returns true. If not, or the class code is not found in the array, the method returns false. Note: to see the full implementation of the CreditRules object and how it is integrated within the application server framework, check the source code listings for this chapter.

Relational interdependencies Referential relations defined between tables are also often based on structural business rules. An invoice must contain a customer number that exists as an entry in the customer table. Each product code on the invoice must match an entry found in the product table stored in the inventory system. Often other additional data items found in the tables

Enforcing Business Rules

must match or conform to a predefined relationship. Items ordered cannot exceed the number of items in inventory or similar rules. Most of these rules can be implemented as direct comparisons, since the rules are structural and will not vary greatly. Explicit rule tables Declarative rules can often be represented by rule tables summarizing allowable conditions within a data structure. The simplest implementation is to add rule indicators or thresholds into code tables. In the payables example described above, each vendor is given a code indicating how critical their products are to the supply chain. Once these codes are defined (numbers 1 through 5, with 1 being most critical), the number of days between invoice and payment can be assigned to regulate cash flow. Figure 12-2 shows this table. Once it is implemented, a quick lookup can determine the date when the bill will be paid. You can establish other rule tables with far more complexity, with each row listing a combination of codes or conditions that must be met. In the managed care environment, each patient must choose a primary care doctor whose specialty matches the age and gender of the patient. Children

Vendor Class

Turn-Around Days

1 2 3 4 5

15 17 20 30 60

Figure 12-2. Vendor payment table

311

312

Building Application Servers must see pediatricians or family practice doctors; only women are allowed to see ob/gyn doctors; only adults may see internal medicine doctors. Figure 12-3 illustrates a rule table that would support all of the allowable combinations. To validate a selection, the program would locate the age and gender of the patient, then do a search on the table, matching doctor specialty, gender, and age. If a record is found, the rule is validated; if a record is not found, the validation fails. Often, the combination of rules grows to many more dimensions; but this brief example illustrates the basic principle.

Generalized rule tables When setting up rule tables, it is often difficult to differentiate all possible combinations of the categories. Specifying every possible permutation of options will expand the table into thousands of rows, resulting in a table far more difficult to manage than any program code implementation. Wild card indicators, a technique that denotes that a specific criteria is not relevant, will collapse the table into a manageable size.

Physician Specialty

Legend:

Age A A C C A A C C A

M LJL

FP (Family Practice) FP FP FP IM (Internal Medicine) IM P (Pediatrician) P OB (OB/GYN)

Gender

M F M F M F F

M - Male F - Female

A - Adult C - Child

Figure 12-3. Rule table for primary care doctor selection

Enforcing Business Rules

Figure 12-4 shows the primary care doctor table generalized using wild card indicators to denote that the criteria does not apply. Notice how the table collapses from 9 rows down to 4. To verify a selection, the program now looks for either an exact match or for the asterisk (*) character in a specific column. This technique works well for validating a single unique value such as the doctor's specialty code. Each rule is validating the selection of an individual specialty, given age and gender. Then, if an entry is found, the selection is valid; if not found, the selection is incorrect. Additional criteria such as chronic conditions (heart problems or diabetes) can also be added to extend the rules by simply adding more columns to the table.

Classification Often, classifying a business entity or activity can be just as difficult as enforcing the rules that apply to the class. Rules vary by arbitrary groupings that make little logical sense to anyone outside the group performing the work. As contracts are written, clauses are added that give special preferences or itemize exceptions to general rules. Trying to determine

Physician Specialty FP (Family Practice) IM (Internal Medicine) P (Pediatrician) OB (OB/GYN) Legend:

Gender

Age

* * * F

* A C A

A - Adult M - Male F - Female C - Child * - Any Gender * - Any Age

Figure 12-4. Generalized rule table for primary care selection

313

314

Building Application Servers when these exceptions apply can be difficult and, just as the code begins to work, the contracts are renegotiated. In addition to creating rule tables, it is often advantageous to create classification tables that can include the general rules, but also specify exceptions. An example is to classify lines of business that do not break down in a simple, hierarchical manner. Customers may be classified within the database by industry, location, and company size, but management may view their customers as manufacturers, retailers, food service, or small business. Small business may also be a food service vendor or retailer, but because they have less than twenty employees, management treats them as a separate market segment with totally different business rules. Unfortunately, the wild card technique illustrated above begins to break down when used to classify and categorize data. Suppose the table was used to try to locate an appropriate doctor for a given patient. A male adult could be assigned to either a family practice or internal medicine doctor; an adult female could be assigned to any of the specialties other than a pediatrician. If a single category is required, the choice would be random depending on the way the database server selected the data. In addition to using the wild card, you must set up some type of order of precedence to determine which categories have priority and which can be ignored. Sometimes a hierarchical arrangement can be used, beginning with one field, adding subsequent fields to narrow down the selection. In other cases, a multi-variant, best fit approach works, finding the closest matching criteria. Each will be examined below. Hierarchical classifications

Often, a hierarchical approach will work when classifying data. A number of criteria are used, such as industry, location, and size, to provide an industry classification. Manufacturers on the east coast will be treated differently than manufacturers on the west coast. Figure 12-5 shows a table arranged in hierarchical form. Each row begins with a column denoting the most general category, then each additional column adds more specific detail. As with the lookup tables described above, the table can be collapsed using wild cards to indicate that all categories apply. When setting up a hierarchical table, you must set up the structure with the most general category in the first column, with each subsequent col-

Enforcing Business Rules

Business Type

Region

Size

Classification

Manufacturer

Small

A

Manufacturer

East East

B

Manufacturer

West

Large *

C

Retail

East

Small

D

Retail

East

E

Retail

West *

Large * *

G

Food Service

F

* indicates that all categories apply

Figure 12-5. Hierarchical classification table

umn refining the general categories. Any deviation from this rule will result in ambiguity, with the possibility of more than one row matching the criteria. Fortunately, many classification structures match this hierarchical approach, so setting up this type of classification tree structure is relatively easy. The user interface program that manages the classification table can enforce some of the structural rules, but it is up to the person who manages the table to ensure that each case returns only one table entry. Multi-variant classifications Unless the hierarchical classification table has only a few categories, or the number of cases is small, errors can occur in these tables. Figure 12-6 illustrates a case with a potential for errors. Within the Manufacturer category, the East region, small businesses are in class A, all other manufacturers are in class B. This seems to be a logical assumption. Unfortunately, when the search is performed for manufacturing, East region, both rows are selected because East region matches both the East region and the wild card (All) region.

315

316

Building Application Servers

Business Type

Region

Size

Classification

Manufacturer Manufacturer

East

Medium

*

*

A B

* indicates that all categories apply

Figure 12-6. Hierarchical classification table returning duplicate rows

There are a couple of different techniques you can use to determine which case applies. The first is to use a best-fit approach, selecting the row that has the most specific case. The search can use a counter of columns that do not contain wild card indicators; the row with the highest number qualifies. This process will select the row that best fits the case in question. The other approach is to prioritize the rows, either using the position in the table or a priority code to indicate which row has precedence. This approach would easily solve the line-of-business problem described above. Figure 12-7 shows a classification table that can be used to determine line of business. Once the data is selected, it is sorted by priority; then the highest priority found (in this case, priority 1 is higher than priority 2) yields the proper line of business category. In Figure 12-7, by classifying the small business criteria as priority 1, small business will always be chosen before any other industry category.

Maintaining rule and classification tables The data stored in code and rule tables is just as sensitive as program code, so it must be carefully managed and controlled. Sometimes the tables can become almost as complex as program code, so complete documentation, with a number of examples, must be provided to insure that the tables are maintained correctly. Often these tables are best

317

Enforcing Business Rules

maintained by a business analyst or other information professional who can relate the technical details to the business requirements. In any case, storing rules as data structures does provide much easier access to business logic and allows the application the ability to respond quickly to changes in business requirements.

Where to Put the Code Business rule processing can be placed almost anywhere in the application server architecture. Rule logic can appear in the user interface, service interface, business objects, or even as stored procedures in the database server. Determining the best location depends on considerations that include code distribution, program efficiency, availability of data, and other program-based criteria. Once these restrictions are met, the code may be placed where it is most convenient.

Business Type

Region

Size

Classification

Priority

*

*

Manufacturer

East

Small Medium

1 2

Manufacturer Retail Retail Retail Food Service

*

G A B C D E F

East East West

*

Medium Large it

* indicates that all categories apply

Figure 12-7. Line of business classification table

3 2 2 3 2

318

Building Application Servers Figure 12-8 shows a diagram of the application server architecture annotated with the types of business rules that should be examined within each layer. In addition to the 3 architectural layers of the application server, the user interface program and the database server also can contain business logic. Each will be examined in the following sections.

User interface The user interface is where the user interacts with all levels of the application server, so any time an exception occurs, the exception must eventually appear on the user's screen. In addition to reporting problems, the user interface also is responsible for checking that data presented to the service interface is complete and matches the correct data formats. Once the data has been screened to meet these constraints, the data is passed on to the service interface.

User Interface: Field validations, field interdependencies and presentation of exceptions and errors

Service Interface

Business Objects

Persistence

Database Server

Service Interface: More volatile field validations, data related rule checking and routing exceptions back to the user interface Business Objects: Table based rule processing, code based rule processing and other complex business logic Persistence: Retrieve and create lookup and rule table objects.

Database Server: Relational integrity, data constraints and stored procedures

Figure 12-8. Location of the business logic in the application server architecture

Enforcing Business Rules

When errors occur or rules are violated, it is the responsibility of the user interface to present the error in an understandable, user-friendly manner. If a data item is incorrect, the field in error should hold the input focus after the error is reported. The message should also give instructions describing how to fix the error. "Invalid date" does not provide a meaningful description of a problem, but "The payment received date was not entered in month/day/year format" will give a somewhat better idea of the error. Presenting error messages in a helpful, understandable manner will not only make the system easier to use, it will also help sell the new technology to the users. In addition to presenting error messages, the user interface program should be responsible for enforcing stable, structure-related business rules. Distributing and coordinating code among a large number of workstations can be difficult, so the user interface should be kept stable. Also, in a multi-platform environment, there may be several implementations of the same user interface, so keeping the UI as thin and simple as possible will go a long way towards minimizing program maintenance. To manage this problem, only those business rules that are based on the overall structure of the application should be validated in the user interface. Data types, required fields, some range checks, and field interdependencies can be implemented in the user interface, but any other more complex validations should be moved to layers that are easier to maintain.

Service interface The service interface is primarily responsible for passing data and exceptions between the user interface and the business objects. As data is received, the service interface should check that the data conforms to structural requirements as well as more volatile data requirements. This is even more important in a multi-platform environment where several different user interfaces are implemented to support a variety of platforms. Field validations take little time, so duplication of field edits will not seriously impair performance and may catch problems before they can cause more serious application errors. The service interface is also the place to implement more volatile rules such as range checks and field dependencies. Service interfaces are only

319

320

Building Application Servers implemented on a few servers, so updating code will be much easier than distributing new user interface code across the network. Allowable ranges grow as business increases or currency devalues, so implementing these checks makes better sense on the server side.

Business objects Most rules will be implemented within the business object layer. Business objects model the business in software, so much of the model involves business rules and processes. When rules are violated, processing stops and the exception is thrown back through the service interface to the user interface screen, where it can be presented to the user. Rules can be enforced within an individual business object or through rule objects. The first place rules are often checked is in the setter methods and constructors. As properties are received, they are validated to make sure that they conform to the type and range that is expected by the object. This is also a good place to check structural, field-related business rules. If these requirements fail, an exception should be thrown back through the service interface to the user. Another place to check business rules is at the beginning of method calls. A post payment method should check that the transaction object matches an existing customer and that the check number has not already been posted for this account (no duplicate posting). Any violation of these structural rules should stop the transaction before it corrupts the database. If a rule test is more than a few lines long, such as a duplicate transaction check, it often makes sense to create a separate rule method to perform the logic. This separate rule method could be called at the beginning of the post payment method to ensure that the transaction is not a duplicate. If the check duplicate method fails, it can throw an exception up through the post payment method, back to the service interface. When a business rule involves a number of different objects, separate rule objects can be created to perform more complex rule validation. These rule objects communicate with the necessary business objects to check relationships and validate the business rules. This approach does pose problems, breaking encapsulation to expose attributes hidden inside the business objects or forcing tighter object coupling by requiring new support methods within the business objects (McClintock 1997).

Enforcing Business Rules

Persistence By the time the data gets back to the persistence layer, the data should be clean. Any errors trapped when the objects are on their way back to persistent storage (the database) are symptoms of problems within the business objects. Each object must maintain its attributes and relationships correctly or the application will not function correctly. Exceptions that occur at this layer should be logged to an application error table (as well as reported to the user) so that maintenance can be scheduled to repair the problems. The persistence layer does have a role in supporting rule processing by retrieving rule objects from the database. These rule objects will contain data structures that encapsulate the rule tables and implement the classification and verification algorithms. Often, these objects will be created when the server is first started so as to make them available once processing begins. Otherwise, the first user who needs a particular rule object will have to wait while the object is loaded into memory. It is also the responsibility of the persistence layer to make changes in rule tables immediately available to the rule objects through notification methods or synchronization techniques discussed in Chapter 13.

Database server The database server often will enforce rules through referential integrity, data constraints, triggers or stored procedures. Other applications may rely on the database server to enforce these rules, but within an application server architecture, errors found at the database server are difficult to send back to the user interface. Business object logic must conform to the structural requirements of the database, insuring referential integrity and maintaining data structures that conform to the constraints of the database. It is up to the business object designers to determine the database requirements before the data is stored. There are cases when errors will occur. Changes made to other applications may change data requirements, causing adverse affects on the persistence logic. Errors within the business objects may also cause data errors. When these exceptions occur, the problems should be sent to an application log where they can be monitored and repaired. Errors within the database will usually prevent data from being stored, and nothing aggravates users worse than lost data.

321

322

Building Application Servers

Standardized Error Handling Once an error occurs, it must be sent back to the user interface screen so that appropriate action can be taken. Since errors can occur anywhere in the application server framework, from service interface all the way down to the database server or other external applications, standardizing the error handling processes will simplify this difficult communication task. Standardized messages, exception objects, message handling and error logs, along with consistent procedures at each level of the architecture, will all make this process much easier to manage.

Standardized messages Good exception handling begins with good message text. Messages that are short, technically oriented or accusatory will confuse or offend users and make it difficult for them to correct the problem. At the other extreme are messages that read like novels, providing so much text that it is difficult to understand the nature of the problem. The object of the error message is to communicate the cause of the problem and offer suggestions to fix the error to the end user. Often, a one-sentence message supported by documentation or help files will provide the best user support. If the message on the screen is not sufficient to solve the problem, the user can go to a manual to find directions for resolving the problem. Another solution is to add a help button on the message box so the user can get additional online support.

Exception objects A set of standardized exception objects also makes it much easier to process errors. Exceptions can be classified by the type of error, data exception, warning message, rule violation, program error, database error, or other classifications; then, when an exception is thrown, a series of catch blocks can separate the errors. A data error may provide a message box, then stop processing. A warning box can display a message box with the options to cancel or continue, allowing the user to decide if changes are necessary. More serious application errors can call code to log the error and halt processing.

Enforcing Business Rules

Within each exception object, you can add additional attributes to make it easier to determine the location of the error and resolve the problem. Listing 12-5 shows the implementation of a custom exception object that handles data exceptions. It is similar to the one shown in the last chapter, but includes additional attributes to report the field in error and a help context field that can be linked to a URL describing additional help information. Listing 12-5: DataException class public class DataException extends Exception { private String fieldName; private String helpURL; public DataException(String s, String f, String h) { super(s); fieldName = f; helpURL = h;

public String getFieldName() {return fieldName;} public String getHelpURL() {return helpURL;)

When an error occurs within the service interface, the program creates and throws the DataException, supplying the error message, the field name, and the URL of the help page. The user interface program will then catch the error and display the message. If the user clicks the help button, the help subsystem is launched and the page specified in the URL is displayed. If the OK button is displayed, focus is moved to the appropriate control and the user can then correct the problem. Developing a set of standardized exception objects will simplify error reporting throughout the application.

Message handling Once you've standardized the exception objects, it is much easier to create a set of standardized error handlers when these exceptions are caught.

323

324

Building Application Servers When an exception is reported back to the user, the user interface can call a handler that not only reports the error, but offers online help for each message. A program logic exception can be caught by the calling method and passed to a handler that logs the message. Each will only require a line or two of code within the catch block, making programming much simpler. In the previous chapter, a method named msgBox was called within the Customer Applet example. Listing 12-6 shows the implementation of this method, which creates a frame containing a dialog window that displays the error message. A new frame (f) is created to contain the dialog window. After it is resized and shown, a new InfoDialog object is created, passing the frame reference, the title "Application Error," and the error message to the constructor. This new dialog is then shown on the screen. Listing 12-6: msgBox method implementation private void msgBox (String s) { Frame f = new Frame("InfoDialog"); f.resize(100, 100); f.show(); InfoDialog d = new InfoDialog(f, "Application Error", s); d.show(); f.dispose();

The InfoDialog class was derived from a similar example found in Java in a Nutshell (Flanagan 1996). It needs some additional work to make it completely functional, such as centering the box on the screen; but it does provide the basic functionality needed. It can be downloaded from the O'Reilly Website listed in the reference. Most Java GUI builders will also provide similar functionality through prebuilt classes or wizards.

Error logs Application and logic errors should not only be reported to the user, they should be logged into an exception database where they can be reported and analyzed. An error log should, at minimum, carry the name of the object, the name of the method where the error occurred, a text describing

Enforcing Business Rules

the message and the service that called the message. Additional information can include the user interface program, user name, and relevant data attributes or parameters pointing to a document or business entity (invoice, customer, etc.). The information logged must provide enough data so the programmer can recreate the failure and determine how it can be repaired.

Commercial Business Rule Engines Another approach to enforcing business rules is through a commercial business rule server or engine. These products create repositories of business rules, described in a proprietary language, that are deployed as a separate tier within a multi-tiered environment. Hooks either in the user interface or on the database server can trigger calls to the business rule engine when critical data items are inserted or changed. Once the rule engine is called, it gathers the necessary data to check the rules that apply, then intervenes if a rule is violated. The rule engine can also perform data classifications and derive results, rates, or limits based on these complex business rules. These business rule engines often rely on artificial intelligence technology in the form of knowledge bases and inference engines. A knowledge base is a database that contains large collections of facts and rules, each entered randomly as they are gathered by a business analyst. As they are entered, the knowledge base stores and organizes them in a manner that is accessible by the inference engine. When a rule is validated, the inference engine gathers the relevant facts and rules and generates a decision tree. This structure is used to organize the rules and dependencies to derive additional facts and then determine if any rules are violated. Once the knowledge base is built, it is incorporated into the application architecture either as a part of the business logic tier or as a separate business rule server. Some tools insert hooks into the user interface to trigger rule validations; others rely on database server triggers to perform the activities. In both cases, the hooks have little impact on the rest of the application, other than eliminating the need to implement business rule logic. As changes are sensed by the rule engine, the inference engine determines which rules apply, validates each rule, and then raises exceptions when rules are violated. Business rule engines can simplify development of rule-intensive projects by eliminating much of the application code needed to validate rules

325

326

Building Application Servers and handle exceptions. The knowledge base consolidates the business rules into a centralized repository and makes rule maintenance easier by providing a prebuilt user interface. The centralized repository also makes it easier to track rules as they change and keep documentation up to date. At the same time, business rule engines have several disadvantages. Each of the rule engines use their own proprietary rule definition languages that are declarative in nature and take time to learn. New programming interfaces must be implemented and new system administration chores are needed to maintain the additional architectural requirements. Cost/benefit tradeoffs must be analyzed to determine if the additional cost of implementing the rule engine outweighs the programming and maintenance costs of traditional programming techniques. Nevertheless, a commercial rule engine may be an excellent choice for applications that support complex or highly volatile business rule requirements (references and vendors listed in Further Reading at the end of this chapter).

Security and Authorization Strategies In the first section, business rules were defined as the procedures and policies that keep a company running. When a new application is introduced into the business, new procedures and policies must also be introduced to describe the roles and responsibilities revolving around the new application. Many of these are procedural, describing how the application will be used to support this portion of the business. Other rules and procedures assign responsibilities and tasks to specific people. Once these are determined, they must also be implemented as additional business rules within the application, limiting access to those authorized to perform the tasks (another development iteration). Implementing security within the application server architecture requires organizing the rules into a logical framework and then implementing them within the application code. Organizing permissions and restrictions can be along functional lines, mapping functions to roles or along organization lines, and mapping departments and individuals to program functions. Once this structure is determined, the appropriate data structures and objects can be designed to implement these requirements.

Enforcing Business Rules

Organizing security rules Scott Ambler, in a two-part series in Software Development, describes several different approaches for organizing application security (Ambler 1998). These include role-based, organization-based and account-based access. Each grants and revokes access to individual users, but logically organizes access in different ways.

Role-based security Traditional role-based security grants or revokes access rights to program functions or data tables based on specific user IDs. Each user is given an access profile, detailing the specific functions that can be accessed and an indication of the level of access allowed (read, add, update, delete, etc.). A variation of this is to create permission groups, patterned on specific job roles, that detail access rights and then assign each user to one or more groups. Control of access rights is centralized, managed by only a few authorized individuals.

Organization-based security Organization-based security attempts to model the business hierarchy, creating permission groups that model the departmental structure of the business. Depending on the department and job level of each user, they will have ownership or access to the data and functions in their department, as well as access to the functions necessary to perform their jobs. Managers are given responsibility to grant or revoke functions within their domain to subordinates or to people outside of the department as project needs arise.

Account-based security Usually access control is seen in light of functions and tables, granting or preventing access to screens or fields. Account responsibility further restricts this by separating the data by accounts: customers, lines of business, product, vendors, or other logical distinctions. As Mr. Ambler described in his article, using the database analogy, traditional security restricts access by tables and columns; account-level security restricts access by rows (Ambler 1998).

327

328

Building Application Servers

Where to implement security Once the security rules are determined and organized, they must be implemented in code. These rules are declarative, stating responsibilities and permissions that will change over time. As such, you should implement them as data structures so they can be changed without having to modify program code. Going back to figure 12-8 helps to determine where the rules should be implemented. Starting at the bottom, the database server will store the tables that contain the security rules. Other applications may also have database access restrictions built into the database server, but an application server should implement sufficient checks within the server to minimize the number of database-generated exceptions, since these are difficult to pass back to the user. You can implement database access restrictions to secure the database, but you should only use these as back-level checks to catch errors in the application security implementation. Security objects that encapsulate security-related data and methods are created by the persistence layer. Often, an initial security object is created when the server starts, which provides a variety of security methods or services that can be obtained by the service interface. Just as on the database server, the persistence layer should not be responsible for enforcing security. The business object layer now contains new objects that encapsulate the security rules. These objects are retrieved and stored by the persistence layer and provide methods that implement the security rules. There are any number of ways to design security objects, but most will require objects that represent users, groups, permissions and security exceptions. These can be accessed by the service interface to validate security rules. The service interface is another level that implements security logic, calling methods from security objects to obtain the information necessary to enforce the rules. Exceptions generated either by the security objects or within the service interface will be thrown back to the user interface to notify the user that a security error has occurred. Securityrelated services will also be implemented in the service interface to allow the user interface to determine what permissions are allowed or denied. Finally, at the top of the diagram, the user interface accesses the security services to determine what actions are permitted or denied. A user

Enforcing Business Rules

ID, retrieved from a welcome screen, network logon, or other source, is passed to the service interface to retrieve a list of capabilities and access levels. These capabilities are then used to control or restrict access to program functions and to disable or hide data items or buttons from user interface screens. When services are requested, the user ID should also be passed along with the other communication objects to allow the service interface to authorize or deny each service request. This will add an extra layer of protection to prevent unauthorized services from being performed by rogue programs or hackers.

Summary The application server architecture provides an excellent platform for supporting and implementing complex business rules. Some of the key points to remember when implementing business rules are: • Business rules are detailed, documented statements that describe or constrain business activities. • Stable, structural rules can be implemented in program code. • Volatile and declarative rules should be implemented in data structures, accessible without requiring program code changes. • Data validations, type checking and other structural rules can be implemented in the user interface. • All other business rules should be implemented within the service interface or business object layer. • Business rules should not be implemented on the database server since reporting errors back to the user can be difficult. • Commercial rule engines can simplify deployment of complex rule-based applications. • Standardized error handling will simplify application server construction. • Security can be implemented as an additional set of business rules.

329

330

Building Application Servers

References Scott W. Ambler. "Object Oriented Security." Software Design, November 1998: 69-71, and December 1998: 65-67. David Flanagan. Java in a Nutshell. Sebastopol, California: O'Reilly & Associates, 1996: 104-105. Colleen McClintock. "The Logic of Business Rules." Software Development, November 1997: 44-50. Usoft Corporation. "Business Rule Automation." n.d. Available from http://www.usoft.com/whitepapers/business_rules/brwpv4.htm

Further Reading Business Rule Engine References Blaze Software, Inc. Available from http://www.elements.com Gottesdiener, Ellen, and Jim Bruce. "The Value of Standardized Business Rules." Object Magazine, March 1998: 22-28. Ross, Ronald G. The Business Rule Book: Classifying, Defining and Modeling Rules. Houston, Texas: Business Rule Solutions, Inc., 1997. USoft Developer, and Usoft. Available from http://www.usoft.com Vision-Builder, and VisionSoftware. Available from http://www.vision.com

Chapter 13

Multiprocessing, Concurrency, and Transactions One of the most striking differences between traditional client/server development and the application server environment is the need to service a large number of users simultaneously. Instead of relying on database servers to manage concurrent access, it is now the responsibility of the application programmer to anticipate these needs, making sure that one user's service request does not interrupt or corrupt another service already running. Because of this added complexity, the programmer must decide when objects can be shared, when separate instances must be created, how to synchronize persistent data between objects, and how to coordinate changes in data when there is a chance that it can be modified by other applications. Fortunately, you have many tools and techniques available to handle these issues. You can purchase middleware tools to replace some of the functionality that used to be provided by the database server. Most development environments provide tools to manage concurrent access, object brokers can assist in life cycle management, and transaction monitors can support complex application dependencies. There are also techniques that can ease concurrency and life cycle management. Application server implementation is far more complex than traditional client/server development, but with the proper approach, your application framework will be open, robust and ready to grow with your business. 331

332

Building Application Servers This chapter will examine the following issues: • The trouble with multiprocessing • Multiprocessing within the application server • The class factory model • Multi-threading • Synchronizing objects and data • Transactions

The Trouble with Multiprocessing Multiprocessing, the ability to service many different users at the same time on the same machine, introduces several new issues that are not often addressed in traditional client/server development. These are not new issues, but they do take on new forms when applied to distributed, object-oriented programming. Traditional mainframe programmers have taken on these same issues for many years, using well-established tools like multitasking operating systems and transaction processing monitors. Now that these same issues are appearing in the client/server market, many of these products are now appearing in new forms, modified to address object-oriented development and component architectures as well as client/server middleware functionality. Multiprocessing issues arise when more than one process shares the same computer. Several workstations may request the same service simultaneously, so as each message is received by the service interface, the same method call will be issued for each request. Each request executes the same block of program code, either using the same or different instance variables depending on the threading capabilities of the distributed object middleware. As the number of service requests increase, multiple instances of the same service interface or business object can be created, but this complicates each object's implementation with processes that must synchronize the instance variables between objects. Also, with many processes accessing multiple data sources, ensuring data integrity will require careful planning.

Multiprocessing, Concurrency, and Transactions

The first step in addressing these issues is to get a firm understanding of each problem. Some of these are obvious; others are more subtle, with hidden side effects that may not be readily apparent. These issues can be categorized as follows: • Multi-tasking • Multi-threading • Multiple objects • Multiple, synchronized data • Multiple data sources

Multi-tasking Any time two or more processes share the same computer, certain obvious events will occur. The computer will have to divide its resources, primarily CPU cycles and memory space. Additional overhead will be required to track which task is currently running to determine when and how often to switch tasks and how to schedule processes efficiently. This is not a new requirement (even desktop machines have these capabilities), but supporting multi-tasking for a large number of users does impact the scheduling requirements. Multi-tasking services are provided by the operating system, so the programmer does not have to be concerned with implementing these functions. The programmer does, however, have to consider how the multi-tasking implementation affects the execution of the program code. The more separate processes launched on a single machine, the greater the impact on the time available for each individual process. This may not impact short transactional services, but it does have implications when longer processes like complex calculations or table searches occur. If the task cannot complete during one scheduling cycle, the multi-tasking scheduler may lower its priority to allow other short tasks to complete, forcing the longer task to run in the background, taking even longer. Multi-tasking also occurs when any type of interrupt or asynchronous event is received, including another workstation's request for services.

333

334

Building Application Servers When a client workstation sends a message requesting a service, the network hardware interrupts the operating system to receive the message. It is then placed in a message queue, which is passed on to the middleware. The middleware then processes each message as it is received, performing the requested service, then sends back the result obtained by the service's method. Depending on the middleware implementation, these processes may implement multi-threading, adding more potential problems.

Multi-threading Multi-threading is similar to multi-tasking, but occurs within a single program, sharing common address space including program code and memory. The amount of support for multi-threading varies by middleware implementation, but threads are almost always used to optimize throughput (Mowbray and Run 1997). The Java virtual machine uses threads extensively to provide concurrent processing within each "sandbox," and threads can also be implemented by the programmer to allow applications to use idle time more effectively. It is almost certain that most application server components, both middleware and application software, will be working in a multi-threaded environment. Threads can have dangerous side effects when not used correctly. Since several threads can run within the same address space, each thread must ensure that it does not corrupt another thread's local variables. If a method implements a calculation with several intermediate results, one thread may begin by calculating results A and B; then, by the time it completes calculating result C, a second thread may have already replaced calculation A, corrupting the final result (see Figure 13-1). Most programming environments do provide ways of protecting fragile code segments, but it is up to the programmer to implement these precautions. Since many of the application and middleware environments do rely on multi-threading, creating and managing multiple threads on their own, it is important for the programmer to know when threading occurs and how it impacts application code. Most programming tools and debuggers provide thread monitors that list the threads that are open and can examine the code that is affected. Study the documentation to see how the middleware uses threads and make sure that fragile code is protected from data corruption.

Multiprocessing, Concurrency, and Transactions

Thread 1

Thread 2

A=1 B=2

C=3

A=10

D=A+B+C D=10+2+3 ?? D=15??

B=20

Figure 13-1. Data corruption by thread execution

Multiple objects As more users access the application server, more business objects will be instantiated to handle all of the customers, invoices, and other business entities. Creating each of these objects will take time and memory space inside of the application server. Some business objects are shared by a number of different users, so they will be frequently accessed and should be kept in memory. Other objects will represent individual entities or documents that will be requested by one user and then stored back to the database, not to be accessed again for several days. Ensuring that the right objects are in memory at the right time takes some initial planning. The frequently used objects should remain in memory, accessible without waiting for the persistence service to retrieve them from the database. Transient objects such as customers or invoices should only be loaded when needed, then stored as soon as possible to conserve memory. Distributing objects among several servers also requires some advance planning and consideration. As the number of users grow, the amount of objects, memory, and CPU time are all impacted. The ability to distribute objects over multiple computers also adds complexity to the entire application server framework. The persistence layer must know how to distribute the objects, both to optimize resources and to provide

335

336

Building Application Servers efficient communication between related objects. At the same time, the service interface and the other business objects must know how to locate objects quickly and return results in as short a time as possible.

Multiple, synchronized data When more than one user has access to application data, changes made by one user must be synchronized with data accessed by other users. In the traditional two-tiered approach, the database server handled this with little difficulty. Within the application server, it is now the programmer's responsibility to ensure that multiple instances of the same data get synchronized. Objects are often duplicated as they are encapsulated in higher-order business objects or as they are replicated across multiple servers. When this happens, their attributes must be synchronized so that changes stay consistent between object instances. Another problem occurs when data residing in a database is changed by external applications. The data residing in the table may also be represented by a business object residing in memory. When the external application changes the data in the database, the change must be sensed so that the objects can be notified to refresh their data.

Multiple data sources A final issue you must consider is synchronizing data from a number of different sources. When a transaction is posted, data may be changed, both in local objects and in external application data. If an error occurs anywhere in the transaction chain, the entire transaction must be rolled back; otherwise, the data will not be consistent and may cause later application errors. Database servers provide transaction facilities to isolate transactions within an individual database server, but when multiple servers or data sources are used, transactions must be handled at the application level, not within the database server.

Multiprocessing, Concurrency, and Transactions

Multiprocessing Within the Application Server The first step in solving these multiprocessing issues is to determine how they impact the application server. The architectural model (see Figure 13-2) helps isolate the issues by application server layer. The service interface is responsible for handling concurrent service requests; the business object layer must be scalable, ready to expand as the needs of the service interfaces grow, while the persistence layer must synchronize data between business objects and databases and maintain the integrity of the data. Each of these will be examined in detail below.

Service Interface

Service Interface: Class factories

Business Objects

Business Objects: Concurrency, locking and transaction support

Persistence

Persistence: Multi-threading, concurrency, locking and transactions

Database Server

Figure 13-2. Multiprocessing across the application server architecture

337

338

Building Application Servers

User interfaces User interfaces are not concerned with multiprocessing because each workstation services a single user. Services are requested by the user interface program; then, the results are displayed on the screen so the user can interact with the data. Multiprocessing should appear transparent to each end user, and it is up to the service interface to make this transparency occur.

Service interfaces As each service request is sent, the service interface must quickly receive the request, access the relevant business objects then return the requested results. The number of requests can vary according to time of day or season, but the service interface must handle the peak demands whenever they occur. Also, as the company grows, the service interface layer must be scalable, ready to grow as the number of users increase. A technique that works well on the front end is the class factory. Instead of exposing a single service interface for multiple users, each user interface first binds to a factory service that creates new instances of the service interface. This new instance is then registered with the naming service and the location is passed back to the user interface. Once the user interface program binds to this new service interface instance, it has exclusive access to its own unique service implementation, solving many of the concurrency issues. This unique instance can hold state attributes or implement background threads to preload anticipated information.

Business objects In traditional transaction processing systems, it was the database tables and files that were synchronized by the transaction monitor. In an objectoriented environment, the transformation of the business objects are now the basic units of each transaction. A transaction-oriented service request will retrieve the necessary objects, call methods that modify the state of each object, and then release them back to the persistence layer. An error at any time during this sequence will cause the entire transaction to fail. In the application server framework, the transaction facilities must now encompass the business objects as well as any data transformations.

Multiprocessing, Concurrency, and Transactions

Most of these requirements will be embedded in the service interface and the persistence layer, but the business objects may also need methods to support prepare, commit, or rollback operations. Also, when business objects are replicated across multiple servers, notification methods may be needed to synchronize attribute changes between objects. Ideally, the business objects should not have to concern themselves with these infrastructure issues, but, depending on the implementation, additional methods may be necessary.

Persistent objects The persistence layer is responsible for creating objects, managing their life cycles, and ensuring the integrity of the data. In a multiprocessing environment this requires a number of additional features, including concurrency and transaction support. Concurrency control ensures that only one process can change an object at a time. Often this can be accomplished by implementing locking and unlocking capabilities within the persistence layer. As long as the remaining infrastructure follows these locking rules, business objects will not be corrupted. In addition to concurrency control, transaction support requires that additional coordination be provided to control how objects are stored back to the database using prepare, commit, and rollback methods. The prepare method checks that all object attributes conform to the business rules and that the data structures are in place to store the data safely. If all transaction steps pass the prepare method, the objects can be stored back into the database using the commit method. If any errors occur, the rollback method can be called to restore the original objects from persistent storage.

Database servers Traditional client/server development depended on the multiprocessing capabilities of the database server. As the number of users and connections increased beyond the capacity of the database, performance began to suffer. Using the application server architecture, the database server now has fewer connections and no longer has to perform all of the multitasking work. With transaction processing handled by the application server, the database can be distributed over several servers with less chance that data

339

340

Building Application Servers will be corrupted. Each of these changes should allow the database server to run faster and provide better throughput for the application.

The Class Factory Model In previous discussion of the service interface, it was assumed that a single instance of an object responded to all of the requests received by the user interface programs. This is often not practical. A single object cannot track state information between method calls, so the user interface must constantly pass the same state information back and forth, resulting in increased network traffic. Also, as the number of service requests grow, the response time will diminish as time is spent waiting for the service request to become available. A better approach is to establish corresponding service interface instances for each user interface. Creating separate service interfaces for each user allows each instance to maintain its own state information and track its own business objects. Less time is taken between service requests, since the business objects are already located and state information does not have to be sent across the network. At the same time, this approach does take more system resources as separate objects are created for each user interface and the middleware must track many more separate distributed objects. Nevertheless, a service interface that needs to track large number of objects or state information can benefit from this approach. Implementing this process is relatively easy using a technique called the class factory. The class factory model or pattern implements a single object that will create new objects (usually derived from the same base class) depending on the message sent from the calling program (Cooper 1999). The persistent object server examined in Chapter 10 used this same pattern. New class instances were created on demand by the object server, depending on the method and parameters received by the ObjectServer class. A call to getCustomer located the customer data, created an instance of a Customer object, then passed the reference back to the calling program. The class factory technique examined here will work in almost the same manner. The user interface program will obtain a reference to a class factory object, then use this reference to request an instance of the service interface object. The only difference is that the service interface will be tracked by the RMI Registry instead of in a collection class.

Multiprocessing, Concurrency, and Transactions

Applying the class factory model In previous examples, the user interface applet called the RMI naming service to obtain a reference to the CustomerServices interface, then used this reference to access each of the services (see Figure 13-3). Since all user interface applets use the same name to obtain the same reference, all applets access the same instance of the CustomerServices object. This works fine for a few users, but as the number of connections grow, the number of service requests to the CustomerServices object will also grow, and response time will begin to suffer. To create multiple instances of the CustomerService interface, a new service interface, the CustomerFactory, is added (see Figure 13-4). The user interface first calls the RMI naming service to obtain the reference to the CustomerFactory interface. Then, using this reference, it calls the getCustomerServices service request. The getCustomerServices method creates a new instance of the CustomerServices object as well as a unique name for the object, then registers these with the RMI naming service.

Request Reference User Interface

Service Interface Return Reference

Figure 13-3. Accessing a single CustomerServices interface

341

342

Building Application Servers Once this is complete, the getCustomerServices method returns a String object that contains the new unique name. The applet can now use this name to obtain the reference to a unique CustomerServices object that can be exclusively used by the user interface applet.

Creating the class factory object Implementing this process begins by defining a new service interface called the CustomerFactory. This service interface provides a single method called getCustomerServices that creates a new instance of the old service interface, registers it with the naming service, then passes the registered name back to the user interface applet. Listing 13-1 shows the

Request New Instance User Interface

Class Factory Return Reference

Create New Instance

Figure 13-4. Accessing multiple CustomerServices interfaces

Multiprocessing, Concurrency, and Transactions

interface definition for the CustomerFactory interface. The interface is defined in Java as a remote interface called CustomerFactorylnterface that defines a single method called getCustomerServices. This method takes no parameters and returns a string that can be used to obtain a reference to the new service interface from the RMI naming service. Listing 13-1: CustomerFactory interface definition import java.rmi.*; public interface CustomerFactorylnterface extends Remote { public String getCustomerServices() throws RemoteException;

Before implementing the getCustomerServices method, we must first go back and look at the implementation of the CustomerServices object. This object needs access to the persistent object server (ObjectServer) to perform its services and requires that a reference to the ObjectServer be passed to the CustomerServices constructor. Before the new class factory can create a new instance of the CustomerServices object, it must also have access to the ObjectServer reference. This can be accomplished by passing the reference to the constructor of the CustomerFactory,which is then stored as a private attribute. Listing 13-2 shows the implementation of the CustomerFactory object. It is a public class that extends UnicastRemote, inheriting the RMI functionality from its parent class. The class has two private attributes: the reference to the ObjectServer, and a counter that will be used to create unique names for the RMI naming service. The constructor method receives the ObjectServer reference then saves it as a private attribute as well as initializing the instance counter. Listing 13-2: CustomerFactory implementation import java.rmi.*; import java.rmi.server.*; public class CustomerFactory

343

344

Building Application Servers extends UnicastRemoteObject implements CustomerFactorylnterface private ObjectServer objSrv; private long instanceCount; public CustomerFactory(ObjectServer os) throws RemoteException { objSrv = os; instanceCount = 10000;

public String getCustomerServices() throws RemoteException { instanceCount++; String className = "CustomerServices" + instanceCount; System.out.println ("Creating instance " + className); try { CustomerServices custSrv = new CustomerServices (objSrv); Naming.rebind (className, custSrv); } catch (Exception e) { System.err.println ("Customer Services " + "not initialized"); System.err.println (e.toString()); return null; } return className; } } / / end class CustomerFactory The getCustomerServices method begins by creating a new, unique name by taking the word "CustomerServices" and appending it with a string representation of the instance counter. The first instance will be named "CustomerServiceslOOl", the second "CustomerServicesl002" and so on. The method next creates a new instance of the CustomerServices object, passing the reference of the ObjectServer to the constructor. This new

Multiprocessing, Concurrency, and Transactions

object is then registered into the RMI registry using the unique name created earlier. Exception handling is included to catch any RMI errors that may occur. If no errors occur, the new name is then returned back to the calling program.

Using the class factory The new service interface only takes a few additional lines of code on the applet side. Instead of a single call to the naming service to obtain the reference to the service interface, the init method of the applet now requires three separate steps (see Listing 13-3). First, it makes a call to the naming service to obtain the reference of the customer factory interface. This reference is stored in a local variable, custFactory. Using this reference, the name of a new instance of the CustomerServices object is obtained by calling the custFactory.getCustomerServices method. This name is stored in the string custSvcID. Finally, the reference to the new CustomerServices interface is obtained by formatting the name into a new URL and passing it to the RMI naming service. Once this is done, the reference is stored in the applet's private attribute custSvc, just as before. Listing 13-3: Changes to the applet to use the class factory public void init() { if (System.getSecurityManager() = null) System.setSecurityManager (new RMISecurityManager()); url o " / / " + getCodeBase().getHost() + "/"; try { CustomerFactorylnterface custFactory = (CustomerFactorylnterface) Naming.lookup (url + "CustomerFactory"); String custSvcID = custFactory.getCustomerServices(); custSvc = (Customerlnterface) Naming.lookup (url + custSvcID); } catch (Exception e) { System.err.println ("Cannot open remote Customer Services");

345

346

Building Application Servers e.printStackTrace();

Once the reference to the customer services interface is obtained, the rest of the applet can function using the same code as before—the difference being that each applet now has its own separate service interface on the application server. Any call made by the applet will be routed back to its own instance of the service interface object. Note that the persistent object server is still shared by all service interface instances, so business objects are still shared. A change made by one instance of the service interface to any business object will be immediately accessible by any other service interface.

When to use the class factory The class factory model should be used only when a large number of client programs share the same service interface or when separate interface instances are necessary to preserve state information. Using separate class instances does incur additional overhead, but it speeds up throughput when many users are accessing the same service interface at the same time. The technique also is effective when the interface uses many business objects or when many separate services are needed to complete a transaction. In these cases, each service instance can hold object references and intermediate results in memory between method calls, streamlining the execution path.

Multi-Threading An application server has to respond to many different requests at the same time from many different client programs. Each request must be handled quickly, with as short a wait as possible; otherwise, requests begin to queue up in the middleware layer and response time begins to drag. Since processing is distributed among several servers and each server runs independently, more work can be done if the servers work in parallel, anticipating the client's needs by preloading business objects and data.

Multiprocessing, Concurrency, and Transactions

Multi-threading is a feature of most operating systems that allows a single program to perform multiple execution paths at the same time. This technique can be used to implement background processing concurrently while the service interface handles other client requests. A telephone banking application will request the customer's account number. As the user interface reads the account holder's name, it could speed up response time if a thread ran in the background, loading a transaction history object. Then, when the customer requests their current balance or recent transaction history, the transactions are already in memory, ready to be quickly retrieved. Multi-threading does have some drawbacks. Since the program code can run more than once in the same address space, local memory variables can be corrupted. Also, debugging can be difficult because several execution paths are occurring simultaneously. Since other processes are also running in the computer, there is no guarantee that the execution paths will run precisely at the same time during each test. A local attribute that was corrupted on one test run may not be corrupted the next time. Another issue when examining multi-threading is to make sure that the middleware and drivers also support multi-threading.

Implementing multi-threading One place that multi-threading can speed up processing is in preloading business objects. This example will illustrate how to preload an object that acts as a lookup table to provide descriptions for customer class codes. Since the object will be needed every time a customer is displayed or entered, it makes sense to preload this object into memory. The same process can be used to load other lists, such as transaction activity or other code tables. Listing 13-4 shows the implementation of the ClassCodes object. The object uses two string arrays to hold the class codes and their corresponding descriptions. An array counter is also included to obtain quickly the number of elements in the array. The constructor initializes the arrays and sets the counter to zero. As each new element is added, the add method inserts the code and description into the array and then increments the counter. Note that duplication errors; bounds checking and other error handling are not included to simplify the example.

347

348

Building Application Servers Listing 13-4: ClassCodes implementation public class ClassCodes { private private private private

static int MAX_CLASSCODES = 50; String classCode []; String description^; int classLimit;

public ClassCodes() { classCode = new String [MAX_CLASSCODES]; description = new String [MAX_CLASSCODES]; classLimit = 0;

public void add(String c, String d) { classCode [classLimit] = c; description[classLimit] = d; classLimit++; } / / ... remaining methods not listed ... } / / end of class ClassCodes The persistent object ClassCodesTable loads the ClassCodes object. ClassCodesTable uses the same approach shown in Chapter 10, but uses a separate execution thread to allow other processes to run concurrently. Listing 13-5 shows the implementation of the CustomerCodesTable class. The class inherits its multi-threading capabilities from the class Thread, overriding the run method that is activated when the object's start method is called. The class has two private attributes, a reference to the JDBC Connection object and a reference to the calling program. This is used to provide a call-back to register the ClassCodes object once it is built (this will be discussed in greater detail below). The constructor receives these attributes from the calling program and stores them for later use.

Multiprocessing, Concurrency, and Transactions Listing 13-5: ClassCodesTable implementation public class ClassCodesTable extends Thread { private ObjectServer objSrv; private Connection conn; public ClassCodesTable(ObjectServer ob, Connection en) { objSrv = ob; conn = en;

public void run() { String clsCode; String descr; ClassCodes classCodes = new ClassCodes(); try { Statement stmt = conn.createStatement(); String sql = "SELECT * FROM Class_Codes"; stmt.execute (sql); ResultSet rs = stmt.getResultSet(); while (rs.next() == true) { clsCode = rs.getStringfClass"); descr = rs.getString("Description"); classCodes.add (clsCode, descr); } stmt.close(); } catch (Exception e) { System.err.printlnfSQL Error " + e.toString()); } objSrv.setClassCodes(classCodes); } } / / end class ClassCodesTable The run m e t h o d creates a new instance of the ClassCode object and loads it from the Class Codes database table. The run m e t h o d t h e n

349

350

Building Application Servers declares two instance variables, clsCode and descr, as Strings to hold the results of the table retrievals; then it initializes a ClassCode object, clsCode. Next, the run method creates a Statement object, executes a SQL command to retrieve the Code and Description items, and retrieves the result set. Each entry found is retrieved into the instance variables, then passed to the add method of the ClassCode object to insert the entry into the array. Once all entries are added, the Statement object is closed; then the run method issues a callback to register the new ClassCode object with the persistent object server. This callback process is somewhat confusing, but is necessary since the run method is not directly called, but runs as a separate execution thread. The persistent object server creates an instance of the ClassCodesTable object, then calls its start method to begin execution. Once the start method is called, execution continues within the persistent object server, but an additional execution path also begins within the run method of the ClassCodesTable object. Because the start method does not wait for the ClassCodeTable's method to complete, a callback is required to pass the reference of the new ClassCodes object back to the persistent object server (see Figure 13-5). The callback method setClassCodes is called at the completion of the run method to set the classCodes attribute within the persistent object server. Listing 13-6 shows portions of the persistent object server implementation that handles the creation of the persistent object and the callback method. The class ObjectServer is the same one shown in Chapter 10, but is enhanced to support the ClassCodes object. Once the initialization process completes, a call to the method getClassCodes will return a reference to the ClassCodes object. Since there is only one instance of ClassCodes in memory, it is stored as a private attribute instead of an entry in the hash table. This speeds access and ensures that only one instance of the table resides in memory. Listing 13-6: Adding the ClassCodesTable into the persistent object server public class ObjectServer { private Connection private ClassCodes

conn; classCodes;

Multiprocessing, Concurrency, and Transactions

public ObjectServer() {try { Class.forName ("sun.jdbc.odbc.JdbcOdbcDriver"); conn = DriverManager.getConnection ("jdbc:odbc:OrderEntry", "admin", "password"); } catch (Exception e) { System.err.println ("Connection error " + e.toStringO); return;

/ / ... other initialization code skipped ... ClassCodesTable clsTbl = new ClassCodesTable (this, conn); clsTbl.start();

public ClassCodes getClassCodes() { return classCodes;

public void setClassCodes (ClassCodes els) { classCodes = els;

Within the constructor, a Connection object is established with the JDBC driver as before and all other initialization code is performed (this was removed to shorten the listing). An instance of the ClassCodesTable object is created in clsTbl, passing this as a reference to the object server instance followed by the JDBC connection reference. After the clsTbl object is created, its start method is called to create the new thread and execute the run method. As the run method completes, it calls the object server's setClassCode method. This simply stores the reference of the new ClassCodes instance

351

352

Building Application Servers Persistent Object Server

public ObjectServer() {

Class Code Table Object

public void run()

codeTbl.start() // create classTbl

setCodeTable(classTbl); public void setCodeTable()

Figure 13-5. Thread execution and callback

into the dassCodes attribute. Later, when a service interface or business object needs a reference to the ClassCodes object, it can call the object server's getClassCode method to obtain its reference. Implementing a threaded persistent object does require some additional work, but it helps speed startup and user response time. The persistent object must inherit threading capabilities from the Thread class, must implement a run method that performs the multi-threaded code, and must receive all its parameters, including a reference to the object server, within the constructor method. The object server must also implement a callback method in addition to passing its own reference when creating the persistent object.

Multiprocessing, Concurrency, and Transactions

Synchronizing execution The ClassCodes example only runs once when the object server is initialized, so there is no chance of multiple threads running this same code. This may not be true when threads are used to load other objects like the bank transaction history described earlier. Since these threads can execute at any time, there is a good chance that one thread execution may not complete before the next request is received. If this happens, the same code could access the same memory variables at the same time. This can easily cause data corruption. Most programming languages that support multi-threading also provide facilities for isolating critical code to prevent memory corruption. In Java, a method can be declared synchronized to block more than one thread from executing the method at the same time. In the example above, the run method could be declared synchronized using the declaration: public synchronized void run() This declaration states that once a thread enters the run method, the method is locked until the thread exits the method. Then the method is unlocked until the next execution thread enters the run method. Since it is often difficult to determine when simultaneous execution may occur, it cannot hurt to add the synchronized declaration. The additional locking overhead will outweigh the amount of time that can be wasted trying to debug a situation where simultaneous execution occurs. See Java 1.1 Developer's Handbook, listed in Further Reading, for an exhaustive discussion of Java thread issues.

Synchronizing Objects and Data Just as multi-threading can corrupt memory variables, concurrent data access can corrupt database tables. Suppose two different users each want to change the same customer information. The first user calls the service interface and requests the information. Now the second user does the same. Each now has a copy of the customer on their screens. The first user changes the customer's last name and then pushes the save button, which sends a message to the service interface to store the data on the screen. Now the second user changes the customer's credit limit and then presses the save button. When the service interface updates the

353

354

Building Application Servers customer data with the information from the second user, the new last name is replaced with the original last name displayed on the second user's computer. The first change is lost. An effective approach to protect data from these types of corruption is through resource locking. Locking restricts access to a single process or user, allowing one user exclusive use of the resource while all other users are blocked from accessing or modifying them. The traditional approach is to use database locking, by requesting either table- or row-level locking. Another approach is to add locking mechanisms to the business objects, restricting write access to one process at a time. An additional option is to implement a locking strategy within the persistent object layer. Choosing the best approach depends on the scope and complexity of the application.

Locking at the database level The traditional approach has been to restrict access through database server locks. As database technology has matured, locking strategies have become more sophisticated and less restrictive. Early approaches relied on table locking, restricting all users from accessing a table when a change was made. Because this was such a broad restriction, most programmers did not hold locks while data was displayed to the user; instead, they would lock the table prior to the update, then release the lock immediately after the data was changed. This may have protected the integrity of the table structure, but did not prevent concurrency problems such as the one described above. Most programmers simply crossed their fingers and hoped that two users would not try to update the same data at the same time. As database servers advanced, row-level locking became the standard practice. As the data was retrieved, the programmer could specify that the rows selected were held exclusively by that user. If another user tried to access the data, a database exception occurred stating that the data was already in use. Options within the locking processes were available to allow other users to read the data while it was locked, but restricted locking requests as other users tried to gain access to modify the data. Deciding when database locking is appropriate depends on several factors. It is an ideal solution when other external applications also

Multiprocessing, Concurrency, and Transactions

modify data. Since the only common access point is the database, it is the only place where concurrent access can be coordinated. Database locking does have its drawbacks in that it can be more resource-intensive, relying on external server calls and network traffic to coordinate locking and unlocking. Even so, it is a reliable technology that provides a broad range of locking options and includes fail-safes to recover from deadlock conditions and lost connections.

Locking at the object level In an object-oriented environment, such as an application server, object locking can often be an effective alternative to database locking. Each object implements its own locking protocol and then restricts updates to only the process holding the lock. Since the service interface interacts with the business objects, not the database, it is easier to implement and eliminates the overhead and network traffic associated with database server locking. Listing 13-7 illustrates a simple object locking strategy. The object uses a simple counter, a boolean status indicator, and two new methods, lockObject and unlockObject, to control the locking cycle. When the service interface needs write access to the object, it first calls the lockObject method, which sets the lock status to true, increments the counter, and then passes the counter back to the service interface. Any time the service interface wants to update an attribute (such as the setNuml method shown in the listing), it must also pass the counter to show that it is the source of the object lock. Once all changes are made, the service interface calls the unlockObject method, passing the counter as its identifier. This clears the status indicator and, as an added precaution, increments the counter to invalidate the counter held by the service interface. Listing 13-7: Simple object locking implementation public class Locking { private long lockID; private bool lockStatus; private int numl;

355

356

Building Application Servers

public Locking () { lockID = 0; lockStatus = false;

public long lockObject() throws LockException { if (lockStatus) throw new LockException(); lockID++; lockStatus = true; return lockID;

public void unlockObject(long Ick) throws LockException { if ((lockID == Ick) && llockStatus) { lockID++; lockStatus = false; } else throw new LockException();

public int getNuml() { return numl;

public void setNuml (int n, long Ick) throws LockException { if (Ick = lockID) numl = n; else throw new LockException(); } } / / end of class Locking

Multiprocessing, Concurrency, and Transactions

In addition to the code to handle the status flag and counter, the lockObject, unlockObject and setNuml methods all implement error checking code to make sure that the locking protocol is followed. The lockObject method first checks that the object is not already locked. If it is, it throws a LockException. Note that the LockException should be enhanced to present some sort of message describing the error and stating which object caused the error to occur. This was skipped to simplify the example. The unlockObject and the setNuml methods also verify the current lock status as well as check that the lock ID presented by the calling program matches the current lock ID. This example is highly simplified, but does illustrate an approach that can be taken to ensure that objects are not corrupted by concurrent access. Object locking is an excellent choice when there is only one object representing each business entity and there is no chance that the object's persistent data can be updated by external applications.

Locking at the persistence level There are many cases where several different business objects represent the same business entity. Several invoice objects may encapsulate the same customer, or the same objects may be distributed to several different server machines to provide better throughput. When this occurs, a locking strategy implemented at the persistent object server level may make more sense. It may help to begin with a quick review of the object server design implemented in Chapter 10. We created a single persistent object server class that implemented two methods for each object. For the customer object, the getCustomer method located the object, either in the memory collection or from persistent storage, and then passed its reference to the calling program. The releaseCustomer method updated persistent storage and, when no longer in use, deleted it from the memory collection. Each object was stored inside a common wrapper that was stored in a hash table to allow quick access of objects already in memory. Implementing locking on the persistent object server is similar to the approach taken with object-level locking. You can enhance the object wrapper to hold locking information, including a lock status indicator and a lock ID similar to the one implemented in the object locking strategy

357

358

Building Application Servers described above. You could call a new method, lockCustomer, that would receive a reference to the Customer object and return a lock ID. The lockCustomer method can reload the Customer object from the database to make sure that it contains the most current data; then, the wrapper can be updated with the lock ID and lock status to prevent other objects from corrupting the object. You can also implement an unlockCustomer method that releases the lock and stores the object back into the database. You can also add exception handling to ensure that the object is unlocked by the process that holds the lock and that the lock is still in place. Other service interfaces can still use the getCustomer method, but will not be allowed to make changes to the object. The release method is also available, but will only handle life cycle chores, not update the database. Persistence-level locking is effective when objects can be duplicated or distributed across several different servers or multiple objects. Since the persistence service already is set up to handle the object life cycles, it makes sense to coordinate locking within this layer. This strategy also lends itself to supporting both object and database locking by coordinating both locking processes in the same place. As the object is locked, you can place database lock requests on the data rows that reflect the object attributes. This ensures that the data is changed in a coordinated manner, both inside the application server and with other external programs. Persistence-level locking will be described in more detail in the section on transaction processing.

Resolving deadlocks One final concern with any locking strategy is avoiding deadlocks. A deadlock is a condition where two different locks prohibit each other's processes from completing their tasks. Process 1 locks resources A, then B; process 2 locks resources B, then A. Process 1 completes the lock on resource A; process 2 completes the lock on resource B. Now Process 1 tries to lock resource B but cannot because process 2 got there first. Process 2 has the same problem with resource A. Both processes are now deadlocked. Neither can continue because each is waiting for the other process to complete. Database server developers have long understood this problem and included capabilities to automatically recover, either by timing out one

Multiprocessing, Concurrency, and Transactions

process or by using a two-phase commit, making sure that all resources are available before committing the lock. Similar precautions must be implemented by the programmer when implementing object- or persistence-level locking. Since the locking implementation shown above simply succeeds or fails, throwing an exception, careful coding of multiple locks will prevent the deadlock from occurring. If several locks are issued one after another, any locking failure should unlock all previous locks before the sequence is attempted again. Simply looping until the lock succeeds will sustain the deadlock. Listing 13-8 shows a code fragment that will help prevent the deadlocks. The code will continue to loop, trying to lock both resources A and B. If the either lock fails, the error flag is reset and the loop continues. If lock A succeeds, but lock B fails, lock A must be released to avoid the deadlock condition. Listing 13-8: Avoiding Deadlocks error = true; while (error) { error = false; try { lockA(); } catch (LockException e) { error = true; } if (! error) { try { lockB(); } catch (LockException e2) { unlockAQ; error = true;

wait(lOO); }

359

360

Building Application Servers Choosing the best locking strategy depends on how the objects are used within the application server as well as how much concurrent access occurs with external applications. Often, the best choice is to delegate locking to the persistence layer. This centralizes object locking within the application server and coordinates locking with the database server. The initial overhead is somewhat greater, but once implemented, allows better scalability as well as integration with other applications.

Transactions Locking works well when a single object or table gets modified; but, as illustrated by the deadlock issue, completing a sequence of operations can cause additional problems. These sequences, often called transactions, must be coordinated to ensure that all steps are completed and that when a problem occurs, the steps already taken are undone. In the deadlock example, the locks must be programmatically released to make sure that other users can update the objects. Later, as the changes are posted back to the database, any errors that occur at any one of the steps will create inconsistencies between the tables, which could cause application errors when the data is accessed later. Transaction processing ensures that the data stays consistent between a number of different data sources. Just like locking, most database servers provide transaction capabilities between tables inside the database. With the growth of distributed databases and application integration, transaction processing often must be implemented over multiple data sources to ensure that data remains consistent across the application.

Transaction basics A transaction, in computer science terms, is a group of logical steps that moves a number of items from one logical state to another. This could be a financial operation, as the name implies, or it could be a nonfinancial operation that coordinates the movement of information from one state to another. A transaction could be a transfer of funds from one account to another, or it could be a transfer of a person from one office location to another, changing the information in payroll systems, office directories, security systems, and other computer applications. Any change that

Multiprocessing, Concurrency, and Transactions

occurs between more than one data source can be coordinated through a transaction. A transaction has a starting point and an end point. These are often called the transaction beginning (beginftan in SQL-speak) and the commit point. At any time prior to the commit point, a rollback command will reverse all operations and move all data or objects back to their original states. Just like exception handling, this is a powerful programming construct that simplifies programming by eliminating much of the intermediate code and storage that would be needed to manually undo partial changes when errors occur. Once transaction processing is implemented, the programmer can simply state when a transaction begins, perform the operations, and then call the commit command at the end of the process. If an error occurs along the way, the programmer calls the rollback operation and all the changes simply disappear. Since the transaction capabilities are isolated in a few additional objects, the impact to the programmer is much lower than when handling each individual exception.

Implementing transaction objects To get a feel for the processes involved in implementing transactions, this section will examine how to enhance the sample persistent object server with transaction capabilities. Before a transaction begins, the service interface will request a transaction object from the persistent object server. This new object will be used to track the events that occur during the transaction. Each object will be retrieved using the lock method described above; then, after the object itself is changed, it will be inserted into the transaction object. At any time, a rollback operation can be called to undo the transaction; otherwise, a commit can be requested to commit all of the changes. Note that the persistent object server implements several new methods to support object locking. These methods include lock, store, reload, and unlock. The lock method locates the object, either from the database or from the registry, and then marks it locked to prevent other users from making changes. Store writes the account data back to the database. Reload retrieves the data from the database, clearing out any changes that may have been made. Unlock releases the account object (like the

361

Building Application Servers

362

release method), deleting it from memory if it is no longer needed, but does not store the data back into the database. Figure 13-6 shows a rough diagram of how the transaction object is created and a transaction is posted. In this example, $10,000 will be transferred into Account 1 from Account 2. To simplify the description, each step will be numbered and explained step by step. Several new methods have been added to the persistent object server and these will be described as they appear. 1. The service interface begins by requesting a new Transaction object from the persistent object server using the getTransaction

Service Interface

Transaction

Object Server

Account 2

Account 1

1 Step 1:

I I

1

getTransaction( w

new() ^

Step 2:

get(Accounti) 1

Step 3:

r lock(Accounti)

< get(Account2)

"^ lock(Account2)

| Ste p6:

i

1

I

1 1 1 1

|

ew()

1 Insert(Acounti)'

Step 4: Step 5:

H

1 1

| new()

'1

|

1 lnsert(Account2l)

Debit ($10,000)

P

I

Credit ($10,000)

|

|

I

I

1 1

I

Figure 13-6. Transaction processing, part 1

I

'I

Multiprocessing, Concurrency, and Transactions

method. This method creates a new Transaction object and returns its reference to the service interface. 2. The service interface next requests an account from the Transaction object using its get method. The get method is generalized to retrieve any object by parameter name. In this case, the arguments would be "Account" to indicate that an account object is requested, followed by the identifier 1, indicating that account number 1 is requested. 3. The get method of the Transaction object calls the object server's generalized lock method, similar to lockCustomer described above, which creates and retrieves the object Account 1 from the database. It is then locked within the object server to ensure that no other users try to modify this object. 4. Once the Transaction object's get method retrieves Account 1, it is registered into the transaction object's collection. 5. The same process is repeated for Account 2. 6. The service interface now calls Account l's debit method to post an additional $10,000 into the account. It also credits Account 2 for the same amount. At this point, the business objects reflect the changes that need to take place. If everything is consistent, the Transaction object's commit method can be called to post the changes to the two account objects. However, if an error occurs (for example, if an account number is incorrect or Account 2 has a balance less than $10,000), the changes must be rolled back. These processes are described in the next section.

Commit or rollback Once all operations have been performed on the business objects, the service interface can request the commit method from the Transaction object. If any error occur along the way, a rollback can be called to undo all changes. Figure 13-7 shows how the commit and rollback methods are implemented. To commit the transaction, the following steps occur:

363

Building Application Servers

364

1. The commit method will loop through each object stored in the transaction's collection. In this example, these are Account 1 and Account 2. 2. Each object will be sent back to the object server using the store method. This method determines the type of object received and then calls the appropriate table mapping object to store the data back into the database. 3. The object server's unlock method is next called for each object in the transaction's collection to remove the locked status for each object.

Service Interface

Transaction

Object Server

commitQ Stepi:

For each object:

Step 2:

* store(object)

Step 3:

* unlock(object)

rollback() Stepi:

For each object:

Step 2:

* reload(object)

Step 3:

* unlock(object)

Figure 13-7. Transaction processing, part 2

Account 1

Account 2

Multiprocessing, Concurrency, and Transactions

These steps are repeated until all objects have been stored to the database and unlocked. Rolling back the transaction performs similar steps, but restores each object, in effect erasing the changes instead of saving them. The following steps are performed: 1. The rollback method will loop through each object stored the transaction's collection. 2. The object server's reload method will be called for each object. This will locate the appropriate table mapping object and reload its attributes from the database, erasing any changes made during the transaction. 3. The object server's unlock method is called for each object in the transaction's collection. These steps are repeated until all objects have been recovered and unlocked. This process protects both the business objects and their data tables from corruption as the transaction is posted. If an error occurs anywhere along the way, the exception handler can call the transaction's rollback method and undo all of the changes. Unfortunately, it is not completely fail-safe, since an error during the commit process will still corrupt data. This is why databases and commercial transaction servers have implemented two-phase commit logic.

Two-phase commit Since databases rely on constraints and referential integrity to ensure that the data remains consistent within the tables, errors can occur when the data is sent to the database server. This can cause errors during the singlepass commit process illustrated above. To prevent these errors, a two-pass process is implemented. In the first pass, each object is checked for consistency to make sure that all database constraints as well as business rules are correct. Often this includes a nested database sub-transaction that stores the data, but does not commit the changes. Once each of these objects is checked (called a prepare operation), the status of all objects is checked to make sure that they pass all of the rules. If all objects pass the prepare

365

366

Building Application Servers phase, each object is then stored and the sub-transactions are committed. If any errors occur, all sub-transactions are rolled back and the transaction's rollback method is called to erase any changes made to the objects. This process, called two-phase commit, ensures that all data is stored consistently even when external errors occur outside of the transaction framework. Implementing two-phase commit would involve changes to the transaction object, object server and the table mapping objects. Each table mapping object would have to implement a prepare method that would check the object's internal consistency, then open a database transaction and store the data back into the database server (the changes would not be committed at this time). If an error occurs, the prepare method would return an exception. The table mapping object would also have to modify its store method to commit the database transaction and also implement a rollback method to send a rollback message to the database server. The persistent object server would also have to implement a prepare method, passing the message to the appropriate table mapping object's prepare method. The Transaction object would have to update its commit method to first call prepare methods for each object in the collection; then, if an exception was returned, the Transaction object would use the rollback method to erase all changes from the objects. It would also have to pass rollback messages through the persistent server back to the table mapping objects to roll back any subtransactions. If no errors occurred during the prepare method calls, the store method could be called for each object in the collection.

Commercial transaction monitors As can be seen by the previous discussion, implementing an object transaction monitor can be a long and tedious chore. Fortunately, many vendors have already done the work, integrating transaction capabilities into their middleware products. These object transaction monitors or object monitors provide two-phase commit and rollback capabilities in addition to their remote procedure, distributed objects, and message broker technologies (Boucher and Katz 1999). The OMG's CORBA specification includes a transaction service that is the model for many of the new object monitors. The transaction service (Orfali 1997) provides a transaction object that is similar to the one

Multiprocessing, Concurrency, and Transactions

described above called a coordinator, but is far more robust and stable (Orfali, Harkey, and Edwards 1997). Each object inherits transaction functions from the base classes Resource and TransactionalObject that provide prepare, commit and rollback functions within each business object. Once the transaction begins, each object is registered into the Coordinator object, then methods are called to post changes. Once all changes are complete, the Coordinator's commit method is called; then each registered object is first prepared, then committed or rolled back depending on the results of the prepare methods. Several vendors also provide transaction services for the Java environment that implement the OMG model. In addition, the Enterprise JavaBean specification includes object transaction services. Microsoft also provides the Microsoft Transaction Server (MTS) to support its DCOM architecture. Transaction objects are implemented primarily in Visual Basic and the architecture is more database-centric, relying on their SQL Server database platform. As the server side technologies continue to mature, object-based transaction monitors will become integral to all of the middleware products.

Summary Managing the multiprocessing requirements of an application server can seem overwhelming, but with a number of tools and programming techniques, you can address and resolve each issue. • Use the class factory model to implement separate service interfaces for each user interface. This way, state information and object references can be retained between each service request. • Use multi-threading to preload business objects before they are needed by the service interface. By having the objects loaded, service requests do not have to wait for objects to be retrieved from the database server. • Remember to synchronize threads to prevent memory corruption by other thread processes. • Implement a locking strategy to prevent corruption of objects and databases from concurrent user access.

367

368

Building Application Servers • Implement database locking when tables are accessed by both the application server and external programs. • Implement object locking when business objects are shared by multiple service interfaces. • Implement persistence-based locking when multiple copies of the same object instances may exist on several different servers or within more complex business objects. • Consider a combined persistence and database locking strategy to handle future growth and enterprise integration. • Implement transaction capabilities to coordinate changes across multiple objects or tables. • Select and obtain a commercial object monitor to implement the transaction capabilities.

References Boucher, Karen, and Fima Katz. Essential Guide to Object Monitors. New York: Wiley, 1999. Cooper, James W. "The Factory Down the Road," Java Pro, May 1999: 6065. Mowbray, Thomas J., and William A. Ruh. Inside CORBA. Reading, Massachusetts: Addison Wesley Longman, 1997. Orfali, Robert, Dan Harkey and Jeri Edwards. Instant CORBA. New York: Wiley, 1997.

Further Reading Heller, Phillip, and Simon Robert. Java 1.1 Developer's Handbook. Alameda, California: Sybex, 1997.

Chapter 14

The Next Generation of Business Applications The application server model will be an effective approach for building software in the twenty-first century, but it is only one of many different options available to the business software developer. Mainframe computing is still effective for large corporations, as millions of lines of code still perform their tasks effectively every day. Two-tiered client/server also offers an excellent option for less intensive database applications and there are a host of different Internet technologies available to deliver applications to Web browsers. In addition to existing technologies, the rapid rate of change will continue to bring new computing models that will spawn new software technologies. Just as client/server was a response to desktop computers, and a host of new software technology appeared in response to the Internet, other new technologies will continue to rise and shape the way that we build software. Looking into the future is a difficult and perilous task. Even the best minds in the industry have trouble seeing beyond the next few years. To see how well others have fared, I got out the book Programmers at Work, published in 1986 (Lammers 1986). The book is a collection of interviews with some of the industry leaders of the time; early Mac developers Jeff Raskin and Andy Hertzfeld, dBase author Wayne Ratliff, VisiCalc designers Dan Bricklin and Bob Frankston, and of course Bill Gates. If 369

370

Building Application Servers you can get your hands on a copy of the book, read it every few years to get your creative juices flowing. Towards the end of many interviews, the programmers were asked their prediction of the future. Looking at their responses, each pretty much related the future in terms of what they were currently working on, and those predictions that did come true occurred within a few years. None mentioned the technologies that have had the greatest impacts: visual programming, components, client/server, or the Internet. Only two mentioned anything close to Internet technology. Bill Gates saw the future applications, such as maps, travel references, sports trivia, flight information, and such, but saw Microsoft as the source and CD-ROM as the media. John Page, author of the pfs software series as well as initial designer of H/P's IMAGE mainframe database system, came the closest, mentioning quick access to a wealth of information online. He described how to find the perfect vacation spot using online services to locate resort features and to download maps and pictures. Another problem with trying to guess the future is that the software industry is already far too future-oriented. Products are announced and discussed in the trade press long before the products are on the shelf. Often, the aftermarket books appear weeks before the product is released. It makes little sense to mention those developments that will appear in the near future, since these topics are flashed across the trade magazines and the Internet every day. For future predictions to have any meaning at all, they must go beyond these beta technologies. With these preliminary cautions in place, it is time to begin to examine some of the factors that will shape business computing in the twenty-first century. This chapter will look at some of the rising trends in business software development as well as other developments that may shape the way we build software. These include: • Clues from the past • Emerging component standards • The application software marketplace • The emerging business platform • Final thoughts

The Next Generation of Business Applications

Clues from the Past Twenty-five years ago, I wrote programs using punch cards for a mainframe that had 96K of memory and filled a good-sized room. Today, my wife wears a Timex Datalink watch on her wrist that has more memory and as much computing power as that mainframe. At the time, input and output media relied on paper, so we wrote programs that supported a particular style of batch-oriented software that generated a lot of paper. As the capabilities of the mainframe grew and terminals became available at a reasonable price, the programming model shifted to online, transaction-oriented processing. Since computers are inexpensive and can be easily networked together, this book examines a new programming model that integrates these technologies. As technology changes, the way that we deliver business applications also evolves to exploit these new capabilities. Even so, the basic tasks that business applications perform have not really changed that much throughout those different programming models. They became more sophisticated, adding intelligence and knowledge capabilities that were not available when computer operators were feeding punch cards through the night; but the new applications still support the same basic business functions. They continue to post general ledgers, print paychecks, monitor inventory, schedule production, accept customer orders and support business processes. The level of communication and ease of use have changed, but the business processes have remained the same. What has changed over the years is the level of support that computer applications have provided. When businesses relied on punch cards, the computers were just support tools, speeding up processes that could just as easily have been done by a room full of accounting clerks. The computer did it faster, more accurately and (sometimes) more cost-effectively. As time went on, the amount of data accumulated by these early applications became a strategic resource in its own right, and businesses began to obtain value from the by-products of the early applications. Data Processing became Management Information Systems and then Information Technology as the role of the applications move from automation to information.

371

372

Building Application Servers Looking back through this process, several factors have changed over time. These factors will continue to change and will contribute to the way we build applications. Some of these factors include: • Increased automation • Ease of use • Business intelligence • Communications

Increased automation Automation, the ability to hand off processes from people to machines, was at the heart of the acceptance of business computing. As the cost of employees grew and the cost of computer hardware diminished, it made good business sense to move work from people to machines. A recent list compiled by the Bureau of Labor Statistics shows sewing machine operators, bookkeepers, typists, word processors, office machine operators, and even computer operators as the categories with the most job losses over the past year (Verdi 1999). The loss of each of these jobs point to ever increasing automation. Two of the jobs listed above illustrate multiple generations of automation. The word processors and computer operators both were positions that resulted from earlier automation cycles. Word processing grew out of the automation of typing, allowing easy corrections and storage of documents to speed the task of typing. Now, as word processing becomes pervasive within the organization, fewer word processors are needed and those who still perform these jobs often perform other jobs as well. Also, with the growth of email and other communication tools, other workers who used to rely on word processors now do their own typing. Computer operations also have followed the same path. As applications become easier to use, there is less need for specialized computer operators to schedule and perform tasks. Fortunately, the job of applications development has also benefited from automation. The tools to develop software have grown, automating some of the most elementary tasks. Code wizards are available to create basic program structures and automate coding of database interfaces. Visual programming

The Next Generation of Business Applications

provides frameworks to drag-and-drop components that encapsulate much of the user interface functionality. Many of the tasks that used to take weeks to code and test can now be done in minutes. At the same time, the level of automation required by business applications increase the demands made on the software developers. Instead of specialized operators who can adapt to poor user interfaces and complicated command languages, the applications must now be far more robust and easy to use. The person using the application is also responsible for many other tasks besides running the computer and must switch between a number of different job skills. Without a simpler, consistent user interface, the person will become confused and work will not be done correctly. In addition to user interface demands, the applications themselves must perform ever more complex tasks with more intelligence and decision making capabilities. All of these demands make programming much more difficult.

Ease of use As automation continues to move tasks from specialized to more generalized users, ease of use becomes a critical issue. A word processor using WordStar can be expected to know that Control-K-B marks the beginning of a block of text, but a senior vice president writing an email to his staff should not have to remember such archaic keystroke combinations. A programmer can be expected to know COBOL syntax, but the CFO should not need to know how to write Lotus 1-2-3 macros to lay out his budget. In the same way, custom applications written in-house must also conform to these same levels of standardization and ease of use. The delivery of ease of use still has a long way to go. The Windows and Mac GUI interfaces make using the computer much simpler, and the Web browser with its hyperlinks is easier still, but even when business applications conform to these platform standards, the user interfaces can still be confusing. Also, many business applications have roots in earlier technology and, although the platform changes, the user interfaces stay the same. Applications move from mainframe to PC terminal emulator with the same user interface wrapped around another confusing piece of software. GUI builders and RAD tools provide somewhat better user interfaces, but force the programmer to work within the confines of the framework.

373

374

Building Application Servers Intranet and multi-tiered computing does allow a more flexible framework, isolating the user interface from the application, but often the same RAD and GUI tools are used to create these user interfaces. Although the Web browser interface has helped simplify the way that computers are accessed, there is still a strong need for easier business application platforms. Too much time is spent providing user support for applications that do not make sense to the people who use them. No amount of computer literacy can address these frustrations, and many more advances need to be made in user interface design as well as the general architecture of the PC platform. Just as the automobile moved from hand throttles and manual transmissions to automatic transmissions and cruise control, the desktop computer still has a long way to go.

Business intelligence In the late 1980s knowledge engineering and expert systems were just gaining momentum when the Internet began shifting the way we look at computing. Now that the Internet is beginning to mature, businesses are going back to some of these earlier technologies to regain this shift from data processing to business intelligence. Data warehousing and online analytical processing are transforming large bases of historical data into strategic assets that let management and marketing know who their customers are and gain insight into their needs. At the same time, intelligent business applications can closely monitor production and inventory and take over functions that used to be handled by supervisors and managers. Supply chains can be optimized down to the hour of the day to ensure that stores like Wal-Mart not only keep stock on hand, but intimately understand their customer's purchasing habits and optimize sales and inventory costs (Darling and Semich 1996). Not only do the business applications handle information gathering, they manage the workflow and optimize costs, performing functions that were previously done by mid- to high-level managers. Building business intelligence systems takes different skills than those of building database applications and, as such, require new languages, tools and abilities. In addition to specialized software design skills, these applications require intimate knowledge of business processes. Finding people with these skill sets is difficult and expensive. These applications

The Next Generation of Business Applications

are large, complex, and require longer development cycles; they definitely cannot be built in "Internet time". Nevertheless, these applications will be the strategic weapons of the twenty-first century, and the companies who can learn to harness this form of business intelligence will become the next century's business leaders.

Communications Although most business applications have performed the same functions since the days of the punch card, there is one truly new application: communications. In the early punch card days, communication flowed into and around the computer. Paper documents were submitted that were punched onto cards, then after the programs were run, cases of paper were produced and distributed around the office. Communications supported early computing. With the introduction of networking, the roles reversed. Computers were now able to support communications. Documents could be created and sent to other desktops, and email quickly evolved to allow messages to be passed among employees. As the technology matured, email and bulletin boards merged into groupware applications that support company-wide communication and collaboration. At the same time that businesses began exploiting network communications, this technology began connecting government research sites and universities together into a global Internet infrastructure that, when released to the general public, allowed businesses to communicate data as easily as voice was carried over the telephone. On a parallel course, business applications began to use these communication tools to transmit information beyond business boundaries into their customer's and vendor's computers. Wide-area networks were used to consolidate production data and financial information. Just-in-time inventory and supply chain management coordinated work between companies and their customers, while electronic data exchange allowed information to be sent to suppliers and customers, shortening business cycles. By adding communications capabilities to business applications, business processes were streamlined and brought automation to a new level.

375

376

Building Application Servers

How much farther can we go? Each of these factors will continue to play a role in how business applications will be built in the future. Automation is fairly mature, but there is still a struggle to balance the human factor, determining which jobs are appropriate for people or machines. Ease of use has a long way to go, and new methods of human/computer interaction must still be developed. Business intelligence is just starting to be exploited, and there is a wealth of data that could be collected and analyzed. Communications is another area that has begun to mature but still has a long way to go. As the industry continues to study these issues, the way we build applications will change. The burden for more functionality will be complicated by the need for more useable software. Software will have to conform to ever tighter standards to provide interoperability throughout the business community. At the same time, new technologies and ideas will emerge that will drastically change the way we build software. The remaining topics in this chapter will look at some of the emerging ideas that are already beginning to shape business applications.

Emerging Component Standards One of the current difficulties of multi-tiered application development is that software is far too difficult. Too much time must be spent to build the framework and infrastructure. Fine-grained objects work well, but the same code is constantly repeated for every object and there is no way to force consistency between them. Even with the support of current middleware, too much work revolves around creating objects and registering them into directory or naming services. The application server itself must begin by instantiating and registering class factories and persistent object servers, each which then create and manage more remote objects. The client applications also must constantly stop and locate objects and interfaces from the naming services. All of this takes too much programming effort and the developers lose focus of the business tasks as they get bogged down in object construction, middleware and architectural requirements. A number of new component standards are beginning to emerge that address this task and try to simplify the process of building business

The Next Generation of Business Applications

applications. Just as Visual Basic and other RAD tools provide an infrastructure where GUI components can be placed and connected together, these new component architectures provide standardized frameworks for server-side components. Ideally, a programmer can create a component that encapsulates business logic and place it into this framework; then, when a user interface programmer needs to call the service, he or she can simply drag and drop the functionality into the program. Now the framework has the responsibility to locate the component, load it into memory, expose its methods, marshal data, and route requests. To see where these component technologies are going, we will examine several of the emerging standards: Microsoft's Distributed interNet Architecture (DNA), Enterprise JavaBeans and CORBA. In addition to these standards, other vendors are also beginning to jump on the component bandwagon, adding component frameworks to their products and marketing them as "Application Servers." These products and standards will all strongly impact the way that we create new business applications.

Microsoft's Distributed Internet Architecture Microsoft's DNA framework is the oldest and most stable of the component standards and provides some good insights into the future of component development. Although the technology is proprietary and is only supported within the Windows environment, it does offer a comprehensive set of tools for delivering multi-tiered applications across desktop, intranet or Internet platforms. The architecture offers a strong component model, infrastructure for distributed programming, transaction and messaging support, and a broad range of development tools, all tightly integrated into an industry-standard operating system. The architecture is based on a component model that is slowly evolving. The original specification required that much of the functionality be implemented within each component, requiring a large, bulky object model that was difficult to program. The need to move components across the Internet led to the ActiveX specification, which began to streamline the component model and removed some of these restrictions. As the standard continues to evolve into COM+, the object model is slowly moving functionality from within the component back into the operating system where it belongs.

377

378

Building Application Servers The architecture provides a strong application framework that is relatively easy to learn and use. The Microsoft Application Services (which integrates their Internet Information Server, Transaction Server and Message Queue products) provides a centralized operating environment and repository where server-side components can live and work (Microsoft Corp. 1999). Component objects are registered in the AppCenter using a simple GUI interface; then a client program requests services as if the object were on the local machine. The server framework locates the component object, loads it into memory, starts a remote instance, and routes service requests back and forth between COM+ object and the client program. Each component does require some additional functionality to fit within the Application Services environment, but there is no need to code servers and class factories; the infrastructure is already in place. One of the strongest features of Microsoft's architecture is the wide variety of development tools. Although the component model is difficult and complex, the tools generate the basic component structures and interface definition files and then automatically manage these structures as additional interfaces and services are added. The broad range of tools is also a strong asset, providing relatively easy-to-use languages like Visual Basic for rapid development of server components and user interfaces as well as Web pages (with Visual Interdev and VBScript). When more technical, under-the-hood programming is needed, Visual C++ and ATL are available for low-level programming. The integrated tool set allows developers to work from a common platform to build and test an entire multi-tiered application within the Visual Studio package. As with all of the component standards, the Microsoft architecture still has a long way to go to simplify the component model and make development easier, but it does offer a good start. The common Visual Basic programming language and the integration of the development environment with the component technology does make software development easier. The operating environment and the application services framework also simplifies deployment and speeds up the development cycle. As other component standards continue to evolve, Microsoft's DNA tool set will be the standard others must beat.

The Next Generation of Business Applications

Enterprise javaBeans One of the contenders that is likely to meet Microsoft's challenge is Sun's Enterprise JavaBeans, or EJB (Kara 1999). Although this standard is restricted to the Java programming language, components can be deployed on a broad range of hardware platforms using any number of different industry-standard EJB application frameworks. While the DNA platform continues to evolve according to Microsoft's enterprise vision, the EJB standard will evolve through vendor competition as each platform competes for market share. Over time, this competition should produce a stronger standard as well as simplify software development. The component model is loosely based on the GUI JavaBean standard, which relied on the Java programming language to expose methods and properties to other JavaBeans, applets, or programs. The Enterprise JavaBean standard extends these features with multiple interfaces and a standardized server-side framework that acts as a repository and operating environment for the components. This framework provides directory, life cycle, persistence, transactions, and a host of other services. Enterprise JavaBeans are created as either session or entity Beans. A session bean is similar to a service interface, encapsulating the business logic that implements the service, coordinating the activities of entity beans. Entity beans correspond to business objects, encapsulating the data and activities of a specific business entity. Entity beans can either provide their own persistence mechanisms, such as storing and retrieving their data from a relational database, or can rely on the operating environment's persistence service to automatically store and retrieve state information. Since the EJB standard is far less mature than Microsoft's component standard, tool support and development frameworks are still evolving. As time goes on, development tools will improve. The EJB model offers an easy transition from two-tiered to three-tiered RAD development, so expect tools like Inprise's Borland JBuilder and Symantec's Visual Cafe to begin to automate much of the EJB creation cycle. Session beans can be derived from the user interface layout, and entity beans can be derived from database structures. Once these components are automatically generated, it will be relatively easy for programmers to add methods and properties to enhance these components with additional business logic.

379

380

Building Application Servers Also, with a standardized operating environment, the feature set will be standardized, so competition will have to be based on performance and ease of use.

CORBA object monitors If CORBA is going to continue to compete in the enterprise architecture arena, it will also have to address factors such as standard operating environments, ease of development, and tool support. With strong multi-platform and multi-language support, CORBA has wide potential; but these same benefits also make it more difficult to work with. IDL is another language that must be learned, and the programmer must manually keep the interface definition consistent with component implementations. Without a standardized application framework, there is little portability for standardized components. Nevertheless, the CORBA component model is standardized, mature, and well defined. Life cycle, directory, transactions, and other necessary services are already in place, and standards for repositories and persistence continue to evolve. In addition to these factors, many vendors are beginning to support the CORBA standard with frameworks and tools that simplify development and begin to fill out the infrastructure needed to construct an industrial-strength application. Vendors like IBM, BEA, IONA, Inprise and others (Boucher and Katz 1999) now offer frameworks and tools that simplify CORBA development. But compared to the Microsoft and Enterprise JavaBean standards, these CORBA tools are still difficult to use and force the programmers to do too much of the work that could be automated. Each vendor provides their own proprietary framework, and setup and administration are far too difficult. CORBA will always have a place in high-end distributed computing environments like telecommunications, but without a standardized framework and better tools, CORBA cannot compete with these other standards.

Other contenders Although this book only looks at multi-tiered client/server development, there are many other effective ways to build business applications. The

The Next Generation of Business Applications

concerns over Y2K compliance show that there are many mainframe applications, written over many years, that still perform their jobs well. Two-tiered client/server is a viable option for less processing-intensive applications, and most Web applications rely on CGI and HTML for the majority of their functionality. The rate of change and cost of development often limit the scope and breadth of software projects, and simpler solutions are needed to address these limited resources. As time goes on, these small, short-term projects could easily become the legacy code of the future. RAD tools quickly generate applications, but maintenance is often a nightmare, and short-term projects often lead to "stove-pipe" applications which have no external communication or integration capabilities. As the number of these quick-and-dirty applications multiply, the information capabilities of the organization begin to fragment and obtaining useful information becomes more difficult. With no long-term strategy, these projects cannot support the long-term needs of the organization. But if an organization starts with a consistent information technology strategy, a variety of development solutions can be used to create a solid information architecture. Twotiered client/server is an effective solution for applications that need little business logic, and RAD tools do provide quick, cost-effective user interfaces. Both of these technologies have matured and vendors are working to meet the needs of performance and maintainability. RAD tool vendors continue to simplify software development, yet offer better control of the code under the hood. Client/server databases also are continuing to mature, adding greater scaleability and programmability. Vendors like Oracle are adopting Java as a language to extend the database platform out to the enterprise, increasing the power of stored procedures and enhancing the database with strong, programmable server-side functionality. Internet vendors are also approaching enterprise application building starting with the Web server, augmenting their products with back-end databases and development tools. These emerging product lines will also shape the future of business application development. Mainframes also have their place in enterprise computing. Businesses have invested many years of resources to build their core mission-critical applications. These applications often do their jobs effectively and, with the added investment of Y2K compliance, there is little reason to

381

382

Building Application Servers replace them. Certain business tasks require huge volumes of data and consume large amounts of processing time. Tasks like processing federal tax returns and monthly billings for utilities and power companies work best using the mainframe processing model. Finally, there are other development models that we have not yet even imagined. Just as the software developers of the mid-1980s could not imagine the impact of the Internet, we cannot possibly imagine the changes that will occur in computing hardware and software design tools. Will we even talk about programming languages, or will we simply describe business problems and interact with software design wizards that shape the software from an interactive conversation? Will some vendor build intelligent wizards that encapsulate the design practices and programming skills of the best programmers today and automate the whole process? Will we even need to know whether data is stored in relational form or in object-oriented databases? Will it matter what programming model or language is chosen? Will we even need to write program code or design specs? Unfortunately, the ultimate application wizard does not exist, and we still have to design and build software—or do we? As the cost of application development continues to rise, the build vs. buy decision becomes an important decision. Why pay for the entire development effort when either part or all of the functionality can be purchased?

The Application Software Marketplace From the time businesses first began using computers, they have tried to find ways to recoup the cost of software development. "Since the software is doing such a good job for our business, we should be able to sell it and recover our development costs." In most cases, this effort has failed, adding even more to the cost of software development, but some of these ventures have been extremely successful and have formed the foundation of the vertical market software business. Today vertical market software is itself a mature industry. Companies like SAP and PeopleSoft are almost as well known as Microsoft. Basic accounting software like QuickBooks and Peachtree Accounting can be purchased in any office supply store, and more specialized software can easily be located on the Internet. As the cost of software development

The Next Generation of Business Applications

continues to rise, it becomes almost impossible to justify the cost of developing core mission-critical business applications totally in-house. Requirements analysis, design, prototyping, and revisions take far too long, and by the time the application deploys, the business requirements have changed. Finding and keeping good technical people can be difficult, while finding good technical people with the right industry experience is almost impossible. Commercial vertical market software solves many of these problems. Buying a commercial package can jumpstart a development project by providing a large percentage of the core functionality. The basic infrastructure, user interfaces, databases, and business logic are already written, moving the project ahead by many man-years. Since the vendors often provide customization services, the software can be tailored to the business environment, and far less in-house development is needed to put the new system online.

Off the shelf applications The past few years has seen the success of large enterprise-wide commercial applications. Companies like SAP and PeopleSoft have introduced major Enterprise Resource Planning (ERP) packages that encompass a large portion of an organization's information needs. Often, the costs of implementation and customization of these packages can exceed the purchase price, but the level of functionality provided as well as the amount of support that can be offered by these vendors far outweighs the years of work to build a home-grown system. The key to these products' success is that they provide a comprehensive infrastructure that can be plugged into an organization. The years of architectural planning, systems analysis, software design, and programming that would be required have already been done by someone else. Better yet, the cost of this work is shared across the product's customer base, offering lower cost for more work as well as a wealth of industry knowledge that would otherwise take years of research. At the same time, these packages have a long way to go. Implementation costs can run into the millions as software developers and consultants fight to fit these packages into an existing business framework. Integrating these packages with existing systems can often be

383

384

Building Application Servers a nightmare and vendor promises always exceed what can be delivered, so schedules and budgets go out of control as critical features are retrofitted into the products. Also, the products are usually based on someone else's vision of how a company does business, so fitting the product to the business model can be difficult. Nevertheless, packaged business software is often a viable option, and the breadth of products and solutions will continue to grow as these companies continue to be successful.

The component marketplace As component standards mature, the market for prebuilt business components has the potential to solve some of the problems of packaged software. The popularity of Visual Basic and other component platforms has grown a thriving market in prebuilt GUI components. In the same way, a stable, standardized server-side component model could open the market for commercial server-side components. Instead of retrofitting a software package to fit business requirements, developers could choose components that encapsulate core business functions like payroll, general ledger, or invoices, then build services that coordinate the interaction between these objects. Before this can happen, the component framework standards must stabilize and vendor implementations have to mature. Standards for component specifications, repositories, and quality assurance have not yet been established. Since core business functionality will be encapsulated into these component black boxes, the interfaces must be well documented and developers have to know that they can rely on these components to do exactly what the specifications say. When an account goes out of balance or an inventory item is priced incorrectly, the developer has no way to go into the component to fix the problem. The component only provides an interface definition that tells him how the data goes in and comes out, not how the functions are implemented. Unless the component works exactly as documented, software that relies on these components will fail. At this point we cannot tell whether server-side components will succeed or fail. The technology has not yet matured. Can large-grained components meet the needs of complex business requirements, or does it make more sense to buy an entire application? Can these components

The Next Generation of Business Applications

anticipate all of the business needs or will they be as restrictive and as difficult to integrate as some of today's RAD-based business applications? Does it make more sense to buy fully functioning applications and integrate them at that level? At this point we do not know. For that matter, we do not know if server-side components themselves will work, since we have no way of knowing how well application developers can adapt to such strict component-based development standards. Only time will tell.

The open source bazaar One final factor that has yet to be played out is the role of the open source initiative as it applies towards business software development. In a widely distributed Internet document called "The Cathedral and the Bazaar" (Raymond n.d.), Eric Raymond chronicles the development process surrounding the Linux operating system. This amazing software package began as a university project by Linus Torvalds to study the multi-tasking abilities of the Intel 386 real-mode architecture. Over time it became a comprehensive public-domain Unix-clone operating system. To illustrate how this operating system has evolved, I recently installed Windows NT Small Business Server (SBS) for a start-up company. About the same time I decided to purchase the Red Had Linux distribution (version 5.2) to test the Java code for this book on an alternate OS platform. My client paid over $2,200 for the SBS package, limited to five client licenses, while Linux cost around $30 with no user restrictions. Both packages provide an operating system, networking, printer and file sharing, relational database, Internet connectivity, and Web servers. In addition, Linux offers a complete suite of development tools as well as the source code for every piece of software included in the distribution. Rumor has it that corporate network administrators are quietly replacing Windows NT with Linux in file and print sharing applications, and the only comments from their bosses is, "Why is the server running so much faster?" What makes Linux and its open source model so effective is the shift in development model from the rush to market to a deliberate, peerreviewed, almost academic approach. In the beginning, the Linux operating system began as a research project, but as it began to be used by students and enthusiasts all over the world, they filled in holes to meet

385

386

Building Application Servers their own needs. Each change was passed back to a peer review committee responsible for code review and testing. Other successful open source projects include the Apache Web server, PostGress database and SendMail. When Netscape decided they could not compete with Microsoft's Web browser, they passed their browser development to the open source community. In addition to developing quality software, companies like Red Hat and Caldera have found ways to turn open source into successful businesses. The question remains, could the open source model be applied to commercial software development? To date most open source work has been geared towards operating system and utility software that has a wide base of use as well as developers who need the functionality enough to contribute programming time. It is questionable whether business applications could gain this same level of cooperation or support. Even in commercial development, customers are often unwilling to allow their products to be sold to local competitors. Such open, shared development with competitors would be difficult to sell to management. But there are places where open source will have an impact. Already through Linux we can see how peer review can enhance software quality. Open source also offers a breeding ground for new technology and approaches to software development. Sendmail and Apache both improved the way we use the Internet, enhancing email and Web server technology, while the OMG actively uses open source to develop and promote middleware standards. OMG recently announced the Open JORBUX initiative Qava, CORBA, Linux) to promote open source standards in distributed computing (Harmon 1999). As a low-cost alternative to more expensive commercial offerings, it should also lower commercial software costs. It is yet to be seen if the open source initiative has the staying power to compete with the likes of Microsoft. Linux and open source are getting a lot of press and are gaining acceptance, while many new businesses are looking at open source as a way to gain a foothold in the marketplace. Many of the big-name software vendors like Oracle and Sybase are beginning to see Linux as a viable platform, and we have yet to see how Netscape will exploit their open source browser. Open source will shape the future of software development, but we have yet to see what impact it will have.

The Next Generation of Business Applications

The Emerging Business Platform In addition to changes in software development, the hardware itself has changed drastically since the days of punch cards. Today the standard is a desktop-based computer (or a notebook that scales the desktop down to portable form) connected to one or more networks. As new devices, such as palmtops, tablets (same technology as palm-tops only larger), cellular phones and pagers all gain added computing power, this standard will adapt and change. Non-information devices such as automobiles, televisions, cameras, and even household appliances are also gaining microprocessor technology. As computer intelligence moves off the desktop, the shape of business applications will change and, over time, this may be the most significant trend of all. As we try to envision the computer platform of the 21st century, we can already begin to see some trends illustrating how the computer will move off the desktop and into our everyday lives. These include: • Cheap computers • Palm-tops and cell phones • Pervasive computing

Cheap computers As we all know, the cost of computers are constantly dropping. Internetready computers with multimedia capabilities can be bought for under $500 and Internet service providers offer free computers in exchange for service contracts. Although the high-end full featured computers still cost more, these cheap computers are not toys—they have the same level of power and features that the top of the line computers had a few years ago. Many homes now have more than one computer, and home networks allow these computers to share resources as well as simultaneously share Internet connections. With these cheap computers comes the ability for businesses to reach into every home, providing products and services without having to lease retail space. Books can be ordered from Amazon.com at any time of the day or night, day traders buy and sell securities at frantic paces from their own homes, students can get advanced degrees without leav-

387

388

Building Application Servers ing their homes, and dinner can be ordered with a few clicks of a mouse. The demands of this real-time, anytime, anywhere customer service drastically changes the way software is designed and deployed. User interfaces must be simple, consistent and meet evolving standards. Customers expect Web pages to respond in certain ways, but industry leaders are constantly improving their interfaces and your company has to quickly deploy these same features or your customers will go to those who do. The companies that succeed in internet commerce know how to make Internet shopping easy and intuitive. An awkward user interface will quickly drive customers away. As computer vendors continue to find ways to deliver more computer power at even better prices, commerce will continue to shift from retail directly into the home. There will always be a need for traditional retail shopping, but the shift is already under way. With prices dropping, only the most disadvantaged will not be able to afford computer technology, and politicians and community leaders are already working on ways to solve this problem too.

Palm-tops and cell phones Just as Internet technology is moving into the homes, it is also moving into pockets and purses. Cellular phones are gaining popularity even faster than home computers and devices like the Palm Pilot and other PDA's and personal devices are quickly becoming critical business tools. As these products merge together and gain additional features, they may easily become the next major business application platform. These devices have the advantage of small size, portability and, with the latest models, wireless connectivity. You can use them to track appointments, jot down notes, track phone calls, send and receive email as well as any number of other information management chores. There are also software development tools that allow programmers to create custom applications and, as these devices become more prevalent, could be used to host business applications. At the present, many companies use custom hand-held devices as business tools. UPS has their electronic delivery pad that can accept customer signatures. Hand-held inventory terminals are common in grocery stores. As the palm-top devices become more common and inex-

The Next Generation of Business Applications

pensive, these could also be used to host similar applications. Sales-call tracking, now hosted on notebooks, could easily be ported to palm-top devices. As these devices grow in popularity, other business applications will also find their way onto these devices. Dwight Deugo, editor of Java Report, observes that the current limitations of these palm-top devices offers some new insights into software design. With their limited resources, developers can only implement those features absolutely necessary to the application (Deugo 1999). There is no room for "feature creep" that we see in current desktop applications. Also, being memory resident, applications open quickly and appear the same as they did when the device was turned off. There are no splash screens or wait time and no need to remember file names or perform sequences of commands to bring in data. As such, the devices act more as appliances than as complex computer devices.

Pervasive computing A final hardware trend that is beginning to appear is the addition of intelligence and communications capabilities into everyday products from cars to appliances. This trend has been given the name "pervasive computing." Newsweek displayed a wide range of products from microwaves with Web browser-enabled front panels to refrigerators with PDA's built into the door (Levey 1999). In recent consumer experiments, shopping carts have been equipped with bar code scanners to eliminate check-out lines and McDonalds has installed ATM-like kiosks in playground areas so mothers can place their orders without leaving their kids. In the not too distant future, your car could schedule its own 30,000-mile tune-up by interrogating your PDA to find a number of available times, then it would call up the dealer's service department to schedule an appointment and post it to your PDA. As the Internet, phones and computers all merge into everyday consumer products, the face of business computing drastically changes. Not only do we have the possibility of bringing the store into the home; we now have the possibility of the products in our house or office performing commerce on their own. Instead of the milkman delivering the same order every morning, the refrigerator could place the order itself. Now if only my house could clean itself.

389

390

Building Application Servers

Where is it all going? I realize that this has taken off into some strange directions, but all of these possibilities will shape the way that we build enterprise software. I personally don't want my appliances spending my money or my car upsetting my afternoon nap, but these same capabilities will alter the way we do business. Just in time inventory already orders and schedules raw materials, so how soon will it be before the factory machinery begins to order its own supplies? In the same way, software development will continue to change. The level of complexity will continue to grow, but the tools will continue to adapt to allow programmers to handle this complexity. Ten years ago few people saw the future impact of the Internet. Where will business computing be 10 years from now? As we form new enterprise architectures, we don't know what the next Internet will be or how it will fit into our current business model. We may not know what it is, but we should assume that it is coming and structure our applications in an open, expandable manner. Multi-tiered application development is one approach that allows easy integration of new user interfaces and hardware platforms, eases the ability to adapt to changing business processes, and allows open integration of other technologies in a relatively seamless manner. Sure the costs are higher and the development time is longer, but once in place, the architecture will accommodate almost any new technology. Your business will be able to quickly take advantage of these new opportunities.

Final Thoughts I hope that this book will give you a better understanding of application server technology and how to use it to build core mission-critical business applications. In this book I've tried to move beyond the hype and technobabble that surrounds middleware and offer a simple, practical framework that will work with any distributed architecture. By spreading the service interface, business objects, and persistence services into separate layers, you can design and build the software in a much more logical, maintainable manner. This approach also creates a solid foundation for later development, providing reusable objects and a scalable, yet integrated application architecture.

The Next Generation of Business Applications

Good luck with your application server projects. I'd really be interested to hear how they are going. Comments and questions are always welcome. You can reach me through my Web page at http://pages.prodigy.net/rleander or through SIGS/Cambridge University Press.

391

392

Building Application Servers

References Boucher, Karen, and Fima Katz. Essential Guide to Object Monitors. New York: Wiley, 1999. Darling, Charles B., and J. William Semich. "Wal-Mart's IT secret: Extreme integration." Datamation, November 1996: 48. Deugo, Dwight. "Ideas." Java Report, September 1999: 6. Harmon, Paul. "An Open Platform for Components." Component Strategies, June 1999: 30-37. Kara, Dan. "The Enterprise JavaBean Component Model." Component Stategies, January 1999: 18-25. Levey, Steven. "The New Digital Galaxy." Newsweek, May 31, 1999. Lammers, Susan. Programmers at Work. Redmond, Washington: Microsoft Press, 1986. Microsoft Corp. "Microsoft Announces AppCenter Server" Available at http://www.microsoft.com/presspass/press/1999/Sept99/appcenterpr.htm Raymond, Eric. "The Cathedral and the Bazaar." n.d. Available from http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ Verdi, Christine. "Top Jobs for the Year 2000 and Beyond." Your Money, June/July 1999: 74.

Appendix

Setting up a Development Environment Setting up a development environment for distributed processing does not have to be complex or expensive. Much of the program code written for this book was developed on a single Pentium 200 MMX machine. Additional testing was done by networking it with a Pentium 133 running NT Server. This machine was built from spare parts, and I think that NT and SQL Server probably cost more than the computer. I also used the Java SDK, Borland's JBuilder, and Microsoft Access. This appendix will describe the two configurations, as well as how to use them to compile and run the program examples. The topics covered will include: • Development using a single computer • Development on a network • Compiling and testing Java and RMI • Setting up JDBC

393

394

Building Application Servers

Development Using a Single Computer Experimenting and testing Java, RMI, and JDBC only requires a single computer. Windows 95 and 98 do a good job of multi-tasking, so there is no reason to go through the trial or expense of networking a second computer. Working on a single computer also saves wear and tear on the chairs and carpet moving back and forth between computers. Figure A-l shows the processes that must be running to make RMI work on a single computer. Before the application server and the applet can communicate, you must have the RMI registry running on top of an Internet server. For you to use JDBC, you must also have the appropriate drivers and database server running. All of these processes take quite a bit of memory, so the more memory in the machine, the better.

Applet Program

Server Program

Applet Viewer

Java Runtime Environment

RMI Registry

Web Server

Figure A-l. Single computer configuration

Appendix

Hardware requirements Any Pentium-class computer or better will work as long as there is adequate memory to handle all of the separate processes. I tried testing on a 486 machine, but it appeared that the Java runtime relies on some Pentium machine instructions. In any case, almost any low-end Pentium will work. The machines must be running Windows 95, 98, NT 4.0, or higher. As with any Windows development, the more memory, the better. I got the examples in the book to run with only 32MB, but I could see some swapping occurring, and run time got pretty slow. Since most Java IDEs now need around 96MB to run, the test machine should have at least that much memory. Disk space requirements for Java are relatively low. The Java SDK itself takes a little over 50MB for an adequate installation. Although a Java IDE is not needed, it does make compiling and debugging easier. If you choose an IDE such as JBuilder or Visual Cafe, plan on 150MB to 300MB plus additional space for project files. You'll need a CD-ROM (to install the software) and Internet capability, through either a modem or a network. Additional video resolution and other requirements may also be dictated by the IDE. Here's a quick rundown of the hardware requirements: Computer Memory Disk Space

Java SDK Pentium 64MB 100 MB

IDE Pentium II 128MB 500 MB

Software requirements The software needed to work with Java, RMI, and JDBC can be obtained from the Internet or from any number of sources. You can download the Java SDK from the sources listed at the end of this Appendix, or purchase it from any of the language vendors. I prefer JBuilder, but Symantec's Visual Cafe, IBM's VisualAge, and Sun's Java Workshop and SuperCede are also good products. At the time I am writing this, Sun is offering a multi-leveled subscription program called the Sun Developer Essentials. The lowest level of this service is a Java developer's subscription that supplies CD-ROMs four times a year containing all of the latest Java SDKs and API's as well as quite a bit of documentation at a very reasonable price. Single-copy CD-ROMs are also available.

395

396

Building Application Servers In addition to the Java Developer's Kit, you'll need a Web server to handle the RMI communication. The simplest way to implement this functionality is to sign on to your ISP, then minimize the Web browser. This allows the ISPs Internet server to handle the communication chores. I do not know if this will work with services like AOL, but it does work with a phone connection into a standard Internet service. If the ISP does not work, there are several demos of Web servers available from the Internet. These are also listed at the end of the appendix. To work with JDBC, you'll also need a database program. This can be a client/server database product like Sybase or Microsoft SQL Server, or it can be a stand-alone database like Microsoft Access, Paradox or dBase. Native JDBC drivers may be supplied with the server; otherwise, you can use the JDBC-ODBC bridge included in the Java SDK. If you use the bridge, you'll have to register the database with ODBC. This will be described later in this section.

Development on the Network Single-machine development works fine for learning the basic programming techniques, but does not work well when developing a commercial product. Even if you are the only developer, you need to work with the same network configuration and operating systems that your product will be supporting. Also, issues such as performance and scalability are much easier to determine when all of the pieces are distributed in their proper places. Although NT Server machines are usually configured with large amounts of memory and huge disk arrays, you can often build a development server around a standard desktop machine. The huge machines have to serve hundreds of users, while a development server only serves a few workstations. Also, a slower processor will emphasize performance bottlenecks. What may seem to be a short wait on a fast machine will seem like an eternity on a slow one. Making a slow machine run faster will make the target machine scream.

Network hardware Figure A-2 shows the configuration of a two-computer network that can be used to test the sample programs. The server is a standard Pentium

Appendix

desktop machine with lots of memory and disk space. The operating system is Windows NT 4.0 with at least 64MB RAM and 6GB of disk space. The network is 10MB Ethernet. These cards are cheap and many new desktop computers have these installed as standard equipment. The client workstation is similar to the single-machine workstation described above, running Windows 95 or 98 with sufficient RAM and disk space to handle the requirements listed above. Both the server and workstation will have to be configured for TCP/IP and assigned arbitrary IP addresses.

Software As with the single-computer configuration described above, RMI requires an Internet server to handle communications. Windows NT Server comes with the Microsoft Internet Information Server (IIS), and this is adequate for distributed Java testing. IIS is relatively easy to configure and run. Since the RMI registry manages communications, IIS simply sits in the background handling communication requests. Other than an Internet server, the remaining software is the same as that needed for the single workstation. The Java SDK must reside on

Workstation

Server Network

Windows 95 or 98 JDK

Figure A-2. Network configuration

Windows NT Internet Information Server Database Server JDK

397

398

Building Application Servers both machines so programs can run within the Java runtime environment. If you use JDBC, the database server and JDBC drivers must both reside on the server machine. I had hoped to also set up a Linux network configuration, but did not have the time to set it up. For those on limited budgets, Linux can either be downloaded from the Internet or purchased from almost any software supplier for a very reasonable cost. Most distributions provide the operating system, TCP/IP networking and the Apache Web server, but you may have to download the Java SDK and hunt for a JDBC-compatible database.

Compiling and Testing Java and RMI As illustrated in Figure A-l, several program layers must be running before RMI programs can communicate successfully. To make it easier to get started, I suggest that you start with the single-machine approach listed above; then, once the process is running, you can distribute the pieces onto the network environment. The procedure described in this section uses the Java SDK running from the command window (DOS window). Consult the manuals that accompany your compiler if you are using one of the Java IDEs such as JBuilder or Visual Cafe. To illustrate the compile and test cycle, the loan calculator example in Chapter 9 will be used. These are small, simple programs that should not be difficult to run. Use the following steps to get the program running: 1. Set up a project directory. 2. Compile the server and applet. 3. Use rmic to create the stub and skeleton classes. 4. Start the Web server and RMI Registry. 5. Start the application server. 6. Run the applet.

Step 1: set up a project directory Create a directory on the hard disk called Loan, then copy the source files from the sample code files. The source code can be obtained from

Appendix

the Cambridge Website as described in the introduction. Once unzipped, the files will be stored in directories by chapter. Within the Chapter 9 directory, there is a subdirectory called loan. This will contain the files: LoanCalc.java

NonRMI version of the applet (not needed for this example)

LoanCalcApplet.java Source code for the loan calculator applet LoanCalcServer.java Source code for the loan calculator server ILoanCalc.java

Source code for the interface definition

LoanCalcDef.Java

Source code for the interface implementation

LoanCalc.html

HTML code used to run the applet

Step 2: compile the server and applet Open the MS-DOS command window and switch to the loan directory (cd Moan). Assuming that the Java SDK was installed correctly (if you are using Java SDK 1.1.x, make sure you have set the CLASSPATH and PATH variables to the proper directories), use the following commands to compile the source files: javac ILoanCalc.java javac LoanCalcDef.java javac LoanCalcServer.java javac LoanCalcApplet.java Each command will create a new class file. Depending on the Java SDK version, you may get warnings stating that a deprecated API is used; this means that a class or method was used that has been replaced in the newer Java SDK version. The program should still work in spite of these warnings.

Step 3: use rmic to create the stub and skeleton classes Once the class files are compiled, you must run the LoanCalcDef class file through the rmic compiler to generate stub and skeleton classes. Enter

399

400

Building Application Servers the following command to create these files, rmic LoanCalcDef This will create two new class files, LoanCalcDef_Stub. class and LoanCalcDef_Skel.class. These classes are used by the applet and server to handle communications between the two programs.

Step 4: start the Web server and RMI registry Minimize the command window (Alt-Esc or press the Window key) and connect to the Internet or start your Web server. Once this is running, reopen the command window and type the following command: start rmiregistry This will open a new command window running the RMI registry program. If the program is running correctly, the new window will stay blank. If an error occurs, messages will quickly appear and then the window will close. To see the errors, go back to the original command window and type: rmiregistry This will display the errors. Most likely, either the rmiregistry program cannot be located or the Web server is not accessible. If the program cannot be located, make sure that the bin directory has been added to your DOS path variable and that the program is in the bin directory. If the Web browser is not accessible, check the connection or consult the Web server documentation. Once it appears that it is running correctly, minimize it and go back to the original command window.

Step 5: start the application server Next, start the LoanCalcServer from within the Java runtime environment using the following command: start Java LoanCalcServer This will open a new command window for the server program. Again, any errors that occur will quickly appear before the window clos-

Appendix

es. Use the same procedure as with the rmiregistry program to see the error message. The most probable problem will be that the skeleton file is not accessible from the RMI Registry. Make sure that the Registry program is running from the same directory as the server and this should solve this problem. Once running, minimize this new command window then reopen your first command window..

Step 6: run the applet Once the Web server, RMI Registry and application server programs are running, the applet can be started. Enter the following command from the command window to start the applet: Appletviewer LoanCalc.html If this is the first time that you have run an applet, you will get a welcome screen listing some legalese along with an Accept button at the bottom of the screen. Depending on the screen resolution, this may not be visible. Use the mouse to pull the window up as high as possible, then click the Accept button. Once this is out of the way, the applet will begin to appear on the screen. There may be a brief wait before the applet starts. Once it's displayed, enter numbers in the Loan amount, interest and time fields, then click the calculate button to see the applet work.

Running on a network The same procedure applies to the network configuration. The applet program (LoanCalcApplet.java) will have to be modified to point to the IP address of the server computer. Remove the comment markers (//) from line 38 and change the IP address from 101.101.1.1 to the IP address of your server, then recompile the applet program. Once the programs are compiled, the server-side programs, as well as the skeleton class, are moved to the server. The RMI Registry and the application server are then started on the server machine. Once these are running, the applet can be run from the client machine.

401

402

Building Application Servers

Where to get help If the sequence above does not work, first check to make sure that the Java SDK is installed correctly and that the DOS path and classpath variables point to the correct locations. On my test machine, I have the Java SDK version 1.1.7 loaded in the c:\java directory (I hate typing all the version numbers). The path variables are set in the autoexec.bat file as follows: PATH C:\JAVA\BIN;... rem (plus additional paths) SET CLASSPATH=c:\java\lib\classes.zip;c:\java\lib;. Make sure that the period is included at the end of the classpath list. This indicates that the current directory (your compiled class files) will be searched along with the standard Java SDK classes. Forgetting to include this may cause errors stating that your classes cannot be found. For the proper settings, consult the readme file that accompanies your SDK version. Any other compile errors may indicate version incompatibilities or other SDK problems. For runtime errors or RMI problems, check the FAQ and support files on Sun's Website. These will often point you in the right direction. I have personally compiled and run all of the program examples using both the Java SDK 1.1.7 and 1.2 versions. If you run into difficulties, check my Web page (still under construction—the URL will be included with the source files) for suggestions or program corrections. I may not be able to respond to each inquiry individually, but I will post common problems on the Web page.

Setting up JDBC JDBC is primarily dependent on the driver that you use. If you are using a vendor-specific driver, check their documentation. The examples in the book use the JDBC-ODBC bridge included with the Java SDK, so this is what will be described here. Begin by locating the driver file (jdbcodbc.dll), then copy it into the Windows directory (or any other directory in the search path). This DLL file interfaces between the Java JDBC classes and the Windows ODBC drivers. You will also need to have the ODBC drivers and registry program installed. These drivers are included with the database programs, software develop-

Appendix

ment tools, and office suites, or they can be purchased independently. Once the drivers are loaded, the database must be registered into the ODBC administration program. The database used with the examples is a Microsoft Access database called OrderEntry.mdb. Start the ODBC administrator from the control panel and add this database using the name OrderEntry as a Microsoft Access database, pointing to the OrderEntry.mdb file. Any options or check boxes should be kept at their current setting. This should be all you need to get JDBC working. If problems occur, make sure that the JDBC drivers can be found in the current classpath and that the jdbcodbc.dll is located in a directory that is accessible from the search path. For other problems, check the JDBC FAQ on Sun's Website.

Summary Good luck and have fun with Java, RMI and JDBC. Setting up the development environment can be frustrating and requires a lot of patience. I hope that the tips listed in this section will make the chore a little easier.

Sources for Software Java SDK Sun's Java home page: http://java.sun.com/ SDK Download page: http://java.sun.com/products/OV_jdkProduct.html Java-Linux ports: http://www.blackdown.org/java-linux/ports.html

IDEs Borland JBuilder: http://www.borland.com/jbuilder/ IBM VisualAge for Java: http://www.ibm.com/developer/java/ Sybase PowerJ: http://www.powersoft.com/products/powerj/

403

404

Building Application Servers Symantec Visual Cafe: http://www.symantec.com/domain/cafe/index.htm

Web Servers Apache Web Server: http://www.apache.org/ BEA WebLogic Server: http://weblogic.beasys.com/ Netscape: http://home.netscape.eom/enterprise/v3.6/index.html Microsoft Internet Information Server: http://www.microsoft.com/ NTServer/web/exec/feature/Datasheet.asp Sun Java Web Server: http://www.sun.com/software/jwebserver/index.html

Database Servers dBase: http://www.dbase2000.com/ Microsoft Access: http://www.microsoft.com/office/access/default.asp Microsoft SQL Server: http://www.microsoft.com/sql/default2.htm

Index

access control, 184 account-based security, 327 ActiveX specification, 120, 377 actors, 95-98 in service interfaces, 71 aggregation (object relation), 107-109 in class diagrams, 56 Ambler, Scott, 251, 327 applets, 199 application (service) interface layer, 16, 29-30 application databases, 168-170 application errors, 86-87 application integration, 158-159 application mining, 159-160 applications designing for integration of, 158-159 existing, integrating into software design, 51 external, represented by objects, 154 future of, 382-386 in Java, 199 services specific to, 78-79 workflow tracking applications, 12-13 applications development, 372-373 application servers, 6-7, 38 alternative architectures for, 34-37 architecture of, 16-17 for business rule processing, 8-9 commercial, 27-28 costs and disadvantages of, 9 designing, 43-45 design of business objects and, 116 for distributed processing, 7-8 framework for, 178-183 implementing security and authoriza-

tion strategies in, 326-329 long-term commitment required for, 10 middleware in architecture of, 18-19, 28-29 multiprocessing within, 337-340 multi-threading and, 346 in n-tiered client/servers, 4 partitioning of, 149-150 application service interface objects, 121-122 architecture of application servers, 16-17 of application servers, alternative, 34-37 of business objects, 125 Distributed interNet Architecture (DNA), 377-378 distributed Java versus other middleware, 219-222 of Java Virtual Machine (JVM), 198-201 of JDBC Qava Database Connectivity), 228-230 middleware in, 18-19, 28-29 moving from traditional client/servers to n-tiered client/servers, 12-13 of n-tiered client/servers, 4 for remote procedures, 22-23 ASCII data files, 168 association (object relation), 112-113 in class diagrams, 55 in Java, 203-204 asynchronous communications, 294-295 ATMs (automated teller machines), 26 attributes (properties; instance variables), 101-102, 207 authorization strategies, 326-329 automation, 372-373, 376

405

406

Building Application Servers B Bassett, Paul, 117-118 BeanBox (Java framework), 200 Bea Systems, Inc., 26, 182 Booch, Grady, 52, 62, 94 Borland Delphi, 4 bugs debuggers for, 191 tracking and reporting of, 192 business object layer, 16, 328 hidden by services, 81-82 business objects, 16-17, 30-33 architecture of, 125 business rules in, 320 complex, 255-258, 260-261 creating new, 122-123 definition of, 94-95 design of, 45, 91-92, 101-105 distributing, 262-263 handling of, 81-82 joining with relational databases, 240-245 linking to service interfaces, 120-121 locating, 95-98 in modeling business processes, 46 multiprocessing and, 338-339 multi-threading and, 347 naming and defining, 98-100 reuse of, 46-47 specifications for, 105 tracking, 245-248 transition from data models to, 92-93 See also objects business processes, modeling, 46 business rule processing, 6, 8-9 business rules, 297-299 classification in, 313-316 coding, 299-306, 317-321 commercial business rule engines, 325-326 in data, 306-313 maintaining rule and classification tables, 316-317 security and authorization strategies in, 326-329

structure-based, 300-301 byte-code Uava), 199 Carey, Bryce, 11 CASE, See computer-aided software engineering cell phones, 388-389 CICS (transaction processing monitor), 26 class diagrams, 53-58, 115 classes in Java, 201-206 names for, 206-207 objects versus, 95 class factory model, 289, 340-346 class factory objects, 342-345 class files, 199 classifications, 313-316 classification tables, 314-317 client/server communications, 270-274 client/server developers, 4 client/server software, 16 Coad, Peter, 94 COBOL, 157, 164 Codd, E.F., 132 coding business rules, 299-306, 317-321 in Java, 206-207 See also programming collections (object relations), 114-115 COM (Component Object Model; Microsoft), 10, 19, 23-25 comments, in UML diagrams, 59 commercial application servers, 27-28 commercial business rule engines, 325-326 commercial frameworks for application servers, 182 commercial transaction monitors, 366-367 commit method, 363-364 Common Object Request Broker Architecture (CORBA), See CORBA communications, 375 asynchronous, 294-295

Index client/server, 270-27'4 between computers, middleware for, 18 between designers and programmers, 47 in development of application server framework, 186-187 among objects, 107 between persistent objects and databases, 33 between user interface and service interface, 29-30 compatibility, 153 compilers, 190 complex business objects, 260-261 complex objects, 255-258 passing, 288 C0M+ (Component Object Model; Microsoft), 19, 222, 377 component models, 25 Component Object Model (COM; Microsoft), 10, 19, 23-25 components, of applications, 384-385 composition in class diagrams, 56 in Java, 203 computer-aided software engineering (CASE), 43, 52, 188-189 computer crashes, 87 computers cheap, 387-388 middleware for communications between, 18 palm-top computers, 388-389 concurrency, 119, 263-266 of application server frameworks, 184 multiprocessing and, 339 concurrency services, 20 consultants, 193 CORBA (Common Object Request Broker Architecture), 19, 23, 28, 163 distributed objects in, 219-221 object monitors in, 380 objects passed by, 286 transaction service in, 366-367 costs of application servers, 9 C++ database wizards in, 137

Java based on, 197-198 C++ Builder, 4 cross-platform integration, 9 Crystal Reports, 5 culture, organizational, 118-119 customer data objects, 82 customer objects, 248-250 D data field validations of, 302-304 interdependencies of, 304-306 multiple, synchronized, 336 multiple sources of, 336 in objects, 93 primitives, 286 relational model of, 132, 133 rules in, 306-313 service interfaces to locate, 282-284 stored in relational databases, 130 storing, 284-285 synchronizing objects and, 353-360 Data Access Objects (DAO; Microsoft), 21, 136 databases accessing, 168-170 business rule processing for, 6 capacity planning for, 259 deleting objects from, 264 distributed processing of, 7-8 JDBC (Java Database Connectivity) for, 200, 233-237 locking, 354-355 minimizing connections in, 259-262 multiple servers for, 262 object-oriented databases, 152-153 object versus relational, 33 optimizing throughput in, 266 other middleware for, 238 persistence layer for, 32-33 persistent objects communicating with, 227-228 remote database protocols for, 21 Structured Query Language (SQL) for, 230-233 See also relational databases

407

408

Building Application Servers database servers, 321 deadlocks in, 358-359 multiprocessing and, 339-340 security implemented in, 328 data-centric application servers, 34-35 data integrity, 184 data models, 92-93 data retrieval operations, 76-77 Date, C.J., 145 deadlocks, in locking, 358-360 debuggers, 191 delete statement (SQL), 233 deleting objects, 140 design for application integration, 158-159 of application servers, 43-44 of business objects, 45, 91-92,101-105 constraints on, 49 integrating existing applications into, 51 iterative development in, 47 joint application design, 44-45 layered, 49-50 to meet needs of end users, 61-62 middleware in, 50 modeling business processes in, 46 of objects, 93-94 of persistent object layer, 137-152 programming combined with, 48 reuse of objects in, 46-47 self-directed technical review in, 48-49 of service interfaces, 66-76 of services, 76-84 standards for, 47 Unified Modeling Language (UML) used in, 51-61 design patterns, 94 destroy method, 285 Deugo, Dwight, 389 development cycles, 116 development environments, 187 diagrams (UML), 52-53 class diagrams, 53-58, 115 sequence diagrams, 58-61, 121-122 use case diagrams, 53 directory services, 20

Distributed Component Object Model (DCOM; Microsoft), 19, 23-24, 28, 163 distributed objects in, 221-222 objects passed by, 286 Distributed Computing Environment (DCE), 19, 21-23, 163 Distributed interNet Architecture (DNA; Microsoft), 377-378 distributed objects, 23-26, 149-150, 163 in CORBA, 219-221 debugging, 191 in Distributed Component Object Model (DCOM), 221-222 distributed processing, 7-8 business objects in, 32 transaction processing layer in, 26 dynamic invocation, 271-272 E

end users design to meet needs of, 61-62 multiprocessing by, 332 Enterprise JavaBean (EJB) standard, 200-201, 367, 379-380 Enterprise Resource Planning (ERP) packages, 383-384 error checking, 81 error handling, 84-87, 290-294, 322-325 in accessing remote objects, 218-219 error logs, 324-325 error messages, 85, 319 errors in database servers, 321 fault tolerance and, 185 in user interfaces, 318-319 See also exception handling event objects, 104 "event occurred" messages, 104 events, 104-105 Exception class (Java), 290-291 exception handling, 84-87, 290-292 in accessing remote objects, 218-219 by Java, 216 in service interfaces, 72-73

Index by services, 80-81 See also error handling exception objects, 322-323 execute commands (JDBC), 236 external applications databases, 168-170 integration of, 158-159 represented by objects, 154 fault tolerance, 185 field validations, 302-304 flowcharts, 70 four-layer architecture, 34 frameworks, for application servers, 178 choosing, 182-183 commercial frameworks, 182 development strategies for, 185-194 initializing, 178-180 persistent object frameworks, 238-239 requirements for, 183-185 service requests processed by, 180-182 Gates, Bill, 370 generalization (object relation), 109-112 in class diagrams, 56-57 in Java, 206 generalized object servers, 140-143 getter and setter methods, 289 Globally Unified Identifiers (GUIDs), 222 group ware, 187 H

"handle event" methods, 104-105 hash tables, 246 hierarchical classifications, 314-315 HTML, 37 I IBM, 27 IDE (integrated development environment), 190,199 impedance mismatches, 144 infrastructure, 118

inheritance, 109-112, 141 in class diagrams, 56-57 in Java, 206 initializing application server framework, 178-180 Inprise Application Server, 182 input and output streams, 164-168 insert statement (SQL), 231-232 integration of applications, 158-159 application mining for, 159-160 interdependencies of data, 304-306 relational, 310-311 interface definition languages (IDL), 9, 24-25, 380 for communications between user interface and service interface, 29-30 Microsoft's Interface Definition Language (MIDL), 222 supported by CORBA, 219-220 interface objects, 66 interfaces in Java, to package objects, 207-210 remote interfaces, 211-212 service interfaces, 65, 66, 269-270 services bundled into, 83-84 Internet, 192, 374-375, 387 Distributed interNet Architecture (DNA), and, 377-378 Java used on, 197 Web server-based tools for, 37 intranets, 37 iteration in service interface design, 73 in UML diagrams, 59 iterative development, 47 Jacobson, Ivar, 52, 68, 94 Java (language), 197-198 coding guidelines in, 206-207 Enterprise JavaBean standard, 200-201, 367, 379-380 error handling in, 294

409

410

Building Application Servers interfaces to package objects in, 207-210 JDBC 0ava Database Connectivity), 228-237 object-oriented programming in, 201-206 other middleware architectures compared with, 219-222 remote objects in, 211-219 transaction services for, 367 JavaBean, 25-26, 120, 200-201, 367, 379-380 javac compiler, 199 Java Software Developer's Kit 0ava SDK) APIs for CORBA in, 29 CORBA supported by, 23 RMI (Remote Method Invocation) included in, 10, 198 RMI registry in, 215 Java Virtual Machine (JVM), 198-201 threads used by, 334 JDBC (Java Database Connectivity), 136, 200 architecture of, 228-233 programming using, 233-237 joint application design QAD), 43-45 common language used in, 73 use cases in, 68-69 Keuffel, Warren, 11 knowledge bases, 325 Lammers, Susan, 369-370 languages (computer), 190 error and exception handling by, 84 interface definition languages (IDL), 24-25 Java, 197-198 Structured Query Language (SQL), 134-136, 230-233 supported by CORBA, 219 Unified Modeling Language (UML), 51-61 languages (human)

RAD (Rapid Application Development) tools, 190-191 used in business objects, 95 layered design, 49-50 legacy software, 157 in development environments, 187 proxy objects to represent, 160-162 life cycle management, 131 life cycle services, 20, 24 Linux operating system, 385-386 locking, 264, 354 at database level, 354-355 at object level, 355-357 at persistence level, 357-358 resolving deadlocks in, 358-360 lock method, 361 lookup tables, 169-170 business rules in, 307-310 Lotus Notes, 187

M managed healthcare applications, 4-6 measurements, 194 message brokers, 27 message handling, 323-324 message-oriented middleware (MOM), 165-167 messages, 294 error messages, 85, 319 for errors in user interfaces, 319 for events, 104 standardized, 322 methods, 102 names for, 207 metrics, 194 Microsoft, 15, 370 Component Object Model (COM) by, 19, 23-25 Component Object Model architecture (COM) by, 10 Distributed Component Object Model (DCOM) by, 19, 23-24, 28, 163, 221-222, 286 Distributed interNet Architecture (DNA) by, 377-378

Index MSMQ message brokers by, 27 Microsoft Access, 4 Microsoft Application Services, 378 Microsoft Foundation Classes (MFC), 141 Microsoft's Interface Definition Language (MIDL), 222 Microsoft Transaction Server (UTS), 10,15, 182, 367 middleware, 10, 38 in application server architecture, 17-19, 28-29 categories of, 19-21 for databases, 136-137 evaluation versions of, 13 interface definition languages (IDL), 9 message-oriented middleware (MOM), 165-167 repositories in, 119-120 services provided by, 20 in software design, 50 vendors of, 15 modeling business processes, 46 Unified Modeling Language (UML) for, 51-61 MQ-Series message brokers (IBM), 27 MSMQ message brokers (Microsoft), 27 multiprocessing, 331-336 within application servers, 337-340 multi-tasking, 333-334 multi-threading, 150-151, 265, 334, 346-353 multi-tiered client/servers, See n-tiered client/servers multi-variant classifications, 315-316 N naming services, 20, 24, 279 Netscape, 386 network errors, 87 networks accessing remote objects on, 217-219 business objects distributed across, 32 Distributed interNet Architecture (DNA; Microsoft) and, 377-378 distributed processing over, 7-8

message brokers for, 27 message-oriented middleware (MOM) for, 165-167 passing data through, 269-270 "sneaker net," 167-168 notation, Unified Modeling Language (UML) for, 51-61 notification, 265 n-tiered (multi-tiered) client/servers, 4-6 designing application servers for, 43 moving from traditional client/servers to, 12-13 object database management systems (ODBMS), 130, 152-153 relational databases versus, 33 Object Management Group (OMG), 18-19, 386 CORBA (Common Object Request Broker Architecture) by, 23 transaction specification of, 26 object modeling, 93 object monitors, 380 object-oriented databases, 152-153 object-oriented programming design combined with, 48 in Java, 201-206 object-oriented programming languages, 32 object-oriented software design business objects in, 93 Unified Modeling Language (UML) standard used in, 51-52 object relations, 107 aggregation, 107-109 association, 112-113 collections, 114-115 generalization and specialization, 109-112 object request brokers (ORBs), 10 objects attributes of, 101-102 business objects, 16, 30-33, 45, 91-92, 94-95 classes versus, 95

411

412

Building Application Servers class factory objects, 342-345 complex, retrieving, 255-258 customer objects, 248-250 data in, 93 deleting from databases, 264 distributed objects, 23-26, 163 events and, 104-105 external applications represented by, 154 increasing, 250-251 interactions among, 107-115 interface objects, 66 in Java, 201-206 locking, 355-357 methods in, 102 multiple, 335-336 multiple, retrieving, 251-255 packaging, in Java, 207-210 passing, 286-288 proxy objects, 160-162 relational databases and, 144-148 remote objects, 211-219 reusable business objects, 8 reuse of, 117-119 states of, 103-104 synchronizing data and, 353-360 tracking, 143-144 transaction objects, 361-363 See also business objects object servers extending, 250-258 generalized object servers, 140-143 persistent object servers, 239-250 ODBC (open database connectivity; Microsoft), 21, 136, 238 JDBC (Java Database Connectivity) bridge to, 200, 229-230, 234-235 Open JORBUX, 386 Open Software Foundation (OSF), 18-19 Distributed Computing Environment (DCE) by, 21-23 open source software, 385-386 operating systems Linux, 385-386 Multi-tasking by, 333 multi-threading and, 346-347

order lookup screens, 79 organization-based security, 327 Page, John, 370 palm-top computers, 388-389 parameters, 272 objects passed as, 286 in UML diagrams, 59 parent objects, 109 persistence, 120, 144, 321 locking, 357-358 persistence layer, 16-17, 32-33, 250, 321 multiprocessing and, 339 optimizing, 258-259 role of, 130-131 persistence services, 20 persistent object frameworks, 238-239 persistent object layer, 129-130, 227, 239 design of, 137-140 generalized object servers in, 140-143 relational databases and, 144-148 scalability of, 149-152 tracking objects in, 143-144 persistent objects, 130 communicating with databases, 227-228 loading into memory, 179 multiprocessing and, 339 persistent object servers, 239-250, 260 pervasive computing, 389 Petzold, Charles, 207 platforms, 374, 387 cross-platform integration, 9 Java Virtual Machine (JVM) as, 199 primitives, 286 procedures remote procedure calls for, 21-23 in service interfaces, 71-72 processes, 118 multiprocessing of, 332 programming design combined with, 48 multi-tiered client/servers, 11 tools for, 188-192

Index using JDBC (Java Database Connectivity), 233-237 programming languages and tools, 190 project management software, 188 properties, 288-290 property pages, 289-290 proxy objects, 160-162 punch cards, 171 RAD (Rapid Application Development) tools, 35-36, 190-191, 381 Rational Rose (CASE tool), 58 Raymond, Eric, 385 reference counters, 246-247 relational databases, 130, 132 joining business objects with, 240-245 middleware for, 136-137 object databases versus, 33 objects and, 144-148 relational data model for, 133 Structured Query Language (SQL) for, 134-136, 230-233 See also databases relational data model, 132, 133 remote communications, 271-272 remote database protocols, 21 remote interfaces, 211-212 remote job entry (RJE) software, 171 remote objects, 211-219 releasing, 285-286 remote procedure calls, 21-23, 162-163 remote software, 162-164 replication of database changes, 169-170 repositories, 119-120 resource locking, 354 reusable business objects, 8, 91 reusable software, 12 reuse of objects, 46-47, 117-119 RMI (Remote Method Invocation), 10, 23, 28-29, 198 to distribute Java objects, 211-219 JDBC Qava Database Connectivity) and, 200 RMI naming service, 341

role-based security, 327 rollback method, 365, 366 rule objects, 320 rule processing, 297 rules, See business rules rule tables explicit, 311-312 generalized, 312-313 Rumbaugh, James, 52 scalability, 149-153 of application server frameworks, 183-184 screens order lookup screens, 79 screen scraping, 164 security, 326-329 in application server frameworks, 184-185 security objects, 328 security services, 20 select statement (SQL), 231 self-directed technical review, 48-49 sequence diagrams, 58-61, 121-122 sequential pooled connections, 261-262 servers communications by, 272-273 database servers, 321 multiple, 262 in n-tiered client/servers, 4 service (application) interface layer, 16, 29-30 service interface objects, 121-122 service interfaces, 65, 66, 269-270 actors in, 71 business rules in, 319-320 context of, 69-70 creating, 274-280 defining, 275-276 design of, 66-68 error and exception handling by, 84-87 exceptions in, 72-73 implementing, 276-279 linking to business objects, 120-121

413

414

Building Application Servers multiprocessing and, 338 procedures in, 71-72 registering, 279-280 security implemented in, 328 use of, 280-285 services accessing, 281-282 application-specific, 78-79 bundling into interfaces, 83-84 business object layer hidden by, 81-82 conforming to standards, 82-83 exceptions handled by, 80-81 implementing, 123-125 processing requests for, 180-182 requesting, 274 self-contained, 79-80 subroutines turned into, 160 use cases turned into, 76-78 Simonyi, Charles, 207 skeleton programs, 24, 29-30, 214, 272-273 "sneaker net," 167-168 socket APIs, 164 software legacy software, 157 reusable, 12 software design, See design software designers, 7 source code, generated by CASE, 189 specialization (object relation), 109-112 standards, 373, 376-377 CORBA (Common Object Request Broker Architecture) as, 23 in design, 47 Distributed Computing Environment (DCE) as, 21-23 Distributed interNet Architecture (DNA), 377-378 Enterprise JavaBean, 200-201, 379-380 for middleware, 18-19 for notation, Unified Modeling Language (UML) as, 52 in programming, 11 services conforming to, 82-83 states, 103-104 static invocation, 271, 272

store method, 361 Structured Query Language (SQL), 134-136, 230-233 used in JDBC (Java Database Connectivity), 236-237 stub programs, 24, 29-30, 214, 271, 272 subroutines, 160 Sun Microsystems CORBA supported by, 23 Enterprise JavaBean standard by, 200-201, 367, 379-400 Java language by, 197 JDBC-ODBC bridge driver by, 229-230 symbols (UML), 52 See also diagrams (UML) synchronization, 119, 263-266 of objects and data, 353-360 synchronizing transactions, 170 system administrators, 7 system errors, 87 table locking, 354 tables classification tables, 314-317 in databases, 133 hash tables, 246 lookup tables, 169-170, 307-310 rule tables, 311-313 testing tools, 191 Thorpe, Margaret, 298 threads, 334 three-tiered client/servers, 4 throw command, 290, 292 time services, 20 tools, 188-192 Torvalds, Linus, 385 tracking objects, 143-144 training, 192-194 transaction objects, 361-363 transaction processing layer, 26, 34 transaction processing monitors, 26-27, 33 commercial transaction monitors, 366-367 transaction requests, 76

Index transactions, 151-152, 360-367 synchronizing, 170 trial projects, 12-13 try/catch blocks, 290, 292-293 Tuxedo (transaction processing monitor), 26 two-phase commit process, 365-366 two-tiered client/servers, 3-4 moving to n-tiered client/servers from, 12-13 U

Unified Modeling Language (UML), 43, 51-52 diagrams and symbols in, 52-61 unlock method, 361-362, 364 update statement (SQL), 232-233 use case diagrams, 53 use cases, 68-69 in service interface design, 76-78 user interfaces, 16 application (service) interface layer and, 29-30 business rules in, 318-319 designing, 76-77 error handling by, 85-86 multiprocessing and, 338 security implemented in, 328-329 users, See end users V variables, multi-threading and, 334 version control, 189-190 Visual Basic, 384 W waterfall method of software design, 44 Web browsers, 199-200 Web pages, 199 Web server-based tools, 37 Windows Distributed Component Object Model (DCOM) on, 23-25, 222 names for classes in, 206-207 ODBC (open database connectivity)

used with, 238 Windows 2000, 19 word processing, 372 workflow tracking applications, 12-13 Y Y2K problem, 301 Yourdon, Ed, 94

415

---

Advances in Building Technology

Read more

Object Technology

Read more

Building Secure Servers with Linux

Read more

Building Secure Servers With Linux

Read more

Tried and True Object Development: Industry-Proven Approaches with UML (SIGS: Managing Object Technology)

Read more

Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems Using Object Technology (SIGS: Managing Object Technology)

Read more

Building Secure Servers with Linux

Read more

Building Secure Servers with Linux

Read more

Advances in Fingerprint Technology

Read more

Advances in Fingerprint Technology,

Read more

Advances in Knitting Technology

Read more

Advances in Sonar Technology

Read more

Advances in UMTS Technology

Read more

Advances in Wool Technology

Read more

Advances in Knitting Technology

Read more

Building Object Categories in Developmental Time

Read more

Advances in Building Energy Research

Read more

Object Technology: A Manager's Guide

Read more

Advances in Yarn Spinning Technology

Read more

Advances in Yarn Spinning Technology

Read more

Recent Advances in Parsing Technology

Read more

Advances in Sonar Technology (2009)

Read more

Advances in Computers: Web Technology

Read more

Advances in Engineering and Technology

Read more

Building Science: Concepts and Application

Read more

Fundamental Building Technology

Read more

Advances in Robotics Research: Theory, Implementation, Application

Read more

Advances In Robotics Research Theory Implementation Application

Read more

Robot Building for Beginners (Technology in Action)

Read more

Robot Building for Beginners (Technology in Action)

Read more

Recommend Documents

Advances in Building Technology

ADVANCES IN BUILDING TECHNOLOGY Proceedings of the International Conference on Advances in Building Technology 4-6 Dec...

---

Object Technology

---

Building Secure Servers with Linux

---

Building Secure Servers With Linux

---

Tried and True Object Development: Industry-Proven Approaches with UML (SIGS: Managing Object Technology)

TRIED & TRUE OBJECT DEVELOPMENT MANAGING OBJECT TECHNOLOGY SERIES 1. What Every Software Manager Must Know to Succee...

---

Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems Using Object Technology (SIGS: Managing Object Technology)

---

Building Secure Servers with Linux

---

Building Secure Servers with Linux

---

Advances in Fingerprint Technology

Advances in Fingerprint Technology SS EE CC O ON ND D EE DD II TT II OO NN CRC SERIES IN FORENSIC AND POLICE SCIENCE ...

---

Advances in Fingerprint Technology,

Advances in Fingerprint Technology SS EE CC O ON ND D EE DD II TT II OO NN CRC SERIES IN FORENSIC AND POLICE SCIENCE ...

---

×

Report "Building Application Servers (SIGS: Advances in Object Technology)"

Your name

Email

Reason -Select Reason- Pornographic Defamatory Illegal/Unlawful Spam Other Terms Of Service Violation File a copyright complaint

Description

Close Send

×

Sign In

Email

Password

Remember me Forgot password?

Sign In

---

Login with Facebook

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close