![3
This chapter begins by analyzing some of the problems facing the software
industry. It then briefly chronicles certain aspects of the industry’s history.
Much of this history will already be familiar to many readers, but I present it
here in order to identify advances that MDA builds upon.
Challenges Facing the Software Industry
It’s common knowledge that difficult challenges confront the IT managers and
entrepreneurs who develop the software that is increasingly critical to the
functioning of the modern enterprise. Producing these systems involves pains-
taking, detailed work by highly skilled programmers. The recent contraction
of the high-tech economy hasn’t changed the fact that skilled software devel-
opers are expensive resources, making it a very costly proposition to staff
enterprise software development projects.
Furthermore, many software development investments yield disappointing
results. Some ambitious projects result in failure.1
Others go so far over budget
that management eventually kills them, which is another form of failure. Some
systems that initially succeed prove to be unstable or inflexible over time.
Pressure and Progress:
How We Arrived at This Point
C HAPTE R
1
1
“85% of IT departments in the U.S. fail to meet their organizations’ strategic business needs.”
[CW 1999]](https://image.slidesharecdn.com/43109-250507063411-acddea8e/85/Model-Driven-Architecture-Applying-MDA-to-Enterprise-Computing-1st-Edition-David-S-Frankel-31-320.jpg)
![There isn’t complete agreement in the software industry on the exact defini-
tion of component, but usually the term refers to a software module that can be
packaged in compiled form so that it can be independently deployed as part of
applications or assembled into larger components.
In manufacturing industries, manufacturers of finished products produce
required components or purchase them from a third party. The ability to use
standardized components in different products was one of the prime drivers
of the industrial revolution.
CBD, which is still maturing, presages another kind of industrial revolution,
one that applies to the production of software. Large companies can afford to
build some components themselves while purchasing some from component
vendors, while smaller companies are more apt to purchase all or most of the
components they use.
A detailed discussion of CBD is beyond the scope of this book. An important
book by Peter Herzum and Oliver Sims, entitled Business Component Factory,2
defines many important CBD concepts that I leverage in this book. I refer to
their approach as Herzum-Sims.
Design Patterns
The concept of design patterns, which is also a key element of industrial pro-
duction processes, has made an important contribution to improving software
development productivity and quality. Programmers can reuse common design
patterns that others have thought through and validated.
Generic reusable patterns have been published3
as well as patterns specific
to certain platforms such as Java 2 Platform Enterprise Edition (J2EE).4
For example, the J2EE BluePrints Value Object pattern5
supports efficient
information exchange with distributed components. Imagine a distributed
component that has multiple attributes including the customer ID, first name,
last name, address, Social Security number, and so on. Because remote invoca-
tion over a network is expensive, it’s inefficient to simply provide remote get
and set operations for each property. The Value Object pattern uses a Value
Object that contains get and set operations for each attribute and a façade object
that provides a remote operation to get a Value Object, thus making it possible
to retrieve the values of all of the properties with one remote call. The façade
object also provides a remote operation to set—that is, to pass in—a Value
Object, thus making it possible to set the values of all of the properties with
one remote call (see Figure 1.5).
10 Chapter 1
2
[HS 2000]
3
[GHJV 1995]
4
[ACM 2001]
5
[JVO]](https://image.slidesharecdn.com/43109-250507063411-acddea8e/85/Model-Driven-Architecture-Applying-MDA-to-Enterprise-Computing-1st-Edition-David-S-Frankel-38-320.jpg)
![dialog, whereupon the tool would generate the bulk of the code for displaying
and managing the dialog, with the programmer enhancing the generated code
to produce the finished product. The tools for drawing the GUIs were called
WYSIWYG (What You See Is What You Get) editors.
With EJB, .NET, and the CORBA Component Model, a descriptor contains
declarations of various properties of a component. The middleware acts in
accordance with the property declarations. For example, in order for a compo-
nent to support ACID6
transactions, a programmer need only declare such
support in the descriptor, rather than write a set of procedural instructions to
support transactional behavior. The middleware takes care of the rest.
We can classify two basic modes for processing declarations:
Code generation. In this mode, the declarations drive a 3GL code
generator. GUI development environments that generate code from a
WYSIWYG declaration of GUI properties are an example.
Runtime interpretation. In this mode, precompiled, predeployed
executable code interprets the declarations at runtime. For example, a
database engine does not generate new 3GL code when handed a new
declarative data model. Instead, the database engine more or less
interprets the model at runtime.
Enterprise Architecture and Separation of Concerns
Software architecture seeks to organize complex systems by separating con-
cerns. Separating concerns tends to localize changes to one aspect of a system.
When changes to one aspect do impact other aspects, separation of concerns
makes it easier to trace the impact.
Separating concerns tends to have a positive effect on the viability variables.
The localization of changes makes systems less brittle and thus improves their
longevity. Once an architecture and a supporting infrastructure are in place,
such localization also improves productivity because change can be effected
more rapidly. Traceability tends to improve quality.
Multitiered architecture is one of the most well-known and widely accepted
architectural approaches for distributed enterprise systems. Nevertheless,
there is some variance in the industry with regard to the number of tiers, and
the names and roles of the tiers. Since I use the concepts of multitiered archi-
tecture later in the book, it’s worth spelling out the concepts and terminology
that I employ.
14 Chapter 1
6
ACID transactions are atomic, consistent, isolated, and durable. See [GR 1993] for a definitive
work on the subject.](https://image.slidesharecdn.com/43109-250507063411-acddea8e/85/Model-Driven-Architecture-Applying-MDA-to-Enterprise-Computing-1st-Edition-David-S-Frankel-42-320.jpg)
![Through the lessons of experience, architects began to realize that systems
would be more scalable if the business logic that involves user interaction
were separated from other business logic. Thus the mid tier was split into two
tiers that separated these concerns: the workspace tier and the enterprise tier. The
workspace tier is responsible for executing the logic of the pattern of inter-
action with the user. The interaction logic accesses the enterprise tier rather
than going directly to the database.
Oliver Sims has been advocating four-tier architecture for the better part of
a decade.7
Herzum-Sims calls the four tiers user tier, workspace tier, enterprise
tier, and resource tier, as Figure 1.10 illustrates. The figure also points out alter-
nate names that some practitioners use for the tiers.
Figure 1.10 Four-tier enterprise architecture.
A B Means A accesses B
USER TIER (a.k.a. Client Tier)
User Presentation
WORKSPACE TIER (a.k.a. Interaction Tier)
User Interaction Logic
Servers
ENTERPRISE TIER (a.k.a. Business Tier)
Encapsulated Business Logic
Servers
RESOURCE TIER (a.k.a. Integration Tier)
Mainframe DBs DBs on other servers
Resource Adapters (e.g. Object-Relational Mappings)
Pressure and Progress: How We Arrived at This Point 19
7
See [HS 2000] for his most recent work on this subject.](https://image.slidesharecdn.com/43109-250507063411-acddea8e/85/Model-Driven-Architecture-Applying-MDA-to-Enterprise-Computing-1st-Edition-David-S-Frankel-47-320.jpg)
Model Driven Architecture Applying MDA to Enterprise Computing 1st Edition David S. Frankel
- 1. Model Driven Architecture Applying MDA to Enterprise Computing 1st Edition David S. Frankel download https://ebookgate.com/product/model-driven-architecture-applying- mda-to-enterprise-computing-1st-edition-david-s-frankel/ Get Instant Ebook Downloads – Browse at https://ebookgate.com
- 2. Get Your Digital Files Instantly: PDF, ePub, MOBI and More Quick Digital Downloads: PDF, ePub, MOBI and Other Formats Service Oriented Architecture SOA Governance for the Services Driven Enterprise 1st Edition Eric A. Marks https://ebookgate.com/product/service-oriented-architecture-soa- governance-for-the-services-driven-enterprise-1st-edition-eric-a- marks/ Model Driven Architecture for Reverse Engineering Technologies Strategic Directions and System Evolution 1st Edition Liliana Favre https://ebookgate.com/product/model-driven-architecture-for- reverse-engineering-technologies-strategic-directions-and-system- evolution-1st-edition-liliana-favre/ An Introduction to Enterprise Architecture 3rd Edition Scott A. Bernard https://ebookgate.com/product/an-introduction-to-enterprise- architecture-3rd-edition-scott-a-bernard/ Building Java Enterprise Applications Architecture 1st Edition Brett Mclaughlin https://ebookgate.com/product/building-java-enterprise- applications-architecture-1st-edition-brett-mclaughlin/
- 3. Just Enough Software Architecture A Risk Driven Approach 1st Edition George H. Fairbanks https://ebookgate.com/product/just-enough-software-architecture- a-risk-driven-approach-1st-edition-george-h-fairbanks/ Directory Services Design Implementation and Management Enterprise Computing 1st Edition Nancy Cox https://ebookgate.com/product/directory-services-design- implementation-and-management-enterprise-computing-1st-edition- nancy-cox/ Plumber s Licensing Study Guide Third Edition Frankel https://ebookgate.com/product/plumber-s-licensing-study-guide- third-edition-frankel/ Quantum Computing Explained 1st Edition David Mcmahon https://ebookgate.com/product/quantum-computing-explained-1st- edition-david-mcmahon/ Surface Architecture 1st Edition David Leatherbarrow https://ebookgate.com/product/surface-architecture-1st-edition- david-leatherbarrow/
- 5. David S. Frankel Model Driven Architecture Applying MDA to Enterprise Computing
- 7. Model Driven Architecture Applying MDA to Enterprise Computing
- 9. David S. Frankel Model Driven Architecture Applying MDA to Enterprise Computing
- 10. Publisher: Joe Wikert Editor: Theresa Hudson Assistant Development Editor: James H. Russell Editorial Manager: Kathryn A. Malm Associate Managing Editor: Angela Smith Text Design & Composition: Wiley Composition Services This book is printed on acid-free paper. ∞ Copyright © 2003 by David S. Frankel. All rights reserved. Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rose- wood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470. Requests to the Pub- lisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, E-mail: [email protected]. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, inci- dental, consequential, or other damages. For general information on our other products and services please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Trademarks: Catalysis is a service mark of ICON Computing. CORBA is a registered trade- mark of the Object Management Group. “Design by Contract” is a trademark of Interactive Software Engineering. EJB, J2EE, and Java are trademarks of Sun Microsystems. Model Driven Architecture, MDA, MOF, Unified Modeling Language, UML, IIOP, and XMI are trademarks of the Object Management Group (OMG). MQSeries is a registered trademark of International Business Machines. Visual Basic is a registered trademark of Microsoft Corporation. Library of Congress Cataloging-in-Publication Data: ISBN: 0-471-31920-1 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1
- 11. To my mother and my late father, who taught me to value learning and truth. To my wife Janice, my loving partner during all the ups and downs of life. To my children, Rafi and Ari, my connection to the future.
- 13. Contents vii Preface xv Foreword xix Part One Introducing MDA 1 Chapter 1 Pressure and Progress: How We Arrived at This Point 3 Challenges Facing the Software Industry 3 The Viability Variables 4 Machine-Centric Computing 5 Application-Centric Computing 6 From Assembly to 3GLs 6 Operating Systems and the Abstraction Gap 8 Object-Oriented Languages and Virtual Machines 8 Enterprise-Centric Computing 9 Component-Based Development 9 Design Patterns 10 Distributed Computing 11 Middleware: Raising the Platform Abstraction Level 12 Middleware: Raising the Programming Abstraction Level 13 Declarative Specification 13 Enterprise Architecture and Separation of Concerns 14 Enterprise Application Integration (EAI) 21 Design by Contract 22 Other Enterprise-Centric Technologies 25 Pressures on Enterprise-Centric Computing 25 Pressure on Production Costs 26 Pressure on Quality 27 Pressure on Longevity 28 A Modern Day Sisyphus 30 Summary 30
- 14. Chapter 2 Model Driven Enterprise Computing 31 Bringing Model-Centrism to Intermediate Tiers, EAI, and B2Bi 31 Models as Development Artifacts 32 Syntactic Abstraction versus Semantic Abstraction 32 B2Bi and MDA 35 First- and Second-Generation Web Services Integration 36 Web Services and Enterprise Architecture 38 Defining Abstract Business Services 39 Mapping Business Information Models to XML 41 Parameterized Mappings 41 Mapping Business Service Models to WSDL 42 Automating Business Processes and B2B Collaborations 43 Flexibility in Choosing the Abstraction Level 45 Modeling Language Extensibility 46 Platform Independence: A Relative Concept 48 EAI and MDA 50 The Limits of Declarative Specification 52 Metadata Integration 52 MDA and Component-Based Development 54 Automatic Pattern Replication 54 A J2EE Example 55 Architectural Styles 56 Pushing More below the Line 57 Model Driven Enterprise Architecture 58 Standardized MDA-Based Modeling Languages 59 Synchronizing among Multiple Tiers 60 Middleware and the Abstraction Gap 60 Design by Contract Revisited 61 MDA and Other New Development Approaches 62 Interactive Design 62 Extreme Programming 63 Summary 64 Part Two The Base MDA Technologies 65 Chapter 3 The Role of UML in MDA 67 Origins and Evolution 67 Strengths 68 Separation of Abstract Syntax from Concrete Syntax 68 Extensibility 70 Support for Platform-Independent Modeling 71 Maintained by a Standards Organization 72 Weaknesses 73 Large and Poorly Partitioned 73 Weak Support for Viewpoints 74 Not Current with Industry Developments in Components and Patterns 74 Vagueness about Relationships 74 viii Contents T E A M F L Y Team-Fly®
- 15. Limitations of Profiling 74 Misalignment of UML and MOF 75 Lack of Standard Diagram Interchange 75 Lack of a Metamodel for Object Constraint Language 75 Future Directions 76 UML 2.0 76 Expected Outcomes 76 What You Can Do Now 77 Summary 77 Chapter 4 Beyond Basic Class Modeling 79 Design by Contract 79 The Basics 79 An Example 80 Contracts, Reuse, and Interoperability 83 As Precise as Programming3 85 Constraints and Exceptions 86 A Framework for Quality 86 DBC and UML Tools 87 Overcoming Barriers to Use 87 Another Look at Constraints 87 Behavioral Modeling 88 State Machines 88 Activity Models 91 Interaction Models 92 Use Case Models 93 Action Semantics 93 What You Can Do Now 94 Summary 94 Chapter 5 The Meta Object Facility (MOF) 95 A Key MDA Foundation 95 A Basic Premise 97 Borrowing from UML 98 MOF Isn’t Just for OO 101 Abstract Syntax Trees 103 Metalevels 105 Level M3 105 Level M2 106 Level M1 106 Level M0 107 How Meaningful Are Metalevels? 107 Self-Description 108 Metalevels and Abstract Syntax 109 Model Driven Metadata Management 110 What Is Metadata? 110 Volume and Value 111 Previous Attempts at Metadata Integration 111 Contents ix
- 16. An Additional Premise 112 What Is the Benefit? 113 Platform Independence 113 Enforcing Semantics 115 Metadata Management Scenarios 115 Generic MOF Code 118 MOF Is Not CORBA-Based 119 Appearances versus Intent 120 Mapping beyond Syntax 120 Applying the MOF-CORBA Mapping 120 A Closer Look at XMI 122 Return on Investment 122 XMI and XML Schema 124 A Common Misconception about XMI 124 Hand-Coded DTDs and Schemas 124 XMI Complexity versus UML Complexity 125 XMI as Input to Generators 126 XMI and UML Diagram Interchange 127 A Closer Look at JMI 128 A MOF-Java Mapping 128 Aren’t XML and DOM Enough? 129 Another Look at MOF Self-Description 131 Additional Applications 135 Human Usable Textual Notations 135 XMI’s Reverse Mapping 136 Weaknesses 138 Lack of Coverage of Graphical Notation 138 Lack of Support for Versioning 138 Misalignment with UML 139 MOF-CORBA Mapping Problems 139 Interoperability Problems Due to Immaturity 139 Future Directions 140 Interoperability Testing 140 MOF 2.0 140 MOF in the Computer Industry 140 MOF and Enterprise Software 141 MOF and the Resource Description Framework (RDF) 142 What You Can Do Now 142 Summary 143 Chapter 6 Extending and Creating Modeling Languages 145 Extending UML via Profiles 145 A Family of Languages 145 Stereotypes 146 Tagged Values of Stereotypes 147 Standalone Tagged Values 148 x Contents
- 17. Can’t We Do This at M1? 149 Defining a Profile Formally 150 Extending UML via MOF 153 Anatomy of a Heavyweight UML Metamodel Extension 153 Profiles versus Heavyweight Extensions 154 Creating New Modeling Languages 155 Tight Domain Focus 155 The Metamodel + Profile Strategy 156 Heavyweight + Lightweight Extension Strategy 158 UML Tools versus MDA Tools 158 UML Modeling versus MOF Metamodeling 159 UML Constructs That MOF Does Not Support 159 What You Can Do Now 161 Summary 161 Chapter 7 Building Compilable Class Models 163 The Scope of the Guidelines 163 Class Modeling versus Behavioral Modeling 164 Level of Abstraction 164 What the Standard MDA Mappings Produce 164 UML versus MOF 165 Purposes of the Guidelines 165 Don’t Define Accessor and Mutator Operations for Attributes 166 Use Association End Navigability Judiciously 167 Navigable versus Non-Navigable Association Ends 168 Navigability and Contracts 168 Redundancy and Navigable Association Ends 170 Generating Read-Only APIs 170 Navigability and Information Formats 171 Avoiding Name Clashes 172 Navigability and Modularity 172 A MOF Complication 174 Use Care in Specifying Multivalued Properties 176 Ordering 176 Uniqueness 176 Use Aggregation . . . Properly 177 Aggregation Properties of Association Ends 177 Composite Aggregation 178 Shared Aggregation 180 Use Abstract Classes 181 Distinguish “Interesting” versus “Uninteresting” Operations 183 Strive for Computational Completeness 185 Syntactic Completeness 185 Semantic Completeness 187 Contents xi
- 18. Special Concerns with M1 Models 188 Use of Deferred Constraints 188 Need for Lower-Level Models 188 What You Can Do Now 189 Summary 189 Chapter 8 Modeling at Different Abstraction Levels 191 A Basic Model Taxonomy 192 Iterative Development 193 How the Models Fit Together 193 MDA Personas 194 Business Analyst 195 Requirements Analyst 195 Application Engineer 195 Middleware Engineer 195 Quality Assurance Engineer 196 Deployment Engineer 196 Network Administrator 196 Architect 196 Infrastructure Engineer 197 Persona Synopsis 197 Introduction to the Examples 197 Business Models 198 Requirements Models 200 Platform-Independent Models (PIMs) 203 Platform-Specific Models (PSMs) 207 An EJB-Specific Model 207 Java Plus Semantics 208 Tracing between Abstraction Levels 209 Limitations of Declarative Models 210 Parameterizing a PIM-PSM Mapping 210 Mapping PIM Collections 210 JMI’s Approach 213 Defining a Parameterization Language 214 Searching for an Abstraction 214 Parameterizing a PSM-Code Mapping 217 Selecting Implementations 218 Elements That Are Less Traceable to the PIM 220 Benefits of Read-Only PSMs 221 PIM Typing Issues 222 Multiple Parameterizations 224 Multiple Parameter Sets in the PIM 224 Multiple Parameter Sets in the PSM 225 Language Definition Strategies 226 Component Descriptors 228 xii Contents
- 19. Synchronizing Models and Code 230 The “Forward Engineering Only” Approach 230 Partial Round-Trip Engineering 233 Full Round-Trip Engineering 235 Round-Tripping and Tools 237 Round-Tripping and Architectural Enforcement 237 Inter-Tier Synchronization 238 The Impact of PSMs 241 Dimensional Flexibility 243 Synchronization Synopsis 243 Physical Models and Deployment Automation 244 What You Can Do Now 245 Summary 245 Part Three Advanced Topics 247 Chapter 9 Modeling Transformations with CWM 249 More Than a Database Metamodel 249 Implementation Strategies 251 The Inner Workings 254 Common Superclasses 254 Mapping Expressions 257 UML Models as Sources and Targets 260 Metamodel-to-Metamodel Mappings 262 MOF Mappings 266 Completing the Picture 268 Limitations 270 What You Can Do Now 271 Summary 271 Chapter 10 Additional Advanced Topics 273 Generating Declarative versus Imperative Code 273 APIs 273 Information Formats 274 The Role of Standards 274 Green Fields versus Legacy 275 Metadata Management Revisited 276 Metadata Management as a Green Field 276 Implementing Interesting Operations 276 Implementing Derived Attributes and Associations 278 Synopsis 279 Generating Bridges 280 Mappings—The Essential Knowledge 280 Generalizing the Bridging Problem 282 Standards and Bridges 285 Contents xiii
- 20. Executable Models and Virtual Machines 286 Examples from Industry 286 Correctness 287 Performance 287 Dynamism at the Lower Level 288 Reflection 290 Reflection and Metadata Fragmentation 290 Drawing Conclusions 291 A Middle Way 292 Raising the Platform Revisited 292 MDA and Systems Engineering 293 What You Can Do Now 293 Summary 294 Epilogue A Reality Check 295 Appendix A Sample Transaction Metamodel 297 ModelElement 297 Tx 297 ACIDTx 297 BusinessTxUnit 298 CompensatableUnit 299 ReversableUnit 299 BusinessTx 299 Appendix B Options Trading Concepts 301 Basic Concepts 301 Examples 302 References 305 Glossary 309 Index 313 xiv Contents
- 21. Preface xv The computer industry is always looking for ways to improve software devel- opment productivity as well as the quality and longevity of the software that it creates. Object-orientation, component-based development, patterns, and distributed computing infrastructures are examples of new approaches that have aided in this quest. Model Driven Architecture (MDA) can make an important contribution as well. It does not eclipse the other approaches. Rather, it works with them syn- ergistically to further improve the way we develop software. What Is Model Driven Architecture? MDA is about using modeling languages as programming languages rather than merely as design languages. Programming with modeling languages can improve the productivity, quality, and longevity outlook. This book explains why this is so, and introduces the technologies that underlie MDA. Who Is Using MDA? MDA has been used for years to generate real-time and embedded systems, even though the term MDAwas coined later. Now IBM, Oracle, Unisys, IONA, and other vendors are weaving MDA-based technology into their enterprise software offerings.
- 22. A Long-Term Transition In the early days of distributed object computing, one of the fathers of CORBA, Mike Guttman, was asked to give a talk to an industry gathering to share his vision of where the technology was headed. He showed a slide projecting that there would be a point in the future when distributed object infrastructures and libraries of components that ran on those infrastructures would be mainstream. An audience member asked him when he thought that would happen. He said that he thought it could easily take 10 to 15 years. He hastened to add that substantial business value would be gained at each stage of the transition, but that did not seem to stick in the minds of the sponsors, who were somewhat chagrined. They took the remark to mean that he was suggesting that nobody should invest in such technology for another decade. I take a similar risk in presenting this book on MDA. To be sure, MDA prin- ciples can be put to good use now. There are specific technologies already in place based on MDA and a number of others are emerging as I write these words. Tools that automate some aspect of software development using mod- els constitute at least a $500 million industry. Nevertheless, I stress that MDA is a budding technology that has years of work ahead before it can realize its full potential. MDA and the Object Management Group (OMG) Early in 2002 the OMG announced Model Driven Architecture as its strategic direction. The OMG is in the early stages of defining this course, and I have been deeply involved in the effort. I hope that this book will help guide this ini- tiative, but I don’t guarantee that my ideas entirely coincide with the OMG’s. As the steward of several modeling language standards, the OMG is posi- tioned to play a pivotal role supporting the growth of this new industry. But other standards bodies such as the Java Community Process, ebXML, and RosettaNet are producing specifications that apply MDA principles to various technologies and application domains. As the industry gains experience, stan- dards bodies will issue additional MDA-based standards. This book suggests some directions that these standards should take as they evolve. It also points out some deficiencies of the standardized modeling languages that must be rectified in order to fully realize the vision of MDA. Goals of This Book Despite MDA’s successes in the real time and embedded systems world, until recently few had applied it comprehensively to the development and xvi Preface
- 23. integration of enterprise systems that manage things like customers, accounts receivable, and supply chains and business-to-business integration. This book focuses on MDA in the context of enterprise systems. I want the builders of enterprise systems to understand MDA accomplishments to date and the potential that MDA offers for improving software development. I also want tool builders to understand what they can do to tap the potential. I want both audiences to be aware of the kinds of issues they will face in trying to scale MDA up to where it can consistently support the development and inte- gration of enterprise systems. Non-Goals of This Book In order for MDA to become a mature technology, one of the tasks that must be completed is the definition of a comprehensive conceptual framework for MDA. In this book I do not undertake to define such a framework, which would tie in conceptual advances in such areas as Aspect-Oriented Program- ming and Intentional Programming. Furthermore, although the book explains what the general shape of a com- prehensive MDA-based enterprise architecture would be, it does not actually define such an architecture. In concentrating on the base MDA technologies, I don’t intend to imply that the kind of comprehensive treatment this book does not supply is not impor- tant. I hope that others will find this basic work helps them to tackle these more ambitious tasks. Organization of the Book This book is organized into parts, each of which consists of a number of chapters. Part One: Introducing MDA establishes the motivation for MDA and pro- vides an overview of the subject. Part Two: The Base MDA Technologies is a hands-on tour through the technologies that constitute MDA’s foundation. This is the heart of the book, containing a large majority of the material. Part Three: Advanced Topics outlines some of MDA’s more ambitious medium- to long-range possibilities. Epilogue is a reality check about the future of MDA. A reader looking for an executive overview of MDA should read this Pref- ace, Part One, and the Epilogue. More technically oriented readers should also read Parts Two and Three. Preface xvii
- 24. Acknowledgments Most of the content of this book synthesizes work done by others. In particu- lar I wish to thank Mike Guttman, my mentor and friend for over 30 years, who helped me edit the final manuscript, provided important suggestions and feedback, and of course wrote the Foreword. I also recognize the contributions of Jack Greenfield, a pioneer in this field from whom I have learned a great deal. Special thanks go to Scott Ambler, Grady Booch, Steve Brodsky, Steve Cook, Philippe Kruchten, Scott Markel, David Mellor, Steve Mellor, Mike Rosen, Bran Selic, Oliver Sims, and Jos Warmer for their reviews of the manuscript. I would also like to acknowledge some other people who helped me develop my ideas on MDA. These include Don Baisely, Conrad Bock, Cory Casanave, Desmond D’Souza, Simon Johnston, Sridhar Iyengar, Haim Kilov, Cris Kobryn, Wojtek Kozaczynski, Jason Matthews, Guus Ramackers, Jim Rumbaugh, Ed Seidewitz, and Richard Soley. About the Author DAVID S. FRANKEL has held senior positions at QuarterSoft, Inc., IONA Technologies, and Genesis Development Corporation. He is a renowned expert in the architecture and development of complex, large-scale distributed computing systems. He has served several terms on the OMG Architecture Board. David Frankel’s contact information: Email: [email protected] (or [email protected]) Tel: +1 530 893-1100 T E A M F L Y Team-Fly®
- 25. On June 14, 1951—shortly after I was born—the U.S. Census Bureau bought the very first UNIVAC computer. This was arguably Sale #1 for the now-behe- moth commercial computing industry. That UNIVAC, the first mainframe, was about the size of a one-car garage, and required a 125-kilowatt power sup- ply to both heat and cool its 5200 vacuum tubes. For the UNIVAC’s million-dollar price tag (worth about seven times that at this writing), the Bureau’s programmers got a whopping 1000 words of pro- gram memory to play with. Nonetheless, compared to any then-available alternative, this was powerful enough to drive the sales of no less than forty- five more UNIVACs over the next five years. It also spawned a slew of com- petitors. One of these, IBM, became the largest corporation on earth, largely on the back of its computer mainframe business. In any event, the first programmers had their work cut out for them. Obvi- ously, starting with just 1000 words of memory, they focused largely on opti- mizing the use of memory and the speed of calculations for a specific machine. For many years, software engineering was driven almost entirely by the requirements—and limitations—of the available hardware. This strongly influenced both the types of computing problems that were selected, and the specific way in which software was developed. Amazingly—and despite Moore’s much-vaunted law governing the expo- nential growth of hardware power—many aspects of this kind of platform- centric thinking about software have persisted up to the present. In 1970, I was cramming bytes into an IBM 360 MVS partition. In 1980, I was juggling to keep my programs within 64K on an HP 2100MX minicomputer. In 1990, I was still worrying about whether my code would compile into a DLL small enough to load efficiently on a PC, and whether I was using up too many Windows Foreword xix
- 26. “handles.” In 1995, when I worked on the CORBA Internet Interoperability (IIOP) standard, I found myself yet again twiddling bits to minimize the size of messages going out over the wire. Nevertheless, there is a really big qualitative difference between 1951 and today. Today a steadily increasing percentage of the typical IT department’s software development process revolves around issues related to modeling the business problems to be solved, rather than the details of writing code. This is true not because individual developers necessarily really want to move in this direction, but simply because the increasing complexity of the business prob- lems that need to be solved demands such a requirements-driven approach. Perhaps reluctantly, some developers are now spending almost as much time fumbling with modeling languages like UML as they are fiddling with tradi- tional programming languages like Java and XML. This approach was presaged as early as 1960, when COBOL, the first plat- form-neutral business-oriented programming language, was introduced. The COBOL programming paradigm explicitly separated the software from the hardware, allowing programmers to think a lot more about business logic and a lot less about machine-level bit-twiddling. COBOL also introduced a signifi- cant amount of structure into software development, forcing its users to at least separate program flow logic from data descriptions and environment specifications. Over the next twenty years, COBOL’s increasing hegemony in the main- frame software market helped to foster an immense amount of de facto stan- dardization of architecture and design across the entire computing industry. This was the first “Golden Age” of software development, and many of the systems created during that period remain the data processing workhorses of major corporations today. Remarkably, they still tower like Gothic cathedrals over the tenements of software bubble-gum and baling wire that characterize so many subsequent systems. Ironically, it was the introduction of the PC—a great boon to computing in most respects—that brought the end of this Golden Age. The PC unintention- ally ushered in a new period of chaos for software development. By historical accident, the structured, platform-neutral languages like COBOL were slow to move over to the PC, and a Babel of other programming languages and devel- opment tools emerged to fill the vacuum. To accommodate the new blend of hobbyist-programmer that gravitated to the early PCs, these languages toler- ated—and even encouraged—low-level, platform-specific bit-twiddling. So, in one sense, the PC era, which started in the 1980s and exploded in the 1990s, was a second great renaissance for computing, pushing software into areas—and in front of users—where it had never been before. At the same time, however, the resulting tidal wave of polyglot software pretty much overwhelmed the traditional IT software development community and, in many ways, actually pushed back the clock in terms of systematic software xx Foreword
- 27. architecture and design. A similar discombobulating tsunami struck again with the commercialization of the Internet. Of course, all during the PC and Internet eras, many industry pundits have continued to advise developers to “design before you code” and—more recently— “to architect before you design.” In fact, there have been many pos- itive innovations in this direction over the last twenty years. But, for the mass of developers who grew up during code-centric PC era, old habits and atti- tudes die hard. To these developers, abstracting design (much less architec- ture) from programming can seem an innately uncomfortable experience that simply “delays coding.” Because of this discomfort, they frequently (if unwit- tingly) sabotage whatever design process is attempted, thereby “proving once again”—at least to themselves—that they would have been much better off to have simply started coding as early as possible. As a result, it has taken almost twenty years to reach the point where we can start recreating a level of rigor in IT software development that approaches that of the previous Golden Age of software. In the last decade or so, the idea that implementation-independent design and architecture have real intrinsic value to the development process quietly seems to be making a comeback. Sometimes this voice of reason can barely be heard above the incessant drum- beat of vendor hype and techno-babble that characterizes much of the soft- ware industry. Nonetheless, a new approach seems to be gaining critical mass in the developer and vendor community, reconstructing the best practices of the first Golden Age, while still incorporating the innovations in software engineering that came about during the PC and Internet revolutions. Model Driven Architecture (MDA), which this book describes, is a major step in this direction. What makes MDA different from any of the myriad other TLAs (three letter acronyms) that constantly flood the software community? Well, first of all, the development of MDA is being driven by the OMG, the largest software industry consortium. OMG has an enviable track record for promulgating and maintaining some of the industry’s most successful stan- dards, such as CORBA and UML. In addition, within OMG, MDA has enjoyed unusually strong backing from the systems and software vendor community. Usually initiatives of this kind take years to develop this level of consensus and support. However, even die- hard rivals such as IBM, Sun, and Microsoft are already strongly behind MDA and actively support the major standards —UML, XMI, MOF, CWM, JMI, and so on—that MDA encompasses. They will no doubt argue incessantly about the details, but they are solidly behind the approach. This means that the sup- porting mainstream tools and platforms MDA needs to grow and prosper are certainly well on the way. Finally, MDA does not purport to wholesale replace previous computing paradigms, languages, or tools. Instead, it attempts to harmonize them, allow- ing everyone to migrate gracefully to the MDA vision at their own pace, and in Foreword xxi
- 28. xxii Foreword response to their real need to do so. MDA is also specifically designed to be flexible enough to adapt to the inevitable—new software technologies that, like the PC and the Internet, will soon emerge to upend all our previous assumptions about computing. As a result, I believe that MDA actually stands a pretty good chance of revi- talizing the practice of software architecture and helping to usher in another Golden Age of software development. This is none too soon, because, as the book suggests, the rising complexity of business problems to be computerized is currently testing the limits of the last generation of development paradigms. As this book cogently argues, to deal with this complexity, design and archi- tecture standards like MDA are needed now to supplant earlier approaches as the focal point in the overall enterprise software development process. This clearly hearkens back to thirty years ago when COBOL and 3GL languages were sorely needed to replace machine code and assembly language as the principal programming tools for business applications. Nonetheless, some developers will undoubtedly try to ignore developments like MDA, and shoulder on as before, milking their existing code-centric development skills for as long as they can. In the near future, however, the most successful and productive developers will certainly be those who are willing to move aggressively to embrace the kind of design- and architecture- centric paradigms that MDA represents. That’s why this book is so important. As the first comprehensive book on MDA, it has the opportunity to set the standard for how MDA is received by the overall software development community. Fortunately, the author, David Frankel, is not just a good technical writer, but also a recognized authority on MDA and one of the driving forces behind the strategic and technical devel- opment of MDA at OMG. Just as importantly, I can tell you from personal experience that David is an accomplished developer and development manager who understands what it means to get real systems out the door. As a result, while this is not a cook- book, it is peppered with examples that show how MDA can be applied to real problems faced by real developers today. In short, I can think of no better person to clearly explain both the concepts and details behind MDA to software technicians and industry technologists alike. So, if you are new to MDA, or having any trouble understanding it, my advice is simple—start by reading this book. It will give you exactly the foun- dation you need to start mastering MDA and immediately applying its con- cepts directly and effectively to your own environment and problems. —Michael Guttman
- 29. PART One Introducing MDA MDA is not a radical departure in the way we have gone about improving software development over the years. Rather, it is an evolutionary step that consolidates a number of trends that have gradually improved the way we produce software. This part of the book positions MDA on that evolutionary path.
- 31. 3 This chapter begins by analyzing some of the problems facing the software industry. It then briefly chronicles certain aspects of the industry’s history. Much of this history will already be familiar to many readers, but I present it here in order to identify advances that MDA builds upon. Challenges Facing the Software Industry It’s common knowledge that difficult challenges confront the IT managers and entrepreneurs who develop the software that is increasingly critical to the functioning of the modern enterprise. Producing these systems involves pains- taking, detailed work by highly skilled programmers. The recent contraction of the high-tech economy hasn’t changed the fact that skilled software devel- opers are expensive resources, making it a very costly proposition to staff enterprise software development projects. Furthermore, many software development investments yield disappointing results. Some ambitious projects result in failure.1 Others go so far over budget that management eventually kills them, which is another form of failure. Some systems that initially succeed prove to be unstable or inflexible over time. Pressure and Progress: How We Arrived at This Point C HAPTE R 1 1 “85% of IT departments in the U.S. fail to meet their organizations’ strategic business needs.” [CW 1999]
- 32. The booming economy of the 1990s covered up many of the ramifications of frequent failure. Corporate earnings were so high that investors often ignored the schedule delays, cost overruns, and disappointing quality of business soft- ware systems built by high-tech startups and Global 1000 companies. A frequent comment from investment analysts who were surprised by the steepness of the NASDAQ’s decline is that they never expected such a drastic shutdown of technology spending. In a tighter economic environment, enter- prise software development must prove its business merit. Corporate man- agers are unlikely to expend precious capital on projects and products that don’t demonstrate compelling value. This kind of pressure is not new. The computer industry has gone through repeated cycles of pressure followed by advances that relieve the pressure and open up new possibilities, whereupon pressure starts building again. The Viability Variables Our industry’s economic viability is determined by the extent to which we can produce systems whose quality and longevity are in line with their cost of production. Building high-quality, long-lasting business software is expensive. As a result, sometimes we are forced to make unacceptable trade-offs among quality, longevity, and the cost of production, which I define as the software develop- ment viability variables (see Figure 1.1). It’s difficult to increase viability by addressing just one of the variables in the equation without considering the impact on the others. To promote eco- nomic viability, we must reduce the cost of production without sacrificing the quality or longevity of the software. Interestingly, we can view the history of the software industry as a series of improvements that rebalanced the viability equation at junctures where grow- ing demands pushed the limits of current approaches to development. New approaches arose each time to replace or augment current ones, slowly at first, then with increasing momentum, helping to align quality and longevity with the cost of production. Figure 1.1 The viability variables. Cost of Production Viability Quality Longevity 4 Chapter 1
- 33. Machine-Centric Computing Early programmers literally coded instructions to the computer in 1s and 0s, laboriously writing out the bit patterns that corresponded to the native CPU instructions. That seems strangely inefficient today, but for some applications the rapid calculations that the computer could perform made this kind of cod- ing economically sound. It also allowed programmers to optimize available memory and processor speed. However, the high costs inherent in labor- intensive 1s and 0s coding, coupled with high hardware costs, sharply limited the number of tasks amenable to computerization. An important software innovation—assembly language—extended the ser- viceable lifetime of machine-centric computing. Assembly language allowed programmers to use simple mnemonics to represent the native instructions that the computer understands. The programmer could write MOV AX,DX to move data from the D register to the A register, instead of writing out the binary code for the move instruction. The programmer could also give a mem- ory location a name and then address the location by that name instead of always having to refer to it by its binary address. The mnemonics and names were abstractions of the binary instructions and memory locations. An assem- bler translated the mnemonics and names into the 1s and 0s that constitute the binary representations of the native processor instructions and memory locations. Many programmers in the industry today have only used assembly lan- guage in their college courses. But, in their day, assemblers significantly changed the economic viability equation. Writing a program became much less time-consuming, thus lowering production costs. Furthermore, it turned out that programmers were less prone to error when using mnemonics than when tediously hand-coding 1s and 0s. Therefore, the level of quality rose. Finally, programs coded with assembly language were less sensitive to incremental changes made to the patterns of 1s and 0s that constituted each of the native instructions. For instance, if a change in the 1s and 0s pattern for MOV instructions occurred from one version of the processor to another, a revised assembler could assemble the programmer’s MOV instruction into the different bit pattern. The old assembly language program source code grace- fully survived the change to new patterns of 1s and 0s. Therefore, the longevity of programs tended to increase. Thus, raising the abstraction level above 1s and 0s favorably changed all three variables in the viability equation. Assemblers made it practical for large companies and government institutions to computerize certain aspects of their operations, such as payroll and billing, which consisted of relatively simple, repetitive tasks. See Figure 1.2. Pressure and Progress: How We Arrived at This Point 5
- 34. Figure 1.2 Raising the level of abstraction. Application-Centric Computing The success of assemblers pointed the way toward an application-centric world, where more complex applications solve a wider range of business problems that entail multiple steps, richer data structures, and human inter- faces. Order entry applications are a prime example of such applications. However, the demand for more complex computing strained the economic viability of machine-centric computing. From Assembly to 3GLs Assembly language programmers, although freed from the tedium of 1s and 0s, still programmed directly in terms of the native instruction set of the processor. The native instruction set is a very low-level set of concepts. A rou- tine to simply read an employee’s monthly salary from a table, read a few tax percentages from another table, and calculate the amount of the check to be issued could require hundreds of instructions, each a separate line in a hand- coded assembly language program. The advent of third-generation languages (3GLs) enabled a big productivity jump. Even the earliest 3GLs, such as FORTRAN and COBOL, raised the abstraction level far above the concepts of the processor instruction set. The developer now programmed with much higher-level constructs. A simple PRINT instruction in FORTRAN replaced tens or even hundreds of lines of assembly code. Language compilers translated the higher-level instructions into native processor instructions, which were now informally called machine code. The ability to program a piece of logic by writing a few instructions instead of dozens dramatically increased programmer productivity, and thus drove down production costs. It also allowed “mere mortals,” such as certain classes of business analysts, to migrate into programming. Assembly Language 1s and 0s Raising the abstraction level improves the viability variables • Cost of Production • Longevity • Quality 6 Chapter 1 T E A M F L Y Team-Fly®
- 35. Initially some programmers legitimately complained that, when the com- piler translated 3GL constructs into machine code, the result was less optimal than the machine code they could write by hand. In addition, early compilers occasionally introduced errors when translating 3GL code into machine code. Over time, though, the productivity improvement more than offset these prob- lems. Machine cycles were becoming cheaper. Programmer labor was, if any- thing, becoming more expensive. The use of 3GLs to produce somewhat less optimal programs essentially offloaded some of the computing burden from expensive programmers to inexpensive machine resources. Improvements in compiler technology also gradually made it possible to generate more reliable and more optimal machine code. New structured 3GLs, such as C and Pascal, introduced even more power- ful programming models. System vendors began to use 3GLs instead of assembly language even to define operating system services. Source-level debuggers were particularly important in promoting the transition to 3GLs because they made it possible for programmers to think entirely in terms of the programming models defined by the 3GLs. Gradually, programmers let go of their reliance on assembly language. The big reduction in the number of lines of handwritten code required to automate business functions also improved the quality of computer programs. They became more intellectually manageable. The opportunity for subtle error is greater when you have to write dozens of instructions for some purpose, as opposed to just a few. 3GLs also increased program longevity. The instructions used in 3GL pro- grams were far removed from the minutiae of the native processor instruction set. If a change in hardware brought in a new processor with a different instruction set, a new compiler could process an unchanged (or minimally changed), preexisting 3GL program and generate machine code targeted to the new hardware. Changes in processor architecture no longer made programs obsolete. The ability to retarget 3GL programs to different processors became known as portability. At first portability, while nice in theory, was shaky in practice. However, over time, 3GL standards and tools matured and port- ability became a practical—if somewhat imperfect—reality. Once again, all three of the viability variables changed in the right direction. A large reservoir of pent-up demand for application development was tapped. Whole new classes of applications became economically viable. It was possible to write more ambitious programs that would have been prohibitively mas- sive in assembly language. Companies below the top tier could now comput- erize some of their operations, a trend that was reinforced by plunging hardware costs. Well before the end of the twentieth century, most, if not all, medium and large businesses had software applications managing at least some of their basic business operations and providing management decision support. Many small businesses were computerized as well. See Figure 1.3. Pressure and Progress: How We Arrived at This Point 7
- 36. Figure 1.3 3GLs further raised the level of abstraction. Operating Systems and the Abstraction Gap Whereas 3GLs raised the level of abstraction of the programming environment, operating systems raised the level of abstraction of the computing platform. If a 3GL compiler has to produce detailed machine code for routine functions such as disk and display manipulation, its job is harder than if it can simply generate machine code that invokes operating system disk and display services. Thus, by raising the level of abstraction of the computing platform, operat- ing systems reduced the abstraction gap between 3GLs and the platform, as Figure 1.4 depicts. Object-Oriented Languages and Virtual Machines Inevitably, as demand for complex features and quick time to market increased, viability problems began to surface with application-centric com- puting, spurring efforts to improve development methods. The result was sev- eral important incremental improvements that extended the lifetime of application-centric computing. Structured 3GLs evolved into object-oriented 3GLs, including Smalltalk and C++. These new languages make it easier to reuse parts of programs in differ- ent contexts. Some object-oriented languages introduce an interpreter called a virtual machine that executes intermediate code generated by the language compiler. Smalltalk, Java, and C# are the prime examples of such languages. The intermediate code is processor- and operating-system-independent. Thus, implementing the virtual machine over different processors and operating systems makes it possible to port even the compiled form of applications to different computing environments. The greater portability improves application longevity. Assembly Language 3GLs 1s and 0s Level of Abstraction 8 Chapter 1
- 37. Figure 1.4 Operating systems narrowed the abstraction gap. Enterprise-Centric Computing Over time the expectations of the degree of automation that computing could achieve continued to increase. It was no longer enough to have islands of automation within the enterprise. The various islands had overlapping func- tionality that duplicated information and applied scarce resources to solve similar problems multiple times. It became necessary to integrate the islands across the enterprise. Component-Based Development Component-Based Development (CBD) draws on lessons learned from indus- trial production processes, promoting a world where applications are assem- bled from interchangeable components. Componentization moves the production process away from reinventing the same solution in different applications, thus improving productivity and decreasing the cost of production. Componentization also tends to improve quality because it isolates functionality, allowing a team to debug and upgrade the functionality in one place. Machine Code //3GL Source Code ... ... ... Machine Code with Operating System Level of Abstraction Compiler Pressure and Progress: How We Arrived at This Point 9
- 38. There isn’t complete agreement in the software industry on the exact defini- tion of component, but usually the term refers to a software module that can be packaged in compiled form so that it can be independently deployed as part of applications or assembled into larger components. In manufacturing industries, manufacturers of finished products produce required components or purchase them from a third party. The ability to use standardized components in different products was one of the prime drivers of the industrial revolution. CBD, which is still maturing, presages another kind of industrial revolution, one that applies to the production of software. Large companies can afford to build some components themselves while purchasing some from component vendors, while smaller companies are more apt to purchase all or most of the components they use. A detailed discussion of CBD is beyond the scope of this book. An important book by Peter Herzum and Oliver Sims, entitled Business Component Factory,2 defines many important CBD concepts that I leverage in this book. I refer to their approach as Herzum-Sims. Design Patterns The concept of design patterns, which is also a key element of industrial pro- duction processes, has made an important contribution to improving software development productivity and quality. Programmers can reuse common design patterns that others have thought through and validated. Generic reusable patterns have been published3 as well as patterns specific to certain platforms such as Java 2 Platform Enterprise Edition (J2EE).4 For example, the J2EE BluePrints Value Object pattern5 supports efficient information exchange with distributed components. Imagine a distributed component that has multiple attributes including the customer ID, first name, last name, address, Social Security number, and so on. Because remote invoca- tion over a network is expensive, it’s inefficient to simply provide remote get and set operations for each property. The Value Object pattern uses a Value Object that contains get and set operations for each attribute and a façade object that provides a remote operation to get a Value Object, thus making it possible to retrieve the values of all of the properties with one remote call. The façade object also provides a remote operation to set—that is, to pass in—a Value Object, thus making it possible to set the values of all of the properties with one remote call (see Figure 1.5). 10 Chapter 1 2 [HS 2000] 3 [GHJV 1995] 4 [ACM 2001] 5 [JVO]
- 39. Figure 1.5 Using the Value Object design pattern to set attributes. Distributed Computing The earliest computers could run only a single job at a time, with any given job single-handedly controlling all of the resources of the computer. Soon multi- tasking operating systems were invented that allowed multiple jobs to run concurrently, each job running in a separate partition. These partitions evolved to provide each job with the illusion that it controlled a whole logical com- puter, a precursor to the virtual machine notion described earlier. This allowed many programs to time-share expensive hardware resources cost-effectively, without generating direct conflicts. A related approach, multiuser computing, allowed the computer to simultaneously control many input-output devices, and to manage the interaction of such devices with the time-sharing programs. Initially, the management of multitasking and multiuser configurations, no matter how complex or physically distributed, was under the total control of a single operating system on a central computer—the master—while all other processing nodes acted as slaves. However, over time it became clear that much of this processing could be off-loaded to satellite processors closer to the user, allowing for a more efficient use of computing resources and communication bandwidth. This approach, generally called distributed computing, became even more attractive with the advent of the personal computer, which brought cheap processing power right to the desktop of the user. A particular form of distributed computing called client-server computing allowed the central computer to act as a server to a PC client. Most early client-server systems perpetuated the master-slave relationship, with the server acting as master, and the PC as a very smart slave terminal. Over time, client- server computing has gradually been evolving towards a more peer-to-peer Client ‚ ‚ 1. Client sets attribute values on value object via local invocations 2. Client passes value object to facade object via remote invocation 1. Local Invocations 2. Remote Invocation Facade Object Value Object Pressure and Progress: How We Arrived at This Point 11
- 40. paradigm, allowing any node to act as either a client or server, depending on the context. Middleware: Raising the Platform Abstraction Level Initially, distributed computing of all kinds was mostly handled on a propri- etary or custom basis, using private messaging systems to communicate between processors over low-level network protocols. Gradually, many of these proprietary systems were replaced by general-purpose systems gener- ally known as middleware, so named because it sat in the middle, transparently connecting a variety of different platforms and operating systems. Initially, middleware was viewed as just a way to generalize communica- tions at a logical level a bit above low-level network protocols, a system totally subservient to the operating systems and applications running on the plat- forms it connected. However, it soon became clear that middleware could also take over many of the functions of coordinating the activities among proces- sors that previously had to be handled ad hoc by each application. As distrib- uted computing has become more important, especially with the advent of the Internet, middleware has gradually been assuming the role of a distributed operating system that controls many of the activities of the computers it con- nects. As such, it now provides a computing abstraction level well above that of traditional operating systems. CORBA, J2EE, .NET, and message-oriented middleware (MOM) are impor- tant examples of middleware platforms that provide services more powerful than those of any particular computer’s operating system. Middleware makes it possible for application programmers to concentrate more on business logic and less on the details of how to provide capabilities such as messaging, trans- action control, security, and so on. Two important ways that applications leverage middleware are: Invoking services directly via middleware APIs. For example, the Java Authentication and Authorization Service provides services that applica- tions can invoke to authenticate a user. Using code generators that middleware platforms provide. For example, CORBA products generate code from declarations of object interfaces expressed in Interface Definition Language (IDL). The generated code supports distribution but does not constitute complete applications. Some middleware supports component-based development by providing an infrastructure and development approach for producing components. Enterprise Java Beans (EJB), .NET, and the CORBA Component Model fall into this category and specifically support developing distributed components. 12 Chapter 1
- 41. Middleware: Raising the Programming Abstraction Level Some middleware has an additional function, namely to provide services that are not dependent on any particular operating system or programming lan- guage. Indeed this was one of the purposes of CORBA. For example, the CORBA Concurrency Service provides an API that appli- cations can invoke in order to obtain and release a lock on a resource. The Con- currency Service is not more powerful than similar services that operating systems supply, but it can be implemented over a variety of operating systems. Applications that use the Concurrency Service are more portable—and thus potentially have greater longevity—than ones that use operating-system- specific concurrency services. CORBA provides a measure of programming language independence by allowing two programs written in different 3GLs, such as Java and C++, to communicate with each other in a well-defined manner. The degree of inter- operability thus achieved also tends to improve longevity because it lowers the likelihood that an object developed in one language will have to be rewrit- ten in order to function in an environment dominated by objects developed in other languages. By raising the level of abstraction above the 3GL and operating system, CORBA made a modest but tangible improvement in the longevity variable. Microsoft’s COM middleware also provided a measure of language indepen- dence via its own interface definition language, Microsoft IDL, but it was not operating-system-independent. Declarative Specification Declarative specification involves programming a system by setting the values of properties. It contrasts with imperative specification, which involves pro- gramming a system via sequential, procedural instructions. Declarative programming improves productivity and quality because it is another form of reuse of preprogrammed, prevalidated logic. It has been in use for some time to reduce the labor intensiveness of producing database systems and graphical user interfaces (GUIs). Sophisticated database systems are an integral part of enterprise computing. When we need a new database, we no longer code all of the logic of the data- base imperatively. Instead, we declaratively describe the formats of the various records. The database system uses these declarations to manage the database, allowing us to fine-tune the database via stored procedures and triggers. Similarly, there was a time when a programmer had to code a graphical user interface (GUI) dialog entirely via laborious procedural instructions. Tools came along that allowed the programmer to simply draw a picture of the Pressure and Progress: How We Arrived at This Point 13
- 42. dialog, whereupon the tool would generate the bulk of the code for displaying and managing the dialog, with the programmer enhancing the generated code to produce the finished product. The tools for drawing the GUIs were called WYSIWYG (What You See Is What You Get) editors. With EJB, .NET, and the CORBA Component Model, a descriptor contains declarations of various properties of a component. The middleware acts in accordance with the property declarations. For example, in order for a compo- nent to support ACID6 transactions, a programmer need only declare such support in the descriptor, rather than write a set of procedural instructions to support transactional behavior. The middleware takes care of the rest. We can classify two basic modes for processing declarations: Code generation. In this mode, the declarations drive a 3GL code generator. GUI development environments that generate code from a WYSIWYG declaration of GUI properties are an example. Runtime interpretation. In this mode, precompiled, predeployed executable code interprets the declarations at runtime. For example, a database engine does not generate new 3GL code when handed a new declarative data model. Instead, the database engine more or less interprets the model at runtime. Enterprise Architecture and Separation of Concerns Software architecture seeks to organize complex systems by separating con- cerns. Separating concerns tends to localize changes to one aspect of a system. When changes to one aspect do impact other aspects, separation of concerns makes it easier to trace the impact. Separating concerns tends to have a positive effect on the viability variables. The localization of changes makes systems less brittle and thus improves their longevity. Once an architecture and a supporting infrastructure are in place, such localization also improves productivity because change can be effected more rapidly. Traceability tends to improve quality. Multitiered architecture is one of the most well-known and widely accepted architectural approaches for distributed enterprise systems. Nevertheless, there is some variance in the industry with regard to the number of tiers, and the names and roles of the tiers. Since I use the concepts of multitiered archi- tecture later in the book, it’s worth spelling out the concepts and terminology that I employ. 14 Chapter 1 6 ACID transactions are atomic, consistent, isolated, and durable. See [GR 1993] for a definitive work on the subject.
- 43. As discussed above, corporate computing systems were originally located entirely on centralized mainframe computers. The terminals on users’ desk- tops were dumb slaves; that is, they had only the minimal processing power necessary to support display and entry functions (see Figure 1.6), under the strict control of the central master. Client-server architects separated concerns by relegating mainframes to database management while shifting display of the data—and business logic using the data—to client PCs, as illustrated by Figure 1.7. Local servers con- nected to groups of PCs via LANs held client-side code files and even some databases that were special to the concerns of local groups. The industry began moving from two-tier client-server architecture to three- tier architecture because it recognized that programmers were coding similar business logic in multiple clients. For example, consider a client-server order entry system in which the client calls to a back-end order, inventory, and gen- eral ledger database. When the client software completes an order, it executes the following steps: 1. Add order record to the order table. 2. Relieve inventory table for the inventory items ordered. 3. Post credits to payables accounts in the general ledger table. 4. Post debits to inventory accounts in the general ledger table. Figure 1.6 One-tier architecture—all processing on centralized mainframe. Dumb Terminal Mainframe Database and Business Logic A B Means A accesses B Pressure and Progress: How We Arrived at This Point 15
- 44. Figure 1.7 Two-tier architecture—some processing off-loaded to client. Gradually the industry realized that it was inefficient to program this kind of logic over and over again for the same database tables in many different client software modules. The inefficiency was due to a failure to separate the concerns of business logic and user presentation. Business logic needed to be encapsulated so many client modules could reuse it for various business use cases. Architects started creating a new tier between the database and the client that encapsulated this kind of business logic. They called this layer by various names, including business tier, enterprise tier, and middle tier, or mid tier for short. The other tiers were called the client tier or front end and the database tier or back end. Thus, while two-tier architecture moved business logic from the mainframe to the client, three-tier moved business logic from the client to the mid tier (see Figure 1.8). Tier separation is logical separation, not necessarily physical separation. It might make sense tactically in some cases to push middle-tier objects and com- ponents to client PCs for performance reasons. However, it became increas- ingly typical to place the middle tier on a separate server machine or set of machines. The advent of the Web solidified this trend because the Web demands that all logic except the basics of user presentation be off-loaded to a remote server. Client Workstation PC CLIENT TIER User Presentation and Business Logic A B Means A accesses B SERVER TIER Database Management Mainframe DBs 16 Chapter 1 T E A M F L Y Team-Fly®
- 45. Figure 1.8 Three-tier architecture. The thin client that thus became de rigueur for Web-based Internet and intranet applications spawned a variation of three-tier architecture in which the presentation facilities of the client machine were limited to a Web browser. Some of the user interaction and presentation facilities ran on remote Web servers, which dynamically generated HTML and sent it to the client; in that sense, Web servers spanned the client tier and mid tier, as illustrated by Figure 1.9. Well-architected systems carefully separated the Web server’s GUI- oriented facilities from the mid tier’s business logic, so that many user scenarios could use the business logic. Three-tier architecture’s concept of the database tier also evolved to include various enterprise information servers that are not mainframe-based. Client Workstation PC CLIENT TIER (a.k.a. Front End) User Presentation A B Means A accesses B ENTERPRISE TIER (a.k.a. Mid Tier) Encapsulated Business Logic Servers DATABASE TIER (a.k.a. Back End) Mainframe DBs DBs on other servers Pressure and Progress: How We Arrived at This Point 17
- 46. Figure 1.9 Three-tier architecture—thin client. Three-tier architecture was a significant improvement over two-tier. How- ever, architects and developers began to recognize that it had a limitation, namely its failure to separate business logic that involves interaction with the end user from business logic that is independent of user interaction. Consider, for example, our order/inventory system now converted to three- tier architecture. The logic of interaction with the end user for one line item of an order might be: 1. Ask user to specify item desired. 2. Access database to get availability and price. 3. If unavailable, tell user. 4. If available, show user the price and give user the option to accept or reject. 5. If user accepts, call database to add a line item to the order. Client Workstation CLIENT TIER User Presentation A B Means A accesses B ENTERPRISE TIER Encapsulated Business Logic Servers DATABASE TIER Mainframe DBs DBs on other servers Web Servers (Including Servlets) Internet or Intranet 18 Chapter 1
- 47. Through the lessons of experience, architects began to realize that systems would be more scalable if the business logic that involves user interaction were separated from other business logic. Thus the mid tier was split into two tiers that separated these concerns: the workspace tier and the enterprise tier. The workspace tier is responsible for executing the logic of the pattern of inter- action with the user. The interaction logic accesses the enterprise tier rather than going directly to the database. Oliver Sims has been advocating four-tier architecture for the better part of a decade.7 Herzum-Sims calls the four tiers user tier, workspace tier, enterprise tier, and resource tier, as Figure 1.10 illustrates. The figure also points out alter- nate names that some practitioners use for the tiers. Figure 1.10 Four-tier enterprise architecture. A B Means A accesses B USER TIER (a.k.a. Client Tier) User Presentation WORKSPACE TIER (a.k.a. Interaction Tier) User Interaction Logic Servers ENTERPRISE TIER (a.k.a. Business Tier) Encapsulated Business Logic Servers RESOURCE TIER (a.k.a. Integration Tier) Mainframe DBs DBs on other servers Resource Adapters (e.g. Object-Relational Mappings) Pressure and Progress: How We Arrived at This Point 19 7 See [HS 2000] for his most recent work on this subject.
- 48. The Herzum-Sims notion of a business component is a component com- posed of smaller components that are specific to individual tiers. A business component thus spans one or more tiers and can cover presentation, inter- action, business logic, and data. An order entry component, for example, contains components that handle presentation, interaction, and so on for order entry. Note that the Herzum-Sims resource tier is not quite the same as the data- base tier from three-tier systems. Instead, it represents the logic that provides the bridge between the enterprise tier and databases. Business components interact with but don’t include databases, which is why Herzum-Sims does not define a tier to encompass databases. However, some enterprise architec- tures define the resource tier as including databases, while calling the tier that contains adapters the integration tier. Some practitioners define distinct tiers that separate client-side user interaction logic from server-side interaction logic handled by technology such as Java servlets. In any case, multitiered enterprise architecture plays an important role in managing the complexity of distributed enterprise systems. The separation of different concerns in logical tiers promotes the reuse of data and logic and thus improves development productivity and quality. There is more to enterprise architecture than organization by logical dis- tribution tiers. For example, enterprise architecture also leverages middle- ware, layering the various tiers over middleware so as to minimize the degree to which basic functionality required by the tiers has to be pro- grammed over and over again. There is middleware that supports GUI development, such as windows frameworks. There is middleware that sup- ports the development of the workspace tier, such as J2EE servlets and analogous .NET technology. There is middleware that supports ACID trans- actions in the enterprise tier, such as the Java Transaction Service and .NET transaction support. There is also middleware that supports object-relational mapping for the resource tier. Layering the tiers over middleware separates concerns into (1) aspects of the system that application programmers must deal with and (2) aspects that infrastructure handles. Oliver Sims uses the analogy of a water line to describe this separation of concerns, designating the aspects of a system that the pro- grammer sees as above the line and aspects that the middleware infrastructure handles as below the line. In Figure 1.11 you can see that middleware implementations that do much heavy lifting for the application programmer are below the line, while only the APIs to middleware services and middleware configuration languages surface above the line. 3GLs have aspects above and aspects below the line. Figure 1.11 does not exhaustively categorize all of the elements of an enterprise system along the water line. Other development tools have above- and below-the-line aspects, and development methodologies do as well. 20 Chapter 1
- 49. Discovering Diverse Content Through Random Scribd Documents
- 50. Toby nodded agreement. “I’d sure like it,” he muttered. “Isn’t there any way to earn that much?” pursued Arnold. “Look here, couldn’t you do anything with this launch? Couldn’t you sell her for something?” Toby looked startled. “I hadn’t thought of that,” he said slowly. “She wouldn’t fetch much, though. Besides, you can buy plenty of second-hand launches around here. They are as thick as blackberries. Maybe—maybe I’ll think of some way, though. I—I’ve sort of made up my mind to go to that Yardley Hall place, Arn, and when I make up my mind I most always get what I’m after. It’s funny, but that’s the way it is.” “Well, then, you make up your mind hard!” laughed Arnold. “And I’ll make up mine hard, too. And—and maybe it’ll really happen!” “Maybe. Sometimes it seems to me as if when you want a thing you’ve just got to set your mind on it and—and steer right straight for it, and you’ll get it. I don’t suppose it always happens like that, but pretty often it does. You’ve got to sort of concentrate, Arn; forget other things and pick up your marks and—and keep your course mighty steady.” Toby drew up his empty hook and began reeling the line. “Anyway, I’m going to try it.” For the next several days Toby had queer periods of thoughtfulness, going off into trances without warning and quite alarming Arnold, who feared, or professed to fear, that his chum’s mind was giving way. “It’s having all that money to think about,” declared Arnold. “If you’d only spend it for something it wouldn’t worry you.” “As long as that bank doesn’t bust,” answered the other, “I’m not troubling about the money. Your father said it was a very safe bank, didn’t he?” “Safe as any of them,” teased Arnold, “but, of course, you never can tell when the cashier or—or some one will take it into his head to start off to Canada!”
- 51. “Huh! They fetch ’em back now,” said Toby. “That doesn’t scare me. Dad says I might have put it in the postoffice, though.” “Buy stamps with it?” asked Arnold in a puzzled voice. “No, put it in the Postal Savings Bank. The government looks after it for you then, and I guess the government would be pretty safe, eh?” “So’s that bank you’ve got it in. If it wasn’t safe do you suppose father would keep money in it?” “N-no, I guess not. I wouldn’t want to lose that hundred and fifty though. I—I’ve got a use for that!” “Have you asked your father about Yardley yet?” Toby shook his head. “I thought I’d better wait until I had some more. Only thing is”—he frowned deeply—“I don’t know how to get any more! I’ve been thinking and thinking!” “Oh, well, there’s lots of time yet. Come on down to the shed and see how the boat’s getting along.” The knockabout was coming fast and Arnold never tired of watching Mr. Tucker and “Long Tim” and “Shorty” at work. Long Tim’s full name was Timothy Tenney. He stood fully six feet three inches tall when he straightened up, but that was seldom since the bending over to his work for some forty-odd years had put a perceptible stoop to his shoulders. Long Tim was thin and angular and weather beaten, with a fringe of grizzled whiskers from ear to ear, and very little in the way of hair above the whiskers. He loved to talk, and was a mine of strange, even unbelievable information which he was quite ready to impart in his nasal drawl. “Shorty” was Joe Cross, a small, square chunk of a man who had come ashore years before from a Newfoundland lumber schooner and had forgotten to return until the schooner had sailed again. Shorty had a family somewhere in Canada, and was forever threatening to go back to it, but never got further than New York. Long Tim came from a family of boat-builders, but Shorty had learned the trade under Mr.
- 52. Tucker. Both were capable workmen, although Long Tim looked on Shorty as still merely an apprentice, and shook his head dolefully when he was entrusted with any more particular task than driving a nail. If Arnold could have had his way he would have spent most of his waking hours sitting in the boat shed with his feet in sawdust and shavings and auger chips watching the knockabout grow and listening to the ceaseless drawling of Long Tim. But Toby wasn’t satisfied to dawdle like that and hailed Arnold off to various more lively occupations. Several afternoons during the next ten days were spent by Arnold, none too enthusiastically, in practicing ball with the Spanish Head team in preparation for that approaching game. Toby, too, put in a little time in a similar way, but the trouble with Toby’s team was that it was impossible to get all the fellows together at the same time. Usually they were shy from one to four players and were forced to fill up the ranks with such volunteers as were on hand. Arnold brought stirring tales of practice over at the Head and predicted overwhelming victory for his nine. But Toby refused to become alarmed. The Towners had won once, and he believed they could do it again. Even if they couldn’t there was still no harm done. Baseball was only baseball and some one had to lose! It was on a Wednesday, just a week after that first contest, that Toby stood on the town landing float and waited for Arnold to come over from the Head in the Frolic. At low tide it was finicky work getting up to the boat-yard pier, and Arnold tied up at the town float instead. The hour was still early, for in the Tucker cottage breakfast was at six-thirty in summer, and Toby had cleaned the spark-plug on the Turnover, mended a window screen, walked to the grocery store and back on an errand, and reached the landing, and, behind him, the clock in the church tower showed the time to be still well short of eight. Arnold had promised to come across early, however, since they had planned to run up to Riverport and get some hardware for the knockabout which was waiting for them at the freight depot. Save that Toby was seated across the bow of a dory instead of on a
- 53. box, he presented much the same appearance as at our first meeting with him. Perhaps his skin was a little deeper brown, and perhaps, as he gazed again across the harbor and bay, his face was a trifle more thoughtful—or his thoughtfulness a bit more earnest. And he was whistling a new tune under his breath, something that Phebe had of late been playing incessantly on the old-fashioned square piano in the cottage parlor. The harbor was quiet and almost deserted. On a black sloop, moored well off the landing, a man was busy with pail and swab, but, excepting for the gulls, he was the only moving thing in sight until footsteps sounded on the pier above and a man descended the gangplank. He was a middle-aged man in a suit of blue serge and square-toed shoes, and he carried a brown leather satchel. He looked like a person in a hurry, Toby concluded, although there was no apparent reason for his hurry. He looked impatiently about the float and then at Toby. “Isn’t there a ferry here?” he demanded. “No, sir. Where do you want to go?” “Johnstown. I thought there was a ferry over there. I was told there was.” He viewed Toby accusingly. Toby shook his head. “There used to be, sir, about six years ago, but the man who ran it died, and——” “Great Scott! Do you mean to tell me that I’ve got to go way around by Riverport? Why, that’ll take me two hours! And I’ve got an appointment there at nine! What sort of a place is this, anyway? No ferry! No place to get any breakfast! No—no——!” he sputtered angrily. “I guess it’ll take most of two hours by carriage,” agreed Toby, “but I can put you over there by eight-thirty, sir.” “You’ve got a boat?” “Yes, sir, but——”
- 54. “Where is it?” The stranger’s gaze swept over the bobbing craft. “I suppose it’s a sailboat and we’ll drift around out there half the morning. Well, I’ll try it. Good gracious, only seventy miles from the city and no—no accommodations of any sort! No place to eat, no ferry——” “Yes, sir, we’re sort of slow around here,” agreed Toby, calmly. “Slow! I should say you were slow! Well, where’s the boat? Bring it along! There’s no time to waste, young fellow!” “Well, if you don’t have to be there before nine”—Toby looked over his shoulder at the church clock—“you’ve got plenty of time to have some breakfast before we start. It’s only three miles across and I’ve got a launch that’ll do it in twenty minutes easy.” “Launch, eh? That’s better! Show me where I can get a cup of coffee then. I haven’t had anything to eat since last night. I left Southampton at six and there wasn’t time. Got a restaurant here somewhere, have you?” “Not exactly a restaurant,” replied Toby, “but if you’ll come with me I’ll show you where you can get some coffee and bread and butter. The launch is over there, anyway, so it won’t take much longer.” “Look ahead, then,” said the man. “I’ll go most anywhere for a cup of coffee!” The prospect of food seemed to better his humor, for all the way up the landing and around the road to the cottage he asked questions and conversed quite jovially. When, however, he discovered that the boy had led him to his home he was all for backing down. “It’s very kind of you,” he said, “but I wouldn’t want to bother any one to make coffee for me. I’ll wait till I get to Johnstown.” “It won’t be any trouble, sir, and my mother will be glad to do it. Gee, she’d like it if I’d bring some one around to be fed every day! Please, come right in, sir, and sit down, and mother’ll have something ready for you in no time.”
- 55. Hesitatingly, the stranger allowed himself to be conducted up the steps and into the sitting room, and Toby went to the kitchen and acquainted his mother with the needs of the occasion, producing in Mrs. Tucker a fine flurry of excitement and an enthusiastic delight. Ten minutes later, refreshed and grateful, the stranger—he had introduced himself as Mr. Whitney of New York—followed Toby through the yard, down the slippery ladder, and into the Turnover. If he felt dubious about trusting himself to that craft and to Toby’s seamanship, he made no sign. Toby cast off and then faced his passenger. “I guess,” he announced, “we’d ought to agree on a price before we start, sir.” “Eh? Oh, yes! Well, you’ve got me where I can’t say much, young fellow. Just be easy and there won’t be any kick from me. What’s the damage going to be?” “Well, sir, it’s three miles over there, and gasoline’s worth twenty- three cents this week, and——” “Don’t frighten me to death!” laughed the man. “Will five dollars do the trick?” “Five dollars!” Toby gasped. “Not enough? Call it seven-fifty then.” “It’s too much! Why, a dollar—or maybe, a dollar and a half——” The stranger laughed loudly. “Go ahead, then! But you’ll never be a millionaire if you do business that way. When any one offers you five dollars, young fellow, it’s poor business to take less.” Toby smiled as he put the handle in the fly-wheel. “Seems to me, sir,” he said, “it’s just as poor business to offer five dollars when the job’s only worth a dollar and a half!” “Well, that’s right, too!” The man chuckled. “Maybe that’s why I’m not a millionaire yet. Want me to do anything in the way of steering?”
- 56. “No, sir, thanks. I’ll steer from here.” The Turnover backed away from the pier, turned and crept out of the narrow channel, across the cove and into the harbor. Half-way to the entrance they passed a surprised Arnold at the wheel of the Frolic and Toby called across to him that he would be back about a quarter past nine. Arnold nodded and waved and the white launch and the gray swept past each other. The passenger came forward and made himself comfortable opposite Toby as the Turnover pointed her nose across the bay. In the course of the conversation that ensued above the clatter of the little engine Toby learned that Mr. Whitney was a contractor and that he was going to Johnstown to consult with a man about building a cottage there. “I’m doing some work at Southampton,” he explained, “and it’s going to be awkward for a while getting from one place to the other. Guess I’ll have to buy me one of these things, eh? Unless—look here, want to arrange to take me back and forth now and then? I’ll pay you three dollars the round trip.” “Yes, sir, I’d be glad to,” agreed Toby eagerly. “When would you want to go again?” “I don’t know that yet. This little tub seems pretty seaworthy. Run her a good deal, have you?” “Yes, sir, and others before her. She isn’t much to look at, but she’s a good boat.” “What do you call her?” “The Turnover.” “The which?” “Turnover, sir,” repeated Toby, smiling. “Well, that’s a pleasant, reassuring sort of name for a launch! Does she—does she do it—often?” “No, sir, she’s never done it yet,” laughed Toby. “You can’t tell much by names, Mr. Whitney.”
- 57. “H’m; well, I’m glad to hear it. I was thinking that maybe we’d better call that bargain off! Is that the landing ahead there?” “Yes, sir. We’ll be in in a minute or two.” “I suppose you get mail in Greenhaven? Well, I’ll drop you a line some day soon and tell you when I’ll be along next. Let me see, what’s your name?” “Tucker, sir; T. Tucker.” “T? For Thomas?” “N-no, sir; for Tobias; Toby for short.” “I see! Toby Tucker, Greenhaven, Long Island.” Mr. Whitney set the address down in a memorandum book. “All right, Toby, you’ll hear from me.” He replaced the little book in a vest pocket and pulled out a wallet. “Now, we’ll settle up for the present trip and start fair the next time.” He took a five-dollar bill from the purse and handed it across. “I—I can’t change that, sir,” said Toby. “You can let it go until next time.” “I don’t want you to change it, Toby. I guess five isn’t too much for that breakfast and this trip. It’s worth it to me, anyway.” “There isn’t any charge for breakfast,” Toby protested. “Well, then, we’ll call it a bonus on the contract. Stick it in your pocket, young fellow, and don’t look as if it was poison.” “But it’s a lot more than it ought to be,” stammered Toby. “Don’t you worry about that,” laughed the man. “It’s worth ten times five dollars to me to get here on time. Here we are! Much obliged to you, Tobias. See you again. Good-by!” Mr. Whitney, bag in hand, jumped nimbly to the float, waved a hand, and hurried away, leaving Toby the happy possessor of the magnificent sum of five dollars, a beatific prospect of more, and a wonderful idea!
- 59. T CHAPTER XII “T. TUCKER, PROP.” he wonderful idea he explained to Arnold as, half an hour later, they started off in the Frolic for Riverport. “What he said about the ferry put it in my head,” said Toby. “There used to be a ferry across to Johnstown five or six years ago. I guess there weren’t many passengers then, but it must have paid or else old Captain Gould wouldn’t have run it so long. And it seems to me there’d be more folks wanting to get across now than there was then. Why, six years ago there wasn’t a half dozen summer cottages around Greenhaven. And the hotel at Johnstown wasn’t built, either. I guess if folks knew there was a regular ferry across they’d use it. Don’t it seem so to you, Arn?” “Sure! But would the Turnover be big enough, Toby?” “She’ll hold eight without crowding, and I guess if I ever get eight folks at once I’ll be pretty lucky.” “How much would you charge?” “Fifty cents,” replied Toby promptly. “Do you think that’s too much? I could make a round trip rate of seventy-five, maybe.” “No, fifty cents isn’t much for a three-mile trip. How often would you make it?” “Four times a day, twice in the morning and twice in the afternoon. I could leave here at nine, say, and come back at ten. Then I could go over again at eleven, two, and four. Even if I carried only four passengers a day it would be two dollars, and that would make twelve dollars a week. And there’s twelve weeks yet, and that would be a hundred and forty-four dollars!”
- 60. “You’ve got to think about gas and oil, though, Toby.” “That’s so! Well, gas would cost me about twenty cents a day, and oil—say, five, although it wouldn’t come to so much. That would make it a dollar and seventy-five cents instead of two, wouldn’t it? How much would I have at the end of the summer?” Arnold did some mental arithmetic and announced the result as a hundred and twenty-six dollars. “But you’d ought to get more than four passengers a day, Toby, after folks heard about it. You could put up notices, couldn’t you?” “Yes, and I’d have a sign on the landing, and——” he paused and frowned. “I wonder if they’d make me pay for using the town landing. They might, you know.” “I don’t see why. It would be a—a public accommodation!” “I can find out. Anyway, they couldn’t ask much, I guess.” “If I were you I’d change the name of your launch, though,” Arnold advised. “Ladies might feel sort of—of nervous about going in a boat with a name like that.” “What would you call her?” asked Toby, dubiously. “Changing the name might change the luck, and my luck’s been pretty good lately.” “I don’t know. You could find another name all right. Say, Toby, why couldn’t I come in on it? I wouldn’t want any of the money, of course, but we could use the Frolic any time we had a lot of passengers. Would you mind if I helped?” “No, I’d be awfully glad to have you, only—do you think your father would want you to?” “He wouldn’t mind. I’ll ask him tonight. I could bring this boat over in the morning and then we could use whichever one we wanted to. Maybe if there were ladies going over they’d rather go in the Frolic.” “I guess maybe they would,” laughed Toby. “But there wouldn’t be many ladies, probably. I suppose if I took other folks over to
- 61. Johnstown for fifty cents I couldn’t ask Mr. Whitney to pay any more, could I?” “Why not? He made a bargain with you, didn’t he? If you got a dollar and a half from him, besides what you made from other people——” But Toby shook his head. “It wouldn’t be fair. I’d ask him the same as the rest. Only, maybe there won’t be any rest. It wouldn’t do any harm to try it for a couple of weeks, though, eh? And it might turn out fine!” “It will! I’ll bet there’s lots of folks over at the Head who’d be mighty glad to get over to Johnstown if they didn’t have to go all around by road. Why, it must be ten or twelve miles by the road!” All the way up the river to the landing at Riverport, all the way to the freight house, all the way back, laden with a forty-pound box of yacht hardware, and all the way home again they talked over the ferry scheme, Arnold becoming even more enthusiastic than Toby. They developed the plan until, in their imaginations, they could see a whole flotilla of ferryboats crossing the bay to Johnstown and Riverport and around to Shinnecock and even as far as Mattituck! And real ferryboats, too; fine white and gold cabin launches holding as many as thirty persons! And Toby was to stand at the wheel and navigate while Arnold, in a resplendent white duck suit and cap with crossed anchors on it was to collect the fares! The only thing that worried Arnold was that he would be so busy helping Toby operate the ferry line that he wouldn’t have time to use the new knockabout. But Toby brought partial consolation by pointing out that there’d be time, between trips, maybe, and that, anyway, they’d have the evenings. Even baseball went to the discard for the rest of that week, so busy were they planning and perfecting the new ferry service. Frank Lamson, whose one desire just then was to wreak vengeance on the town ball team, threatened mutiny, declaring that if Arnold didn’t call practice and attend it he and the other members of the Spanish Head team would take affairs into
- 62. their own hands and elect a new captain. Arnold managed to put him off until Monday, however, and by that time “Tucker’s Ferry Line” was about ready for business. Toby had decided to wait until Thursday before starting the service in order to play that ball game on Wednesday. Arnold would have canceled it willingly, but Toby declared that it wouldn’t be fair to the fellows who had joined his team, and practiced more or less faithfully, to disband without at least one more game. “After Wednesday I’ll tell them I can’t play any more and then they can choose another captain and keep on if they want to. Maybe if the ferry doesn’t succeed we can have some more games. It wouldn’t interfere with your playing, Arn, because we wouldn’t both have to attend to the ferry.” But Arnold denied that vigorously. “I’m going to do my full share of the work,” he declared. “Besides, I can play baseball most any time. Those fellows can find a new captain, if they like, and go on playing. I guess Frank will be glad to take the job. He doesn’t much like the way I’m doing it, anyway,” he concluded with a laugh. On Friday, Long Tim, painter as well as carpenter, planed down a four-foot pine plank after hours, sandpapered it, braided a small half-round along the edges, and covered the whole with a priming coat of white paint. And then, the following evening, while Toby and Arnold stood over him, breathless and admiring, he traced out the inscription “Johnstown Ferry,” filled in the letters with black, put another coat of white on the remainder of the surface, and finally finished up by placing a black border around all. The boys viewed the result with enthusiastic approval and sighed with regret when Long Tim turned it to the wall to dry. They found a new name for the Turnover that evening by the simple expedient of chopping off the first and last letters, and the launch became, for the summer at least, the Urnove. On Monday morning Toby parted with two dollars and a half of that precious five in exchange for fifty cardboard placards which announced startlingly:
- 63. GREENHAVEN-JOHNSTOWN FERRY Commencing Thursday, July 17, launches Frolic and Urnove will leave the town landing for Johnstown daily except Sunday at 9 and 11 A. M. and 2 and 4 P. M. Returning, leave Johnstown one-half hour later. Fare, one way, 50 cents. Round trip, 75 cents. T. Tucker, Prop. Armed with the placards, Toby and Arnold made the round of the principal stores in Greenhaven and Johnstown and saw them obligingly placed in the windows. The hotel at Johnstown was similarly honored, as was the postoffice there and in their own town. And after that they tacked the notices wherever they thought they would attract attention without entailing a penalty. The final placard —no, not the final one, either, for Arnold kept that to go up in his room at school, but the next to the last one was tacked to the side of Hawkins’ leather store at the corner of the alley that led to the landing, and, lest some one might be in doubt as to the location of the town landing, Arnold added a hand, which pointed quite dramatically down the little lane. Long Tim put the sign in place that evening. Mr. Hawkins was very complaisant, perhaps thinking that some of the patrons of the ferry might be attracted to his stock, and gave ready permission to attach the sign to the alley side of the store so that it jutted out well over the sidewalk and was visible a block away. The boys were certain of that, because they hurried along the street to a position in front of the postoffice and looked! They spent most a quarter of an hour viewing Long Tim’s handiwork from various places at various angles, and would have stayed longer if it hadn’t got dark. The question of paying for the privilege of using the landing was still unsettled. It had been left to Mr. Tucker, who was himself one of the selectmen, and Mr. Tucker reported that the other members of the board were unable to reach any conclusion in the matter and proposed postponing a decision until the next town meeting, which
- 64. was scheduled for November. Meanwhile he advised Toby to go ahead as long as no one interfered with him, which Toby did. Mr. Tucker, rather to Toby’s surprise, approved of the ferry enterprise warmly. “Likely,” he said, “you won’t make a pile of money, Toby, but it’ll keep you out of mischief and give you something to do. And I’m not saying it won’t pay, either. I guess there’s folks that’ll be glad to run over to Johnstown that way instead of driving to the Port and taking the train. What you going to do with all your wealth, Toby, anyhow? Maybe you’d like to buy into the business, eh?” Toby hesitated a minute, but it seemed a very good opportunity to tell his father of his ambition to go to Yardley Hall School, and he did so. Mr. Tucker listened without comment until Toby had somewhat breathlessly finished. Then he did what was very characteristic. He pushed back an imaginary hat—the conversation took place in the cottage one evening just before bedtime—and scratched his head thoughtfully. At last: “That’s a pile of money, son, to spend for a year’s schooling. What are you going to get out of it that you can’t get over at Johnstown? Do they teach you more things at this school you’re telling of?” “N-no, sir, not more, exactly. Maybe they do, though, too. But it’s being at a place like that that’s the fun, Dad.” “Fun, eh? Sure it isn’t just the fun you’re thinking of? Three or four hundred dollars is a sight of money to spend for fun!” “I’m not thinking of only that, Dad. I—I guess I can’t explain very well, but it’s meeting other fellows and—and making friendships and learning how to—to look after myself that I’m thinking of.” “Seems to me you could do all that at high school, Toby. And high school won’t cost more’n a fifth as much, fares and all. It’s your money and I suppose you ought to have the spending of it, so long’s you don’t spend it plumb foolishly. But what occurs to me is that this Yardley Hall place is a mighty poor place for a boy who hasn’t plenty of money. Mostly rich boys, ain’t they; those that go to it?”
- 65. “No, sir, Arnold says there are lots of fellows who aren’t rich; fellows about like me, Dad.” “H’m, well, I don’t know. We’ll think it over. What you going to do next year for money? One year won’t do you much good, I guess.” “I don’t know. Only, somehow, I’ve got a hunch that if I can get through the first year I’ll manage the others, Dad.” Mr. Tucker shook his head. “I wouldn’t put too much faith on ‘hunches,’ as you call ’em, Toby. I’ll talk to Arnold about this school some day. If it’s going to give you something the high school can’t give you, son, and you’ve got the money to pay for it, why, I don’t know as I’m going to interfere none. But you’ll have to get your ma’s consent.” Toby agreed, feeling fairly certain that he could obtain that without much difficulty, although he knew that his mother would view his absence from home with alarm and sorrow. When Phebe was told of the plan she disappointed Toby by her lack of enthusiasm at first. “You mean that you’ll be away from home for months at a time?” she asked dolorously. “Won’t you be coming home ever, Toby?” “Maybe, but I guess I couldn’t afford to come home very often even if they’d let me. Of course, I’d be home at Christmas and—and Easter.” “Christmas is a long time from September. I suppose it’ll be perfectly dandy for you, Toby, but—but I’ll be awfully lonesome!” “You wouldn’t be after awhile. I guess I’d be, too, at first. But we don’t have to worry about that, because maybe there won’t anything come of it.” But Phebe refused to be consoled so easily. She assured him that she “just felt that he would go!” And Toby, although pretending to have no faith in her premonition, secretly hoped it would prove correct.
- 67. W CHAPTER XIII TRICK FOR TRICK ednesday didn’t promise very well at first for the baseball game, for the morning dawned dark and lowery, with a thick fog rolling in from the bay. But by noon the fog-horns had ceased bellowing, the mist had burned off and the sun was out again. The audience was flatteringly large when the game began at half-past three, the Head being represented by an impressive array of cars and carriages which, after climbing the hill by a stony and devious lane, parked along the edge of the field. Mr. Trainor was again on hand to umpire, and his brother and Mrs. Trainor sat on the grass back of first base under a vividly green sunshade and poked fun at him and “rooted” enthusiastically for the Towners. Toby’s team contained a new player in the person of “Chuck” Morgan, who took Harry Glass’s place at shortstop, Harry being confined at home with the mumps. The Spaniards, too, presented a stranger in their line- up, a large youth named Phillips, who held down third base. Toby and the other Towners viewed Phillips with misgiving and some indignation, for he must have been nineteen years old if he was a day. Toby sought Arnold and registered an objection vigorously. “We didn’t agree to play with grown-ups, Arn,” he said. “We haven’t a fellow over sixteen on our team.” Arnold was apologetic. “It’s Frank’s doing, Toby,” he explained. “Sam Cushing’s away and Frank said he knew of a fellow to take his place, and I told him to get him. I didn’t know he was so old. If I had I wouldn’t have let him on. But there isn’t any one else we can get now. Still, if you say you won’t play against him, all right. Maybe we can borrow a fellow from you.”
- 68. “He looks like a pretty good player,” murmured Toby, mollified, but still dubious. “Is he?” “I don’t know much about him. I’ll ask Frank.” Frank Lamson was summoned to the conference and the question put to him. “Phillips?” replied Frank, carelessly. “No, I guess he isn’t much at baseball. He played football at Townsend School last year, but I never heard he was much of a baseball shark. Anyway, we’re only playing for fun, Toby, so what does it matter?” “Well, he’s a heap older than us fellows,” Toby objected. “It doesn’t seem quite fair, that’s all.” “You’re afraid of getting licked,” laughed Frank. “Be a sport, Toby!” “If Toby doesn’t want us to play Phillips,” began Arnold. “We haven’t any one else, though,” said Frank impatiently. “We can’t play them with only eight men!” “All right,” said Toby. “Go ahead. Maybe it won’t make any difference.” But it did make a difference, as was soon apparent. For when Tracey Gay had reached first on Tony George’s poor peg to Billy Conners, and Arnold had sacrificed him neatly to second, Phillips stepped to the plate in a knowing way, swung at Tim Chrystal’s first offering, and slammed it into deep right for two bases, scoring Gay. One more tally was added before the Towners succeeded in disposing of the third Spaniard, and that two-run lead held until the fourth inning. Then Tony George, first man up for the home team, got a scratch hit past shortstop and Gus Whelan sent him to second on a bunt, being thrown out at first. The next two men went out, and it was up to “Snub” Mooney to rescue the runner on second. This Snub did by dropping a “Texas Leaguer” behind third, Tony George getting to third on the hit and racing home when the fielder unwisely threw to second to get Snub. Snub slid into the bag unchallenged, and Tony got to the plate before the ball from second baseman reached the catcher.
- 69. But the Spaniards came back in their inning and added two more tallies, making the score 4 to 1. In the fifth the Towners went down in one, two, three style, for Frank Lamson was pitching a much better game than a fortnight before and the whole team from the Head was playing together in very snappy form. There was some improvement in the Towners as well, but they displayed an unfortunate disposition to make errors at critical times. Tim Chrystal was slanting them over in good shape, but both Phillips and George Dodson found him for long hits every time they came up. The game held more excitement than had the first contest, and Mr. Trainor, very warm and perspiring, was forced to make a number of close decisions at bases. Whenever he did so loud hoots of derision came from under the green sunshade! Mr. Trainor’s office was no sinecure that hot afternoon! It was the seventh that saw things happen. Manuel Sousa waited and got his base. Morgan laid down a bunt half-way to the pitcher’s box, and Frank juggled the ball and both runners were safe. “Snub” Mooney went out, third baseman to first, advancing the runners. Tim Chrystal, who had so far failed to connect, smashed a line drive into short center. Sousa and Morgan tallied, but Tim was out in an attempt to reach second on the throw-in. With two gone, the inning looked about over, but Toby, next up, took advantage of Frank’s momentary let-down and pushed the ball down the third base line just out of reach of the accomplished Phillips, who had so far fielded his position like a veteran—which he probably was. After that, although Frank threw to first repeatedly in an effort to catch him, Toby stole second on the third delivery, beating the throw by inches only,—but beating it. Billy Conners fouled off two strikes, watched two balls go past him, fouled another for good measure, and then landed on a drop and raised it high and far into center field. Hal Mason had scarcely to move out of his tracks to take it, but somehow he let it get away from him after it had settled into his hands, and Toby, legging it like a jack rabbit, raced around third and slid the last ten feet to the plate in a cloud of yellow dust and scored without question. Then Tubby Knowles, desperate and determined,
- 70. tried his very best to bring Billy Conners in from second but only succeeded in popping a fly to shortstop. But the score had changed to 4 to 4, and the Towners had bright visions of another victory. Tim Chrystal began badly, though, by passing Frank Lamson. Then Mason singled to left and George Dodson sent a long fly to Tubby Knowles, which that rotund youth captured after a breath-taking sprint, almost to the foul line. Frank took third and Mason reached second. Tracey Gay rolled one toward third. Frank scored and Tracey was safe at first on a wide peg by Tony George. Tracey stole and a moment later Arnold worked Tim for a pass and filled the bases with but one down. Things looked bad then for the Towners, and no better when the renowned Phillips, after a conference between Toby and Tim, was purposely passed, forcing in another tally. Then, however, Pete Lord struck out and the Spaniard’s shortstop, after knocking two screeching fouls in among the carriages and automobiles and almost producing heart failure in the Towners, popped a weak fly to Billy Conners at first, and Toby drew a deep breath of relief. The Towners came back in the eighth with another tally, making the score 6 to 5, when Manuel Sousa, with one down and Gus Whelan on second, landed on one of Frank’s fast ones and drove it far out into right field. Tracey Gay got under it and made a spectacular catch, but his throw-in was short, and by the time Arnold had got it and relayed it to the plate Gus Whelan had tallied. Try as they might, however, the Towners could not even up the score, for Chuck Morgan, after beating out a slow bunt, was caught going down to second. The Spaniards went to bat with the evident intention of putting the game on ice there and then, for First Baseman Lord connected with the first ball Tim offered him and slammed it so hard at Chuck Morgan that Chuck had to drop it and hunt around before he could get his stinging hands on it once more. Then Frank tried to bunt
- 71. twice and failed, and, with two strikes and one ball on him, rolled one down to third. Tony George threw to second too late and both runners were safe. Then, however, Tim struck out Hal Mason and Dodson, and, swinging fearsomely, only succeeded in sending a foul to Tony George which that youth juggled but eventually saved. Tracy Gay got a safety past third, but Lord decided not to try for the plate, since Tubby Knowles had come in fast and had scooped up the ball before Lord was well around third. With the bases full, Arnold went to bat looking very determined. But there were two down and, as Tim refused to send him anything he could line out, he finally brought the inning to an end by flying out to center fielder. Snub Mooney, first up for the Towners in the ninth, drew a base on balls, but was out when Tim Chrystal hit to shortstop. Tim went on second when Toby placed a short fly behind first base that no one could reach. Then Billy Conners hit down the alley between shortstop and third, and suddenly the bases were full with only one out, and the Towners on the bench and their friends in the stand were shouting joyfully. Perhaps it was the noise and the vociferous coaching of the opponents that affected Frank Lamson’s command of the ball. At all events, after pitching two into the dirt and one over Tubby Knowles’s head, he worked a drop over for a strike and then plugged Tubby in the ribs. Tubby very promptly sat down on the plate and stared speechlessly, breathlessly, and accusingly at the pitcher until Tim trotted in from third and prodded him into activity with his toe. “Beat it, Tubby!” said Tim. “Go ahead down! You’ve tied the score!” Tubby, amidst laughter and wild acclaim, got to his feet groaning loudly and, a hand pressed anxiously to his side, limped to first. The Towners whooped joyously. The score was 6–6, the bases were still full, and there was but one out!
- 72. Frank Lamson and Catcher Dodson met and talked it over, and then Arnold walked in from second and they talked it over some more. And the enemy hooted and gibed and demanded action. Frank went back to the mound and Arnold to his position. On the bases the runners, encouraged by shrill shouts from the coachers, took long leads. Toby, at third, ran half-way to the plate on Frank’s first wind- up, with the result that the delivery was wild and Dodson only prevented a tally by blocking the ball with his body. Then Frank threw to third quickly and unexpectedly and Toby had a narrow escape. Once more Frank tried it, but this time Toby was watchful. Then Frank walked out of the box and signaled to Phillips, and the third baseman advanced some ten feet from base to meet him. Frank kept an eye on Toby while he and Phillips conferred, and although Snub Mooney raised a wonderful racket back of base and Toby threatened dashes to the plate, the latter had no chance to get home. Frank and Phillips whispered with heads very close and then Phillips returned to the bag, Frank walked back to the box, apparently rubbing the ball with his hands, and Toby danced along the path again. And then—well, then Phillips took the ball from under his arm, stepped after Toby and dug him none too gently in the ribs with it! And Mr. Trainor waved his hand and said, “Out at third!” in a rather disgusted tone of voice. And Toby, surprised, dismayed and, it must be confessed, decidedly peeved, dropped his head and joined Snub on the coaching line. “That’s a kid trick,” he said to Phillips, contemptuously. “Bush league stuff,” supplemented Snub. “Why don’t you play the game fairly?” The big third baseman grinned mockingly as he turned after throwing the ball back to Frank. “Keep your eyes open, fellows,” he replied. “You’re easy!” By that time the Towners had flocked across from the bench, protesting angrily. “Hiding the ball’s forbidden,” declared Gus Whelan. “How about that, Mr. Umpire?”
- 73. “He’s out,” replied Mr. Trainor, calmly. Gus and the others sputtered, but Toby sent them back. “There’s no rule against the hidden-ball trick,” he told them. “It was my fault. I ought to have seen it. It’s all right, though, fellows. We only want one run. Let’s have it. Hit it out, Tony!” But Tony swung helplessly under one of Frank’s fast ones and let the third delivery go by and heard it called a strike. “Gee, I wish he could hit it,” muttered Toby to Snub. “If we can only get Billy to third we can get him in. I’ll coach here. You beat it down to first, Snub, and take it there. Manuel’s up after Gus.” Frank tried the batter with a wide one that didn’t fool him, and it was two and two. “It only takes one, Tony!” called Toby. “Pick out a good one!” And Tony did that very thing the next instant when Frank tried to sneak one over in the groove. Tony met it not quite squarely, but he met it and the ball shot across the infield and for the first moment looked like a safe hit. But Arnold dashed to the right and, although he couldn’t make the catch, knocked the ball down. Billy Conners was turning third, but Toby seized him and shoved him back by main force, for Arnold had recovered the ball and finding that he was too late to get the runner at second or first, was pegging to the plate. “I could have made it!” gasped Billy, disappointedly. “You didn’t have a chance,” answered Toby. “Now listen. Hug your base until I shout ‘GO!’ and then don’t stop to look or anything. Just beat it! Understand?” “All right.” Billy got his foot on the base while Frank received the ball back from the catcher and glanced around the field. The bases were filled once more and at the plate Gus Whelan was tapping his bat eagerly. “Two gone, fellows!” called Arnold. “Play for the batter!”
- 74. Frank folded his fingers around the ball and settled for the wind- up. And at that instant Toby stepped across the base path and held up his hand. “Hi, Frank!” he called. “That ball’s ripped! We want another one!” Frank looked the ball over. “No, it isn’t. It’s perfectly all right.” “I tell you it is ripped! Let’s see it!” “Go on and play the game,” shouted Phillips. “I want to see that ball,” demanded Toby, advancing into the diamond. “It’s all right, I tell you,” replied Frank impatiently. “Get off the field, Toby.” “If it’s all right show it to me then.” Frank muttered, stepped out of the box and tossed the ball to Toby. “Have a look, then, and hurry up,” he growled. “Go!” yelled Toby. Instantly Billy Conners streaked for the plate, Toby stepped to one side and the ball went bounding across the base line. Pandemonium reigned. From second came Tubby, galloping for all he was worth, from first raced Tony. Phillips, after an instant of surprise, scurried after the ball. Billy swept across the plate. Toby waved Tubby on. Over near the fringe of the autos and traps Phillips was scooping up the ball. But by the time he had rescued it Tubby was rolling over and over in a cloud of dust across the plate and Tony was sliding, more scientifically but no less effectually, into third! The entire infield flocked about the umpire. Six voices shouted together. At first Toby smiled gently and winked at Tony George. And Tony, breathless but delighted, sat on the bag and winked back. “One trick,” murmured Toby pleasantly, “calls for another.” All the protests failed to aid the Spaniards and Mr. Trainor patiently explained that as time had not been asked for or called, the ball was
- 75. still in play. “Your pitcher,” he said, “threw the ball out of the field and the runners scored, as they had a perfect right to do.” “But Tucker called for the ball!” exclaimed Frank. “It was a trick! He hadn’t any right——” “There’s nothing in the rules forbidding that,” answered the umpire gently. “You didn’t have to throw it to him, you know.” “You call that fair playing?” demanded Phillips bitterly. “According to the rules of the game it’s fair,” was the response. “I can’t go back of the rules.” “It’s a low-down, measley trick!” declared Frank hotly. “Those runners ought to be sent back, Mr. Trainor.” “It was a trick, of course,” was the reply. “But so is hiding the ball, don’t you think? One isn’t any worse than the other and the rules don’t prohibit either, Lamson. Play ball, please.” But it was several minutes later before the Spaniards accepted the inevitable with bad grace and went back to their positions. As for Arnold, though, it is only fair to say that he made little protest, for he was possessed both of a sense of humor and a sense of justice. Phillips, however, scowled darkly at Toby and Tony as he returned to his base. “Cheating,” he said grumpily, “is the only way you fellows could win.” “Keep your eyes open,” replied Toby sweetly. Then the game went on. But the Spaniards had lost their grip, and Frank Lamson, too angry to care much what happened, passed Gus Whelan and allowed Manuel Sousa to land against a straight ball and send it speeding over shortstop’s head. Tony trotted home unhurriedly and Gus took second. Chuck Morgan brought the inning to an end by fouling out to the catcher. After that, with the score 9 to 6, the Towners had only to hold their opponents for the last of the ninth, and, although Tim Chrystal
- 76. threatened to make trouble for himself by passing the first man up, he soon settled down again, and by the time the runner had stolen second and reached third on a put-out at first there were two down, and Frank Lamson ended the contest by ignominiously striking out. The Spaniards’ cheer for the victors was noticeably faint.
- 77. T CHAPTER XIV TOBY IS DOWNHEARTED he next morning the Johnstown ferry began operations, at least theoretically. As a matter of fact, no one had appeared by nine o’clock, and, after pondering the matter, the boys decided to omit the first trip, arguing that if there were no passengers at this end there’d be none at the other, or, if there were, it wouldn’t hurt them to wait until 11.30! Toby was disappointed and showed it. He hadn’t expected that the capacity of the Urnove would be taxed on its maiden voyage as a ferryboat, but he had looked forward to having at least one passenger. Sitting idly there in the hot sun on the hard seats of the little gray launch made one feel decidedly flat! Arnold, though, was not in the least downcast. He had more perfectly plausible reasons for the lack of patronage than Toby, in an unnaturally pessimistic frame of mind, could counter. “You wait until eleven,” said Arnold cheerfully. “Bet you we’ll have three or four then!” When it was evident that there was to be no excuse for making the nine o’clock trip they went up the gangplank and found seats in the shade of a shed at the end of the wharf, and presently Toby forgot his disappointment. They talked of yesterday’s ball game and Arnold, who had gone off the field a little bit peeved, today laughed at his grouch. “You surely turned the trick on us, Toby! Frank was as mad as—as——” “As mustard,” interjected Toby helpfully. Arnold accepted the simile doubtfully. “Well, he was some peeved, anyhow. He says you didn’t play fair, but I told him——” “I didn’t,” responded Toby.
- 78. “Well, no more did we.” “That wasn’t any reason for my pulling that raw trick, though. The trouble was that I got mad at being caught off third like that, and wanted to get square.” “Well, I don’t blame you. That hide-the-ball business was got up by Frank and Phillips. I didn’t know anything about it until they pulled it. I don’t like that sort of piffle. Toby, I say if you’re going to play ball, why, play ball!” “Yes, we both—both teams, I mean—played baby. I wished afterward I hadn’t done it. Even when you win like that you don’t really feel right about it. Anyway, I don’t.” “Shucks, what’s the odds! I’ll own I was sort of sore yesterday, but now I’m glad you did it. It was only what we deserved. Besides, it’s made Frank so grouchy he can’t see straight. He’s going to keep the team going and try to get you fellows to play again. He called me a quitter and got quite nasty about it.” “If he keeps at it long enough,” observed Toby dryly, “he’s bound to beat us. What time is it?” “Twenty-five to ten,” answered Arnold. “We don’t have to sit here, so let’s go over and see how the boat’s getting on. Say, I wish we could think of a name for her.” “All names I like you don’t,” said Toby as they ascended the lane to Harbor Street. “Why don’t you do the way we did with the Turnover? Knock off the first and last letters, I mean.” Arnold stared blankly. “Knock off—— But we haven’t got any letters yet, you idiot!” “That’s so,” replied Toby demurely. “Let’s go to the postoffice.” Arnold swung about obediently before he thought to ask, “What for?” “To get some letters,” said Toby.
- 79. Arnold tried to reach him with the toe of one water-stained white buckskin shoe, but was foiled by Toby’s agility, and they went on again. “There was a yawl I knew once called Saucy Sal,” observed Arnold presently. “How well did you know her?” asked Toby. “You’re too bright for anything today!” said the other, in a grieved tone. “If you’re so smart why don’t you think of a name for me?” “I didn’t know you wanted one. I can think of several,” said Toby significantly, “but you mightn’t like them.” “I mean for the boat, you chump! It’ll be ready to launch before we know it, and you just can’t launch a boat without a name!” “All right, Arn, I’ll put my giant intellect at work tonight. I always think better after I’m in bed, don’t you?” “No, I don’t. When I get to bed I go to sleep.” “So do I after a while, but I always think things over first.” “Now don’t forget that we ought to be back at the landing at a quarter to eleven. The trouble with you is that when you get in there looking at that knockabout you forget everything.” “There’s one thing I don’t forget,” chuckled Arnold, “and that’s dinner!” They were back on the float at a little past the half-hour and Toby seized a rag and performed a lot of quite unnecessary polishing during the ensuing wait. Perhaps it relieved his nervousness. At a quarter to eleven Chuck Morgan and Snub Mooney descended the gangplank. Chuck had thirty-five cents and Snub twenty-two, and they tried to engineer a deal whereby they were to be taken across to Johnstown and back for fifty-seven cents in cash and a promise of eighteen cents more at some future date. Snub said he thought Toby ought to make a special rate to his friends. “I will,” said Toby. “I’ll take one of you over and back for fifty- seven or I’ll take you both one way for it. Which do you choose?”
- 80. “Oh, go on, Toby! Have a heart! Honest, we’ll pay you the other eighteen, won’t we, Chuck? I’ll give it to you tomorrow, or maybe next day.” “This is business, Snub,” answered Toby emphatically. “If you fellows want to make the trip over and back I’ll take you this once for nothing. But the next time you’ll have to pay full fare, friends or no friends.” “All right,” agreed Snub cheerfully. “I guess we won’t ever want to go again! Anybody else coming?” Toby looked at the town clock and shook his head, trying not to appear disappointed. “I guess not this trip,” he replied. “Better wait five minutes more,” said Arnold, “in case some one’s late, you know.” But Toby shook his head resolutely. “They’ve got to be on time if they’re coming with me. This ferry sails right on the hour. Cast off that line, Arn, will you?” And so, after all, the Urnove made its first trip, if not without passengers, at least without profit. But when she was out of the harbor, with the waves slapping at her bow and the fresh breeze ruffling damp hair, both boys forgot to be downcast and they had a very merry sail across the smiling blue water. They tied up at the little spindly pier at Johnstown promptly at eleven-twenty and waited. Now and then, ostensibly to get the cooler breeze above, Toby climbed to the pier. The approach to it was in sight for a couple of hundred yards and always, before returning to the float, Toby’s gaze wandered anxiously and longingly up the road. But eleven- thirty came without a passenger and the Urnove cast off again and began her homeward voyage. By that time Toby was frankly despondent, and he had little to say on the way back. It was becoming painfully evident that the Johnstown ferry was not to be a financial success! But when he got home for dinner—Arnold had resisted the temptation to accept Toby’s invitation and had chugged back to the
- 81. Head in the Frolic—the gloom was slightly illumined by a letter which Phebe put in his hand. Toby had almost forgotten Mr. Whitney, but the letter corrected that, for it announced that the contractor would be at the landing the next morning at eight to be carried over to Johnstown. Toby’s face brightened. Mr. Whitney would pay three dollars! Then he recalled the fact that he had decided that Mr. Whitney was to pay the same as others, and his countenance fell again. Still, if the contractor arrived at eight it would mean a special trip, and a special trip was a different matter! He determined to lay the question before Arnold after dinner, being, of course, quite certain of Arnold’s decision! But that letter cheered him up and he had no difficulty in eating a very satisfactory meal, and felt a whole lot better after it. Phebe made the trip across with them at two, and again at four, and if it hadn’t been that Toby was horribly disappointed over the absence of patronage they’d have had a pretty good time. Even as it was they enjoyed it. Between trips they sat, the three of them, in a shady and breezy corner of the boat yard, from where, by craning their necks a bit, they could see the town landing, and tried to decide on a name for the knockabout. They canvassed every name they had ever heard of or could think of, but none seemed to please Arnold. Toby at last told him he was too hard to suit. “There aren’t any more names, I guess,” he said. “Not unless you get a city directory and go through it. I think Slap-Dash is the best. Don’t you, Phebe?” “I like Foam better. It’s prettier.” “Girls,” said Toby sententiously, “always want something pretty. Gee, I’ll bet there are eighty-eleven million boats called Foam!” “That doesn’t matter, does it?” asked Phebe. “I suppose there are lots of boats called Slap-Dash, too.” “Not near so many. Besides——” “I don’t like either of those names much,” said Arnold apologetically. There was a discouraged silence then until Phebe
- 82. observed: “I don’t see why you don’t call it the Arnold. Arnold’s a pretty name——” “Wow!” jeered Toby. “There’s one for you, Arn. A pretty name for a pretty boy, eh?” Arnold threw a chip at him. “A fellow wouldn’t want to name a boat after himself,” he demurred. “There was a man around here a couple of years ago,” said Toby, “who had a sloop he called the A. L. We used to say it stood for always last, but it was really just his initials. You might call yours the A. D.” Arnold considered. “A. D.,” he murmured. “Say, that isn’t so bad, is it? It—it’s sort of short and—and neat, eh?” “Yes, and you could call it Anno Domini for long,” laughed Toby. Arnold’s face clouded. “Yes, I suppose fellows would get up all sorts of silly meanings for it. If it wasn’t for that——” Phebe clapped her hands. “I’ve got it!” she cried. “Call it the Aydee!” “That’s what we said,” began Toby. “No, not the letters, Toby,” explained Phebe. “‘A-y-d-e-e,’ Aydee! I think that would be lovely!” “That’s not so worse,” commented Arnold, reaching for a chip and his pencil. “Let’s see what it would look like.” He printed it in capital letters, viewed it, and passed it around. “I think it’s clever, Toby. Folks wouldn’t know it stood for anything, would they? It sounds like —like a name out of the ‘Arabian Nights,’ or—or something.” “Aydee it is, then,” declared Toby. “Funny, but I was just going to suggest that myself!” “Yes, you were!” Arnold jeered. “Like fun! That’s Phebe’s name, and Phebe will have to christen her! We’ll have a regular christening
- 83. Welcome to Our Bookstore - The Ultimate Destination for Book Lovers Are you passionate about books and eager to explore new worlds of knowledge? At our website, we offer a vast collection of books that cater to every interest and age group. From classic literature to specialized publications, self-help books, and children’s stories, we have it all! Each book is a gateway to new adventures, helping you expand your knowledge and nourish your soul Experience Convenient and Enjoyable Book Shopping Our website is more than just an online bookstore—it’s a bridge connecting readers to the timeless values of culture and wisdom. With a sleek and user-friendly interface and a smart search system, you can find your favorite books quickly and easily. Enjoy special promotions, fast home delivery, and a seamless shopping experience that saves you time and enhances your love for reading. Let us accompany you on the journey of exploring knowledge and personal growth! ebookgate.com