Get the full ebook with Bonus Features for a Better Reading Experience on ebookgate.

com

Enterprise JavaBeans 2 1 1st Edition Stefan

Denninger

https://ebookgate.com/product/enterprise-javabeans-2-1-1st-
edition-stefan-denninger/

OR CLICK HERE

DOWLOAD NOW

Download more ebook instantly today at https://ebookgate.com

Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

Pediatric Palliative Care 1. Auflage Edition Stefan J.

Friedrichsdorf

https://ebookgate.com/product/pediatric-palliative-care-1-auflage-
edition-stefan-j-friedrichsdorf/

ebookgate.com

Understanding Enterprise SOA 1 / illustrated edition

Edition Eric Pulier

https://ebookgate.com/product/understanding-enterprise-
soa-1-illustrated-edition-edition-eric-pulier/

ebookgate.com

Progress in Responsible Tourism Vol 2 1 Volume 2 Issue 1

1st Edition Harold Goodwin

https://ebookgate.com/product/progress-in-responsible-tourism-
vol-2-1-volume-2-issue-1-1st-edition-harold-goodwin/

ebookgate.com

Enterprise resource planning 1. ed., international. ed

Edition Mary Sumner.

https://ebookgate.com/product/enterprise-resource-planning-1-ed-
international-ed-edition-mary-sumner/

ebookgate.com
Knowledge Management 2 0 Organizational Models and
Enterprise Strategies 1st Edition Imed Boughzala

https://ebookgate.com/product/knowledge-management-2-0-organizational-
models-and-enterprise-strategies-1st-edition-imed-boughzala/

ebookgate.com

Storytown Rolling Along Level 2 1 Grade 2 1st Edition Hsp

https://ebookgate.com/product/storytown-rolling-along-
level-2-1-grade-2-1st-edition-hsp/

ebookgate.com

Enterprise 2 0 Social Networking Tools to Transform Your

Organization 1st Edition Jessica Keyes

https://ebookgate.com/product/enterprise-2-0-social-networking-tools-
to-transform-your-organization-1st-edition-jessica-keyes/

ebookgate.com

The Little SAS Book for Enterprise Guide 4 2 1st Edition

Susan J. Slaughter

https://ebookgate.com/product/the-little-sas-book-for-enterprise-
guide-4-2-1st-edition-susan-j-slaughter/

ebookgate.com

Python 2 1 Bible 1st Edition Dave Brueck

https://ebookgate.com/product/python-2-1-bible-1st-edition-dave-
brueck/

ebookgate.com
 Enterprise
JavaBeans 2.1
STEFAN DENNINGER and INGO PETERS with ROB CASTANEDA
translated by David Kramer

APress Media, LLC

Enterprise JavaBeans 2.1
Copyright ©2003 by Stefan Denninger and Ingo Peters with Rob Castaneda
Originally published by Apress in 2003

All rights reserved. No part of this work may be reproduced or transmitted in any form
or by any means, electronic or mechanical, including photocopying, recording, or by
any information storage or retrieval system, without the prior written permission of
the copyright owner and the publisher.
ISBN 978-1-59059-088-1 ISBN 978-1-4302-0771-9 (eBook)
DOI 10.1007/978-1-4302-0771-9

Trademarked names may appear in this book. Rather than use a trademark symbol
with every occurrence of a trademarked name, we use the names only in an editorial
fashion and to the benefit of the trademark owner, with no intention of infringement
of the trademark.
Translator, Editor, Compositor: David Kramer
Technical Reviewer: Mary Schladenhauffen
Editorial Directors: Dan Appleman, Gary Cornell, Simon Hayes, Martin Streicher,
Karen Watterson, John Zukowski
Managing and Production Editor: Grace Wong
Proofreader: Lori Bring
Cover Designer: Kurt Krames
Manufacturing Manager: Tom Debolski

The information in this book is distributed on an "as is" basis, without warranty.
Although every precaution has been taken in the preparation of this work, neither the
author nor Apress shall have any liability to any person or entity with respect to any
loss or damage caused or alleged to be caused directly or indirectly by the information
contained in this work.
 Contents at a Glance

About the Authors Ix

Acknowledgments x

Preface xl

1 Introduction 1

2 Fundamentals 7

3 The Architecture of Enterprise JavaBeans 21

4 Session Beans 63

5 Entity Beans 111

6 Message-Driven Beans 231

7 Transactions 277
8 Security 323

9 Practical Appllcations 339

10 Web Services and Scbedullng 431

References 457

Index 459
 Contents

About the Authors Ix

Acknowledgments x

Preface xi

1 Introduction 1
A Hypothetical Scenario . 1
First the Bad News . 1
TheTask . . . . . . . . . 1
The Solution . . . . . . . 2
Multiple-User Capability 3
Scalability . . . . . . . . 3
Availability. . . . . . . . 3
Connection with the Outside World 4
Integration with Other Applications and Rapid Extensibility. . 4
Short Development Cycles . . . . . . . 4
Configurability . . . . . . . . . . . . . 5
Stepwise Migration and Data Storage . . 5
Summary .. 5
So Now What? . 6

2 Fundamentals 7
Enterprise . 7
Java . 11
Beans . . . 13

3 The Architecture ofEnterpr1se JavaBeans 21

TheServer . . . . . . . . 22
The EJB Container . . . . 23
The Persistence Manager 30
Enterprise Beans . . . . 31
How Everything Works Together 44
The Client's Viewpoint . . . . . . . . . 47
What an Enterprise Bean May Not Do . 50
EJB Assignment of Roles. 51
Points of View . . . . . . . . . . . . . . 56
Contents

4 Session Beans 63
Introduction . 63
Concepts . . . 64
Programming 75
Examples ·. 97

5 Entity Beans 111

Introduction . .............. 111
Concepts . . . . . . . . . . . . . . . . . 113
Container Managed Persistence 2.0/2.1 129
Relations Among Entity Beans (EJB 2.0/2.1) 150
EJB-QL (EIB 2.0/2.1) . . . . . . . . . . . . . 174
Example: Warehouse Management (EJB 2.0) 189
Container-Managed Persistence 1.1 203
Bean-Managed Persistence . · .... 210
Summary · ...... . ..... 228

6 Message-Driven Beans 231

Java Message Service UMS) 233
Concepts . . . 260
Programming 263
An Example 268
Summary ·. · ....... 273

7 Transactions 277
Fundamentals . .......... 277
Concepts . . . . . . . . . . . . . . 280
Implicit Transaction Management 286
Explicit Transaction Management 305
Transactions in the Deployment Descriptor 319

8 Security 323
Introduction . ..... 323
Programming .. . .... 326

9 Practical Applications 339

Performance . . . . . . ............ · .... 339
Processes, Enterprise Objects, and Services 349
Aggregation of Enterprise Beans 355
Inheritance ............ 370
Enterprise JavaBeans and Events . 374
Internet Connection. . . . . . . . 385
Entity Beans and Details Objects 389
Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

vi
 Contents

10 Web Services and Schedullng 431

Introduction . . . . . . . . . . . . 431
Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
The Standardized World ofJ2EE . . . . . . . . . . . . . . . . . . . . . 431
Solving the Integration Problem . . . . . . . . . . . . . . . . 435
Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Timers . . . . 446
Summary 455

References 457

Index 459

vii
 About the Authors

Stefan Denninger
Stefan Denninger completed his university education in February 1996 with
a degree in business management. He has worked as a software engineer
for Kromberg & Schubert in Abensberg, Germany, IXOS Software in Munich,
Germany, and eCircle Solutions in Munich. He currently works for ConSol GmbH
in Munich as a senior software consultant.

Ingo Peters
Ingo Peters currently works with the HypoVereinsbank, a group of European
banks managing Internet portals and applications. As a project manager, he
has guided many different applications and Internet portals using Enterprise
JavaBeans to success. He started programming with Enterprise JavaBeans in 1998.

Rob Castaneda
Rob Castaneda is Principal Architect at CustomWare Asia Pacific, where
he provides architecture consulting and training in EJB/J2EE/XML-based
applications and integration servers to clients throughout Asia and America.
Rob's multinational background, combined with his strong real-world business
experience, enables him to see through the specifications to create realistic
solutions to major business problems. He has also contributed to and technically
edited various leading EJB and J2EE books.
 Acknowledgments

Working on this book has been a great pleasure for all of the authors. Long
discussions about local interfaces and dependent objects have resulted in
several chapters being rewritten and then rewritten again, and changes in the
specification have led to many interesting discussions and insights.
Without the active support of colleagues and friends, work on this book would
not have been nearly so interesting, nor so productive. Stefan Denninger and
Ingo Peters would like particularly to thank Stefan Schulze and Alexander Greisle,
whose constructive and highly competent feedback have significantly improved
the quality of this book. They would also like to thank the readers of the first
German edition, whose support and feedback made the second edition possible.
Finally, they wish to thank their editor, Martin Asbach, of Ad dison-Wesley, for his
great care and friendly collaboration in bringing this book into the world, to the
staff of Apress for making the English translation possible, and for their amiable
and uncomplicated collaboration.
Rob Castaneda would like to thank John Zukowski, Grace Wong, and the team
at Apress, as well as colleagues at CustomWare Asia Pacific, including Ian Daniel,
Nathan Lee, and Scott Babbage, as well as his wife, Aimee Castaneda. Without the
support of the these individuals, this work would not have been achievable.
 Preface
ENTERPRISE IAVABEANS (BIB) IS THE standard component architecture for the
creation of distributed business applications in the programming language
Java. EJB offers all mechanisms necessary for the creation of applications for
enterprise-wide deployment and for the control of critical business processes.
Application developers can profit from distribution of processes, transaction
security, pooling of network connections, synchronous and asynchronous
notification, multithreading, object persistence, and platform independence.
With EJB, programming remains relatively simple.
In March 1998 the first specification of Enterprise JavaBeans was published
by Sun Microsystems. In relatively short order there followed in December 1999
the consolidated version 1.1. In the meantime, the component architecture has
accounted for considerable change in the market for application servers, so
that today, the large majority of application servers support EJB. EJB has also
established itself in the growing market for finished application components.
Today, there exists a large market for everything from specialized solutions to
specific problems to complete application frameworks.
In August 2001 version 2.0 was released. The new version offers considerable
extensions and improvements, which are considered in this book, now in its
second edition. The first edition has been greatly revised in order to take account
of the following developments:
• The new message-driven beans (EJB 2.0) offer completely new ways to
achieve asynchronous communication and parallel processing of business
logic. This is made possible by the integration of the Java Message Service
(JMS) into tht EJB architecture.
• Local interfaces (EJB 2.0) enable optimization of process-internal
communication among Enterprise Beans and between local clients and
Enterprise Beans.
• The persistence manager has been introduced (EJB 2.0). With relationships
between entity beans it is now possible to model complex data structures.
The associated query language EJB QL makes it possible to work efficiently
with these structures.
• A new chapter (Chapter 8) deals with security issues of EJB.
• The chapter on practical applications (Chapter 9) has been greatly
expanded.
• All the examples have been reworked, with emphasis on ease of execution.
Preface

Today, one may safely state that Enterprise JavaBeans has brought the
success of the programming language Java to the server, particularly in the
areas of portals and integration of older applications, where EJB has become a
widely used solution strategy. However, information technology is on the verge
of yet new changes. The trend today is in the direction of freely combinable
application components from a variety of producers that are connected via
web services. EJB 2.0 offers answers to these growing requirements. Particularly
the new developments in the areas of marketplaces, private stock exchanges,
e-procurement, and electronic funds transfer can profit from using EJB as the
base architecture.
This book is directed to the reader who wishes to learn more about
Enterprise JavaBeans. It discusses the fundamental concepts underlying the EIB
architecture. Building on this foundation, it explains the technical details and
concrete programming of Enterprise Beans. Many examples are used to clarify
and expand on the concepts introduced. The source code for all the examples
in this book is available at http://www.apress.comin the "Downloads" section.
A knowledge of the Java programming language and a basic understanding of
distributed programming are prerequisites for reading this book.

xii
 CHAPTER 1

Introduction
A Hypothetical Scenario
Imagine that you are an application programmer working for a midsize firm in the
automobile industry that maintains numerous offices in a number of European
countries. Your firm is pursuing the strategy of developing its own business
applications in house. At first glance such a strategy may seem rather odd. But
extreme competition and increasing cost pressures now demand a high level of
flexibility and stability from the development team, and your division leader has
guaranteed that the software systems developed will have these characteristics,
and this is the justification for management's decision to support in-house
development.
Up to now each office has installed and maintained its own software system,
since the development teams in each branch have been working independently
of one another.

First the Bad News

One fine day, you are summoned to your division leader's office. He informs
you that big events are about to occur in the data processing division of the
company. To accommodate increasing international growth and to promote
efficiency, all the software in the entire company is to be unified, standardized,
and streamlined into a single distributed system. The development teams will
remain at the individual offices, but beginning at once they are all to report to a
newly appointed division leader, under whose direction they are to work together
to achieve the stated goals. Existing software at the individual branch offices is
to be replaced piece by piece by the newly developed replacement packages.
Isolated systems in various parts of the company (such as personnel management
and accounting) are to be integrated into the new system. Thus you, a specialist
in accounting and supply systems, are affected by the new developments.

The Task
Your job is to develop a prototype for this new system, which after an evaluation
phase is to be further developed into a stable building block of the new system.
Chapter 1

Yow piece of the action is to be a rudimentary accounting system. Other

offices are to develop compatible inventory and annual accounts modules, and
they together with yow accounting module are to be presented to company
management. A number of users from the various divisions must be able to
use the system simultaneously. Since yow company is planning on introducing
telecommuting, the system must also be usable from outside the company, over
the Internet, for example. In order to avoid bottlenecks during critical periods
(such as the end of a quarter or year) the system must be able to operate under
heavy usage. Fwthermore, anticipated growth in the number of employees must
also be taken into account.

The Solution
A superficial reading of the above text could easily lead one to the conclusion that
the task as set out should give little trouble to an application developer who is
an expert in business applications. But if one reads more closely, a rather more
complex pictwe begins to present itself (see Figure 1-1). The crux of the problem
is in the new set of circumstances that confront ow application specialist. These
altered circumstances bring problems that will complicate the development of a
prototype of a rudimentary accounting system. Let us examine the situation more
closely in terms of the following observations.

Easy Extensibility

Stepwise Migration
~_.;",."""",~ ~
~I ~ Multiuser Capability
~---::

Data Storage
Business Scalability

Configurability
Problem Usability

Short Develoment Cycles Connection to the Outside World

Integration with Other Applications

Figure 1-1. Solution ofa business problem.

2
 Introduction

Multiple-User Capability
The accounting system, which until now has been conceived as an isolated
solution, must now be integrated into a larger system and enable a number
of users to work simultaneously. For this the system must satisfy the following
requirements:

• multiprocess capability (multithreading),

• transactions,
• user control,
• security mechanisms,
• networking capability.
A further consideration is the necessity of ensuring that the requirements
listed above are standardized and consistent among all modules of the system.
This is a very important requirement to consider. It is often overlooked because it
does not directly map to any user requirements, and it becomes a critical factor in
working with remote development teams.

Scalability
To accommodate an increase in the number of employees the system must be
scalable. If the previously available resources become overtaxed, then it must be
possible to expand the software to include additional resources. This goal results
in a distribution of the applications among several servers usually located within
a cluster. The system should then (possibly after a reconfiguration) make use of
the new resources and thus offer improved performance without the occurrence
of bottlenecks. It is important that the reconfiguration and redeployment of an
application be flexible and not require major source code modifications and
recompilation. Rigid designs that require that source code modifications be made
in reconfiguring and redeploying the system reduce the system's flexibility and
increase the burden on the system administrator.

Availability
In general, but most importantly at critical junctures such as end of quarter
or year end, the system must offer a high degree of availability. If a computer
becomes unavailable, then another computer must be able to take over the
requisite functions without a great deal of effort (or perhaps none at all) in
reconfiguring the system. This requires that the system be capable of transferring
functional units from one computer to another.

3
Chapter 1

Connection with the Outside World

Since the company hopes to work with greater cooperation among its associated
parts and also plans on introducing telecommuting, the system must offer an
interface to the outside world (for example, through a defined port through the
corporate firewall). The result is not only an increase in security requirements, but
also in the requirements on the system architecture in general, since the structure
of Internet applications is fundamentally different from that of traditional
applications.

Integration with Other Applications

and Rapid Extensibility
In the ideal case the method of integration is such that various applications that
have been developed as a collection of building blocks can be assembled into a
complete system. Each application should itself be constructed of building blocks
and have the capacity to make itself available to other applications in a limited
way by means of clearly defined interfaces. The system can be extended through
the provision of additional building blocks. This means that the basic structure of
the system supports a suitable degree of granularity.

Short Development Cycles

In the software development process the requirement of efficiency places one
fundamental goal in the foreground: shortening the development cycle and
thereby reducing development costs. The challenge for the development team is
to reduce development costs, while maintaining (or even improving!) the quality
and robustness of the system. This is achieved, as a rule, through increasing the
granularity. Legacy applications can also be added into the system by the creation
of building blocks that wrapper existing functionality. A large and unwieldy
project is subdivided into many small, easily managed projects, each of which
constitutes a building block. The totality of all the building blocks is the system.
Each building block can be defined, built, and tested as an individual piece of
functionality to ensure qUality. Thus this building-block approach contributes not
only to integrability and extensibility, but to the shortening of the development
cycle as well. It also helps to provide for remote development, since building
blocks can be designed and then developed at remote offices and integrated once
completed for end-to-end testing.

4
 Introduction

Configurability
If applications that are developed in one location are to be usable at another (just
think of differences in national laws, languages, notation, and on and on), then
there must be a high degree of configurability, so that the applications can be
adapted without the necessity of being recompiled. As a further alternative one
might imagine (thinking again of the building-block approach) replacing building
blocks that cannot be implemented at a particular location by location-optimized
building blocks.

Stepwise Migration and Data Storage

Rome, as has often been observed, was not built in a day (and it is still under
construction!), and neither can a system redesign and reconfiguration take
place overnight. Therefore, the step-by-step changeover to a new system is an
important topic. It should be simple to create interfaces to existing systems, a
requirement that results in something even more important: In the ideal case it
should make no difference to a particular application where data is stored. It can
be located in a database belonging to the new system, in a database belonging
to an old system, or indeed in an external database that does not belong to the
system at all.

Summary
The number of considerations that are required in order to produce the solution to
our problem can easily exceed the capabilities of a normally endowed application
developer. However, today a number of software companies offer solutions to
developers that provide ways of overcoming the problems inherent in a project
such as the one that we have described, and a great deal of the thought and design
required to handle the issues listed above have been collected into a number of
industry standard platforms. This book discusses one of these platforms in great
detail: Enterprise JavaBeans (or BJB for short). So wake up and smell the coffee,
and let's get started.

5
Chapter 1

So Now What?
In Chapter 2 we discuss the fundamentals of Enterprise JavaBeans and place
them in the context of the technologies for software development. In Chapter 3
we devote our attention to the fundamental architecture of Enterprise JavaBeans
as well as the roles that the development team can play during the development,
deployment, and management stages of the system. The different varieties of
components (known as beans), namely, entity, session, and message-driven beans,
are discussed in Chapters 4, 5, and 6. Building on this we go on in Chapter 7 to
discuss the topic of transactions, while Chapter 8 is devoted to security. In each
of these chapters extensive examples are introduced to clarify the discussion. In
Chapter 9 we discuss several aspects of the practical application of the principles
discussed (again with extensive examples). Finally, in Chapter 10, we discuss web
services and the integration of Enterprise JavaBeans to other platforms that exist
within common enterprises.
After you have read this book you should have a firm grasp of the capabilities
of the Enterprise JavaBeans platform. Furthermore, you should be in a position to
translate the knowledge you have gained from theory into practice.

6
 CHAPTER 2

Fundamentals

Enterprise JavaBeans is an architecture (Framework) for component-oriented

distributed applications. Enterprise Beans are components of distributed,
transaction -oriented business applications.
-Sun Microsystems, 2001

Enterprise
The programming language Java is known primarily for two features: its platform
independence and its ability to beautify web pages by means of applets. However,
Java has many capabilities to offer above and beyond the decoration of web pages.
Java is a full-fledged object-oriented programming language that is increasingly
being used for the development of enterprise-critical applications. As Figure 2-1
shows, Enterprise JavaBeans is a building block in the product and interface
catalog of Sun Microsystems for the development of enterprise applications.

Figure 2-1. The place ofEnterprise JavaBeans in Sun's enterprise concept

[J2EE-APM, 2000.J
Chapter 2

In the figure, J2EE stands for java 2 Platform, Enterprise Edition, JSP for
javaServer Pages, and EJB for Enterprise javaBeans.
Enterprise JavaBeans is not a product, but merely a specification. Any
individual who feels the calling may bring to market an implementation of the
Enterprise JavaBeans specification.
That Enterprise JavaBeans involves a client-server architecture should be no
cause for wonderment (Sun has positioned Enterprise JavaBeans in the domain.
of server-side applications logic. Three-tiered architecture is currently the one
favored by most system architects (the trend is in the direction of multitiered, or
multilayered, architectures).
Three-tiered systems are distinguished in that the actual program logic (in
relation to enterprise applications often called "business logic") is located in the
middle layer (on an application server); see Figure 2-2.

Client Layer Client

Application Layer
(Middleware)

Data Storage Layer

Figure 2-2. Three-tiered architecture.

The bundling of the application logic on its own server in a layer between
the clients and the database offers the following advantages over traditional
two-tiered systems:
• The client programs become significantly smaller (and therefore are
often called "thin clients") and thus require fewer resources of the client
computer.
• The database is transparent to the client developer. The middle layer
(application layer) is completely abstracted from access to the data and

8
 Fundamentals

concerns itself with data stability (which simplifies considerably the

development of client programs) .
• Applications are more easily scalable, since a division of tasks can already
take place on the application layer (for example, in the case of server
overload a client query can be passed to another server) .
• A particular application logic is programmed only once and made available
to all clients centrally in the middle layer, and so the system is easy to
maintain and extend. If there is a change in the application logic, then only
a central component is affected and not a large number of individual client
applications.
If we were to attempt to classify existing system architectures in order to
locate Enterprise JavaBeans, then we might end up with a picture like that shown
in Figure 2-3.

Multilocation Network Enterprise!

Single-Location Applications Applications Intranet Internet
Applications (Mainframe) (Client-Server) Applications Appliations

(Single-Layer)
Systems

(Two- Layer)
Systems

(Three-Layer)
Systems

(n-Layer)
Systems
== - - - - --- - -

1 Number of Users n

Figure 2-3. Classification ofEnterprise JavaBeans in a system portfolio.

Enterprise JavaBeans is at its best in the domain of enterprise, intranet, and

Internet applications, which are built primarily on a three-tiered, or even n-tiered,
architecture and are developed in an object-oriented language (in this case Java).

9
Chapter 2

One speaks of a multitiered architecture (also called n-tiered) if in addition to the

client, application, and database layers there are additional layers for increasing
the level of abstraction or to improve scalability, or else when several three-tiered
systems are arranged in a cascade.
Since the word "enterprise" appears explicitly in the name, one feels
compelled to ask what the Enterprise JavaBeans specification provides to assist
developers in meeting the demands of business today. To answer this question we
must first consider on what criteria a decision for or against a given technology
should be based.

Economic Viability
Economic viability refers to the domains of development, acquisition, main-
tenance, and adaptation. Economic viability in development exists when the
technology actively supports a shortening of the development cycle. An increase
in productivity thus leads to reduced costs, which can then be passed along (this
is what economic viability in acquisition means to nondevelopers). Economic
viability in maintenance is the result of stability, which results in lower servicing
requirements. Economic viability as it relates to further development and adap-
ation is offered by a technology that enables a system to be extended or adapted
without great expense and risk.

Security
The question of security must be examined with extreme care. In relationship to
an investment, such security exists if the technology promises a certain minimum
life span and is assured of long-term support. Security also refers to security
against breakdown, that is, to availability. Its purpose is to avoid costs due to
failure in parts of the system or to system breakdowns. Security means as well the
capability of a technology to protect sensitve data from prying eyes and to protect
the system from unwelcome intruders.

Requirements
The deployment of a particular technology is justified only at the point where
there is a requirement for the capabilities that it offers. An enterprise will not
institute a technology or product merely on account of its current popularity
without experiencing a genuine need.

10
 Fundamentals

In the following chapters this book will lay out in detail how the Enterprise
JavaBeans specification attempts to deal with the requirements of modem
enterprises for a stable system.

Java

Enterprise JavaBeans is designed to help the programming language Java

make the jump from the client platform to the server platform. To be sure, it
is possible to develop a server without Enterprise JavaBeans. However, Java
offers in its standard libraries extensive support for network communication
as well as support for threads. With Enterprise JavaBeans it is possible even for
"ordinary" programmers, that is, those who are not server specialists, to expand
the functionality of an application server or to develop server-side logic.
How can Java contribute to making Enterprise JavaBeans into a successful
concept for the development of enterprise-critical applications?

Object Orientation
Java is an object-oriented programming language, and thus it offers the developer
the advantages of object-oriented techniques. Java is also well equipped for the
next step, namely, in the direction of component-oriented software development,
for which object-oriented technologies are the best starting point (more on this in
the section "Beans."

Platform Independence
Many enterprises find themselves confronted with the problem of a heteroge-
neous hardware and software landscape that can lead to almost insuperable
difficulties. Many software systems are available only for specific platforms.
Java source code is translated by the Java compiler not into machine code, but
into machine-neutral byte code, which is then interpreted by a Java run-time
environment. Therefore, applications that are developed in "pure" Java can
run on all platforms for which a Java run-time environment is available. The
run-time environment is platform-dependent and provides the Java program
an implementation of abstract interfaces for system-dependent operations (for
example, for access to file systems, access to network interfaces, and the display
of graphical interfaces). Java applications offer an enterprise increased security
and continuity through their platform independence.

11
Chapter 2

Dynamics
As an interpreted language Java provides the capability of loading byte code
either from the local file system or over a network into the address space of a
process and from this to generate objects at run time (that is, program segments
can be reloaded at run time, even over a network). Thus the stony path of rigid,
inflexible systems is smoothed into dynamic run-time systems with a high degree
of adaptability, and a contribution as well to greater flexibility and continuity.
Java classes can be examined at run time (reflection). Methods can be called
dynamically, attributes recognized and modified, and so on. With increasing
support for Java in database systems (Oracle, for example), groupware systems
(such as Lotus Notes), web servers (via Servlet API and JavaServer Pages), and
browsers there are numerous possible combinations for system development.
Even the linkage with other platform-independent technologies such as XML
offers interesting perspectives. Thus in version 1.1 of the EJB specification
XML replaces serialized classes as deployment descriptors (more details on
deployment descriptors in Chapter 3).

Stability
The Java programming language is relatively easy to learn (compared, for
example, to C++) and less subject to programming errors to the extent that certain
language features (such as pointers to variables and functions) are absent, in
favor of a consistent object orientation. Since it is platform-independent, to
the extent to which the system in question has been developed in pure Java, no
porting is necessary. Thus the possibility of porting errors does not arise. Since
Java is an interpreted language, serious run-time errors (such as access to invalid
object references, null pointers) do not lead to uncontrolled system crashes. nie
program is terminated in a controlled manner by the run-time environment.
Thus critical errors can be located and fixed more rapidly.

Security
Java supports security through the features of the language. Thus direct access to
memory by means of pointers is forbidden, stack overflow and exceeding array
bounds are trapped and reported as an error in the form of an exception, and so
on. Java also supports the sandbox concept, which has application p~arily to
applets.

12
 Fundamentals

On the other hand, security is supported under Java by means of program

interfaces and implementations that belong to the standard range of run-time
and development environments (currently version 1.3). With an implementation
of a Java SecurityManager customized to individual requirements it is possible
to keep track of, for example, critical operations of objects (such as reading and
writing of files, opening of network connections) and prohibit them as necessary.
Java offers management of private and public keys as well as program interfaces
for encryption. There is also the possibility of signing Java archive files (JAR files)
for preventing the manipulation of byte code by a third party. An excellent and
thorough treatment of the topic of security in relationship to Java is given in [16].

Performance
The advantages that Java gains from the properties of an interpreted language
must be paid for with performance limitations. Although much has been done to
improve Java's performance (for example, by just-in-time compilation), execution
speed remains a critical point (in complex client applications as well as in
server applications). Through continual improvement in hardware and the Java
run-time environment this problem has perhaps become less severe. However,
until Java reaches the execution speed of a compiled language, there will remain
the necessity of developmental work in the area of virtual machines.

Beans
When speaking about Sun Microsystems and components, the talk is always
about beans. The currently most popular component of Java is most likely
JavaBeans. Before we go into the difference between JavaBeans and Enterprise
JavaBeans, we need to dive briefly into the world of componentware, without
wishing to get involved in a full-blown discussion of the component paradigm.
There are numerous books about components that show the variety of ways that
this topic can be addressed. Here, however, we shall merely take a glance at the
topic (which plays an important role with respect to Enterprise JavaBeans) in
order to increase our understanding a bit.
In order to avoid misunderstandings we should mention explicitly that the
intention of this book is not to give ,the reader instructions in how to develop
good components. This book describes the component architecture of Enterprise
JavaBeans, their practical application, and the requirements that components
must fulfill if they are to be deployed in an EJB server.

13
Chapter 2

Software Components
We would like to offer a definition of software components, cited in [6] as well as
in [17], that represents a relatively neutral middle ground between the very broad
and the very narrow:

A component is a piece of software that is small enough to create and

maintain in one piece and big enough to offer useful and practical
functionality and to justify its separate maintenance; it is equipped
with standardized interfaces that allows it to cooperate with other
components.

First, we simplify the view of a component by imagining it as a sort of Lego

building block. The inner workings of the building block remain hidden from
view. Nonetheless, one can see that it has connectors that allow it to be attached
to other building blocks. A combination of suitable building blocks results in a
structure that serves a particular purpose (a house, a garage, a road). Software
components are also building blocks in that one cannot necessarily see inside
(see Figure 2-4). Each component offers an encapsulated partial functionality (in
analogy to Lego building blocks, such as the frame for a window, a stone as part of
a wall, or a slab for the foundation of a house), while hiding its implementation.
Its functionality can be deduced only from the public interface, which in addition
to allowing it to be used, also permits linkage to other components. As with Lego
building blocks, with software components the crucial property is reusability. A
component that can be used in only one application scenario is not a genuine
component.
A component is distinguished from traditional objects or classes in a number
of ways (see also [6]):

• Components must be able to be used in a variety of application scenarios

and thereby be highly reusable. Thaditional objects, on the other hand, are
developed as a rule for a particular scenario. Furthermore, in fulfilling their
appointed tasks traditional objects frequently make use of other objects
and through this involvement make reusability more difficult.

• As a rule, objects are not big enough to deal with a complete task from
beginning to end. They serve more for structuring and mapping to models.

• The development cost of a component is considerably greater than

that of a traditional object, since with a component one must take into
consideration both reusability in a variety of applications and the ability of
the component to be integrated into a system.

• A component can be used only in a particular way that has been defined
by the public interface. Objects can, by the process of derivation, be altered
(almost) at will.

14
 Fundamentals

Components of a Business Application

Figure 2-4. Example of components in a commercial enterprise.

• Objects also offer the concept of the interface, which as a rule, however,
is narrowly coupled to the underlying system technology and thus limits
interoperability.
Undoubtedly, the close relationship between objects and components is
clear. The object-oriented approach and techniques thus seem to offer the best
basis for the development of components and component-oriented software.
A fundamental concept of the component paradigm is that of the interface.
The interface of a component is a sort of contract whose conditions the
components are obligated to fulfill. It is an interaction point with the components,
documenting their features and capacities. A component can have several
interfaces. Each interface represents a service provided by the component (for a
detailed discussion of interfaces see, for example, [33)). Chapter 3 will show in
detail how this aspect of components is transplanted into Enterprise JavaBeans.
An advantage of component-oriented software development is (as mentioned
previously) in the reusability of cod~. A further advantage is the possibility, with
the aid of completed components, of rapidly developing application prototypes
(for an extensive treatment of this see [9)). The early availability of a prototype
means that in the early stage of development one is already able to confront
design choices; (pilot) customers or (pilot) users can be brought into the
development process at an earlier stage, and so on. The reuse of code in the form
of (mature) software components can lead to a shortening of development cycles
and savings in development costs.

15
Chapter 2

Component Architecture
As mentioned above, Enterprise JavaBeans is a component architecture. The
domains of application and variety of forms of a component architecture can
be quite diverse. Enterprise JavaBeans represents a quite particular variant: a
component architecture for distributed, server-side, and transaction-oriented
components. Thus Enterprise Beans are components that provide services
to many clients on a single server. Without a framework that embeds the
components into a sort of run-time environment and provides them necessary
services, each component that is to be made available over a network would have
to have its own server. This would make the development of such components
much more difficult and if several components were deployed on one computer
would result in an unnecessary strain on its resources. Even the reusability of a
component could thereby become endangered, since servers must frequently
be matched to the underlying platform. A component architecture such as
Enterprise JavaBeans makes possible the deployment of components for
distributed applications without the components themselves being significantly
affected (see Figure 2-5).

Components of a Business Application

Embedded in a Component Architecture

o Communications Point
Figure 2-5. Example ofcomponent architecture.

16
 Fundamentals

Griffel [6] gives a list of requirements that a component architecture

must fulfill:
• Independence of the environment: Components should be deployable
without reference to programming language, operating system, network
technology, etc.
• Locational transparency: For the user of components it should make no
difference whether the component offers its services in the user's local
address space or in the address space of another, remote, computer.
The requisite mechanisms for the transparent use of local or remote
components should be made available via the component architecture.
• Separation of interface and implementation: The specification of a
component should be completely independent of its implementation.
• Self-descriptive interfaces: To achieve a loose coupling of components at
run time, a component should be capable of giving information about its
capabilities and entry points.
• Immediate problem-free usability (Plug & Play): A component should be
usable on any platform without having to be adapted in any way (which
implies a binary independence of the component code).
• Capacity for integration and composition: In combination with other
components, a component should be able to contribute to the creation of
new, usable components.
However, Enterprise JavaBeans is not only a component architecture. The
specification defines a system-technically oriented component model (for the
notion of a component model, see, for example, [6]). This makes possible
the implementation of various types of Enterprise Beans. It defines protocols
for the management of components, for cooperation and communication of the
components among themselves, and for the their use by a client.

JavaBeans Versus Enterprise JavaBeans

A JavaBean is a reusable software component that can be manipulated
visually in a builder tool.
-Sun Microsystems, 1997

JavaBeans is a component model for Java produced by Sun Microsystems.

A JavaBean is essentially a Java class that follows the rules laid down in the
JavaBeans specification. The most important attributes of a bean are its public
interface, the possibility of its being analyzed based on its composition, its

17
Chapter 2

adaptability to individual requirements, and its capacity for persistence (via

object serialization). The public interface consists of the properties of a bean, the
methods that it allows others to use, and the events that it receives or executes.
A bean can be a visible (a button, for example) or an invisible component (for
instance, a network service). listing 2-1 demonstrates a valid JavaBean:

Listing 2-1. Example ofa JavaBean.

public class AValidBean implements AEventListener {

private int aPropertyj
private Vector beanListenersj
public AValidBean()
{
aProperty = -1j
bean Listeners = new Vector()j
}
public void setAProperty(int value)
{
aProperty = valuej
}
public int getAProperty()
{
return aPropertyj
}
public void addBEventListener(BEventListener listener)
{
beanListeners.addElement(listener)j
}

public void removeBEventListener(BEventListener listener)

{
beanListener.remove(listener)j
}
private void fireBEvent() {
BEventListener lj
for(int i = OJ I < beanListener.size()j i++) {
I = (BEventListener)beanListener.elementAt(i)j
l.notify(new BEvent(this»j
}
}

18
 Fundamentals

//Implementation of AEventListener Interface

public void notify(AEvent event)
{
//processing the event
}
}

This bean class is not derived from any class. It does not implement any
standard interface, and is nevertheless a valid JavaBean (only visible JavaBeans
must be derived from java.awt.Component). It simply follows the naming
conventions established in the specification. It has the property a Property, which
can be manipulated and read by the methods setAProperty and getAProperty.
Since it implements the interface AEventListener, it can react to the event
AEvent. It triggers the event BEvent, for which other beans can register via
addBEventListener and unregister via removeBEventListener. By exchanging
events beans can pair with one another dynamically, since they can register and
unregister for particular events at run time. This coupling over events is also a
loose coupling, since the bean is abstracted from the actual type by means of the
corresponding Listener interfaces.
With the naming convention (type) get (property) , void (property) ((type)),
implements (EventType)Listener, void add (EventType)ListenerO, and void
remove(eventTypeListener)O, etc., a builder tool can, for example, analyze
(introspection) the bean with the help of the Java Reflection API with respect to its
properties and the possibility of binding it to events. The tool can place the user
in a position to manipulate the bean visually. Thus the JavaBeans specification
concentrates essentially on the description of the program interface for:

• recognizing and using properties of JavaBeans,

• adaptation of JavaBeans to particular circumstances,

• registering for events and sending then between individual JavaBeans,

• the persistence ofJavaBeans components.

The Enterprise JavaBean specification, on the other hand, focuses on

distributed computing and business transactions. JavaBean objects do not have
a distributed character. The EJB specification describes a service framework for
server-side components. Enterprise Beans are never visible server components.
One may search in vain through the EJB specification for a discussion of
properties and events of an Enterprise Bean, since it describes primarily the
programming interface and the properties of the framework.

19
Chapter 2

Of course, servers can be developed based on traditional JavaBeans. Then,

however, the framework itself, which offers the components the relevant server
utilities and sees to the distribution, would have to be developed. One could,
however, imagine a combination of invisible JavaBeans and Enterprise Beans
in which an Enterprise Bean provides a certain interface in the EJB server and
delegates calls to JavaBeans (for example, by the triggering of JavaBean events).
One should not attempt to seek out too many similarities between the two
models, since in spite of a superficial similarity in name, the two models are quite
different in emphasis. However, JavaBeans and Enterprise Beans are not to be
seen as opposing concepts, but rather as complementary.
The different viewpoints suggested by the words Enterprise, Java, and Beans
will be made more concrete in the remaining chapters of this book. In Chapter 3,
'~chitecture of Enterprise JavaBeans," we shall investigate the extent to which
the EJB specification corresponds to the viewpoint discussed in this chapter.

20
 CHAPTER 3

The Architecture of
Enterprise JavaBeans

IN CHAPTER 2 WE INDICATED that Enterprise JavaBeans (EJB) is a component of the

Java-2 platform, Enterprise Edition (for details see [26]). In this model EJB takes
over the part of the server-side application logic that is available in the form of
components: the Enterprise Beans. This chapter introduces the architecture of
Enterprise JavaBeans. Figure 3-1 shows Enterprise Beans (in their incarnations as
entity, message-driven, and session beans) as the central elements.

Figure 3-1. Overview of the EJB architecture.

Chapter 3

They contain the application logic used by the client programs. Enterprise
Beans reside in an EIB container, which makes a run-time environment available
to them (so that, for example, they can be addressed by client programs via
the home and remote interfaces and have the possibility of communication
among one another via the local home and local interfaces, so that life-cycle
management can be provided). The EJB container is linked to services via the
standard programming interface, services that are available to the bean (for
example, access to databases via JDBC, access to a transaction service via rrA,
and access to a message service via JMS). The EJB container is installed (possibly
in addition to other containers) in an application server.
We shall now go into the details of the individual components of the
architecture and their interrelationships.

The Server
The server is the fundamental component of the EJB architecture. Here we are
deliberately not speaking of an EIB server. Actually, it should be called a I2EE
server. Sun Microsystems' strategy in relationship to enterprise applications
in the framework of the J2EE platform involves Enterprise JavaBeans to a
considerably greater extent in the full portfolio of Java-based programming
interfaces and products than was the case in version 1.0 of the Enterprise
JavaBeans specification.
The specification of Enterprise JavaBeans in version 2.1 does not define any
sort ofrequirement on the server Oust as in versions 1.0 and 1.1). The reason for
this is presumably their stronger integration into the Java 2 platform, Enterprise
Edition (see Figure 3-2).
A J2EE-conforming server is a run-time environment for various containers
(of which one or more can be EJB containers). Each container, in turn, makes
a run-time environment available for a particular type of component. Creators
of Java application servers tend more and more to support the J2EE platform.
There is scarcely a producer who offers a pure EJB server. Many suppliers of
databases, transaction monitors, or CORBA ORBs have meanwhile begun to
support Enterprise JavaBeans.
In the environment of the J2EE platform (and thus indirectly in the EJB
architecture) the server component has the responsibility of providing basic
functionality. This, includes, for example:
• Thread and process management (so that several containers can offer their
services to the server in parallel);
• Support of clustering and load sharing (that is, the ability to run several
servers cooperatively and to distribute client requests according to the load
on each server to obtain the best-possible response times);

22
 The Architecture ofEnterprise JavaBeans

--
B"--··
,,-
......

- • .....
Information
System
~

Figure 3-2. EJB in the context ofJava2, Enterprise Edition.

• Security against breakdown (fail-safe);

• A naming and directory service (for locating components);
• Access to and pooling of operating system resources (for example, network
sockets for the operation of a web container).
The interface between the server and containers is highly dependent on the
producer. Neither the specification of Enterprise JavaBeans nor that of the Java 2
platform, Enterprise Edition, defines the protocol for this. The specification of
Enterprise JavaBeans in version 2.1 assumes that the producer of the server and
that of the container are one and the same.

The EJB Container

The EJB container is a run-time environment for Enterprise Bean components.
Just as an EJB container is assigned to the server as a run-time environment and
service provider, a bean is dependent on its EJB container, which provides it a
run-time environment and services. Such services are provided to the bean via
standard programming interfaces. The specification in version 2.1 obliges the EJB
container to provide at least the following programming interfaces:

23
Chapter 3

• The API (Application Programming Interface) of the Java 2 platform,

Standard Edition, in version 1.4;

• The API of the specification of Enterprise JavaBeans 2.1;

• The API of JNDI 1.2 (Java Naming and Directory Interface);

• The UserTransaction API from ITA 1.0.1 (Java Transaction API);

• The API of the JDBC 2.0 extension (Java Database Connectivity);

• The API ofJMS 1.1 (Java Message Service);

• The API of Java Mail 1.3 (for sending e-mail);

• The API ofJAXP 1.1,1.2 (JavaXMLParser);

• The API ofJAXR and JAX-RPC 1.0 (Java XML Remote Procedure Calls);

• The API ofJava Connectors 1.5;

• The API ofJava Web Services 1.0.

A provider of a Java application server may offer additional services via the
standard interface. Some producers offer, for example, a generic service interface
particular to the producer by means of which specially developed services (such
as a logging service or user management) can be offered. If an Enterprise Bean
uses such proprietary services, then it cannot simply be placed in any available
container.
The EJB container provides Enterprise Beans a run-time environment,
and also offers the Enterprise Beans particular services at run-time, via the
above-mentioned (static) programming interfaces. We now would like to examine
the most important aspects of both domains (that of the run-time environment
as well as that of provided services).

Control of the Life Cycle of a Bean

(Run-Time Environment)
The EJB container is responsible for the life cycle of a bean. The EJB container
generates bean instances (for example, when a client requests one), deploys them
in various states via callback methods, and manages them in pools in case they
will not be needed until a later time. The bean instances are also deleted by the
EJB container. The states and respective methods that lead to a state transition
depend on the type of bean. They are discussed in detail in Chapter 4, "Session
Beans"; Chapter 5, "Entity Beans"; and Chapter 6, "Message-Driven Beans."

24
 The Architecture ofEnterprise JavaBeans

Instance Pooling (Run-Time Environment);

Activation and Passivation
A system that supports mission-critical applications must be capable of dealing
with great demands. It must be capable of serving a large number of concurrent
clients without them having to put up with long response times. The greater the
number of clients, the greater generally the number of objects generated in the
server.
In order to keep the number of bean instances from growing without bound
and to prevent bean instances from continually being created and then destroyed,
an EIB container maintains a certain number of bean instances in a pool. As long
as a bean is in the pool, it is in a Pooled state and is to a certain extent deactivated.
On demand (as a rule, as a result of a client request) the first available bean
instance of the requisite type is taken from the pool. It is reactivated and placed in
a Ready state.
Such instance pooling is common practice in database applications. This
practice has also proved itself in the management of thread objects (such as in
server development). With pooling, fewer bean instances than the number of
client connections are needed, as a rule. By avoiding permanent object generation
and destruction, system performance is enhanced. Instance pooling is closely
connected with the life-cycle management of a bean. Finally, we note that the
specification does not obligate an EIB container to support instance pooling.
A further possibility for the EIB container to save system resources is to make
Enterprise Bean instances that are currently not needed (for example, from object
serialization) persistent and to remove them from memory (passivation). Upon
demand these instances can again be deserialized and made available in memory
(activation). Such a temporary storage of bean instances (those, for example,
for which a certain time period has expired) on secondary media can reduce
the burden on system memory resources. This behavior is similar to that of an
operating system page file.
Whether bean instances can be pooled, activated, or passivated depends on
their type. In the description of bean types in what follows we shall make the
necessary distinctions.

Distribution (Run-Time Environment)

The EJB container ensures that Enterprise Beans can be used by client programs,
which as a rule are not running in the same process. The client does not know on
what server the Enterprise Bean that it is currently using is located. Even when
an Enterprise Bean uses another Enterprise Bean, it is a client. The place where
the Enterprise Bean exists is transparent to the client. The use of an Enterprise

25
Chapter 3

Bean on another computer is not essentially different for the client from the use
of objects that are located in the same address space.
For distributed communication between the various parties, Java Remote
Method Invocation (Java RMI) is used. To achieve interoperability among applica-
tion servers supplied by different manufacturers the EJB specification prescribes
support for the communications protocol of the CORBA specification, IIOp, for
an EJB container that conforms to specifications. Distributed communication
thus takes place over the protocol RMI-IIOP (RMI over IIOP). In no case does the
developer of an Enterprise Bean have to worry about the bean being able to be
accessed from outside. This is the sole task of the EJB container.
This book assumes that the reader is already familiar with the techniques of
remote method invocation (or else see [13] and [4] for information on RMI). In
particular, the reader should understand the notions of stub and skeleton.
Since version 2.0 of the Enterprise JavaBeans specification the client has had
the ability to communicate with an Enterprise Bean via the Local interface. In
many applications it is necessary that Enterprise Beans, all of which are installed
in the same EJB container (aggregation of components), communicate with one
another. In version 1.1 of the EJB specification this means a remote call to a
component located in the same address space. The overhead of the RMI protocol
is unnecessary, and it leads to a degradation of performance. The advantage of
using local interfaces is that RMI is thereby completely ignored. Local interfaces
can then be sensibly used only if client and Enterprise Bean are located in the
same address space of a Java virtual machine. The location of the Enterprise Bean
is thus no longer transparent to the client. Transparency of location applies only
to EJB components that are called over the remote interface. Furthermore, the
semantics of a method call to a component are altered when a local interface is
used. With calls to the local interface, parameters are passed via call by reference,
while calls to the remote interface use call by value.
The various chapters on various types of beans will deal extensively with the
difference between the remote and local interfaces and will delve deeply into the
viewpoint of the client with respect to an Enterprise Bean.

Naming and Directo~ Service (Service)

If a client wishes to find a bean, it is directed to a naming interface. A naming
service offers the possibility of associating references to removed objects under a
particular name, which may be assigned arbitrarily, at a definite place (binding).
It also offers the possibility oflooking up the object bound to the naming service
under that name Oookup). This is similar to the white pages, whereby one looks
up an object by name.

26
 The Architecture ofEnterprise ]avaBeans

A directory service is more powerful than a naming service. It supports not

only binding of references to a name, it can also manage distributed objects
and other resources (such as printers, files, application servers) in hierarchical
structures, and it offers wide-ranging possibilities for administration. With a
directory service a client can be provided with additional descriptive information
about a reference to a remote object. This is similar to the yellow pages, whereby
one looks up an object by its attributes.
The interface over which the naming and directory services are accessed
is JNDI (Java Naming and Directory Interface). The bean, too, can receive
information via the naming and directory service. The EJB container provides
the bean instance information, for example, that was established at the time
of installation of the component (so-called environment entries). In this
way it is possible to influence the behavior of Enterprise Beans by external
parameterization. The bean also has the possibility of accessing particular
resources, such as database connections or a message service, via the naming
and directory services.

Persistence (Service)
The EJB container provides the beans, via the naming and directory services,
the possibility of accessing database connections. Beans can thereby themselves
ensure that their state is made persistent. However, the specification of Enterprise
JavaBeans provides for a mechanism by which the state of certain Enterprise Bean
types can be made persistent automatically. (We shall return to this mechanism
in Chapter 5, "Entity Beans.")
As a rule, in the case of automatic storage of the state of Enterprise Beans by
the EJB container the data are made persistent in a database. One can imagine
other EJB containers that provide persistence mechanisms that place the data
in other storage systems (for example, in the file system or electronic archives).
There is also the possibility of developing EJB containers that make use of the
interfaces of other application systems in order to read or write data from or to
that location. Thus, for example, the data in an old main-frame system can be
bound by means of special EJB containers to component-oriented systems (the
container then acts to a certain extent as a wrapper for the old systems).
However, what is really at issue is that in the case of automatic persistence of
an Enterprise Bean, the bean couldn't care less where the data are stored. The EJB
container takes on the task of ensuring that the data are stored and remain in a
consistent state. Thus a particular bean can be installed in various EJB containers
that support varying storage systems as persistence medium. For the Enterprise
Bean the persistence remains transparent. It doesn't know where its data are
stored or where the data come from that the EJB container uses to initialize it.

27
Chapter 3

Transactions (Service and Run-Time Environment)

Transactions are a proven technique for simplifying the development of dis-
tributed applications. Among other things, transactions support the applications
developer in dealing with error situations that can occur from simultaneous
access to particular data by multiple users.
A developer who uses transactions splits up the actions to be executed into
atomic units (transactions). The transaction monitor (the EJB container) ensures
that the individual actions of a transaction are all executed successfully. If an
action fails, the successful actions thus far executed are canceled.
The support of transactions is a fundamental part of the specification
of Enterprise JavaBeans. In distributed systems in which several users work
simultaneously on many separate actions with the same data (which may be
distributed among several back-end systems), a transaction service on the level
of the application server is unavoidable. It is the task of the EJB container to
ensure that the necessary protocols (for example, the two-phase commit protocol
between a transaction monitor and a database system, context propagation,
and a distributed two-phase commit) for handling transactions are available.
The specification of Enterprise JavaBeans supports flat transactions; that is,
transactions cannot be nested.
The developer of an Enterprise Bean can choose how he or she wishes
to use transactions. On the one hand, transactions can be used explicitly, by
communicating over ITA directly with the transaction service of the EJB container.
Alternatively, the developer can opt for declarative (or implicit) transactions. In
this case, at the time of installation of an Enterprise Bean in the EJB container it is
specified what methods should run within which transactions. The EIB container
intervenes when these methods are called, and it ensures that they are called
within the appropriate transaction context.
In the case of declarative transactions the bean developer does not need
to be concerned with manipulating the transactions. During installation in EJB
container A, a bean can be installed with a completely different transactional
behavior from that during installation in EJB container B. The bean itself remains
untouched in each case, since in every case the container remains responsible
for guaranteeing the desired transactional behavior. Much more detail on
transactions in the EIB context is to be found in Chapter 7, "Transactions."

Message (Service)
With version 2.0 of the specification of Enterprise JavaBeans the EJB container
is obligated to integrate a message service via JMS-API (Java Message Service).
With the definition of a new bean type-the message-driven bean-the message
service is integrated into the EIB container in a significant way. The development

28
 The Architecture ofEnterprise JavaBeans

of applications based on Enterprise JavaBeans thus gains two additional

dimensions: asynchronicity and parallel processing.
Basically, a message system enables the asynchronous exchange of messages
among two or more clients. In contrast to the case of a client-server system,
here the architecture of a message system is designed around a loose coupling of
equal partners. Each client of the message system can send and receive messages
asynchronously. The sender of a message remains largely anonymous, and the
same holds for the recipient. Message systems are also known under the name
message-oriented middleware (MOM).
In addition to the use of message-driven beans, the message service can,
of course, also be used for asynchronous message exchange between any two
parties. Enterprise Beans, like clients, can also send messages. Through the use of
messaging, processes can, for example, decouple from each other or even create
interfaces to other systems, making it an excellent component for enterprise
integration.
Chapter 6 offers a fuller discussion of Java Message Service message-
driven beans.

Security (Run-Time Environment)

The specification obligates the EJB container to provide Enterprise JavaBeans an
infrastructure for security management as a part of the run-time environment.
It is the task of the system administrator and of the installer of the Enterprise
Beans to establish security policy. Once again, the EJB container is responsible
for the implementation of this security policy. The goal here is (as with container-
managed automatic persistence and declarative transactions) to make the
security mechanisms transparent to the Enterprise JavaBeans, so that they can be
deployed in as many systems as possible.
If the security strategy were implemented in the bean, it would be problematic
to employ the same bean under both more- and less-strict security requirements.
On the other hand, it makes much more sense to place the security mechanisms
in the run-time environment of the components. They are thereby reusable
to a great extent, and the security policy can be adapted from the outside as
the situation warrants. The specification of Enterprise JavaBeans specifically
mentions that it is preferable that no logic relating to security be present in the
code of a bean.
It is possible to define user roles. In every Enterprise Bean particular
permissions can be assigned to a particular role. The assignment takes place, as
with the establishment of the user roles, at one of the following times:
• The time of bean installation;
• The time at which several beans are combined into an aggregate.

29
Chapter 3

Permissions are focused essentially on whether the user is permitted to call

particular methods of an Enterprise Bean. At run time the EJB container
determines whether a client call to a bean method should be allowed to be
executed. To this end it compares the role of the client with the permissions of the
respective Enterprise Bean method.
As a rule, in addition to the security mechanisms that we have described, an
EJB container offers the following security attributes:
• Authentication of the user by a user ID and password;
• Secure communication (for example, via the use of secure socket layers).
Chapter 8 contains a more detailed discussion of security in relation to Enterprise
JavaBeans.
Finally, we note that the EJB container is the central instance in the
component model of Enterprise JavaBeans. It provides the Enterprise Beans
(the components) a convenient run-time environment at a very high level of
abstraction and makes a variety of services available by way of standard interfaces.

The Persistence Manager

The persistence manager is the building block in the architecture of Enterprise
JavaBeans that enables the automatic persistence of particular components.
It was introduced with version 2.0 of the EJB specification to achieve a better
separation of the physical data storage from the object model. The goal was to
improve the portability of persistent EJB components to application servers of
other manufacturers. Moreover, improvements were introduced for the mapping
of a persistent component onto the storage medium, as well as the possibility
of constructing declarative relations between persistent components and an
abstract query language. In version 1.1 one was often forced, in the situation of
automatic container-governed persistence, to rely on the use of proprietary tools
(object-relational "OR" mapping tools) or the use of proprietary extensions of the
EJB container, with the result that the portability of the components was greatly
compromised.
As always, persistence is managed by the EJB container; that is, it determines
when the data of a component are loaded or stored. The EJB container also
determines whether in the case of an action's failure a successfully executed
saving operation should be undone (transaction). The persistence manager,
on the other hand, is responsible for where and how the persistent data are
stored. It takes over communication with the storage medium (for example, a
database). The mapping of the persistent data of an Enterprise Bean onto the
storage medium (for example, the mapping onto one or more database tables)
is determined at the installation of a component. The persistence manager

30
 The Architecture o/Enterprise JavaBeans

plays no role when the Enterprise Bean itself looks after persistence or when the
components possess no persistent data.
In most cases a database is used for storing data. In spite of the ANSI SQL
standard the databases of different producers are not one hundred percent
compatible with one another. For example, they use different key words in the
syntax of their query languages. It is usual that particular database functions
that distinguish one database from those of other producers are usable only
with proprietary extensions of the standard query language SQL. The persistence
manager is supposed to catch these difficulties as well. Depending on the
implemented database, a specialized persistence manager can be used that is
able to deal with the peculiarities of the database system.
A further responsibility of the persistence manager is the formulation of
search queries. With knowledge of the mapping of the data and of the peculiarities
of the storage medium in use it can translate abstract search queries into concrete
search queries. For the formulation of abstract search queries for finding EJB
components the specification of Enterprise JavaBeans offers a query language
called EJB-QL (Enterprise JavaBeans Query Language). EJB-QL was introduced in
version 2.0 of the EJB specification and is further enhanced in version 2.1.
The persistence manager and the query language EJB-QL are dealt with
extensively in Chapter 5.

Enterprise Beans
Enterprise Beans are the server-side components used in the component
architecture of Enterprise JavaBeans. They implement the application logic
on which the client programs rely. The functionality of the server and the EJB
container ensures only that beans can be used. Enterprise Beans are installed in
an EJB container, which offers them an environment at run time in which they
can exist. Enterprise Beans rely implicitly or explicitly on the services that the EJB
container offers:

Implicitly In the case of

• container-managed persistence (CMP);
• declarative transactions;
• security.
Explicitly In the case of
• The use of explicit transactions;
• bean-managed persistence (BMP);
• the sending of asynchronous messages.

31
Chapter 3

Types of Enterprise Beans

There are three different forms of Enterprise Beans, which differ more or less
sharply one from the other: entity beans, message-driven beans, and session
beans. Table 3-1 describes the basic differences among these three types of
Enterprise Beans.

Table 3-1. Defining characteristics distinguishing session, message-driven, and entity

Beans (see [25]).

Session Bean Message-Driven Bean Entity Bean

Task of the Represents a server- Represents server- Represents an enter-
bean side service that side enterprise logic prise object whose
executes tasks for a for the processing data are located in
client. of asynchronous permanent storage.
messages.
Access to the A session bean is a pri- A message-driven An entity bean is a
bean vate resource for the bean is not directly central resource; the
client, available to the accessible to the bean instance is used
client exclusively. client. Communi- simultaneously by
cation is effected several clients, and its
exclusively via send- data are available to
ing messages over a all clients.
particular channel of
the message service.
Persistence Not persistent. When Not persistent. When Persistent. When
of the bean the bound client or the server is termi- bound clients or
server is terminated, nated, the bean is server is terminated,
the bean is no longer no longer accessible. the state of the en-
accessible. The messages that tity bean is located in
have not yet been de- a persistent storage
livered to the bean medium. The bean
are persistent as re- can be recreated at a
quired. (More on this later time.
in Chapter 6.)

Session beans model ordinary processes or events. For example, this could be
the entering of a new customer in an enterprise resource planning system (ERP),
the execution of a booking in a booking system, or setting a production plan
based on open orders. Session beans can be viewed as an extension of the client's
arm toward the server. This point of view is supported by the fact that a session
bean is a private resource of a particular client.
Entity beans, on the other hand, represent objects in the real world that
are associated with particular data, such as a customer, a booking account, or a
product. An instance of a particular entity bean type can be used simultaneously
by several clients. Session beans usually operate on data represented by entity
beans.

32
 The Architecture o/Enterprise JavaBeans

Message-driven beans are recipients of asynchronous messages. A message

service acts as a mediator between the sender of a message and the message-
driven bean. Entity and session beans are addressed via the remote or local
interface. Calls to entity or session beans are synchronous; that is, the execution
of the client is blocked until the method of the Enterprise Bean has been
processed. After the method call has returned, the client can continue its
processing. Message-driven beans can be addressed by the client only (indirectly)
by sending a message over a particular channel of the message service. A
particular type of message-driven bean receives all messages that are sent over
a particular channel of the message service. Communication over a message
service is asynchronous. That is, the execution of the client can proceed directly
after a message is sent. It does not remain blocked until the message has
been delivered and processed. The container can deploy several instances of a
particular message-driven bean type for the processing of messages. Thus in this
case parallel processing is possible. Message-driven beans have no state between
the processing of several messages. Furthermore, they have no identity vis-a-vis
the client. In a certain sense the are similar to stateless session beans (see the
following paragraph). For the processing of a message, message-driven beans can
use session or entity beans as well as all services that the container offers.
There is another distinction to be made with regard to session beans, namely,
whether a session bean is stateless or stateful. Stateless session beans do not store
any data from one method call to the next. The methods of a stateless session
bean operate only with the data that are passed to it as parameters. Stateless
session beans of the same type all possess the same identity. Since they have no
state, there is neither the necessity nor the possibility of distinguishing one from
the other.
Stateful session beans, on the other hand, store data over many method calls.
Calls by methods to stateful session beans can change the state of the bean. The
state is lost when the client is no longer using the bean or when the server is
taken down. Stateful session beans of the same type have differing identities at
run time. The EIB container must be able to distinguish them, since they have
differing states for their clients.
A session bean receives its identity from the EIB container. In contrast to
entity beans, the identity of a session bean is not externally visible. Since clients
always work with a session bean that for them is an exclusive instance, there is no
need for such visibility.
Entity beans can be distinguished by whether they themselves are responsible
for making their data persistent or whether the EIB container takes over this task.
In the first case one speaks of bean-managed persistence, while in the second the
talk is of container-managed persistence.
Entity beans of the same type have differing identities at run time. An entity
bean of a particular type is identified at run time by its primary key, which is

33
Chapter 3

allocated by the EJB container. It is thereby bound to particular data, which it

represents in its activation phase. The identity of an entity bean is outwardly
visible.
The bean types playa role in resource management of the EJB container. With
entity beans, message-driven beans, and stateless session beans the container can
instigate pooling, while with stateful session beans it can instigate passivation and
activation (serialization and deserialization onto a secondary storage medium).
The interface between an entity bean and the EJB container is called the
context (javax. ejb. EJBContext). This interface is again specialized for the three
bean types (to javax.ejb.EntityContext, javax.ejb.MessageDrivenContext, and
javax.ejb.SessionContext). The bean can communicate with the container
using the context that is passed by the EJB container to the bean. The context
remains bound to a bean during its entire life span. By means of the context the
EJB container manages the identity of an Enterprise Bean. With a change in the
context the EJB container can change the identity of a bean.
Chapters 4,5, and 6 provide an extensive discussion of the technical details of
session, message-driven, and entity beans. The second section of Chapter 9 deals
with the differing semantics of the various bean types.

Components of an Enterprise Bean

An Enterprise Bean possesses the following components:

• The remote interface and the (remote) home interface or

the local and local home interface (for entity and session beans);
• The bean class (for entity, message-driven, and session beans);
• The primary key or primary key class (for entity beans);
• The deployment descriptor (for entity, message-driven, and session beans).
One speaks of the remote client view when an Enterprise Bean is addressable
over the remote interface. If an Enterprise Bean uses the local interface, one
speaks of the local client view. Basically, an Enterprise Bean can support both the
local and remote client views. However, the specification advises that one choose
one of the two cases.
Let us describe the individual components of a bean by way of an example.
We would like to develop an entity bean that represents a bank account.
The components should make it possible to ascertain the account number, a
description of the account, and the current balance of the account. Furthermore,
the balance of the account should be capable of being raised or lowered by an
arbitrary amount. The bank-account bean should be able to be addressed by the
remote client, that is, from a client that is located outside the address space of the
bank-account bean.

34
 The Architecture ofEnterprise JavaBeans

This chapter concentrates on the representation of the special features

determined by the architecture. In this example we shall not go into the special
features of a particular bean type (that will be done extensively in Chapters 4, 5,
and 6). Since an entity bean exhibits all the components mentioned above, it is
best suited for this introductory example. Moreover, we shall not use the local
interface in this example. Since EJB is a distributed component architecture, the
use of the remote interface is standard. The use of the local interface is analogous
to that of the remote interface, and it will be dealt with in Chapters 4 and 5.

Remote Interface
The remote in!erface defines those methods that are not offered externally
by a bean. The methods of the remote interface thus reflect the functionality
that is expected or demanded by the components. The remote interface
must be derived from javax.ejb.EJBObject, which in turn is derived from
java. rmi. Remote. All methods of the remote interface must declare the exception
java. rmi. RemoteException. See listing 3-1.

Listing 3-1. Remote interface ofBankAccount.

package ejb.bankaccountj
import java.rmi.RemoteExceptionj
import javax.ejb.EJBObjectj
public interface BankAccount extends EJBObject
{
Ilascertain account number
public String getAccNumber()
throws RemoteExceptionj
Ilascertain account description
public String getAccDescription()
throws RemoteExceptionj
Ilascertain account balance
public float getBalance()
throws RemoteExceptionj
Ilincrease account balance
public void increaseBalance(float amount)
throws RemoteExceptionj
Ilreduce account balance
public void decreaseBalance(float amount)
throws RemoteExceptionj
}

35
Chapter 3

Home Interface
The home interface must be derived from javax.ejb.EJBHome (in this interface
is to be found the method for deleting a bean; it does not need to be separately
declared). EJBHome, for its part, is likewise derived from javax.rmi.Remote. In
the home interface as well all methods declare the triggering of an exception of
type java. rmi. RemoteExeption. As in the case of the remote interface, everything
points to the distributed character and the embedding in the BJB framework. See
Listing 3-2.

Listing 3-2. The home interface ofBankAccount.

package ejb.bankaccountj
import java.rmi.RemoteExceptionj
import javax.ejb.CreateExceptionj
import javax.ejb.EJBHomej
import javax.ejb.FinderExceptionj
public interface BankAccountHome extends EJBHome
{

Ilgenerate an account
public BankAccount create(String accNo,
String accDescription,
float initialBalance)
throws CreateException, RemoteExceptionj

//find a particular account

public BankAccount findByPrimaryKey(String accPK)
throws FinderException, RemoteExceptionj

Bean Classes
Bean classes implement the methods that have been declared in the home and
remote interfaces (with the exception of the findByPrimaryKey method), without
actually implementing these two interfaces. The signatures of the methods of the
remote and home interfaces must agree with the corresponding methods in the
bean class. The bean class must implement an interface that depends on its type,
and indeed, it must be javax. ejb. EntityBean, javax. ejb.MessageDrivenBean, or
j avax. ej b. Session Bean. The bean implements neither its home nor its remote

36
 The Architecture ofEnterprise JavaBeans

interface. Only in the case of an entity bean with container-managed automatic

persistence is the class abstract. The classes of session, message-driven, and entity
beans, which manage their own persistence, are concrete classes. See listing 3-3.

Listing 3-3. Bean class ofBankAccount.

package ejb.bankaccount;
import javax.ejb.CreateException;
import javax.ejb.EntityBean;
import javax.ejb.EntityContextj
import javax.ejb.RemoveExceptionj
public abstract class BankAccountBean implements EntityBean {
private EntityContext theContextj
public BankAccountBean() {
}
//the create method of the home interface
public String ejbCreate(String accNo,
String accDescription,
float initialBalance)
throws CreateException
{
setAccountNumber(accNo)j
setAccountDescription(accDescription);
setAccountBalance(initialBalance);
return null;
}
public void ejbPostCreate(String accNo,
String accDescription,
float initialBalance)
throws CreateException
{
}
//abstract getter/setter methods
public abstract String getAccountNumber();
public abstract void setAccountNumber(String acn);
public abstract String getAccountDescription();
public abstract void setAccountDescription(String acd);
public abstract float getAccountBalance();
public abstract void setAccountBalance(float acb);

37
Chaprer3

lithe methods of the remote interface

public String getAccNumber() {
return getAccountNumber()j
}
public String getAccDescription() {
return getAccountDescription()j
}
public float getBalance() {
return getAccountBalance()j
}
public void increaseBalance(float amount) {
float acb = getAccountBalance()j
acb += amountj
setAccountBalance(acb)j
}
public void decreaseBalance(float amount) {
float acb = getAccountBalance()j
acb -= amountj
setAccountBalance(acb)j
}
lithe methods of the javax.ejb.EntityBean interface
public void setEntityContext(EntityContext ctx) {
theContext = ctXj
}
public void unsetEntityContext() {
theContext = nullj
}
public void ejbRemove()
throws RemoveException
{
}
public void ejbActivate() {
}
public void ejbPassivate() {
}
public void ejbLoad() {
}
public void ejbStore() {
}
}

38
 The Architecture ofEnterprise JavaBeans

Primary Key (Primary Key Class)

The primary key is relevant only for entity beans. Its purpose is to identify an
entity of a particular type uniquely. As in the case of the primary key of a database
table, it contains those attributes that are necessary for unique identification.
With the primary key a particular entity can be found, which then is associated
by the EJB container with an entity bean instance of the correct type. With the
primary key the identity of ari entity bean is externally visible. The primary key
class is irrelevant for session and message-driven beans, since their identity is
never externally visible. The specification distinguishes two types of primary keys:
• primary keys that refer to a field of the entity bean class;
• primary keys that refer to several fields of the entity bean class.
A primary key that refers to only a single field of the entity bean class
can be represented by a standard Java class (for example, java .lang. String,
java. lang. Integer). In our example the class java. lang. String is the primary
key class, since the unique identification of an account is possible via its
(alphanumeric) account number.
A primary key that refers to several fields of the entity bean class is
represented, as a rule, by a class specially developed for that purpose. Such a class
must be a public class, and it must have a public constructor without arguments.
The fields of the primary key class that represent the primary key of the entity
bean must address those of the entity bean class by name. Furthermore, these
fields must also be public. The class must be RMI-IIOP compatible (serializable),
and it must implement the methods equals ( ) and hashCode ( ). Listing 3-4 shows
an example of such a primary key class for an account bean that requires for its
unique identification the number of the client as well as the account number
(client-capable system).

Listing 3-4. Example ofa primary key class for multipart keys.

package ejb.custom:
public class CustomAccountPK implements java.io.Serializable
{
public String clientNumber:
public String accountNumber:
public CustomAccountPK() {
}
public int hashCode() {
return clientNumber.hashCode() A

accountNumber.hashCode():
}

39
Random documents with unrelated
content Scribd suggests to you:
The Project Gutenberg eBook of Die seltsamen
Geschichten des Doktor Ulebuhle
 This ebook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this ebook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.

Title: Die seltsamen Geschichten des Doktor Ulebuhle

Author: Bruno Hans Bürgel

Illustrator: Edmund Fürst

Release date: October 14, 2020 [eBook #63460]

Language: German

Credits: Produced by Jens Sadowski

*** START OF THE PROJECT GUTENBERG EBOOK DIE SELTSAMEN

GESCHICHTEN DES DOKTOR ULEBUHLE ***
Die seltsamen Geschichten
des
Doktor Ulebuhle
Zeichnungen
von
Edmund Fürst
Die seltsamen Geschichten
des

Doktor Ulebuhle
Ein
Jugend- und Volksbuch
von

Bruno H. Bürgel

1920

Verlag Ullstein & Co, Berlin

 Alle Rechte vorbehalten
Copyright 1920 by Ullstein & Co
Berlin
 Inhalt
Ein Vorwort für die Großen VII
Vom Doktor Ulebuhle 1
Die versunkene Stadt 6
Der Wassertropfen 16
Gespenster-Heinrich 30
Der Diamant und seine Brüder 44
Der alte Baum 56
Johann der Wunderbare 60
Das Zündholz und die Kerze 73
Der Weltuntergang 83
John Dolland, der Taucher 87
Das Herz und die Taschenuhr 110
Ein Tag auf dem Monde 115
Die Schwalbe und der Telegraphenpfahl 135
Der Eisberg 142
Die Busennadel 151
Der Tod in der Flasche 161
Als die Sonne feierte 176
Der gläserne Sarg 184
Gebrüder Sturm 188
Die sonderbare Welt 211
 Ein Vorwort für die Großen
Der deutschen Kinderwelt steht eine Fülle von wundervollen
Märchendichtungen zur Verfügung. Sie alle sind so gemütvoll,
anziehend und phantasiereich, ja zum Teil (insbesondere für den
Erwachsenen) so reich an ernsten Gedankengängen, daß sie auch in
unserer immer materialistischer werdenden Zeit das Herz des Kindes
wie des Erwachsenen, der sich ein Plätzchen für das Stille und
Beschauliche bewahrt hat, mit Freude erfüllen werden.
Dennoch entgeht es wohl dem tiefer Blickenden nicht, daß die
Jugend des zwanzigsten Jahrhunderts, insbesondere die
Großstadtjugend, und auch da wieder vor allem die Buben, sobald
der erste Schmelz der Kindlichkeit dahin ist, kein rechtes Verhältnis
mehr zu diesen Märchen gewinnt. Es geht dem alten poesievollen
Märchen so ähnlich wie dem so reizenden Kasperletheater unserer
eigenen Jugendtage: Die oft recht wenig poesievolle und noch
weniger zum Kinderherzen sprechende flimmernde Leinwand hat es
zum alten Eisen geworfen.
Die Zeiten haben sich geändert! Man kann das bedauern, aber
schwer ungeschehen machen. Das Kind des zwanzigsten
Jahrhunderts hat einen starken Wirklichkeitssinn und eine große
Hinneigung zu technischen Dingen, mit denen es ja auch tagtäglich
– zum mindesten in größeren Orten – in engste Berührung kommt.
Kein Wunder, daß es mit einer mechanischen Eisenbahn lieber spielt
als mit dem hölzernen Harlekin, der einmal unsere Freude war, und
kein Wunder auch, wenn es spannend geschriebene Erzählungen, in
denen moderne technische Wunder und aufregende Abenteuer eine
Rolle spielen, lieber liest als das Märchen vom Wolf und vom
Rotkäppchen, das sein Wirklichkeitssinn einfach als „unsinnig“
beiseite schiebt, während wir Großen erst wieder das Symbolische
darin zu würdigen wissen.
Aus solchen Erwägungen heraus sind die vorliegenden
Geschichten entstanden. Es sind gewissermaßen
naturwissenschaftliche Märchen. Märchen nur der Form nach; ihr
Kern besteht aus leicht faßlichen naturwissenschaftlichen und
technischen Erkenntnissen und Erfahrungen, und wenn die Kinder
dieses Buch mit einigem Interesse (wie ich hoffen darf) gelesen
haben werden, so haben sie eine ganze Masse dabei gelernt und
sich doch gut unterhalten. Auch der Humor und eine kleine
moralische Nutzanwendung kommen da und dort zu ihrem Recht.
Als ich vor nunmehr zwanzig Jahren zum erstenmal den Versuch
machte, in der hier vorgetragenen Weise das „Märchen des
zwanzigsten Jahrhunderts“ zu schaffen, fanden die wenigen Proben
eine so allgemein günstige Aufnahme, daß ich den oft mir
geäußerten Wünschen, einen ganzen Band solcher Erzählungen
herauszugeben, glaubte nachkommen zu sollen. Wozu mir schöne
Friedensjahre nicht Zeit ließen, das entstand dann in langen
Kriegsjahren draußen „an französischen Kaminen“. Im Kriege
ersonnen, in Revolutionstagen niedergeschrieben, mögen diese
Erzählungen, das ist mein Wunsch, den deutschen Kindern, die nicht
minder schwer als wir Großen die Härte der Zeit gespürt, ein wenig
Freude und ein wenig Sonnenschein bringen.
Bruno H. Bürgel
Neubabelsberg bei Potsdam
 Vom Doktor Ulebuhle
Meine lieben jungen Freunde! Ehe ihr nun die Geschichten des
Doktor Ulebuhle lest, wollt ihr sicher auch wissen, wie sie denn
zustande gekommen sind, und was es mit dem Ulebuhle für eine
Bewandtnis hat. Eigentlich hieß er gar nicht so, und wie in Wahrheit
sein Name war, das haben die Kinder nie erfahren, oder sie hatten es
wieder vergessen, aber so viel weiß ich, daß er ein schnurriger Kerl
war, so schnurrig wie der Name, den ihm die Leute gegeben hatten.
Da unten im Harzgebirg mit seinen dunklen Tannenbergen liegt
die alte Kaiserstadt Goslar, mit ihren uralten spitzen Türmen,
seltsamen Torbogen und engen Gassen mit wunderlichen,
jahrhundertealten Häusern am Fuße des Rammelsberges, in dem
tief, tief unter der Erde die Bergleute pochen. Vor vielen Jahren lebte
da der Doktor Ulebuhle. Er bewohnte ganz allein eines jener etwas
windschiefen, mittelalterlichen Häuser, die verwundert aus ihren vom
Alter fast erblindeten winzigen Fensterchen in die neue Zeit
hineinblinzeln. Oben auf dem Hause war ein Turm, gedeckt mit
lauter Schiefertafeln, fast so wie die, mit denen wir Buben zur Schule
zogen, und da oben hatte Ulebuhle ein großes Fernrohr stehn, mit
dem man den Mond und die Kometen betrachten konnte. Und dann
waren da im Hause ein paar ganz einfache Zimmerchen, mit alten
Möbeln und seltsamen Uhren und allerlei Schnickschnack, und eines
davon war ganz mit Büchern vollgestopft, daß man nicht wußte,
wohin man treten und wohin man sich setzen könnte. Nebenan sah
es noch viel toller aus! Das wahre Museum. Ausgestopfte Tiere,
versteinerte Fische und Schnecken, Tiergeripp und Totenbein, und
Schmetterlingssammlungen und seltene Käfer. Erdglobus und
Himmelsglobus, Elektrisiermaschinen und Mikroskope, hundert
Instrumente und weiß der Teufel was noch für Krimskrams.
 Und da hauste der alte Ulebuhle ein Leben lang wie ein Maulwurf
in seinem Bau. Er hatte keine Frau und keine Kinder; ein ganz altes
Weiblein mit einer großen schwarzen Haube besorgte alles und war
der einzige Mensch, mit dem sich Ulebuhle vertrug, denn er war ein
rechter alter Knurrhahn.
Und wenn ihr nun fragt, wie er ausgesehen hat, der Doktor
Ulebuhle, so muß ich sagen, höchst schnurrig! Er war so groß, daß
er kaum durch die niederen Türen des alten Hauses ging, und dürr
wie ein Pfeifenrohr. Das Alter hatte sein Gesicht in tausend Runzeln
zerrissen, es war bartlos und von vielem Tabakrauch gebräunt wie
eine alte Meerschaumpfeife, und eisengraues Haar bedeckte das
Haupt. Was aber ganz putzig aussah und uns Kindern als das
Sonderbarste vom Sonderbaren erschien, das war das kleine
Zöpfchen, das dem guten Ulebuhle hinten über den Rockkragen
baumelte. Ein Zöpfchen, nicht länger und kaum dicker als ein
Rattenschwanz, eisengrau, und mit einer winzigen schwarzen
Schleife nahe der Spitze. Mein Vater sagte mir zwar, und aus alten
Büchern könnt ihr das ja auch an den Bildern sehen, früher hätten
die Männer alle so kleine Zöpfchen getragen, und der gute alte
Ulebuhle, der schon fast siebenzig Jahre alt war, habe es sich nur
nicht mehr abgewöhnen wollen, als die neue Mode kam und eines
Tages schnipp-schnapp die ganzen Zöpfe von der großen Schere der
Zeit weggeputzt wurden, aber das ist egal, es sah doch zu schnurrig
aus. Zudem trug er auch noch eine mächtige Hornbrille, mit großen
runden Gläsern, und wenn er dann so bedächtig mit den
Augendeckeln klappte, dann sah das in Verbindung mit der Brille und
der scharfen Hakennase aus wie bei einer Eule oder „Ule“, wie die
Leute da unten sagen. So aber war auch sein seltsamer Name
entstanden. Eigentlich hieß er nur Doktor Buhle, für uns aber war er
nur der Ule-Buhle, und dabei blieb es!
In einem langen grauen zugeknöpften Rock, Sommer und Winter
mit buntkarrierten Filzschuhen an den Füßen, saß der Doktor
Ulebuhle so, aus der langen Pfeife blaue Rauchwolken von sich
stoßend, über seinen Büchern, seinen Instrumenten, und kümmerte
sich um keinen Menschen in der weiten Welt.
 Aber wenn er auch wunderlich aussah, und wenn die Leute auch
verstohlen über ihn lachten, sie zogen doch tief den Hut vor ihm,
wenn er mal aus dem Fenster schaute oder in seinem Garten die
Bäume beschnitt, denn er war ein Mann, der so viel wußte wie
keiner in weiter Runde, die Lehrer und den Pfarrer, die Ärzte und den
Bürgermeister mit eingeschlossen, und das will was heißen, denn
von denen wollte doch auch einer immer mehr wissen wie der
andere. Er hatte viele gelehrte Bücher geschrieben, und aus fernen
Ländern schickten berühmte Professoren, die so weise waren, daß
sie sich Tonnenbänder um den Kopf legen lassen mußten, damit er
nicht vor lauter Wissen auseinandersprang, Briefe an unseren
Ulebuhle und baten um seinen Rat.
Wie aber, so werdet ihr fragen, kam nun der Doktor Ulebuhle
dazu, diese Geschichten zu erzählen?
Das ging so zu: Da, wo das Haus des Doktor Ulebuhle stand, war
ein freier Platz, und ein Brunnenbecken stand darauf. Hier aber
versammelten wir Kinder uns am liebsten und lärmten da umher, wie
eine Schar Spatzen im Kirschenbaum. Das aber war schrecklich für
den Alten! Es störte ihn ganz gräßlich bei seinem gelehrten Tun, und
als all sein Schimpfen nichts half, da versuchte er es auf einem
anderen Wege. Er ließ uns einst, als wir an einem Sommerabend
wieder um den Brunnen jagten, von der alten Dienerin heraufholen,
was ihm aber nur bei den Mutigsten zunächst gelang. Mit einem
seltsamen Schauder und mit einer noch größeren Neugierde
betraten wir das sonst so fest für jedermann verschlossene Haus.
Ulebuhle aber hielt uns eine lange Rede. Wir wären zwar allesamt
Taugenichtse, die noch einmal ein übles Ende nehmen würden,
sagte er in einem seltsam knurrigen Ton, aber er wolle uns alle
Sonntagabend bei Kuchen und Tee schöne Geschichten erzählen,
durch sein Fernrohr den Mond und die Sterne zeigen und andere
Dinge, wenn wir versprächen, künftig nicht mehr um den Brunnen
zu tollen und Bälle in den Garten zu werfen.
Und so geschah’s! Erst kamen nur wenige, dann mehr, und
schließlich alle. Und die Geschichten waren sehr interessant, der
Kuchen voller Rosinen, und um den Brunnen war es still geworden,
denn keiner wollte es mit Ulebuhle verderben. Dieser aber war ein
kluger Mann! Das waren keine gewöhnlichen Märchen, die er da
erzählte, keine von Hexen und Menschenfressern, von Prinzessinnen
und verwunschenen Froschkönigen und all solchen Dingen, die es
gar nicht gibt, sondern es waren Geschichten, aus denen wir Kinder
viel lernen konnten und viel gelernt haben, und nur scheinbar waren
es Märchen. So wie der Apotheker eine bittere Pille, die uns kurieren
soll, mit einer Zuckerhülle umgibt, damit wir sie bereitwilliger
schlucken, umgab der gelehrte Doktor seine Erzählungen von all den
wunderbaren Dingen der Natur mit einem Märchenkleid.
Was ich behalten habe von diesen Geschichten, das habe ich hier
niedergeschrieben, und wenn ihr sie alle gelesen haben werdet, so
habt ihr eine ganze Masse gelernt von Sonne, Mond und Sternen,
von Wolken, Regen, Schnee und Wind, von Feuerbergen und
Meerestiefen.
Wenn ihr aber etwas nicht verstanden habt oder mehr davon
wissen möchtet, dann schreibt mir nur und denkt, ich wäre der
Ulebuhle selber, und dann will ich mir die Hornbrille aufsetzen, es
sorgfältig lesen und euch antworten, wenn auch nicht so knurrig und
brummig wie Doktor Ulebuhle.
 Die versunkene Stadt
«Ach, da unten im Süden ist es herrlich! So tiefblau ist der Himmel,
wie wir Nordländer ihn gar nicht kennen. Eine warme Luft weht
herüber vom Mittelländischen Meere, und wundervolle Blumen
blühen. Lorbeerhaine stehen am Ufer, und in sonnigen Gärten
leuchten Apfelsinen- und Zitronenbäume. Ja, es ist herrlich da unten
im Lande Italien.
Seht, da pflügte an einem schönen Frühlingstage ein Bauer das
Feld. Er zog das blanke Eisen durch die dampfende Erde, die ein
warmer Regen aufgeweicht, und rauchte vergnüglich seine
Tonpfeife. Das war nicht weit von dem spitzen Kegelberge, der da
hoch aufragt wie ein mächtiger, umgestülpter Napfkuchen, und den
die Leute „Vesuv“ nennen. Und was der Bauer konnte, das konnte
der Berg auch! Eine feine Rauchsäule stieg aus seinem Gipfel, denn
er ist ein feuerspeiender Berg und ein gefährlicher Bursche. Wenn er
seinen Rappel kriegt, rumort er plötzlich los. Mit Blitz und Donner
fährt das glühende Teufelszeug aus ihm heraus, heiße Asche und
brennende Steine sausen durch die Luft und zerstören alles ringsum.
Dann ist der tiefblaue Himmel verschwunden, die Lorbeerhaine
verbrennen, die Apfelsinen- und Zitronengärten werden im heißen
Schlamm begraben. Ach, dann ist es nicht mehr herrlich da drunten
im Süden, im Lande Italien.
Der Berg raucht, aber ganz friedlich nur, und der Bauer raucht
unbekümmert um ihn sein Pfeifchen, da fährt sein blankes
Pflugeisen gegen ein hartes Ding. Ein Stein, denkt er und bückt sich,
ihn aus dem Wege zu räumen. Aber wie er das Ding aufheben will,
ist es eine wunderschöne Bronzekanne, ein metallener Krug,
wundervoll verziert. Wenn man die Erde und Asche abscheuert, die
ihn mit dicker Kruste überzieht, sieht man, daß er uralt ist, so, wie
ihn die Menschen heute nicht mehr herstellen.
Der Bauer freut sich wie ein König. Das ist eine gar seltene
Erdfrucht, denkt er, und nachdem er den Krug lange genug
betrachtet, stellt er ihn behutsam seitwärts. Sein Weib wird sich
freuen, ein so feines Ding auf ihrem Schrank zu haben.
Der Bauer pflügt und pflügt, und als der Mittag kommt und er
eben aufhören will mit seiner Arbeit, da sitzt das Eisen wieder fest
und will sich nicht mehr lösen. Ei, denkt der Bauer, bin ich ein
Schatzgräber heute! Er holt seinen Spaten und gräbt das Ding
heraus. Was ist es? Ein riesiger Metall-Leuchter mit fünf Armen und
Löwenfüßen, und ist wohl einen Meter groß und so schwer, daß man
ihn kaum heben kann.

Der Bauer ist ein Pfiffikus. Er schiebt den Strohhut in den Nacken
und überlegt. Wo das gesteckt hat, kann noch mehr stecken, sagt er
zu sich, und so gräbt er im Schweiße seines Angesichts immer tiefer
auf seinem Acker und sieht, daß da unten alles Asche ist, Asche, die
der feuerspeiende Berg wohl vor vielen Jahrhunderten ausgeworfen
hat. Einen niedlichen Handspiegel findet er noch, und ganz unten
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