Sap Web Dynpro SysmodSeminar2005

HASSO - PLATTNER - INSTITUT
fr Softwaresystemtechnik an der Universitt Potsdam
SAP Web Application Server

Technology
Bernhard Grne, Peter Tabeling
Technische Berichte
des Hasso-Plattner-Instituts
fr Softwaresystemtechnik an der Universitt Potsdam
Technische Berichte des Hasso-Plattner-Instituts fr Softwaresystemtechnik

an der Universitt Potsdam
X
SAP Web Application Server Technology
Bernhard Grne, Peter Tabeling
Mai 2006
Bibliografische Information der Deutschen Bibliothek

Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen
Nationalbibliografie; detaillierte bibliografische Daten sind im Internet ber
http://dnb.ddb.de abrufbar.
Die Reihe Technische Berichte des Hasso-Plattner-Instituts fr Softwaresystemtechnik an der

Universitt Potsdam erscheint aperiodisch.
Herausgeber:
Professoren des Hasso-Plattner-Instituts fr Softwaresystemtechnik

an der Universitt Potsdam
Redaktion
EMail
Bernhard Grne, Sabine Wagner

bernhard.groene@hpi.uni-potsdam.de
Vertrieb:
Universittsverlag Potsdam
Postfach 60 15 53
14415 Potsdam
Fon +49 (0) 331 977 4517
Fax +49 (0) 331 977 4625
e-mail: ubpub@rz.uni-potsdam.de
http://info.ub.uni-potsdam.de/verlag.htm
Druck
allprintmedia gmbH
Blomberger Weg 6a
13437 Berlin
email: info@allprint-media.de
Hasso-Plattner-Institut fr Softwaresystemtechnik an der Universitt Potsdam, 2006

Dieses Manuskript ist urheberrechtlich geschtzt. Es darf ohne
vorherige Genehmigung der Herausgeber nicht vervielfltigt werden.
Heft X (2006)
ISBN
ISSN X
Contents
1
Introduction
1.1 The Seminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
The Clustering Concept of the SAP Web Application Server (Torben Schreiter)
Bea JRockit (Sebastian Steinhauer)
15
The SAP VM Container (Andreas Blher)
23
Administration of the SAP Web Application Server (Martin Wolf)
29
UME: User Management and Security (Marco Helmich)
37
Profiling, Monitoring and Tracing in the SAP Web Application Server (Johannes Passing)
45
The Eclipse Platform (Matthias Kunze)
55
Eclipse PlugIns (Michael Perscheid)
63
10 Enterprise Java Beans and their Deployment using SAP NetWeaver (Ralf Gldemeister)
73
11 Web Services and the SAP Web Application Server (Johannes Nicolai)
81
12 Apache Struts (Daniel Rinser)
91
13 Web Dynpro Overview (Andreas Fahle)
101
14 Web Dynpro: Navigation and ComponentOrientation (Christian Holz)
107
15 Web Dynpro: Context Mapping and Model Binding (Matthias Weidlich)
117
16 J2EE Persistence Mechanisms of the SAP Web Application Server (Bernd Schufele)
125
17 The Java Data Objects Persistency Model (Stefan Marr)
135
18 SAP DTR und Subversion: Zwei Versionskontrollsysteme (Tino Truppel)
143
19 Die SAP NetWeaver Development Infrastructure (Sebastian Bttner)
153
20 SAP NWDI: Entwicklung durch mehrere Team mit Hilfe von Tracks (Stefan Httenrauch)
163
System Modeling of the SAP Web Application Server

Bernhard Grne and Peter Tabeling (editors)
HassoPlattnerInstitute for Software Systems Engineering
P.O. Box 900460, 14440 Potsdam, Germany
{bernhard.groene, peter.tabeling}@hpi.uni-potsdam.de
Abstract
covering the presentation and the Q&A session. It

should have a similar outline, use the same models
(maybe worked over, according to the remarks and
hints), and stay within a ten page limit. The student
could write in German or English. Many chose English although none of them is a native speaker.
This report is a compilation of the elaborations
of this seminar. They are provided as is. The papers vary in style and even language, there may
be errors regarding the contents, syntactic or typographic mistakes. But nevertheless, they provide a
good view on the technology and concepts of application servers.
This report presents the results of the seminar System

Modeling of the summer term 2005 at the HassoPlattner
Institute. It is a compilation of the students elaborations dealing with concepts and technologies of the SAP Web Application
Server Java.
1
1.1
Introduction
The Seminar
The Seminar System Modeling intends to let students in the 4th semester get experience in modeling
systems and transferring this knowledge. Beginning in 2002, each seminar focused on a real product
or technology domain which had to be analyzed,
modeled and explained. In 2005, the general topic
given to the students was the SAP Web Application
Server Java and the according technology concepts.
A student had to study the given information
sources, find other sources, analyze and work with
the product, create models, and structure and create a presentation. At this point, one week before
the presentation in the seminar, the student had to
show the presentation slides, especially the models,
to us, the supervisors of the seminar. We usually
asked many questions and gave hints regarding the
didactical quality of the presentation and the understandability of the models. This session took about
one hour and turned out to be an important means
to teach modeling.
The presentation in the seminar was limited to 25
minutes, which often forced the students to abstract
carefully and therefore let them choose which was
really important about a topic. The question and
answers session after the presentation made obvious how well a topic was understood by both the
presenter as by the audience. A good presentation
provokes good questions which go into details. Last
part of the Q&A session were remarks and hints to
presentation style and modeling decisions.
Within two weeks after the presentation in the
seminar, a student had to prepare an elaboration
1.2
Topics
The first part of the report gives an overview of the

SAP Web Application Server, underlying technology, and tools to run and maintain the server. The
first paper covers the whole WebAS System, focusing on the clustering mechanisms used there. The
next papers cover the Java VM technology of two
concurrent products BEA JRockit and SAP VM
Container. For the operation and maintenance of an
application server, the topics administration tools,
user management, and monitoring are important.
The next part of the report shows the developers
view: As the SAP NetWeaver Developer Studio is
based on Eclipse, the next two papers focus on the
Eclipse platform. Backends using EJB technology,
deployment of software in clusters, Web Service interfaces to EJBs, and persistency technologies have
been analyzed. This is followed by papers about
frontend technologies such as Java Struts and SAPs
Web Dynpro. The software life cycle is covered by
the last papers about code version management and
SAPs development infrastructure for Java.
The Clustering Concept of the

R

Torben Schreiter
Hasso-Plattner-Institute for Software Engineering,
University of Potsdam, Germany
torben.schreiter@hpi.uni-potsdam.de
June 2005
Abstract
Typically, these services are mission-critical,

which means that they have to be highly
available. High availability correlates with
fail-safeness. To provide fail-safe services, the
relevant components of the system need to be
kept redundant. Additionally, fault tolerance
(failover) mechanisms have to be implemented
in order to prevent any loss of transient data.
So, we want the work left open by a crashed
node to be taken over by another cluster node.
The processing cluster node should return the
expected result to the user, leaving him unaware of the incident as such.
Scalability means the ability to adapt to an
increasing number of requests (in a certain
period of time) in order to minimize the response times for the users requesting the services. Mostly, this is achieved by adding
more machines to the cluster. A basic requirement is an effective load balancing mechanism,
which is responsible for a fair delivery of requests to the connected cluster nodes. The
total workload should be evenly distributed
between the cluster nodes and the integration
of new machines just as the disappearance1 of
Application Servers has to be handled by the
load balancer(s) as well.
To SAP, the development of distributed
The Java 2 Enterprise Edition (J2EE) has become

a widely-used platform for the development of Enterprise Applications, which are often responsible
for many business processes within a company. So,
Enterprise Applications have to be more reliable
than any other kind of software.
The concept of combining many physical machines into one cluster offers this reliability in two
important ways: Failover mechanisms guarantee
a maximum degree of availability to the users and
load balancing results in scalability of the applications.
This paper aims to describe the specific archiR Web Application
tecture of a cluster of SAP
Servers, concentrating on their Java-personality.
The cluster architecture explained provides a sophisticated technological basis for the efficient execution of Enterprise Applications.
Keywords: Clustering, J2EE, SAP Web AS,
Failover, Load balancing, SDM
Introduction
A clustering architecture, in general, is motivated by two primary aims. These are high
availability and scalability of the software system. Due to this, the applications have to be
highly distributed among a number of cluster nodes. The whole distribution should be
transparent to the users of the services [AK2].
1
There are different possibilities for an Application
Server or whole cluster node to disappear. It can disappear e.g. in consequence of a failure but it can also
disappear because of maintenance concerns. This supported facility last mentioned is called hot-swapping.
31
high-performance ERP2 software systems is

nothing new. In fact, the SAP Web Application Server (SAP Web AS) is more a
SAP R/3-Application Server extended by a
Java-personality than an entirely new designed system. Whilst implementing this
Java-personality, SAP could revert to experiences that were gained during the development of the R/3-architecture.
In the first part of this article, the structure
of a cluster of SAP Web AS will be explained.
Part two and three deal with detailed explanations of the load balancing and failover mechanisms within a SAP Web AS cluster. Finally,
several aspects concerning the Software Deployment Manager (SDM) as a central cluster
component responsible for the integrity of all
deployed software in the cluster will be examined in the fourth part.
Enqueue Server (see section 2.2.2). The central

instance also contains the server component
of the Software Deployment Manager (not illustrated here, see section 5).
The SAP Web Dispatcher is situated above
the cluster nodes. It receives all incoming requests from the users via HTTP or HTTPS using SSL and forwards them to a selected cluster node (see section 3.1).
The major components of the cluster will be
discussed in the following chapters.
2.2
The SAP Central Services consist of the Message Server and the Enqueue Server. Often,
these services run on the central instance,
but there are certain possibilities to, at least,
source out the Enqueue Server to a dedicated
machine with regard to fault tolerance. These
aspects will be explained below.
The database system will not be explained
in detail since the SAP Web Application
Server abstracts from the specific third-party
database solution used.
Clustering Architecture of the

2.1
SAP Central Services
Structure of a cluster
Figure 1 shows the general structure of a

cluster of SAP Web Application Servers. A
single central instance of the SAP Web AS
as well as multiple dialog instances can be
seen in the middle. Every Web Application Server includes an Internet Communication Manager (ICM) and one or more J2EEEngines.3 The ICM is mainly responsible for
the recognition of the type of request. It decides whether the request has to be handed
over to the Java- or ABAP-personality.4 A
J2EE-Engine, essentially, comprises one dispatcher and several J2EE-Server Application
Server Processes. All J2EE-Engines are connected to the central database as well as to the
2.2.1 Message Server

The Message Server is responsible for all communication (e.g. events, data transfer) within
the cluster. Thus, it provides a powerful API5 ,
which enables the cluster components to communicate with each other.
The concept of using a Message Server
to accomplish the cluster communication between the Java-nodes was first implemented
in the release 6.40 of the SAP Web AS.
The earlier releases implemented a pointto-point communication between the Javanodes instead of a star-architecture as in 6.40.
[WASJ6.40] The point-to-point approach is
problematic, because the cluster has to handle
n (n 1)/2 connections (where n is the total
number of nodes). In other words, every node
has to hold one connection to each of the other
nodes. If the cluster grows, the number of
connections rises nearly quadratically. This of
abbreviation for Enterprise Resource Planning

The SAP Web AS certainly consists of more than the
components shown. However, this article focuses on
the Java-personality of the Web AS and therefore only
the relevant components related to this context are mentioned.
4
Since this paper focuses on the Java-personality, the
structure of the ABAP-personality is not shown in Figure 1.
3
42
Application Programming Interface
course affects the network performance and,

consequently, the cluster performance. In contrast to this, the star-architecture only needs n
connections altogether: One from every node
to the central Message Server.
However, since the Message Server exists
only once per cluster it might prove to be
a possible bottleneck for the overall performance of the whole cluster, but tests revealed
that clusters of 50 and more nodes pose no
problem for this architecture [WASJ6.40].
The abovementioned API helps to accomplish an adequate performance of the cluster
communication by abstracting from the concrete form of communication. If e.g. a node
wants to send a large amount of data to another node, it would slow down the Message
Server because all traffic would have to pass
the Message Server as an intermediary first
until it is redirected to its destination (Message Server communication). To avoid this, the
API - transparently - decides to send messages of a certain size upwards through a temporary point-to-point connection (via sockets)
directly to the destination instead of using the
persistent connection to the Message Server
(lazy communication). [JPWAS]
Additionally, the Message Server collects
and stores information about the whole cluster and its components such as the available
J2EE-Dispatcher, J2EE-AS Processes, the Web
Dispatcher, etc.
2.2.2
resource. When the node has finished its operation, it has to release the lock again.
The Enqueue Server, generally, locks socalled logical objects. Even though most of
these objects are related to the database (e.g.
table rows or cells), the whole locking concept
realized by the Enqueue Server is not related
to the locking mechanisms provided by the
vendor of the database system.
2.3
Expanding the cluster
When the demand for the services offered increases, it is desired to be able to improve the
performance of the cluster by expanding it by
additional machines. Relatively little effort is
needed to accomplish the integration of new
cluster nodes. Basically, two steps affect the
integration:
integration into the load balancing mechanisms of the cluster
synchronization of all deployed applications
These steps are automated, which means that
often it is enough to specify the correct address of the Message Server and configure
several other initialization settings in order to
integrate the new cluster node.
Prior to the two steps mentioned above, the
J2EE-Engines have to start up. This start-up
is managed by two different kinds of (operating system) processes shown in Figure 2.
The JControl process is responsible for starting up and monitoring several JLaunch processes, which offer the actual functionality for
the role of the J2EE-Engine.
Figure 3 clarifies the dynamic structure of
the start-up procedure belonging to a J2EEEngine as depicted in Figure 2. During this
procedure different instances of JLaunch are
created. The characteristics of the JLaunch
processes can differ from each other. There
are three different types of personalities a
JLaunch process can adopt:
Enqueue Server
As a part of the Central Services, the Enqueue

Server merely exists once per cluster, too. It
provides the ability to synchronize access to
common cluster resources.
When a cluster node wants to use a shared
resource such as the central database it has
to request a lock for this resource at first. If
the resource is available, the lock is granted
by the Enqueue Server. This means, that the
Enqueue Server appends an entry with information about the granted lock to the lock table.
After receiving the confirmation from the Enqueue Server, the cluster node can access the
Bootstrapper
53
to Message Server
to ICM
3 Load balancing
to Message Server
J2EE-Engine
The SAP Web Application Server realizes load

balancing within the cluster by implementing
dispatching on two different levels.
Whereas the SAP Web Dispatcher operates
on cluster-level, the J2EE-Dispatchers work
on level of J2EE-AS Processes within the cluster nodes. Both types of dispatchers are explained in the following.
JLaunch
(Process)
JVM
JVM startup agent
(Dispatcher subroutine)
JControl
JLaunch
JLaunch
(Process)
(Process)
JLaunch
(Process)
JVM startup agent
JVM startup agent
JVM startup agent
JVM
JVM
JVM
(Bootstrap subroutine)
(AS subroutine)
(AS subroutine)
3.1
instance.properties
bootstrap.properties
The SAP Web Dispatcher acts as a global load

balancer for the cluster nodes. It can be seen
as the linkage between the Internet and the
cluster of SAP Web AS. Hence, it is situated in
the DMZ7 , where it is accessible for the clients.
This is also advantageous because the cluster
nodes need not to be located inside the DMZ.
Thus, they are safe behind the firewall.
As shown in Figure 1, the SAP Web Dispatcher is the only way for clients to request
services from the cluster. It realizes the Single point of entry/Facade design pattern [DPAT]
regarding all incoming HTTP(S)-requests. After receiving a request, the dispatcher forwards it to a Web Application Server using a distribution algorithm. Usually, the
weighted round robin algorithm is applied.
This means, that the requests are distributed
among the connected J2EE-Engines using the
following scheme. A weight is assigned to
each J2EE-Engine. Mostly, the weight is equal
to the number of contained J2EE-Application
Server Processes. The SAP Web Dispatcher,
then, distributes the requests depending on
the weights. If e.g. Engine A contains 10
processes and Engine B contains 20 processes,
twice as many requests are redirected to Engine B as to Engine A.
The SAP Web Dispatcher is implemented
as a software web switch, which is an operating system process usually running on a dedicated machine. The implication to fault tolerance will be discussed later on.
to Enqueue Server / DB
Figure 2: Structure of a J2EE-Engine during

start-up
Dispatcher
Application Server
Before adopting one of the personalities (represented by their according subroutines), the
process loads a Java-VM6 into its own context.
After that, the desired subroutine (written in
Java) is executed.
At first, JControl establishes a connection to
the Message Server. Then, one JLaunch process is spawned by JControl. It becomes the
Bootstrapper, which synchronizes all binaries
that are needed to serve client requests. Next,
it writes the file INSTANCE.PROPERTIES.
This file contains an exact definition of the
J2EE-Engine to start up, e.g. the number of AS
Processes is specified. The Bootstrapper, then,
terminates and JControl starts one JLaunch
process that becomes the J2EE-Dispatcher and
as many JLaunch processes as specified in INSTANCE.PROPERTIES to become the J2EEApplication Servers.
6
SAP Web Dispatcher
Virtual Machine
64
Demilitarized Zone
4.2
Alternatively, it is possible to set up a thirdparty hardware solution instead of using the

SAP Web Dispatcher as global load balancer.
3.2
The failover services supported by the SAP

Web AS can be divided into the two following
categories (both are explained in detail later
on):
J2EE-Dispatcher
Bean session failover
Each J2EE-Engine possesses a J2EEDispatcher. Within the engine, the dispatcher

acts as the local load balancer (see Figure 1).
HTTP session failover

However, both of them have to prevent data
loss of transient data within sessions. To
achieve this, the particular session data has
to be serialized and replicated to a persistent
medium from where it can be restored in case
of a failure.
SAP offers two possible locations for the
storage of serialized sessions. They can either be replicated to the central database or to
the local file-system. Accessing the database
is relatively slow compared to the usage of
the local file system. On the other hand,
the sessions stored in the database can be restored by any other cluster node whereas using the file-system is disadvantageous since
the session can only be restored on this particular machine. Anyway, fault tolerance diminishes performance. It is recommended
to use the file-system option because this
marks a reasonable compromise between performance and security as it is relatively unlikely for a cluster node to fail completely. It
is more likely that individual AS Processes
crash. Replicating to the file system is sufficient in this case. [JPWAS]
A J2EE-Dispatcher receives requests that

were redirected by the SAP Web Dispatcher.
These requests are, then, parsed and dispatched again. The J2EE-Dispatcher also
makes use of a distribution algorithm to assign each of the requests to a selected J2EEApplication Server Process. The dispatcher
receives a list of all Application Server Processes connected to itself from the Message
Server. Therefore, the dispatcher is able to
react to changes that result from crashed AS
Processes or from a higher number of configured AS Processes.
The architecture of a J2EE-Engine is very
much related to the Worker Pool architectural
pattern [BG2004]. In this concrete implementation, a J2EE-AS Process can be mapped onto
a Worker and the Listener is represented by the
dispatcher.
4
4.1
Failover services supported by the

Failover mechanisms
Definition
4.2.1 Bean session failover
The deployed applications within a cluster

often provide services to the clients that are
mission-critical. Thus, these services need to
be highly available, which means that the system downtime has to be reduced to a minimum. Generally, another server has to take
over responding to a request if the server that
currently serves the request fails. This is only
possible due to redundancy of cluster components and should, of course, happen transparently to the user.
Bean session failover refers to failover regarding the state of Enterprise Java Beans (EJBs).
Therefore, it takes place in the EJB-Container
which is located inside the J2EE-AS Process.
J2EE comprises different types of Enterprise
Java Beans. Entity Beans have a state that is
already persistent per definition. Hence, there
is no need to replicate them. Besides, there are
two kinds of Session Beans: the Stateful and
the Stateless Session Beans. The SAP Web AS
75
sion from the persistent medium and proceeds serving the request as usual.
supports failover mechanisms for both types

of Session Beans.
When serializing a Stateless Session Bean,
the EJB-Container simply stores an ID
mapped to the session of that bean. Since
the Bean has no state that would have to be
saved, it is sufficient to create a new instance
of the Bean in case of a failure.
Replicating a Stateful Session Bean8 requires the serialization of the Bean state. Depending on the actual Bean, the amount of
data that has to be serialized may become
relatively large. Because of this, the developer can configure the failover options for
his Beans in the Deployment Descriptor EJBJ2EE-ENGINE.XML.
4.2.2
4.3
The two abovementioned failover services

can be applied in case of Application Server
failures. Thus, they only focus on one possible point of failure. The SAP Web Application
Server comprises other fault tolerance mechanisms that are more related to the overall stability of the cluster, which is influenced by
many different kinds of cluster components.
Heterogeneous load balancing offers the possibility to isolate particular applications, which
are known to be instable, on specified cluster nodes. If such an application brings
down its J2EE-AS Process quite often, the
isolation is able to prevent a chain reaction
that would otherwise be the consequence of
failover mechanisms and might bring down
the whole cluster engine by engine. Therefore, the load balancing algorithms have to
consider if the selected J2EE-Engine owns the
respective application. Thus, it is obvious
that Heterogeneous load balancing represents
a combination of failover and load balancing.
The following passages briefly describe
how the failure of cluster components different from the AS Processes influences the overall stability of the cluster and what possibilities exist to prevent a failure of the whole cluster.
HTTP session failover
Since most of the communication between

Application Servers and the clients is based
on HTTP, the data concerning the HTTP sessions has to be replicated as well. In general,
the procedures and also the (dis-)advantages
of Bean and HTTP session failover are comparable. The most significant difference is the
level on which they operate. Whereas Bean
session failover operates on level of the particular Beans, HTTP session failover acts on
level of the HTTP sessions (Web Container).
Figure 4 depicts the dynamic behavior of
a request/response-sequence between client
and the concerned cluster components. The
session has to be serialized at certain points.
This happens always before dispatching the
request and, in case the application failover
option is enabled in the appropriate Deployment Descriptor (APPLICATION-J2EEENGINE.XML), after processing each request,
too. It is also possible, that the server is shut
down or either the Web Container Service or
the application is stopped. Under these circumstances, the session is serialized again. If
the server unpredictably crashes, serialization
of course cannot be performed anymore.
In case that a session has to be restored,
the AS Process deserializes the particular ses8
Overall system stability
4.3.1 SAP Web Dispatcher

As discussed in chapter 3.1, the SAP Web Dispatcher is an operating system process. It has
to be highly available since it is the only cluster component that is directly reachable for
the clients.
In UNIX-environments9 it is possible to
realize this by using a secondary so-called
watchdog-process, which is mostly identical to
the primary Web Dispatcher process. It is created as a child-process and, therefore, knows
about the same shared memories, sockets and
9
This process is often called Stateful Session Failover.
86
due to the usage of the fork()-system call
administration structures as the parental process. The watchdog monitors the primary
process and is able to take over the control
whenever this is necessary. After the former
watchdog gains control it creates a process
that becomes the new watchdog. [SLIB]
High availability on (operating system)
process-level can be achieved by this. However, in case of e.g. a hardware failure of the
machine the SAP Web Dispatcher is running
on, the cluster is not able to receive any requests anymore. To prevent this, an additional hardware redundancy solution should
be taken into consideration.
4.3.2
If the Message Server fails, all cluster components that want to communicate are blocked
until the Message Server is operational again.
Usually, the restart of the Message Serverprocess is completed within seconds. Hence,
a temporary crash is not that problematically.
But similarly to the SAP Web Dispatcher, this
only works on level of operating system processes. To eliminate a failure of the cluster resulting from hardware malfunction of the machine that houses the Message Server, a hardware redundancy solution is inevitable. The
same applies to Enqueue Server and the central Database System.
In contrast to this, SAP provides the additional facility to use a Standalone Enqueue
Server. Since the Enqueue Service has to hold
a lock table in memory, one runs the risk that
the lock table is lost if the machine crashes. All
information about the granted locks are gone
in that case. Therefore, all applications that
owned locks have to be reset. When using the
Standalone solution instead, it is possible to
replicate the lock table and avoid data loss.
During the time the Enqueue Server is unavailable, all applications that either want to
request or release a lock are blocked until the
Enqueue Server is operational again. [SLIB]
J2EE-Dispatcher
The J2EE-Dispatchers are so-called stateless10

components of the cluster. If one of them
crashes, it is immediately restarted by the
JControl-process. Due to the fact that no state
is existent, no data is lost. The restarted dispatcher is able to continue dispatching immediately.
In case that the restart is not possible, the
SAP Web Dispatcher recognizes the failed
J2EE-Dispatcher to be absent and, thus, no
more requests are redirected to it. The sessions, which were processed by this J2EEEngine, are, then, restored by another Engine using the failover mechanisms described
above.
4.3.3
5 Software Deployment Manager

As described above, the load balancing mechanisms redirect incoming requests to the connected cluster nodes. Every request is related
to an application, which, then, serves the request and returns the desired result. Naturally, every of these applications has to be
deployed within the cluster before they are
ready to be executed.
The Software Deployment Manager (SDM)
is the cluster component that is responsible
for the integrity of all deployed software on
the cluster nodes. It consists of two parts: the
client GUI-utility and the server component. Figure 5 depicts the Compositional Structure of
the relevant system components taking part in
Single Points of Failure (SPOF)
The whole cluster has a total of three Single

Points of Failure. This means that no Application Server can work if one of the following
three cluster components fails:
Message Server
Enqueue Server
Database System
10
Since a J2EE-Dispatcher is a dynamic (software) system, it of course does have an internal state. But there
is no state that is actually related semantically to its task
as a dispatcher.
97
ceivable:
compiled
sourcecode
IDE
packer
initial deployment
other files
Developer
updating existing archives

deployable archive
undeployment
Software Deployment Manager
Each of these actions refers primarily to the

SDM Repository. The stored data inside the
repository is, then, used to synchronize the
data with the specified destination(s). All
data that has to be synchronized is specified to be delivered to a particular destination. As depicted in Figure 511 , these destinations are either the central database or the
local file system of the cluster nodes. The
file system content can be divided into the
J2EE-applications, other files and additional
libraries for the J2EE-Engines12 .
Synchronization is only performed if it is required. Usually, this is the case when the content of the Repository changes. Besides, a single synchronization takes place, if e.g. a new
J2EE-Engine is started up (see section 2.3).
(GUI)
Deployer
Software Deployment Manager
(server component)
SDM Repository
Enqueue Server
lock table
J2EE-Engine
RDBMS
database
local
file system
Figure 5: Compositional structure showing

the participants in the deployment process
the deployment process.
All deployable content has to be merged
in deployable archives. These may either be
Software Deployment Archives (SDA) or Software Component Archives (SCA). The SDA is
the smallest unit that can be deployed. Usually, a SDA contains one particular version
of a software component whereas the SCA
comprises several SDAs. Thus, the number
of SDAs reflects the version-level or versionhistory of the contained software component.
[SLIB]
The GUI-utility allows the deployer to import selected archive(s). In doing so, the client
utility connects to the server component of the
SDM and, then, hands over the archive. Next,
the archive is placed into the SDM Repository,
where all imported archives are stored for future use (e.g. redistribution of the archives to
new cluster nodes). During the whole deployment process special dependencies between
and within the archives are taken into consideration, to avoid incompatibilities.
Three different deployment actions are con-
6 Conclusion
Applying a cluster-architecture is essentially
motivated by the two primary aims scalability and high availability of the offered services.
This paper described how these aims are realized regarding the concrete example of the
Java-personality of the SAP Web Application
Server.
The two main concepts - flexible load balancing and effective fault-tolerance mechanisms
- were discussed in detail. The SAP Web AS
utilizes 2-level-based dispatching combined
with various failover mechanisms in order to
adapt quickly to changes in the availability of
cluster nodes and to provide a well-balanced
11
Naturally, the SDM has to utilize the Message

Server in order to communicate with the J2EE-Engines.
Though, in the chosen level of abstraction it is possible
to ignore this fact.
12
In some cases it is necessary to restart the whole
J2EE-Engine to integrate the deployed data.
10 8
References
workload across all available nodes. Therefore, expanding the cluster is fairly easy to accomplish by adding new machines.
All of the mentioned activities are enabled
due to redundancy of cluster components and
aim at the users satisfaction. Thus, they are
completely transparent to the users.
The sophisticated cluster-architecture of the
SAP Web AS provides a solid technical basis
for the execution of Java Enterprise Applications if all eventualities are considered while
setting up the local cluster. Especially the Single Points of Failure have to be secured by
additional hardware redundancy solutions in
order to guarantee real high availability.
[WAS]
Frederic Heinemann and Christian

Rau, SAP Web Application Server, SAP
Press/Galileo Press, 1st Edition, 2003
[JPWAS]
Karl
Kessler,
Peter
Tillert
and Panayot Dobrikov,
JavaProgrammierung mit dem SAP Web
Application Server, SAP Press/Galileo
Press, 1st Edition, 2005
[DPAT]
Erich Gamma, Richard Helm, Ralph

Johnson and John Vlissides, Design
Patterns: Elements of Reusable ObjectOriented Software, Addison Wesley,
5th Edition, 1996
[SLIB]
SAP Library,
http://help.sap.com/
[SDN]
SAP Developer Network,

https://www.sdn.sap.com/
[WASJ6.40] SAP AG, SAP Web AS Java 6.40 - a

Reliable, Scalable, Efficient J2EE Application Server, 2005
[MK2.3]
Matt Kangas, Introduction to the

SAP Web Application Server, Version 2.3, 2005,
http://www.sap.com/mk/
get? EC=wjqfETRbYxuv8o fZzdmLI
[AK1]
Abraham Kang, J2EE-Clustering,

Part 1, JavaWorld.com, 2001,
http://www.javaworld.com/javaworld/
jw-02-2001/jw-0223-extremescale p.html
[AK2]
Abraham Kang, J2EE-Clustering,

Part 2, JavaWorld.com, 2001,
http://www.javaworld.com/javaworld/
jw-08-2001/jw-0803-extremescale2 p.html
[BG2004]
Bernhard Grone,
Konzeptionelle
Patterns und ihre Darstellung, 2004
[CA2004]
BEA Systems, Clustering Architectures, 2004,

http://e-docs.bea.com/wls/
docs81/cluster/planning.html
[JAP2004] SAP AG, Creating a J2EE-Based Car

Rental Application, 2004
11 9
Web-Browser
HTTP(S)
Web-Browser
HTTP(S)
SAP Web Dispatcher

(global load balancer)
Message Server
J2EE-Engine
(Host j)
Cluster-Node
SAP Web AS
local file system
ABAP Engine
J2EE-Engine
context
m
Request Queue
context
m
ABAP Work Process
context
1
ABAP Work Process
context
1
shared
memory
ABAP Dispatcher
shared
memory
(application server)
J2EE-Server Process m
(application server)
ICM
ABAP-Engine
J2EE Dispatcher 1
J2EE-Server Process 1
(dialog instance i)
(Host j)
Cluster-Node
Internet Communication Manager
Request Queue
SAP Web AS
(central instance)
local file system
Enqueue Server
(locking service)
RDBMS
(JDBC-compatible)
database
Figure 1: Structure of an operational SAP Web Application Server cluster
1210
lock table
JLaunch
JControl
Bootstrap subroutine
(Process)
(Process)
initialize signal handling

connect to Message Server
read BOOTSTRAP.PROPERTIES
initialize settings needed for
starting up the VM
load the VM into current process
synchronize all binary data
with the database
get J2EE-Engine settings
from database and write
them to INSTANCE.PROPERTIES
read INSTANCE.PROPERTIES
JLaunch
Dispatcher startup subroutine
(Process)
JLaunch
JLaunch
AS 1 startup subroutine
(Process)
AS m startup subroutine
(Process)

starting up the VM

starting up the VM

starting up the VM
start J2EE-Dispatcher
start J2EE-Application Server
start J2EE-Application Server
processed all
J2EE-Engine elements
in INSTANCE.PROPERTIES
Figure 3: Petri net describing the dynamic behavior of the start-up procedure of a J2EE-Engine
Client
Dispatcher
Session Failover Service
J2EE-Application Server
(HTTP session failover)
(Process)
send HTTP request
handle HTTP request
serialize HTTP session

(storage on persistent medium)
determine destination-server
(dispatch)
HTTP session available
deserialize HTTP session
process request
application failover
enabled
else

return result
receive result
Figure 4: Petri net describing the HTTP failover mechanism
1311
server shutdown ||
Web Container Service stopped ||
application stopped
crash
else
14
BEA-JRockit, a Java Virtual Machine for server-side use

Sebastian Steinhauer
Seminar System Modeling 2005
Hasso-Plattner-Institute for Software Systems Engineering
sebastian.steinhauer@hpi.uni-potsdam.de
Abstract
the components of a Java development

environment. An exemplary environment can be
Starting from an Java development platform

architecture and a Java Source Code example the Java
Byte Code as well as its processing environment, the
Java
Virtual Machine (JVM), are introduced.
Furthermore, requirements for server-side use of JVMS
are derived. Finally, BEAs approaches towards a
reliable, robust, and high-performance JVM for serverside use are presented.
Profiler
Classlibs
Java API
javac
Java Byte
Code
Keywords: Java Virtual Machine, server JVM,

BEA-JRockit, architecture, garbage collection,
Just-in-Time compilation
Java
Source
Code
Developer
IDE
1. Introduction
JVM
Debugger
CodeDocu
On May 5th 2005, BEA-JRockit established a

new record processing the server side JVM
benchmark, SPECjbb2000, on an Dell PowerEdge
server [SPEC]. This record is the result of a close
collaboration between Intel cooperation and BEA
Inc. targeted at an optimization of BEA-JRockit
for Itanium and Xeon architectures [Intel]. The
importance of BEA JRockit at the market is also
based on JBoss-certification as well as powerful
features such as efficient runtime monitoring
[JBoss].
This article is intended to introduce the
architecture of the Java platform as well as basic
mechanisms of JVMs [J2SPEC]. A simple code
sample is used for exemplification. After
describing the operating mode of Java platform
components and the Java Virtual Machine,
requirements for server-side use and there
realizations are presented.
JavaDoc
seen as an FMC model in Figure 1 [FMC]. The

Figure 1: A Java development environment
[FMC]
described Java-SDK contains of several

components. These components and their
interactions will be illuminated in the following
paragraphs. The given Java platform is a sample
configuration for Java software development. The
following sections also provide references to
products realizing the functionality encapsulated
in the FMC-agents in Figure 1.[J2SPEC]
2.1. Integrated Development

Environment (IDE)
The core of a modern Java software development
environment usually is a powerful integrated
development environment (IDE). Current IDEs
such as Borland JBuilder or Eclipse provide a
graphical user interface integrating Java source
code editing, a compiler (e.g. javac), a debugger as
2. The Java development

Environment
Describing the operating mode of Java Virtual
Machines makes it necessary to firstly focus on
15
first overview about the mapping between Java

source code and Java Byte Code.
well as JavaDoc.
2.2. javac
3.1. Compiling Java Source Code
javac is used exemplarily as a place holder for any

Java compiler producing Java Byte Code from
Java source code. A closer look at the
transformation of Java source code to Java Byte
Code will be provided in section 3.
To provide a profound impression on the

compilation from Java source code to Java Byte
Code, this section will present a code sample as
well as its Java Byte Code counterpart. The code
sample is on purpose of low complexity to
2.3. JavaDoc
public static void main(string[] args)

{
// initialization
int a=1;
int b=0;
int c=2;
int d=3;
// calculation
b=a+c*d;
}
The JavaDoc compiler parses the Java source code

written by the user. It extracts information
marked with special tags for JavaDoc and
produces HTML-files from it. These user-readable
code documentation provides precise information
such as method or class dictionaries to the reader.
2.4. Profiler
The Profiler component is often used together
with the debugger. Profilers are tools gathering
information about internal procedures inside the
JVM. They should implement the Java Virtual
Machine Profiler Interface (JVMPI) which is
currently not standardized.
Figure 2: Java Source Code Sample
present the basic ideas of the Java Byte Code and

not to present the large scale of the Java Byte
Code itself.
3.1.1. A tiny Java Source Code sample
The Debugger component can be realized in

several, very different ways. Sun implemented
the Java Platform Debugger Architecture
providing different interfaces and protocols to the
user. This system offers features like remote
debugging and native tool adaptation.
The source sample, which can be seen in Figure 2,

contains a class with a static void method,
main, describing the main entrance point of the
entire program.
To not leave the scope of this paper in the
following sections, we will focus on the method
main. According to the Java syntax this method
has to be embedded in a class.
2.6. Java Virtual Machine (JVM)
3.1.2. The Java Byte Code sample
An essential part of every Java Development

environment is the Java Virtual Machine (JVM).
The JVM processes the Java Byte Code compiled
from the Java source code by the Java compiler
(javac).
Compiling the source code from Figure 2

produces binary Java Byte Code which is not
published in this paper. To make the reader
understand the Java Byte Code produced by the
Java compiler. Figure 3 shows the mnemonics
corresponding to the binary Java Byte Code1.
2.5. Debugger
3. Java Byte Code
The following section is intended to provide a
16
e.g. the Bye Code for the mnemonic iload is 0x15
00
01
02
03
04
05
06
07
09
10
11
13
14
15
16
mapped onto int.
iconst_1
istore_1
iconst_0
istore_2
iconst_2
istore_3
iconst_3
istore 4
iload_1
iload_3
iload 4
imul
iadd
istore_2
return
4. The Java Virtual Machine

To process the Java Byte Code introduced before,
a special engine is needed. This engine is the Java
Virtual Machine (JVM). It has been designed
according to the basic ideas of hardware
processor design. The architecture used to design
the JVM is rather based upon the Harvard
architecture, demanding a strict separation
between data and program memory than on the
John von Neumann architecture.
The following section will describe the
architecture of a generalized Java Virtual Machine
[J2SPEC]. This is done by giving an FMC-Block
diagram of the JVM (also published in the
appendix) followed by a scenario describing the
loading of a class file into the JVM.
Figure 3: Java Byte Code created for the method

main(string[] args)
The Java Byte Code commands from byte zero to

byte seven can be mapped onto the
initialization part of the source code sample
listed in Figure 2. It shows that special Java Byte
Code commands for the definition and loading of
common used numbers are defined (iconst_1).
Comparing the mnemonics stored in byte 01 and
byte 07/08 shows that there are also special
commands defined for storing
values to
numerous used local variables (istore_1). This
command does not take any parameter in contrast
to the command stored in byte 07/08 (istore 4)
witch takes the index of the local variable as
parameter [LiMag].
The efficient support of primitive types in Java,
such as integer, can also be identified in the Java
Byte Code. The letter i indicates that all the
variables used in this example are int variables
or int values. Other primitive types supported
can bee seen in the following table.
Type
Byte
Short
Int
Long
Float
Double
Char
object reference
GC
Thread
Frame
Pointer
OnTop
Op.Stack
PC
Vars
Pointer
Heap
JITC
Native Methods
Stack
Const. Pool
Name
Resolver
Control Unit
Method. Area
Locals
Operands
Stack
Native
Byte Code Processor

Frame
JBC
Frame
Frame
ALU
JAVA (Frame) Stack

Initial Class Loader
I/O (OS)
Thread Controller
Figure 4: The Java Virtual Machine
After giving this startup scenario, a detailed

description of each agent is provided. Finally this
section provides a profound insight into the
execution of the Java Byte Code inside the JVM.
Type indicator
b
s
i
l
f
d
c
a
4.1. Loading a classfile into the JVM

Starting up the JVM using a command line like
java sysmodSample.class
relays the filename of the classfile to the I/Oagent which loads the file and passes its content
to the Initial Class Loader by using the Thread
Controller.
After verifying the Java Byte Code and the
class file, the initial class loader extracts the
Table 1: Type indicators in Java Byte Code

mnemonics
The primitive types boolean and short

supported by Java are fully mapped onto int
values and variables. byte and char are partially
17
the Native Methods Area.

On every method call, the combined JIT-Compiler
and Name Resolver agent first tries to find a native
method in the Native Method Area. If its search
does not succeed, the agent decides whether to
compile the method from the Java Byte Code
stored in the Java Byte Code Area or to bring its
Java Byte Code to execution.
symbols like method or class identifiers and

stores these into the Constant Pool. The Java Byte
Code associated with these is stored into a
memory area named Java Byte Code Method Area.
After loading the content of the classfile, the
thread controller creates and initializes a new
Thread. This new thread processes the Java Byte
Code starting in main(string[] args) by
using the Java Byte Code Processor. Its registers are
initialized while creating the thread. An initial
Frame for the method main is also created as top
element of the Java Stack.
4.2.5. Garbage Collector

The Java 2 Specification [J2SPEC] demands every
JVM to realize a garbage collected heap. This heap
is used to store non-primitive types, the objects.
The specification does not go into detail
considering the implementation of the garbage
collection.
The garbage collection is used to remove
unreferenced objects from the Heap and
defragmentate the memory allocated for the heap.
The Garbage Collector can be started by calling
functions like system.gc() from the Java source
code.[JWorld]
4.2. Agents in Detail

In the following sections, a brief theoretical
introduction into the activities processed by each
agent will be given.
4.2.1. I/O-Agent
The I/O-Agent realizes the interaction with the
environment. It also provides file system access to
other components. The services provided by this
agent can be used by the programs running in the
JVM as well as by the JVM components
themselves.
4.2.6. Byte Code Processor

The core of the Java Virtual Machine is the Byte
Code Processor. This agent consists of the same
logical parts as a hardware processor does. These
constituents are the Arithmetical Logical Unit
(ALU) as well as the Control Unit. The ALU
processes the Java Byte Codes with mathematical
or logical semantics. It generally uses the On Top
of Operands Stack register, referencing the top
element of the Operands Stack. The Control Unit is
used to perform method calls. Calling methods
and returning from methods is done by a
manipulation of the Java Frame Stack (PUSH, POP)
and the Current Frame register referencing the
element on top of the Java Frame Stack.
Local variables are also loaded by the control
unit. Therefore the control unit makes use of the
Variables register, referencing the first position of
an array containing the local variables. It also
controls the execution of the Java program itself.
This is done by manipulating the Program
Counter(PC) register of the JVM referencing the
current execution position within the Java Byte
Code.
4.2.2. Thread Controller

The Thread Controller is used to control running
threads. It can pause, terminated, and instantiate
threads. These features are provided to internal
components of the JVM such as the Garbage
Collector. The thread controller can also be used to
realize non standardized internal scheduling
approaches such as thin threads.
4.2.3. Initial Class Loader

Resolving symbols and loading Java Byte Code
into the method areas Java Byte Code region is
done by the Initial Class Loader. It also stores
resolvable symbols into the Constant Pool. These
features are used by the thread controller.
Providing this facilities to the Java Byte Code
Processor enables a programmer to overload the
class loaders.
4.2.4. JIT-Compiler and Name Resolver

Due to the performance of interpretation of Java
Byte Code, it became necessary to map Java Byte
Code efficiently onto hardware machine code. To
increase performance, whole methods can be
compiled and stored in a special memory area,
4.3. Processing Java Byte Code

This section will provide an insight into the
execution of the Java Byte Code generated from
the source code sample introduced in section
3.1.1. Starting the execution of the sample lets the
18
5. Basic Technology Approaches
JVM create a new frame. In this frame an array for

the local variables is created and the initial values
are filled into. The Java Byte Code command in
byte 00 and 01 for example initializes the local
variable on position 1 of the array.[J2SPEC]
In the following sections, a closer look on two

basic technologies, garbage collection and Just-inTime (JIT) compilation, will be provided.
Both technologies can be used to describe the
different requirements on client and server JVM.
00 iconst_1
01 istore_1
5.1. Garbage Collection
The integer value 1 is PUSHed onto the

Operands Stack and then POPed into position 1 of
the local variables array within the current frame.
This means that the two lines above are equal to
the line
Objects located on the heap typically are

composed of the object data as well as a two-word
object header, usually containing at leased two
bits used to distinguish different states of garbage
collection. An object can be referenced or nonreferenced, it can be already finalized or still
waiting for finalization. Only objects which are
non-referenced can be garbage collected. Objects
containing a finalizer can only be garbage
collected after its execution.
A finalizer is code associated with an object
and executed directly before the garbage
collection of the object.
The typical solution towards the garbage
collected heap, is a non-parallel, single spaced,
non concurrent garbage collector. This means that
all threads running in the JVM are stopped, while
the garbage collector running on one single
processor identifies all non-referenced objects in
the whole heap. Analyzing all existing references
lets the garbage collector search any local
variables as well as any elements in the operands
stack in every Java-Frame and every hibernated
thread.
If a reference to an object can be found, its
referenced-bit is set to true. Finalizer code
assigned to the special object, is prepared for
execution by creating a new thread or a new
frame on top of the frame stack. Objects
containing a finalizer are marked as finalized after
the execution of their finalizer. Therefore these
objects are deleted in the next garbage collection
cycle. All other objects can be deleted from the
heap before or while defragmentation of the heap,
witch can be done by moving object beside each
other and updating existing references.
Starting the garbage collector by using
commands like system.gc() or runtime.gc()
not guarantee a complete execution of the garbage
collection. In Suns classic Java implementation it
is not feasible to prevent the starting of the
garbage collection during time-critical processes
or limit the time or resources consumed by the
garbage collector [JWorld].
int a=1;
from the source code introduced in Figure 2. The

first entries starting from 0 in the array are
reserved for primitive parameters or parameter
references. The command iload_X or iload X
used in Figure 3 loads the content from position X
in the local variables array to the operands stack.
The command imul used in byte 13 lets the ALU
take two topmost elements from the operands
stack, multiply them and PUSH the result back on
the stack.
JAVA (Frame) Stack
Locals
Operands Stack
Control Unit
c
b
c*d
a
Frame
Frame
Byte Code Processor
ALU
Frame
Figure 5: Execution of the code sample, state

after execution of imul (byte 13)
The command iadd in byte 14 also takes two

integer values from the stack and pushes the sum
of both back on the stack. Before finally leaving
the method main by executing retun, the top
element of the stack is stored by istore_2 into
the second position of the local variables array.
19
5.2. Just-in-time Compilation
the chance to run on multiprocessor systems. For

that reason client JVMs do not support high
performance mappings between Java threads and
hardware processors. A JVM running on a client
system will be rebooted or shut down if the
computer itself is shut down, e.g. every evening.
A server JVM normally has to run for several
weeks or months without any reboot or restart.
This forces the server JVM to provide much more
reliability.
Running on a server with large scaled memory
does not mean to the JVM to consume big
amounts of memory. Actually it rather means to
manage the usage of memory and other hardware
resources very efficiently to archive the best
quality of service.
Creating machine code for the current

environment on-the fly during the execution of
the Java program from the Java Byte Code is a
concept named Just-in-Time compilation.
This fast compilation processed during runtime
makes it possible to the Java platform to deploy
platform independent small Java Byte Code
programs. In contrast to classic approaches
compiling source code to different platform
specific native codes these programs can be
compiled from the intermediate language to
native code if feasible. If a mapping from the
platform independent Java Byte Code is not
wished or available the it can also be interpreted
as described in section 4.3.
If the JIT compiler is enabled, calling a method in
the Java Byte Code will make the JIT compiler try
to resolve the methods name within the native
methods area. If this resolving succeeds, the
method will be processed using the native
method stack similar
to
the
Java
frame
stack.[J2SPEC]
If the native code assigned to the methods symbol
is not available inside the native method area the
corresponding Java Byte Code is extracted from
the Java Byte Code area and compiled to native
code. This native code finally is stored inside the
native methods area and executed.
The classic JIT compiling approach is to compile
every method called to native code. The classic
approach also uses just one single compiler
optimized for a short compilation time, to
increase the startup as well as the so called first
run performance.
6.2. Industrial approaches towards

Server JVM
Different suppliers for Java server solutions exist.
Some of them, such as Sun or IBM, do provide
server JVMs as well as server hardware.
BEA, the provider focused on in the following
section, provides a high performance server JVM
optimized for Intels server architectures such as
Xeon or Itanium 2. The distribution of these
server systems makes the BEA solution, JRockit,
an important competitor in the field of server
JVMs.
Optimizations and realizations made by BEA in
the field of JIT compiling and garbage collection
will be explained in the following sections.
6.2.1. Incremental optimizing JITCompilation

As mentioned in section 5.2 the compilation
processed during execution of the Java program
has to be as fast as possible, to provide a short
startup time and to avoid compilation breaks
during the execution of a program.
Based on the idea that a program spends most
of its runtime in few central methods, BEAJRockit analyses the program during runtime and
increases the optimization of its compiler
incremental. A high efficient compiled method
will run faster, but the compilation process itself
will need much more time, creating more efficient
code.
The entire sample byte code from Figure 3
could be optimized to
6. Server JVMs
After describing basic technology approaches, this
section will describe the basic requirements
existing for server JVMs. Based upon these
requirements, the influence of the described
technology approaches, JIT compilation as well as
garbage collection, will be analyzed. This will be
done by presenting the basic ideas behind BEAJRockit. [BEAJ4E]
6.1. Requirements for Server JVM

Differences between desktop or client JVMs in
contrast to server JVMs can be found in runtime,
restart
frequency
or
memory
quantity.
Additionally desktop JVMs usually are not given
iconst 9
istore_2
20
technologies to provide an optimized garbage

collection strategy. The combination of these
options is automatically adapted during runtime
based upon information collected from the JVM
during runtime. [BEAJ4E]
In contrast to Suns JVM JRockit deallocates
unused memory before allocated for the heap.
or even removed at all, during the compilation to

native code, because of its redundancy and it
missing of side effects, before compiling to native
code. Such optimization is not suggestive for
every method, but it can result in much faster
execution of core methods. The fast compiled first
version native code is replaced during runtime by
new compiled higher optimized native code. This
can be done through several levels, always
providing faster code.
To examine these core methods, BEAs JRockit
has been instrumented with special sensors
giving the possibility of runtime analyses without
using a special and slow debugger mode to the
user. [BEAJ4E]
6.2.3. Just-in-Time monitoring

As mentioned before the BEA-JRockit JVM has
been instrumented with different sensor systems
delivering information for incremental JITcompilation or adaptive garbage collection.
These information are also provided to the user.
The user of the BEA-JRockit JVM can get runtime
information about heap and memory usage,
garbage collection, core methods as well as
information about the current execution time in
the Java Byte Code. Logging these information as
well as exception occurrence and further
execution details are also provided. [BEAJ4E]
6.2.2. High-performance Garbage Collection

Another field described before is garbage
collection. To optimize garbage collection, BEA
provides four different garbage collection
algorithms. Every garbage collector provides
another combination of garbage collection
frequency and duration. All four garbage
collectors are more efficient than the garbage
collector described in section 5.1.
BEA-JRockit supports parallel garbage collection,
concurrent garbage collection and generational as
well as single spaced garbage collection.
[BEAMMS]
Parallel garbage collection is garbage collection
performed by all available processors while the
Java threads are stopped. This garbage collector
has to be performed often, but provides a fast
cleaning and defragmentation of the heap.
Concurrent Garbage collection has been
developed
for
multiprocessor
systems.
Performing concurrent garbage collection means
that one single processor searches for
unreferenced objects in the heap during the entire
runtime of the JVM. To perform defragmentation
of the heap the JVM still has to be stopped for a
very short time.
In contrast to the single spaced garbage
collector the generational garbage collector
divides the memory in different sections
describing the age of the objects stored in. This
approach follows the idea that objects which
already exist for a long time will furthermore
exist for a long time as well. Based upon this
approach, the heap which has to been cleared is
smaller and the garbage collection finishes faster.
BEA JRockit uses combinations of these
7. Conclusion
Server JVM are high performance, strong
featured, reliable Java Byte Code processors. To
understand all the features provided by modern
server JVM profound knowledge about Java
Virtual Machines is needed.
Server JVMs use platform or even computer
specific characteristics to produce efficient code,
specialized on server-side requirements such as
large scale memory, multiprocessor systems as
well as a long runtime. To provide these,
approaches like adaptive garbage collection,
incremental code optimization and internal
scheduling are used.
Beside these advantages several disadvantages
like higher memory requirements, longer start up
time or less distribution have to be assessed. The
usage of server JVMs should be critically proven
for every application.
8. References
[SPEC]
http://www.spec.org/jbb2000/results/res2005q1/
State: 2005-04-28
[J2SPEC]
The Java Virtual Maschine Specification Second
Edition, Sun Microsystems Inc.
21
[Intel]
[LiMag]
http://www.intel.com/cd/ids/developer/asmona/eng/198984.htm?page=1
Die virtuelle Java Maschine, Linux-Magazin,

1997/06
State: 2005-04-28
[JBoss]
[FMC]
http://www.jboss.com/products/jbossas
http://www.f-m-c.org/notationreference/download/FMC-Notation_Reference.pdf
State: 2005-04-28
[BEAJ4E]
FMC Research Staff, 12/03
BEA-JRockit: Java for the Enterprise, BEA

Systems Inc.
State: 2005-05-17
[BEAMMS]
9. Appendix
Selecting and Running an Memory Managment

System, BEA Systems Inc.
1.
[JWorld]
Architecture of the JVM
Javas garbage-collected heap, Java World,

1996/08
GC
Thread
Frame
Pointer
OnTop
Op.Stack
PC
Vars
Pointer
Heap
JITC
Native Methods
Stack
Const. Pool
Name
Resolver
Control Unit
Method. Area
Locals
Operands
Stack
Native
Byte Code Processor

Frame
JBC
Frame
Frame
ALU
JAVA (Frame) Stack

Initial Class Loader
I/O (OS)
Thread Controller
22
SAP VM Container
Andreas Blher
Seminar System Modellierung 2005
Andreas.Blueher@hpi.uni-potsdam.de
Die Integration d er Java Virtual Machine

(JVM) in d en SAP Ap p lication Server (AS)
stellt eine Bereicheru ng d es ursprnglichen
AS Prod u ktes d ar. Bisher bestand d er AS nu r
au s ABAP Cod e u nd es konnte nu r ABAP
Code in einer VM ausgefhrt werden.
Erst m it d er Integration d es VM
Containers ist es m glich au ch Java Dienste
zu nu tzen bzw . Java Cod e au szu f hren. Das
SAP VM Container Konzep t soll d en SAP
Ap p lication Server u m Java erw eitern u nd
die Konkurrenzfhigkeit zu BEA WebLogic
und IBM WebSphere erhhen.
w ird eine Java VM Architektur vorgestellt

und beschrieben w ie d ie id eale Integration
der Java VM in den SAP AS aussehen wrde.
Der AS stellt Dienste f r viele
verschied ene N u tzer zu r Verf gu ng. Jed er
N u tzer kann Anfragen an d en AS stellen u nd
somit Dienste in Anspruch nehmen.
Im SAP AS w erd en d ie Anfragen an d en
Dispatcher geleitet und w elcher die Anfragen
au f d ie verschied enen freien Workp rozesse
verteilt. Ein Workp rozess ist f r d ie
Abw icklu ng von N u tzeranfragen in einem
Ap p lication Server verantw ortlich. Zu einem
Zeitp u nkt w ird in einem Workp rozess
m axim al eine Anfrage bearbeitet, sod ass eine
hohe Isolation zw ischen d en N u tzern u nd
d eren Anfragen gew hrleistet ist, d ies w ird
als Robu stheit bezeichnet. Des Weiteren ist
d er AS gu t skalierbar, w eil d u rch d as
H inzu f gen
neu er
Maschinen
neu e
Workp rozesse bereitgestellt w erd en knnen.
Robustheit u nd Skalierbarkeit sind au ch d ie
zwei wichtigsten Anford eru ngen d ie SAP an
den Application Server stellt.
Ein erster Ansatz w re es, eine Java VM
d u rch einen SAP Workp rozess abwickeln
u nd so Java in d en AS zu integrieren. In
Verbind u ng m it d en Anford eru ngen von
SAP an d en AS ist d ieser Ansatz nicht
realisierbar, dies macht der nchste Abschnitt
deutlich.
1. Architektur SAP AS
2. Architektur einer Java VM
Um d as VM Container Konzep t im Um feld

d es SAP AS beschreiben zu knnen, ist eine
ku rze Einf hru ng in d ie Architektu r u nd d ie
Fu nktionsw eise d es AS notw end ig. Danach
Die genau e Fu nktionsw eise d er Java VM ist

z.B. u nter [JRockit] nachzu lesen. Wichtig f r
d as Verstnd nis d es SAP VM Containers ist,
d ass
d u rch
d en
Thread
Controller
Abstract
Dieser A rtikel bietet eine Einfhrung in das
Konzept und die A rchitektur des SA P V irtual
M achine (VM) Container.
Z u Beginn stelle ich den SA P A pplication
Server vor, in dem der V M Container laufen
wird.
Danach werden A nstze erlutert, wie Java in
den A pplication Server integriert werden kann.
A bschlieend wird das Konzept des V M
Containers und zwei konkrete Implementierungsanstze vorgestellt.
Keywords: VM Container, Architektur, SAP,
Application Server
0. Einleitung
23
GC
Java Thread
Locals
Operanden
Stack
Heap
Control Unit
Const Pool
JITC
Frame
Byte Code
Processor
Meth.
Area
Native
Frame
JBC
Frame
ALU
Java Stack
Init Class Loader
Threadverwalter
I/O (OS)
Bild 1 Architektur Java VM
verschiedene Java Threads gestartet werden.

Diese Threads verfgen hnlich w ie
Workprozesse ber einen eigenen lokalen
Speicher. In jed em Java Thread knnen
Anfragen von verschied enen N utzern
beantw orten
w erd en.
Objekte
w ie
Nutzerdaten liegen in einer gem einsam en
Heap und sind fr alle N utzer zugnglich.
Objekte w ie d er Program m counter w erd en
lokal im Java Thread gehalten, d .h.
verschiedene N utzer knnen auf gleiche
Objekte zugreifen. Die Isolation innerhalb
und zw ischen d en einzelnen Java Thread s
gengt damit nicht d er Anford erung nach
Robustheit d es SAP AS. Dazu knnen in
einem Java Thread mehrere Anfragen von
mehreren Usern beantwortet werden.
Sollte eine d ieser Anfragen d ie in einem
Java Thread bearbeitet w erd en fehlschlagen,
kann d ies d azu fhren, d ass d ie gesamte
Virtual Machine beend et w ird . Wenn bei d er
Ausfhrung eine Exception gew orfen w ird ,
gibt es keine ausreichend e Trennung
zw ischen d en einzelnen Anfragen, sod ass ein
Beend en d er einzelnen Anfrage nicht
m glich ist. Durch d en Einsatz gezielter
Techniken wie Exceptionhandling muss dann
verhind ert w erd en, d ass d er gesam te Java

Thread beend et w ird. Im schlimmsten Fall
kann eine unbehandelte Exception sogar zum
Absturz d er gesam ten Java VM fhren.
Dad urch w ren alle Anfragen d ie sich gerad e
in d er Bearbeitung befu nd en haben m it allen
bereits berechneten Teilergebnissen verloren.
Sollte ein N utzer im m er w ied er inkorrekte
Anfragen schicken, d ie zum Abbru ch eines
Java Thread s od er d er Java VM fhren,
beeintrchtigt er d am it d as gesam te System ,
w eil
and ere
Anfragen
d urch
d as
Fehlverhalten nicht m ehr korrekt au sgefhrt
werden knnten.
Diese geringe Isolation zw ischen einzelnen
Anfragen verschied ener N utzer ist nicht nur
fr d en Einsatz im SAP AS nicht akzeptabel,
auch in allen and eren App lication Servern
m uss es Mechanism en geben, um d ieses
Szenario zu verhindern.
2.1. Ideale Integration der Java VM

Ebend w urd e gezeigt, d ass es nicht ausreicht,
eine norm ale Java VM von einem
Workprozess abw ickeln zu lassen. Es m ssen
strkere
Isolationseigenschaften
erfllt
werden, d enn d as Ausfhren m ehrerer
24
Anfragen in einer VM birgt viele Risiken.

Bild 2 begegnet d em und stellt die id eale
Abarbeitung von Useranfragen in JavaMehrnutzersystemen vor.
User A
schnell w ie d enkbar abzuarbeiten. In d er

Praxis ist ein solches System auf Grund d er
gestellten Anford erungen zurzeit nicht
praktikabel implementierbar.
User B
2.2. Wahl der Virtual Machine

SAP stellt an d ie Virtual Machine, d ie im
Application Server laufen soll, hohe
Anford erungen
um
ein
m glichst
performantes und sicheres Ergebnis zu
erzielen. Wie unter Punkt 2 schon vorgestellt
wurde, sind regulre Java VMs nicht
geeignet, w eil d ie Isolation zw ischen
verschied enen N utzern und d eren Anfragen
nicht ausreicht.
Aus d en genannten Grnd en w ird nach
d em VM Container Konzept nur noch eine
Nutzeranfrage zu einem Zeitpunkt in d er
Virtual Machine gehalten. Eine VM d ie nur
noch von einem N utzer Anfragen bearbeitet,
bentigt d em zufolge auch keine MehrNutzer-Verwaltung.
Dies w ar einer d er Grnd e, w arum sich
SAP f r d ie Compact Virtual Machine (CVM)
entschied en hat. Die CVM ist Bestand teil d er
J2ME (Java 2 Micro Ed ition) und d am it fr
Anw end ungen auf Palm s, PDAs und
and eren m obilen Gerten entw ickelt w ord en,
d ie ber w enig Ressourcen verfgen. Sie ist
eine vollw ertige JVM d ie bez glich d es
Ressourcenverbrauchs stark optim iert w urd e
und entsprechend d en Anford erungen
verndert werden kann [CVM].
Ressourcen zu sparen ist auch in einem
Application Server von SAP ein immer
aktuelles Them a. Mit d er CVM wurde eine
Java VM ohne Mehr-Nutzer-Verwaltung und
ohne Multi-Threading gew hlt, d ie aber
dennoch ber alle Fhigkeiten verfgt, d ie
bei d er Abarbeitung d er N utzeranfragen in
einem SAP AS bentigt w erd en. Denn d ort
w ird zu einem Zeitp unkt m axim al eine
Anfrage bearbeitet.
JRE
JRE
JVM
JVM
Computer
App 2
App 1
Bild 2 Ideale Java Umgebung
Die Id ee ist es, jed em N utzer eine eigene Java

VM zuzuteilen und alle Anfragen und
Berechnungen in d ieser JVM ablaufen zu
lassen. N utzer B ist es zu keinem Zeitpunkt
m glich auf d ie Daten von N utzer A
zuzugreifen, w eil d iese gegenber allen
and eren N utzern gekapselt sind. Sollte ein
N utzer m ehrere Anfragen starten, knnen
d ie Daten in der selben VM erneut genutzt
werden.
Jed och ist d ieser Ansatz praktisch nicht
realisierbar. Dabei spielt d er verbrau chte
Arbeitsspeicher in d iesem Zusam m enhang
d ie grte Rolle. Jed er N utzer, d essen
Anfragen von d em vorgestellten System
abgearbeitet w erd en sollen, bentigt eine
eigene Virtual Machine m it eigenem JRE
(Java Runtime Environment).
Jed e VM bentigt um lauffhig zu sein
Daten w ie z.B. Klassenbibliotheken. Diese
mssen
bei
d ieser
Im plem entierung
red und ant gehalten w erd en, um d as hohe
Ma an Isolation zw ischen d en einzelnen
VMs zu gew hrleisten. Ferner erscheint d ie
Abwicklung in einer eigenen Java VM nu r
dann sinnvoll, w enn auch fr jed e VM ein
eigener Betriebssystemprozess (gleichzeitig
auch Hardwareprozessor) zur Verfgung
steht, mit dem die VM abgewickelt wird.
Sollten Ressourcen w ie CPU Zeit
(Prozessoren) und
Arbeitsspeicher
in
ausreichender Menge verfgbar sein, w rd e
d er vorgestellte Ansatz eine Mglichkeit
d arstellen, N utzeranfragen so sicher und so
3. Das VM Container Konzept

Das VM Container Konzept beschreibt w ie
eine Java VM in die Architektur des SAP AS
25
Dispatcher
Active Workers
Worker Pool
Work Process 1
Server Data
Work Process 2
Rolled out
Rolled out
Java VM
Java VM
Active
Java VM
Active
Java VM
User Data
User Data 2
User Data 1
User Data 3
VM Data
VM Data 2
VM Data 1
VM Data 3
Inactive VMs
Work Process m
Work Process 3
New
New Java VM n
Java VM 4
VM Data
VM Data
Active VMs
New VMs
Shared Memory
Bild 3 Classic Approach
integriert werden kann.

Es gibt zw ei Anstze d er SAP d en VM
Container in d en Applikation Server zu
integrieren, d en Classic App roach und d en
Olym pia Approach. Folgend stelle ich beide
Anstze kurz vor und gehe auf Vor- und
N achteile ein. Abschlieend w ird ein Fazit
zum aktuellen Stand gezogen.
Anfragen d es N utzers abgearbeitet w erd en,

ohne, d ass von auen auf d en Container
zugegriffen werden kann.
Die gesam te VM m it N utzerd aten und
VM-Daten liegt im Shared Mem ory u nd w ird
zur Abarbeitung in d en lokalen Speicher
eines Workprozesses gem appt. Das bed eutet,
es w ird nu r ein Verw eis auf d ie VM im
Shared Mem ory gelegt. Dieses Mapping ist
sehr schnell und kostengnstig, w eil kein
kopieren notw end ig ist. Desw egen ist
Mapping auch kein Problem fr d ie
Performance und kann hufig d urchgefhrt
werden.
Im Aufbaubild habe ich d en VM
Container bew usst nicht als Akteur
eingefgt. Der VM Container stellt eine .
3.1. Classic Approach

Wie ich bereits unter Kapitel 2 vorgestellt
habe, w erd en in einer norm alen Java VM
Userdaten und VM-Daten zusam m en in
einer H eap gehalten. Im Classic Approach
wird f r jed en N utzer w hrend einer Session
eine eigene VM verw end et, um eine
m glichst hohe Isolation zw ischen d en
einzelnen Sessions zu erreichen und zu
verhind ern d as auf Daten and erer Nutzen
zugegriffen w erd en kann. Eigene Daten
sollen auch von keinem and eren N utzer
bearbeitet werden knnen.
Die Virtual Machine kann als Container
bezeichnet w erd en in d en d ie N utzerd aten
eingepflegt w erd en und in d em alle
3.2. Konsequenzen des Classic

Approach
Der Classic App roach hat Nachteile. So
bentigt m an fr jed e N utzersession eine
eigene VM und d am it Speicherp latz. Des
Weiteren w erd en z.B. Konfigurationsd ateien
26
d ie beim Start einer App likation erstellt bzw.

ausgefhrt w erd en m ssen, red und ant
gespeichert. Denn es ist nicht m glich von
einer VM auf eine and ere VM zuzugreifen,
da d ie Speicher voneinand er gekapselt sind .
Durch d iese Red und anz knnen leicht
m ehrere
GByte
Arbeitsspeicher
m it
redundanten Daten gefllt werden.
Der Fakt d as fr jed e N utzersession eine
eigene VM zu Abarbeitung bentigt w ird ,
w irft noch ein zw eites Problem auf. Alle
Nutzeranfragen d ie keine freie Virtual
Machine zur Verfgung haben, m ssen
entw ed er auf eine Warteschlange gesetzt
oder abgelehnt werden.
In einem Application Server w erd en zu
einem Zeitpunkt hunderte von Anfragen von
verschied enen N utzern bearbeitet. In d iesem
Zusam m enhang w ird sehr schnell d eutlich,
w elch starke Beschrnkung d ie Anzahl d er
VMs darstellt.
gesam te
Dauer
d er
Session
zusammenhngend zu halten, w erden die
Nutzerdaten getrennt im Shared Mem ory
abgelegt.
Die Trennung von N utzer- und VMDaten ist keinesfalls einfach und kann
d eshalb nur in bestim m ten Zustnd en d er
Virtual Machine vorgenom m en w erd en,
d enn auf d er H eap liegen sow ohl N utzer- als
auch VM-Daten.
Wird in d er VM gerad e eine Anfrage
bearbeitet, haben d er Program m counter und
and ere
w ichtige,
zur
Abarbeitung
notwendige, Daten einen bestim m ten Wert.
Wrd e jetzt d er Befehl gegeben w erd en, d ie
N utzerd aten auszulagern und im Shared
Mem ory abzulegen, ginge zw angslufig der
Zustand der VM verloren. Eine Trennung der
Daten w hrend d er Bearbeitung ist nicht
mglich,
w eil
sonst
notwendige
Informationen verloren gehen.
Die Trennung von N utzer- und VMDaten ist som it nur m glich, w enn sich d ie
Virtual Machine in einem initialen Zustand
befind et. Darunter verstehe m an d en
Zustand einer VM, in der sie unabhngig von
jeglichem N utzerkontext ist. Diesen Zustand
3.3. Olympia Approach

Im Unterschied zum Classic Approach
w erd en beim Olym p ia App roach statt
N utzerd aten und VM-Daten ber d ie
Dispatcher
Active Workers
Worker Pool
Work Process 1
Server Data
Work Process 2
Work Process m
Work Process 3
User Data 2
Rolled out
Java VM
User Data 4
Active
Java VM
Active
Java VM
User Data 3
User Data 6
VM Data 1
VM Data 3
Java VM n
Java VM 4
User Data 1
User Data 5
User Data
Shared Closure
VM Data
VM Data
VM Data 2
Active VMs
Shared Memory
Bild 4 Olympia Approach
27
Inactive VMs
erreicht d ie VM nach Bearbeitungsbeginn

einer Anfrage erst w ied er nach Beend igung.
Durch d en Austausch d er N utzerd aten kann
ein N utzerw echsel in d er Virtual Machine
durchgefhrt werden.
Beim Olym pia Approach w ird in d en
lokalen Speicher jed es Workp rozesses ein
VM-Gerst abgelegt. Stellt ein N utzer eine
Anfrage, w erd en d ie N utzerd aten in d en
lokalen Speicher d es Workprozess, in d as
VM-Gerst, kopiert. Erst w enn d ie Anfrage
fertig abgearbeitet ist, knnen N utzer- und
VM-Daten getrennt w erd en, um d ie
N utzerd aten zur ck in d en Shared Mem ory
zu auszulagern.
Da I/ O Anfragen d ie Abarbeitung
unterbrechen knnen und d er lngere
Stillstand eines Workerprozesses nicht
akzeptabel ist, m uss eine Mglichkeit
gefund en
w erd en
d en
Workprozess
and erw eitig zu nutzen. Dabei wird der
Classic Ap proach eingesetzt. Die gesam te
VM w ird hierbei aus d em lokalen Speicher in
d en Shared Mem ory kopiert w erd en. Bei
groen Datenm engen ist d ies eine sehr teure
Operation und zeigt d eutlich eine d er
Schw chen d es Olympia Approach. Dazu
m uss ein neues Gerst in d en lokalen
Speicher d es Workprozesses kopiert w erd en.
Ist d ie I/ O Anfrage beantw ortet, m uss d as
Gerst w ied er ausgelagert und d ie gesam te
VM zu r ck kopiert w erd en. Dieses Vorgehen
ist sehr ressourcenaufwndig, aber nicht
vermeidbar, w eil d er Zustand d er VM, in
d em sie sich vor d er I/ O Anfrage befand ,
gesichert wird.
Da d ie N utzerd aten im Vergleich zu d en
VM-Daten im N orm alfall um ein vielfaches
kleiner sind und d am it teurer Speicherplatz
gespart w erd en kann, ist d er Olym pia
Approach
d ennoch
em pfehlensw ert.
Trotzdem m uss beobachtet w erd en, ob d ie
Vorteile bei d er Speicherplatzbelegung nicht
d urch d en erhhten Aufw and beim Kopieren
d er Daten aufgehoben w erden. In einem
System m it groen Mengen N utzerd aten und

vielen I/O Anfragen m uss d ie Frage gestellt
w erd en, ob d er Classic Approach nicht zu
bevorzugen ist.
4. Zusammenfassung
SAP hat sich mit dem VM Container Konzept
d ie Tore in ein neues Geschftsfeld geffnet.
Die gew hlte Im plem entierung ist sehr
robust und gut skalierbar und som it id eal f r
d ie Integration in d en SAP Ap plication
Server.
Im Vergleich zu den Konkurrenten IBM
und Bea fehlt d er SAP aber noch
Perform ance. So ist d er VM Container ca.
20% langsam er als vergleichbare Prod ukte.
Dieser Performanceverlust ist zu gravierend
um ein ernsthaftes Konkurrenzprod ukt
d arstellen
zu
knnen.
Als
zw eiter
entscheid end er N achteil w ird bisher nur Java
in d er Version 1.3 d urch d en VM Container
untersttzt.
SAP w ird d ie genannten Schw chen
d ringend beseitigen m ssen, um ein
ernsthafter Konkurrent fr Firm en w ie IBM
und BEA werden zu knnen.
References
[JRockit] Sebastian Steinhauer, BEA-JRockit, a Java
Virtual Machine for server-side use. Potsdam
05.2005
[SAPVM1] E. Lck, K. Hbner and M. Wintergerst,
SAP VM Container. Walldorf, 07.2004
[SAPVM2] Michael Wintergrest, VM Container
Architecture Overview, Walldorf 07.2004
[SAPVM3] N. Kuck et al, SAP VM Container: Using
Process Attachable Virtual Machines to Provide
Isolation and Scalability for Large Servers. Walldorf
[FMC] FMC Research Staff, 12.2003, http://www.f-m c.org/notation-reference/download/FMCNotation_Reference_Sheets_pdf.zip
[CVM] CDC Hotspot Implementation Overview,
http://java.sun.com/products/cdchi/overview.html
28
Administration of the
Martin Wolf
martin.wolf@hpi.uni-potsdam.de
Abstract
greater detail in the first part of this article.

There is a reference implementation of the Java
Management Extension specification provided by
SUN but each vendor can have their own
implementation. How the specification is
implemented by SAP will be topic of the second
part. The Web AS components are described as
well as the main services responsible for offering
administration functions.
These functions are used by the administration
tools provided by SAP to control the Web AS. The
last part gives details about which tools are
available and what for they serve. Moreover, the
connection between these tools and the SAP
implementation of the Java Management
Extension is stated.
Usability is an important factor in the evaluation of a

software product. In order to reduce the total cost of
investments a support infrastructure is necessary that
offers both powerful configuration and intuitive access
features.
This paper aims to offer an introduction to the
administration infrastructure of the SAP Web
Application Server, which is an important element
within a support infrastructure. The basic technologies
are presented as well as their SAP implementation.
Furthermore, the administration tools provided by
SAP will be presented.
Keywords: JMX, MBean, SAP Web AS,
Administration Services, Visual Administrator
2. Java Management Extension
1. Introduction
Java Management Extension (JMX) is a nonproprietary technology specification which was

developed in the course of the Java Community
Process. Companies like IBM, BEA Systems, SAP
and SUN are working together to specify the JMX
standard. It defines a management architecture as
well
as
design
patterns,
Application
Programming Interfaces, and services for
application and network management and
monitoring. JMX allows any Java technologybased or accessible resource (which can be
realized through a Java-wrapper 1 ) to be
inherently manageable. Furthermore, by using
Java technology and JMX, it is possible to manage
resources that are originally managed by other
technologies, such as SNMP 2 .
Basically, JMX defines an isolation layer
between applications and management systems.
The SAP Web Application Server (Web AS) in

its current version (6.40) fully supports the J2EE
standard and has therefore a second personality.
Both personalities, ABAP and Java, are integrated
in a common infrastructure. On the one hand, this
integration is completely transparent to users and
applications. On the other hand, it cuts the cost of
administration and enables customers to use their
existing ABAP software and expertise in addition
to benefit from the advantages of Java (nonproprietary, platform-independent, etc.).
The SAP Web AS promises that SAP
applications as well as custom-developed
Java/J2EE applications are centrally managed and
administered. For that reason, the administration
infrastructure of the SAP Web AS is oriented
towards the Java Management Extension
instruction set. This specification defines an
architecture where the management applications
are separated from the resources that should be
managed. Java Management Extension and how it
helps to reach the demands will be explained in
1 A wrapper is a piece of code which is combined with another

piece of code to determine how the latter code is executed.
2 Simple Network Management Protocol (SNMP) can support
monitoring of devices attached through a network.
29
It can be compared to JDBC 3 , which allows

applications to access arbitrary databases. JMX
allows applications to be managed by arbitrary
management systems. One advantage of this
separation is the possibility to make Java
applications
manageable
without
great
investments. Other advantages include the
scalability of the management architecture, and
the option to integrate given management
solutions. Manageable resources are represented
by one or more manageable beans.
default behaviour for dynamic instrumentation of

resources. The type of MBean determines how the
MBean is deployed on the MBean Server, but it
has no effect on how the bean is managed. All
MBeans are designed to be standardized, flexible
and easy to implement.
Administrative functions of the Web
Application Server and all the parameters
monitored by diagnostics programs are provided
by MBeans.
2.2. Architecture
2.1. MBeans
The JMX architecture is divided into three

levels:
In the Java programming language, a

manageable bean (MBean) is a Java object that
represents a manageable resource, such as an
application, a service, a component or a device.
This object must be assigned a unique object
name. A management application uses the object
name to identify the object that will perform a
management operation, such as reading and
writing attribute values of the MBean.
Additionally, there are operations for
receiving notifications generated by MBeans and
querying MBeans based on their object name or
their attribute values. It is also possible to perform
operations defined by the MBean itself.
Altogether there are four types of MBeans:
Instrumentation Level
Agent Level
Distributed Services Level
Altogether they specify a JMX agent which
runs on a Java Virtual Machine. Such a JMX agent
and its basic components are shown in the
following block diagram (fig. 1).
Standard MBeans
Dynamic MBeans
Open MBeans
Model MBeans
A standard MBean is a concrete Java class

that includes the implementation of its own
MBean interface. These MBeans are easy to design
and implement when developing new JMX
manageable resources. Their management
interface is described by their method names.
An MBean that offers a dynamic
management interface is referred to as a Dynamic
MBean. Certain elements of its instrumentation
can be controlled during runtime for greater
flexibility.
Open MBeans are Dynamic MBeans that rely
on basic data types for universal manageability;
they are self-describing for user-friendliness.
Model MBeans (also Dynamic MBeans) are
fully configurable and self-descriptive during
runtime. They provide a generic MBean class with
Figure 1, JMX Architecture
2.2.1. Instrumentation Level

The instrumentation level specifies the way to
implement resources, i.e. the way to design
MBeans. All resources that provide functions are
represented by one or more corresponding
MBeans. Moreover, the instrumentation level
specification describes notification mechanisms
that allow MBeans to generate events, such as
timeouts, and notify other components of them.
2.2.2. Agent Level

The agent level specification is the most
important one. This tier contains the MBean
server and a set of agent services. The MBean
Java Database Connectivity (JDBC) is an API that offers a

uniform interface to data bases of different vendors.
3
30
server is the key stone to the JMX architecture. It

is responsible for handling MBeans and therefore
provides some services, such as instantiation of
new MBeans. Another service is to register new or
existing Mbeans in the central object repository.
All objects to administer are registered in
that repository. Other services that can perform
management operations on the MBeans are
referred to as agent services. Through the
inclusion of including management intelligence in
the JMX agent, more powerful management
solutions can be achieved. There are four such
agent services that are required to be supported
by the JMX agent:
Dynamic class loading retrieves and
instantiates new classes and native libraries
from an arbitrary network location.
Monitor services observe the values of
attributes of several MBeans and can notify
other objects of changes.
Timers provide a scheduling mechanism (onetime alarm-clock notification or periodic
notification).
The relation service defines associations
between MBeans and ensures their consistency.
Figure 2, JMX Remote Connection Types

Depending on the JMX compatibility of the
management application, the connector client can
be integrated into a JMX manager. That JMX
manager creates management interfaces and
adapts Application Programming Interfaces. For
each connected client there is one connector
server.
These two components convey management
operations transparently over a specific protocol,
such as CORBA 4 . Because compliant connector
implementations must observe the JMX protocolspecific rules for how to exchange data, in theory,
any connector client supporting protocol X should
be able to connect to any connector server that
supports protocol X as well.
Protocol adapters alter the operations of
MBeans and the MBean server into a
representation in the given protocol, such as
HTTP, and possibly into a different information
model, for example SNMP. Management
applications that connect to a protocol adaptor are
usually specific to the given protocol. This is
typically the case for legacy management
solutions that rely on a specific management
protocol. They access the JMX agent not through a
remote representation of the MBean server, but
through operations that are mapped to those of
the MBean server.
2.2.3. Distributed Services Level

The last tier is the distributed services level,
which contains the components that enable
management applications to communicate with
JMX agents.
Once an application that determines
management (such as switching JDBC sources at
runtime or changing logging properties) and
monitoring functionality (response time of
requests or number of live business objects) is
deployed, the information is distributed through
one or more MBeans. Management applications
can now gain access remotely to the functionality
of the application through the use of either a
connector client or a protocol adaptor depending
on their implementation. The block diagram (fig.
2) in the right column illustrates the three remote
connection types.
A connector provides the same interface to the
management application as the MBean server.
Although the management application is running
on a remote Java Virtual Machine it can use the
MBeans as if they were local. This kind of
communication involves a connector server,
which is set up and configured by the MBean
server and a connector client in the manager.
4 Common Object Request Broker Architecture (CORBA) is a

cross-platform middleware architecture that defines protocols
and services.
31
MBean Server
RDMS
Global Properties
Central Services
Libraries
Interfaces
Figure 3, JMX implementation by SAP

low level components have no knowledge of
component interfaces above them.
The application developer is engaged with
the first layer and the APIs provided by the
underlying tiers. These underlying tiers are
explained more precisely in the following lines
and are illustrated in the block diagram (fig. 3) on
top of this page. For design purposes and because
in this context it is permissible, there is only a
dispatcher process running in the J2EE Engine.
3. SAP Implementation
After introducing the JMX specification in
general, its implementation by SAP is the topic of
the next section. The main element of a SAP Web
AS is at least one J2EE Engine, which comprises
one dispatcher and several J2EE Server
Application Server Processes. Each of these
processes runs on their own Java Virtual Machine.
The architecture of the server and dispatcher node
is the same from the runtime design point of
view. It is divided into three layers:
3.1. Kernel
The Java-Kernel provides basic functions
concerning resource management and the
operating system. The Kernel is divided into
subsystems internally called managers. Those
core modules are divided in several groups in
accordance to their specific function:
Application Layer
Infrastructure Layer
Kernel
The communication between components in
those layers is based on the Top-Down-Approach,
that is, higher level components can access the
interfaces from lower level components, whereas
32
3.2.3. Services
Class Loading System

(registering and managing of references)
Thread System
(Thread pooling and management)
Cluster Manager Configuration
(handling cluster elements)
Communication Management
(sockets and session communication)
Service Management
( control of services)
Services are more powerful than the

previous two components. They have a complex
lifecycle handling and well defined interactions.
Furthermore, such components are able to access
and utilize functions from the Kernel through the
APIs made available by the managers. Apart from
their name and a set of classes, services provide
the system with runtime objects. These runtime
objects are registered on the system once the
component classes have been loaded. If a service
integrates the functions of a manager, it is
referred to as a core service. Core services are
initialized during the starting process of a
dispatcher or server process. If the initialization
fails, the whole starting process will be halted.
The manager functions can only be used

through services that implement the APIs
provided by the managers. Thus the Kernel is
separated from the next level.
3.2. Infrastructure Layer
3.3. Implementation
The Infrastructure Layer is the most

important one, and consists of the pluggable
components. Built on top of the Kernel and being
able to communicate and use each other, these
components
form
the
complete
system
infrastructure, able to run both J2EE and SAP
proprietary applications. Components in the
infrastructure layer implement specifications
concerning the application programming model 5
and several services, such as the security service
and the local and distributed naming service. The
three types of pluggable components are
interfaces, libraries and services.
As required in the JMX specification, there

are one or more MBeans for each component.
Generally, these MBeans can be separated in two
groups:
Generic MBeans offer basic functions
depending on the type of the component. These
functions can be starting and stopping or
editing of properties for example.
Specific MBeans are created according to the
objects of a component. Thus they offer access
to the functions provided by the component.
In order to administer these MBeans, there
are two main services: the Basic Administration
Service and the Administration Adapter Service.
Additionally there are several services that
provide a means for working with MBeans.
3.2.1. Interfaces
Interfaces
describe
how
different
components work together in the system. They
are defined by a name and a set of classes. A
direct implementation is impossible, so a service
component is necessary to implement the
interface.
3.4. Administration Services

3.4.1. Basic Administration Service
3.2.2. Libraries
The Basic Administration Service is

deployed as a core service, and provides
instrumentation of the kernel and the server
components (libraries, interfaces, services). One
generic MBean is registered to the kernel, but also
each manager can have a specific MBean. With
libraries and interfaces, only generic MBeans are
registered. Two other MBeans are registered by
the Basic Administration Service. The first one is
for the cluster node. It contains methods for
reboot and shutdown, a method for defining the
type of the cluster node (dispatcher or server),
Library components are generic usable

classes without their own lifecycle. They provide
a set of functions, which are represented by
according objects. These objects are created by the
system when it loads the library. One library can
comprise of several classes. The Factory Pattern
and static methods offer access to its functions.
5 An Application Programming Model in this context defines
how to use and combine the features of the J2EE platform to
create solutions for common application domains in
enterprise.
33
and a method for retrieving specific information

such as the cluster ID. The second MBean is
registered for the whole cluster, which has only
one method for retrieving information relating to
the cluster.
have to interact with their local MBean server.

Each local MBean server provides a virtual view
of all MBeans in the cluster, i.e. a client can access
MBeans regardless of whether they are registered
locally or on a remote cluster node
3.4.2. Administration Adapter Service
3.4.4. JMX Notification Service
The Administration Adapter Service is part

of the distributed services level of the JMX
infrastructure. It provides a remote connector to
the MBean Server based on RMI/P4 6 , interfaces
for working with the MBeans registered by the
Basic Administration Service, a Swing 7 -based
Graphical
User
Interface
for
remote
administration, and shell commands for console
administration.
This
means
that
the
Administration Adapter Service provides a
higher-level view of the server.
This view is represented by a tree, the root
node of which is the MBean that allows
management of the cluster. During the
registration process, each MBean can specify a
path in the administration tree where it must
appear when displayed. There is also the option
to group MBeans under a common node in the
administration tree. The interfaces created by the
Administration Adapter Service also enable the
registration of event listeners. These event
listeners can be configured to send notifications
about added/removed MBeans, started/stopped
services, and changed properties, for example.
All MBeans are able to send JMX

notifications if a defined event happens. The
service responsible for the distribution of the
MBean server notifications throughout the cluster
is the JMX notification service. MBean server
notifications inform all the clients within the
cluster about recently registered MBeans and the
removal of MBeans from the MBean server. This
concept of messaging makes administration more
flexible.
4. SAP Administration Tools

4.1. Visual Administrator
While on the server side the previously
mentioned services provide information about
registered MBeans and make the access to them
possible, the Visual Administrator is used on the
client side to work with the administration
infrastructure. This tool thereby uses the API that
is provided by the Administration Adapter
Service. Considering the architecture of the SAP
Web AS, a J2EE Engine is divided in dispatcher
and server processes in the administration tree.
Each process node has subnodes for its
appropriated loaded libraries, the available
interfaces, the loaded services and the active
managers.
3.4.3. JMX Adapter Service

Another important service that provides a
means for working with MBeans is the JMX
Adapter Service. This service creates the MBean
Server and registers all MBeans, except for those
used for administration, which are registered by
the Basic Administration Service. Afterwards, it
manages the configuration and lifecycle of the
MBean server and provides access to it for
applications, services, and libraries. On each node
in the cluster (both types: dispatcher and server),
a local MBeans server is created. The local MBean
servers communicate with each other so that
clients running inside the SAP J2EE Engine only
6 RMI-P4 refers to the development framework that is used to
develop distributed remote Java objects applications on the
SAP J2EE Engine. It is based entirely on the P4 protocol, which
is an SAP proprietary protocol that facilitates communication
between distributed objects from different namespaces
(possibly different hosts).
7 Swing is a GUI toolkit for Java.
Figure 4, Administration Tree in the VA

As mentioned previously, each of these
elements is represented by a generic MBean. In
the Visual Administrator, this MBean is
represented by an Info tab for interfaces and
34
necessary. It facilitates offline configuration of the

J2EE Engine cluster elements, as well as adding
and removing server processes. Moreover,
changing Java parameters like the location of the
Java Home, or the Heap Size of a Java Virtual
Machine is also done by using the Config Tool.
Another option is exporting the system
configuration to an XML file, so the system can be
restored in case of problems.
libraries and a Properties tab for managers and

services. In the latter case the properties can be
modifiable. In case of problems there are default
settings available that can be restored. Timeout
values and location settings for log files are two
examples for changeable properties. Locations of
resource files (e.g. jar-files) and reference settings
cannot be modified from within the Visual
Administrator.
Furthermore, there is a Runtime tab
representing the specific MBean of service
components that provide additional functions. An
important example of this is the access to the user
and policy management through the use of the
runtime view of the Security Provider Service. For
instance, new users can be created and assigned
to a security group. This example is shown in the
screenshot on bottom of this page (fig. 5).
4.3. SAP Management Console

The SAP Management Console 8 is a
graphical user interface for the Java-Startup and
Control-Framework. It offers a central view of all
components of the cluster in a current status tree
with eventual alerts. Monitoring, starting or
stopping any number of SAP systems and
application servers are centrally handled with the
SAP Management Console, as long as they are
running under Windows.
4.2. Config Tool

Besides the Visual Administrator, which is
used for online and remote administration, there
is also a tool applied for the offline
administration. The Config Tool connects directly
to the database so no running J2EE Engine is
4.4. Backup Tools

Backup and restore strategies relate to
specific backup and restore solutions and tools
offered by specific vendors. For that reason, only
Figure 5, Visual Administrator
8 Actually the SAP Management Console is only a snap-in for

the Microsoft Management Console. This console offers a
common framework whereas the snap-in provides the
management functionality.
35
server. This MBean server shall be deemed to be

an isolation layer. In the SAP Web AS, the
administration of these components is supported
by different services named and explained in this
paper. Furthermore, the administration tools
provided by SAP, such as the Visual
Administrator, were introduced.
the general backup strategies are presented in the

following lines. There are two backup strategies
that should be applied to ensure that the system
can be restored.
In order to create a full backup of a system,
so that it can be restored in case of a hard disk
crash or an operating system problem, an offline
backup is necessary. This strategy requires system
downtime, and therefore cannot be performed on
a daily basis.
In contrast to the previous strategy, online
backup takes place during system operations, i.e.
several components and services are running.
This strategy is used for incremental backup of
the database and the file system. Opened files are
ignored during online backup.
References
[JPWAS] Karl Kessler, Peter Tillert and Panayot
Dobrikov, Java-Programmierung mit dem SAP Web
Application Server, SAP Press/Galileo Press,
1st Edition, 2005
[SLIB] SAP Library,
[SDN] SAP Developer Network,
https://www.sdn.sap.com/
5. Conclusion
[JM] SUN AG, Java Management

http://java.sun.com/products/JavaManagement/
The SAP Web AS combines an ABAP personality

with a J2EE personality in one infrastructure
based on the JMX specification. Therefore SAP
applications can run on it as well as any J2EE
compliant software.
The resources in the Web AS are represented
by MBeans and can be accessed by arbitrary
management applications through the MBean
[JMX] JMX Specification 1.2

http://www.jcp.org/en/jsr/detail?id=3
[OIO] Orientation in Objects GmbH, Java und SAP
http://www.oio.de/public/sap-java/
[BS2004] Blain Simpson, JMX Accelerated How-to
http://admc.com/blaine/howtos/jmx/jmx.pdf
36
UME: User Management & Security

Marco Helmich
marco.helmich@hpi.uni-potsdam.de
Abstract
fulfilled.
The main purpose of a user management
system is the authentication and authorization of
users. There are several ways to achieve this goal.
The second part deals with two approaches how
to determine the users identity and permissions.
The third part introduces the role concept,
which aims to abstract from each single
permission and therefore is used to hide the
complexity of permission mapping. Furthermore
two types of roles are described. The basic J2EE
role and its extended version used in SAP Web
AS, the UME role which promises an increased
precision. At the end of this section both roles will
be compared with each other.
After these considerations, there is an
example, which is used to show, how a common
request for a protected resource goes on.
An important topic of user management is giving

users access to sensible company data. With too much
permissions the users can access and modify these
sensible information, with too less permissions they
cannot do their job.
Almost every enterprise has security requirements
and specific mechanisms and an infrastructure to meet
requirements and mechanismes. Sensible resources
that can be accessed by many users, or that often
traverse unprotected open networks (such as the
internet) need to be protected.
The SAP Web Application Server (AS) provides a
new platform for user management to meet the
demands of a modern security model: the user
management engine (UME). This platform offers
centralized user management and the parallel use of
existing user directories.
This paper is intended to describe some basic
concepts of user management in the context of SAP
Web AS and to consider the user management engine
and its techniques.
2. SAP Web AS Architecture

2.1. System Landscape
Keywords: User Management Engine, UME

Roles, SAP Web Application Server
Figure 1 (next page) shows the overall

architecture of a common SAP Web AS with UME
enabled. The web container and the Java Server
Pages (JSP) or Servlets belonging to it form the
presentation layer of this web application server.
The presentation layer offers a graphical user
interface and presents the results, which it
receives from the application logic.
The bean container provides the application
logic in form of Enterprise Java Beans.
Some of these JSPs or beans can be protected
so the user needs the permission to access these
resources. To ensure that the user has the
permission to access these resources the web
container
and
bean
container
engine
communicates with the UME.
1. Introduction
Most software systems contain multiple
components for user management with own
storages for user data and they are distributed all
over
the
system.
Consequences
are
inconsistencies between these storages and high
effort for administration. SAP's user management
engine
(UME)
promises
centralized
administration and parallel use of existing user
directories. The first part will show the
architecture of the UME, its integration into the
system landscape and how these demands are
37
Web
Browser
Web
Browser
Cache
Servlet /
JSP
Local
Data
Local
Data
Other Data
Authorization
Authentication &
Servlet /
JSP
User
Management
Engine
Bean Container
Cached
SAP ABAP
System
EJB
EJB
Local
Data
Local
Data
Other Data
Authentication
Storage Of ABAP System
Cached
Web Container
Data
Data
Cache
For User
SAP
Frontend
For User
Cache
J2EE Engine
Storage For User Data
LDAP Directory
User Database
Sap System Database
Figure 1 Compositional structure of the system landscape of a common J2EE engine with integrated UME
detail the user management core processes each

method call of the API.
The UME completely encapsulates the J2EE

engine from all user directories. The UME
accesses all user directories using adapters as if
they where one large database.
2.2.2. Persistence Agent

The persistence agent connects the user
management core to the user directories. Figure 2
shows a system in which user data is stored in
more than one data sources. Each type of data
sources has its own adapter. With UME you can
leverage existing user data repositories in your
system infrastructure by connecting them using
configurable persistence adapters.
By configuring the query dispatcher which
data source to use, the application, which uses the
API, does not need to know where the data is
stored. This means that the data source, which is
accessed by the persistence agent, is transparent
to applications using UME.
The UME management console is a small tool
which uses the UME API and allows the
administrator to perform routine tasks such as
creating roles and assigning users to roles.
2.2. UME Architecture

The internal structure of the UME is illustrated in
Figure 2 (see next page).
The main purposes of the UME are the
centralization of user management and parallel
work with user management data from multiple
data sources. The centralization is realized by an
own API which is available for all applications.
The parallel access of several user directories is
realized by predefined adapters.
2.2.1. User Management Core

The user management core realizes the
centralization by exporting a special API. This
API encapsulates every request for user
management data.
This prevails inconsistencies in several data
sources because every change within the user
management data is processed by the UME, in
38
Web
Container
alternative approaches that can be used.

Authorization is the process by which an
authenticated user is granted access to various
items of data. Authorization allows some users to
read data, whereas others can read, modify or
update data.
The J2EE authorization model is based on the
concept of security roles. Roles will be discussed
in part four.
Bean
Container
User Management Engine

Cached User
Management
Data
User Management Core
Broadcast
Persistence Agent
Query Dispatcher
Adapter For
Database
Adapter For
LDAP
Config Data
Replication
Agent
3.1. Declarative Security

Declarative security refers to the means of
expressing an applications security structure,
including security roles, access control, and
authentication requirements in a form external to
the application.
In this case the access control is linked to the
resource. Hence each resource has a marker on it,
defining which permission a user must have to
access this resource.
The J2EE engine holds a list of methods and
websites that can be accessed by a given security
role.
Marking the resources decouples the access
control from the application logic.
Therefore, it is easy to implement and
maintain the software. But marking the resources
also means, the access to the user data will be
done decentralized by the containers.
Using the declarative approach, it is only
possible to grant either full or no access to the
protected resource because the container has no
opportunity to react instead of sending a
permission error or the requested resource.
Adapter For
ABAP
SOAP
Database
LDAP
ABAP System
User Data
External
System
Figure 2 Compositional structure of the UMEs

internal structure
2.2.3. Replication Agent

UME allows to replicate user data to external
systems. Figure 2 illustrates this. A replication
agent forwards UME data to external systems.
User data that is written to the persistence agent
is also written to the replication agent. The
replication agent generates SOAP sheets and
sends them to the external systems, which process
them and perform corresponding actions.
It is not recommended to use the replication
feature and it should only be used in exceptional
circumstances where no other solution is possible.
UME replication is still available in this release
for existing customers, however it is not planned
to further develop this feature and it will be
phased out in the next releases. [SAPL]
3.1.1. Declarative Authentication

When a user requests a protected resource from
the web application server, the server has to
authenticate the user. J2EE servers use
authentication mechanisms based on validating
credentials, such as user ID and password pairs.
Credentials are verified against a user registry
that supports the requested authentication
scheme.
For example, authentication based on user ID
and password can be performed against an LDAP
user registry, where authentication is performed
using an LDAP bind request.
With this approach the web container is
responsible for authenticate the user. The
authentication is passed to the bean container on
demand.
3. Authentication & Authorization

Approaches
The following section is intended to introduce the
two security approaches specified in the J2EEspecification.
User authentication is the process by which a
user proves her identity to the system. This
authenticated identity is then used to perform
authorization decisions for accessing application
components. The most common form of IT
authentication involves providing a username
and password, but other techniques are
39
authenticate against the UME using the UME API

and not directly against the user directory.
The
component
explicitly
triggers
authentication with a certain method call
(context.getCallerPrincipal().getName()). This
call returns the user name as a string or causes the
web container to send a login form. With the call
getUserByUniqueName(username) the UME returns
a user object to the application. The authorization
checks can be performed using this object.
The web container triggers the authentication

whenever the user wants to access a protected
resource.
3.1.2. Declarative Authorization

The declarative authorization is done by both
containers to check whether the user has the
necessary permissions to access the resource or
not.
If the user who calls is in one of the security
roles that are allowed to access a method, the user
is allowed to execute the method. Conversely, if
the calling user is in none of the roles, the caller is
not allowed to execute the method. Access to web
resources can be protected in a similar manner.
3.2.2. Programmatic Authorization

The next step is to make sure that the
corresponding permissions are checked when the
resource is accessed. For this purpose the two
methods user.checkPermission(actionToPerform)
and user.hasPermission(actionToPerform) are
available.
During the processing of this method call the
UMEs query dispatcher sends a request to the
right persistence adapter which accesses the user
directory and returns information about the user.
The user management core determines waether
the user either has the appropriate permission or
not.
The method checkPermissions() has no return
value and throws an UMexception if the caller
has not the corresponding permission.
The method hasPermission() returns a result
of type boolean. This method allows the
developers to branch into their applications.
3.2. Programmatic Security

When declarative security is insufficient, it may
be necessary to retrieve security-sensitive
information programmatically.
With this approach the responsibility for the
authentication and authorization of users is with
the application itself. The application developer
has to write security issues related to the specific
application, running as part of the application.
Therefore the programmatic security offers
more flexibility and allows more complex rules in
the user management system.
However, such a practice makes the
application less portable and less maintainable.
And assembling an application from several
components that use programmatic security will
be difficult or impossible if the programmed
security model is not consistent between these
components.
The
regular
J2EE
engine
provides
programmatic security as well as the UME but the
UME extends some of the concepts. Hence, in all
following parts the use of the UME is assumed.
The two following sections explains how to
retrieve the user's identity and privilege
information programatically.
3.3. Declarative vs Programmatic

Approach
There is a trade-off between the external access
control policy configured by the deployer
(declarative security) and the internal policy
embedded in the application by the component
provider (programmatic security). The former has
the major benefit of being more flexible in
maintenance after the application has been
written. Changes to a security policy can be made
without having to change the underlying Java or
JSP code. Furthermore, several components from
different sources can be integrated to build a
complete application. Afterwards security can be
applied to the application as a whole rather than
the individual components. Declarative security
is
also
transparent
and
completely
comprehensible.
The latter provides more flexibility, in the
form of functionality, while the application is
3.2.1. Programmatic Authentication

The word programmatic in this context means
implemented from scratch, which is a good choice
for authentication if total control is needed.
Because it is more work than relying on your web
container, programmatic authentication can be a
bad choice if those benefits are not interesting.
Components running on the J2EE Engine
40
written. It is useful when declarative security

alone is not sufficient to express the security
model of the application. But the security model
is buried in the application such that it may only
be completely understood by those who
developed the application.
The mapping of users onto roles (see section 4)
is, in both approaches, entirely under the control
of the system administrator.
In summary, declarative security is capable to
protect static information or applications that are
explicitly distinguishable from another. [SAPL]
When declarative security is not sufficient to
capture the business logic requirements,
programmatic security can be used for a more
fine-grained approach.
Programmatic
security
provides
more
flexibility and more complex rules [SAPL] for the
security model.
access control. The concept is based on the

assignment of permissions by activity of the
person, but not by cases. This means that all users
to which a certain role is assigned can use the
entire component. For example, a user who has
the role Financial Accountant can access the
entire booking component. Thus she can post for
all cost centers.
The activity-relation is caused by the fact that
the developer decides during the development
how many and which role references shall be
delivered to the administrator. The developer
tries to think about which kind of people will use
the application and designs according this
considerations the role references.
A role reference is the name of a role used
within the code of a J2EE application. As part of
the J2EE application environment definition,
every role reference must be mapped onto a real
role. The decoupling of the coded role reference
from the actual role should help improving
portability of a J2EE component. [MB]
The developers can use role references that
correspond to individual authorizations of their
applications. In a second step, the developer
assigns at least one security role to each role
reference. These J2EE security roles are delivered.
The administrator then assigns the security roles
to users or user groups.
The major disadvantage connected to this
concept is that the mapping between the role
references and the existing roles must not fit. In
case mapping does not fit, the administrator has
to give some users more permissions as
necessary.
4. Roles
A security role is a logical grouping of users
that is defined by an application component
provider/developer. It is then mapped by an
administrator to security identities (e.g., users,
groups, etc.) in the operational environment.
A security role can be used either with
declarative or programmatic security. [SPEC]
The role concept aims to abstract from the
permissions and provide a pattern for sets of
permissions for several user groups.
During the design of a component the
developer should always think about the kind of
users who will employ the component. These
users are grouped into roles. (see J2EE roles)
The set of permissions of these roles should
reflect the responsibilities of the persons within
an organization. Any person within an enterprise
can usually be categorized into security roles.
These roles are to be assigned to only as much
permissions, as the users need to perform their
tasks. In ideal case they have exactly the set of
permissions they need, not too little nor too
much. The finished roles can be mapped to users
or user groups.
In the following part only the use of the
programmatic approach is assumed.
4.1. J2EE Roles

J2EE roles are suitable for static, activity-related
41
illustrated in figure 3.
User
4.3. J2EE Roles vs UME Roles

J2EE roles as well as UME roles allows abstract
and logical grouping of user permissions.
Due to role references J2EE roles define a
given interface for roles. The mapping from role
references to roles can become difficult because
existing roles does not have to be consistent with
the set of offered role references.
The introduction of actions (as a set of
permissions) into UME roles aims to make the
UME roles independent from predefined role
references to afford a more flexible and precise
role mapping.
From these bases and because the
implementation effort of J2EE roles and UME
roles equals, UME roles are the better choice in
programmatic security.
A mixture of both role implementations is
technical possible but not advisable.
is assigned to
Role
Superrole
Subrole
consists of
This entity and

these mappings
are defined during
administration
consists of
An action is a
collection of
permissions
Action
consists of
These entities and

this mapping are
defined during
development
Permission
Figure 3 Value range structure of a UME role
4.2. UME Roles
5. Control Flow Of A Common

Authorization Request
Authorization is granted in UME by using

permissions, actions and roles.
An action is a set of permissions. Each
component defines a list of actions. This list
which represents which kinds of operation can be
carried out within this component. This list of
actions is exported to the administrator who
assigns actions to roles. The roles can be assigned
to a user. A direct mapping between actions and
users is not possible. So within the UME role
concept there is no need for role references. Thus
the developers has not to imagine what types of
users could access their application. They simply
deliver all possible operations to the
administrator.
One benefit of this concept of UME roles is
that the developers are able to export all
operations they implemented in their application.
With the 3-leveled-role concept, a developer can
define a fine granular security model while
hiding the complexity from the administrator.
UME Roles are provided by the user
management engine and only supported if
programmatic security is used. Furthermore the
API of the UME allows the developer to branch to
the users permissions.
The UME role concept is structured as
This dynamic structure depicts a common

permission check which is performed by the
UME. (see next page)
42
Web
Browser
Web
Container
Enterprise
Java
Bean
been achieved by exporting an own API and

using predefined user directory adapters.
The paper has compared declarative with
programmatic security and remarks that
declarative security is sufficient for small and
static user management systems with explicitly
distinguishable resources in it. The programmatic
approach should be used if the security model
requires more complex rules and fine grained
structures.
The UME roles have been introduced as an
extension of common J2EE roles. UME roles
increase the flexibility of security models and the
precision of role mapping by introducing actions.
User
Management
Engine
Request For
A Resource
Generate Website
Start Operation
Invoke Method
Calculate First
Part Of The Result
Trigger
Authentication
References
User
User
Unknown Authenticated
Send Login
Form
Pass
Information
To UME
[SAPL] SAP Library

Users Types In
Their Credentials
[SPEC] Java 2 Platform Enterprise Edition Specification,

v1.4
Caching And Passing

Information To UME
[MB] Martin Bond, Security

http://www.samspublishing.com/articles/article.asp?
p=28496&rl=1
Trigger
Authorization
Perform Authorization
Check Against User
Directory
Return Result
Access Granted Access Denied

End
Calculation
Throw
Exception
Return
Result
Send Page
With Result
Send Error
Page
Display
Display
Result Page Error Page
6. Conclusion
This paper has explained basic concepts of user
management and the UME architecture. The
UME internals and its integration in the overall
structure have been considered. The two major
goals, centralization of the user management and
parallel access to existing user directories, has
43
44
Profiling, Monitoring and Tracing in SAP Web

Application Server
Johannes Passing

Logging is the most common technique used

for reporting the state of a running system.
Programs or whole systems report normal and
especially exceptional events to a sequentially
organized persistent storage often a flat file.
The log can both act as history as often
applied in case of Web servers and, if checked
regularly, as a source for determining
misconfiguration of the system. As such, logging
is mainly considered a technique for problem
detection. Though the verbosity of logging can be
adjusted, logging is rarely turned off logs are
written by staging systems as well as production
systems.
In contrast to logging, which is mainly
targeted at system administrators, tracing is a
means for developers to track down
misbehaviour of running systems thus being a
technique for problem analysis. Rather than just
reporting the occurrence of certain events, traces
serve to reveal the program flow of a certain
component by reporting each action performed.
In the case of multi-threaded systems, these
records have to contain information about the
caller-thread. Based on this information, the
developer may examine the actions performed by
each thread separately.
If tracing records contain timing information
such as the time spent by a specific action, traces
may also serve for performance analysis. In this
case, however, the distinction between tracing
and profiling is blurred.
Since tracing may generate immense amounts
of data, it is mostly performed on an application
or component basis rather that on a system basis.
Further more, tracing can pose significant
additional load on the system. To avoid this
overhead, tracing is in contrast to logging
switched off during normal operation and is only
activated on demand.
Abstract
After shortly describing and distinguishing the

commonly used terms Monitoring, Tracing, Logging
and Profiling, the paper will describe their role in large
SAP installations.
Finally, some of the monitoring and tracing
features provided by the SAP Web Application
Server (Web AS) for Java will be presented.
Alert Monitor, CCMS, DSR, GRMG,

JARM, JMX
Keywords:
1. Introduction
The ability of a software system to both offer

insight into the state of the system and to allow
administrators as well as developers to easily spot
and solve problems is an important aspect of a
supportable system (see [JPW]).
Features and tools offered for this purpose
may be classified into two categories problem
detection and problem analysis. Whereas the
former includes techniques to identify or even
anticipate problems, the latter deals with finding
the reasons behind the problems identified (see
[SDN0], [SDN1]).
2. Profiling, Monitoring and
Tracing
This section will describe the concepts of tracing,

logging, profiling and monitoring and will show
the differences between these concepts.
2.1. Tracing versus Logging
Though logging and tracing are similar in

implementation, they are used for different
purposes (see [SDN2]).
45
3. Monitoring infrastructure in
SAP installations
2.2. Profiling
Profiling deals with analyzing the performance of

certain components or complete systems. During
development, profiling is used to identify
portions of code that consume the most time. As a
common rule of thumb, 80 percent of the
execution time of a program is spent in 20% of its
code.
To identify these parts, most profiling tools
observe a program by measuring both the time
consumed by a procedure and the number of
times the procedure has been called. Using this
technique, hot procedures may be easily
identified. Identifying these bottlenecks may
well reveal weaknesses of the program such as
poorly performing algorithms or bad locking
strategies.
In production mode, profiling may be used to
determine the overall performance of a system
this includes measuring response times of certain
components or web pages as well as database
queries. This information can be especially useful
if gathered regularly to compare the results over
certain time intervals or to contrast response time
during high-load hours and low-load hours.
A system landscape especially in the SAP

environment seldom consists of only a single
server (see [SDN3]). However, maintaining and
monitoring multiple servers, including clusters,
different operating systems and different software
puts greater demands on a monitoring system.
3.1. Computing Center Management
System (CCMS)
The SAP Computing Center Management System

(CCMS) accomplishes the task of monitoring large
installations by providing an infrastructure that
allows monitoring of both different SAP systems
as well as external systems such as a database
server.
The components of a CCMS system may be
split in three roles (see [SAPL], [SDN3])
2.3. Monitoring
The intention of monitoring is mainly to identify

the health of a running system. To accomplish
that, data is to be retrieved from different sources.
This may include analyzing log files for the
frequency of severe errors or using data provided
by performance counters. Further more,
applications may be instrumented to provide
monitoring data themselves.
Though the exact usage of the term differs,
monitoring is not a replacement for logging and
tracing, but rather embraces these techniques.
As such, it is greatly supported by tools used
to aggregate and analyze the data provided as
well as presenting the user an overview of the
overall state of the monitored system. Moreover,
these tools often include the ability to generate
reports and statistics.
Depending on the information contained,
these reports may not only be targeted at system
administrators, but may also serve as a valuable
resource for management.
46
Data suppliers
The system to be monitored is considered a

data supplier (shown at the bottom of fig. 1)
during its normal operation, the system collects
different sorts of monitoring data which may
be used by Data Consumers. The data is made
accessible by being stored in a machine-wide
known shared memory segment used by all
Data suppliers on the same machine.
Data consumers
Data consumers (shown in the middle of fig. 1)
gather monitoring data provided by data
suppliers for the purpose of analysis this data
is either obtained by reading from the local
monitoring shared memory segment or from
CCMS agents. One of the most commonly used
data consumer is the Alert Monitor.
CCMS agents
Whereas the monitoring data provided by
suppliers is only accessible on the local
machine, CCMS agents (not shown in fig. 1),
which are independent processes running on
the monitored systems, provide access to this
data to remote machines. The usage of CCMS
agents allows running suppliers and
consumers on different machines and thus
makes central monitoring of distributed
systems feasible.
AdHoc monitoring data

analyst
Long-term monitoring
data analyst
BW/Reporting
< monitoring
data
transfer
Central Monitoring System (ABAP)

Extractor
Data consumers
Alert Monitor
CPH
Cache
Push/Pull of monitoring
data
Via CCMS
Java System
External System
ABAP System
Data suppliers
Figure 1: CCMS architecture (own illustration)
allow even more thorough analysis, Extractors

allow CPH data to be transferred to the Business
Warehouse.
Just as the Alert Monitor, the CPH is located
on the CEN.
3.2. CCMS Data Consumers
In order to centralize monitoring facilities and not

to put additional load on production machines,
one ABAP-based system may be declared as the
Central Monitoring System (CEN) (see [SAPL],
[SDN1], [SDN3]). The CEN is dedicated to only
contain monitoring-related components which
mainly act as data consumers.
Essential part of a CEN and the most
commonly used data consumer is the Alert
Monitor.
Besides accessing the local shared memory
segment, the Alert Monitor queries CCMS agents
running on remote machines via Remote Function
Calls (RFC) for monitoring data. In recent releases,
CCMS agents may also push their data collected
to the CEN in certain time intervals. To improve
performance, all data obtained is held in a local
cache on the CEN. Though data may be held in
the cache for up to 24 hours, the Alert Monitors
responsibility is only to provide an ad-hoc view of
the system.
In order to store monitoring data to build up a
history, the Central Performance History (CPH) may
be used. The CPH is a database that stores
monitoring records over longer periods of time.
Based on this data, reorganization and
aggregation may be performed, as well as
creating reports showing the evolution of data. To
3.2.1. Alert Monitor
Whereas the actually monitored entities as well as

the data they provide may differ, the CCMS
provides a common model to which data is
mapped (see [SAPL]).
A monitored system is considered to consist of
several monitored entities referred to as
. While a monitoring object
identifies such an entity, it does not provide any
data instead it acts as container for at least one
. Each attribute is named and
yields the value for one specific trait of the object.
A common example for a monitoring object is
a Central Processing Unit (CPU) of a server
containing an attribute describing the current
load.
A CCMS
a is tree-structured set of
. While monitoring
objects and monitoring attributes constitute the
two bottom-most layers of this tree, virtual nodes
may be created to further structure the tree. A
special kind of virtual nodes are the summary
monitoring tree entries these aggregate
information provided by their child nodes.
monitoring
objects
monitoring attribute
monitor
monitoring tree entries (MTE)
47
3.3.1. Monitoring an ABAP 3.x or 4.x system

with SAPCM3X or SAPCCM4X
To each attribute, threshold-values may be

assigned. The graphical user interface (GUI) of the
Alert Manager will show attributes in different
colors, depending on whether its value has
exceeded its threshold or not. In case of a critical
value, the attribute as well as all its parent nodes
will be highlighted in red color. The user of the
graphical user interface will thus immediately
notice the existence of the critical value and can
easily locate the corresponding attribute by
navigating down the tree along the highlighted
nodes.
Further more, methods may be assigned to
monitoring tree entries, which will be triggered if
certain alerts such as the exceed of a certain
threshold occur.
In conjunction with SAP Central Alert
Management (ALM) framework, the administrator
may be automatically notified of the occurrence of
such events in a variety of ways this includes
sending e-mails, fax or SMS messages (see
[SDN3]).
As these systems are implemented to use the

CCMS architecture, monitoring data is directly
written to the shared memory segment (see fig. 2).
Thus, the main responsibility of the CCMS Agent
is providing access to this data for remote
consumers.
From CEN via
native ABAP
interface
From CEN via

RFC
CCM4X shared memory
segment
SAPCCM4X
ABAP System
Server
Figure 2: Monitoring an ABAP system

using SAPCM3X/SAPCCM4X
(own illustration)
3.3. CCMS Agents

Monitoring data provided by data suppliers is
as mentioned above stored in a shared memory
segment which is well known on the local
machine.
However, this technique has two implications:
Though not discussed in greater detail, these

systems offer the ability to provide access to
monitoring data via a native ABAP interface as
well. However, to improve robustness and
performance, using CCMS agents to accomplish
this is now considered the preferred way.
Data may only be accessed by consumers
executing on the same machine

Programs have to be implemented to make use
of the shared memory segment this implies
that by default, third-party programs cannot be
monitored this way.
3.3.2. Monitoring an external system using

SAPCCMSR
An external system to be monitored may be a
database server. However, these systems cannot
make use of the services provided by CCMS.
Thus, these systems report their state in their
usual way for example, by writing log files (see
fig. 3). The SAPCCMSR agent provides the ability
to analyze these log files and write the results to
the local shared memory segment. Another option
is to set up the agent to receive Simple Network
Management Protocol (SNMP) traps issued by the
system to be monitored.
Just as the SAPCM3X and SAPCCM4X agents,
this data is then made accessible via an RFC
interface.
Consequently, SAPCCMSR agents solve the
second issue raised above and facilitate the
transparent integration of external systems in the
CCMS monitoring architecture.
CCMS agents address both these issues. The

agent is an independent process executing on the
same machine as the system to be monitored. It
attaches itself to or creates in the lack of
existence the local shared memory segment (see
[SAPL], [SDN3]).
By acting as a RFC server, consumers such as
the Alert Monitor may actively request data this
scenario is referred to as pulling monitoring
data.
By acting as a RFC client, recent releases may
push data by periodically sending data again,
the Alert Monitor uses this technique.
Depending on its usage, three different agents
may be used namely SAPCM3X, SAPCCM4X
and SAPCCMSR.
48
4.1.
To CEN
4.1.1. Java Management Extensions
J2EE engines, of which one or more may coexist

on a single machine, use the JMX infrastructure
to provide standardized interfaces both for
administration and monitoring (see [JPW], [MW],
[SAPL]).
In a nutshell, JMX provides a central authority
(the MBeanServer), which MBeans may be
registered to (see fig. 4). An MBean wraps a
specific resource to be managed. It consists of a
Java class implementing one of a set of JMX
interfaces and, through the attributes and
methods defined herein, allows querying the state
as well as adjusting settings of this resource. The
MBeanServer in turn allows clients to indirectly
interact with these resources by acting as a broker
delegating requests to the corresponding MBeans.
Further details on JMX may be obtained in [JMX].
While administrative usage both reads and
writes attributes of MBeans as well as invokes its
methods, monitoring is mainly based on querying
data exposed via attributes.
As a result of being based on JMX, tools may
access and manage MBeans by directly
connecting to the MBeanServer. For remote
access, adapters such as the SAP RMI/P4 adapter
may be used.
In the case of a solely J2EE-based landscape,
exclusively using these tools may be an attractive
and lightweight alternative to using CCMS.
Further more, being a widely adopted
industry standard, JMX greatly lowers the burden
for third-party component developers to make
use of the monitoring infrastructure.
Though JMX offers the ability of monitoring a
J2EE system such as SAP Web AS without the
need for a CCMS infrastructure, there are still
strong reasons for integrating JMX technology
with the CCMS the most obvious and
compelling reason being the need to integrate
J2EE systems with an existing, non-J2EE SAP
system landscape.
CCMSR shared memory

segment
SAPCCMSR
Collectors, e.g. SAPOSCOL

External monitored
system
Logs etc
Server
Figure 3: Monitoring an external system

using SAPCCMSR (own illustration)
Beside the features provided by the agent

itself, further collectors may be used a collector is
another independent process collecting
monitoring data and writing the results to the
memory segment. The most commonly used
collector is the SAP Operating System Collector
(SAPOSCOL), which gathers data from the
underlying operating system (shown at the right
of fig. 3).
4. Web AS Java
Being a J2EE Application Server, Web AS Java not

only offers features known from ABAP systems,
but also introduces standardized technologies like
Java Management Extensions (JMX) to the SAP
monitoring infrastructure.
This section will present some of these
technologies and will show how they integrate
with the CCMS architecture.
To SAPCCMSR shared
memory segment
CCMS
Connector
GRMG
Infrastructure
DSR
Service
Logging
To
Visual
Administrator
Mon.
data
Monitor Service
J2EE Engine
Monitoring a Web AS Java system
4.1.2. CCMS integration using SAPCCMSR
MBean
Besides offering the ability to monitor an external

system, the SAPCCMSR agent provides a
switch, activating further features specific to
monitoring a J2EE system.
One of these features is the integration of the
JMX-based monitoring infrastructure used by
JMX MBean Server
j2ee
Server
Figure 4: Usage of JMX within the J2EE engine

(own illustration)
49
CEN
R
CCMSR shared memory

segment
SAPCCMSR -j2ee
R
CCMS
Connector
Collectors, e.g. SAPOSCOL

GRMG
Infrastructure
Avail.
data
DSR
Service
DSRs
Logging
Logs
Visual
Administrator
Mon..
data
Server
Monitor Service
(JMX)
J2EE Engine
Figure 5: Monitoring a Web AS Java system using SAPCCMSR j2ee (own illustration)
J2EE systems with the mentioned CCMS-based

infrastructure.
Though the implementations of these two
concepts differ, both share the concept of
monitors providing data through attributes.
Using the CCMS Connector (see fig. 5),
monitoring data obtained from the JMX
infrastructure is transformed and transferred to
the CCMS shared memory segment being
available in this segment, different machines and
tools may access this data using the features of
CCMS agents already discussed.
4.2.2. Distributed Statistics Records
On ABAP systems, a concept called

is used to record information about the
workload generated and the resources used by
specific actions (see [SAPL], [SDN2], [SDN3]).
Based on this, information about the overall state
of a system may be derived. Further more, the
root causes of problems such as performance
bottlenecks may be determined by analyzing
these records.
are an
enhancement of Statistics Records that may be
used on both ABAP and J2EE systems.
To make use of DSR in case of a system
spanning multiple machines, correlating records
collected on different machines must be
identifiable to be grouped together in case of a
, in which components
on different machines are involved, all records
created on the affected machines must be
combined to determine the workload generated
by the LUW as a whole.
To facilitate this, a
is sent along all
communications such as RFC calls. Along further
information such as the user ID of the user
triggering the LUW, the passport contains a
, which uniquely
identifies the LUW. Based on these passports,
correlating records generated on different
Statistics
Records
Distributed
4.2. Problem detection in Web AS Java

4.2.1. Logging
During normal operation, the Web AS server

writes logs. On the one hand, these logs originate
from several components of the server itself, on
the other hand, developers may use the SAP
Logging API to include logging features in their
applications (see [JPW], [SAPL]).
By setting the verbosity level, the
administrator may adjust the granularity and
amount of information written.
These logs may be either viewed using the Log
Viewer or if CCMS is used may be analyzed by
the SAPCCMSR agent.
Statistics
Records
Logical Unit of Work (LUW)
passport
Globally Unique Identifier (GUID)
50
(DSR)
machines may be identified.

Besides the
, which
corresponds to the passport, a Distributed
Statistics Record contains a
as well as
any number of
. Whereas the Main
Record contains the actual statistical information
about actions performed, Call Subrecords contain
information about other components called.
The
, which generates the DSR,
stores all records in files, which in turn can be
read by the SAPCCMSR agent to be made
available to the CEN.
Using the
, the data
collected by all machines may be aggregated and
analyzed on the CEN.
Certificate
measurement process (see fig. 6). As the

communication is based on HTTP, these
applications may be hosted on the same machine
as well as on different machines. The results
received are aggregated and may be made
available to the Alert Monitor.
If performed periodically, data obtained by
GRMG applications provide a good overview
about both the availability and the responsiveness
of the system during different levels of load.
Subrecord
Main Record
Call Subrecords
DSR
Service
Global
Workload
4.3. Problem Analysis in Web AS Java
Monitor
4.3.1. Tracing
Though plenty of techniques exist for finding and

eliminating failures in software during
development, it is hardly inevitable to find
failures in an application when it has already
been deployed to a production machine.
As the Java Virtual Machine does not support
the attachment of a debugger unless it is launched
in debug mode, using a debugger for
troubleshooting applications deployed on a
productive Web AS server on the fly is not
possible.
To compensate for this shortcoming, Web AS
offers various tracing techniques. Providing
thorough information about the execution of a
component, these techniques aim at providing the
developer enough information to spot the failure
and thus eliminating the need to restart the
machine in debug mode. Further more, tracing is
extensively used for performance measurement.
4.2.3. Generic Request and Message

Generator
Another important aspect of maintaining a

production system is to guarantee availability. As
a web server, Web AS has to face the challenge of
handling significant amounts of concurrent
requests during peek hours this not only implies
that the server as a whole must be able to serve all
these requests, but also that every single
component used by any of these requests must be
able to respond within the allotted time.
Though most requests may be handled with
only short delay, it is possible to have certain
components not responding in such a situation
due to problems like lock contention.
To identify these components and problems,
the
may be used (see [SAPL], [SDN1]).
The idea behind GRMG is to create a
(shown at the top right of fig. 6),
mostly implemented as a JSP page or Servlet, that
may run different
that is, the
component determines the availability of a single
or a small number of components.
GRMG applications are called via HTTP, using
an XML-based format for both request and
response. Whereas the request contains the name
and additional information about which of the
scenarios implemented to run, the response
contains a result code along with further
messages generated during the measurement
process. To simplify handling the XML formats,
SAP provides an API for reading and encoding
GRMG messages.
The
(shown at the left of
fig. 6), which may also be located on the CEN,
calls these applications and thus invokes their
Generic Message and Request Generator (GRMG)
4.3.2. SQL Tracing
GRMG
The
acts as an abstraction layer
above the actual database drivers used. As such, it
compensates for the differing implementation and
SQL dialects used among drivers of different
vendors (see [BS], [JPW]).
application
Open SQL Engine
scenarios
To
CCMSR
GRMG
Infrastructure
DSR
Service
GRMG
Request/
Response
Logging
(HTTP/XML)
Monitor Service
(JMX)
J2EE Engine
Server
GRMG Application
(e.g. Servlet)
R
Run scenario
Monitored entity
(e.g. EJB,
HTTP Service
etc)
J2EE/ABAP
Server
Figure 6: Monitoring availability using GRMG

(own illustration)
GRMG infrastructure
51
As all SQL queries pass through the Open SQL

Engine, detailed statistics about the frequency and
the load generated by queries may be gathered.
This information is made available through a
separate web-based user interface.
Complex and inefficient SQL queries may
consume a significant amount of time and can
thus slow down the overall performance of an
application analyzing the information provided
may therefore be of great use when spotting
performance bottlenecks.
Just as other tracing techniques, SQL tracing
may be enabled or disabled at any time.
involved has been instrumented using JARM, the

component consuming most execution time and
thus causing weak performance may be located.
Using techniques like Application Tracing or
debugging, this part of code may then be further
analyzed.
4.3.5. Application Trace
Using the Application Trace, a developer may

observe a component at the level of method calls
(see [JPW], [SAPL]). However, the component
itself does not have to be manually instrumented
for tracing purposes as in the case of JARM
instead, the required code is injected
automatically by the J2EE engine on demand.
To enable tracing, the server unloads the
selected component and searches for the
corresponding byte code. A copy of the byte code
is then instrumented by being added tracing
statements to each method contained. After the
byte code enhancement has been performed, the
application is started again.
While performing its normal task again, the
application now writes tracing records. Beside the
names of a method being called, these records
also contain the time spent within the method.
When the desired information has been
gathered, tracing can be disabled again the
server will then reload the application using the
original code.
Based on the information collected, tools like
Visual Administrator may reconstruct the flow of
execution of the component the developer is
now able to browse the tree of nested method
invocations that were performed on each single
thread.
In combination with a byte code decompiler,
this may well serve as an alternative for an
interactive debugger in the case of troubleshooting a production system.
Besides giving thorough insight into a
component, the Application Trace is also a
valuable means for locating performance
bottlenecks. By revealing the number of times a
method has been called as well as its time
consumption, the Application Trace greatly
simplifies pinpointing those methods that are
called extremely frequently as well as poorlyperforming methods.
4.3.3. Java Application Response Time

Measurement
Components may be manually instrumented for

performance-tracing by using Java Application
Response Time Measurement (JARM) (see [SAPL],
[SDN1]). The concept of this API is to have the
component first acquire a named monitor and to
enclose each processing part of a request or
method invocation by calls to IMonitor.
startComponent()
and
IMonitor.
endComponent(). Calls to these methods may
also be nested if, for example, further methods are
involved.
As the time elapsed between each two
corresponding calls is recorded, an application
instrumented with JARM provides detailed
information about how much execution time has
been spent in which part of the component.
Using tools like the Visual Administrator, this
information may be aggregated and analyzed
this includes calculating the average time
consumed by a request or displaying those
requests having consumed most execution time.
4.3.4. Single Activity Trace
If components have been instrumented with

JARM, the Single Activity Trace (SAT) can be used
for cross-component tracing (see [JMI], [JPW],
[SAPL]). Similar to the concept of DSR, SAT
allows the inspection of a specific request
involving several components by analyzing the
information provided by JARM.
Using SAT is thus especially useful if a certain
workflow such as a specific HTTP-Request has
shown to be especially expensive.
In this case, the administrator may choose to
enable SAT for this request to have all JARM data
collected. Assumed that each component
52
[SDN2] Scott Braker, Tips and Tricks to fully leverage

SAP Web AS for Java developers (Presentation),
SAP Developer Network,
http://www.sdn.sap.com/irj/servlet/prt/portal/p
rtroot/com.sap.km.cm.docs/library/uuid/c59736a
7-0301-0010-c3bf-9f9f07bc6bc9, 2005 (retrieved
19.06.2005).
[SDN2] Christoph Nake, Session ID: LCM202 System
Management for SAP Solutions (Presentation), SAP
Developer Network,
https://www.sdn.sap.com/irj/servlet/prt/portal/
prtroot/com.sap.km.cm.docs/documents/a1-84/System%20Management%20for%20SAP%20Solut
ions.pdf, 2005 (retrieved 30.06.2005).
5. Summary
Through its numerous logging, tracing and

monitoring features, the SAP Web Application
Server offers a variety of techniques supporting
both administrators and developers in developing
and maintaining a stable and responsive system.
Monitoring, tracing and profiling techniques
offered by Web AS as well as those techniques
provided by other SAP and external systems may
be integrated using the proven CCMS
architecture, which may greatly simplify the
maintenance of large, distributed and
heterogeneous installations.
References
[BS] Bernd Schufele, J2EE persistence mechanisms of

the Java Web AS, HPI Seminar System Modelling
2005, Hasso-Plattner-Institute for Software Systems
Engineering, 2005.
[JMI] Astrid Tschense, Java-Monitoring Infrastruktur
im SAP NetWeaver 04 (Chapter 3), SAP Press, 2005.
[JMX] JavaTM Management Extensions Specification
http://www.jcp.org/en/jsr/detail?id=3, 2005
(retrieved 20.05.2005).
[JPW] Karl Kessler, Peter Tillert, Panayot Dobrikov,
Java Programmierung mit dem SAP Web
Application Server (Chapter 12), SAP Press, 2005.
[MW] Martin Wolf, Administration of the SAP Web
Application Server, HPI Seminar System Modelling
2005, Hasso-Plattner-Institute for Software Systems
Engineering, 2005.
[SAPL] SAP Library, http://help.sap.com/, 2005
(retrieved 11.05.2005).
[SDN0] Astrid Tschense, LCM204: Toubleshooting for
SAP Web AS Java (Presentation), SAP Developer
Network, https://www.sdn.sap.com/
irj/servlet/prt/portal/prtroot/com.sap.km.cm.doc
s/library/webas/STU/Troubleshooting%20for%20
SAP%20Web%20AS%20Java.pdf, 2005 (retrieved
18.05.2005).
[SDN1] Julia Levedag, Monitoring in Web AS 6.40
(Presentation), SAP Developer Network,
https://www.sdn.sap.com/irj/servlet/prt/portal/
prtroot/com.sap.km.cm.docs/documents/a1-84/Systems%20and%20Application%20Monitoring%
20WebAS%20640%20Java.pdf, 2005 (retrieved
18.05.2005).
53
54
The Eclipse Platform

A Snapshot on Version 3
Matthias Kunze
matthias.kunze@student.hpi.uni-potsdam.de
Abstract
or designing models with languages such as

UML. It supports the development, management
and deployment of any imaginable software
product.
In favour of that it is built on top of several
components realizing basic concepts, data models
and services. The following paper opens with
fundamental concepts of the Eclipse Platform and
its integration in the Software Development Kit.
The Platforms architecture will be outlined and
discussed in detail. Finally the underlying data
model the Workspace Resource Model will be
explained.
Starting from a small IBM project, the Eclipse

Platform has become a Platform for anything and
nothing in particular first released as an open-source
software in 2001 by the Eclipse Foundation.
Based on the architectural concept of plug-ins, the
Platform provides mechanisms for integrating
discretionary tools which support application
development.
These
tools,
called
Integrated
Development Environments, are activated dynamically
by the Platform Runtime implemented with the OSGi
framework. Dynamic plug-in activation - policy of
laziness - affords the integration of a multitude of
plug-ins without huge memory overhead and drawnout start-ups.
The underlying data model of the Platform IDE
framework consists of the workspace containing actual
manipulated projects, the user working directory
storing all project-data on a local hard disk and the
Resource Manager, managing every access to
workspace and working directory.
This paper aims to illustrate the functionality of the
Eclipse Platform describing its fundamental
architectural concepts and design models based on
FMC and UML diagrams. It is neither an operating
instruction nor an implementation reference.
2. Overview
2.1. Who is Eclipse?
Primarily the Eclipse Platform was designed by
OTI 1 a subsidiary of IBM in April 1999. OTI
invested more than 40 Million Dollars in the
development of the Platform.
In June 2001 Eclipse 0.9 was shipped, version
1.0 followed in October of the same year. Only
one month later IBM donated the Eclipse source
base and established the Eclipse Foundation. The
website www.eclipse.org was launched, which is
the official homepage of the Eclipse Foundation.
From then on, the Foundation was directed and
managed by the Eclipse Consortium.
All following versions of Eclipse have been
released as open-source software. Version 2.0 was
published in June 2002. Current version (at date
of writing) is 3.0.
In February 2004 the Foundation formed into a
completely
independent,
not-for-profit
corporation [ECLIPSE1]. With this change a fulltime management organization was established,
called Board of Stewards. The Eclipse Foundation
Keywords: Eclipse Platform, Architecture, IDE,

RCP, Workspace, Pattern
1. Introduction
Nearly every programmer or software-designer
knows the Eclipse Platform. Most of them use it
for developing Java applications, because it is the
state-of-the-art Java Development Environment,
runs on any operating system and because it is for
free.
But the Eclipse Platform provides much more.
It can not only be used for developing
applications with every programming-language
1 Object Technology International: founded in 1988, aquired by

IBM in 1996, full part of IBM Ottawa Softwarelab since 2003
55
2.2.1. Design Goals
has over 50 members now. These leading vendors

of the IT- industry delegate representatives to the
Board.
The Board of Stewards is divided into four
classes of membership:
Eclipse should provide an open platform for

application development open to be used in
various ways:
Since the Platform should be accessible to
everyone, it is free of charge. Open
furthermore includes that it runs on as many
operating systems as possible, especially on
Windows and Linux.
Last but not least the Platform is released
under the terms of the CPL. Hence the source
code of the Platform is published for free use,
distribution and reproduction. [CPL]
Eclipse Platform is intended to support tools to
manipulate arbitrary content types.
The seamless integration of these tools is to be
facilitated.
The community of tool developers should be
attracted. To achieve this aim, the choice of
JavaTM as programming-language for nearly all
of the Platforms components is essential,
because of the languages popularity.
Strategic Developers
Strategic Consumers
Add-In Providers and
Open Source Project leaders.
Eclipse Foundation
Eclipse Tool Project
Eclipse Technology
Project
Eclipse Project
PDE Project
JDT Project
As a result of these cognitions the definition of the

Eclipse Platform changes to:
Eclipse is a universal Platform for integrating tools.
The following chapters will mainly focus on
the construction, integration and interconnection
of these tools.
Platform Project
Figure 1: Organization of the Eclipse Foundation
To organize the Eclipse Foundation, it is

divided into top-level projects (figure 1). Each of
them is overseen by a Project Management
Committee, a set of councils that guides the
development of a top-level project as
requirements, planning and architecture.
One of the Open-Source top-level projects is
the Eclipse Project that splits up into three
subprojects:
3. Concepts of Eclipse
The Platform Project is responsible for the

development and release of the Eclipse Platform.
Eclipse Platform's major task is to offer tool

providers mechanisms to use and rules to follow,
that lead to seamlessly-integrated tools. These
mechanisms are exposed via well-defined APIs,
classes and methods.
The Platform also provides useful building
blocks and frameworks that facilitate developing
new tools. These tools are called IDEs 2
Integrated Development Environments and
consist completely of plug-ins. So not only the
IDEs are composed of plug-ins the whole
platform is, as seen later on.
2.2. What is it, the Eclipse Platform?
3.1. Plug-ins
The official answer on this question is:

The Eclipse Platform is an IDE for anything and for
nothing in particular. [ECLIPSE2]
To answer this question in detail, it seems to
be expedient to look at the aspects, which the
designers of the platform considered when
releasing an open-source platform.
Plug-ins is the fundamental concept of the

Platform. They form the basis of the Platforms
and IDEs architecture.
A plug-in is the smallest unit of Eclipse
1. Java Development Toolkit Project

2. Plug-in Development Environment Project
3. Platform Project
2 So the official definition of Eclipse Platform as an IDE (for

anything) is not correct, but it is quoted everywhere.
56
contents. It provides the fundamental lifecycle

of every resource: open, edit, save and close.
The term Editor is not unique to a special data
type. Editors manipulating images, diagrams
and every other resource data can be added to
the Platform. The Platform itself is distributed
with a standard text editor.
Views provide secondary information about the
resources the user is currently working with.
These can be project inspectors, content
outlines, etc.
The lifecycle of the data in Views is simpler
than in Editors: any changes are saved
immediately.
Perspectives are just arrangements of Editors
and Views on the screen. Many different
Perspectives can coexist, but only one can be
shown at a given moment.
Platform function that can be developed and

delivered separately.
Usually simple tools are written as single plugins, whereas complex tools have their
functionality split across several plug-ins building
a feature. Complex IDEs themselves often consist
of a number of features providing documentation
and support to the developer.
A feature in turn is the smallest unit of Eclipse
Platform function that can be downloaded and
installed. To install a new feature, each of its plugins is stored into the /plugins directory in the
installation directory of the Eclipse Platform. To
manage multiple different versions of one plugin, every plug-in (even a newer version of the
same plug-in) is stored in an appropriate
directory. The name of this directory is made up
of the plug-ins name and version, separated by
an underscore, for instance:
org.eclipse.jdt.core_3.0.1.
To become part of the Eclipse Platform and to
enable the collaboration of plug-ins every plug-in
has to be interconnected to at least one other
plug-in. Therefore each plug-in has a Manifest
declaring its interconnections to other plug-ins.
The Manifest is an XML-file inside the installation
directory of the plug-in named plugin.xml.
These interconnections are divided into two
classes:
It is possible to append new Editors, Views and

Perspectives to the Platform by extending
Extension Points of the Workbench with plug-ins.
4. Architecture of the Eclipse

Platform
Eclipse SDK
Dependencies
If one plug-in depends on another one (which is
called the prerequisite) the functionality of the
prerequisite is mandatory for the functionality of
the dependent one. If the prerequisite does not
work properly, the dependent wont do too.
JDT
New PlugIn
Eclipse Platform
PDE
Extension Points
A plug-in can define interfaces where it allows its
functionality to be extended. These interfaces are
called Extension Points. The plug-in offering
Extension Points is called Host- plug-in. If another
plug-in implements one of these interfaces it can
append its own functionality to the Host- plug-in.
It is called the Extender- plug-in.
New PlugIn
hard disk storage
Figure 2: FMC Block Diagram: The Eclipse SDK
The Software Development Kit is the package

which the Eclipse Platform is distributed in
(figure 2). It offers basic functions and all plug-ins
that are required to build new plug-ins. Beside the
Eclipse Platform it contains the JDT and PDE.
3.2. User Interface
The Java Development Toolkit is the native

Eclipse development environment for the Java
programming-language.
The Plug-in Development Environment provides
tools supporting the development of new plugins like definition and documentation of
Extension Points, versioning, deploying and
Plug-ins are the major feature of the Platforms

architecture. The user interface constitutes the
concept of usage.
The Platforms graphical-user-interface- paradigm
is based on three items:
The Editor serves to manipulate resource
57
packaging of plug-ins.
Platform plug-ins
New plug-ins are not part of the SDK. They are

distributed by the Eclipse Tool Project or as thirdparty-tools, open-source or commercial.
As shown in figure 3 the Eclipse Platform is
almost operatingsystem independent. The only
component that is operatingsystem dependent is
the Standard Widget Toolkit which is
implemented with the native window system of
the operating system. The remaining part of the
diagram is self-explanatory showing the different
layers of usage of the Platform.
The Eclipse Platform itself is composed
completely of plug-ins, except of a small kernel
that manages them: the Platform Runtime.
In order to understand the architecture of the
Eclipse Platform, it will be explained by the
means of figure 4 and some selected aspects.
Eclipse Platform
swt
Java VM
OS-windowing
system
Operating
System
Figure 3: FMC Layer Diagram: Platforms usagelayers
Workbench
R
project k
Plug-in
Help
workspace
R
Update Manager
http
install/ uninstall/ update
activated Plug-ins
Resource
Manager
Plug-in Registry
project n
IDE Framework
project 1
Platform Runtime
Eclipse(OSGi)
RCP
project i
.metadata
3rd party
plug-ins
JDT
Debug
Team
PDE
Help
Update
Manager
workspace directory
Figure 4: FMC Block Diagram: Platform Architecture
58
RCP
Eclipse Platform
Core
Plug-ins
UI
Plug-ins
plug-in directory
harddisk
command line user interface.

The Workbench is based on two toolkits,
shown in figure 5:
4.1. Eclipse Rich Client Platform

Since version 3.0 the Eclipse Platform was
completely restructured under the aspect to
provide a Rich Client Platform framework. Thus
Eclipse is not only a platform for integrating IDEs,
it is rather a platform to build any application on
it.
The Rich Client Platform is the minimal set of
plug-ins required to build a platform application
that provides dynamic plug-in services and the
Platform Workbench which represents the user
interface. The minimal set of plug-ins results that
building an application on top of the RCP
framework requires the two major plug-ins and
their prerequisites making the:
The Standard Widget Toolkit is a widget 4 set and

graphics library. To support more performance
and better Look-and-Feel of the accordant
operating system it is implemented with the
native window system. AWT or Swing are not
used. In order to use SWT independently from
an operating system, it has an operating system
independent API.
JFace is a toolkit that provides usual, complex
GUI-components, for example wizards,
preference pages, dialog-boxes etc.
It works with SWT without hiding it and has
an operating system independent API and
implementation.
Runtime (org.eclipse.core.runtime) and

Workbench (org.eclipse.ui).
4.1.1. Runtime
R
The Runtime is the base of the Eclipse Platform;

often it is called the Engine of the Platform
demonstrating its importance. It implements the
fundamental concepts of plug-ins and is built on
top of the OSGi 3 framework.
Starting the engine means starting the
Platform and this is a task of the Runtime. It
contains the bootstrap code and provides more
components that initialize and start the Platform:
The file eclipse.exe (eclipse on Linux) is the
Platform Launcher. It is written in C, starts the java
interpreter, loads the platform code and processes
the return values of the Platform. The Launcher
prints out messages on errors or restarts the
Platform if necessary; for example after installing
new plug-ins. The Java Package startup.jar
contains the main part of the code to start the
Platform.
The Runtime also creates the Plug-in Registry,
this will be discussed later.
It provides more important functions: The
Runtime performs low level job-management,
complex plug-in management and contains utility
classes, for example the core exception handler.
user
request
OS-native Window System
R
R
user
request
OS
dependent
show
workbench
user request
user
request
register
component
user
request
R
R
R
R
user
request
JFace
register
component
Plugin
R
R
R
R
OS
independent
register component
register
component
SWT
UI Manager
Workbench
Figure 5: FMC Block Diagram: Workbench
The channels of the workbench have two different

request- directions: user request and a registercomponent request.
Plug-ins can append own functions to the
Workbench user interface at any time, using the
register-component request. The UI Manager uses
4.1.2. Workbench
The Workbench provides the over-all-structure of
the Eclipse Platform and presents an extensible
user interface. In most cases the graphical user
interface is used, but the Workbench also offers a
4 widget is a contraction of window and gadget: invisible gadget

and display which work together and act as an extension to
computer screens, leaving it free for information [DICT]
Open Services Gateway Initiative: provides dynamic

installation, update and uninstallation of bundles (the plug-ins
of Eclipse) [OSGI]
3
59
The Update Manager installs, uninstalls, updates

and manages the configuration of plug-ins. In
favour of that, it offers a channel to a remote
site via http, where it searches for newer
versions of installed plug-ins. If a later one is
detected, it is downloaded and submitted via
the request channel to the Runtime that stores
the plug-in into the plug-in directory.
JFace and SWT components to fulfil these

requests. The requests of the user to plug-ins
through the user interface are routed back to the
plug-in via the same channels.
4.2. Eclipse IDE Framework

Figure 4 shows the Eclipse IDE Framework
containing three important components:
The Plug-in Registry contains information about
all installed plug-ins. On Platform start-up, the
Runtime reads all plug-ins Manifest files,
creates an entry in the Registry for each
installed plug-in and connects the entries of
interconnected plug-ins via crosslinks.
Tool Plug-ins are not activated until their
function is required. This policy of laziness
provides better performance, less memory load
and shorter start-up time. The actual set of
activated plug-ins is depicted as a structure
variance in figure 4. When a plug-ins
functionality is requested, first all prerequisites
of this plug-in are activated and then the
requested one. On Platform shut-down the
plug-ins are deactivated in reverse order of
activation. This principle assures that no plugin depends on another one, which is not
available.
The Workspace Resource Model, made up of
workspace and Resource Manager, performs
the resource management and will be
discussed in chapter 5.
5. Workspace Resource Model

The Workspace Resource Model is the underlying
data model of the Eclipse Platform IDE
framework. Every plug-in operates on resources
in the users workspace, where resource is a
collective term for items structuring the
workspace:
The Workspace Root is a container for projects, it
exists exactly once per workspace.
Projects are containers to collect every data that
is associated with a project. Every project
contains at least one file: .project which
contains project-related information.
Folders just serve to structure project-data
hierarchical.
Files contain the arbitrary data forming a
project, for example: code, debug information,
makefiles etc.
The Resource Workspace Manager is responsible
for saving and exiting the workspace on platform
shut-down and restoring it on platform start-up.
It synchronizes resources with files and
directories in the users working directory
(sometimes also called workspace) by reading,
creating, modifying and saving resources.
Plug-ins can access the workspace via resource
APIs, using the Resource Manager. The Resource
Manager also optimizes access to the workspace
storage.
It is possible to bypass the Resource Manager
but this is not recommended and can cause file
corruption.
4.3. Platform Plug-ins

The Eclipse Platform brings along a lot of plugins, so-called building blocks that facilitate the
development of applications and plug-ins. The
four most important will be outlined.
The Help plug-in provides a full-featured
framework for integrating documentation and
context-sensitive help into projects. The help
content can be published as a standalone
desktop help system or an online infocenter
server.
The Debug component is a framework for
building integrated debuggers in Eclipse. It
includes a generic debug model and important
debug mechanisms.
Team is the native configuration and version
management system of the Eclipse Platform. It
manages and tracks changes to project
resources. Other CVS can be added via plugins.
5.1. Mapping and Meta Data

In order to save project data onto a persistent
storage, resources are mapped to the users
working directory serving as container for all
project data. Every project has its own directory
that is named after the projects title. Folders are
mapped to directories and files are mapped to
files with arbitrary content on the storage.
The workspace directory and all project data
60
contains other components.

The Workspace can contain projects, projects
can contain folders and files, in turn folders can
contain folders and files. A project has at least one
file. This matches the definition of the resources
items.
The interface representing the workspace used
by the Resource Manager is called IWorkspaceRoot.
There is one per running instance of the Platform.
It is possible, that quite a lot of interfaces exist
accessing the workspace, but they are all
associated with the same IWorkspaceRootInterface. Therefore IWorkspaceRoot is realized as
a Singleton Pattern, which ensures, that only one
instance of an object exists.
This is realized by a simple mechanism: If
IWorkSpaceRoot is called into action, its
implementation checks, if there is already an
instance of IWorkspaceRoot. If one exists it will be
returned, otherwise a new instance of
IWorkspaceRoot will be created and returned. To
achieve this, the constructor-method has to be
static.
can be accessed and manipulated with native

tools of the operating system.
The Eclipse Platform saves all metadata under
/.metadata in the workspace directory. This
directory and its content should not be
manipulated by other tools, because this can
cause damage to the Platform.
The file .log contains all plug-in and Runtime
errors.
The file .lock serves for securing the working
directory. If one instance of the Platform is
running, another instance cannot access the
same working directory. This mechanism is
created to avoid file corruption.
The metadata directory contains a directory
named /.plugins, where every plug-in can save
its own metadata in a separate subdirectory. This
can be regarded as the plug-ins current state.
5.2. Design Patterns

The Eclipse developers used approved design
patterns, designing the Resource Workspace
Model.
interface
IWorkspaceRoot
5.3. Resource Management
Singleton
The Resource Workspace Model has a lot of

features. Some of them the most important and
useful ones will be outlined.
With Natures it is possible to tag a project,

giving it a personality. Doing this, equivalent
projects can be managed homogenous. The
Nature mechanism is open, which means that
tools can provide any new Natures and code to
manage it. Natures can be for example: Java
Natures, HTML Natures, etc.
The History mechanism keeps track of the
previous content of files in the workspace that
have been changed or deleted. In order to keep
the amount of data manageable, changes are
saved as change-deltas. These deltas provide
any information to undo or redo changes.
Markers record any type of annotations to file
contents. These annotations can be appended at
any place in the resource file, if a tool
managing the resource provides it. The Java
Development Toolkit for example enables the
user to insert to-do- lists, comments,
bookmarks and more at the according line in
the source code. Compilers can add their error
or warning messages at the correct place of the
code, to facilitate corrections.
0..*
interface
IProject
1
1..*
interface
IResource
interface
IFile
0..*
member
interface
IFolder
Figure 6: UML Class Diagram: Design Patterns
The workspace is structured using the Composite

Pattern [MUN]. The Composite Pattern serves for
structuring arbitrary hierarchical data, especially
data trees. The Component (IResource) can be
either a leaf (IFile), containing data but no other
components, or a composite (IContainer) that
61
6. Conclusion
References
Zawinskis Law: Every program attempts to expand

until it can read mail. Those programs that cannot so
expand are replaced by ones that can.
Jamie Zawinski [ZAW]
[ECLIPSE1] Eclipse Foundation,

http://www.eclipse.org/org/
[ECLIPSE2] Eclipse Platform Whitepaper (technical
overview),
http://eclipse.org/whitepapers/eclipseoverview.pdf
Grown from a small IBM- led project, the Eclipse

Platform expanded to a complex framework
providing a nucleus of mechanisms and APIs for
discovering, integrating and running plug-ins.
Building useful tools, those plug-ins are based on
the main concept of the Platform also building its
architecture via Extension Points. Managed by the
Runtime, all plug-ins are activated dynamically.
The Workbench provides an extensible, fullfeatured user interface that provides high
performance and a look-and-feel that is native to
the operating system.
Many tools can be integrated into one Platform
instance. They run and cooperate to provide
certain tasks not only Java application
development.
Furthermore, it offers a Rich Client Platform
that facilitates the design of applications using the
Eclipse Platform design and its components.
Based on approved design patterns the
Resource Workspace Model provides highly
efficient and reliable management of all resources
that are manipulated by these plug-ins.
[CPL] Common Public License,

http://www.opensource.org/licenses/cpl1.0.php
[OSGI] Open Services Gateway Initiative,
http://www.osgi.org
[DICT] Link Everything Online LEO Dictionary,
http://dict.leo.org/?search=widget
[MUN] UAS Munich (faculty information technology),
http://www.cs.fhm.edu/~boettcha/sws/plugindev.pdf
[ZAW] Jamie Zawinski Netscape Software Designer,
http://www.jwz.org/hacks/
The Eclipse Platform cannot read mails itself, but

there are applications based on Eclipse that do.
That sums it all up.
62
Eclipse Plug-ins
Michael Perscheid
michael.perscheid@hpi.uni-potsdam.de
bersicht
von zyklischen Abhngigkeiten). Ebenso kann

jedes Plug-in in Eclipse nur einmal gestartet
werden, deshalb werden viele mittels des
Singleton Pattern realisiert.
Lazy loading bietet eine Mglichkeit um
Grenzen bei der Menge an Plug-ins zu umgehen.
Hierbei wird jeweils - erst beim wirklichen Bedarf
- die eigentliche Komponente geladen. Dies wird
einerseits mit der Bekanntmachung der Plug-ins,
mittels ihres Manifests und andererseits mit dem
OSGi-Framework realisiert.
An dieser Stelle sei auf The Eclipse Platform
(siehe [1]) verwiesen, welches zum besseren
Verstndnis von Eclipse und dessen Architektur
beitrgt.
Dieses Dokument beschftigt sich mit den Konzepten

und Technologien von Eclipse Plug-ins.
Es wird gezeigt, wie man Eclipse erweitert und wie
sich Plug-ins strukturell aufbauen.
Anschlieend wird auf die einzelnen Komponenten
und Technologien eingegangen, um deren Verbindung
zum Gesamtaufbau darzulegen.
Am Ende wird anhand des JDT (Java Development
Tool) die Einbettung von Plug-ins in Eclipse
dargestellt.
Schlsselwrter: Eclipse Plug-in Architektur,
Manifest, Extension Point, OSGi Framework,
Java Development Tool
2. Problem
1. Einleitung
Das Plug-in-Konzept ist ein mchtiges Werkzeug,

um Eclipse zu nutzen und zu erweitern. Doch
besteht deren Dokumentation meist nur aus
Tutorials und vielen verstreuten Informationen.
Diese Ausarbeitung soll helfen, die wichtigsten
Informationen zu Plug-ins zusammenzustellen
und dabei ihren Zusammenhang in das
Gesamtkonzept zu verdeutlichen.
Des Weiteren soll auch das Verstndnis fr
eine abstrakte Vorstellung, fr die Handhabung,
sowie der Technologie von Plug-ins in Eclipse
gestrkt werden.
Im Inhalt wird sich jedoch keine Anleitung fr
die Entwicklung eines Plug-ins finden1. Jedoch sei
mir an einigen Stellen erlaubt, auf kleinere Tipps
fr den Umgang mit Plug-ins und der PDE2
einzugehen.
Eclipse ist eine universelle Plattform, auf der

alle mglichen Programme laufen knnen. Um
dies zu realisieren, bentigt man Plug-ins und
weitere wichtige Konzepte.
Eclipse bietet grundstzlich 3 Mglichkeiten es
zu erweitern, daher sind die normalen
Bibliotheken und Dokumentationen nur der
Vollstndigkeit halber genannt. Die wichtigste
Mglichkeit ist das Konzept, dass die eigentliche
Plattform mittels Plug-ins erweitert wird. Dabei
gilt, dass Eclipse nahezu vollstndig aus diesen
aufgebaut ist.
Die kleinste Einheit in Eclipse, welche separat
ausgefhrt werden kann, nennt man Plug-in. Es
ist ein strukturiertes Bndel aus Ressourcen,
welches die Mglichkeit bietet sich ber
festgelegte Schnittstellen in Eclipse einzuklinken.
Auch gibt es die Mglichkeit, selbst solche Stellen
zu schaffen und somit aus vielen kleinen
Komponenten ein groes Ganzes zu schaffen.
Dabei ist es wichtig zu beachten, dass die
hierarchische Anordnung der Plug-ins und ihrer
Schnittstellen nicht verletzt wird (keine Bildung
Dieser Bedarf sollte von anderen Quellen mehr als gedeckt

sein. (siehe [6])
2 Plug-in Developer Environment
1
63
resources
Feature
icon
Manifest
owns
- name
- id
- version
uses
documentation
consists of
Plug-In
Java Code
Extension
Point
Fragment
0,1
contains
references to
consists of
library
Dependency
Point
provides
has parent
p , e provides , p , m owns
e , m references to
p , e uses , p , m owns
e , m references to
p - Plug-in / Fragment
e - Extension Point / Dependency Point
m - Manifest
Abbildung 1 Plug-in Struktur
Grobstruktur des jeweiligen Plug-ins beschreibt.
Zustzlich knnen noch optional Java Code oder
eine bzw. mehrere Ressourcen genutzt werden.
Die letzte Komponente sind die so genannten
Fragmente. Sie gelten als optionale Teile eines
Plug-ins. Damit ist es mglich sie unabhngig
vom Host-Plug-in zu installieren oder zu
verndern. Sie besitzen daher auch genau die
gleiche Struktur wie Plug-ins (d.h. ein Manifest,
optional Ressourcen, Java Code). Im Gegensatz zu
Plug-ins sind Fragmente nicht allein lauffhig,
denn sie bentigen immer ein Host-Plug-in von
dem sie auch die Abhngigkeiten erben und
somit benutzen knnen. Es gilt, dass Fragmente
von der Runtime logisch aber nicht physisch dem
Host-Plug-In zugeordnet werden, d.h. auch das
Plug-in selber sieht das Fragment als optional an
und ist auch ohne ihn lauffhig. Aus diesem
Grund werden sie gerne fr Spracherweiterungen
genutzt.
Ein verbreiterter Missbrauch von Fragmenten
findet beim Patchen von Plug-ins statt. Dabei
nutzt man den Ladezyklus der Runtime aus und
trgt das Fragment vor dem eigentlichen Laden
des Plug-ins ein. Diese Praxis ist zwar sehr
3. Plug-in Architektur
3.1. Struktur
Das Entity-Relationship-Diagramm in Abbildung
1 verdeutlicht den grundlegenden Aufbau von
Plug-ins. Dabei lsst sich dort leicht erkennen,
dass es 3 Teilarten von Komponenten gibt.
Das Feature besteht aus einem oder mehreren
Plug-ins.
Es
ist
damit
die
kleinste,
herunterladbare und installierbare Einheit in
Eclipse. Die Unterscheidung wird getroffen um,
groen Projekten eine Abstraktion von Plug-ins
zu geben und somit das Installieren von
Komponenten zu erleichtern. Features spielen
hier nur eine kleine Rolle und werden auerhalb
von Eclipse gerne mit dem Begriff Plug-in
gleichgesetzt.
Das
eigentliche
Plug-in
ist
die
Hauptkomponente in der Architektur. Es ist eine
Kapselung von Verhalten und/oder Daten,
welches dazu, dient mittels anderer Plug-ins ein
lauffhiges Programm zu erschaffen. Sie besitzen
jeweils genau ein Manifest, welches die
64
3.2.1. Lazy Loading
umstritten, allerdings bietet Eclipse im Moment

keine Alternative dafr.
Mit diesem Konzept ist es mglich, beliebig viele

Plug-ins zu installieren, ohne einen Verlust von
Performance zu haben.
Beim Start von Eclipse wird das Plug-in
Verzeichnis (hier befinden sich alle installierten
Plug-ins) gelesen, dabei werden alle Manifeste in
die Registry geladen. Die Platzhalter geben nun
Auskunft ber Abhngigkeiten und stellen
sozusagen einen Schatten (nur Plug-in Manifeste
sind geladen aber der Code selbst noch nicht)
aller mglichen Plug-ins dar.
Nun gilt es, die notwendigen Core-Plug-ins zu
laden. Diese stellen Kernfunktionalitten bereit
und mssen somit von Anfang an verfgbar sein.
Alle anderen Non-Core-Plug-ins werden erst
nach Bedarf geladen, d.h. wenn ihre Funktion
bentigt wird. Dabei geht Eclipse in die Registry,
schaut sich dort das Manifest des jeweiligen Plugins an und ldt gegebenenfalls RuntimeAbhngigkeiten. Als letzten Schritt startet die
Runtime nun das Plug-in und ldt, falls
notwendig, weitere Abhngigkeiten, wenn sie im
Code auftreten.
3.2. Manifest
Das Manifest beschreibt den groben Aufbau eines
Plug-ins oder Fragments. Darin enthalten sind
wenigstens der Name, die Version und eine
eindeutige ID mit der die Runtime das Plug-in
identifizieren kann. Ebenso findet man dort
smtliche Abhngigkeiten3 die ein Plug-in
bentigt oder benutzt.
An dieser Stelle sei kurz auf die Formel
unterhalb des Diagramms eingegangen. Sie
bedeutet, dass es fr jede Abhngigkeit im Plugin, sei es nun Bereitstellung oder Benutzung, eine
eindeutige Referenz im Manifest von ihm geben
muss. Sollte eine Abhngigkeit benutzt werden,
welche nicht hier aufgelistet ist, so kann man sie
auch nicht verwenden.
Das Manifest basiert auf der XMLTechnologie, wobei dies fr die Entwickler
zweitrangig ist, da Eclipse mit dem PDE einen
sehr guten Editor bereitstellt. Dieser sollte auch
unbedingt benutzt werden, da Fehler im Manifest
die Ladbarkeit des eigenen und anderer Plug-ins
gefhrden.
Zu beachten ist, dass die Manifestdatei
plugin.xml bzw. fragment.xml heien muss.
3.3. Dependencies
Mit Dependencies werden Verbindungen zu
Funktionen
anderer
Plug-ins
oder
Funktionsbibliotheken beschrieben, welche ein
Plug-in bentigt. Auch gibt es die Mglichkeit,
eigene Klassen etc. nach auen zu ffnen. Bei den
Dependencies unterscheidet Eclipse zwei Arten,
welche
sich
nur
im
Lademechanismus
unterscheiden.
Normale Dependencies werden erst beim
eigentlichen Bedarf im Sourcecode geladen. Fr
Entwickler heit dies, dass man sie erst mglichst
spt einbinden sollte.
Runtime Dependencies unterscheiden sich im
Gegensatz dazu in dem Punkt, dass sie immer
bevor das Plug-in gestartet wird, geladen sein
mssen.
Dies
sind
also
meist
die
Standardbibliotheken oder Core-Plug-ins.
Da Dependencies auch im Manifest stehen
mssen, unterscheidet man die Angebotsseite,
welche ebenso bekannt gemacht werden muss,
bevor das Plug-in geladen wird und die
Nachfrageseite, welche sich in Normal und
Runtime unterscheidet. Auch hier gilt wieder:
Wenn Fehler im Manifest auftreten, kann man
zwar sein Plug-in kompilieren aber nicht
ausfhren.
Beispiel
<?xml version="1.0" encoding="UTF-8"?>
<plugin
id="de.myExample.eclipse"
name="HelloWorld Plug-in"
version="1.0.0"
provider-name=Max Muster"
class="de.myExample.eclipse.HelloWorldPlugin">
An diesem Beispiel erkennt man, dass auch

zustzliche Eintrge erlaubt sind und auch oft
genutzt werden. Vor allem Dokumentation zu
dem Plug-in wird meist erweiternd bereitgestellt.
Sollte die Komponente Javacode bereitstellen, so
muss natrlich auch eine Startklasse angegeben
werden, welche wiederum eine Subklasse von
org.eclipse.core.runtime.Plugin
sein
muss,
damit Eclipse den Einstiegspunkt finden kann.
Der Sinn des Manifests liegt nun in der lazy
loading Mglichkeit von Eclipse.
Abhngigkeiten bestehen hier aus Dependencies und
Extension Points
3
65
All diese Eintrge mssen wiederum im

Manifest stehen, damit Eclipse jederzeit wei, wer
welche Extension Points anbietet und wer welche
erweitert. Intern wird dies ber so genannte
Querverweise (Crosslinks) realisiert. Da sie nun
sehr gro und komplex werden knnen, lagert
das PDE sie aus dem Manifest in eigene
Schemata.
Dadurch
erhht
sich
die
bersichtlichkeit und Entwicklern wird es
leichter gemacht, sich in den Extension Points
zurecht zu finden.
In Eclipse stehen nun genau 3 Arten von
Extension Points zur Verfgung:
Bei der ersten Form stellt das Host-Plug-in ein
Interface bereit, welches implementiert werden
muss. Diese Implementierung wird dann vom
Host-Plug-in gestartet und abgearbeitet (siehe
auch 3.4.1.). Zum Beispiel Anwendungen
allgemein; welche mittels Eclipse ausgefhrt
werden und somit nur IPlatformRunnable
implementieren mssen.
Die zweite Art basiert nur auf XML-Eintrgen,
welche zur Erweiterung angegeben werden
mssen. Das eigentlich Verhalten darauf ist im
Host-Plug-in gekapselt und kann nur ber die
Spezifikationen verndert werden. Plug-ins,
welche nur solche Extension Points nutzen,
bentigen meist keinen eigenen Java Code, da sie
alles ber die XML-Eintrge erklren. Beispiele
hierfr sind Sprachpakete oder der Extension
Point Ignore. Bei diesem jedoch, gibt man nur an,
welche Dateiendungen das System Ignorieren
soll.
Die dritte und letzte Form ist eine Mischung
aus Beidem. Dort realisiert ein Teil das Verhalten
des Host-Plug-ins (XML-Eintrge) und der andere
die Implementierung des Interfaces. Bekannte
Beispiele hierfr sind die SWT/JFace4 Extension
Points, dabei gibt man im Manifest an, wie
Buttons, Mens etc. auszusehen haben aber das
eigentliche Verhalten wird dann ber die
Interfaceimplementierungen definiert.
Da Eclipse, wie bereits erwhnt, nahezu nur
aus Plug-ins aufgebaut ist, bentigt jede
Erweiterung auch einen Extension Point an dem
es sich an der entsprechenden Stelle in Eclipse
einklinken kann.
Die Tags im Manifest sehen auf Angebots- und
Nachfrageseite sehr hnlich aus. Eclipse kann dies
nun aber ber die Pfade entscheiden: So heit ein
relativer Pfad, das Plug-in bietet ein Extension
Beispiel
<runtime>
<library name="eclipse.jar">
<export name="com.myExample.*">
</library>
</runtime>
<requires>
<import plugin="org.eclipse.core.*"/>
</requires>
Das Beispiel zeigt die Angabe mehrerer

Dependency Points , wobei sowohl die
Benutzung von runtime (library) und normalen
Dependencies (requires, import) beschrieben wird,
als auch die Bereitstellung des Plug-ins nach
auen (export).
3.4. Extension Points

Dieses Kernkonzept bietet die Mglichkeit, sich
bei anderen Plug-ins einzuklinken und sie somit
zu erweitern. Dies ist also genau das Gegenteil
der Dependencies, bei denen man auf
bereitgestellte
Funktionen
von
anderen
Komponenten zurckgreift, um sie selbst zu
nutzen.
Extension
Points
bilden
daher
Schnittstellen, welche einen eindeutigen Namen
besitzen und meist eine Kombination aus XMLEintrgen und einem Java-Interface sind. Ein
Plug-in, welches solch einen Punkt erweitern will,
muss also alle Spezifikationen die dieser
bereitstellt
ausfllen,
d.h.
XML-Eintrge
spezifizieren
und
das
Java-Interface
implementieren. Dabei kann das Host-Plug-in
selbst eine Default-Implementierung bereitstellen.
In Abbildung 2 ist nun ein mgliches
Klassendiagramm,
welches
diesen
Zusammenhang ausdrckt dargestellt.
Abbildung 2 UML Extension Point
66
Eclipse GUI (siehe [1])
Point an, wobei ein absoluter Pfad bedeutet, man

mchte den Extension Point von einem anderen
Plug-in nutzen.
Fr Entwickler sei jedoch erwhnt, dass diese
Beschreibung sehr allgemein gehalten wurde und
fr die Entwicklung von Plug-ins ein
ausfhrliches Studium der entsprechenden
Extension Points ntig ist.
Runtime) und whlt den zu suchenden Extension

Point aus. Daraufhin werden alle Erweiterungen,
die an ihm anliegen, separat in eine Liste geladen,
welche nun abgearbeitet wird.
Aus jeder
Erweiterung werden alle Elemente (XMLEintrge, Java Interface) herausgeholt und mit
ihnen versucht umzugehen. Dabei ist bei den
XML-Eintrgen das Verhalten im Host-Plug-in
beschrieben und bei den Java Interfaces wird
versucht, mittels Java Reflection, eine ausfhrbare
Klasse zu erschaffen und sie auszufhren. Somit
wird nun die komplette Erweiterung im HostPlug-in abgehandelt.
An dieser Stelle sei aus didaktischen Grnden
noch kurz die Steckdosennotation erwhnt. In
vielen Quellen[2],[5],[6] wird diese Notation
verwendet, um das Konzept von Extension zu
erlutern. Angebotene Extension Points werden
dabei als Steckdosenleisten dargestellt in denen
sich viele beliebige Plug-ins (Nachfrager)
einklinken knnen und somit eine Erweiterung
darstellen. Diese knnen selbst auch wieder neue
Steckdosen anbieten usw.
3.4.1. Host-Plug-in Implementation

Die Implementierung von Host-Plug-ins muss
einen Algorithmus bieten, mit dem man alle
Erweiterungen an einem Extension Point abfassen
kann, ohne jedes Mal neu zu kompilieren. Dieser
ist in Abbildung 3 dargestellt. Um ihn zu
verstehen ist ein Systemverstndnis von Eclipse
sehr
wichtig,
da
beide
sehr
eng
zusammenarbeiten.
Example
Connect to
Platform Registry
Registry
Registry: Choose
Extension Point
Extension
Point
Read all
extensions in a list
3.5. Installation von Plug-ins
Registry
Die einfachste Art Plug-ins zu installieren: Man

kopiert
sie
einfach
in
den
Ordner
/eclipse/plugins/, welcher bei jedem Start
von Eclipse komplett durchsucht wird und alle
gefunden
Manifeste
ldt.
Eine
weitere
Mglichkeit ist es, den Software Update Manager5
zu nutzen, welcher unter Angabe einer URL ein
gesamtes Feature herunterldt und installiert.
Zur Verwaltung von Plug-ins bietet Eclipse
ebenso einen lokalen Browser6 mit dem man sie
aktivieren/deaktivieren kann.
Fr Entwickler seien hier noch kleine Tipps
erwhnt, welche unter umstnden hilfreich sein
knnten. /workspace/.metadata/.log bietet
reichhaltige Informationen ber den Status von
Eclipse. Eine Liste aller gefundenen Plug-ins
findet man unter Help -> about eclipse platform
->
Plug-in
details
und
detaillierte
Informationen zum Ladestatus einzelner Plug-ins
erhlt man durch das Anlegen eines neuen Plugin-Projekt mit dem PDE. In der neu geladenen
Perspektive ist im Log-View einiges an
Informationen enthalten.
Registry
Element
Read all elements
from extension in
a list
Element
Extension
no further
extensions
No further
elements
Handle Element
Abbildung 3 Host-Plug-in Algorithmus

Mit
Hilfe
des
Beispiels
soll
das
Zusammenwirken verstndlicher werden. Eclipse
befindet sich bereits in der Laufzeit, nun erfolgt
vom Benutzer der Ansto ein neues Plug-in zu
laden. Daraufhin durchsucht die Runtime die
Registry nach dem Manifest des zu ladenden
Plug-ins. Stellt es an dieser Stelle eine
Erweiterung zu einem bestehenden Extension
Point fest, so wird der obige Algorithmus
abgehandelt.
Das Host-Plug-in verbindet sich anschlieend
ebenfalls mit der Registry (indirekt ber die
5
6
67
Help -> Software Updates -> Find and Install

Help -> Software Updates -> Manage Configuration
4. OSGi7 Framework
Workbench
Das OSGi-Framework[3] ist ein offener Standard

fr
die
Verwaltung
von
dynamischen
Komponenten und eingebetteten Systemen. Da
Eclipse genau diese Ansprche stellt, bietet sich
das Framework sehr gut als Implementierung an.
Dazu ist allerdings noch zu sagen, dass die
Umsetzung etwas vom Standard abweicht.
Das OSGi-Framework sieht vor, dass
Softwarekomponenten dynamisch installiert,
gelscht und gendert werden knnen. Ebenso
soll es die Mglichkeit des selektiven Exports von
Teilen der Komponenten geben. Es soll komplett
vom Benutzer verdeckt sein, sodass er nach wie
vor nur mit der Plattform Runtime arbeitet. Auch
bezeichnet nun der Standard Komponenten als
Bundles, welche ihren eigenen Java Class Loader
und ein Protokoll zur Verwaltung des Zustandes
(installiert, entfernt, gestoppt etc.) besitzen. Das
Framework selber unterteilt sich in 4+1 Schichten.
L0: Execution Environment, ist im Allgemeinen
die JVM oder eine andere ausfhrbare
Umgebung.
L1: Modules, bezeichnet alle Ressourcen,
Klassen und Softwarekomponenten, sowie die
OSGi spezifischen Erweiterungen.
L2: Life Cycle Management, verwaltet das
dynamische Leben der Bundles.
L3: Service Registry, verwaltet nun die Bundles
intern (z.B. ihren Zustand).
Die letzte Schicht ist das Security System,
welches mit allen anderen Schichten verknpft ist
und somit fr die Sicherheit sorgt. So geht die
Kommunikation zwischen den Komponenten
oder Anfragen nach Ressourcen ber sie.
Bildet man dieses System auf Eclipse ab, so
sieht man, dass bestimmte Funktionalitten nur
teilweise bernommen wurden. Abbildung 4
zeigt eine Verfeinerung der Runtime (Original aus
[1]) und die Implementierung der Schichten.
Man kann an dieser Abbildung leicht alle
Schichten wieder finden. Die JVM spiegelt L0
wider, wobei alle Plug-ins auf sie zugreifen
knnen.
Die L1 Modul Schicht findet sich im Plug-in
directory wieder, wo sich alle Ressourcen
befinden.
7
Workbench
Plug-In
Java Execution Environment
JVM
Platform
Resources
R
Activated Plug-Ins
Lifecycle
Manager
Service registry
manager
Plug-In Registry
Security Service
Plug-In
OSGi Framework
Eclipse IDE
Platform Runtime
Plug-In Directory
(Modules)
harddisk
Abbildung 4 Eclipse Runtime OSGi

L2 ist der Steuerakteur fr die dynamischen
Plug-ins. Hier treten auch die ersten Unterschiede
auf. Seit Version 3.0 ist das dynamische
installieren von Plug-ins mglich. Dafr mssen
die entsprechenden Extension Points genutzt
werden, um die Abwrtskompatibilitt zu
sichern. In diesen sind bestimmte Methoden
deklariert (start/stop), mit denen die Ressourcen
dynamisch angefordert werden. Sind diese
Methoden nicht implementiert, so ist das
Installieren whrend der Laufzeit auch nicht
mglich. Die Deinstallation von Plug-ins soll erst
ab Version 3.1. untersttzt werden, da sich hier
jedoch einige Probleme in Bezug auf die LaufzeitAbhngigkeiten ergeben, kann die Entwicklung
dieser Extension Points noch etwas andauern. Der
Lifecycle Manager realisiert also im Groben die
leazy loading Politik von Eclipse.
L3 befindet sich im Service Registry Manager,
welcher das Laden der Manifeste und den Zugriff
auf die Registry steuert. Hier werden die
Konzepte fr das Manifest, Extension Points und
Dependencies realisiert. Die Erweiterung der
Zustnde fr Bundles wird ebenfalls nur teilweise
umgesetzt, da nicht alle Zustnde bentigt
werden. Der Security Service bleibt wie im
Standard
erhalten
und
steuert
die
Kommunikation zwischen allen Schichten und
verwaltet die Rechte fr Ressourcen.
Man sieht, dass Eclipse das OSGi-Framework
schon recht gut implementiert und die fehlenden
Punkte unter Umstnden in folgenden Versionen
realisiert werden.
Open Services Gateway Initiative
68
GUI
R
Packages
view
Type
hierarchy
view
Java editor
Java
outline
Run
Preference
Page
Action
Java Perspective
JDT UI
R
Java Model
Java Builder
Sourcefiles
files
Source
Binary
Binary
classfiles
files
class
classpath
Java Problems
Marker
Java Project
Nature
Java Element
Tree
Dependency
Graph
Workspace
JDT Core
Abbildung 5 JDT - Aufbau

Suchmglichkeiten, Compiler und Debugger.
Die Plug-in Developer Environment greift
ebenfalls auf dessen Teile zurck und nutzt sie
um z.B. Plug-ins zu kompilieren.
5. Java Development Tool

Viele Menschen assoziieren Eclipse meist mit
einer Java Entwicklungsumgebung, dass dem
nicht so ist, sollte aus [1] und dieser Ausarbeitung
ersichtlich geworden sein. Trotzdem sei an dieser
Stelle kurz auf die Leistungsfhigkeit der JDT
eingegangen und danach auf die eigentliche
Einbettung in das Eclipse Framework.
In
Abbildung
5
erkennt
man
den
grundlegenden Aufbau aus der Sicht eines
Anwenders. Man greift mittels einer grafischen
Oberflche (die GUI von Eclipse) auf die
entsprechenden Teile, wie die Package View oder
verschiedene Editoren zu. Neben Views und
Editoren gibt es auch Buttons etc. mit denen man
direkte Funktionen aufrufen kann, so z.B. Run.
Der Benutzer selbst hat somit nur Zugriff ber die
grafische Benutzerschnittstelle auf das JDT UI.
Alles, was im Hintergrund abluft, behandelt die
JDT Core. Dort finden sich Elemente wie das Java
Model und der Java Builder, welcher den
Compiler und Debugger beinhaltet.
Es wird somit eine komplette Java
Entwicklungsumgebung in das Eclipse SDK
eingebettet. JDT bietet somit Standardmerkmale,
wie
z.B.:
Java
Projects,
Editoren,
5.1. Implementation
Realisiert wird das Ganze nun vornehmlich ber
das Konzept der Extension Points (Abbildung 6
zeigt
eine
Aufzhlung
der
wichtigsten
Erweiterungen). Eclipse stellt auf der linken Seite
Punkte fr Editoren, Views, Perspektiven usw.
bereit. Diese werden dann durch konkrete Plugins erweitert und implementiert. Man kann hier
auch eine eindeutige Trennung zwischen
Workbench und Workspace erkennen. Dies ist
darin
begrndet,
dass
die
grafische
Benutzerschnittstelle
vom
Laufzeitkern
abgekapselt wurde, um unabhngig davon
verschiedene Mglichkeiten zu bieten. Die
Trennung wurde ebenfalls vom JDT bernommen
und so findet man sie im JDT UI und JDT Core
wieder. Das erlaubt z.B. die Kompilation von Java
Projekten mittels der Core ber die Konsole.
5.1.1. JDT Core

Der Kern baut sich aus folgenden drei Dingen
zusammen:
69
5.1.2. JDT UI
Java Project Nature markiert Projekte als Java

spezifisch. D.h. es wird z.B. ein classpath file
eingefhrt und der Aufbau von Klassennamen
definiert.
Der Java Builder bildet im Groben den
Compiler und den Debugger, mit denen die Java
Projects kompiliert werden knnen.
Fehler werden ber das Java Problem definiert
und beim Auftreten in die Dateien/Editoren
geschrieben. Eine Besonderheit bildet der
Dependency Graph (siehe Abbildung 5). Mittels
diesem, ist es mglich eine sehr effiziente
Kompilierung auszufhren. Der Builder merkt
sich, welche Dateien bereits verndert sind,
welche kompiliert wurden und auf welche
momentan zugegriffen wird. Somit wird bei
einem Run nie alles neu kompiliert - es sei dem,
es ist gewnscht. Ebenso bietet es die Mglichkeit
in Leerlaufphasen schon Teile vorzukompilieren,
daraus folgt, dass auch ein teilweise fehlerhafter
Code benutzt werden kann und groe Projekte
schneller lauffhig sind, da nur die vernderten
Teile bersetzt werden mssen.
Das UserInterface bildet die Schnittstelle zum

Benutzer und bietet ihm eine Perspektive mit
Action Sets (z.B. Buttons), Editoren und Views.
Mit diesen kann er seine Java Projekte
zusammenbauen und editieren. Um auf den
Ressourcen zu arbeiten, bietet das JDT das Java
Model.
5.1.3. Java Model

Das Modell bildet eine API zur Navigation auf
dem Workspace, dabei werden alle Ressourcen
durch Objekte ersetzt, um nicht direkt auf ihnen
zu arbeiten. Dazu puffert es oft gebrauchte
Elemente in dem Java Element Tree und stellt
somit eine sichere Schnittstelle zur Verfgung.
Alle Akteure aus dem JDT UI mssen ber das
Model zugreifen, damit Konflikte ausgeschlossen
werden. Nur der Builder hat noch direkten
Zugriff auf den Speicher um seine Aktivitten
auszufhren.
5.1.4. Run and Debug

Nach der Kompilation durch den Builder startet
das JDT eine separate JVM, um das Programm
laufen zu lassen. Damit wird sichergestellt, dass
ein Fehler Eclipse nicht beeintrchtigt. Auerdem
ist es somit mglich in der Debug Perspektive alle
laufenden und terminierten Prozesse anzuzeigen
und aus ihr heraus zu verndern. Damit wird
dem Entwickler eine gute Mglichkeit geboten
auf seine Programme zur Laufzeit Einfluss zu
nehmen.
JDT UI Elements
Workbench
Elements
Perspectives
extends
Java
Perspective
Perspectives
Type Hierarchy
Perspective
Views
extends
Views
Packages View
Type Hierarchy
View
Editors
extends
Editors
Java Editor
Scrapbook
Editor
Wizards For
extends
New Java
Project
Wizards
New Java
Package
New Scrapbook
Page
6. Schluss
extends
Action Sets
Mit dem Plug-in Mechanismus von Eclipse ist es

mglich viel Funktionalitt ohne einen Verlust
von Performance zu realisieren. Des weiteren
sind
weit
reichende
Mglichkeiten
zur
Erweiterung geschaffen worden. All diese
Konzepte und Technologien lassen Eclipse zu
einem Musterbeispiel in vielerlei Hinsicht
werden.
Auch in Bezug auf die Einsatzmglichkeiten
sind Eclipse keine Grenzen gesetzt. Im Laufe der
Zeit hat es sich wirklich zu einer universellen
Plattform entwickelt und stellt durch seine
Plattformunabhngigkeit im Zusammenspiel mit
Java eine optimale Lsung fr viele Probleme dar.
Man kann also gespannt sein, was an Plug-ins fr
Eclipse noch auf den Markt kommt.
Java Action Set
Property Pages For

extends
Property Pages
Java Build Path
Jar Source
Attachments
Java Preference Pages
Preference
Pages
extends
Classpath
Variables
Workspace
Elements
Code Formatter
Java Editor
JDT Core
Elements
extends
Project Natures
Java Project
Nature
extends
Builders
Java Builder
extends
Marker Types
Java Problem
Abbildung 6 Eclipse/JDT Extension Points
70
[2] Eclipse Foundation
Ich hoffe ich konnte mit meiner Ausarbeitung

einen Teil dazu beitragen, die Komplexitt von
Plug-ins und deren Einbettung in die Konzepte
und Technologien von Eclipse zu vereinfachen,
sodass es anderen Entwicklern eine Hilfe sein
wird.
http://www.eclipse.org
[3] Open Services Gateway Initiative
http://www.osgi.org
[4] Article of Javaspektrum 2/2005 (OSGi
Framework)
Referenzen
http://www.sigs.de/publications/js/2005/02/link
e_JS_02_05.pdf
[1] M.Kunze, The Eclipse Platform, 2005
[5] J. Arthorne, C. Laffra, Official Eclipse 3.0 FAQs,

Addison Wesley Professional, 2004
http://wendtstud1.hpi.uni-potsdam.de/sysmodseminar/
[6] Javamagazin eclipse special Herbst 2004

http://www.eclipse-magazin.de
71
72
Enterprise JavaBeans and Their Deployment Using SAP NetWeaver

Ralf Gueldemeister
ralf.gueldemeister@hpi.uni-potsdam.de
Abstract
Enterprise JavaBeans (EJB) represent a convenient way
to build distributed applications. The concept includes the
integration into a container that provides several useful services and a sophisticated deployment process, enabling an
attribute-based programming approach. First, the general
EJB architecture is examined utlizing an example application. Next, the major features of Enterprise JavaBeans are
presented: the primary services of the container, the types
and interfaces of the beans, and their complex life cycle.
Lastly, the deployment using SAP NetWeaver is explained,
along with its key elements, the Software Deployment Manager and the versatile use of deployment descriptors.
1. Architecture Overview
To motivate the use of the Enterprise JavaBeans (EJB)
infrastructure, a brief example will illustrate the main concepts and the composition of a typical business application.
In this example two agents access counters, one increasing
a specific counter and the other generating a list from a set
of counters. These agents are called from a set of web pages
to count page views and a special web page that summarises
all collected data.
This simple example demonstrates the split into the typical three-tier architecture, with a presentation layer at the
top, the database layer at the bottom and the actual business
logic on the middle tier as shown in Figure 1. This pattern
can also be found in our model environment, the SAP Web
Application Server (WebAS), part of the SAP NetWeaver
suite.
This application can easily be modelled and implemented using the Enterprise JavaBeans concept. The web
pages residing in the presentation layer use Java Server
Pages technology to access the two agents realising the
business logic, which are implemented as session beans.
These session beans work together with entity beans, which
encapsulate the counter data and can be found partly in the
Figure 1. Architecture Overview
73
database, considering the persistent data, as well as the business layer, where all EJBs are executed. This counter bean
example will be continually referenced to support some underlying theoretical details of EJBs.
The following chapters introduce and discuss Enterprise
JavaBeans as a mean to develop such applications, how they
are embedded in the WebAS and how the deployment process is put into practice.
become persistent and the container maps them to a relational database. This service, offered in two variants, container managed persistence and bean managed persistence,
is the topic of another seminar contribution. [10]
Security services[3], in terms of authentication, access
control and secure communication, as well as transactions are also available to the bean. Transactions are either method-based managed by the container or specially
marked code fragments using the Java Transaction API.
The next primary service, concurrency, is slightly ambivalent. Although all business method calls are processed
concurrently by the container, there is no concurrent access
to single bean instances and no possibility for the developer
to control this concurrency1. Hence, the container uses a
pessimistic locking strategy and the EJB specification complies with a non-reentrance policy.
The last service, naming, which is essential for locating
bean objects and their interfaces, is realised with the Java
Naming and Directory Interface (JNDI).
2. Enterprise JavaBeans
Speaking academically, the Enterprise JavaBeans concept is a component architecture for building distributed applications and is classified in the category of component
transaction monitors. These involve convergence of traditional transaction processing, which typically deals with
high volume and mission critical data, and distributed object services, like CORBA or DCOM.
The concept of EJB, which tends to be platformindependent, scalable and reusable, was specified by Sun
Microsystems[13] and exists in different versions. Widely
used and accepted is version 1.1. The current version 2.0 includes two important changes. It adds the local client view
and introduces an additional bean type. The SAP WebAS
fully implements EJB 2.0.
Enterprise JavaBeans provide a convenient way to follow
an attribute-based programming approach using advanced
deployment descriptors to modify properties and to some
degree the behaviour of an application without changing its
programme code. Regarding the comprehensive supporting
infrastructure the developer can focus on its main task, programming the business logic.
In contrast to the similar names, Enterprise JavaBeans
and conventional JavaBeans differ substantially. The major difference lies in communication. Namely, that JavaBeans cover intraprocess communication, while Enterprise
JavaBeans are constructed for interprocess communication
between components and applications.
An essential part of EJB is the container concept. Bean
objects are embedded in the EJB container, which takes care
of the whole life cycle management and provides several
services.
2.2. The Three Bean Types

After having examined the EJB services, a closer look at
the bean types follows. Enterprise JavaBeans exist in three
varieties: entity beans, session beans and message-driven
beans2 .
Entity beans represent persistent business objects, which
can typically be expressed as nouns. They provide an encapsulation of entities with the relevant database accesses
and may contain a state and behaviour, whereupon the behaviour is limited to simpler operations on the managed
data. While they can be shared between clients, it is ensured by the container that all instances have the same representation of data on changes. Usually, entity beans are
not accessed directly by the presentation layer and for performance reasons the local view is recommended (2.4).
Session beans provide the business logic, sometimes acting as a facade of entity beans. They extend the clients
functionality and can be seen as a software agent. Typically, session beans are accessed remotely, which then access entity beans or other session beans locally. This server
side component structure results in a reduction of network
traffic and the number of network connections. A classical
example of a session bean is the summary agent that is used
for list generation directly from the database.
Session beans can either be stateful or stateless. They are
dedicated to one client if they contain a conversational state,
holding session information and process data. Otherwise,
they are stateless, leading to a higher performance, because
few instances can serve many clients. In the latter case, all
activities must be within one method call.
2.1. Primary Services of the Container

The six primary services provided by the container originate from the Component Transaction Monitors. The first
service deals with distributed objects and is fulfilled per se
by the EJB concept. Chapters 2.3 and 2.4 explore the communication between distributed objects.
Persistence, an important service available only to entity
beans, is solved in an object-orientated manner, i.e. the developer simply marks the attributes of an entity that should
1 In
this context Javas synchronized keyword is prohibited.

beans are available since version 2.0.
2 Message-driven
74
Message-driven beans, the third type, were introduced

to receive and process asynchronous messages through
Java Message Service (JMS). This ability not only enables
clients that are bound to asynchronous communication to
use EJB, but also prevents inelegant polling.
context, both the stub and the skeleton are automatically

generated by the container.
2.4. The Client View and the Interfaces

Now described is the client view and the application of
RMI in the communication between the client, e.g. a JSP,
an EJB or a web service consumer, and the server, which is
implemented by an Enterprise JavaBean. In general, there
is no direct communication between these two, because
the bean is always represented externally by the container,
which manages all requests. The EJB concept contains two
important types of interfaces, the home interface and the
bean interface.
2.3. Remote Method Invocation
Figure 2. Compositional Structure of RMI

Before explaining the client view, a digression to the
general concept of distributed object protocols is needed to
provide background information about the mechanisms applied in EJB communication. The beans are usually partitioned into two types. They can either act as a server offering business methods or as a client using these methods. In a distributed object environment, these two atypical objects do not have to be located on the same physical
computer unit, rather they can be running on any machine,
granted that a network connection exists between the two
hosts. This structure introduces the significant problem of
forwarding a clients method call to the server through the
network.
EJBs use the Remote Method Invocation (RMI) concept
to supply a virtual communication channel. RMI consists
mainly of two additional objects, which are the stub on the
client side and the skeleton on the server side. The stub acts
as proxy for the server and defines all public business methods, but instead of implementing them, it only contains the
necessary network operations for accepting a method call
from the client and packing it into a RMI network stream.
On the server side, the skeleton wraps the server, listens for
requests from the stub, unpacks and processes the network
stream and calls the server object with the original client
request. The reply is transported on the reverse track.
Due to this system model, remote objects are transparently mapped to local objects and the specifics of RMI are
hidden from the client and the server object. In the EJB
!!!
Figure 3. Client View Using Remote Interfaces

The home interface acts as a factory for bean objects and
is responsible for the life cycle management and the location of bean instances. The latter, realised by the so-called
finder methods, is explained in Chapter 3.3. After an instance has been created or located, a remote reference to it
is returned to the client, which then can be used to gain access to the bean. The access to the home interface, keeping
in mind it may be located on a remote machine, is realised
by the Java Naming and Directory Interface (JNDI).
75
The bean interface, also referred to as the remote or the

component interface, defines all public business methods of
the bean.
These interfaces exist in two varieties. The remote variant, illustrated in Figure 3, uses the RMI means of the stubskeleton pattern, with which the server-side proxy skeletons are handled by the EJB container and the client avails
the home interface and the bean interface provided by the
stubs. The remote view is location independent and results
in a loose coupling between client and bean. However, remote calls are expensive because of the intermediate RMI
layer and the need to process and handle remote exception.
Also, all arguments are passed by value, which leads to
high network load when working with bigger objects, but
conversely, may save explicit working copies and reduce
sources of error.
The second variant is the local view, which is available
since Version 2.0 of the EJB specification. It requires the
client and the bean to be co-located in the same Java Virtual Machine (JVM), which is the Java processing platform.
Here, arguments are passed by reference, which allows the
client and the bean to share states. This view provides a
very efficient communication option, but restricts the distribution.
Typically, only one approach is considered but it is possible to use both of them to increase re-usability and enable
the client to chose the best-fitting view with regard to the
actual application.
tion classes are provided transparently by the container.
2.5. The Life Cycle of an Entity Bean

Before presenting the deployment process, the EJB life
cycle is inspected, because it is an integral part of understanding the container-bean relationship. Figure 5 shows
the dynamic structure of an entity bean. It includes the three
states does-not-exist, pooled and ready[4], the possible
transitions between these states and the triggering agents,
either the client or the container.
The life cycle starts in the does-not-exist state. At this
stage, there is no instance of this entity bean available. After the application has been loaded, the container instantiates the bean and adds it to the instance pool. The petri net
covers only one instance for simplicity, but in general several object instances exist at the same time. When an object
is created it receives the context providing the interface to
the container services. From this point on, the entity bean
object is accessible by the client.
When a client needs to create an instance, direct or indirect via a finder method, the object is not created, but rather
an instance is taken from the pool and assigned to the client.
This action makes the EJB ready to accept calls to the business methods. During the business processing initiated by
the client, the container takes care of persistence and transparently synchronises the bean data with the database before the business method is executed and afterwards stores
the changed data afterwards. If all work is done and the
bean is no longer needed, it will be reset and moved to the
pool again. It should be noted that the instance will not be
destroyed at this moment.
The actual removal of an object only takes place on unusual occurrences, e.g. unstable behaviour of an object, instance pool resizing or the shutdown of the whole application server. Thereafter, the unset context transition is fired
and the instance is dereferenced for later garbage collection.
The container uses two important mechanisms to save
server resources. Firstly, it uses passivation to conserve the
state of an idle EJB, which is assigned to a client, but has
not been accessed for a long period of time. It serialises
all attributes, except the marked transient ones, saves them
to the secondary storage and pools the instance, but keeps
the connection to the bean object. Of course, persistent attributes of an entity bean are saved directly to the database.
On an incoming call to the original instance, a new object
is taken from the pool, initiated with the serialised data and
then assigned to the client, taking over the role of the passivated instance. This process is called activation and is not
noticed by the client.
Another resource management concept is the already
mentioned instance pooling. Obviously, it is more efficient
to reuse object instances rather than to create and destroy
Figure 4. Class Diagram of an Entity Bean

Figure 4 shows the interfaces on class level using the
counter bean example. Illustrated are the bean interfaces
in the remote and local variant, Counter and CounterLocal respectively, and their super classes EJBObject and
EJBLocalObject. On the right is shown the two home interfaces CounterHome and CounterLocalHome, which extend EJBHome and EJBLocalHome respectively. Currently,
the missing part is the actual bean class CounterBean. In
this example it inherits EntityBean, while the other types of
bean would inherit SessionBean or MessageDrivenBean. It
is noteworthy that only the bean class contains an implementation part, the business methods. Remark that there
is no direct implementation association to the bean interface. The relation is in fact realised through corresponding
method signatures. Furthermore, the interface implementa-
76
Figure 5. Petri-Net of an Entity Beans Life Cycle

The other bean types are not covered explicitly, but their
similar life cycle can be derived from the given petri net. As
session beans do not contain persistent data, the load and
store transitions are omitted. Stateless session beans and
message-driven beans have no state, and therefore no need
for passivation or client assignment. Thus, the ready and
pooled places are merged, while the create and remove
transitions become unnecessary.
them frequently. Instances are dynamically shared between

clients, but associated with a single client during its business processing. On assignment, all pooled instances are
equivalent and randomly chosen.3
The EJB container makes heavy use of this concept, as
in the typical enterprise application the business layer, and
thereby the EJBs, is accessed by a large number of clients
causing a high server load. Instance pooling also helps to
significantly reduce response time, a determinant application characteristic. Furthermore, the container can adapt the
pool size to the current utilisation.
For all transitions, the container triggers according callback methods, allowing the bean object to react or prepare.
3. The Deployment Process

Also fundamental in the EJB concept, is the installation
and integration of a software package into the Application
Server. This final step in the software delivery process is
called deployment.
3 In fact this is usually realised by a first-in-first-out (FIFO) or last-infirst-out (LIFO) queue.
77
Figure 6. Deployment Overview Block Diagram

Figure 6 shows an overview of the development and deployment process. At the beginning of the work flow the
developer uses the NetWeaver Developer Studio to work
with the sources and to programme the application as usual.
Subsequently, the final output, including the class files and
several deployment descriptors, is packed into deployment
archives.
Using the built-in client of the Developer Studio, the developer is able to connect to the Software Deployment Manager (SDM) and to initiate the deployment process. The
SDM takes over the deployment archives, stores them in its
repository and starts the deployment to the targets. Within,
the WebAS there are three different targets. Namely, the
file system for static content like images, the database for
the tables, later containing the persistent data, and the J2EE
environment for the actual application.
To achieve the separation between development and deployment, two alternative SDM clients are available. The
SDM Gui is a tool to manage the whole life cycle of an application. It can upload and install deployment archives, update or uninstall an application, as well as providing useful
information about installed components. The third client,
the Deploy Tool, is necessary either when the NetWeaver
infrastructure is unavailable or for the use of third party
components, which need to be adopted for the utilisation

in the WebAS.
3.1. The Software Deployment Manager
The key role in the deployment process is played by the

Software Deployment Manager. It takes care of the installation into the WebAS and the distribution to the containers,
e.g. the Servlet, JSP, Connector or the EJB container.
If more than one physical machine realise the application
server, synchronisation of the cluster is also a major responsibility of the SDM. The used mechanisms and concepts are
described in detail in [11].
The entire deployment operation is consistent and transactional, so it is either done completely or not at all. For
its tasks, the SDM uses the messaging protocol and locking
concept of the framework.
Furthermore, the SDM maintains a repository, containing all registered deployment archives for software life cycle management.
78
Figure 7. Example of Deployment Archives
3.2. Deployment Archives
In SAP NetWeaver, there are two kinds of deployment archives. Firstly, the Software Deployment Archive
(SDA) represents the smallest deployable software unit. In
the J2EE context, this unit is called Enterprise Application Archive (EAR). Secondly, the Software Component
Archive (SCA) comprises several SDAs and forms a more
complex application consisting of several sub components.
Based upon SCAs, the SDM offers software version management. [1]
Figure 7 illustrates the content of deployment archives
using the counter bean example. The EAR contains the application parts for the presentation layer and the business
layer. The Java Server Pages presenting the counter results and other required resources like images are included
in the Web Archive (WAR). The EJB Java Archive (EJBJAR) contains all bean classes and optionally other supporting Java classes.
The database vendor independent XML4 definitions of
the persistence tables of the example are included in an extra SDA. This special archive realises the idea of a Java Dictionary, see [10] for details.
Figure 8. Deployment Layer Diagram
All archives include multiple deployment descriptors.
79
! )
#$%&'
"
!
" (
!"
3.3. Deployment Descriptors
Due to several useful services offered transparently by the

container, the application developer can focus on the actual business logic. The advanced deployment technology
and the convenient editors for deployment descriptor of the
Developer Studio come close to the idea of attribute based
programming.
Moreover, the EJB philosophy is optimised to architectures that rely on distributed objects. Thus, development
often results in reusable and extendable components, which
are open to various types of clients. Although not discussed
in this paper, the flexible concepts of EJBs also make them a
practical starting point for the use and offer of web services.
Deployment descriptors are XML files that contain serialised objects describing EJB structures, their integration
and relations. They are the linking devices for the separation of administration and development and increase the
portability of an application. Next, the most important deployment descriptors, which control the services provided
by the container, are presented.
The ejb-jar.xml configures the properties and behaviour
of the Enterprise JavaBeans. It contains the names of the interface classes and the implementing bean classes, relations
between beans and resource dependencies. It also includes
security related options, like identities, roles and access
control, as well as session related options, like timeouts,
transaction enabled methods or the stateless session flag.
In addition, it allows the setting of entity bean specifics,
e.g. aliases for JNDI lookups and the important EJBQL5 queries for the finder methods, which are translated to
JDBC6 calls during deployment. Defined in the home interface, these finder methods offer the possibility to search for
particular entities or a group of entities. For improving performance, the container provides object caching of found
entities.
Another main deployment descriptor is persistent.xml,
by which persistence of entity beans is managed. It includes
the persistent attributes of a bean class, the matching mappings to the table fields and information about the primary
keys.
Three further descriptors, web.xml, data-sourcealiases.xml and application.xml, allow the configuration of
web components and references to data sources, or setup
application wide properties. Web.xml presents another
possibility to abstract even more from bean details by
introducing symbolic names and virtual path mapping. In
application.xml for instance, the deployer can define the
application entry URL called context root.
The last set of deployment descriptors, *-j2eeengine.xml, includes J2EE and SAP specific settings, like
the application failover behaviour or the EJB instance pool
size.
The review of these deployment descriptors concludes
the brief discussion of the vital parts of EJBs.
References
[1] SAP Library - Development Manual, May 2005. From
http://help.sap.com.
[2] J. Farley, W. Crawford, and D. Flanagan. Java Enterprise in
a Nutshell. Cologne: OReilly, 2003.
[3] M. Helmich. UME: User Management & Security. 2005.
[4] E. Horn and T. Reinke. Softwarearchitektur und Softwarebauelemente. Munich: Hanser, 2002.
[5] M. Kangas. SAP Web AS - Architecture and Programming
Model. 2002.
[6] K. Kesser, P. Tillert, and P. Dobrikov. Java-Programmierung
mit dem SAP Web Application Server. Bonn: Galileo Press,
2005.
[7] R. Monson-Haefel. Enterprise JavaBeans. Sebastopol, CA:
OReilly, 1999.
[8] L. Neitsch. Enterprise JavaBeans und ihr Container. 2004.
[9] J. Nicolai. Web Services and the SAP Web AS. 2005.
[10] B. Schaeufele. J2EE-Persistenz-Mechanismen im SAP WebAS. 2005.
[11] T. Schreiter. The Clustering Concept of the SAP WebAS.
2005.
[12] D. Stollenwerk. SAP Web AS - Application Development J2EE Development. 2004.
[13] Sun Microsystems. Enterprise JavaBeans Specification,
Version 2.0, 2001.
4. Summary
Overall, Enterprise JavaBeans provide a portable and
scalable concept for building typical enterprise applications.
4 The Extensible Markup Language (XML) is a platform and vendor
independent document exchange format.
5 EJB-QL is a subset of the Structured Query Language (SQL) 2.0.
6 Java Database Connectivity (JDBC) provides uniform access to the
database layer.
80
Web Services and the SAP Web Application Server

Johannes Nicolai
johannes.nicolai@hpi.uni-potsdam.de
Section 5 focuses on the implementation of Web

Services conforming to the J2EE 1.4 standard.
Section 6 explains the differences between the
J2EE specification and the specification used by
the SAP Web Application Server while section 7
demonstrates how to implement Web Services
with the SAP Web AS. Finally, section 8
summarizes the important facts you really have
to keep in mind.
Abstract
In this paper, the term Web Service itself as the related
terms WSDL, UDDI and SOAP are described to give
an impression about the basic technologies in the field
of Web Services.
Furthermore, information will be presented how to
implement Web Services on a J2EE platform. Finally,
the paper illustrates how to modify the J2EE view on
Web Services in order to port them to the SAP Web
Application Server.
2. What are Web Services?
Keywords : Web Services, SAP Web AS, WSDL,

UDDI, SOAP, J2EE
Web Services are entities that provide an

interface for clients via HTTP or HTTPS (thus a
web based transport protocol). The clients can
exchange data with the Web Service by calling an
operation specified in the provide interface. Web
Services are typically used among business
partners to exchange important data (business to
business data exchange).
The difference between Web Services and
similar technologies like CORBA or RMI is that
the method how to
1. Introduction
The term Web Service is a typical marketing
buzz word you can read in lots of IT magazines.
Unfortunately, most articles only describe Web
Services in a way that is not sufficient to
understand how they really work.
The author of this paper assumes, that
understanding the technical details of Web
Services is essential if you really plan to work
with them and not only use the word to be part of
the hype.
Understanding Web Services means that you
have to be familiar with the important terms and
technologies that are typically used in this field.
To facilitate the learning process, all abstract
definitions are explained on a concrete Web
Service example application, which will be
implemented based on the J2EE platform and the
SAP Web Application Server.
The rest of the paper is structured as follows:
Section 2 defines what Web Services really are
and describes a typical Web Service scenario.
Section 3 introduces the sample Web Service
application. Section 4 discusses important terms
and technologies in the field of Web Services.
search a Web Service according to a specific

criteria and obtaining its interface,
calling its operation, encoding / decoding its
parameters and transporting the request to
the right location
is standardized
via protocols that
are
independent of a specific operating system,
platform, programming language, development
environment or programming model.
In
an
ideal
Web
Service
world,
communication between applications will not
require any human intervention. Figure 1
illustrates the general architecture of a Web
Service environment. At first, the Web Service
consumer uses a specific protocol to contact the
search engine for Web Services. According to its
request, the search engine browses through its
81
database and will return the address (URL) of

the Web Services that match the requested
criteria. The address and further information
about the available Web Service were published
before by the Web Service developers to the
search engine using the same protocol. Having
obtained these information, the consumer now
contacts the hosting Web Service container in
order to find out how to use the Web Service in
question. The related Web Service specification is
generated on the fly out of the provided interface
of the Web Service and the Web Service
configuration (transport protocol, data type
encoding, encryption) specified by its developer.
Next, the consumer can call its desired
operations on the Web Service via the Web
Service protocol. The request will be processed by
the Web Service protocol processor and then
forwarded to the concrete entity implementing
the functionality of the Web Service.
Database
any protocols or technologies the described

architecture relies on. The following sections will
explain these details step by step on a concrete
example.
3. ASGDeployService
The mentioned example Web Service will be the
ASGDeployService developed as a first design
prototype for the Adaptive Services Grid project
[ASG]. You may download the sources on
http:/ / m y h pi.de / ~ nicolai /
Application Server
R
ASGDeploy
Client
ASGDeploy
Service
Developer
J2EE
components
Repository
Figure 2 General architecture of the

ASGDeployService
Development files
Developer
Figure 2 illustrates the aim of the

ASGDeployService. It provides an interface
allowing every client to deploy J2EE components
on an application server, so the functionality of
the example Web Service is similar to a file
upload server.
publish
R
Search Engine
for Web
Services
search
Development Environment
request
R
Web Service
Specification
Generator
Parser
Web Service
Consumer
Virtual
Interfaces
Web Service
Configuration
Web Service
Tester
Web
Service
use
Web Service Protocol Processor
Web Service Container
Figure 1 Typical Web Service scenario

(generic version)
Finally the entity, which was deployed by the

developer in the Web Service container, will
return a result that in turn will be encoded by the
Web Service protocol processor and transported
back to the consumer where it can be evaluated.
If a developer likes to test his or her Web
Services, he or she can write a consumer or use a
more intuitive way provided by his or her
development environment and the Web Service
container. Typically, this testing interface allows
to simply specify the values for the parameters of
the Web Service operations and to graphically
analyze its result values. Furthermore, most
development environments also allow obtaining
and looking into the Web Service specification
that will be generated for the developed Web
Service.
Up to this point, this paper has not mentioned
Figure 3 Interface of the ASGDeployService
Figure 3 shows all operations, a client can call

on the ASGDeploy Web Service. As you can see,
the only important operation is deploy. The
arguments are encapsulated as Java Beans 1 to
simplify the type mapping from Java types to
types that every Web Service client can
understand. The ASGDeployParameterBean
contains the file to upload as a byte array and its
filename as a string. The returned bean contains
the result of the operation and a string providing
1 have nothing to do with Enterprise Java Beans
82
further information in case of an error.

The next section will cover how a Web Service
client can obtain the interface and the address of
this Web Service, how to call the deploy
operation and how to encode its parameters.
The section will close with an overview about
Web Service Search engines.
that the data type deploy is a complex one that

has a data field for the contents of an
ASGDeployParameterBean that in turn consists
of the file and filename data fields that are
mapped
to
the
native
WSDL
types
base64binary and string.
<types>
...
<complexType name="deploy">
<sequence>
<element name="ASGDeployParameterBean_1"
type="ASGDeployParameterBean"/>
</sequence>
</complexType>
<complexType name="ASGDeployParameterBean">
<sequence>
<element name="file" type="base64Binary"/>
<element name="filename" type="string"/>
</sequence>
</complexType>
...
</types>
4. Important terms and technologies

4.1. WSDL
A WSDL (Web Service Description language)
[WSW] document is the output produced by the
Web Service Specification generator displayed in
figure 1. It contains all information in order to
contact the required Web Service correctly. A
WSDL document is XML-based and consists of
namespace declarations, a types section, a
messages section, a port types section, a bindings
section and a services section.
Typeelement
-name
Figure 5 Types section
After having specified the needed data types

you have to think about the concrete instances of
these types you want to exchange with the Web
Service. Instances of data types are called
elements in the WSDL terminology. Elements
have a name and may underlie further
2
restrictions . Elements are also specified in the
types section.
In order to form a message, you have to group
the elements, you want to send to or receive from
a Web Service, together. A message can be a
request for an operation of the Web Service or the
corresponding result.
Element
-constraints
-name
refers to
Part
-name
specifies
1..*
references
Type
Complex Type
-name
Primitive Type
-native type
Message
-name
input
Service
-name
output
Operation
-name
-faults
Port Type
-name
<message name="ASGDeployService_deploy">
<part name="parameters" element="deploy"/>
</message>
<message
name="ASGDeployService_deployResponse">
<part name="result"
element="deployResponse"/>
</message>
publisher
Encoding
-input enc .
-output enc .
binds
determines
Port
-name
-address location
Binding
-transport protocol
-name
Figure 4 Structure of a WSDL document
To explain the meaning of these sections,

figure 4 gives an overview about the general
structure of a WSDL document.
Before you can start thinking about the
interface, your Web Service should provide, you
have to specify the data types you want to use to
send and receive the data you are interested in.
Data types in WSDL may be complex, so they can
itself consist of further data fields. Primitive types
will be mapped on standard WSDL types
understood by every client.
Figure
5
shows
a
piece
of
the
ASGDeployService types section. You can see
Figure 6 Messages section
Figure 6 shows the messages involved in the

ASGDeployService. The first message contains all
elements (parts of the message) that will be
transmitted by the client if it likes to upload a file
while the second one contains the elements to
describe the result.
Consequently, you can think about an
operation as an input and an output message and
some optional exceptions that can occur during
processing. WSDL in fact groups two messages
2 e. g. they may not be null
83
together to form an operation. Operations can

only be defined as part of a concrete interface, the
Web Service should provide. This interface is
described as a port type in WSDL.
Figure 7 illustrates how the interface (port
type ASGDeployService) is composed of the
operation deploy that groups the messages
defined in figure 6 together.
where it now can be accessed by any client

following the encoding and transport rules
defined in the ASGDeployServiceBinding.
WSDL is very complicated to understand for
beginners because it consists of many different
terms and sections. For this simple example, the
many levels of abstractions seem to be too
sophisticated. For bigger Web Services, the
complex structure of WSDL can help to reuse
certain elements. Data types, messages, port
types and even bindings may be included in
multiple WSDL documents.
<portType name="ASGDeployService">
<operation name="deploy">
<input message="ASGDeployService_deploy"/>
<output
message="ASGDeployService_deployResponse"/>
</operation>
</portType>
<service name="DeployService">
<port name="ASGDeployServicePort"
binding="ASGDeployServiceBinding">
<soap:address location="http://asgplatform.org/asg/DeployService"/>
</port>
</service>
Figure 7 Port Types section
After the interface of a Web Service is defined,

you have to clarify how the different parts of the
messages forming its operations should be
encoded and what protocol should be used by
the client to transport and call a certain operation.
These details are described in a WSDL binding
that provides all data exchange and transport
rules for a specific port type. Figure 8
demonstrates how to transport requests and
responses to the ASGDeploy Web Service via the
HTTP protocol, whereas the parts of the
messages and the operation call and response
itself are encoded using the SOAP wrapped style
(more details in the next sub section).
Figure 9 Services section
After having answered, how a client gets to

know everything about the interface of a Web
Service, the question, what protocol is used to
encode and call its operations, arises. The next
sub section will deal with this topic.
4.2. SOAP
SOAP (in earlier versions Simple Object Access
Protocol) [WSW] is a protocol to exchange
messages between systems via XML documents.
SOAP is typically used to call operations on Web
Services and to receive its result. Normally, the
communication follows the request / response
pattern illustrated in figure 10.
<binding name="ASGDeployServiceBinding"
type="ASGDeployService">
<soap:binding transport=
"http://schemas.xmlsoap.org/soap/http"/>
<operation name="deploy">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
Client side
Server side
Send message
via SOAP
request
Figure 8 Bindings section

Process SOAP
At last, you have to determine the URL where

a client should post its requests according to the
binding specification. Because a Web Service in
WSDL may have different interfaces, it consists of
different ports whereas every port declares the
address of its associated
binding. The
ASGDeployService only provides one interface
and one binding for it, thus the WSDL document
only defines one port for it.
Figure 9 shows how to publish the Web
Service with the interface described in figure 3 at
http: / / a sg- platform.org /asg / De ployService
Send SOAP
response mesage
Process result
Figure 10 Request / response pattern
After having sent the request to the Web

Service container, the client waits until the Web
Service protocol processor (see figure 1) have
84
processed the SOAP document, called the correct

operation on the Web Service that implements
the requested interface and sent back the result
(encoded as a SOAP response).
The protocol that is used to transport the
SOAP requests and responses is independent of
SOAP itself. Typically HTTP and HTTPS are used
for this purpose, while SMTP or FTP are possible
as well 3.
SOAP Attachments
-further parts
contains
SOAP envelope
-namespace declarations
contains
Otherwise, the processor has to understand

the header or must generate a SOAP failure as
response. SOAP attachments are used to
transport parts of the requested or returned
message that contain large binary data, not
suitable to be encoded to fit in an XML tag of the
SOAP body due to performance reasons.
The SOAP body either contains a message
used to call an operation of the Web Service's
interface or the corresponding response message.
If an error encounters during SOAP processing or
during execution in the implementing Web
Service, the SOAP body will contain a SOAP
failure providing additional details.
Figure 12 shows the request generated by a
Web Service consumer to call the deploy
operation of the ASGDeployService. Because the
ASGDeployService example uses the SOAP
wrapped style, where every message consists of
4
exactly one part , the SOAP body does not
contain the name of the message but the name of
its element being its only part.
SOAP Header
-optional data
-mustUnderstand
contains
SOAP Body
SOAP Request
-parameters part
SOAP Response
-result part
SOAP Failure
-reason
-detail
Figure 11 Components of a SOAP document
A SOAP document consists of the structures

illustrated in figure 11. The entire content is
enclosed in a SOAP envelope, that in turn
contains some namespace declarations, a SOAP
body and optionally some SOAP headers and
SOAP attachments. SOAP headers may contain
further information for the Web Service protocol
processor like session state, cryptographic and
compression information. These headers may be
ignored by the SOAP processor as longs as the
attribute mustUnderstand is set to false.
HTTP/1.1 200 OK
X-Powered-By: Servlet 2.4; Tomcat5.0.28/JBoss-4.0.1sp1 (build:
CVSTag=JBoss_4_0_1_SP1 date=200502160314)
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Mon, 11 Apr 2005 16:51:55 GMT
Server: Apache-Coyote/1.1
1d9
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soa
p/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance">
<soapenv:Body>
<ns1:deployResponse
xmlns:ns1="http://asgdeployservice.asgplatfor
m.org/types">
<result>
<message>Deployment was successful.</message>
<result>true</result>
</result>
</ns1:deployResponse>
</soapenv:Body>
</soapenv:Envelope>
0
POST /asgdeploy/DeployService HTTP/1.1

Content-Type: text/xml; charset=utf-8
Content-Length: 527
SOAPAction: ""
User-Agent: Java/1.4.2_05
Host: 127.0.0.1:8081
Accept: text/html, image/gif, image/jpeg, *;
q=.2, */*; q=.2
Connection: keep-alive
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/en
velope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
xmlns:enc="http://schemas.xmlsoap.org/soap/en
coding/"
xmlns:ns0="http://asgdeployservice.asgplatfor
m.org/types">
<env:Body>
<ns0:deploy>
<ASGDeployParameterBean_1>
<file>RGllcyBpc3QgZWluIFRlc3QgZvxyIEFsZXhhbmR
lciBTYWFyLg==</file>
<filename>test.txt</filename>
</ASGDeployParameterBean_1>
</ns0:deploy>
</env:Body>
</env:Envelope>
Figure 13 SOAP response over HTTP
Figure 13 shows the corresponding SOAP

response. As you can see, the client's request to
deploy the file test.txt with its content encoded
Figure 12 SOAP request over HTTP
4 There are three other SOAP encoding styles available where

a message can have more than one part.
3 but really unlikely in the field of Web Services
85
as Base64 5 was deployed successfully.

At this point, almost all questions about the
protocols used in the scenario, depicted in figure
1, are answered. The only unanswered point is
how Web Services can be published or searched
in a Web Service search engine. The next sub
section concentrates on this issue.
businessEntities are referenced by the white

pages. They contain all information about the
specific company including its name, a
description, contact addresses and links to its
web sites. Every businessEntity can publish the
Web Services it provides. For every service, one
businessService entity determines its name, its
description and its category. Its concrete interface
and its address (location where to find the
corresponding WSDL document) are stored in a
bindingTemplate entity.
The aim of tModel entities is to reuse
information required in many places. If two
services belong to the same category, they both
simply reference to the same tModel. Two Web
Services are equivalent if their bindingTemplates
reference to the same tModel. tModel entities are
very generic so that they can be used to describe
different kinds of information. They only contain
a short description and some links to further
documents describing their meaning in detail.
Ariba, Microsoft, SAP and IBM all provide
public available UDDI registry servers that are
regularly synchronized on each other. Many
companies use their own UDDI servers in their
intranets so that interfaces of internal services
may be slightly changed without further
notification to other departments.
Of course, Web Service consumer still have to
know the semantic behind the signature of the
Web Services they want to use. If the semantic of
a standardized interface is clear, a client can
search the UDDI registry according the
6
associated service type and use the obtained
Web Services without any human intervention.
The last general question is how to contact a
UDDI registry in order to search for or publish a
Web Service. The answer is simple: UDDI itself is
a Web Service with a standardized interface.
At this point, the paper has explained all basic
terms and technologies needed to understand
and work with Web Services. The following
sections focus on the implementation of Web
Services using the J2EE platform respective the
SAP Web Application Server.
4.3. UDDI
UDDI (Universal Description, Discovery and
Integration) [UDDI] is the technology used to
publish and search Web Services according
certain criteria.
Information in the UDDI registry may be present
in different languages. Companies may use UDDI
to discover the services provided by their
business partners or to inform about companies,
they like to trade with in the future. UDDI
provides three different types of pages where you
can search for required information.
The white pages can be used to search
companies by their name and category. The
yellow pages provide all information about
available Web Services categorized by industries,
products, services and locations. The green
pages contain technical information about the
Web Services in question, for example the URL
where to get the corresponding WSDL document
from the Web Service specification generator (see
figure 1).
All pages are stored within a relational
database. The entities in this database are
illustrated in figure 14.
contain
White Pages
businessEntity
-businessKey
-discoveryURLs
-name
-description
-contacts
ID
references
contain
Yellow Pages
businessService
-businessKey
-serviceKey
-name
-description
category
tModel
-tModelKey
-name
-description
-overviewDoc
references
ServiceType
contain
Green Pages
5. Web Services and J2EE
bindingTemplate
-businessKey
-serviceKey
-bindingKey
-accessPoint
-hostingRedirector
Since J2EE v. 1.4, the J2EE standard [J2EE] fully

supports as well Web Service clients as Web
Service implementations. To achieve that aim,
numerous APIs were introduced, to enable
Figure 14 Structure of an UDDI registry

5 These fields are encoded according to their types string
and base64Binary specified in the WSDL types section.
6 Some interfaces are standardized by a specific tModel key.
86
XML parsing
SOAP processing
WSDL parsing and generation
Web Service consumption
UDDI searching and publishing
If he or she likes to start with a given WSDL

document, the development environment will
automatically extract the needed information to
create a Service Endpoint Interface that can be
implemented by a Java class afterwards.
The SEI is not sufficient to generate a
complete WSDL document, because binding and
port information are still missing. These details
are specified in J2EE compliant deployment
descriptors that are included in the different
types of Java archives (.war, .jar, .ear), which are
deployed by the developer on the J2EE servers. In
the container, these descriptors will be parsed
and the obtained Web Service configuration will
be stored in a vendor- specific format.
With this concept, an archive containing a
Web Service can be deployed on every J2EE
compliant application server without any
modification. The ASGDeployService Stateless
Session Bean (packaged into a JAR file) was
deployed on JBoss, Jonas, Sun One, WebSphere
and Bea WebLogic whereas no single line of code
needed to be changed.
Unfortunately, trying to deploy the archive on
the SAP Web Application failed completely. The
following section will reveal the reasons for this
incident.
A detailed explanation of these APIs would go

too far. This section will concentrate on the
implementation of Web Services. The central
term, you really have to be familiar with, if you
like to do this using J2EE technology, is Service
Endpoint Interface (SEI) or Virtual Interface.
A Service Endpoint Interface is the interface that
a J2EE Web Service will provide to its clients.
Thus, a SEI is a kind of Java-based specification of
a WSDL port type (remember figure 4).
In a J2EE container, a Stateless Session Bean or
an ordinary Java class has to implement this
interface; they are candidates for Service
Endpoints. Because the concrete implementation
will run in a J2EE environment, ordinary classes
will be automatically transformed to Servlets by
the hosting J2EE container. Every request to the
Web Service will be forwarded to the Servlet or
the Stateless Session Bean. The whole concept is
illustrated in figure 15. As you can see, the figure
is similar to figure 1, but the generic terms have
been replaced by the concrete protocols and
technologies described in section 4.
UDDI
Database
WSDL files
Java Classes
Developer
6. J2EE and the SAP Web AS

The current version of the SAP Web Application
Server (version 6.40) claims to be J2EE 1.3
compatible and to support some features of the
J2EE 1.4 standard like Web Services [SWA]. This
statement is not incorrect at all, but it does not
clarify a very important point:
The SAP Web AS Web As 6.40 does not
support J2EE 1.4 compatible Web Service
archives but provides similar functionality with
the help of proprietary SAP-specific deployment
descriptors. As a consequence, Web Services
created within the SAP NetWeaver Development
Studio for the SAP Web AS will not run in a J2EE
1.4 compatible application server and vice versa.
As a consequence, the SAP-specific archive of the
ASGDeployService differs in many points from
the generic one. Even simple .war and .jar
archives that contain J2EE compliant Servlets or
Enterprise Java Beans cannot be deployed
directly. They have to be prepared by a SAPspecific
tool
named
Deploy
Tool.
Unfortunately, this tool was not able to transform
the J2EE compliant Web Service deployment
descriptors to SAP-specific ones.
Deployment
descriptors
publish WSDL
(SOAP)
R
UDDI Registry
Server
search
(SOAP)
Development Environment
request
WSDL
R
WSDL
Generator
XML Parser
Web Service
Consumer
use
(SOAP)
Virtual
Interfaces
Web Service
Configuration
Web Service
Tester
Stateless
Session
Bean
or
Servlet
R
R
SOAP Processing
J2EE Application Server
Figure 15 Typical Web Service scenario

(J2EE-specific version)
In a J2EE environment, a developer can start

with a Java class or a given WSDL document if he
or she likes to implement a Web Service. If he or
she starts with a Java class (ordinary or Stateless
Session Bean), its implemented interface will
become the SEI / Virtual Interface provided by
the created Web Service. In this case, the WSDL
documented will be generated by the container.
87
Of course, Web Services deployed into a SAP

application server can be used by J2EE compliant
clients
and
vice versa,
because
SAP's
7
implementation follows the WS I standard . Up
to now it is unclear, when SAP will try to support
the J2EE compliant deployment descriptors.
If you plan to develop Web Services for the
SAP Web AS, the next section gives you an
overview about the basic concepts.
except this point, the both terms are equivalent.

Every Virtual Interface can have multiple Web
Service definition artifacts. Here you can specify,
if the Web Service should be operated stateful or
stateless, which operations require further
authentification (via J2EE security roles) and if
and how the Web Service should use encryption.
Web Service deployment descriptors reference
a certain Web Service definition artifact and can
contain multiple Web Service Configuration
artifacts. Web Service Configuration artifacts are
used to determine the encoding and transport
protocol, further security settings and the
concrete URL to contact the deployed Web
Service by its consumers. Out of a Web Service
Configuration, the Developer Studio will create
the corresponding WSDL document with its five
sections (remember figure 4).
Being informed about the meaning of these
artifacts, creating Web Services with the SAP
NetWeaver Development Studio is a really
straight forward process. Figure 17 shows the
necessary steps. After having written the Stateless
Session Bean or ordinary Java class, you have to
create the mentioned artifacts in order of
appearance in this paper. For every step, a
graphical wizard in the Developer Studio will
assist you, so that you really cannot do anything
wrong [SWAH].
7. Creating Web Services with SAP

NetWeaver Developer Studio
As already stated in the last section, the SAP Web
As 6.40 is not J2EE 1.4 compatible and therefore
does not provide J2EE compliant Web Services.
However, the process to implement Web Services
is almost the same. Figure 16 gives you an
impression about the artifacts you need to create
within the SAP NetWeaver Developer Studio in
order to implement a Web Service.
Service Endpoint
Stateless
Session Bean
Java Class
provides
Virtual Interface
-selected methods
-default parameters
attributes
W eb Service
Deploym ent Descriptor
deploys
W eb Service Definition
-session mode
-authentification method
-security roles
-encryption mode
Java class
publishes
W eb Service C onfiguration
-transport binding
-W SDL port name
-target server address
results in
-further security settings
Create the
Java Clas
Generated W SD L
-types
-messages
-port types
-bindings
-service
Figure 16 artifacts needed to build a Web

Service with SAP Web AS
EJB
Create the
Stateless
Session Bean
Create virtual interface

Create W eb Service Definition
Create W eb Service Deployment Descriptor
Create W eb Service Configuration
Again, the central term is the Service Endpoint

Interface (SAP prefers the term Virtual Interface)
that can be implemented by a Stateless Session
Bean or an ordinary Java class and will become
the interface, clients will use to exchange data
with the Web Service. Thus, Stateless Session
Beans or ordinary Java classes can act as Service
Endpoints like before in the J2EE 1.4 standard.
There is a subtle difference between a SEI in
J2EE and a Virtual Interface. For Virtual
Interfaces, you can set some parameters in the
signatures of the provided operations to default
values, the client is not allowed to change, but
Java class
EJB
Generate JAR
Generate EAR
Add to EA project
Generate EAR
Deploy EAR to J2EE server
Figure 17 Process to create a Web Service

with the NetWeaver Development Studio
If you have finished to create your Web

Service Configuration artifacts and started with
an ordinary Java class as Service Endpoint, you
7 standard [WSI] that determines what features of WSDL and

SOAP should be used in order to be compatible
88
can directly create an Enterprise Application

Archive (EAR) with NetWeaver's help and
deploy it to the application server. If your Service
Endpoint is a Stateless Session Bean, you first
have to create a Java Archive (JAR) that then can
be added to a NetWeaver Enterprise Application
(EA) project. Enterprise Application projects can
in turn be packaged into an EAR and finally
deployed to the server.
In any case, the generated EAR will contain all
SAP-specific deployment descriptors that will be
stored along with the Virtual Interfaces in order
to create WSDL documents for the deployed
Service Endpoints on the fly. Ordinary Java
classes will be transformed to Servlets by
NetWeaver as well. Consequently, the J2EEspecific Web Service scenario, illustrated in figure
15, also applies to the SAP Web Application
Server 6.40.
However, two differences will remain: the
format of the deployment descriptors is not
compatible at all and there is no way to generate
a Virtual Interface out of a given WSDL
document with NetWeaver's help while this
process is common in J2EE v. 1.4 compliant
development environments. Hopefully, the SAP
Web AS and the NetWeaver Developer Studio
will adapt to this standard in the nearer future.
White pages present basic facts about the

registered companies, yellow pages focus on
the categorization and explanation of their Web
Services and green pages contain the technical
information needed to retrieve the corresponding
WSDL documents.
J2EE supports portable Web Service creation
and consumption since version 1.4. Stateless
Session Beans and ordinary Java classes can act as
Service Endpoints that implement Service
Endpoint Interfaces, which in turn will become
the interfaces provided by the resulting J2EE Web
Services. Detailed configuration of these Web
Services is done via vendor- independent
deployment descriptors contained in the related
Java archives.
The SAP Web Application Server 6.40 cannot
handle J2EE 1.4 compliant Web Service
deployment descriptors but provides similar
functionalities based on similar concepts.
However, automatic generation of Service
Endpoint Interfaces out of given WSDL
documents (common for J2EE compliant
development environments) is not supported by
SAP NetWeaver Developer Studio yet.
References
[ASG] Adaptive Services Grid Network, http://asgplatform.org
[J2EE] The J2EE 1.4 standard, http://java.sun.com
[JABW] Michael Girdley, Rob Woolen and Sandra L.
Emerson, J2EE Applications and BEA WebLogic
Server. Prentice Hall, 2003
[JWSA] Dapeng Wang, Thomas Bayer, Thilo Frotscher and
Marc Teufel, Java Web Services mit Apache Axis.
Software & Support Verlag, 2004
[MWS] Robert Taylor, Microsoft .NET XML Web Services.
SAMS, 2001
[PSW] Karl Kessler, Peter Tillert and Panayot Dobrikov,
Java Programmierung mit dem SAP Web Application
Server. SAP Press, 2005
[SSM] Seminar System Modeling,
http://wendtstud1.hpi.uni-potsdam.de/sysmod-seminar/
[SWA] Official information about the SAP Web AS,
http://www.sap.com/
[SWAH] Useful hints regarding the SAP Web AS,
[UDDI] Official information about UDDI,
http://www.uddi.org
[WSI] Official information about the WS -I standard,
http://www.ws-i.org
[WSW] Official information about Web Services, Soap and
WSDL, http://www.w3.org/2002/ws/Activity
8. Summary
This paper has given an overview about Web
Services and its basic related terms and
technologies. Web Services are entities that
provide an interface called by clients to exchange
(business) data over the web via open and
accepted standards independent of operating
system, programming language, programming
model and development platform.
The structure of its interfaces, the encoding of
the parameters of its operations, the protocols
used to transport operation requests and
responses and the concrete contact URL are
determined by a WSDL (Web Service Description
Language) document. The protocol used to
encode request and response messages to and
from an operation of a Web Service is SOAP.
Both WSDL and SOAP are XML-based protocols.
Web Services can be published and searched for
according certain criteria through an UDDI
(Universal
Description,
Discovery
and
Integration) registry server that acts as a Web
Service itself. UDDI provides three different
types of pages to structure its information.
89
90
Apache Struts Technology

Daniel Rinser
daniel.rinser@hpi.uni-potsdam.de
Abstract
aims to be a fundament for well-structured Java

web applications by implementing the ModelView-Controller design pattern.
Generally, each web application can be
separated into two different key components: On
the one hand, there are the application data and
the business logic performed on this data. On the
other hand, there is the presentation of parts of
the application data to the user in an appropriate
form. In order to build a well-structured web
application, these two components should be
strictly separated. The Struts framework
constitutes a basis for web applications that
ensures this separation, but also provides a
controlling component to couple them loosely.
Web applications are becoming more and more

important, because of their flexibility and
independency from client software. In this context,
Java web applications and especially the J2EE
architecture have become very popular.
This paper introduces the Apache Struts
framework, which helps to build better structured and
thus very good maintainable Java web applications by
having the Model-View-Controller design pattern
being implemented. In order to give the reader a short
introduction, standard Java web application techniques
are outlined and the MVC pattern is described in
short.
After the over-all Struts architecture has been
depicted, the individual components of a Struts web
application will be explained in detail, with Controller,
View and Model components being separated. To sum
up the gained insights, the applications control flow
when processing a typical request will be illustrated
with the help of a diagram.
Finally, section 8 will present two additional
features provided by Struts and the frameworks
benefits and possible restrictions will be outlined in the
final conclusion.
1.1. Traditional Java web applications

As the Struts framework is completely based on
standard Java web application technologies, it is
necessary to have a look at them first.
Traditionally, there are four ways to produce
dynamic output (which is usually HTML, but can
be just as well XML or any other markup
language) in Java web applications.
Servlets are Java classes that provide some
special request processing methods such as
doGet() and doPost(). An example of creating
dynamic output with the help of Servlets would
be: out.println("<H1>" + myStr + "</H1>");
This example demonstrates, that there is no
separation between Java code and presentation
elements, which may confuse web designers as
well as it renders maintenance almost impossible.
Java Server Pages (JSPs) ameliorate this
situation a little, but still do not separate Java
from presentation code, as they promote
embedding Java code (so called Scriptlets) into
the presentation code. The above example would
be implemented as follows:
Keywords: Java, web application, J2EE, MVC,

internationalization, XML
1. Introduction
As web applications in an enterprise environment
may become very large and complex, there is a
need for structuring these applications. This can
be done by separating different components of
the application to increase its maintainability and
extendibility.
The Struts framework, which has been initially
developed by Craig R. McClanahan and is now
under the auspices of the Apache Software
Foundation (ASF), is an open-source project that
<H1><% out.println(myStr); %></H1>
Later on, JSPs have been extended by so called
91
2.1. The Model
tag libraries, which aim to ban Java code from

JSPs. A standard set of tag libraries has been
assembled in the JSTL1. To demonstrate this, let us
look at the above example implemented with the
help of a JSP using the JSTL:
The Model holds the application data and the

business logic performed on this data. The
general idea is, that the Model is absolutely
independent from the user interfaces (that is, the
View), as well as the user interfaces are not
dependent
on
the
Models
internal
implementation. This way, modifications in the
Views do not affect the Model implementation.
<H1><c:out value="${myBean.myStr}"/></H1>
This
solution
increases
readability
and
maintainability, but the interaction with Beans
turns out to be somewhat complicated.
The forth approach combines the advantages
of JSPs with the flexibility of Servlets, by letting
the request be processed by a Servlet which then
passes the request to a JSP to render the output.
This last approach is one of the ideas Struts is
based on. Instead of having to redesign this
forwarding in every Servlet/JSP combination, the
use of a comprehensive framework such as Struts
provides a centralized ready-to-use solution for
this problem and of course addresses many
other issues.
2.2. The View

The View is responsible for presenting relevant
parts of the Model to the user, so it is the
component that the user actually sees. In order
to do that, the View components may query the
Model for the appropriate application data to be
displayed to the user. As the Model should not
depend on the View presenting it, it is perfectly
possible to have more than one View presenting
the same Model data (e.g. web client, rich client
etc.). In fact, this is one of the main advantages of
MVC-based applications.
2. The Model View-Controller

Design Pattern
Struts is based on the J2EE blue print for Java,
which heavily promotes the MVC architecture
[WTAFD]. Thus, the Model-View-Controller
design pattern builds the foundation of the Struts
framework, and will be depicted in short at this
point. In its most general form, the MVC pattern
arose from Smalltalk-80, in which it was used to
design applications that interacted with the user.2
2.3. The Controller

The Controller can be considered the bridge
between Model and View, as it interconnects
them. The Controllers main task is to control the
application flow. It receives and interprets the
users input, performs the requested actions
(which most often results in invoking business
logic on the Model) and finally triggers a View
update.
In the traditional MVC design it is possible
and actually very common to let the Model
trigger a View update through an event.
Nevertheless, this case is not considered here, as
the HTTP protocol is request-response based and
consequently the View (that is, the response page)
can not be updated without the user having sent a
request.
change state
Controller
user
request
Model
trigger
view update
business
logic
application
data
View
response
to user
query state
Figure 1 The Model-View-Controller architecture
As its name suggests, MVC splits up

responsibilities for handling user interactions in
an application into three tiers: the Model, the
View and the Controller, as shown in figure 1.
Their roles and the interaction between them are
subject of the following paragraphs.
2.4. Benefits
As the MVC pattern separates these three areas of
concern, its use increases maintainability and
testability of applications, simplifies the creation
of new kinds of user interfaces and finally helps
dividing tasks in the development process. Thus,
the Model-View-Controller pattern has been
adopted for the use in many different
environments, such as web applications.
JSP Standard Tag Library

The MVC architecture presented here is a slightly modified
variation of the MVC (see 2.3), sometimes referred to as the
Model 2 architecture of a web application.
1
2
92
WAR
EAR
JSPs
Java classes
TagLibs
libraries
EJB classes
struts-config.xml
Home interface
Struts libraries
static data (HTML, img.)
EJB deployment descr.
web.xml
Struts config objects for...

action-mappings
forwards
plug-ins
form-beans
message-resources
other config
Controller
Action
Servlet
form
data
ActionForm
R
forward
EJB
JavaBean
state
JavaBean
to DBMS
EJB
View
JSP
EJB-Container
HTTP
Web-Container
HTTP-Server
Browser
Action
Struts TagLibs
JavaBean
state
Resources
Client-Tier
Web-Tier
external libraries
configuration
log data
Business-Tier
Figure 2 The over-all architecture of the Struts framework and its surrounding components
The following sections will focus on the

runtime presentation of the different Struts
objects as enclosed by the web container in the
above diagram.
3. The architecture of the Struts

framework
We will now have a look at the architecture of the
Struts framework and its surrounding elements
shown in figure 2, before in the following sections
the different components of a Struts application
will be explained in detail. The above diagram
also illustrates the division of a Struts application
into the three abovementioned MVC layers.
In order to access a web page, the client,
shown on the left hand-side, communicates with
the web container via a HTTP-server. The web
container sets up the runtime objects by getting
the static web application data from a WAR3-file,
which may include Java classes, JSPs, libraries,
Struts specific data and static content such as
images and plain HTML. In the business tier there
may live an EJB container backended by a DBMS
to ensure data persistency.
3
4. Controller components
The Struts Controller is built up by three
components: the ActionServlet, which is the central
controlling unit, usually many Action classes that
perform the actual processing logic and possibly
one or more ActionForms, a Struts internal
representation of web forms.
4.1. The ActionServlet

The ActionServlet, which resides in the Controller
of the Struts framework, can be considered the
central component in a Struts application. It is the
place where every request sent to the web
application starts to be handled. Thus, the
ActionServlet represents a so called Single Point
of Entry of the application, which is often referred
to as the Front Controller Pattern (see [FCP]).
web application archive
93
configuration file request paths are mapped to

specific Action classes. Moreover, in the actionmapping section there may be defined forwards
that tell the ActionServlet which View component
should be triggered to create the response page.
The ActionServlet controls the flow within a

Struts application. It receives a users request
through the surrounding web container and
decides how to react to the request, determining
the Action class that is responsible for processing
it. After the Action class has finished its work, the
ActionServlet forwards to an appropriate View
component that will create the output which will
then be sent back to the user as a response to the
given request.
In every Struts web application there exists
exactly one instance of the ActionServlet, so it is
the place where web application wide concerns
such as logging and initialization are attended.
To understand the architecture of the Struts
framework, it is important to know that the
ActionServlet is implemented as a common Java
Servlet class. Usually the requests to a Struts
application are suffixed by .do to clearly separate
them from non-Struts requests. This way, the
integration (that is, the deployment) of the Struts
application into the surrounding web container is
simply done by listing the ActionServlet in the
web applications deployment descriptor for
handling this type of requests (e.g. *.do).
As mentioned above, the ActionServlet is a
standard Java Servlet class. Thus, and due to the
fact that Struts is an open-source project, for the
few cases in which the functionality provided by
the ActionServlet shipped with Struts is not able
to meet the demands of a certain purpose, it is
perfectly possible to extend and customize the
standard ActionServlet to satisfy the custom
requirements.
<struts-config>
<! [...] -->
<action-mappings>
<action path="/login"
type="app.LoginAction"
name="app.LoginForm">
<forward name="failure"
path="/login.jsp" />
<forward name="success"
path="/welcome.jsp" />
</action>
</action-mappings>
<! [...] -->
</struts-config>
Listing 1 An action mapping in the struts-config.xml
To clarify this, let us have a look at listing 1,

which shows a possible action mapping in a login
application.
The path attribute of the <action> tag
represents the application-relative request path
(without .do), which in this case is mapped to an
Action class (see below) named LoginAction,
whereas the name attribute points to the
responsible ActionForm (see 4.3). The two
enclosed <forward> declarations tell the
ActionServlet which View component should be
triggered to create the response, depending on the
Action class return value.
4.1.1. struts-config.xml
4.2. Actions
In order to fully understand how the

ActionServlet works, it is advisable to have a look
at the Struts main configuration file named
struts-config.xml.
This configuration file lays the foundation for
the operation of a Struts application and can thus
be considered a Struts applications internal
deployment descriptor. It is interpreted at
initialization time by the ActionServlet, which
instantiates the corresponding configuration objects
(see figure 2), which are used during further
execution.
Most global options are defined in this file.
Apart from plug-in integration, form-bean (see
4.3) and global forward definitions, among others,
especially the so called action mappings are done
here. As the name may suggest, in this part of the
Actions are Java classes that process a certain

request to the Struts application, performing logic
to carry out the requested action(s) such as
checking if a submitted username and password
are correct.
In contrast to the ActionServlet, which is
usually used as is and which is a web application
wide singleton, the Action classes used within a
custom Struts application are not shipped with
Struts, but must rather be developed for a specific
application. However, the Struts framework
includes an abstract Action class, which offers
some basic functionality and has to be extended
by all concrete Action classes used within the
application.
94
lifetime and visibility they should have.

Apart from their validating features (see 4.3.1),
ActionForms become especially interesting when
they are used to build multi-page forms. For
instance, these can be wizard-like forms that are
spread over more than one web page, but
semantically belong together. In this case, it is
possible to unite these HTML forms in one
ActionForm,
which
helps
increasing
maintainability as the page designers may
rearrange the form fields among the different
pages without requiring changes to the
underlying processing logic [ASFS].
As one can easily imagine, defining
ActionForms for forms with a great amount of
fields can become an annoying job. For this case,
the so called DynaActionForms have been
introduced allowing ActionForm specifications to
be done in XML. The concrete ActionForms will
then be automatically created at initialization
time. However, DynaActionForms underlie some
restrictions, as described in [ASFS].
To build our login example, we would create
an ActionForm with two string attributes
username
and
password
and
the
corresponding getter/setter methods. Moreover
we will have to map the ActionForm in the
struts-config.xml as shown in listing 1. Now
we would be able to easily access the form values
in the Action class through the ActionForm.
Annotation: While ActionForms have many
characteristics of JavaBeans and thus sometimes
are counted among the Model components, they
should be considered a Controller component,
because as such they are able to transfer data
between the Model and the View. [ASFS]
As mentioned above, the appropriate Action

class for handling a request is determined by the
ActionServlet from the action mapping in the
struts-config.xml. The ActionServlet calls the
execute() method that has to be provided by
every Action class and in which the request
processing is done. Depending on the type of
action to be performed, the Action class can either
do that directly (in case of non-complex actions;
especially actions, that do not involve business
logic) or call one or more methods in the Model
that perform the actual business logic.
Apart from actually performing the necessary
actions, every Action class has to return an
ActionForward object back to the ActionServlet
from which the ActionServlet can decide which
View component should create the response. The
ActionForward objects represent uniquely named
forward declarations that are listed in the
struts-config.xml (see 4.2).
So, in our login example, the Action class will
probably call a business logic method to validate
the username and password and, depending on
its result, will return either a success or a
failure ActionForward.
4.3. ActionForms
Apart from the common Controller components
that are necessary to process a users request,
Struts offers an additional feature concerning
request handling - the ActionForms, often called
form beans.
Principally, ActionForms represent the data
stored in HTML forms by providing attributes
holding the state of the form and getter and setter
methods to access them. In the ActionForm, there
must be an equally named attribute for each filed
in the HTML form.
Similar to the Action classes, there is only one
general abstract ActionForm class shipped with
Struts, which must be extended in order to build
custom ActionForms. When a request containing
form data is received by the ActionServlet, it fills
the corresponding ActionForm with this data
before invoking any Action classes. Thus, the
Action class can easily access the submitted form
data through the ActionForm. The actual
mapping between HTML forms and ActionForms
is done in the struts-config.xml (see 4.2).
Similar to JavaBeans, ActionForms can be
stored in different scopes (see 6), which may be
either session or request scope, depending on the
4.3.1. Validating user input

Almost every bigger web application uses a great
number of HTML forms to enable the user to
submit different kinds of data. In order to
guarantee a faultless operation of the web
application, all the form data has to be validated
before it can be processed. Implementing this
low-level validation is a very time-consuming job.
The Struts framework provides two options to
automatically validate user input. That is, as we
have seen above, the data stored in ActionForms.
Both approaches have in common, that this
validation is done before any Action classes are
invoked. Obviously, at this point there can only
be done a structural validation, e.g. concerning the
length or range of input data. It is not the
95
login application. Listing 2 shows the source code

of a very simple JSP representing the login form.
validators job to do business logic validation

such as checking username and password!
In case of errors found during the validation
process, the request is not forwarded at all to the
Action class, but rather the previous page
containing the form is sent back to the user, to
give him the chance to correct his input.
Additionally, at this point it is possible to
automatically include messages describing the
occurred errors. Correctly filled out fields are
preallocated with the provided data.
The first option to validate user input is to
provide a validate() method in the ActionForm.
This method should check if the ActionForms
attributes hold structurally correct data. If there
are no problems, this method should return null,
otherwise an ActionErrors object containing the
errors
occurred
during
validation.
The
validate() method is called by the ActionServlet
right after the ActionForm has been filled with the
form data.
The second approach, which is surely more
suitable for larger web forms, but is not as
flexible, uses the Jakarta Commons Validator
[JCV] to validate the form data. Struts provides a
plug-in that facilitates the interaction with the
Commons Validator, which is a rule-based
validation tool. Rules are defined in XML and can
describe certain constraints for each field in the
form, such as minimum/maximum length,
required fields, correct URL/email format etc.
<%@ prefix="html" uri="/WEB-INF/

struts-html.tld" %>
<html>
<body>
<html:errors/>
<html:form action="login.do">
Username:
<html:text property="username"/>
<br/>Password:
<html:password property="passwd"
redisplay="false"/>
<br/>
<html:submit>Login</html:submit>
</html:form>
</body>
</html>
Listing 2 The source code of the login JSP
The first line includes one of the Struts tag

libraries for further use in the JSP. The actual form
is built with the help of the <html:form> tag and
other tags representing the form elements. The
main reason why it is convenient to make use of
the Struts tags instead of plain HTML tags is the
abovementioned interaction with the ActionForm.
This way, there is no need to preallocate the form
fields with the help of confusing statements like
value="<%= loginBean.getUsername(); %>",
but this is rather handled automatically by the
Struts tags. Moreover, in this example we could
for instance define a validation rule to ensure that
the username is at least 8 characters long. In case
of disregard of this rule, the <html:errors> tag
would be replaced by the provided error
message. The resulting page in such a case is
shown in Figure 3.4
5. The View
The View component in a Struts web application
is usually built of standard Java Server Pages
(JSPs) in conjunction with a set of tag libraries
provided by the Struts framework. However, JSPs
as the default Struts View component can be
replaced or extended by other techniques such as
the Velocity Template Engine [VTE], which can
very easily be integrated into the Struts
framework. Nevertheless, this text will only
consider JSPs and the Struts tag libraries as this is
the most common approach.
The Struts tag libraries aim to simplify the
development of Views using JSPs by providing
standardized access to Model data, enabling the
interaction with ActionForms and providing
simple structural logic such as iteration, among
others.
To understand the use of the Struts tag
libraries we will again have a look at the sample
Figure 3 Screenshot of the produced login form

including a validation error message
4 To increase clearness, the design of the form shown in this
screenshot has been improved
96
6. The Model
Beans. In any case, EJBs should never be tied to

the use in a web environment. In fact they should
not even know about the type of environment
they are used in to ensure their portability.
As mentioned above, the Model in a web

application holds the application data and the
corresponding business logic. In fact, the Struts
framework does not directly provide any tools to
build Model components, but rather falls back on
existing approaches such as JavaBeans and for
use in larger applications - Enterprise JavaBeans
(EJBs). As these are not Struts specific, they will
not be subject of this paper. Nevertheless, they
should be mentioned in short.
JavaBeans are reusable Java components with
a standardized interface, as they follow certain
naming conventions. JavaBeans are not tied to the
web application context, but when used there,
they reside in the web container and may be
stored in different types of collections, so called
scopes. The scope in which a JavaBean is stored
defines its lifetime, visibility and accessibility.
Enterprise JavaBeans are standardized, often
distributed components in a J2EE environment,
and as such reside in the EJB container of a J2EE
server. There are three different types of EJBs:
Entity Beans, Session Beans and Message Driven
Client
Web-Container
7. Control Flow of a Struts

application
Now that we have examined the different Struts
components in detail, let us sum up by having a
look again at their interaction. Figure 4 shows the
typical control flow of a Struts web application
when processing a request.
The web container receives the request sent by
the client and looks up the responsible Servlet,
which in a Struts application will be the
ActionServlet, in its deployment descriptor. The
ActionServlet first detects, if there is form data in
the request, and if so, it either retrieves an existing
instance of the corresponding ActionForm, or
creates a new one. The ActionForm is resetted
before it gets filled with the form data and stored
in the desired scope. If the ActionForm provides a
validate() method, validation is invoked by the
ActionServlet
ActionForm
Action Class
JSP (View)
send request (.do)

lookup Servlet (web.xml)
no form in
request
else
create/retrieve AF
reset()
fill AF with form data
store AF in scope
validate()
validate() returned ActionErrors
else
create/retrieve appr. Action Class
recreate last view

execute()
forward to appr. JSP

create response
send response
display response
Figure 4 The typical control flow of a Struts web application when processing a request
97
ActionServlet.5 In case of validation errors, the

previous page that caused the errors is sent to the
user again. Otherwise the ActionServlet now
identifies the correct Action class responsible for
processing the request and calls its execute()
method, in which the actual request processing is
done. The Action class finishes its work by
returning an ActionForward object telling the
ActionServlet which JSP shall create the response
page. This JSP is now triggered and the response
is sent back to the user through the web container.
These are files containing collections of text

resources to be used within the View components
of the application. These text resources can be
considered named strings - e.g. the title of a
certain web page or a welcome message - that can
be referenced within the JSPs. This way, JSPs are
freed from static and thus language-dependent text.
To localize the web application, the developers
simply have to contribute additional resource
bundles containing all the text in another
language. The Struts framework automatically
detects the users preferred language through the
HTTP request and uses the appropriate resource
bundle.
Moreover, entities like validator rules can be
localized in a similar way to support the different
local characteristics, such as different date
formats.
8. Additional Features
The Struts framework offers some additional
features to simplify the development process of
Java web applications. Two of them are
particularly interesting and worth to be
mentioned: Tiles, a Struts plug-in that simplifies
the development of bigger composed web pages,
and Struts internationalization support.
9. Conclusion
8.1. Tiles
After the Struts framework has now been

introduced, let us summarize why Struts can be
so useful.
Most importantly, Struts structurally separates
data presentation from business logic. This results
in easy separation of different development tasks
and
increases
the
maintainability
and
extendibility of the web application. Moreover,
Struts provides a Controller that, among others,
centralizes the flow control and abstracts from
hard coded file names by providing forwards,
while ActionForms dramatically simplify the
maintenance of web forms.
Internationalization has been excellently
implemented
into
Struts,
which
makes
localization very easy and saves lots of
development efforts.
As Struts is completely based on standard Java
technologies such as JSPs, Servlets and JavaBeans,
it is absolutely portable across any kind of Java
web container.
Last but not least, Struts is an open-source
project with a very vivid developer community,
which
makes
its
use
affordable,
cuts
dependencies from external companies and adds
robustness to the application due to freely
accessible source code.
Nevertheless, Struts is surely not suitable for
every kind of web application, especially not for
very small projects, because it can cause a lot of
overhead and it may take time till the developers
Tiles is a powerful templating engine that allows

building complex web pages by combining
various rectangular page components (so called
tiles). This way, those page components can be
easily reused throughout the View of the web
application. For the use in JSPs Struts brings along
a Tiles tag library. For instance, including a subpage into a page may be done with the help of the
following tag:
<tiles:insert attribute="title"/>.
The mapping between the tiles is done in a global
XML file.
8.2. Internationalization
One of the great benefits of web-based
applications is their global accessibility. Thus, in a
more and more globalized world with globally
accessible web sites, there is a strong need for
localized web applications. But localizing web
applications can be a very monotonous and timeconsuming job.
From the beginning Struts has been designed
to offer easy solutions for internationalization
issues (often abbreviated as i18n). A central
component for this internationalization support is
constituted from the so called resource bundles.
5 In this simplified scenario, the possible use of the Commons
Validator is not considered.
98
[ST80MVC] Smalltalk-80: How to use MVC,

http://st-www.cs.uiuc.edu/users/smarch/stdocs/mvc.html
familiarized themselves with Struts. But, as we

have seen, especially large enterprise applications
can benefit a lot from the use of the Struts
framework.
[FCP] Core J2EE Patterns - Front Controller,

http://java.sun.com/blueprints/corej2eepatterns/
Patterns/FrontController.html
References
[WTAFD] Sun J2EE Guidelines: Web-Tier Application

Framework Design,
http://java.sun.com/blueprints/guidelines/design
ing_enterprise_applications_2e/web-tier/webtier5.html
[ASFS] Official Struts documentation by the ASF,

http://struts.apache.org
[JSL2004] Richard Hightower, Jakarta Struts Live.
SourceBeat, 2004
[JCV] Official Jakarta Commons Validator Website,

http://jakarta.apache.org/commons/validator/
[PJS2004] James Goodwill, Richard Hightower,

Professional Jakarta Struts. Wiley, 2004
[VTE] Official Velocity Template Engine Website,

http://jakarta.apache.org/velocity/
[SIA2003] Ted Husted et. al., Struts In Action. Manning,

2003
[MVC] The Model-View-Controller Pattern by Sun,
http://java.sun.com/blueprints/patterns/MVCdetailed.html
99
100
SAP Web Dynpro Overview

Andreas Fahle
andreas.fahle@hpi.uni-potsdam.de
proprietary frontend application called SAP GUI.

In contrast, Web Dynpro UIs can be rendered in
non-proprietary,
ubiquitous
frontends,
particularly web browsers, employing dynamic
web technology like JavaScript. Thus, Web
Dynpro is aimed to combine high interactivity
(i.e. a dynamic UI) with zero installation (i.e. an
ubiquitous UI). [2]
Abstract
SAP Web Dynpro is a framework for developing user
interfaces for use with the SAP NetWeaver platform. It
comes with design tools that are part of the NetWeaver
developer studio, enabling developers to do most of the
programming in a graphical or declarative manner.
Web Dynpro applications can run on different
platforms, including Java, ABAP, and .NET.
Component-orientation supports reusability of user
interfaces.
The concepts covered in this article allow a
separation of layout and logics, and ease the
integration of different backends. Using contexts and
models, data may be synchronized automatically
between the user interface and the backend.
Besides discussion of basic concepts and a glance at
the development process, this article briefly illustrates
the client-driven execution of a Web Dynpro
application.
Keywords: Web
Interfaces
Dynpro,
NetWeaver,
1.2. Objectives and approaches

The Web Dynpro framework has been developed
to achieve some characteristic design goals, so
there is a bunch of technical approaches that
directly address those design goals. [2]
First of all, developers should be able to build
as much as possible without procedural
programming, according to the slogan minimize
coding, maximize design. The NetWeaver
Developer Studio offers facilities for graphical
and declarative programming here, where much
of the code is generated.
Another objective affecting the development
process is separation of layout and logics. This is
achieved through the view and controller
concepts: views can be equipped with controls
and navigation plugs independently of actual
data bindings and event handlers, which are put
into a view controller.
In order to support arbitrary backends, Web
Dynpro uses so-called models as an interface to
the functionality of backends. Currently, models
for JavaBeans, ABAP, and Web Services are
supported.
Applications should run on multiple platforms,
in terms of the program processor at the
presentation server side. Java, ABAP, and .NET
are suitable runtime environments at present.
Web Dynpro is aimed to be a high fidelity web
UI, which comprises flexible client-side solutions
as
well
as
accessibility
features
and
internationalization. Basically, there are three
User
1. Introduction
1.1. What is Web Dynpro?
Web Dynpro is a framework for development of
user interfaces (UIs) for use with SAP NetWeaver.
It supports programming for different platforms,
including Java, ABAP, and .NET. For Java
programming, Web Dynpro comes with extensive
design tools, which are based upon the Eclipse
framework and part of SAPs NetWeaver
Developer Studio.
The product name has a historical background:
SAPs legacy product lines, starting from the R/2
system, include a technology for interactive UIs
called Dynpro, an abbreviation for dynamic
program. Dynpro UIs are described in the ABAP
programming language and rendered in a
101
view
EmployeeForm
control
to the
backend
component
EmployeeBaseDataEditor
"model manager"
view controller
of EmployeeForm
component
controller
control
"name" text field
context
context
model class
Employee
control property
text
context element
employee/name
context element
employee/name
model property
"name" attribute
control property
context element
context element
model property
model
Human Ressources
Figure 1 Simple example
types of client platforms:
2.1.1. View
JavaScript-capable web browsers (up from

Internet Explorer 5.5 or Mozilla 1.7),
mobile devices (PocketPC, Blackberry),
the Web Dynpro Client for Windows, which
can be regarded as the successor of the SAP
GUI application. [4]
A view describes a visible screen area, which

contains and lays out controls (also called UI
elements or widgets). In the example, a view
called EmployeeForm contains controls of type
text field for displaying and entering information
such as the name of an employee. Actions are
defined for designated user input (i.e. entering
text, or pressing a button), they may trigger event
handling.
Views can be arranged to complex screen
layouts using view areas, view sets and windows,
and navigation plugs may be added to a view for
switching between views. Both is beyond the
scope of this article.
In addition to client-side rendering using

JavaScript, other rendering modes are under
consideration, such as static HTML assembled by
the server. [2]
The remainder of this article will focus upon
Java development and rendering using
JavaScript-capable web browsers. However, the
basic concepts discussed in section 2 hold true for
other use cases as well. Diagrams use FMC
notation (see [8]).
2.1.2. Controller
For realization of dynamics, controllers are
required. Every view has a dedicated view
controller, and every component has a component
controller. Custom controllers may be added for
further structuring of the system.
A view controller performs event handling
based of the actions invoked in the view. For
example, the view controller of EmployeeForm
may react on pressing a button by updating data
(see section 2.1.6) or switching to another view.
Besides event handling (which is described in
event handler methods), controllers may perform
other activity described in methods.
2. Basic concepts
2.1. An example
The basic concepts of Web Dynpro are now
explained using the example in Figure 1. A form
for editing employee base data (like name, date of
birth and so on) should be realized as a Web
Dynpro application. Note that is a simple
example: it comes with only one view and no
further controllers beyond the view controller and
the component controller. Furthermore, it uses no
complex data types, i.e. only strings are mapped
between contexts.
2.1.3. Model
A model describes data in the backend, for
example using JavaBeans. Those data are
102
provided through model classes which comprise

model properties. In the example, the Web
Dynpro component uses a model called Human
Ressources. Inside this model, the Employee
model class contains an employees data, in
particular the name attribute as a model
property.
Models may also contain executable model
classes, which can be called. These are not
covered in this article.
It should be noted that the classic Model-ViewController pattern (MVC) is not apparent in Web
Dynproalthough the same wording is used and
although this is claimed in various publications.
In classic MVC, a view gets updates directly from
the model ([7], i.e. without indirection via a
controller), which is not true for Web Dynpro.
model of the data to be presented in controls of

the view, and a binding exists between these
context elements and control properties. Then, a
component controllers context keeps the model
Figure 2 A context
of all data required in the component, and these

context elements are bound to a model. Moreover,
context elements may be mapped across contexts.
According to context mappings, data changes
are synchronized between controls and models,
so one may have the idea of only one location for
the data. In Figure 1, this is illustrated by the long
rounded node for the employees name, which
comprises the corresponding control property,
context elements, and model property.
2.1.4. Component
A reusable, encapsulated part of the system (and
the describing software package) is called a
component. In most cases, a component contains
several views and controllers (in fact, a
component controller is always present), and uses
one or more models. In the example, the
component is called EmployeeBaseDataEditor.
Components are able to communicate with other
components via component interfaces.
2.2. Meta-model
In Figure 3, all the concepts introduced so far are
put together to form a meta-model. The entity
types and relationships concerning screen layout
and navigation are grayed out since they are not
covered in this article.
As Figure 3 depicts, a component consists of
views and controllers, may use models, and is
started by an application. Controllers are
partitioned into view controllers, component
controllers, and custom controllers, whereas there
is exactly one component controller, and one view
controller per view. A view consists of controls,
which have control properties. As well, a model
consists of model classes, which have model
properties.
A context is part of each controller and
consists of context elements. To simplify matters,
context elements are not partitioned into non-leaf
and leaf elements in Figure 3, so it is true that
context elements may be bound to both model
classes and model properties. On the other hand,
context elements may be bound to control
properties, and can be mapped to context
elements in other contexts.
2.1.5. Application
An application, which is not embodied in Figure 1,
serves as the entry point for users in terms of
something runnable from the frontend. It is
identified by a uniform resource locator (URL).
Running an application means
1. starting a designated component, and
2. navigating to an initial view, which in turn is
displayed in an initial window.
2.1.6. Context
All data processing in a Web Dynpro application
is done via contexts. Each controller has a context,
which represents a hierarchical data model1 as
depicted in Figure 2, where leaf nodes are typed
using Java native types (e.g. String as in the
example) or Java dictionary types.
Typically, a view controllers context keeps the
Model means a structure of metadata (i.e. types and their
relationships) here. The quotation marks are used to
distinguish this term from a WebDynpro model as
introduced in section 2.1.3.
1
103
screen layout
application
start
component
have
use
window
consist of
component
controller
custom
controller
consist of
view
controller
controller
model
view
outbound
plug
have
navigation
link
context
inbound
plug
plug
model
class
control
have
have
model
property
context
element
control
property
bind
bind
navigation
map
Figure 3 Meta-model
automatically. In addition, programmers may

alter the generated code in order to add event
handlers or additional methods (see Figure 4). [5]
The Web Dynpro tools require custom code to
be restricted to designated regions, which are
marked with special comments. In the following
code, only the blocks between the //@@begin
and //@@end markers may be edited and would
be preserved during code re-generation:
3. Development process
As mentioned before, the NetWeaver Developer
Studio provides tools to create Web Dynpro
applications in a graphical or declarative manner.
Usually, this includes all the layout and
navigation, as well as context data and model
binding. These pieces of system description are
known as Web Dynpro metadata, for which the
corresponding
Java
code
is
generated
//@@begin javadoc:onActionBack(ServerEvent)
/** Declared validating event handler. */
//@@end
public void onActionBack(
<...> IWDCustomEvent wdEvent
)
{
//@@begin onActionBack(ServerEvent)
wdThis.wdFirePlugToStartView();
//@@end
}
Web Dynpro Tools

Editor
developer
Generator
Web Dynpro
Metadata
Writing a Web Dynpro application typically

includes some common steps as listed in Table 1.
For each step, the table states if graphical,
declarative, or procedural programming is
appropriate.
Java Code
Figure 4 Development process
104
Table 1 Common development steps
Step
Start
create component
(code is generated)
Design views
create view (code is generated)
place controls on view
(metadata are generated)
add control properties
(metadata are updated)
Design screen layout
apply screen layout to views
Design navigation
create and connect navigation plugs
(code is generated)
write event handlers
Design data flow
populate and map contexts
use models
Add additional features
add controllers, write event
handlers and methods
Web Dynpro
client
4. Execution
decl.
Figure 5 depicts the execution environment of a

Web Dynpro application. At high level, one can
have the idea that the application, which runs on
a presentation server, reads and writes screen
data (i.e. control properties and layout) at the
client, and communicates with the backend
application in order to use business data. All
information about data binding and contexts is
stored inside the application on the presentation
server.
Considering the control flow in more detail,
its the Web Dynpro client (e.g. implemented as a
bunch of JavaScript functions) that initiates all
activitynamely when an action fires. The
resulting request/reply cycle is called a roundtrip
and includes
decl.
graph.
decl.
graph.
graph./
decl.
proc.
a message from the client to the server, and

context update at the server,
possibly further activity by controllers at the
server, and
a message from the server to the client, and
screen update at the client. [1]
graph./
decl.
graph./
decl.
proc.
The application makes use of the Web Dynpro

runtime, which performs, amongst other things,
event dispatching and model management for
communication with backends. According to the
type of the backend server, different protocols are
used for communication: Remote method
invocation (RMI) for Java-based beckends, SAP
Java Connector for ABAP-based backends, or
SOAP for Web Services.
Web-Dynprobased application
screen data
Type
Web Dynpro
runtime
RMI
Backend
application
J2EE
Application Server
business
data
Backend server
(J2EE-based)
User
R
R
Web browser
Web server
HTTP
Client
SAP Java
Connector
R
Web Service provider
Presentation server
SOAP
Figure 5 Execution environment
105
Backend server
(ABAP-based)
Finally, at low level the Web Dynpro client

and the Web Dynpro runtime make use of a web
browser2 and a web server, respectively, so the
client/server communication takes place via the
Hypertext Transfer Protocol (HTTP).
References
[1] Kessler, K., Tillert, P., Dobrikov, P.: JavaProgrammierung mit dem SAP Web Application
Server. Galileo Press, Bonn 2005.
[2] McNulty, P.: Web Dynpro Overview. SAP AG,
2002.
5. Conclusion
[3] Tillert, P., Wilson, A.: Web Dynpro

Introduction/Concepts. SAP AG, 2003.
With Web Dynpro, SAP introduces a powerful

framework for user interfaces in NetWeaver.
Although the combination of Java-based server
applications
and
JavaScript-enabled
web
browsers is the most common use case at the
moment, it is open for different programming
languages and platforms, different frontend
types, as well as new backend types.
Most of the programming can be done in a
graphical or declarative manner. The NetWeaver
Developer Studio, which offers the tools to do so,
is in turn based upon the Eclipse framework and
thus excellently extensible. At product level, the
component concept supports reusability of Web
Dynpro applications.
From a technical point of view, the mapping
and synchronization of data between UI controls
and the backend via models and contexts is a
distinguishing feature. All activity is initiated
from the client, forming roundtrips. This
approach makes Web Dynpro feasible for a large
class of frontend types (particularly, limited web
browsers).
[4] SAP Library Development Manual, Web Dynpro.

[5] SAP Library Architecture Manual, Web Dynpro
Architecture.
[6] SAP Online Help, Creating Your First Web Dynpro
Application.
[7] Knpfel, A.: Konzepte der Beschreibung
interaktiver Systeme. Universittsverlag Potsdam,
Potsdam 2005.
[8] Fundamental Modeling Concepts home page,
http://www.f-m-c.org
It's a simplified association that the Web Dynpro client

communicates with a web browserin fact it is implemented
by parts of a web browser. However, one can consider these
components two agents (one for screen interaction, one for
page loading) to preserve the idea of layering.
2
106
WebDynpro
Navigation & Component-orientation
Christian Holz
christian.holz@hpi.uni-potsdam.de
Abstract
WebDynpro is SAPs new approach for web application development. Developers are supposed to create their applications with visual tools that require little
knowledge concerning implementation details. Hence,
most of the source code is generated by the used development environment. The WebDynpro approach allows
developers to separate presentation- and business-logic.
In addition, WebDynpro Applications are operatingsystem independent. Developers can create WebDynpro
Applications using either ABAP- or Java-technology.
This paper aims to describe opportunities provided by
WebDynpro technology regarding front-end design, navigation logic and reusability. Besides, it focuses on the
Java-personality of the SAP Web Application Server
and, therefore, deals with the Netweaver Development
Studio regarding application design.
Keywords: WebDynpro, Netweaver,
Component, Context mapping
provides an application development framework to developers that have to be familiar with certain basic
vocabulary in order to use it. At the first glance, the
Metamodel seems restricting, but WebDynpro Applications feature a high maintainability and long life cycles. Although developers are not able to extend the
Metamodel1 ; they can create new elements using Component technology. Components can encapsulate certain operating sequences and are additionally able to
present a user interface. WebDynpro Applications consist of active parts (Controller) and passive elements
(Context), whereas Controllers are able to interact and
share memory with others. The latter is important regarding navigation and data transfer.
Developer
Developer
R
Netweaver Development Studio
Navigation,
Project Manager
View Designer
Windows
Views
Applications
Navigation
Modeler
Data
Modeler
Controller
Context
Navigation
Graph
ViewSets
Components
system description
design time environment
Runtime environment
WebDynpro Runtime
Introduction
WebDynpro Component
WebDynpro creates a high abstraction level in comparison to JSP and Servlet technology. Indeed, the
runtime environment is based on Servlets, but developers do not get into contact with them. They range
within the scope of the WebDynpro Metamodel [2],
which provides various possibilities to develop an application. Furthermore, the Metamodel enables developers to control message dispatching, information transfer and frontend design of their application. Developers
have no need to deal with runtime or client technology, because WebDynpro Application development is
independent from both, client presentation and server
runtime operating-system. Additionally, WebDynpro
ComponentController
Interface
Controller
View
Controller
View
Controller
Custom
Controller
Custom
Controller
Interface
Controllers
Context
Context
Context
context
context
View
View
Component
Controllers
Context
described system
Figure 1. Block diagram, system description

and described system
1 e.g.
107
to extend the Metamodel by new UI-Elements
WebDynpro Tools
dition, the runtime manages user sessions, security and

optionally retrieves information from backend systems.
The WebDynpro approach intends to separate

presentation- and business-logic under the terms of the
Model-View-Controller Pattern [6]. WebDynpro distinguishes three different main domains with regard
to application development and therefore provides the
so-called WebDynpro Tools as depicted in figure 1.
Firstly, the Netweaver Development Studio offers the
so-called View Designer. Designers use this tool to create the front-end, i.e. web pages provided to the user.
This encloses the need to arrange User-Interface (UI)
Elements on those web pages. Secondly, the Navigation
Modeler creates navigation graphs and provides access
to refinement settings. Different user front-ends can
be placed on and arranged within different grouping
units. The Navigation Modeler administrates all navigation logic. Hence, this tool provides the only way
to change navigation flows and user-screen transitions.
Thirdly, the Data Modeler allows developers to specify information-exchange relations and adjust the data
flow. The Netweaver Development Studio provides the
Project Manager that presents all WebDynpro Application elements and starts the appropriate tool in order
to edit them.
3.1
WebDynpro Client
The WebDynpro Client is the universal presentation system for end-users. It is capable of presenting the described screen content and forwards user actions to the server. Due to the current market situation, HTML and web browsers are currently used
on the client side of the application. In the course of
web applications, WebDynpro provides a web interface.
Hence, web browsers act as WebDynpro Clients as depicted in figure 3. Smart clients that do not require a
web interface are still to come anyway. The JavaScript
environment of the used web browser contains the WebDynpro Client framework. Framework functionalities
are necessary to check empty fields, mandatory checkboxes and the current state of web page elements . Besides, the framework provides functions for repositioning and resizing web page elements in order to adapt
the frontend to events like window size changes.
user
R
user
Browser Engine
R
WebDynpro Client
input
data
+
action
http
Scripting
Agent
Metadata
output
data
+
layout
WebDynpro Client
Framework
Site
Retriever
HTML Render
Agent
HTML/CSS/JS
Cache
Internal Cache
(Layout, Data)
sessions
WebDynpro
Runtime
WebDynpro
Client
policies
http
SAP J2EE Server

R
Figure 3. Block diagram, WebDynpro Client
backend system
database
Figure 2. Block diagram, scenario
WebDynpro Applications
WebDynpro Applications consist of the WebDynpro

Client and the WebDynpro Runtime as shown in figure
2. While clients know the current web page only, the
WebDynpro Runtime manages the business logic and
generates web pages out of so-called Metadata. In ad-
3.2
WebDynpro Runtime
Regarding the WebDynpro architecture, the predominant part of the WebDynpro Application is executed on the server side, i.e. business-logic2 is managed there, too. Since HTTP is a stateless protocol
[7], clients know single user-screens only. Clients have
no knowledge of background storage, dependencies and
flow logic. Thus, they have to request a web page from
the runtime in order to retrieve the current application state. The WebDynpro Layer within the J2EE
2 i.e.
108
flow, data, structure, dependencies, ...
Server resides on top of the Servlet layer [8]. It contains the WebDynpro Runtime and is based on Servlet
technology. The development environment generates
application code out of developers adjustments with
the WebDynpro Tools at design time. Additionally,
developers are able to extend applications manually.
Both, generated code and developers implementation
use the WebDynpro API that allows applications to
access running services in the WebDynpro Runtime.
WebDynpro Client
WebDynpro Runtime
preprocess
relevant data
execute local
checks
no errors detected
checks. Next, the web browser triggers the runtime and

the server-side part of the WebDynpro Application receives the transferred data. It examines the delivered
information and carries out remote checks3 . In that
way the server application is able to send back a generated error page immediately, although there can be
totally different content on it. Otherwise, the application can process the transferred data, retrieve additional information from a backend system and generate
a new page out of recalled information and Metadata.
Consequently, the server sends back the new page to
the web browser client and the Roundtrip is completed.
Hence, during a Roundtrip input and output data are
synchronised with the server-side storage of the application (see figure 2).
errors detected
handle
local errors
prepare request
print
detected errors
pose request
to the server
contains
0..1 ViewContainer
contains
check
data integrity
View
process data
errors detected
combines
no errors
perform
event handling
- Type
optionally
retrieve data
ViewArea
(backend system)
display
error page
displays
Component
no errors
generate
new View
send result
back to the client
embeds
display
new site
- Type
Figure 5. ER diagram, WebDynpro terms
Figure 4. Petri net, Roundtrip
3.3
Roundtrip
The communication cycle between WebDynpro

Client and WebDynpro Runtime is called Roundtrip.
The Petri net in figure 4 shows the flow of a Roundtrip
with regard to the composed system depicted in figure 2. A Roundtrip is a procedure initiated by the
WebDynpro Client that poses a request to the server.
Users can access the current web page containing fields,
buttons and/or links on it. After they filled in information, they submit this page by hitting a link or
button. Before actually submitting this page to the
server, the client-side part of the WebDynpro Application is able to call functions provided by the WebDynpro Client framework in order to perform prerequisite
Window
belongs to
Event Handlers
discovered errors
ViewSet
WebDynpro Terms
In the course of WebDynpro Application development, designers have to be familiar with certain basic
terms.
4.1
Window
Usually, users have the imagination of one web page

filling the entire screen. Hence, Window is the term
closest to common understanding. It characterises
a rectangular area on the screen that can have behavioural features. These can be options like popup or
modal. The former causes the WebDynpro Runtime
3 i.e.
109
it proves the acceptance of data
to generate HTML-code that triggers the client to open

a new browser window. The latter occurs whenever
modal foreground windows have to be closed before
background windows are accessible again. The runtime
establishes the blockade of the background window as
long as foreground windows are opened.
4.2
View
Window is assigned to a Component, which is the super ordinate unit and features reusability as described
later on. ViewAreas are also able to display Components, which is interesting with respect to embedding
both Views and functionality.
Components
has
Window
In order to have more granular units composing the

screen, WebDynpro offers so-called Views. A View is
the smallest unit that can be managed by the Navigation Modeler. Furthermore, Views are the only elements in which UI-Elements can be placed. Since
Views represent only a section of the screen, they have
to be organised on the screen. The View Designer allows developers to change the look and feel of Views.
They can be nested, combined and come to the fore
at the same time. The Netweaver Development Studio
provides different perspectives on all the aspects of a
View, e.g. Context, Plugs, and Implementation. Developers define the screen content with the perspective
layout. UI-Elements can be arranged via drag and
drop as described in section 7.1.
4.3
ViewSet
ViewSets are the preferred way to create a layout on

the screen. They manage a certain area and split it up
into several other areas. The ViewSets themselves are
responsible for the arrangement of these areas that act
as containers. There are different kinds of ViewSets for
different arrangements of those containers. The layout
decides the sectioning of the screen. The T-layout,
for instance, creates an area above two tile areas, the
so-called ViewAreas.
4.4
ViewArea
Figure 5 shows that ViewSets offer ViewAreas to

fill in sub-elements. Hence, ViewAreas are placeholders in order to abstract from the embedded content.
Although ViewAreas are capable of containing numerous Views, ViewSets and Components, they always display exactly one embedded element at a time. Besides,
ViewAreas allow the refinement of ViewSet sections
with other ViewSets. Users change contained Views
by navigation. According to web page transitions, a
navigation initiation triggered by a link in one frame
can invoke the replacement of various other Views contained in different frames. Thus, each Window offers a
ViewArea, too. The Window can contain a single View
or a ViewSet in order to split up the initial screen. Each
MainWindow
defines
started by
Application
Component
entry point
Inbound Plug
- Parameter
Component Plug
has
Outbound Plug
Figure 6. ER diagram, characterising Components

Figure 5 characterises Components as another abstract grouping facility. They can embed several windows as well as related ViewSets and Views. However,
Components even are substantial units for modularising. Figure 6 shows the meaning of a Component
within a WebDynpro Application. Actually, they are
not only another abstraction level, but also essential
to every application. Each WebDynpro Application
starts exactly one Component and defines one of the
windows belonging to the Component as MainWindow.
It is initially shown by the WebDynpro Runtime. Components have Plugs, too. If a single Component is set
up, developers will not notice any occurrence of Plugs.
Strictly speaking, Inbound-Plugs are entry points into
the Component and they are necessary in order to display a covered Window. Entry events can be treated by
Event Handlers, which can receive certain parameters
delivered from the URL requested by the user. Thus,
initial settings such as defining the primary View can
be carried out. Outbound-Plugs are formal exit points,
i.e. firing an Outbound-Plug means terminating the
active Component and, consequently, exiting the application.
5.1
Components as mandatory elements
At the first glance, WebDynpro Components are an

obligatory method for application development, but
110
WebDynpro Component
embeds
1
ComponentController
Interface
Controller
Interface
Controllers
Context
View
Controller
View
Controller
Context
Context
View
View
Custom
Controller
context
Transparent
Container
Navigational
Link
Custom
Controller
context
View
embeds
Component
Controllers
Context
0..1
RootUI
Container
Container
- Layout
UI Elements
Navigation
Layout
0..1
Figure 7. Block diagram, typical composition

of WebDynpro Components
Attributes
1
- Name
Context
Controller
Components encapsulate certain functionality comparable to hardware modules. Although developers do

not need to know anything about the implementation,
they can utilise Components within their own applications. With respect to hardware modules, Components
offer parameters they can process and return information they calculated in turn. Components are not only
able to return computed results, but also to represent
Views, additionally. Therefore, they can be embedded
into ViewAreas as depicted in figure 5. The Navigation
Modeler treats Components contained in other Components as View objects without interior logic. They are
also termed InterfaceViews, because they are the visual
interface for procedures within the Component. For
the embedding Component there is no difference between atomic Views and InterfaceViews. The Navigation Modeler is able to handle both kinds of Views and
combine them in ViewSets or connect them through
Navigational Links. Figure 5 illustrates the typical
composition of WebDynpro Components. They contain two obligatory Controllers. Firstly, they enclose
the ComponentController and secondly, they contain
the InterfaceController
Controller
Controllers are active components that cause and

handle events. They have methods and can interact
by calling methods offered by other Controllers. In
addition, Controllers hold data in their Context as depicted in figure 6. The Context represents all locally
stored information that is available without retrieving
information from other Controllers. The Context can
contain both, local and global data without the Controller knowing which part of the Context is globally
stored and which is not. The Contexts life cycle is as
long as the Controller lives.
Local Data
Global Data
Figure 8. ER diagram, relationship between

View, Controller and Context
6.1
ViewController
If Controllers are assigned to Views, they are called

ViewControllers. They are the active components
within the WebDynpro Application that have to handle
events caused by UI-Elements on the presented Views.
Consequently, ViewControllers manage the surface of
their View, fill in facts and evaluate the transferred
user-data. Apart from dealing with Views, ViewControllers also generate HTML-code out of the stored
Metadata and deliver it to the WebDynpro Runtime
whenever asked for the related View. ViewControllers
trigger web page transitions by activating Navigational Links as will be introduced later on.
6.2
CustomController
With regard to figure 7, developers can create additional Controllers that are not assigned to Views.
Those Controllers also feature a Context for data storage and are called CustomControllers. They offer similar functionality as other Controllers do, but may have
longer life cycles than ViewControllers. The meaning
of a Controllers life cycle is discussed in section 9.1.
6.3
ComponentController
Every WebDynpro Component has a dedicated

ComponentController that lives as long as the Component is active. Similar to other Controllers, the ComponentController has its Context for local data existing
111
as long as the Controller itself. Consequently this is the

only place, where information can be saved with longer
persistence.
6.4
InterfaceController
The InterfaceController is the only subject that is

visible to the environment of the related WebDynpro
Component. The meaning of InterfaceControllers is
discussed in section 10.1.
6.5
Context
The Contexts structure is composed hierarchically.

Nodes represent data structures, whereas attributes are
mapped to single elements by the runtime. Nodes can
hold multiple data instances, which is useful regarding table UI-Elements that are capable of displaying
numerous records. Binding data to table UI-Elements
automatically causes the runtime to create enough lines
in order to display the entire result set [10].
Design
7.1
Static Design
A View is the only entity that can embed UIElements. They are organised hierarchically, too. Figure 8 depicts that Container elements provide the basic
region for embedded items. Hence, Views commence
with the initial RootUIContainer, which is the exclusive element that is placed on each View. Other UIElements that are placed on the View have a parent
Container. Apart from the RootUIContainer, developers are able to group UI-Elements with so-called TransparentContainers. This is useful regarding the visibility or capability state of a whole category of elements.
Each element placed on the View has certain named
attributes with values retained in the belonging ViewControllers Context4 . The View Designer also provides the ViewContainer UI Element. The usage of
this element expatiates space for embedded Views or
ViewSets as shown in figure 5. Hence, the ViewContainer offers an additional ViewArea and covers problems like text surrounding an embedded View5 . Views
can contain several ViewContainer UI-Elements and,
thus, compensate the ViewSet function, i.e. ViewContainers are an adequate substitution for missing
ViewSet layouts. Unusual to developers, WebDynpro
does not allow a precise arrangement of UI-Elements.
4 e.g.
5 e.g.
Instead, the underlying containers layout determines

the position of each element. Allowing developers to
place elements pixel accurately the designed surface
would depend on screen resolution settings and window sizes. Besides, frontends could not be designed
for different client systems, such as notebooks, PDA
systems and mobiles. Consequently, there are layouts
allowing table-, row- and simple layouts. The latter arranges elements one after the other allowing line
breaks everywhere, whereas row-layouts arrange elements in one row each. Since WebDynpros intention
is to provide a toolbox for developers in order to enable them to compose applications and web pages for
varying systems, absolute positioning would not help
out with that. Pixel accurate arrangement of elements
is possible, anyway. Therefore, Designers have to use
Adobes Form Designer [1] and users need to have Acrobat Reader installed. Another advantage of this solution is offline completion, i.e. forms can be filled out
while users are offline. They are able to submit all entered data when they are back online. A disadvantage
is the dependency on Adobe products, i.e. there can
be no guarantee for WebDynpro Clients constructing
web pages on every architecture anymore.
7.2
Dynamic Design
The Netweaver Development Studio generates

source code that creates one Java object for each
Context- and UI Element representing the modelled
element at runtime. Of course, developers are able to
create Context- and UI-Elements at runtime as well.
Dynamic changes related to UI-Elements are only allowed to one Event Handler: doModifyView. Each time
a user requests a web page containing a View, the runtime calls this Event Handler right before displaying
the View. The RootContainerUIObject is delivered to
this Java method in order to apply changes to the layout. Regarding figure 4, it is the last Event Handler
that is called on the server side. In spite of having
the possibility to apply changes to the entire application, developers are supposed to restrict to dynamical changes on the layout and not to change the Context. Once UI-Elements are created dynamically they
are available until the end of the running application.
There are many dynamic opportunities, which can be
found by creating the intended application statically6
and having a look into the generated source code. Mixing static and dynamic design can be absolutely reasonable. For instance, developers can create basic parts
of a survey application statically, e.g. web page layout, navigation controls and data operations in order to
width, caption and id

for the usage of iFrames
6 i.e.
112
at design time
save results to a backend system. However, situationdependent parts such as radio-buttons, checkboxes and
input fields can be created dynamically at runtime, because they are different for each question of the survey.
Navigation
8.1
Navigational Links
connects
View
Handler. In that way, initial settings, e.g. visibility or

caption of input fields, can be adapted before users get
to see the finally rendered View. The Netweaver Development Studio automatically generates Java methods
out of the Plugs names for entering events and the
so-called Plug firing methods. When a ViewController
fires an Outbound-Plug, the runtime will follow all outgoing edges from this Outbound-Plug in the navigation graph and will then display all connected Views.
These Views can be embedded in several ViewAreas
and, thus, evoke several part changes on the web page8 .
8.2
Navigational
Link
Action Event
triggers
Figure 9. ER diagram, Navigational Links

Navigational Links are connections between two
Views and can merely be defined with the Navigation
Modeler. Developers design navigation graphs without
having to look into the inner part7 of a View. As figure
9 shows, there can be more than one link between two
Views in order to treat web page transitions differently
that are caused by Action Events.
belongs to
View
- Name
belongs to
Web pages offer a variety of possibilities concerning

user activities, e.g. highlighting UI-Elements, selecting radio- or check-boxes and entering text into input
fields. UI-Elements provide so-called UI-Events, which
they can process such as the click event on a button.
Consequently, UI-Events are qualified activities that
may occur. As shown in figure 11, events can cause
predefined Actions, which developers specified at runtime. In addition to that, Actions are the only subjects
that can cause a Roundtrip and initiate the client-side
based processing (checks), the server-side processing
(data operations9 ) and the new page generation.
UI Event
Outbound
Plug
Plug
View
Actions
Possible
User Action
Navigation
Link
causes
Inbound
Plug
Controller
layout, links and other navigation controls
Roundtrip
treats
fires
Outbound
Plug
7 i.e.
evokes
Action
Figure 10. ER diagram, Navigational Links

implemented by Plugs
WebDynpro implements navigation with Plugs.

There are Inbound- and Outbound-Plugs offering possibilities to enter and leave the assigned View. As
depicted in figure 8, Outbound- and Inbound-Plugs
are connected by the mentioned Navigational Links.
A View neither knows its environment nor has it
knowledge of other Views, but it is able to define
an Outbound-Plug in order to provide a possibility
to change Views. The connected Outbound- and
Inbound-Plugs can belong to the same View. Whenever a View becomes active due to the activation of an
Inbound-Plug, this event can be treated by an Event
UI
Element
0..1
implements
Event
Handler
Custom
Coding
Figure 11. ER diagram, characterising Actions
8.3
Event Handler
WebDynpro Actions have to be treated by Event

Handlers that are executed by Controllers. As de8 e.g. a menu link that changes not only the web page within
one frame, but also in numerous others, which is not possible
with standard hyperlinks
9 i.e. data is recorded in the related ViewControllers Context
113
picted in figure 11, Event Handlers take care of the

triggered Actions. Event Handlers provide Java skeleton functions and may be implemented by so-called
Custom Coding. In addition, Action Event Handlers
open up firing Outbound-Plugs, which can be generated by Netweaver Development Studio automatically.
8.4
Implementation
The implementation section of a View shows the

source code implementing the current ViewController
on application execution. The largest part of this code
is generated by the Netweaver Development Studio
that creates methods with corresponding names out of
defined Event Handlers, Plugs and UI-Elements. Code
changes can only be carried out in certain areas within
the source code [9]. All statements within this section
do not get lost during the regeneration process and is
reconstructed at this place by the Netweaver Development Studio. As already mentioned, code within these
sections is called Custom Coding. Changes beyond this
area are not recognised by the Netweaver Development
Studio. At all times, when developers switch to the implementation tab or deploy the application, code generation is initiated from scratch.
Data Transfer
9.1
Controllers life cycle
The life cycle of a ComponentController, an InterfaceController and a CustomControllers is as long as

the super ordinate Component itself lives. The life cycle of a ViewController is much shorter, i.e. as long as
the related View is presented to the user.
9.2
Data Binding
With regard to data exchange, records need to be

transported from one View to another, e.g. authenticating a user against the server or displaying transferred information on the next page again. Although
information provided by the user is available in the
ViewControllers Context for a certain time10 , the next
ViewController requires having access to this information, too. Hence, users need to have a storage medium
lasting longer than every ViewController does. For
this purpose every WebDynpro Component has a dedicated ComponentController that lives as long as the
Component is active. Additional to UI-Elements attribute values, which are stored in the related ViewControllers Context, the Context is capable of holding
10 namely
as long as the ViewController is active
extra attributes11 . Developers can bind UI-Elements

attributes to these Context Elements by creating a
link between them (so-called data binding). Whenever the elements attribute value12 is changed, the
runtime changes the associated Context Element as
well and vice versa. As a matter of fact, the runtime
transports data in both directions. Application developers can access the Context out of their implementation part of the WebDynpro application. Hence, they
can change attributes that were additionally defined at
design time. If UI-Elements attributes are bound to
Context Elements, developers are able to change the
front-end indirectly. Changes to the Context are applied to the current View after the user causes an Action. With binding attributes to Context Elements,
designers are able to create complete scenarios without
having to type any source code. Things like visibility
or capability state can be connected using data binding. Consequently, one text fields or checkboxs value
could have an influence on the visibility of a submit
button13 . Data binding still does not open up the possibility of active data transfer between different Views,
i.e. between the concerning ViewControllers.
9.3
Context Mapping
Apart from binding element attributes to Context

Elements, developers are able to bind Context Elements to other Context Elements (so-called context
mapping). The affected Context Elements can be associated with different Controllers. Consequently, changing an element in one Context invokes the change
of the related other one. Hence, mapped Context
Elements will always have exactly the same content
and size. Thus, Context mapping is the appropriate
way to implement information exchange. Element attribute names are no longer identifiers for locally stored
values, but rather pointers to storage cells. Consequently, Controllers are able to exchange information
via shared-memory as depicted in figure 12. Developers can have the imagination that the actual value
is stored at a memory cell where Controllers Context
scopes overlap.
Regarding figure 13, the following scenario is imaginable: Two ViewControllers have one additional element14 in their Context. In addition, the ComponentController has a Context Element, too. The text
attribute of an input field on the first View is bound to
the Views Context Element. The text attribute of a
11 such
as name, type, value

text, colour or visibility
13 think of licence agreement screens
14 additional element means an extra attribute in the Context
that already holds UI-Elements attributes
12 e.g.
114
10
WebDynpro Runtime
View request
initialisation
View request
Component Controller
View
Controller
View
Context
View
Controller
name
Context
10.1
Reusability
Components as special elements
At runtime, Components are the only WebDynpro

constructs that can be instantiated as often as needed.
Developers either set the multiplicity and the WebDynpro Runtime generates code automatically or they create instances of this Component manually. The latter
case gains importance with regard to dynamically created Components.
View
WebDynpro Runtime
Controllers
Context
R
web page request
Figure 12. Block diagram, Context mapping

WebDynpro Component
ComponentController
label on the second View is bound to the corresponding

Views Context Element.
View
Controller
Component
Controller
R
R
Interface
Controller
View
Controller
View
Controller
Context mapping
embedded WebDynpro Component
ComponentController
Context
Context
name
name
name
View
Controller
Component
Controller
View
Controller
Context
name
Context
Context
Figure 13. Block diagram, Context mapping

Both Context Elements are mapped to the ComponentControllers Context Element. In this way, inserted information into the input field will automatically be saved in the storage cell all attributes and Context Elements point to as depicted in figure 13. Every
time the content of one Context Element is changed,
the value in this storage cell is updated by the WebDynpro Runtime. Every different Controller accessing
any Context Element mapped to the ComponentControllerss Context Element will access the current value.
Data changes15 are not applied until the user invokes
a Roundtrip caused by an Action.
15 i.e.
content of input fields
Interface
Controllers
Context
Context
Interface
Controller
View
Controller
Interface
Controllers
Context
View
Context
View
Component
Controllers
Context
Component
Controllers
Context
Context
Figure 14. Block diagram, reusability

Similar to Views, WebDynpro Components do not
have knowledge of their environment, but offer the InterfaceController in order to receive requests from surrounded Controllers as shown in figure 14. As already
mentioned, the InterfaceController is the only part of a
Component that can be accessed by the environment.
Consequently, all sensitive data has to be stored in
the Context of the InterfaceController. Other Components can create a mapping against the InterfaceControllers Context or call offered methods, but never
get into contact with the ComponentController or any
ViewController of the embedded Component directly.
The Component itself can build up mappings against
Context Elements belonging to the InterfaceController.
In this way, internal Controllers are able to access information originating from the environment. Mapping
across Component-borders has no restrictions.
10.2
Components as reusable elements
Aside from Components being the basis of each application, the most important function is to encapsulate reusable objects. As the term Component already
115
states, it is supposed to offer an amount of services

and to hide the implementation at the same time. This
principle of information hiding is established by the InterfaceController. Reusability means a separate module that can be reused in several other projects. The
Component accepts the delivery of a record set and
presents data like a search result set in online shops.
There is a certain predefined layout for one entry that
is put into effect by the Component. The Components
user can define the usage of the delivered information
out of the table data into the fields. In addition, developers define how many entries are supposed to be
shown on one page. The Component provides controls
in order to browse from page to page. It is up to the
component what happens to the data (internal logic).
Components are of high importance regarding reusability. For instance a search result Component could
display a picture, several facts concerning author, title, pricing information and control elements, e.g. add
to basket in a web shop. The acquired information
can be bound to the InterfaceControllers Context and
multiplicity can be set to any value. Consequently,
the runtime environment creates the defined amount
of Components and displays result set entries in each
of them. In addition, the runtime automatically detects, whether there are more results than the amount
of instantiated WebDynpro Components and automatically generates control elements such as page up and
page down controls. The InterfaceController features
input elements16 . Besides, it provides certain methods
that enable developers to trigger the display of initial
records. After changes have been made to the record
set, the InterfaceController can be triggered in order
to refresh the display. InterfaceController Context Elements are available to all other Controllers covered
by the containing Component. Consequently, ViewControllers can map their Context against the InterfaceControllers Context and make use of information
delivered from the environment.
11
Conclusion
WebDynpro enables developers to model their application featuring the automatic generation of source
code. Besides, WebDynpro is intended to ease application development in order not to have the need to write
too much source code. Hence, little Custom Coding is
needed. In most cases the Netweaver Development Studio generates the source code for the developer. WebDynpro provides a wide range of UI-Elements. Although absolute positioning is possible with Adobe
16 nodes
technology, WebDynpro normally automates the placement of UI-Elements based on relative arrangements
adjusted by the developer at design time. As a matter of fact, developers create Views and Context statically. However, they are able to create additional elements dynamically at runtime, too. View transitions
are prepared statically while initiating the transfer is
done dynamically at runtime. Sectioning of the screen
is possible so that several Views can be visible at the
same time. Data transfer can be realised using data
binding and context mapping that enables WebDynpro Application to use shared memory for information
exchange. Relationships between Controllers build up
the fundament of every application. Developers model
data in the Context that is handled by the Controller at
runtime. Mappings between the Context of two Controllers lead to an automatic data exchange. Event
Handlers are implemented by Custom Coding. Components enable the reusability of WebDynpro Applications and can be integrated into other applications. In
addition, they are capable of representing a user interface. Hence, they can be embedded in other Views,
e.g. for the presentation of search results. With regard
to figure 1, the WebDynpro Tools that are provided
by the Netweaver Development Studio allow developers to work on all aspects of a WebDynpro Application.
This system description encloses the description of web
pages (Views, ViewSets), navigation logic (Plugs and
Navigational Links) and data relations (data binding
and context mapping). Whenever a WebDynpro Application is requested by a user, the WebDynpro Runtime loads this description and creates the application
system. It consists of active (Controllers) and passive
(Context and other storages) parts that put the described system into effect.
References
[1] K. Kessler, P. Tillert and P. Dobrikov
JavaProgrammierung mit dem SAP Web Application Server
SAP Press/Galileo Press, 1st Edition, 2005
[2] P. McNukty, 2004 WebDynpro Overview
[3] B. Ganz, 2004 WebDynpro Foundation Framework
[4] SAP Library http://help.sap.com
[5] SAP Developer Network http://sdn.sap.com
[6] E. Gamma, R. Helm, R. Johnson and J. Vlissides Design Patterns: Elements of Reusable Object-Oriented
Software Addison Wesley, 5th Edition, 1996
[7] Hypertext Transfer Protocol http://www.w3.org/
[8] J. Brunnert J2EE WebApplications Seminar Systemmodeling, 2004
[9] A. Fahle WebDynpro: An Overview Seminar Systemmodeling, 2005
[10] M. Weidlich WebDynpro: Data Binding and Context
Mapping Seminar Systemmodeling, 2005
for the Context
116
Web Dynpro:
Context Mapping and Model Binding
Matthias Weidlich
matthias.weidlich@hpi.uni-potsdam.de
Abstract
be explained. The first part ends with a short description of the approaches for context programming.
In the second part the focus will turn to the
dataflows in a Web Dynpro application. Therefore the
three different dataflow types, Data Binding, Context
Mapping and Model Binding, will be introduced. After the questions of the model origin will be answered,
communication scenarios are illustrated.
Finally the main points about dataflows in Web
Dynpro will be concluded.
In this paper the main concepts and basic technologies

concerning data management in Web Dynpro are described.
After the context concept has been explained, the focus
turns to the different types of dataflows in a Web Dynpro
application. Therefore the mechanisms Data Binding, Context Mapping and Model Binding will be discussed. Completing the given impression of the link between frontend
system and backend system, the import of models and their
connections at runtime will be characterized.
2. Context Concept
1. Introduction
2.1. Utilization of Contexts
With the launch of the NetWeaver platform, SAP

introduces a new framework for developing browser
based user interfaces, Web Dynpro. As it claims
to be the user interface technology for all applications within the scope of NetWeaver, it comprises
many complex concepts, such as a generic, platformindependent meta model oriented on the Model View
Controller (MVC) design pattern. An introduction
into these general concepts can be found in [9, 12].
Referring to [5], Web Dynpro allows the separation
of design decisions, navigation issues and data modelling, which includes the concepts to store and transport data inside an application.
Context Mapping and Model Binding, mentioned
in the title, are two mechanism for data passing in Web
Dynpro. Nevertheless this paper focuses not only on
these issues, but also explains the basic principles concerning data management. That is why the article is
divided into two parts.
Firstly the context concept, the main concept regarding data storage in Web Dynpro, will be discussed. On account of this the utilization and the
structure including the most important properties will
A Web Dynpro application consists of active parts,

the controllers, and passive parts the contexts. Moreover each controller, for instance a view controller or
a custom controller, has its own context. Although all
data used by the controller or views is stored in the
corresponding context, another aspect is even more
important. Contexts are used as interfaces to pass data
from the frontend, the user interface, to the backend
system and vice versa. That brings us to the question,
how these contexts are structured.
2.2. General Context Structure

Contexts are always structured as a tree, consisting
of nodes (the non-leafs) and attributes (the leafs), as it
is shown in the Entity Relation Model in figure 1 on
the following page. Each context has a root node,
underneath the data fields are stored. Although the
name implies something different, the root node is not
a usual node, but a pointer that simply defines the entry point into the tree. That is why the cardinality is
unchangeable, set to 1..1 (see also 2.3). Both types of
context elements, subnodes and node attributes, exists
117
sents either an individual instance2 of an object type

or a list of instances at runtime [2]. This property
of a node is called cardinality, which is specified via
minimal appearance .. maximal appearance and
can take on four values:
!
0..1
The node contains only one element instance,
which have not to be instanced.
!
1..1
Again the node contains only one element instance, but this time it has to be instanced.
0..n
The node is called multiple node and can contain
several element instances, of which none have to
be instanced.
1..n
Again the node is a multiple node and can contain
several element instances, of which at least one
have to be instanced.
Figure 1. Context Structure

in two flavours: a model and a value flavour. The difference is not only a varying set of properties. In addition value nodes have no binding to the Web Dynpro
model (the model will be explained in 3.4), the typical
services existing for a model node, like data transfer
to the model, are not available for the value node. The
same term is endowed for value attributes and model
attributes.
Since it is not possible to discuss all properties of
context elements within the scope of this article, in the
next part the focus will be laid on the most important
ones.
The property name should be self-explanatory, it
contains the name of the context element that have to
be unique in the whole project. As type declares the
data type of a value attribute it can be a Java Native
Type. Nevertheless Java Dictionary Types1 are even
better to use as attribute types, due to the possibility
to attend a Data Binding.
According to the possibility to define multiple nodes,

a mechanism to mark a specific element instance in
the list is necessary. For that reason each element in an
instance list belonging to a value node has a boolean
property called leadSelection. This property can be set
true for only one element of the list at one time. If
nothing else is specified, the first element of the list is
automatically assigned the lead selection property.
2.4. Calculated Attributes

A special type of value attributes are the calculated
attributes. Hence these attributes are not stored as
memory objects at runtime, they are automatically calculated by the Web Dynpro Runtime on demand. This
demand can be triggered by the Web Dynpro Runtime
or some controller coding by accessing the attribute.
After setting the property calculated true, the body of
a setter- and a getter-method is generated and the developer has to add the calculation part.
A short code example for a calculated attribute can
be seen on figure 2. It shows how a full name of a
person can be calculated by simply combining the first
name and the last name.
2.3. Cardinality and LeadSelection

Causing the fact that the context is a data model
that describes entities and relations, each node repre1 The Java Dictionary contains central, platform- and source code
independent type descriptions, including meta data for database
objects and user interfaces.
2 To be accurate it has to be said that the individual instance is

also embedded in a singleton list.
118
cific context) and IWDNode (to modify, respectively

create a context node).
The typecasted APIs, the second type of provided
APIs, are generated automatically for all statically defined context elements. These interfaces are typecasted, meaning that the signatures of the methods
already contain the corresponding object types respectively Java Dictionary Types. The typecasted interfaces, for instance IContextNode (the interface to
modify a specific node) or IContextElement (to modify a specific node element), are derived from the
global interfaces.
! " "
!
%
&
Figure 2. Calculated Property Code Example
2.5. Singleton Property and Supply Functions
3. Web Dynpro Dataflows
Another important property is the singleton property that can be found in value nodes as well as in
model nodes. Unlike the cardinality of a node, which
describes the number of possible elements within
the node, the singleton property determines whether
these elements are set for all elements of the parent
node3 (non-singleton) or for exactly one element of the
parent node (singleton) [2]. The affiliation of these singleton elements is realized in the following way: the
singleton elements correspond to the parent node element which is highlighted by the property leadSelection (as it was described in 2.3). Therefore a change of
the lead selection in the element list of the parent node
makes it necessary to update the data in the singleton
elements.
For that reason a special type of controller methods for filling value nodes with elements exists, the
Supply Functions. These functions are called by the
Web Dynpro Runtime whenever the element list of
the associated node is accessed. Although each node
can have a Supply Function they are mainly used in
connection with singleton elements. The data origins
used to fill the singleton elements can be various, for
instance other elements of the current context.
3.1. Overview
In this chapter the three types of dataflows in a Web
Dynpro application, the Data Binding, the Context
Mapping and the Model Binding, will be explained.
Before the focus turns to the structural details the
relevance of these dataflows should be motivated. On
the one hand the Data Binding realizes the link between the user interface and the data structures behind, in the sense of ordinary input- and output mechanism. On the other hand it allows controlling the appearance of the user interface by the data structures.
The Context Mapping, which enables data to be circulated between contexts, is mainly used to make the
data persistent, due to the limited lifetime of view controllers. An example for such a usage can be found in
[5]. Moreover the Model Binding connects the internal data structures of a Web Dynpro application with
the model that represents the backend system (see also
3.4).
Furthermore it is necessary to envision the structure of a typical application which is shown in the
block diagram in figure 3. The Web Dynpro Runtime
embeds the application, which consists of agents, for
instance a view controller, a custom controller and a
model agent. To keep the diagram concise, the application consists of only one controller of each type and
some parts (e.g. interface controller and component
controller) are not even shown at all.
Additionally there is a big storage containing several smaller storages. As it was already mentioned,
every controller has its own context, in this case the
view controller context and the custom controller context. Moreover the view layout contains the properties of the user interface elements, while the structure
of the model is depicted in 3.4. Pointed out by the
figure, the big unnamed storage is fragmented by the
four smaller storages. Accordingly the imagination
2.6. Context APIs

While Supply Functions only deal with the instances belonging to a context node, there also has to
be the possibility to change the structure of the context by programming. On account of this Web Dynpro
provides two different types of Application Programming Interfaces (APIs).
The first one is the set of generic APIs which are
needed for the dynamic creation of new context elements at runtime. Examples for generic APIs are the
global interfaces IWDContext (to gain access to a spe3 A parent node of a context element is the node, which is located
directly above the element in the hierarchical structure.
119
"
'
&
%
Figure 3. Overview of Dataflows
120
of multiple interfaces, used to access the big storage,

is appropriate. Several numbered storage elements
are available in more than one storage hence the four
named storages overlap in some areas. Concerning
the dataflows these are the interesting parts, that will
be introduced in the following sections.
context belongs to, they can be regarded as local variables. After a Context Mapping has been defined between two context elements located in different contexts, one and the same context element is visible in
both contexts. Similar to the Data Binding a Context
Mapping does not require any data transport, because
the same storage is assigned for mapped elements. In
figure 3 the Context Mapping involves the view controller context and the custom controller context. The
storage elements with the number 5 and 8 are context
elements that have not been mapped. In contrast, the
elements with the number 3, 4, 6 and 7 are mapped,
whereas the elements 3 and 4 are also bound with a
Data Binding as it is described in 3.2.
3.2. Data Binding

The first dataflow to discuss is the Data Binding involving the view layout and the view controller context. Data Binding allows the use of context attributes
of the view controller as properties of user interface
(ui) elements. Referring to figure 3 the storage elements with the number 2, 3 and 4 participate in the
Data Binding, while the storages with the number 1
and 5 are ui element properties, respectively context
elements that have not been bound. On account of the
binding any user change to the ui element properties,
e.g. the text property of an edit field, is immediately
visible in the context. Due to the assignment of the
same data storage, there is no necessity of data transport.
Figure 4. Data Binding

Figure 5. Context Mapping
As it is shown in figure 4 the Data Binding can

be defined with value attributes as well as model attributes if the attributes type is a Java Dictionary Type.
In the specific case that the ui element property is a
field of values (e.g. the entries in a table) the parent
node of the bound attribute has to be a multiple node,
regarding 2.3. If a single property value is bound to
an attribute of a multiple node, the leadSelection highlights the value that has to be shown.
The figure 5 shows that a Context Mapping on the

one hand can be defined either between value nodes
or between model nodes, but not between a single
value node and a single model node. On the other
hand value attributes can be mapped only to value attributes. For model attributes the same rule is applied.
Additionally the following constraint has to be satisfied: a mapping between the parent nodes of two attributes is a precondition for a mapping between these
attributes.
Moreover Context Mapping is a directive relation.
Although the direction has no impact on data changes,
because it is irrelevant in which context the changes
3.3. Context Mapping

The mechanism used to pass data from one context
to another is called Context Mapping. As context elements are in general only visible for the controller the
121
are made, modifications of the mapping relation have

to be done at the context in which the mapping relation starts. Consequently the context that is mapped
does not even have any knowledge about the mapping at all.
Nonetheless it is necessary to define a usage relation between the controllers, whose contexts should
participate in a Context Mapping.
In the probable case that structure information are

available not until runtime, it is also possible to define
the Model Binding dynamically at runtime. Therefore
the access to the model classes is gained via generic
methods, so that the identification of model elements
is exclusively based on their names.
3.4. Web Dynpro Model
The Model Binding is used to access the model and

for that reason it links the model with a controller context. In the example application shown in figure 3 on
page 4, the Model Binding is defined between the custom controller context and the model. Thus the storage elements with the number 4, 7 and 9 participate
in the Model Binding. In contrast, the storage with
the number 8 is a context element, that has not been
bound, while the storage with the number 10 is an unbound model element. As it was already discussed
for the Data Binding and Context Mapping the assignment of one storage address for both bound elements
redundantizes any data transport.
3.5. Model Binding
Figure 6. Web Dynpro Model

Before the focus turns to the third type of dataflow,
the Model Binding, the Web Dynpro model itself
should be discussed. The model is a data structure
that represents the data and the functionality of the
backend, for instance a web service provider or a
ABAP 4 backend server. As it can be seen in figure 6, the model consists of model classes which on
their part contain other model classes and model attributes. The model classes are Java classes which can
be grouped in executable and non-executable classes.
Nevertheless they all have to implement the Common
Model Interface (CMI), an interface that affects mainly
data management and event handling [8].
If the structure of the model is already known at
design time, the CMI implementing model classes
contain typed getter- and setter-methods similar to
Java Beans5 . Therefore a typed access to the classes
is provided. The availability of information about
the model structure allows it to declaratively define
a Model Binding in the way it is described in 3.5.
Figure 7. Model Binding

Regarding figure 7, on the one hand context model
attributes can be bound to attributes of the model. On
the other hand context model nodes can be bound to
model classes. Similar to the Context Mapping, it is
necessary to state a Model Binding relation between
the parent node of a context model attribute and the
parent model class of the model attribute to bind the
attributes.
4 Advanced Business Application Programming (ABAP) is a programming language created by SAP, which is positioned as the language for programming SAPs Web Application Server.
5 Java Beans are reusable software components, for which a specification have been defined by Sun Microsystems.
122
3.6. Model Import and Connections to the Model
J2EE based Web Dynpro Runtime [9]. To call procedures from a J2EE backend server, Remote Method
Invocation (RMI) is used. The data transfer to a web
service is done via SOAP, which is described in detail
in [10]. Moreover a ABAP backend server can not be
accessed directly. For that reason a middleware component named SAP Java Connector (JCo) is required
to generate RFCs out of Java calls and vice versa.
As it was already mentioned in 3.4, all model

classes have to implement the CMI. Usually the model
classes are generated by an import wizard, on account
of this the developer does not have to care about the
correct implementation of the CMI. Depending on the
type of the used backend system, the import wizard
can create the model classes out of different model descriptions.
!"
# $
"
#$
Figure 9. Connection to Model (J2EE based)
!
" #
Figure 8. Model Import

In figure 6 the four possible import types are
shown. If the Web Dynpro application should use a
web service, the model classes will be created out of
the WSDL6 description. Concerning the case the developer wants to use existing Web Dynpro UML models a description in the XMI 7 format has to be available, while a RFC8 model is needed to call RFCs directly in an ABAP system. The source code of Java
Beans is directly parsed by the import wizard due to
the similar structure of Java Beans and model classes
implementing the CMI.
On account of the two flavours of the Web Dynpro Runtime the possibilities to communicate with the
model at runtime are potentially restricted. Figure 9 illustrates the conceivable communication flow for the
Figure 10. Connection to Model (ABAP based)

In contrast to the J2EE flavour, the ABAP flavour
of the Web Dynpro Runtime is restricted in its communication to web service providers and ABAP backend servers [9]. While the data exchange with web
services works in the same manner as with the J2EE
flavour, the ABAP backend system can now be accessed directly. Therefore the Business Application
Programming Interfaces (BAPIs), which are standardized methods to gain access to SAP Business Objects,
can be called via RFCs.
6 The
Web Service Description Language (WSDL) is an XML format published by the World Wide Web Consortium (W3C) for describing web services.
7 XML Metadata Interchange (XMI) is an OMG (Object Management Group) standard for exchanging metadata information via
XML.
8 Remote Function Calls (RFCs) are a standardized mechanism
for communication between applications on SAP systems as well as
non-SAP systems.
4. Summary
In conclusion the contexts are the main concept for
the storage, handling and management of data in Web
Dynpro. As contexts describe entities and their relations, they define the structure, the data model, in
123
which all values will be stored. Advanced design

mechanism, for instance singleton nodes, allow creating complex data structures according to the project
domain. Although much of the data modelling can
be done declaratively, the data structure can also be
modified by context programming at runtime.
In addition, there are three possibilities to realize
dataflows in Web Dynpro. Data Binding creates the
link between the properties of user interfaces and controller contexts, that can be connected to another context via Context Mapping. The data and functionality
of the backend system, represented by the Web Dynpro model, can be accessed by defining a Model Binding. Hence the employed backend system can be a
J2EE server, an ABAP server or a web service provider,
an import wizard automatically creates the suitable
model that abstracts the type of the backend system.
Due to this, the discussed data management concepts are the basis for the whole Web Dynpro technology.
References
[1] Introduction to Web Dynpro. SAP Developer Network.
www.sdn.sap.com.
[2] Web Dynpro Architecture.
SAP Library.
www.help.sap.com.
[3] Business
Application
Programming
Interfaces.
tse
technologieberatung
und
systementwicklung, Hamburg, 2005.
http://www.tsehamburg.de/Papers/SAP/sapBAPI.html.
[4] A. Fahle. SAP Web Dynpro: berblick. 2005.
[5] C. Holz. Web Dynpro: Navigation and Komponentenorientierung. 2005.
[6] T. Horn. Application Server, Web Application Server,
Web Services, SOAP, Java. 2005. http://www.torstenhorn.de/techdocs/applicationserver.htm.
[7] T. Horn.
SAP BAPI und SAP JCo.
2005.
http://www.torsten-horn.de/techdocs/sapbapi.htm.
[8] K. Kessler, P. Tillert, and P. Dobrikov. Java Programmierung mit dem SAP Web Application Server. Galileo
Press, 2005.
[9] P. McNulty. Web Dynpro Overview. SAP AG, 2003.
[10] J. Nicolai. Web Services im WebAS. 2005.
[11] P. Tillert. Wiederverwendbare Software (Web Dynpro).
2004. www.sap.info.
[12] P. Tillert. The Basic Facts About Web Dynpro. SAP AG,
2005.
[13] Winkler.
The new face of SAP - Web Dynpro.
2004. http://www.oio.de/web-dynpro-the-new-sapface.htm.
124
J2EE persistence mechanisms of the SAP WebAS

Bernd Schufele
bernd.schaeufele@hpi.uni-potsdam.de
possibilities of the persistence models are limited.

As a consequence of this, there has to be a way to
manage persistence conventionally with SQL
statements. In this case, the developer himself has
to be aware, that the program code is database
independent. Moreover, there usually is no syntax
or semantic checking on the server, but only in
the database. This problem is solved by the SAP
WebAS with the Open SQL Engine. But the SAP
WebAS also allows to run J2EE applications
which have run on another server before and
make use of database specific features.
To assure that Business Applications work
properly, the application data, which is held in a
database, must be consistent. This is even more
important in a cluster of several Application
Servers. That is the reason why there have to be
mechanisms for transactions and locking.
Transaction Services guarantee that transactions,
that means database operations that belong
together, are executed completely or not at all.
Transactions are realized in the SAP WebAS by
the Java Transaction Service (JTS), an obligatory
element of the J2EE standard.
Locking mechanisms prevent that different
users can write at the same time on the same data
or that one user reads data, which is changed at
the same time by another user. The J2EE standard
does not prescribe any locking mechanism. But as
there are several J2EE servers in a cluster and as
various users can be connected to each J2EE
server, a locking mechanism is necessary. This is
the reason why in an SAP WebAS server cluster
there is one central Enqueue Server, which is
responsible for database locking. Furthermore, on
each J2EE server exists a Locking Manager for
communication with the Enqueue Server.
Abstract
In the development process of a Business Application,
there has to be a decision about the way, the application
data is kept persistent in a database. Often applications
should be database independent in order to be able to
use different databases. Therefore, the Java Enterprise
Edition (J2EE) standard defines several mechanisms
which allow database independent persistence, such as
Container Managed Entity Beans. On the other hand,
developers might want to use particular features of a
specific database or use complex persistence models.
For that reason, J2EE also allows to make application
data persistent with common SQL statements.
This paper is intended to explain the J2EE
persistence mechanisms and how they are realized in
the SAP Web Application Server (SAP WebAS).
Furthermore, it will be explained which additional
persistence features are offered by the SAP WebAS and
which solutions for essential issues of persistence, such
as transactions and locking, exist in the SAP WebAS.
Keywords: Persistence, J2EE, SAP WebAS, Entity
Beans, Database
1. Introduction
Often the development of a Business Application
begins with the design of the business logic and
the user interface. Developers tend to leave the
decision about how to keep the application data
persistent for later. The reason for that is mostly
the fact, that during development it is not yet sure
which database will be used later. Concepts
which allow database independent applications
facilitate development as well as administration,
since the database can be exchanged without any
problem.
With Container Managed Entity Beans, J2EE
Servers offer a strong concept to solve this
problem. But as persistence management is left
completely to the Web Application Server, the
125
However, object-relational persistence gives an

object-oriented view of persistent data. Mapping
objects and relations to relational databases
usually is automatic and transparent to the
developer, so that storing, loading and navigating
can also be performed transparently. With objectrelational persistence, a very high level of
separation between the business and the
persistence logic of an application is achieved.
Complex relationships between objects can be
made persistent without the developer having to
mind.
Since Java is an object-oriented programming
language, a J2EE server of course provides
mechanisms for object-relational persistence. The
SAP WebAS supports Enterprise Entity Beans,
that are mandatory in the J2EE standard and will
be treated later in this paper. Furthermore, Java
Data Objects (JDO) are supported. They are topic
of another seminar contribution. [JDO]
2. Persistence theory
2.1. Persistence
Persistence means storing transient data, which is
usually held in the main memory of a computer,
in a non-transient storage, for example a database.
Without persistence mechanisms, the application
data is lost, when an application is terminated. In
a server environment, such as provided by the
SAP WebAS, after closing a session, the data of a
user must also be available for further sessions.
There are two major persistence concepts. The
first one is relational persistence and the second
one is object-relational persistence.
2.2. Relational persistence

Relational persistence has its origin in database
technology. Most databases themselves use a
relational model of data storage. The so-called
relations are the tables of the database. In
application development, relational persistence
means, that the developer has the view of the
database tables without abstraction and that the
programmer has to deal with database tables.
The most important advantage of relational
persistence is the possibility to decide, how the
data is stored in the database tables and how it
can be retrieved from there. That way, relational
persistence is efficient and flexible. On the other
hand, the developer is forced to program
additional code to access the database. That is
often not very comfortable and costs a lot of time.
Relational persistence is provided by the SAP
WebAS through the Open SQL Engine and the
Vendor JDBC Layer. [SLIB]
3. Persistence architecture of the

SAP WebAS
3.1. Architecture of the SAP WebAS
As shown in Figure 1, the SAP WebAS consists of
three layers, the Presentation Layer, the Business
Layer and the Persistence Layer. The Presentation
Layer is the interface between the user and the
application. It should be held completely free
from the business logic of the application.
In the Business Layer, the actual work of a
Business Application is done. This is the place
where the business logic of the application is
hidden. But the Business Layer also offers
abstractions of the underlying Persistence Layer.
Entity Beans and Java Data Objects can be found
in this environment, as you can see in Figure 1.
The third and lowest layer is the Persistence
Layer. In this layer, the abstraction of the database
takes place. It offers several mechanisms to access
the database. This can be done either in a
standardized database independent way or also
using query language statements that can only be
understood by a specific database. The
Persistence Layer itself consists of three layers, the
Vendor JDBC Layer, the Native JDBC Layer and
the Open JDBC Layer, as shown in Figure 2.
Those three Layers allow different levels of
abstraction.
Moreover, there are components that cannot
2.3. Object-relational persistence

The counterpart of relational persistence is objectrelational persistence. It has its origin in objectoriented programming. In object-relational
persistence data is represented by objects with
relations between them. As in most cases,
relational databases are used, these objects have
to be mapped to relational database tables. In this
case, object-relational persistence is only an
abstraction to make development with persistent
data easier; objects are stored in relational
databases and can be accessed like persistent
objects. Object databases can also be used, in
which the persistent objects can be stored without
mapping.
126
Additional services
Presentation Layer
JSP
Servlets
Web Dynpro
Business Layer
Data types
&
Structures
EJB Container
Session bean
Enqueue
Server
Locking
Manager
Java
Java
Transaction
Service
(JTS)
Entity beans
JDO
Dictionary
Database Layer
Open SQL Engine
R
R
Database
metadata
Vendor JDBC
R
DBMS
Database
DB Catalog
Figure 1 Architecture of the SAP WebAS
be assigned to a specific layer, such as the Java

Dictionary, the Locking Manager or the Java
Transaction Service. They are also referred to as
Cross Layer components.
Therefore, SQL queries that are only supported by

a specific database vendor can be used with the
Vendor JDBC Layer. All databases, for that a
JDBC driver exists, can be applied. Nevertheless
for a set of databases, the JDBC drivers were
tested intensively and are recommended by SAP.
These are the JDBC drivers of the most common
databases.
The Vendor JDBC Layer offers an important
advantage: the encapsulation of database
connections with the so called Connection Pool.
Databases can only hold a limited number of
connections and initializing a connection is a
time-expensive operation. With the Connection
Pool, a connection is not closed, when it is not
needed any more, but is pooled and can be reused
for further database requests. Connection Pooling
3.2. Vendor JDBC Layer

The Vendor JDBC Layer, as illustrated in Figure 2
is the lowest level of abstraction in the Persistence
Architecture of the SAP WebAS. With regard to
the JDBC1 driver, it offers no abstraction, but
contains the JDBC driver of the database vendor.
SQL queries are directly passed to the
database without syntax or semantic checking.
Java Database Connectivity (JDBC) is explained more
detailed in chapter 3.4
127
is part of the J2EE standard. Connections Pools

are defined once by the developer. Usually, one
Connection Pool is used per database. A minimal
and a maximal number of connections in the pool
can be set, as well as authentication information,
to keep it away from the business logic of
applications. Connection Pools have a logical and
unique name that is saved in the Java Naming
and Directory Interface (JNDI). [SLIB]
overwritten. The configuration can also be

changed.
SQL statements are saved in the SQL Trace
with input parameters and results and when, how
long, by whom, in which session and in which
application they were executed. The SQL Trace
can be evaluated and administrated with a web
browser. Filters can be set on the information for
evaluation. The filters can be set on sessions,
applications users and access duration. Each SQL
query can be analyzed in detail. Besides
performance analysis, the SQL Trace can also be
used to find out, which SQL statements are
produced automatically by more abstract
persistence mechanisms, such as Entity Beans.
As the SQL Trace produces vast amount of
data and costs performance, the SQL Trace can
also be turned off and existing information can be
deleted. Usually, it is not turned on during
normal server operation.
The Statement Cache facilitates performance
improvement with Prepared Statements. Usually,
a Prepared Statement is used, if several similar
queries have to be executed in succession. Of
course it can also be exactly the same query,
which has to be executed several times. A
3.3. Native JDBC Layer

The Native JDBC Layer is an encapsulation of the
JDBC driver. But just like in the Vendor JDBC
Layer SQL queries are directly passed to the
database. Compared with the Vendor JDBC
Layer, the Native JDBC Layer offers the services
Figure 2 Architecture of the Persistence Layer
of Statement Caching and the SQL Trace, as you

can see in Figure 2.
The SQL Trace is a statistic tool to analyze the
database usage. It logs the SQL statements that
are issued against the database. In the standard
configuration the information is stored in ten files
of which each has 10 MB of size . If the last file has
reached its maximal size, the first one is
Figure 3 Petri net describing a Prepared Statement query

with Statement Cache
128
Prepared Statement looks just like a normal SQL

statement, but the WHERE-clause can include
parameters. The database ascertains the optimal
work flow for the execution of the Prepared
Statement. After that, the Prepared Statement can
be executed several times and the database
doesnt have to calculate the work flow again.
Without Statement Cache, Prepared Statements
are closed and deleted after usage.
As connections to the database are not
released, but are held in the Connection Pool, also
the Prepared Statements are not discarded by the
database. Therefore, in the SAP WebAS, the
close()-command does not really close the
Prepared Statement, but leaves a logical handle
onto it in the Statement Cache.
Figure 3 shows, that, when a Prepared
Statement call is executed in an application, at
first a lookup in the cache is performed. Only if
no matching Statement is in the Cache, the
database really creates a new Prepared Statement.
Otherwise the existing Prepared Statement is reinitialized, marked as used in the Statement
Cache and marked as unused again after the
close()-statement If it has been a new Prepared
Statement, a logical handle is created in the
Statement Cache. As the Statement Cache is very
close related to the database connections, there is
one Statement Cache per connection. Prepared
Statements are used intensively in the
implementation of JDO, Entity beans and SQLJ.
Hence with the utilization of them, performance
improvements can be achieved.
3.4. Open JDBC Layer

The Open JDBC Layer can handle both JDBC
statements and SQLJ statements. For that, at first
the difference between JDBC and SQLJ will be
explained.
JDBC is the common way to access databases
in a Java application. JDBC is just an Application
Programming Interface (API), which does not
define syntax and content of the database query.
SQL statements are expressed as common Java
Strings, that are sent to the database, interpreted
there and answered with ResultSets. Hence also
dynamic queries are possible with JDBC and
database specific SQL statements can be used.
On the other hand, SQLJ follows a completely
different way. SQL statements are integrated into
native Java Code with the keyword # sql. Java
variables can be integrated with a colon, e.g. :a. As
you can see in Figure 4, the SQLJ-File is translated
by a pre-compiler into a normal Java-File, which
can be translated with the common Java
Compiler. The SQLJ statements are converted into
calls to the SQLJ Runtime. The SQLJ Translator is
transparently integrated into the SAP NetWeaver
Developer Studio, while the SQLJ Runtime is part
of the SQL processor. As the SQLJ Translator
performs syntax checking of the SQL statements,
only statements that are conform to the Open
SQL-grammar are allowed, which is based on the
ISO standard SQL 92. This is a limited SQL
grammar, which should be sufficient for most
applications. Moreover, only static SQL
statements are possible. The SQLJ Translator also
checks the database schema with help of the
offline catalog provided by the Java Dictionary.
Figure 4 Block diagram of the translation and execution of SQLJ files
129
The Open JDBC Layer, in contrast to the

Native and Vendor JDBC Layer supports only the
SQL 92 standard for JDBC queries, too. Therefore,
also syntax checking can be performed for JDBC
queries, as well as semantic checking, but only at
runtime and not at design time, like for SQLJ
queries. As that way syntax and schema errors are
already detected in the J2EE server, they do not
lead to database errors. Database specific SQL
statements cannot be utilized with the Open JDBC
Layer, for this the Native or Vendor JDBC Layer
have to be use used.
Besides the advantage of syntax and semantic
checking, the Open JDBC Layer provides another
advantage, the Table Buffer. The Table Buffer is a
local cache, which exists on each server node in a
server cluster and is shared among all threads of a
server. Already during design time, decisions
about which tables should be held in the Table
Buffer take place with help of the Java Dictionary.
Besides whole tables also database areas or
single rows can be held in the Table Buffer. The
developer has to specify this Buffer Granularity.
The Buffering happens completely transparent. If
the data requested by a database query is already
in the Table Buffer, no database communication is
necessary. At the first time, a matching database
query is executed, the concerning data has to be
loaded from the database. Only database queries
that refer to one table use the Table Buffer.
Database queries which refer to more than one
table or that contain subqueries or other complex
statements bypass the Table Buffer and are
interpreted by the database.
As there is a Table Buffer on each server node,
changes of buffered data should be propagated to
all nodes of a cluster, to avoid inconsistency. This
is realized with a buffer synchronization
mechanism. Changed data is set invalid on
remote nodes. Just when this data is required
again on another node, it is loaded newly into its
Table Buffer.
If a database change is rolled back, this is also
propagated to remote hosts. Since only an invalid
flag has been set, the rollback can be performed
easily in the remote Table Buffers by removing
the invalid flag. Obviously changing buffered
data produces a lot of communication between
server nodes. It follows that Table Buffering
should only be used for tables, onto which hardly
any writing access will be performed.
4. Entity Beans
The J2EE standard provides Entity Beans for Java
object persistence. One Entity Bean instance
represents one database table row of the
underlying relational database persistence, while
an Entity Bean class represents one table. Entity
Beans can be accessed by various clients
concurrently and remain persistent beyond a
client session. Different from Java Data Objects,
Entity Beans always run in a managed
environment, the EJB container. As they offer
object-relational persistence, J2EE applications
with persistent objects can be developed very
easily with them. The persistent data can be
accessed uncomplicated from Session Beans with
Get, Set and Find methods. Also relationships
between objects can be held persistent easily with
Entity Beans. There are two types of Entity Beans,
those which use Container Managed Persistence
(CMP) and those which use Bean Managed
Persistence (BMP).
Entity Beans, like all Enterprise Java Beans
(EJB), besides the class implementation in Java
code, are defined in the ejb-jar.xml Deployment
Descriptor. This Deployment Descriptor offers
important information to the EJB Container about
the Entity Bean, such as name, persistent fields,
primary key and relations to other Entity Beans.
There is a Home Interface for each EJB, thus
also for Entity Beans. It acts as a bean factory and
hence provides a way to create, destroy and find
Entity Bean objects. There are Local and Remote
Interfaces dedicated to calls from local or remote
clients. These Interfaces are not implemented by
the Entity Beans themselves, but objects that
correspond to these Interfaces are provided by the
EJB Container.
Often applications need to find certain
persistent data, e.g. information about a customer
with help of the Customer ID in an online-shop
application. For this purpose, Finder Methods
exist. Each Entity Bean class must at least have a
findByPrimaryKey() method. Additional Finder
Methods, e.g. findByName(), can be defined. These
methods are defined in the Home Interface,
starting with the key expression find. The
respective EJB class, then must include a method,
which begins with the keyword ejbFind, e.g.
ejbFindByName(). Find methods return references
to Entity Beans. As all Find methods, except
findByPrimaryKey(), potentially return more than
one object, the type of the return value should be
130
Collection or Enumeration. They have to be

implemented manually or are provided by the
EJB Container, depending on whether BMP or
CMP is used.
clearer. Additionally, the source code is also

absolutely database independent. Thus, it can
easily be ported to different databases.
Consistence and integrity of the data are
assured automatically by the EJB Container as
well as synchronization for concurrent access in a
cluster. The developer does not have to bother
about loading and storing of data. But if some
additional activity should be executed after
loading or before storing data, these activities can
be specified in the ejbLoad() method, respectively
the ejbStore() method of an Entity Bean.
The Find methods do not have to be written
explicitly by the developer. The EJB container
generates all required methods, which are
declared in the ejb-jar.xml Deployment Descriptor.
This is depicted in Figure 5.
Since the container cannot infer automatically
by the method name, which activity is desired,
this has to be specified in a certain way by the
developer. For that reason, an own language, the
EJB Query Language (EJB QL) has been
developed. EJB QL statements are similar to SQL
statements, an example for an EJB QL statement
would be Select object (p) from EmployeeBean p.
These statements are placed in the ejb-jar.xml
Deployment Descriptor together with the
declaration of the Entity Bean. Of course these EJB
QL statements do not refer to the database model,
but to the object model, that is defined in the
Deployment Descriptor.
4.1. Container Managed Persistence

(CMP)
Container Managed Persistence is also called
declarative persistence [SLIB]. This means, that the
developer does not have to write SQL queries
himself. Instead he defines the Entity Beans. The
corresponding tables have to be created once and
the mapping between the object model and the
relational model has to be performed once in a
declarative way in the Deployment Descriptor.
Therefore, CMP can be used easily if the object
model of the data, that shall be persistent, is very
complicated. There are certain restrictions to the
mapping in order to make it easier to handle The
J2EE Object/Relational (O/R) Mapping Rules
restrict the mapping of Entity Beans and Relations
to database tables, e.g. each field of an Entity Bean
has to be stored in a single database row and only
binary relations are allowed between Entity
Beans. While the declaration of the Entity Beans
can be found in the ejb-jar.xml Deployment
Descriptor, the declaration of the database tables
and the mapping between Entity Beans and tables
is defined in the persistent.xml file.
The required SQL statements are created
automatically by the CMP Manager. For that
ordinary JDBC commands are generated. Using
Container Managed Persistence, the persistence
and business logic can be separated completely.
No SQL statements are used inside the Entity
Beans source code, which makes the latter much
4.2. Bean Managed Persistence (BMP)

Bean Managed Persistence does not offer the
mentioned facilities. It is more difficult to use, but
allows more freedoms, as one can and has to
write the SQL queries himself. Therefore, BMP is
called a programmatic persistence [SLIB]. The usage
of BMP should be considered very carefully. It
can be recommended if more complex or database
dependent interactions with the database are
required. If the J2EE O/R Mapping Rules shall
not be applied, BMP has to be used.
Using BMP, much more code has to be
written by the developer himself compared with
CMP. A lot of things that are realized implicitly
by the EJB Container for CMP have to be realized
explicitly by writing Java code. All the ejbLoad,
ejbStore, ejbFind methods etc., that deal with
database operations, have to be implemented in
the Entity Bean class.
Business Layer
Deployment
Descriptor
EJB Container
ejb-jar.xml
persistent.xml
CMP
Manager
Session bean
Entity beans
JDO
Manager
JDO
Persistence layer
Figure 5 Infrastructure of the Business Layer

for Entity Beans and Java Data Objects
131
Concerning 1:n relationships, the table of the bean

that has the multiplicity n contains the primary
key of the other table as foreign key. If an n:m
relationship shall be mapped, a helper table is
mandatory. Its columns should be foreign key
columns that reference the primary key columns
of the tables, to which the beans that participate in
the relationship are mapped.
4.3. Developing Entity Beans

Almost all activities for Developing Container
Managed Entity Beans can be performed using a
Graphical User Interface in the SAP NetWeaver
Developer Studio. As shown in Figure 6, there are
two major components in the Developer Studio
that allow the development of Entity Beans. These
are the Dictionary Explorer and the J2EE explorer.
5. Java Dictionary
The Java Dictionary is a central storage, in which
database objects, data types and structures can be
defined. It provides additional information in
comparison to the vendor-specific database
catalog of the database used. This allows the
developer to describe data types redundancy-free
and independently of the program code. The
defined database structures and data types are
absolutely platform independent, the description
system is based on XML.
Elementary data types and structures of the
Java Dictionary can be used for user interfaces
and Web Dynpro2 in the Presentation Layer. If a
data type of the Java Dictionary is assigned to an
input field, the type of entered values is
automatically checked by the Web Dynpro
runtime. Dropdown menus with possible values
are shown automatically to the user, if a type with
a limited range of values is used. Also the field
names can be derived automatically from the
information about a persistent field in the Java
Dictionary.
The Java Dictionary allows different versions
of the metadata of database tables and fields. This
is useful because during the development of an
application, it usually is not run on only one
database, but e.g. on developer databases, testing
databases etc.
Type checking in the Open SQL Engine is
performed with help of Java Dictionary
definitions, too. As the SQLJ Translator compares
table names, column names and data types of the
SQL statements with the Java Dictionary,
semantic security is provided already during the
development. JDBC queries can at least be
checked at runtime, so that database errors are
avoided. For JDO and Container Managed Entity
Beans, the consistence with the corresponding
Deployment Descriptor is assured.
Figure 6 Developing CMP Entity Beans in the

Developer Studio.
In the latter, Entity Beans can easily be defined,

with all their fields and methods, as well as the
EJB QL statements for the Find methods. All
information about the Entity Beans and the
relations is stored in the Deployment Descriptor
in the ejb-jar.xml file. As the relations are also
managed by the Container, they are referred to as
Container Managed Relationships (CMR). Only in
very rare cases, e.g. for relationships, which can
be navigated in both directions, the developer has
to make changes himself in the ejb-jar.xml file.
The tables can be defined in the Dictionary
Explorer. The definition of the tables is saved in
the persistent.xml Deployment Descriptor. While
the ejb-jar.xml file is obligatory to the J2EE
standard, the persistent.xml file is a SAP-specific
Deployment Descriptor. The Dictionary Explorer
offers mapping Entity Beans to database tables.
This happens almost automatically, if the
Dictionary Explorer can find a table with columns
that match the persistent fields of the Entity
Beans.
Also the mapping of CMR between Entity
Beans to database relations can be defined in the
Dictionary Explorer. Only binary relationships are
allowed and usual mapping rules between
relational models and databases are applied. For
1:1 relationships, one of the two tables contains
the primary key of the other table as foreign key.
2 Web Dynpro is SAPs new approach for web application

development with visual tools. [WDYN]
132
As the data types of the different layers do not

always fit completely, e.g. Java data types and
database data types, the Java Dictionary also
provides common data types, such as String or
Integer. For example, these data types are used by
Web Dynpro. The Java Dictionary data types are
mapped to the respective data types of each layer.
(JTS). For persistence that is handled in a

programmatic way, it offers another API: the Java
Transaction API (JTA). JTS also allows to manage
and execute transactions from other servers, not
only local transactions, as they can be performed
with JDBC or SQLJ.
But the most important advantage of JTS is
obvious when it is used together with Container
Managed Persistence since it allows Container
Managed Transactions (CMT). For EJB Session
Beans it is possible to choose, whether to use
Container or Bean Managed Transactions, but
Entity Beans are not allowed to use Bean
Managed Transactions (BMT). With CMT,
transactions always refer to complete methods.
There are six different transaction values, which
can be associated with a method in the
Deployment Descriptor, NotSupported, Supports,
Required, RequiresNew, Mandatory and Never.
The behavior of the bean depends on the value
of the invoked method and on whether there is a
transaction already running. If the value of an
invoked method is NotSupported and a transaction
is already running, this transaction is interrupted
and resumed afterwards. Methods with a Supports
value only run in a transaction, if there is already
a transaction running. With Required, a new
transaction is created before executing the method
if no transaction is already running. RequiresNew
means that a new transaction is automatically
created by the container when the method is
invoked. For methods that are declared as
Mandatory, a transaction must already be running
on invocation. Otherwise, an exception is thrown.
Never is exactly the opposite, here an exception is
thrown when the method is invoked within a
transaction.
Hence the JTS used in combination with
Container Managed Transactions offers a very
easy but also exactly adjustable way to handle
transactions. It is highly recommended that CMT
is used. Only if various transactions have to be in
one method, Bean Managed Transaction should
be utilized. A more detailed explanation of
transactions in a J2EE server can be found in
[TRS].
6. Transactions
Transactions are defined as a set of operations,
which fulfill the four ACID Properties: Atomicity,
Consistency,
Isolation
and
Durability.
Transactions are a very important issue
concerning databases and persistence.
Atomicity means, that all operations of a
transaction must be executed successfully, or
none of them is executed at all. This means that if
one operation fails, all other operations must be
rolled back, too. For example, if in a bank transfer
transaction the debiting is successful but the
crediting fails, the debiting must be rolled back,
too.
Consistency implies that a resource that has
been in a consistent state before a transaction,
must also be in a consistent state after it. The
Isolation property requires, that concurrent
accesses to the same resource must be isolated
from each other. Changes made in a transaction
may not be seen by other transactions, before it
has terminated. Durability means that results of
transactions have to be kept persistent, even in
case of system failure.
Isolation and durability are realized differently
in each context. Isolation of concurrent access to
Entity Beans by different users is realized by the
EJB container while it is realized by locks for the
database. The locking mechanisms will be
explained more detailed in chapter 7. Durability is
assured by most modern database systems with
logging techniques.
Concerning atomicity
and consistency,
different approaches can be used in the SAP
WebAS. If persistence is not Container Managed,
but realized by the developer using SQLJ or
JDBC, these programming approaches, offer an
API to realize transactions. In both cases the
AutoCommit mode of the database connection
has to be disabled. Both APIs offer statements to
commit a transaction and to roll it back, if an
exception occurs.
Moreover, there is a third possibility to
manage transactions, the Java Transaction Service
7. Locking
Locks guarantee that two transactions that are
running concurrently do not affect each other.
Locks can be set on database table rows before
reading or writing access. Usually, databases offer
133
several isolation levels by which the degree of

isolation between two transactions is determined.
As the database vendors of the databases that are
supported by the SAP WebAS do not have the
same semantic for locking, the SAP WebAS does
not utilize database locks for isolation, but it
provides own Logical Locks. Thus, database
locking mechanisms should be operated on a
weak level.
These Logical Locks are administrated by the
Enqueue Server. Logical Locks can be set for
single database table rows or for table areas. Read
and Write Locks are distinguished. While there
can be several Read Locks for the same data at the
same time, there can only be one Write Lock.
Read and Write Locks are mutually exclusive.
Each J2EE server has a Locking Manager. It is
a wrapper for manipulating locks on the Enqueue
Server. This server, that exists once per server
cluster, either on the Central Instance or as
Standalone Enqueue Server, administers locks
with the lock table, as you can see in Figure 7. The
Enqueue Server checks the lock table when it
receives a lock request in order to determine
whether the lock request collides with an existing
lock. If there is a collision, the lock is rejected.
Otherwise, it is granted and an entry in the lock
table is set. The lock table is a shared memory of
the Lock Server (Central Instance or Standalone
Enqueue Server).
The Enqueue Server is realized by one process.
Other processes on the Lock Server access the
Lock Table directly without the Enqueue Server

Process, while the Enqueue Server Process is
responsible for requests from external servers.
8. Conclusion
The SAP WebAS offers a wide range of
persistence mechanisms. It supports both
relational and object-relational persistence. The
developer can decide whether to handle
persistence in a programmatic way or leave the
persistence completely to the EJB container, with
CMP Entity Beans or JDO.
Hence persistence can be handled very easy
and comfortable without having to bother much
about programming, or it can be handled very
freely, allowing complex persistence scenarios
and database specific queries. With the Open SQL
Engine, also when persistence is realized by
programming own SQL statements, syntax and
semantic of them can be checked during
development time and runtime. Furthermore, the
Java Dictionary provides a facility to define
database metadata and data types centrally and in
a database independent manner. Moreover, the
Java Transaction Service and the Enqueue Server
allow to handle these important persistence
concerns absolutely database independent. For
these reasons, the SAP WebAS offers a complete
environment for handling persistence of
Enterprise Applications.
References
[SLIB] SAP Library, http://help.sap.com
[JPWAS] Karl Kessler, Peter Tillert and Panayot
Dobrikov, Java-Programmierung mit dem SAP Web
Application Server, SAP Press/Galileo Press, 2005
[JEN] Jim Farley, William Crawford, David Flanagan,
Java Enterprise in a Nutshell, OReilly (2002)
[JDO] Stefan Marr, The JDO Persistency Model, 2005
[WDYN] Christian Holz, WebDynpro, Navigation and
Component-Orientation, 2005
[TRS] Silvan T. Golega, J2EE Transaction Services, 2004
[EJBC] Lukas Neitsch, Enterprise JavaBeans und ihr
Container, 2004
[WASA] Benny Schaich, SAP Web Application Server
Architecture, Presentation, 2003,
https://www.sdn.sap.com
[DEPL] Ralf Gldemeister, Enterprise Java Beans and
their Deployment using SAP NetWeaver
Figure 7 Server Cluster with Enqueue Server
134
The Java Data Objects Persistence Model

Stefan Marr
stefan.marr@hpi.uni-potsdam.de
Abstract
persistence itself.
JDO is a specification for design object domain models

without having to consider the persistency of data. The
main target of JDO is the abstraction of concrete data
storage solutions and the provision of transparent and
implementation-independent solutions for persistent
data.
Starting with an introduction to the architectural
model of Java Data Objects, benefits of this approach
and the realization by a tool-based enhancement are
outlined. Furthermore, the API itself is in focus of
examination, main programming interfaces and the
JDO-QL will be discussed.
Finally, it is aimed to give an outlook on the upcoming JDO 2.0 specification.
2. JDO
2.1. What is JDO?
The Java Data Objects (JDO) API is a standard
interface-based definition of object persistence. It
describes the transparent storage and retrieval of
Java objects.
JDO is intended to provide transparent
mechanisms to persist the whole object domain
model of an application, including mapping of
JDO instances to data
storage and implicit
updates of persistent
object states.
It is intended to
reduce most efforts of
introducing
a
persistence layer by
the use of automated
enhancements.
Figure 1 is a
simplified example of
a typical application
using
JDO
as
persistence
service.
The
[JDOSPEC]
requires
all
JDO
implementations to be
binary
compatible. Figure 1 Structure of a
Thereby, it is possible JDO-based application
to exchange a specific
JDO implementation and start to use another type
of datastore without the need to recompile.
A JDO implementation, delivered by a thirdparty vendor is highly optimized on a particular
data storage system like common RDBMS
ODBMS or maybe XML-based file storage
depending on the area of application. The
Keywords: Java, Persistence, JDO, Database,

Code Enhancement
1. Introduction
Persistence of data is one of the main
requirements of business application software.
Relational databases are the most commonly used
systems to meet these requirements. They are
wide spread and highly optimized for
performance and reliability.
However, the use of RDBMS requires mapping
of business object models to a specific database
schema and introduces complexity and
dependencies into the development process and
the resulting product. This leads to a reduced
exchangeability of the used data storage which
delimitates the reusability and spectrum of
applications.
So, an effort should be the introduction of a
standardized abstraction layer. This makes you
independent of a specific data storage type,
disposes the necessity of mapping your object
model on a data schema, and reduces the
modeling and programming complexity for
135
functionalities. The operations like creating,

finding, modifying, or storing persistent objects
are covered by the JDO API. Initial operations like
make an object persistent or delete it from the
introduced abstraction layer results in an

application which is independent of a single data
storage type and could be used with a variety of
different kinds of these systems.
Figure 3.1 Persistence without and with JDO
Figure 3.2 Persistence with JDO
data store are realized by the JDO

PersistenceManager interface. A small introduction
to the main interfaces is given in a later section of
this paper.
This architecture results in a storage-type
independent object model and provides access to
persistent data objects without knowledge of
internal mapping or data store specific query
languages.
2.2. Advantages of using JDO

In Figure 2 a FMC based block diagram is
intended to visualize the different modeling
efforts. Figure 2.1 illustrates an application, which
uses a relational database system for persistence
and services implementing class specific
persistence methods. Figure 2.2 displays an
application using JDO for data persistence.
The system on the left hand side consists of a
generic persistency manager which implements
the main functionality and a number of class
specific persistence managers which realize the
data storage and retrieval for the class specific
attributes based on a mapping between attributes
and rows in a database schema. For each class in
the object domain model a specific persistence
manager is necessary.
In addition, a transaction service has to be
implemented which might be provided by a used
persistence framework, but in general it is a
service tailored to a specific generic persistence
manager.
Figure 2.2 displays the Java Data Objects way.
Most functionality is realized by the JDO
implementation. The transaction service is part of
the specification and class persistence is
implemented by transparent techniques. There is
no programming or modeling effort to get these
2.3. Environments for JDO

JDO is intended to be used in two types of
environments, non-managed and managed
environments.
In
a
non-managed
environment
the
application is directly connect to resources it
needs and it is responsible for invocation of
persistence actions on objects or configuration of
connections to resources. In such environments
the programmer and application are independent
of e.g. J2EE container technologies but have to
handle all interactions with the underlying
persistence service.
In contrast to this, managed environments like
J2EE-based multi-tier applications provide, in
conjunction with the used container, special
mechanisms for declarative configuration of the
persistence service in use.
Depending on the used container, the
136
should be persisted in a database with all

associated items. Therefore, no changes have to be
made on the domain model, neither by changes
on attribute visibility nor by adding special
persistence methods and attributes.
All necessary changes for realizing persistence
will be added by the enhancer and do not
influence the Java object model. The developer
has to create an XML-file which names and
describes the classes to be persisted. Depending
on the used JDO implementation, there are
several vendor-specific extensions to the XML-file
possible. In some cases it is necessary to build a
new application upon an existing database
structure and the developer will have to map his
class attributes on a database schema.
Furthermore,
the
specification
provides
additional settings for persistent fields. It is
possible to control the persistence behavior in
more detail. Especially for collections and arrays
handling and type of included objects has to be
specified. In addition, the object identity type can
be specified. For all unspecified details default
settings are used.
After creating the JDO Metadata the developer
can initiate the enhancement process. According
container
itself
takes
responsibility
for
configuring the service, managing transactions,
providing security services, or pooling of
PersistenceManagers.
The JDO transactions are harmonized with
J2EE transactions. It is up to the programmer to
decide, which type of transaction will be used.
JDO implementations can synchronize there
transaction to distributed J2EE transactions.
Standards like EJB, JSP, Servlets, CMT, and BMT
are supported and JDO is designed to be used in
such environments.
2.4. The Class Enhancement

The benefits in modeling and programming are
achieved by an automated enhancement process.
The JDO specification requires every JDO
implementation to provide an enhancer tool,
which is binary compatible to the standard.
This enhancer tool will work on Java Bytecode
files, the class files.
The structure and an example are shown in
Figure 3. The developer will design a class
according to domain requirements like an order
for multiple items with a given date. This order
Figure 4 Enhancement and its effects
137
3.1. The Persistence Manager
to the named classes, the JDO Enhancer will

modify the Java Bytecode. It will implement the
PersistenceCapable interface and add several
methods and fields to the classes. On the right
side of Figure 3 a couple of effects on data classes
are outlined.
For each persistent attribute a set of getter and
setter methods will be added and executable
code, which accesses the attribute, will be
changed to call the accessor or mutator methods.
With these changes, the added StateManager is
able to guarantee data persistence for all
modifications on a single data object.
Even if it is possible to implement the
PersistenceCapable interface manually it is strongly
recommended not to do so. No methods and
attributes with the prefix jdo should be used
directly in unenhanced code. Most tasks can be
done by using the JDOHelper class instead of
calling these methods and attributes.
Furthermore, it is important to know that JDO
Metadata will be used by the enhancer tool to
identify classes to be made persistence capable,
and some information like mapping rules or other
vendor-specific enhancements are used at
runtime. Therefore, behavior is not specified if the
metadata is changed after initiating the
enhancement process.
The main interface for application developers is

the PersistenceManager interface. It is intended to
be used for all persistence operations on
PersistenceCapable 1
objects
and
provides
overloaded variants of most cache management
and instance lifecycle methods. These methods
manipulate single instances, collections, arrays of
instances, or potentially all applicable instances in
the cache. Besides, it is used to obtain Query,
Extent, and Transaction objects.
Depending on the environment, there are
several ways to retrieve such a manager object. In
non-managed environments the concrete class
JDOHelper makes the PersistenceManagerFactory
available.
A PersistenceManagerFactory object is used to
get an instance of PersistenceManager. Thereby, it
is
possible
to
get
more
than
one
PersistenceManager object from a single factory.
The factory can even implement pooling.
In J2EE environments, it is possible to obtain a
factory from properly configured JNDI (Java
Naming and Directory Interface).
After obtaining a PersistenceManager object the
following methods can be used by an application:
makePersistent()
These methods can be used to explicitly make
transient objects persistent so they will be
stored in the datastore after the transaction
successfully completes. They can only be used
within a transaction, otherwise a
JDOUserException is thrown.
In fact, applications only rarely need to invoke
makePersistent() directly. Usually, newly created
objects are referenced by existing persistent
objects, e.g. via a singleton reference or
membership of a collection. In such cases, the
new object will be transparently made
persistent when the transaction is committed.
deletePersistent()
These methods delete persistent instances from
the database and must be called in the context
of an active transaction. The Java object thus
remains, but no longer represents the persistent
data store entity, which has been deleted.
Unlike making objects persistent, deleting
objects only deletes the specified instances.
3. Using JDO
This part aims to give a short introduction into
the main classes and interface a JDO programmer
has to concern with. Furthermore, the used
concepts for object identity, object lifecycle, and
the JDO-Query Language are outlined.
<<interface>>
PersistenceManagerFactory
creates
1
0..n
creates
0..1
0..n
handles
<<interface>>
Query
uses
0..1
<<interface>>
PersistenceManager
returns
0..n
0..1
creates
0..1
has a
1
1
<<interface>>
Transaction
0..n
<<interface>>
PersistenceCapable
0..n
contains
0..n
<<interface>>
Extent
0..1
Figure 5 Main JDO Interfaces

In 2.4 the enhancement process is outlined which adds the
PersistenceCapable interface to all class meant to be made
persistent.
138
required, which may be provided by pooling via

PersistenceManagerFactory or via methods in a
J2EE environment.
JDO supports two transaction strategies.
Pessimistic transactions are a required feature,
whereas optimistic transactions are an optional
feature.
Therefore, pessimistic transactions are the
default. They are suitable for short-living
transactions. Typically, there is no user interaction
or other blocking operations between start and
end of a transaction. This type of transaction will
exclude other transactions from accessing data,
which is accessed within.
When working with long-living transactions, it
is often unacceptable to deny access on data used
within this transaction, the complete period of
time the transaction lasts. To reduce such data
locking, optimistic transaction will not lock the
accessed data. They may be implemented with
native optimistic transactions of the underlying
datastore or they are implemented using two
pessimistic transactions.
The first pessimistic transaction is used to get
the current state of used data objects from the
data storage. This state will be saved for later data
integrity checks.
After doing all modifications on the persistent
objects over a longer period of time, the second
pessimistic transaction is started. This one will
retrieve the actual state from the datastore and
compare it with the saved data. If the data
integrity is ensured, all operations done on the
data objects will be committed. Otherwise, a
concurrent operation has changed the data in the
datastore and the whole optimistic transaction
failed and an exception will be thrown.
A transaction object can be obtained from the
PersistenceManager
by
invocation
of
currentTransaction(). With begin() and commit() a
demarcation of actions belonging to a transaction
is done. rollback() is used to discard modifications
on persistent objects in an erroneous transaction.
There is no reach-ability algorithm; referenced

persistent objects are not deleted.
To emulate this behavior, the InstanceCallbacks
can be used to implement the jdoPreDelete()
method to delete referred objects.
makeTransient()
Make a persistent instance transient again. This
does not affect the underlying data store entity
in any way. It does not delete the data. The
instance will be disassociated from the
datastore only, and any subsequent changes to
the instance will not be synchronized with the
datastore.
evict() or evictAll()
Evict the given or all cached persistencecapable instances from the cache.
However, eviction is only a hint to the
persistence manager that an instance should be
removed from its cache. By default persisted
objects are automatically evicted, and it is not
necessary for an application to do it
programmatically.
refresh()
These methods re-retrieve the values of the
fields from the datastore for the specified
instances, whether or not they have been
already modified in the current transaction.
Furthermore, there are additional methods which
will be discussed in more detail e.g. in
[JDOAW2003] and [JDOPH2003].
3.2. Transactions
A transaction is a group of modifications on
persistent objects; these modifications must be
completed in its entirety or not at all. The
demands for ACID (Atomic, Consistent, Isolated,
Durable) have to be met.
Most resource managers allow different levels
of isolation. Nevertheless, developers should not
rely on any isolation level greater than Read
Committed, because JDO does not explicitly
specify the isolation level that will be applied.
On isolation level of Read Committed, state
changes of persisted objects within a transaction
cannot be seen by other transactions until a
commit has been issued.
Per PersistenceManager, only a single
transaction is possible at a time. Furthermore,
JDO does not support the concept of nested
transactions.
To work with concurrent transactions
additional PersistenceManager instances are
3.3. Object Identities

JDO provides three different kinds of identity for
persisted objects. This is done to improve the
transparency and the mechanisms provided by
Java for identity (==) and equality (equals())
remain unaffected.
The default type of object identity is called
Datastore Identity. A unique Identity is assigned
139
required by the specification. For instance

Persistent-Nontransactional, Transient-Clean, and
Transient-Dirty are optional states and are only
required if a specific JDO implementation
provides associated optional features.
In this section, only required states and state
transitions are treated, which are also shown in
Figure 5.
to an object when it is made persistent. The nature

of this Object-ID is handled internal by the JDO
implementation and the underlying data store.
Theoretically datastore identity corresponds to
primary-keys in RDBS.
Application Identity is the second and most
complex type of object identity. It is used, if the
object identity is derived from a subset of
persistent fields of an object or created outside of
the application, like ISBN.
For this type of identity, it is necessary to
implement a specific Object-ID class, which fulfils
special requirements. The Object-ID class has to
implement the java.io.Serializable interface and the
toString(), equals(), and hashCode() methods have
to be overridden. All requirements are listed in
section 5.4.1 of the [JDOSPEC].
The third, non-durable identity is used for
objects without need for own identity, like simple
lists or bulk data.
3.4.1. Transient
JDO does not influence standard object
construction mechanisms in conjunction with the
new operator. Therefore, all with a developerwritten constructor created objects are transient
by default. They behave like instances of the unenhanced class. Until they are made persistent,
there is no identity associated with these objects.
Moreover, there is no handling of persistent fields
and no transactional behavior.
If a transient object of an enhanced class is
referred by a persistent object at commit time, it
will be persisted.
3.4. Object Lifecycle

JDO defines a number of states for persistent
objects. These states are used by the JDO runtime
to manage the in-memory lifecycle of persistent
objects and to decide when data has to be
synchronized with data store. Not all states are
3.4.2. Persistent-New
Instances are in this state if they have been made
persistent during the current transaction. During
the transition from transient to persistent, the
associated
PersistenceManager
becomes
Figure 6 Object Lifecycle
140
3.6. JDO-Query Language
responsible for handling further state transitions

and handling of field values for rollbacks and
synchronization with data store. Furthermore, it
will assign a JDO identity to the instance.
The aim of the JDO-Query Language is to provide

a simple query grammar that is familiar to Java
programmers and that can be executed by the
JDO implementation, possibly by converting it to
a different representation and passing it to the
underlying data store. Hence, it abstracts from
data store languages like SQL or other datastore
depending premises.
JDO enables vendor-specific enhancements
and additional query languages. In some
implementations it is possible to use SQL query
statements concurrent to native JDO-QL queries.
A query itself consists of a set of candidate
instances, which can be specified using a Java
class, an Extent, or a collection and a filter string.
In addition it is also possible to declare import
statements, parameters and variables as well as an
ordering for the set of results. When executed, a
query takes the set of candidate instances and
returns a Java collection of references to the
instances that satisfies the query filter.
Queries will be highly optimized on the
underlying datastore, depending on the JDO
implementation. For instance, Extents can
internally be used to produce an equivalent query
in native data store language.
Filter strings of JDO-QL can consist of attribute
names, logical operators, references on objects
and a few methods related to strings or objects.
For instance, a filter string can be attrName
== \"string\" and a few common supported
logical operators are !, &&, ||, <, >, ==, etc.
Indeed, for string comparison no SQL like likeoperator is supported. JDO provides startsWith()
and endsWith() constraints. To assists work with
collections of objects, isEmpty() and contains(Object
o) are specified.
In comparison with SQL or other common
query languages JDO-QL is limited to the very
basics in version 1.0.1, but will be enhanced in the
upcoming JDO 2.0 standard.
3.4.3. Persistent-New-Deleted
This state will be reached if an object has made
persistent and be deleted within one single
transaction.
3.4.4. Hollow
Objects in the Hollow state are already persisted,
but at this state only their object identity is
loaded. All ordinary attribute values have not
been loaded.
3.4.5. Persistent-Clean
The data of these objects had been read, but not
modified within the current transaction.
3.4.6. Persistent-Dirty
The data of objects in this state had been changed
in the current transaction, or the makeDirty()
method of JDOHelper had been invoked.
A call to makeDirty() is useful, when changes to
a persistent field of an array type had been made,
since JDO does not require automatic tracking of
changes made to array fields.
3.4.7. Persistent-Deleted
JDO instances that have been deleted in the
current transaction are Persistent-Deleted.
3.5. Extents
An Extent represents the complete set of all
persistent instances of a class. It is obtained from
a PersistenceManager by getExtent and it is possible
to decide whether items of subclasses should be
included or excluded.
The primary purpose of an extent is to provide
a candidate collection of objects to be used in a
query, where filtering or ordering can be applied.
Nevertheless, it can be used to access all
persisted objects of a given class and maybe its
subclasses, therefore an Iterator is provided by the
Extent interface.
The data-retrieval process will not start until
the first invocation of next() on a obtained Iterator.
Thus, it is possible to delegate an Extent to a
Query without unnecessary data access.
4. Outlook on JDO 2.0

The upcoming revision of JDO, so called JDO 2.0,
is finally approved. It will provide several
improvements to the first version of Java Data
Objects.
In particular, JDO 2.0 implementations will be
binary compatible to all earlier versions and
among each other. Nevertheless, it will introduce
141
new interesting additional features.

One of the main targets had been to specify a
standard object/relational mapping to improve
JDOs
acceptance
among
the
general
programming public. Standardized mapping and
runtime behavior will improve portability
between different JDO implementations and will
increase utility of vendor independent tools. 2
Furthermore, JDO 2.0 will introduce an
attach/detach API, which will simplify handling
objects in multi-tier applications. For instance, an
application has to transfer an object to a client and
allow the client to modify its states. Afterwards,
the object has to be returned and the done
modifications have to be saved.
Maybe, the most important improvements had
been done on the JDO-Query Language. Its
capabilities had been enhanced a lot, compared to
JDO 1.0. The JDO-QL will now support
aggregates, named queries, projections and
additional functions for string-related and
mathematic operations.
In JDO 1.0 all query results had been a
collection of objects identified by the query. Since
addition of projections and aggregates in JDO 2.0
a result can be an array of objects, which
represents a table of records with named
columns.
The newly supported aggregate functions are
count(), sum(), avg(), min(), and max(). The
following functions had been introduced to
enhance string and math capabilities:
an instance directly in a query.
5. Conclusion
Persistence is one of the most important concepts
in business applications. Therefore, an easy to use
and common interface is required to meet
business requirements.
JDO will meet these requirements in most
cases. It is a standardized interface-based
definition of object persistence, which is
supported by leading vendors.
Provided transparency will help to reduce
modeling and programming efforts, compared to
ordinary JDBC and SQL usage, which
nevertheless is not obsolete in specific use cases.
Furthermore, the abstraction of specific data
storage will lead to an improved portability of the
whole application.
The programmer itself will benefit in an API
for accessing persistent data with object model
information only and tools which provide this
transparency by automated code enhancement.
While JDO 1.0 may not suit anyone, JDO 2.0
will bring a lot of promising improvements and
may be considered when choosing a persistence
framework.
References
[JDOSPEC] Java Data Objects Specification
http://jcp.org/aboutJava/communityprocess/final
/jsr012/index2.html
get(Object) applies to Map types

containsKey(Object) applies to Map types
containsValue(Object) applies to Map types
toLowerCase() applies to String type
toUpperCase() applies to String type
indexOf(String) applies to String type
matches(String) applies to String type, but only
the following regular expression patterns are
required to be supported: Global (?i) for caseinsensitive matches; and . and .* for wild
card matches.
substring(int, int) applies to String type
Math.abs(numeric)
Math.sqrt(numeric)
JDOHelper.getObjectId(Object) static method in
JDOHelper, allows using the object identity of
[JDO20DRAFT] Java Data Objects 2.0 Public Draft

http://jcp.org/aboutJava/communityprocess/pr/j
sr243/index2.html
[FMC] Fundamental Modeling Concepts
http://www.f-m-c.org/notation-reference/
[JDOC] JDO Java Doc
http://java.sun.com/products/jdo/javadocs/
[UUJDO2003] David Ezzio,
Using and Understanding Java Data Objects,
Apress, 2003
[JDOPH2003] Sameer Tyagi et al.
Core Java Data Objects, Prentice Hall PTR, 2003
[JDOAW2003] Robin M. Roos,
Java Data Objects, Addison Wesley, 2003
[JDOO2003] David Jordan and Craig Russell,
Java Data Objects, OReilly, 2003
[HOLU2004] Andreas Holubek,
Java Data Objects in der Praxis,
Javamagazin 06/2004
E.g. Versant offers an Eclipse plug-in for JDO based

development
as
open
source
software
http://www.versant.com/opensource/orm/en-us
2
142
Vergleich von DTR und Subversion

Zwei Versionskontrollsysteme
Tino Truppel
Seminar Systemmodellierung 2005
Hasso-Plattner-Institut f
ur Softwaresystemtechnik
tino.truppel@hpi.uni-potsdam.de
6. Juli 2005
Zusammenfassung
In der vorliegenden Arbeit werden zwei Versionskontrollsysteme verglichen. Zum einen das
Open-Source-Tool Subversion (SVN) und zum
anderen das von SAP entwickelte und in die
NetWeaver Entwicklungsumgebung integrierte
Design-Time-Repository (DTR).
Hierbei soll eine Diskussion bez
uglich OpenSource pro und kontra vermieden werden. Vielmehr steht der Vergleich des Aufbaus, der
Funktionsweise und der Verwendung der beiden Programme im Vordergrund. Daf
ur werden einleitend generelle Begriffe und Konzepte des Themenbereiches Versionskontrollsystem
gekl
art, um anschlieend die beiden Systeme
im Aufbau und in der Verwendung einzeln zu
erl
autern. Abschlieend werden die haupts
achlichen Gemeinsamkeiten und Unterschiede noch
einmal aufgezeigt. Aspekte wie Installation,
Konfiguration und Sicherheit werden in dieser
Arbeit nicht behandelt.
Schlu
orter: Aufbau, Verwendung,
sselw
Konflikte, Check-In, Check-Out, Zweige
Einfu
hrung
Bei der Entwicklung von groen Softwareanwendungen mit langen Lebenszyklen arbeiten viele Entwicklerteams meist zur selben Zeit auf
den selben Ressourcen. Deshalb werden in heutigen Entwicklungen von groen Softwaresystemen Orte gebraucht, in denen die Entwickler ih-
143
re Ressourcen zentral, sicher, synchronisiert und

auf Dauer ablegen konnen. Ressourcen konnen
sowohl Dateien als auch Verzeichnisse sein.
Hierbei konnen Dateien nicht nur Quelltexte
beinhalten, sondern etwa auch Definitionen und
Beschreibungen (in Form von Diagrammen und
Texten) der Ziele und Moglichkeiten des zu entwickelnden Systems. Genauso sollen auch Dokumentationen und ganze Benutzerhandb
ucher
samt Bildern und Ahnlichem wahrend der Entwicklungsarbeit gespeichert werden. Es soll also
moglich sein in einem Repository Dateien unabhangig vom Typ abzulegen.
Auf das Repository soll auerdem gesteuert
und organisiert zugegriffen werden konnen. Dies
bedeutet, dass Entwickler eigene Sichten auf die
Ressourcen sich erstellen oder erstellt bekommen. Ein Versionskontrollsystem soll aber mehr
leisten als ein herkommlicher Dateiserver. Durch
den Zugriff soll ermoglicht werden, dass Entwickler Informationen teilen und Daten simultan bearbeiten konnen. Nach dem Editieren sollen Resultate des simultanen Bearbeitens nicht
verloren gehen, sondern es ist w
unschenswert,
dass die Ergebnisse der verschiedenen Entwickler verschmolzen werden. Es soll auch moglich
sein auf altere Zustande, d.h. altere Versionen
von Ressourcen zugreifen zu konnen.
In Abbildung 1 ist zu erkennen, wie der Nutzer im Allgemeinen auf ein Versionkontrollsystem mit Hilfe seines lokalen Client-Programmes,
meist u
ber ein Netzwerk, auf den Server zugreift. Durch ein Check-Out werden Daten empfangen und in den lokalen Arbeitsplatz ablegt.
welche eine oder meist mehrere Nachfolger besitzt und beim Anlegen einer Ressource erzeugt
wird. Diese Nachfolger stellen jeweils die Anderungen zu den jeweiligen Vorgangern dar. Das
heit, dass eine Ressource aus einer Ausgangs
version und einer Liste mit Anderungen
besteht.
1.1.2
Abbildung 1: Allgemeine Architektur von Versionskontrollsystemen

Nach dem Editieren werden die nun veranderten Daten durch ein Check-In in das Repository
zur
uckgeschrieben und damit anderen Nutzern
verf
ugbar gemacht.
Ein Versionskontrollsystem ist also ein zentrales Programm um Informationen zu teilen.
Durch das Hochladen von Daten (Check-In)
werden Informationen Anderen zur Verf
ugung
gestellt und durch das Herunterladen (CheckOut) kann man Informationen von Anderen erhalten.
1.1
Funktionsweise
Um mit Ressourcen in einem Versionskontrollsystem zu arbeiten, wobei mehr als ein Entwickler an derselben Ressource simultan arbeiten kann, m
ussen die in den folgenden Abschnitten beschriebenen drei Hauptfunktionen realisiert werden (entnommen aus [SAP1]):
1.1.1
Versionskontrolle
Um verschiedene Versionen einer Ressource im

selben Repository verwalten zu konnen, wird
im Allgemeinen nicht die Ressource in jeder
Version komplett gespeichert, sondern es werden nur die Differenzen (Deltas) im Repository
abgelegt. Auerdem kommunizieren die ClientProgramme und der Server nur mittels dieser
Differenzen. Dies spart nicht nur Speicher im
Repository, sondern auch Bandbreite wahrend
der Daten
ubertragung.
Um dies zu realisieren, existiert zu jeder
Ressource eine Ausgangsversion (Root Version),
144
Zweige und Marken
Oft ist eine lineare Entwicklung einer Ressource, wie dies eine Liste ermoglicht, nicht ausreichend. Vielmehr ist es w
unschenswert das gesamte Projekt moglicherweise in verschiedene
Richtungen weiterzuentwickeln, um zum Beispiel lander- oder sprachspezifische Anpassungen vorzunehmen. Hierf
ur sind Zweige (Branches) nutzbar. Ein Zweig ist eine Liste von Verweisen. Jeder Verweis zeigt auf eine Ressource.
Da Ressourcen, wie schon erwahnt, Listen von
Anderungen
sind, kann dieser Verweis nicht nur
auf die aktuelle Version, sondern auf eine beliebige Version einer Ressource weisen. Um Zweige
von dem Hauptzweig (Head ) zu unterscheiden,
m
ussen sie benannt werden. Nun konnen an die
sen Verweisen weitere Anderungen
hinzugef
ugt
werden. Somit konnen Ressourcen unterschiedliche Entwicklungsgeschichten (Histories) haben.
Wird auf das weitere Entwickeln verzichtet,
so spricht man von Marken (Tags). Eine Marke
ist eine Moglichkeit stabile Zustande des Repositories zu speichern, um etwa eine zu veroffentlichende Version des Projektes zu haben, auf die
man gezielt auch spater zugreifen kann.
Zweige konne auch als Sichten auf ein Repository verstanden werden. Angenommen ein
Entwickler A will Teile des Repositories grundlegend u
berarbeiten, wobei jedoch die normalen Entwicklungsarbeiten an dem Projekt durch
weitere Entwickler fortgesetzt werden. Da Entwickler A nun von Ressource zu Ressource seine
Arbeit durchf
uhrt, w
urde er vermutlich das Entwicklerteam beeintrachtigen. Besser ist, wenn A
sich einen eigenen Zweig erstellt und an dem un
abhangig von anderen Nutzern Anderungen
vornimmt. Er hat nun seine personliche Sicht auf
das Projekt. Wenn A seine Arbeit beendet hat,
kann er seinen Zweig in den Hauptzweig integrieren.
1.1.3
Simultane Entwicklung
Bei der Verwaltung von Anderungen

mehrerer
Nutzer auf einer Ressource konnen zweierlei Typen von Konflikten entstehen. Aus einem gleichzeitigen Check-Out derselben Ressource und simultaner Bearbeitung durch zwei oder mehrere Entwickler konnen Check-In-Konflikte resultieren. Beim Check-In des ersten Entwicklers konnen noch keine Konflikte entstehen, jedoch sobald weitere Entwickler versuchen dieselbe Ressource in das Repository hinaufzuladen, besteht im Repository eine aktuellere Version der Ressource als die, welche die Entwickler
als Ausgangspunkt ihrer Entwicklungen genutzt
haben. Einen solchen Konflikt kann man durch
das Loschen der schon im Repository vorhandenen Version, durch das Loschen der lokalen
Version oder durch ein Verschmelzungsvorgang
(Merge) losen. Hierbei wird die zuletzt genannte
Methode bevorzugt, jedoch ist beim Verschmelzen von Ressourcen eine manuelle Bearbeitung
notwendig.
Ein weiterer Konflikt ist der sogenannte Integrationskonflikt. Dieser entsteht durch eine Integration zweier Zweige, in denen gleiche Ressourcen unterschiedliche Entwicklungsgeschichten haben. Auch hier muss ein Verschmelzungsvorgang durchgef
uhrt werden, um diesen Konflikt zu losen.
1.2
Beispiel
F
ur ein besseres Verstandnis ist in der Abbildung 2 ein Beispiel einer Entwicklungsgeschichte
eines Repositories aufgezeigt.
ner Ressource (Development Resource 1). Nach

der Erzeugung der zweiten Ressource und einer
Editierung der ersten, wird in diesem Beispiel
die zweite Version der ersten Ressource und die
erste Version der zweiten Ressource markiert. In
den folgenden Schritten wird eine Verzweigung
der Ressource 1 und 2 und die Integration der
beiden Zweige der Ressource 1 dargestellt.
Ein Versionskontrollsystem ist also ein essentielles und machtiges Werkzeug bei der teambasierten Softwareentwicklung.
Design-Time-Repository
Das von der SAP entwickelte und auf Perforce basierende Versionskontrollsystem DTR
ist die zentrale Ressourcenverwaltung in der
NetWeaver-Entwicklungsumgebung. Es lauft,
ahnlich wie andere Programme der Entwicklungsumgebung, auf einen SAP Web Application Server als J2EE-Applikation.
2.1
Die Entwicklungsumgebung besteht aus einem

lokalen Teil und der zentralen Java Development Infrastructure (JDI). Den lokalen Teil bilden das NetWeaver Developer Studio als Entwicklungsumgebung, welches das lokale Dateisystem als temporarer Speicher verwendet. Auch
andere Clients sind denkbar, welche jedoch nur
eingeschrankten Zugriff auf das DTR haben.
In der 3. Abbildung werden die Elemente
der JDI dargestellt. Hierzu gehoren neben dem
Design Time Repository auch der Name Service, das System Landscape Directory (SLD),
der Component Build Service (CBS) und der
Change Management Service (CMS).
2.1.1
Abbildung 2: Beispiels eines Repositories

Das Beispielrepository ist nach der Erzeugung leer. Der erste Schritt ist das Anlegen ei-
145
Einordnung in die Java Development Infrastructure
System Landscape Directory
Das System Landscape Directory enth

alt Informationen u
ber die vorhandenen Softwareprodukte und die Beschreibung der installierten
Systemlandschaft. So sind etwa in diesen Metadaten u
ber die Systemlandschaft Informationen
enthalten, was entwickelt wird, was kompiliert
Abbildung 3: Einordnung des DTR in das JDI

werden soll und wohin die Ressourcen nachher
verteilt werden.
Das SLD ist eigentlich nicht Teil der JDI,
sondern gehort zur Standardinstallation von
der SAP J2EE-Implementation. Weil jedoch der
Entwicklungsprozess mit der JDI das SLD voraussetzt, wird es dennoch hier behandelt.
2.1.2
Component Build Service
Durch die Aktivierung der Ressourcen im DTR

werden diese im CBS kompiliert. Auerdem verwaltet dieses die so entstandenen Archive der Binaries. Hierbei basiert der Bauprozess auf Komponenten, was bedeutet, dass nur neu hinzugef
ugte oder geanderte Komponenten gebaut
werden m
ussen und nicht das gesamte Projekt.
und spater auch an Produktivsysteme. Dies geschieht durch die Freigabe der Entwickler. Somit
ist das CMS in der Lage den gesamten Zyklus
der Entwicklung von Software zu kapseln.
2.1.4
Dieser optionale Service verwaltet die Namensraume bestimmter kritischer Ressourcen,

wie etwa Komponenten oder Datenbanktabellen. Dadurch, dass das NetWeaver Developer
Studio beim Erstellen von neuen kritischen Ressourcen stets den Name Services kontaktiert,
wird die eindeutige Namensvergabe im gesamten System garantiert. Der Name Service ist ein
Teil des SLD.
2.2
2.1.3
Change Management Service
Dieses System verwaltet und regelt den Zugriff

auf Ressourcen des DTR und des CBS f
ur alle Entwicklungsaufgaben. So verteilt es auch
die Binaries an ein Laufzeit-J2EE-Testsystem
146
Name Service
Funktionsweise des DTR
Das DTR besteht aus dem DTR-Server und verschiedenen Client-Programmen, normalerweise
wird hier das NetWeaver Developer Studio verwendet, aber jeder andere WebDAV-Client ist
denkbar. Client und Server kommunizieren mit
Hilfe des DeltaV -Protokolls1 . Der Server speichert alle Dateien als Binary Large Objects
(BLOB) in eine rationale Datenbank.
Der Zugriff auf die Ressourcen geschieht u
ber logische Speicherorte, die DTRWorkspaces, welche nicht mit dem Konzept
des Workspaces zu verwechseln ist, wie er
etwa in der Entwicklungsumgebung Eclipse
vorkommt. DTR-Workspaces sind neben den
versionierten Ressourcen der zweite Bestandteil
der DTR-Datenbank. Wie in der 4. Abbildung
zu erkennen ist, besteht zwischen diesen beiden Entitaten Beziehungen derart, dass die
DTR-Workspaces Ressourcen referenzieren. Um
jedoch auf jede beliebige Version verweisen zu
konnen, geschieht dies nicht direkt, sondern der
DTR-Workspace zeigt auf Activities. Activities
sind im Kontext des SAP DTR genau die oben
genannten Differenzen zwischen benachbarten
Zustanden einer Ressource.
auf die Ressourcen Zugriff haben, welche f

ur ihre
Aufgaben relevant sind.
In der 5. Abbildung wird neben dem Aufbau des DTR auch der eben genannte Aspekt illustriert. Die Entwickler, welche mit ihrem NetWeaver Developer Studio auf das DTR zugreifen, verwenden DTR-Workspaces um auf eine
Auswahl von Ressourcen in unterschiedlichen
Versionen zugreifen zu konnen. Dies geschieht,
indem sich der Check-Out-Prozess auf DTRWorkspaces bezieht und dadurch alle Ressourcen innerhalb eines DTR-Workspaces in der jeweiligen Version in den lokalen Workspace kopiert werden.
Es ist zwar theoretisch moglich mit DTRWorkspaces nicht nur Sichten zu ermoglichen,
sondern auch tatsachliche Verzweigungen, jedoch wird in der Praxis hierf
ur das System
Landscape Directory genutzt (weiteres hierzu in
[KK5]).
Abbildung 5: Relationen des DTR-Inhaltes

Es ist also zu erkennen, dass das Konzept
der DTR-Workspaces unterschiedliche Sichten
auf das Repository realisiert. Hierbei gehen die
Moglichkeiten der Steuerung u
ber das analoge
Konzept durch Zweige hinaus. Zweige beziehen
sich immer auf zusammenhangende Teile (wie
etwa Verzeichnisse) oder auf das gesamte Repository. Es ist nicht moglich einzelne Ressourcen
nicht in einen Zweig aufzunehmen. Workspaces
m
ussen hingegen nicht alle Ressourcen enthalten. Damit ist gewahrleistet, dass Entwickler nur
1
Das WebDAV-Protokoll besteht aus einen Satz von

Methoden und Header f
ur das HTTP. Hierbei steht DAV
f
ur Distributed Authoring und Versioning. Uber
dieses
Protokoll wird der Zugriff (
ahnlich wie bei einen Dateiserver) auf entfernte Dateien via HTTP gew
ahrleistet.
Jedoch wurde die M
oglichkeit zu Versionierung in WebDAV noch nicht standardisiert. Deshalb wurde DeltaV
entwickelt, welches ein Standard ist, der auf HTTP und
WebDAV aufsetzt und die Versionierung von Dateien regelt (siehe [WD]).
147
Abbildung 6: Wichtige Entwicklerschritte in der

NetWeaver Entwicklungsumgebung
2.3
Verwendung des DTR
Die enge Bindung der Komponenten des JDI haben auch Einfluss auf die Verwendung des DTR.
Abbildung 4: Aufbau des DTR

Um dies zu verdeutlichen, zeigt die Abbildung
6 die notwendigen Schritte bei der Erstellung
und Bearbeitung von Entwicklungskomponenten. Alle diese Schritte konnen von dem NetWeaver Developer Studio aus durchgef
uhrt und
gesteuert werden.
Initial sind grundsatzliche Daten aus dem
SLD zu importieren, welche etwa Informationen beinhalten, wie das DTR und das CBS zu
erreichen sind. Daraufhin besteht die Moglichkeit entweder einen Check-Out auf einen DTRWorkspace auszuf
uhren oder neue Ressourcen
zu erzeugen. Falls neue Ressourcen erzeugt werden, m
ussen deren Namen auf Eindeutigkeit im
Name Service gepr
uft werden. Ein Check-Out
ist explizit, das bedeutet es ist dem DTR jede
Ressource bekannt zu geben, welche bearbeitet
wird. Dadurch kann man im DTR Ressourcen
sperren, so dass ein simultanes Bearbeiten nicht
mehr moglich ist.
Nach dem lokalen Bearbeiten konnen die
Ressourcen lokal getestet werden. Durch das
Editieren von Ressourcen werden Activities
mit Anderungen
gef
ullt, welche durch Hoch-
148
laden oder durch ein Check-In auf das DTR

propagiert werden. Hochladen bedeutet das
zentrale Sichern von Ressourcen in personliche DTR-Workspaces, wobei keine Check-InKonflikte entstehen konnen. Ein Check-In ist
das Bereitstellen von Activities in globale DTRWorkspaces, hierbei kann es zu einem Konflikt
kommen. Zum Losen dieser Konflikte wird eine
neue Activity erzeugt, welche entweder die eine der beiden Versionen loscht und die andere
beibehalt oder beide Versionen verschmilzt. Es
bleibt festzuhalten, dass durch die starke Einbindung des DTR in das JDI und durch die
expliziten Check-Outs die Moglichkeit offline zu
arbeiten auf das Editieren von Ressourcen eingeschrankt ist. Hierbei meint online, dass eine
Verbindung zum Server u
ber das Netzwerk bestehen muss.
In Abbildung 6 wird nur das Bearbeiten von
Ressourcen in Developement Configuration Perspective vom Developer Studio beachtet. Struk
turelle Anderungen
(Tree Changes) sind im Entwicklungszyklus nicht vorgesehen.
Erwahnenswert ist die Moglichkeit des
Abbildung 7: Aufbau von Subversion

Uncheck-Out, welche ein Check-In einer Ressource wieder r
uckgangig machen kann. Diese
Funktion ist in Subversion so nicht vorhanden.
Subversion
In diesem Kapitel werden nicht nur der Aufbau, die Funktionsweise und die Verwendung
von Subversion erlautert, sondern gleich dar
an Gemeinsamkeiten, Ahnlichkeiten
und Unterschiede zum DTR aufgezeigt.
Subversion ist eine Open-Source-Software,
das viele Schwachen des sehr beliebten Programms CVS behebt. Deshalb wird Subversion
oft als dessen Nachfolger bezeichnet, obwohl es
sich um ein eigenstandiges Projekt handelt.
3.1
Aufbau von Subversion
Der Aufbau von Subversion ist grundsatzlich

dem des DTR ahnlich. Jedoch gibt es mehr
Moglichkeiten auf ein Subversion-Repository
zuzugreifen. Zum einen sind viele ClientProgramme verf
ugbar (etwa als Eclipse-Plug-In)
149
und zum anderen gibt es drei unterschiedliche

Zugriffsarten auf das Repository:
1. Der Zugriff u
ber ein subversion-eigenes
Protokoll, welches die Kommunikation mit
einen leichtgewichtigen Subversion-Server
erlaubt. Da in der Praxis hierf
ur SSH genutzt wird, ist es notwendig, dass die Entwickler jeweils einen SSH-Account auf der
Maschine, auf der das Repository liegt, haben.
2. Der lokale Zugang.
3. Der Zugriff per DeltaV auf einen ApacheWebserver, welcher ein Subversion-Modul
geladen hat.
Da der verwendete Subversion-Syntax unabhangig der Zugriffsart gleichbleibt, lediglich
die Pfadangaben angepasst werden m
ussen (siehe [SVN]), ist es im Groen und Ganzen moglich
mit jedem Subversion-Client alle drei Protokolle nutzen zu konnen. Jedoch ist der Zugang
u
ber DeltaV zu empfehlen, da diese Schnittstelle standardisiert ist und das Anlegen von neuen
Nutzern nicht von einen Administrator der Maschine, sondern durch einen Administrator des
Repositories durchgef
uhrt werden kann.
Die Subversion-Daten liegen im Gegensatz
zum DTR-Repository nicht in einer Datenbank,
sondern direkt im Dateisystem. Das SubversionVerzeichnis enthalt im wesentlichen 6 Verzeichnisse und eine Datei:
1. Das Conf-Verzeichnis enthalt Daten u
ber
die Konfiguration des Repositories.
2. Das Dav-Verzeichnis wird vom Webserver
und dem dazugehorigen Subversion-Modul
als eigener Zustandsspeicher genutzt.
3. Die Format-Datei enthalt genau einen Integerwert, die aktuelle Revision-Nummer
des Repositories. Durch jeden Check-In
wird diese Nummer inkrementiert. In einem neuen, noch leeren Repository ist diese Nummer gleich null.
4. Das Hook-Verzeichnis enthalt Hooks. Ein
Hook ist ein Script, welches durch ein Ereignis im Repository ausgelost wird. So
kann etwa dadurch die Autorisierung von
Entwicklern im Repository realisiert werden (was jedoch sehr aufwendig ware).
5. Subversion unterst
utzt, wenn gew
unscht,
wie das DTR das Sperren von Dateien, sodass kein simultanes Bearbeiten moglich
ist. Diese Informationen werden im LockVerzeichnis abgelegt.
6. Das Repository an sich liegt in einer BerkeleyDB2 oder direkt im Dateisystem3 in
einem Unterverzeichnis.
Die Revision-Nummer ist eine Besonderheit
von Subversion. In anderen Versionskontrollsystemen (wie etwa in DTR) werden Versionsnummern f
ur jede Ressource einzeln vergeben. In
Subversion gibt es hierf
ur nur eine Nummer, die
2
Eine BerkeleyDB ist eine Datenbank, welche aus Dateien im Dateisystem besteht auf welche direkt, d.h. ohne
Server, zugegriffen werden kann.
3
Diese Option wird erst ab der Subversion-Version 1.1
unterst
utzt.
150
Revision-Nummer. Das heit sobald eine Ressource geandert wird, wird diese Nummer inkrementiert. Commits sind analog zu Activities
als eine Menge von Anderungen

zu verstehen.
Im Unterschied zum DTR sind jedoch Commits
Transaktionen, welche also atomar sind. Die globale Revision-Nummer ist dadurch begr
undet,
dass im Gegensatz zum DTR-Repository, in dem
jede Ressource aus einer Liste (mit Verzweigungen) aus Differenzen besteht, ein Subversion
Repository aus einer einzigen Liste von Anderungen, welche sich jeweils auf eine oder mehrere Ressourcen beziehen, besteht. Deshalb spricht
man auch nicht von Versionen von Ressourcen,
sondern von Ressourcen aus einer bestimmten
Revision.
Abbildung 8: Relationen
Repository-Inhaltes
des
Subversion-
Da bei jeder Inkrementierung der RevisionNummer jede Ressource geandert wird, meint
man mit Working-Revision-Nummer, die
Revision-Nummer zu der die Ressource das
letzte Mal geandert wurde. Wie auch der 8.
Abbildung zu entnehmen ist, besitzt jede Ressource eine eigene Working-Revision-Nummer.
Die hochste Working-Revision-Nummer ist
gerade die globale Revision-Nummer. Durch
die einzelnen Anderungen

kann nun jeder Ressource eine oder mehrere (durch Verzweigung)
Entwicklungsgeschichten zugeordnet werden.
Eine solche Geschichte beginnt immer mit dem
Anlegen der Ressource.
3.1.1
Beispiel
Die 9. Abbildung soll dazu dienen den Zusammenhang zwischen den versionierten Ressourcen
und der Revision-Nummer an einem Beispiel zu
verdeutlichen. Im ersten Schritt wird das Repository angelegt, es hat die Revision-Nummer
0. Mit den 1. Commit werden 2 Ressourcen erzeugt (Development Resource 1 und 2), nun hat
das gesamte Repository die Revision-Nummer 1.
Durch das zweite Commit wird die 1. Ressource und nur diese geandert, nun ist die aktuelle Revision-Nummer 2. Jedoch ist die WorkingRevision-Nummer von der 2. Ressource immer
noch 1, da zu diesem Zeitpunkt die Ressource
das letzte Mal geandert wurde. Schlielich, nach
der 8. Revision, ist die Revision-Nummer eben
8, die Working-Revision-Nummer der Ressource
2 auch und die Working-Revision-Nummer der
Ressource 1 ist 7.
Abbildung 9:
Repositories
Beispiel
eines
mits sich nicht auf eine Ressource beziehen, sondern auf das gesamte Repository, konnen diese
nicht einfach zu einer einzelnen Ressource hinzugef
ugt werden. Deshalb funktioniert eine Integration in Subversion durch das Hinzuf
ugen
eines Commits, welcher die Differenz zwischen
dem Quellzweig und dem Zielzweig an den Zielzweig hangt.
3.2
Verwendung von Subversion
Im Folgenden werden die wesentlichen Schritte

bei einer Entwicklung von Software unter der
Verwendung von Subversion erklart.
Subversion-
Aus der Abbildung 9 ist noch weiteres erkennbar: Auch in Subversion werden nur die
Differenzen zwischen den einzelnen Zustanden
von Ressourcen gespeichert. Jeder Zustand einer Ressource zeigt auf seinen Vorganger, indem
in ihm die Revision-Nummer gespeichert ist, in
welcher vor ihm das letzte Mal die Ressource
geandert wurde. Dieses Konzept wird auch f
ur
Zweige und Marken genutzt. Dadurch sind Zweige und Marken sehr kosteng
unstig, da sie nur
Zeiger auf einen bestimmten Zustand sind. Zweige konnen als einzigen Unterschied zu Marken
nicht nur eine Vorgangergeschichte haben, sondern auch eine Nachfolgergeschichte. Somit sind
Zweige und Marken fast das gleiche: lazy copies
von Ressourcen.
Dieses Konzept kann bei der Integration
zweier Zweige nicht durchgesetzt werden. Im
DTR werden bei einer Integration alle Activities einer Ressource aus dem Quellzweig in den
Zielzweig integriert. Da aber in Subversion Com-
151
Abbildung 10: Wesentliche Schritte bei der Entwicklung mit Subversion

Durch einen initialen Check-Out wird eine Kopie des auszucheckenden Zweiges auf der
Client-Maschine erzeugt. Wenn nun immer mit
der Arbeit begonnen wird, sollte ein Update
durchgef
uhrt werden (dies ist nicht notig, wenn
zeitnah der initiale Check-Out stattgefunden
hatte). Dadurch wird die lokale Kopie mit al
len etwaigen Anderungen
seit dem letzten Update aktualisiert. Nachdem das getan ist, kann
offline weitergearbeitet werden. Hierbei konnen
sowohl einzelne Dateien editiert werden (mit
einen beliebigen Editor) oder aber auch strukturelle Veranderungen (wie etwa das Erzeugen
von Ressourcen) vorgenommen werden. Sogenannte Tree Changes konnen aber nur mit den
subversion-eigenen Programmen (wie etwa svn
add oder svn delete) durchgef
uhrt werden. Wie
zu erkennen ist, ist es moglich auch offline Ressourcen hinzuzuf
ugen. Dies ist im DTR nicht der
Fall.
Ist die Bearbeitung abgeschlossen, so konnen
nun die vorgenommenen Anderungen

u
uft
berpr
werden. Subversion halt daf
ur eine weitere Kopie vor, welche nicht bearbeitet werden kann4 .
Sollen nun die Anderungen

an das Repository geschickt werden, so ist vor dem Check-InVorgang ein Update notwendig. Hierbei werden
mogliche Check-In-Konflikte erkannt, welche lokal gelost werden m
ussen. Ohne das Losen dieser
Konflikte ist ein Check-In nicht moglich. Hier sei
nochmal erwahnt, das ein Check-In, mit all sei
nen Anderungen
am Repository, atomar ist.
Fazit
Nachdem nun im Detail der Vergleich abgeschlossen ist, im Folgenden eine Zusammenfassung der wesentlichen Gemeinsamkeiten und
Unterschiede. Vorab sollte aber erw
ahnt werden, dass eine Entscheidung f
ur ein bestimmtes Programm nicht notwendig sein wird, da das
DTR in der SAP Entwicklungsumgebung nicht
ersetzbar ist und auch nur dort eingesetzt werden kann.
Es lasst sich festhalten, dass beide Systeme weitentwickelte Programme sind, welche im
Aufbau und damit im Kern sehr ahnlich funk
tionieren. Beide nutzen das Konzept der Anderungen, was Speicherplatz und auch Bandbreite spart, da nur Differenzen (Deltas) versendet und gespeichert werden. Desweiteren sind
Workspaces im DTR den Zweigen im Subversion ahnlich, wenn man Zweige als Sichten
auf ein Repository versteht. Beide referenzieren auf eine Menge von Zustanden, was bedeutet, dass Workspaces und auch Zweige sehr
kosteng
unstig sind. Erwahnenswert sind noch
folgende Funktionalitaten, welche von beiden
System unterst
utzt werden: So konnen Dateien unabhangig vom Typ versioniert werden. Es
konnen Ressourcen im Repository verschoben
werden, ohne das die Entwicklungsgeschichte
verloren geht. Und es ist ein bedingter CheckOut moglich, indem etwa Zustande von Ressourcen ausgecheckt werden, welche zu einem bestimmten Zeitpunkt aktuell waren.
4
Die wesentlichen Unterschiede begr

unden
sich vorallen auf die unterschiedlichen Umgebungen, in denen die Systeme laufen. Da das
DTR sehr stark in die JDI integriert ist, ist die
Verwendung dessen meist nur mit den anderen
Komponenten zusammen sinnvoll. Der Vorteil
f
ur den Entwickler besteht hierbei darin, dass
das DTR von der Entwicklungsumgebung gekapselt wird. Das DTR bietet einen Service wie
andere Komponenten (etwa CBS) an, welche alle durch das NetWeaver Developer Studio aus
bedient werden konnen. Das ist jedoch nicht nur
ein Vorteil des DTR, da es sehr monolithisch ist,
kann es schwer erweitert oder angepasst werden.
Dies ist bei Subversion ohne weiteres moglich, da
Subversion ein separates Programm ist und aus
C-Bibliotheken mit wohldefinierten Schnittstellen besteht. Schlielich soll noch kurz der Aspekt
Autorisierung erwahnt werden, welche im DTR
per Access Control Lists funktionieren und damit feingranularere Zugriffssteuerung wie sie in
Subversion moglich ist, erlaubt. Jedoch sollen
ACLs in der kommenden Version von Subversion
integriert werden (weiteres hierzu in [SVN]).
Literatur
[KK5] Java-Programmierung mit dem SAP
Web Application Server, Karl Kessler et
all., Galileo Press, Bonn 2005
[SAP1] DTR User Documentation, 2001 SAP
AG
[SAP2] Architecture and Concepts of the Design Time Repository, SAP Online
(help.sap.com)
[SAP3] Administration
des
Repository Servers,
(help.sap.com)
[SAP4] Working With the DTR, SAP Online

(help.sap.com)
[SVN] Subversion-Homepage
on.tigris.org)
[WD]
Diese Kopie liegt im versteckten Verzeichnis .svn.
152
Design-TimeSAP
Online
(subversi-
WebDav-Homepage (www.webdav.org)
SAP NetWeaver Java Development Infrastructure

Sebastian Bttner
Hasso-Plattner-Institute fr Softwaresystemtechnik
Sebastian.Boettner@hpi.uni-potsdam.de
Abstract
2. bersicht
In der vorliegenden Arbeit wird die SAP

NetWeaver Java Development Infrastructure (NWDI)
vorgestellt Dazu wird speziell auf die Komponenten
der Infrastruktur und ihre Zusammenarbeit
eingegangen.
Der Aufbau und die Funktionsweise der
Komponenten und das von SAP entwickelte und in der
Infrastruktur verwendete Komponentenmodell werden
nher beleuchtet werden.
Das NWDI bietet fr die Entwicklung in

Teams oder die verteilte Entwicklung folgende
Konzepte:
Klare Definition des Entwicklungsziels,
beginnend bei der Definition des zu
entwickelnden Projektes und seiner Teile
Alle Entwickler haben bei der Entwicklung die
gleiche Ausgangsbasis, sowohl fr Quellen als
auch Archive
Ein Komponentenmodell, das die Kopplung
zwischen Komponenten verringert und damit
die Wartbarkeit und Wiederverwendbarkeit
von Teilen des Projektes erhht.
Automatische Synchronisierung der Arbeit der
Entwickler whrend der Entwicklung.
Projekt-bezogene Ablufe die ber die
Entwicklung hinausgehen, wie Test,
Konsolidierung und Auslieferung, werden
ebenfalls durch die Umgebung definiert und
verarbeitet.
Keywords: Java, SAP, NWDI, JDI, NetWeaver
1. Einfhrung
Die Herausforderungen bei groen SoftwareProjekten liegen in der Gre und der Anzahl der
beteiligten Entwicklungsgruppen, welche auf
verschiedene Standorte verteilt sein knnen, und
dem Software-Lebenszyklus.
Diese Projekte mssen ber einen langen
Zeitraum gewartet werden, wobei auch von
Kundenseite
eingebrachte
Modifikationen
bercksichtigt werden mssen.
Um diesen Herausforderungen entgegentreten
zu knnen, bedarf es einer konsistenten
Umgebung, die den Entwicklern alle Ressourcen
und Archive in den bentigten Versionen zur
Verfgung
stellt,
Modifikationsmanagement
erlaubt und Stabilitt im Software-Lebenszyklus
gewhrleistet.
Die SAP NetWeaver Java Development
Infrastructure adressiert diese Probleme durch
vordefinierte Entwicklungsprozesse, die von den
Infrastruktur-Komponenten verarbeitet werden
knnen und durch Entwicklungskonzepte wie
das von SAP entwickelte Komponentenmodell.
Diese Konzepte werden durch das Design

Time Repository (DTR), den Component Build
Service (CBS), das Change Management System
(CMS) und das SAP Komponentenmodell
umgesetzt.
Diese Eigenschaften sind fr kleine Teams
nicht zwingend notwendig, dennoch profitieren
auch kleine Entwicklungen von der NDWI.
153
Local File
System
NetWeaver Developer Studio
Component Build
Service
Name Service
Design Time
Repository
Namespace
Archives
Landscape
Configurator
Configurator
Development
Resources
Transport
Studio
System
Landscape
Directory
R
Quality Manager
Operator
Change Management System

R
Development
Configuration
Run Time Systems

Central Infrastructure
Bild 1: Aufbau des NWDI
3. Das SAP Komponentenmodell
3.1 Software Components
Die Zerlegung von Software in weitgehend

unabhngige Teile ist ein wesentlicher Ansatz,
um Software wartbar und bersichtlich zu halten.
Die Wiederverwendung dieser Teile wird
dann vereinfacht, wenn die Teile voneinander
entkoppelt werden, jedoch klar definierte
Schnittstellen existieren, durch die die Teile
einander
nutzen
knnen.
Das
SAP
Komponentenmodell, bietet diese Eigenschaften
und ermglicht daher eine przise Planung der
Software Architektur.
Das Komponentenmodell erlaubt durch seine
besondere
Struktur
auch
eine
neue
Herangehensweise an den Build-Prozess (dies
wird im Abschnitt ber den CBS nher erlutert).
Software Components funktionieren als

Einheiten und knnen zu anderen SoftwareKomponenten Abhngigkeiten und Beziehungen
definieren, die explizit in der Development
Configuration
gespeichert
werden,
und
ermglichen damit eine Strukturierung des
Projektes in verschiedene Schichten.
Software Components werden im DTR in
Workspaces als Dateien und Ordnern abgelegt
und
sind
die
Einheiten
die
zur
Wiederverwendung gedacht sind.
Dennoch sind sie nur Rahmen fr die so
genannten Development Components und bieten
von sich aus keine Mglichkeiten zur Kapselung
oder Sichtbarkeitsbeschrnkung der enthaltenen
Ressourcen.
Das
Komponentenmodell
ist
hierarchisch
strukturiert und beinhaltet 3 Schichten.
Zuoberst steht immer das Produkt, das es zu
entwickeln gilt. Das Produkt gehrt nicht zum
Komponentenmodell und wird in der NWDI
durch
die
so
genannte
Development
Configuration realisiert.
Ein Produkt beinhaltet eine oder mehrere
Software Components, die entweder entwickelt
werden knnen oder bereits in fertiger Form
(zum Beispiel als Bibliotheken) vorliegen.
3.2 Development Components

Development Components sind ebenfalls nur
Behlter fr die eigentlichen Elemente der
Entwicklung, den Development Objects.
Durch Kapselung des Zugriffes auf diese
Objekte bilden die Development Components die
Struktur der Software Components.
Eine Development Component darf dabei nur
154
Zur Kompilierung vorgesehene Public Parts,

werden
bei
der
Entwicklung
anderer
Komponenten genutzt und kommen immer dann
zum Einsatz, wenn Objekte der Komponente zum
Kompilieren einer anderen gebraucht werden.
Public Parts die vom Typ Assembly sind,
werden dann bentigt wenn eine Komponente
keine deploybaren Build Resultate hat. Die
Objekte im Public Part werden dann in die
verwendende Komponente verpackt und knnen
so auf den Server deployed werden.
Mit dem Konzept der Public Parts scheint nun
eine Verwendung von Objekten nur auf gleicher
Hierarchie-Ebene oder zwischen einer Eltern- und
ihrer eigenen Kind-Komponente mglich.
Um Objekte ber diese Grenzen hinaus
sichtbar zu machen, gibt es dafr das Konzept der
Propagation.
Dabei werden Public Part Entities einer Public
Part in die Public Parts der direkten ElternKomponente bernommen und damit auf der
hheren Hierarchie-Ebene sichtbar.
Dadurch wre es mglich alle Objekte eines
Projektes in jeder Development Component
sichtbar zu machen, dies widerspricht jedoch der
angestrebten Kapselung. Auch mit Propagation
ist es jedoch nicht mglich das KindKomponenten Beziehungen oder Abhngigleiten
zu ihrer Eltern-Komponente definiert.
Zur
zustzlichen
Einschrnkung
der
Sichtbarkeit haben Public Parts Access Control
Lists, wobei jeder Access Control Entry eine
Development Component nennt, die auf den
Public Part zugreifen kann. Ist die Access Control
List leer, so kann jede Development Component
auf den Public Part zugreifen, der ber die
normalen Sichtbarkeiten Zugriff htte.
genau einmal in einem Projekt vorkommen und

deshalb auch nur genau zu einer Software
Component innerhalb des Projektes gehren.
Diese Struktur wird beim Build auf
Korrektheit berprft. Dies bietet sich an, da die
Development Components die Einheit des BuildProzesses sind.
Diese Komponenten besitzen ein so genanntes
Black Box Verhalten, das heit das alle Objekte,
die in einer Komponente enthalten sind, nach
auen unsichtbar bleiben, es sei denn sie werden
speziell sichtbar gemacht (siehe Public Parts).
Das Component Nesting erlaubt es, dass eine
Development Component eine oder mehrere
weitere Komponenten enthlt.
In Verbindung mit dem Black Box Verhalten,
ergibt sich aus dieser Struktur eine feinere
Sichtbarkeitskontrolle als es ber die public,
private, protected Schlsselwrter mglich wre.
Durch die Beschrnkung der Sichtbarkeit nach
auen, ergibt sich eine perfekte Entkopplung der
Development Components, wie sie fr die
einfache Wiederverwendung und Wartbarkeit
notwendig ist, jedoch wre eine gegenseitige
Verwendung
der
Objekte
dadurch
ausgeschlossen.
Nichtsdestotrotz
knnen
Development
Components Verwendungs- oder AbhngigkeitsBeziehungen untereinander definieren, diese
werden dann direkt in den Komponenten
gespeichert.
Um das zu ermglichen, existieren Public
Parts, die als Schnittstellen der Komponente nach
auen fungieren.
3.2.1 Public Parts
3.2 Development Objects
In den Public Parts von Komponenten werden

diejenigen Development Objects verffentlicht,
die nach auen hin sichtbar und somit nutzbar
sein sollen. Diese Eintrge werden Public Part
Entities genannt
Jede Development Component kann mehrere
Public Parts haben, in denen verschiedene
Development Objects verffentlicht werden. Das
ermglicht es die Abhngigkeiten zwischen
mehreren Komponenten zu minimieren um damit
eine grere Unabhngigkeit zu erreichen.
Public Parts knnen vom Typ Compilation
oder Assembly sein.
Diese Objekte sind die eigentlich zu

entwickelnden Ressourcen. Dabei kann es sich
um praktisch alles handeln, wie Tabellen, Bilder,
Java-Class Dateien, WebDynpro Dateien oder
Metadaten.
155
P r o p a g a t e s o b je c t s
D epends / U se
D epends / U se
has
c o n t a in s
D epends / U se
P u b lic P a r t
D e v e lo p m e n t
Com ponent
S o ftw a r e
C om ponent
c o n t a in s
L is t s u s a b le
has
F o ld e r
W e b D y n p ro
Com ponent
A c c e s s C o n tro l
L is t
D e v e lo p m e n t
O b je c t
J a v a C la s s
G ra n ts a c c e s s
Bild2: Das SAP Komponentenmodell
4. Infrastruktur Komponenten
Auf dem Bild 3 ist zu erkennen, dass das DTR
aus einer Client und einer Serverseite besteht.
4.1 Design Time Repository

Das Design Time Repository ist das zentrale
Versionierungs- und Speichersystem fr alle
Quellen die whrend der (verteilten) Entwicklung
eines Projektes entstehen.
Das DTR ist eine J2EE-Anwendung, die eine
relationelle Datenbank verwendet, in der alle
Versionen aller Ressourcen gespeichert werden,
so dass nie ein Zustand verloren gehen kann. Die
Datenbank kann dieselbe sein, die das CMS und
das CBS nutzen.
Dabei trgt das DTR Sorge dafr, dass ein
Entwickler nur Zugriff auf die Daten und Objekte
in ihren jeweiligen Versionen erhlt, die er fr das
aktuelle Projekt bentigt.
Zustzlich stellt das DTR sicher das
Versionierungsinformationen erhalten bleiben,
auch wenn die Objekte in andere Instanzen des
DTR eingebracht werden. Dies ist notwendig um
Versionskonflikte vermeiden zu knnen, die bei
verteilten Entwicklungen oder Modifikationen
beim Kunden auftreten knnen.
Bild 3: DTR Client und Server
Der DTR Client ist dabei eine XML-Datei die die

notwendigen Metadaten enthlt um die
verwendete graphische Oberflche mit dem
156
durchzufhren, fhrt man Activities aus.

Activities gruppieren nderungen an den
Ressourcen eines Workspaces und fhren diese
atomar aus. Soll eine Ressource gendert werden,
so wird sie zuerst aus dem DTR ausgecheckt und
alle nderungen in der Activity gespeichert, diese
kann solange gendert werden bis sie eingecheckt
wird. Dadurch werden die nderungen auf den
zentralen Speicher gebracht und fr alle
Entwickler sichtbar. Die Activity kann nun nicht
mehr verndert werden.
Mit Activities lassen sich auch Dateien
lschen, da aber keine Ressourcen verloren gehen,
wird beim Einchecken der Activity nur die
Referenz auf die Datei im jeweiligen Workspace
gelscht.
Activities wirken immer nur auf den
Workspace in dessen Kontext sie erzeugt wurden,
das bedeutet das andere Workspaces die auf eine
gemeinsame Ressource referenzieren, weiterhin
eine ltere Version enthalten. Die Activity kann
jedoch auch transportiert werden um die
nderung in anderen Workspaces sichtbar zu
machen. In dem Fall wird die Activity in die
anderen Workspaces integriert. Liegen Quell- und
Ziel-Workspace in unterschiedlichen Repositories,
werden die betroffenen Objekte erst exportiert um
spter zusammen mit der Activity wieder
integriert
zu
werden,
die
Versionierungsinformationen bleiben dabei stets
erhalten.
Sollen
mehrere
Activities
gemeinsam
transportiert werden, nutzt man PropagationLists. Diese fassen Activities zusammen, die dann
als Einheit transportiert werden. Durch
Propagation-Lists ist es auch mglich ltere
Versionen von Workspaces wiederherzustellen,
indem man in einen neuen Workspace eine
Propagation-List mit allen Activities bis zu dem
gewnschten Zeitpunkt einbringt.
Server verbinden zu knnen.

Der Server speichert alle so genannte
Versioned Resources in Form von BLOBs (Binary
Large Objects) in der Datenbank, prsentiert der
graphischen Oberflche jedoch eine Datei und
Ordnerstruktur.
Die Kommunikation zwischen Client und
Server erfolgt auf Grundlage des htt-Protokols
basierend auf den Standards WebDAV und
DeltaV.
Der Nutzer des DTR greift ber logische
Speicherbereiche
der
Datenbank,
den
Workspaces, auf die Objekte zu.
Da alle Versionen aller Ressourcen stets in der
Datenbank vorhanden sind, ermglichen diese
Workspaces den Zugriff auf genau die Version
die in der aktuellen Entwicklung verwendet wird
und reprsentieren so den Zustand einer Software
Component. Die Ressourcen werden dabei im
Workspace als Referenzen gespeichert und jede
Ressource darf nur in genau einer Version
referenziert werden.
Development Objects knnen jedoch in
mehreren Projekten vorkommen und werden in
dem Fall mehrfach referenziert, dies hlt den
Speicherbedarf gering und die Entwicklung
konsistent.
Da ein Workspace eine Version einer Software
Component darstellt ist die Anlegung mehrerer
Workspaces
fr
verschiedene
Entwicklungszustnde, wie Entwicklung und
Konsolidierung sinnvoll. Wird das DTR
zusammen mit dem CBS und dem CMS
verwendet, werden die beiden Workspaces active
und inactive erzeugt. Der active Ordner enthlt
dabei die aktuellsten mit anderen Versionen
abgestimmten Ressourcen, whrend der inactive
Ordner neue oder genderte Objekte enthlt, die
berfhrung vom inactive in den active Ordner
nennt sich Activation und wird spter behandelt.
Wenn nderungen in einen Workspace

eingebracht werden, kann es immer sein, das es
Konflikte gibt.
So ist es mglich das zwei Entwickler die
Version einer Ressource gleichzeitig auschecken
und anschlieend den Check-in versuchen. Der
erste Entwickler kann das ohne Probleme
erledigen. Wenn der zweite Check-in erfolgen
soll, erkennt das DTR das die gerade
einzubringende Version kein direkter Nachfolger
der aktuell aktiven Version (die Entwickler 1
eingebracht hat) ist und bietet dem Entwickler
Um die bersichtlichkeit zu erhhen und die

Zusammengehrigkeit von Workspaces zu
kennzeichnen, verfgt das DTR ber so genannte
Workspace Folder, diese knnen weitere
Workspace Folder oder Workspaces enthalten.
Bei dem Szenario das SAP zur Entwicklung
empfiehlt, sind die untersten Workspace Folder
immer dev und cons und beinhalten die
Workspaces active und inactive.
Um
nderungen
in
einem
Workspace
157
dann die Mglichkeit:
Bild 4: Beispiel einer Belegung des DTR
4.2 Component Build Service
Die aktive Version zu akzeptieren und die neue

zu verwerfen
Die eigene Version als aktive Version zu
bestimmen und die andere verwerfen
Die beiden Versionen verschmelzen (Merge).
Dabei bietet das SAP NetWeaver Developer
Studio Methoden an um die Unterschiede in
den Versionen zu erkennen und den Merge
durchfhren zu knnen.
Wie das DTR ist das CBS eine J2EE

Anwendung und verwendet eine Datenbank zur
Ablage von Archiven, diese ist in Buildspaces
unterteilt.
Das CBS ist die zentrale Build-Umgebung der
NWDI und verwaltet alle in der Entwicklung
anfallenden Build-Resultate.
Die Buildspaces, die als logische Speicherorte
auf der Datenbank des CBS genutzt werden,
reprsentieren
jeweils
eine
Development
Configuration. Fr jede Software Component gibt
es im Buildspace ein Compartment und diesem
sind jeweils die beiden Workspaces active und
inactive aus dem DTR zugeordnet.
Das bedeutet, dass ein Buildspace immer einen
Zustand des Projektes reprsentiert. Ein
Buildspace beinhaltet daher immer alle neu
gebauten und alle genutzten Archive die in der
aktuellen Entwicklung notwendig sind.
Das gleiche Konzept kommt zum Tragen,

wenn man nderungen in ein anderes Repository
einbringen will. Durch dieses Konzept ermglicht
das DTR eine konsistente Entwicklung auch bei
verteilter Entwicklung und Modifikation beim
Kunden.
Um jedem Entwickler nur auf die Objekte
Einblick zu gewhren die fr die aktuelle
Entwicklung notwendig sind, verfgt das DTR
ber ein System von Authentifizierung und
Autorisierung.
Die Authentifizierung kontrolliert den Zugriff
auf die Datenbank durch Abgleich von
Bernutzernamen und Passwort gegen ein anderes
SAP System. Die Autorisierung arbeitet mit
Access Control Lists, die fr jedes Objekt einzeln
festlegen knnen, welche Nutzer welche Rechte
haben.
Dabei
erben
alle
Objekte
die
Berechtigungen ihrer bergeordneten Ordner,
wenn nicht explizit eigene angegeben wurden.
Der Build-Prozess des CBS basiert auf dem

SAP Komponentenmodell. Dies fhrt dazu das
aufwendige Builds des gesamten Projektes ber
Nacht vermieden werden und stattdessen nur die
aktuell genderten Development Components, als
Einheiten des Build-Prozesses gebaut werden.
Dabei erkennt das CBS automatisch, wenn durch
einen Build abhngige Komponenten veraltet
sind und baut sie neu.
Die Activation ist eine der wichtigsten
Funktionen des CBS bezglich der verteilten
Entwicklung. Hat ein Entwickler seine Activity
eingecheckt, so liegt die neueste Version der
Komponente im Workspace inactive, das heit
andere Entwickler knnen diese nicht mit
Gewissheit
nutzen,
das
diese
Version
funktionstchtig ist.
Der Entwickler hat nun die Mglichkeit seine
nderungen zu aktivieren. Dazu sendet das
NDWI einen Build-Request an das CBS, dort wird
dieser
vom
CBS
Request
Recieve
entgegengenommen, der den Auftrag nicht direkt
verarbeitet sonder auf die Request Queue legt.
Der aktuelle Zustand des Auftrages kann jetzt
ber die CBS Web UI eingesehen werden.
Ist der Auftrag an der Reihe wird er von der
Build Engine aus der Queue genommen. Die
Build Engine bereitet nun den Build vor, dazu
DTR Database
Cons
(Workespacefolder)
R
Active
Dev.
Object 1
Vers 1
Inactive
DTR Client
Workspace Folder of Software Component X
Dev.
Object 1
Vers n
DEV
(Workspacefolder)
Active
Inactive
Versioned Resources
Dev.
Object n
Vers 1
Workspace Folder of Software Component Y
Dev.
Object n
Vers n
158
Einrichtung einer Build-Umgebung kmmern
werden die genderten Quellen aus dem DTR in

D a ta b a s e
(w o rk s p a c e s )
D e s ig n T im e R e p o s ito ry C lie n t
C hange
M anagem ent
S e rv ic e
A rc h iv e P o o l
(B u ild s p a c e s )
CBS
R equest
R e c ie v e
N e tW e a v e r
D e v e lo p e r
S tu d io
D a ta b a s e
B u ild
E n g in e
T e m p o ra ry
F o ld e r
R equest
Q ueue
B u ild
E n g in e
R
W e b B ro w s e r
C BS W eb U I
(J 2 E E S e rv ic e )
C B S B u ild
C o n tro lle r
C o m p o n e n t B u ild S e rv ic e
und den Build-Prozess steuern, da das CBS ihm

das abnimmt.
eine temporre Verzeichnisstruktur kopiert.

Bild 5: Aufbau des CBS
Ebenso werden die genutzten Archive, die

bereist vorliegen aus dem Archive Pool kopiert.
Zuletzt werden die fr den Build notwendigen
Plug-Ins aus dem Archive Pool kopiert. Welche
Plug-Ins dabei genutzt werden hngt vom Typ
der zu kompilierenden Development Component
ab und wird vom CBS automatisch erkannt. Die
Build Engine kann multi-threaded oder auf
mehrere Serverknoten verteilt laufen um die Last
groer Projekte aufnehmen zu knnen.
Ist der Build vorbereitet, stt die Build
Engine den CBS Build Controller an, dieser ldt
die Plug-Ins aus dem Speicher und startet dann
den Build.
Ist der Build erfolgreich, so werden die
entstanden Archive in den Archive Pool kopiert
und die Quellen von inactive nach active
verschoben und so fr alle Entwickler wieder
konsistent nutzbar.
Schlgt der Build fehl, so werden die Archive
als broken markiert und die Quellen verbleiben in
inactive.
Damit ist gewhrleistet, dass die Entwickler
keine fehlerhaften Versionen als Grundlagen
nutzen und sich Fehler propagieren knnen.
Der Build einzelner Komponenten hat darber
den Vorteil, dass es eine Zeitersparnis gegenber
dem Build ber Nacht ist und der Entwickler
entstandene Fehler sofort sieht. Auch muss sich
der Programmierer nicht mehr um die
4.3 Change Management System

Das Change Management System ist die
Umgebung
fr
Administratoren
und
Qualittsmanager der NWDI.
Die Hauptaufgaben das CMS sind das
Anlegen neuer Projekte und der Transport von
Quellen und Archiven zwischen verschiedenen
Komponenten des NWDI als auch externer
Testsysteme, dazu gibt es im CMS die beiden
wichtigen
Sub-Systeme,
den
Landscape
Configurator und das Transport Studio.
Im Landscape Configurator legt der
Administrator bei Beginn eines neuen Projektes
zuerst eine Domne an, diese ist ein Rahmen der
einem speziellen Lieferanten gehrt. Diese
Domne muss bei SAP registriert werden, wenn
die Produkte vertrieben werden sollen.
In der Domne werden nun die Tracks
angelegt, dabei entspricht ein Track immer einem
Projekt in einem bestimmten Entwicklungstand,
zum Beispiel Entwicklung oder Konsolidierung.
In diesem Track werden nun die URL des CBS
und des DTR in Form einer Development
Configuration gespeichert, damit der Entwickler
spter Zugriff auf diese Komponenten hat.
Tracks enthalten die bereits erwhnten
Software Components, die nun angelegt werden
mssen. Beziehungen und Abhngigkeiten
knnen bereits festgelegt, spter aber wieder
159
Quelldateien in das Konsolidierungs-System

deployed. Hier knnen umfangreiche Tests
vorgenommen
werden.
Sind
die
Tests
gendert werden. Dabei unterscheidet der

Administrator zwischen zu entwickelnden
Software Components und solchen die bereits
Local File
System
Local File
System
Local File
System
Local File
System
Central
Development
System
Consolidation
System
Test System
Production
System
QA
Manager
R
Change Management
System
Landscape
Configurator
Transport
Service
Database
Admin
Development
Configuration
System
Landscape
Directory
Design Time Repository Client
DTR
DEV
CONS
Component Build
Service
Archive Pool
(Buildspaces)
abgeschlossen, wird das Produkt verpackt und als

neue Version auf das Test System aufgebracht.
fertig zur Nutzung vorliegen.

Bild 6: Aufbau des CMS
Der nchste Schritt liegt in der Festlegung der

Laufzeitsysteme, die einzeln fr die 4 Phasen der
Entwicklung (Entwicklung, Konsolidierung, Test
und Produktion) definiert werden knnen. Dabei
wird die Adresse des Systems und ein Passwort
das die Berechtigung zum Deploy gibt, festgelegt.
Zu guter letzt besteht die Mglichkeit
Verbindungen zwischen Tracks zu definieren, fr
den Fall das eine Software Component die in
einem Track entwickelt wird, in einem anderen
zur Nutzung vorliegen soll.
Hierbei knnen die Quellen mitverpackt

werden, wenn dies gewnscht ist.
Nach den Tests im Test System entscheidet ein
Qualittsmanager
ob
das
Produkt
zur
Auslieferung bereit ist und kann es dann ins
Produktions-System
zur
endgltigen
Auslieferung deployen.
5. Fazit
Die NWDI bietet eine Abbildung des gesamten
Software Lebenszyklus in einer integrierten
Entwicklungslandschaft.
Das zugrunde liegende Komponentenmodell
mit der starken Kapselung und den exakt
definierten
Schnittstellen
erleichtert
die
Wartbarkeit und Wiederverwendbarkeit und
erlaubt
fr
einen
Build-Prozess
auf
Komponentenebene mit vordefinierten BuildProzessen.
Das globale Versionierungssystem ermglicht
die verteile Entwicklung auf einer gemeinsamen
Das Transport Studio erlaubt einem

Administrator
oder
Qualittsmanager
die
Kontrolle ber den Lebenszyklus der Software.
Hat ein Projekt den erfolgreichen Build und
Test in der lokalen Umgebung hinter sich, kann es
in das zentrale System eingecheckt und aktiviert
werden. Im Central Development System sind
dann alle Software Components zu finden die
verwendet werden um fr die Entwicklung bereit
zu stehen. Ist die Entwicklung abgeschlossen
werden alle verwendeten und die zu
entwickelnde
Software
Component
als
160
konsistenten
Code-Basis
und
Modifikationsmglichkeiten beim Kunden, ohne
diesen von Updates und Support-Packages
auszuschlieen.
Zustzlich zu den Quellen werden auch die
Archive
konsistent
gehalten
und
die
Komponenten
der
Infrastruktur
erkennen
automatisch
Inkonsistenzen
und
bieten
automatische Lsungsvorschlge an.
Qualittsmanager und Administratoren haben
jederzeit Einblick auf die komplette Landschaft
und
zustzliche
Testsysteme
ermglichen
umfassende Qualittsmanahmen nach dem
Abschluss der Entwicklung als auch whrend
dieser.
Damit bietet die NWDI eine effiziente
Umgebung zur Entwicklung sowohl in groen
und verteilten Teams als auch fr kleinere
Projekte mit wenigen Entwicklern.
Literatur
[KK5] Java-Programmierung mit dem SAP
Web Application Server, Karl Kessler
et all., Galileo Press, Bonn 2005
[SAP1] SAP NetWeaver Java Development
Infrastructure, SAP Online
(help.sap.com)
[SAP2] Working with the SAP NetWeaver Java
Development Infrastructure, SAP Online
(help.sap.com)
161
162
SAP NetWeaver Java Development Infrastructure
Entwicklung durch mehrere Teams mit Hilfe von Tracks
Stefan Httenrauch
Seminar Systemmodellierung 2005
Hasso-Plattner-Institut fr Softwaresystemtechnik, Universitt Potsdam
stefan.huettenrauch@hpi.uni-potsdam.de
st.huettenrauch@freenet.de
Abstract
2. berblick ber die NWDI und

der Begriff des Tracks
Nach einem berblick ber die NetWeaver Java

Development Infrastructure (NWDI) und der
Definition des Begriffs Track, wird detailliert auf die
Entwicklung von Software unter zu Hilfenahme eines
Tracks eingegangen.
Danach liegt der Fokus auf der parallelen Softwareentwicklung. Es wird dargestellt, wie mit den
gegebenen Mitteln nebenlufig gearbeitet werden kann
und wie die Entwicklungsergebnisse zusammengefhrt
werden.
Abschlieend werden die Rollen innerhalb der
NWDI sowie ihre Zugriffsrechte betrachtet.
Um nachfolgend auf die Entwicklung mit Hilfe

von Tracks eingehen zu knnen, wird zuvor kurz
die Architektur der NWDI beschrieben und der
Begriff des Tracks erlutert.
2.1. Die NetWeaver Java Development

Infrastructure
Keywords: Track, SAP NetWeaver, Multi-Team

Development, Parallel Development, Roles
1. Motivation
Die verteilte Entwicklung mit einer Vielzahl von
Entwicklern bzw. Entwicklerteams ist eine der
Herausforderungen, der sich heute nahezu alle
Softwareentwickler stellen mssen. Hierbei gilt es
Abhngigkeiten zwischen Entwicklern aufzulsen, Kontroversen (z.B. Versionskonflikte) zu
vermeiden und die Mglichkeit zu schaffen,
unabhngig voneinander zu arbeiten, um eine
parallele, mglichst konfliktfreie Entwicklung zu
ermglichen.
Mit dem Konzept des Tracks und der Definition zugehriger Rollen (engl. Roles) versucht
SAP, innerhalb der NetWeaver Java Development
Infrastructure (NWDI) und dem NetWeaver
Development Studio, diesen Problemen zu
begegnen.
Abbildung 1: Die Architektur der NWDI (nach

[BOE] und [KTD])
Man erkennt aus der abstrakten Sicht auf die

Architektur der NWDI in Abbildung 1 fnf
Komponenten, die in diesem Kontext relevant
sind.
Das System Landscape Directory (SLD) ist die
zentrale Informationsverwaltung. Es beinhaltet
Metainformationen ber die Systemlandschaftsdaten, also die Verteilungsstruktur der NWDI.
Das Design Time Repository (DTR) dient der
Quellcode- und Dateiverwaltung. Sein Speicher
ist in aktive und inaktive Workspaces (WS akt.
und WS inact.) gegliedert.
163
Fr den zentralen Build der Softwarekomponenten (engl. Software Component, kurz SC) wird
der Component Build Service (CBS) genutzt.
Das Change Management System (CMS) steuert
als bergeordnete Instanz den gesamten
Entwicklungsprozess und greift dabei auf die drei
zuvor genannten Architekturelemente zurck.
Fr die Entwicklung kann z.B. zu Test- oder
Consolidationzwecken auf Laufzeitsysteme
(engl. Runtime Systems) zurckgegriffen werden.
2.2. Der Begriff Track

Fr den Begriff Track existieren mehrere
Erklrungsperspektiven. In 2.2.1 wird der Track
zunchst als Metakonstrukt vorgestellt; in 2.2.2
wird er spter als Workflow definiert.
Abbildung 2: Der Track als Metakonstrukt
2.2.1. Der Track als Metakonstrukt
Abbildung 2 fasst die Definition des Tracks als

Metakonstrukt zusammen, wobei der Abstract
Track Agent als Zusammenfassung aller Akteure
zu verstehen ist, die mit dem Track in Berhrung
kommen. Zu einem Track gehrt zustzlich eine
Track Management Information in der Metadaten,
wie z.B. Trackname und die Adressen von DTR
und CBS, hinterlegt sind.
Einen Track kann man als eine Menge von

Speichern und Laufzeitsystemen verstehen.
Hierbei beschreibt eine Development Configuration
die zu entwickelnden Softwarekomponenten,
sowie die Komponenten, von denen die zu
entwickelnden Komponenten abhngig sind.
Ferner beschreibt sie die Organisation der
Speicher, auf die der Entwickler oder das
Entwicklerteam whrend seiner Arbeit Zugriff
hat. Jede Development Configuration ist dabei
unterteilt in einen Development Workspace und
einen Consolidation Workspace, die beide die
gleiche Struktur besitzen. Sie bestehen aus
potentiell mehreren Workspaces im DTR und
einem Buildspace im CBS, in dem Archive abgelegt
sind, welche in die Entwicklung mit eingebunden
werden mssen. Ein Workspace im DTR ist
unterteilt in den Workspace active und den
Workspace inactiv (vgl. Abbildung 1). Die
Development Configurations mehrerer Tracks
werden in Domains verwaltet.
Als Laufzeitsysteme stehen J2EE Server zum
Entwickeln, Kompilieren, Konsolidieren und
Produzieren zur Verfgung. Diese Laufzeitsysteme knnen zur besseren Lastbalancierung auch
jeweils mehrfach vorhanden sein.
2.2.2. Der Track als Workflow

Im Gegensatz zu der Definition im letzten
Abschnitt, kann man den Begriff Track auch als
einen Workflow einen wohl definierten Ablauf
interpretieren.
Abbildung 3: Der Track als Workflow
Der Entwicklungszyklus in Abbildung 3

besteht nach [SAPAr] aus den vier groen Phasen:
Development, Consolidation, Quality Management
(QM) und Production. Diesen Phasen kann man
164
ming und local build / local test beliebig oft

abwechseln und wiederholen(vgl. Abbildung 3).
eine Vorbereitungsphase voranstellen (Preparation). Die Phase Development lsst sich darber
hinaus in die Subphasen Programming, local build /
local test und Activation unterteilen.
Jede zu entwickelnde Softwarekomponente
durchluft alle Phasen dieses Workflows.
3.2.1. Programming
Der Developer bearbeitet nun existierende
Quellcodedateien und Objekte oder erstellt selbst
neue Artefakte.
3. Die Entwicklung mit Hilfe von

Tracks
Im Folgenden werden die Transitionen des
Petrinetzes aus Abbildung 3 und somit der Track
als Workflow nher spezifiziert. Es wird dabei
dargestellt, welche Rollen fr die jeweiligen
Schritte verantwortlich sind (Zugriffsrechte: vgl.
Kapitel 5). Abbildung 12 (siehe Anhang) zeigt
abschlieend den gesamten Entwicklungsprozess.
Abbildung 4: Standardworkflow eines

Developers
Abbildung 4 zeigt das bekannte Vorgehen

beim Verndern existierender Objekte (check out)
und die Nachfrage beim Name Service, um
eineindeutige Namensbezeichnungen fr neue
Objekte zu garantieren.
Whrend dieser Phase erstellt der Developer
so genannte Development Components (DCs) und
Activities. Diese Metakonstrukte dienen der
besseren Organisation und bersichtlichkeit der
Entwicklungsarbeit.
3.1. Preparation
In Hinblick auf die durchzufhrende Entwicklung wird durch den Configurator das zu
erreichende Endergebnis der Entwicklung z.B.
ein Softwareprodukt definiert. Dazu werden ein
oder mehrere Tracks angelegt. Jeder Track enthlt
eine Referenz auf die Softwarekomponenten, die
in dem jeweiligen Track entwickelt werden sollen.
Zustzlich werden Referenzen auf Softwarekomponenten hinterlegt, von denen der Track
abhngig ist. Der Configurator nutzt dazu den
Landscape Configurator des CMS. Die dabei
erstellte Development Configuration wird im
Speicher des SLD abgelegt.
Im nchsten Schritt importiert der Developer
diese Development Configuration in sein
NetWeaver Developer Studio (NWDS). Alle
Komponenten die er auf Grundlage der Trackdefinition fr seine weitere Entwicklungsarbeit
bentigt, werden daraufhin automatisch in das
NWDS importiert.
Als Ergebnis dieser Phase erhlt der Developer
eine von Auen unabhngige Entwicklungsumgebung mit allen fr seine Entwicklung bentigten Softwarekomponenten. Ebenso ist das zu
entwickelnde Softwareprodukt inklusive seiner
Abhngigkeiten definiert.
3.2.2. Local build / local test

In bestimmten Intervallen und am Ende der
Entwicklungsarbeit wird durch den Developer
ein lokaler Build durchgefhrt. Dies geschieht in
der abgeschlossenen Entwicklungsumgebung.
Alle dafr notwendigen Softwarekomponenten
stehen dazu bereits seit der Phase Preparation
(vgl. Abschnitt 3.1) zur Verfgung. Der Vorgang
luft hierbei vollstndig unabhngig von der
NWDI und anderen Entwicklern ab.
Abbildung 5 zeigt einen Ausschnitt aus der
lokalen Entwicklungsumgebung. Wird der
Auftrag zu einem Build gegeben, werden aus
dem lokalen Dateisystem alle erforderlichen
Softwarekomponenten in den local build agent
geladen und die erzeugten Archive nach
erfolgreicher
Durchfhrung
wieder
lokal
gespeichert. Eine J2EE engine testet daraufhin
diese Archive.
3.2. Development
Wie im Abschnitt 2.2.2 erwhnt, lsst sich die
umfangreiche Phase Development in 3 Subphasen
zerlegen, die nachfolgend erlutert werden.
Hierbei knnen sich die Subphasen Program-
165
Abbildung 5: Lokale Build- und Testumgebung
3.2.3. Activation
Im Zuge der Activation wird das erste Mal nach
der Entwicklung wieder auf die NWDI zurckgegriffen.
Durch die Aktivierung der Activities eines
Developers wird der Inhalt des lokalen Dateisystems in den zugehrigen Workspace inactive im
DTR bertragen. Danach wird ein Build Request
an das CBS gesendet, um den Build in Zusammenhang mit anderen Softwarekomponenten
durchzufhren. Wie in Abbildung 6 zu sehen,
fhrt das CBS den Build durch und importiert
zuvor nur die im Track festgelegten Softwarekomponenten in der aktuellsten Version aus den
aktiven Workspaces des DTR und die vom
Developer synchronisierten Quellcodedateien aus
den Workspaces inactive.
Es ist somit mglich nur einzelne Module der
gesamten Software durch einen Build zusammenzufhren und zu berprfen. Ein zeitaufwndiger Build des gesamten Produktes ist nicht
erforderlich. Dies hat weiterhin den Vorteil, dass
ein fehlgeschlagener Build nur geringe Auswirkungen auf andere Developer hat.
Nach erfolgreichem Kompilieren und Zusammenfhren werden die Daten aus dem Workspace inactive in den Workspace active berfhrt.
Somit stehen die entwickelten Komponenten
anderen Entwicklern zur Verfgung (vgl.
Abschnitt 4.1). Parallel wird ein zentraler Test
angestoen, der die soeben erstellten Archive im
globalen Kontext testet. Die bereits angesprochenen Laufzeitsysteme zum Testen werden dafr
genutzt.
Abbildung 6: Ablauf bei der Aktivierung und dem

zentralen Build
Das gesamte Vorgehen wird vom Quality

Manager berwacht. Er hat die Mglichkeit z.B.
beim Auftreten von Fehlern Builds anzuhalten
oder abzubrechen.
3.3. Consolidation, Quality Management

und Production
Nach dem Vorgang der Activation und dem
Beenden der Entwicklungsarbeit, fhrt der
Developer ein Release seiner Arbeit durch.
hnlich wie in Abschnitt 3.2.3, geschieht dies
durch wenige Interaktionen mit dem NWDS.
Daraufhin wird ein Consolidation Request an
den Quality Manager gesendet. Dieser synchronisiert seinen Consolidation Workspace mit dem
Developer Workspace (cons. WS und dev. WS) des
Developers (vgl. auch Abbildung 2).
An dieser Stelle werden die Ergebnisse mehrerer Tracks zusammengefhrt (Consolidation) und
in einem isolierten Laufzeitsystem getestet
(Quality Management).
Nach erfolgreichem Abschluss dieser beiden
Phasen erstellt der Operator das Gesamtprodukt.
In Abbildung 7 ist dieser Ablauf zusammengefasst.
166
Daraus folgt, dass Track B von den Ergebnissen

von Track A abhngig ist. Die oberste Schicht
(Track C) bentigt wiederum die Ergebnisse von
Track B.
In Abbildung 8 ist ebenfalls zu erkennen, dass
die Ergebnisse eines Tracks nach dem Quality
Management an den jeweilig nachfolgenden
Track weitergegeben werden.1
Es ergibt sich der Vorteil, dass die bergebenen Softwarekomponenten die Qualittssicherung schon durchlaufen haben. Somit werden nur
qualitativ hochwertige Komponenten in die
Entwicklung der davon abhngigen Tracks
eingebunden ([SAPD]). Als Ergebnis erhlt man
einen stabilen Entwicklungsprozess. Ebenso ist
das Risiko gering, Softwarekomponenten erneut
adaptieren zu mssen, wenn Fehler in eingebundenen Komponenten auftreten. Jedoch verringert
sich aufgrund der fehlenden Parallelitt am
Anfang der Entwicklung potentiell die Entwicklungsgeschwindigkeit. Dies kann darber hinaus
Auswirkungen auf kritische Pfade whrend des
gesamten Entwicklungsprozesses haben.
In Abschnitt 3.2.3 wurde erwhnt, dass schon
nach der Aktivierung die entwickelten Komponenten auch anderen Entwicklern zur Verfgung
stehen. Dies ermglicht eine frhere Einbindung
von Komponenten in andere Tracks und somit
eine hhere Parallelitt und Entwicklungsgeschwindigkeit. Da zuvor ein erfolgreicher
zentraler Build durchgefhrt wurde, sind diese
Komponenten auch im globalen Kontext
funktionsfhig.
Durch
den
angestoenen
zentralen Test (vgl. Abbildung 6), kann frhzeitig
auf evtl. auftretende Fehler und damit verbundene nderungen reagiert werden.
Erkennt man trotz der Qualittssicherungsmechanismen whrend der Entwicklung Fehler an
referenzierten Softwarekomponenten, so knnen
diese Fehler durch die Wiederaufnahme des
ursprnglichen Tracks und das sptere Einbringen eines Patches behoben werden.
Abbildung 7: Ablauf bei Consolidation, Quality

Management und Production
4. Parallele Entwicklung
Nachdem nun der gesamte, auf einem Track
basierende Entwicklungsprozess erlutert wurde,
geht dieses Kapitel in einem Szenario beispielhaft
auf die parallel verlaufende Entwicklung unter
Verwendung von Tracks ein.
4.1. Parallele Entwicklung mit interTrack-Abhngigkeit

Es soll ein Softwaresystem mit einer dreischichtigen Architektur entstehen. Jede Schicht wird in
einem separaten Track entwickelt. Dadurch
ergeben sich bspw. die in Abbildung 8 dargestellten Abhngigkeiten zwischen den drei Tracks A,
B und C.
4.2. Parallele Entwicklung ohne interTrack-Abhngigkeit

Einzelne Module einer Architekturschicht, die
nicht voneinander abhngen, knnen in vollstnAbbildung 8: Parallele, untereinander abhngige
Tracks
1 Die Entwicklung des Tracks, der als Quelle dient, kann

durchaus fortgefhrt werden und weitere Versionen der
jeweiligen Softwarekomponenten hervorbringen. Diese
wrden spter erneut an die davon abhngigen Tracks
weitergegeben werden.
In Track A wird die unterste Schicht des

Systems entwickelt, in Track B die mittlere.
167
dig nebenlufigen Tracks entwickelt werden. Die

Ergebnisse dieser Tracks werden, wie in
Abschnitt 3.3 erwhnt, whrend der Consolidation zusammengefgt.
Abbildung 9 verdeutlicht diesen Zusammenhang.
Abbildung 10: Vererbung der Rollenrechte im

CBS
In Kapitel 3 wurden die verantwortlichen Rollen

fr die einzelnen, durchzufhrenden Ttigkeiten
genannt: Configurator, [X]Developer, Quality
Manager und Operator. Diese Rollen haben
eingeschrnkte Zugriffsrechte auf die NWDI, um
sicher zu stellen, dass alle an der Entwicklung
beteiligten Personen nur die Aufgaben wahrnehmen, fr die sie autorisiert sind.
Im Folgenden werden die Rollen und ihre fr
Kapitel 3 wichtigsten Rechte getrennt nach CBS
und CMS genauer dargestellt. Eine ausfhrliche
bersicht ber die Rechte einzelner Rollen kann
[SAPAd] entnommen werden.
Die rollenspezifischen Zugriffsrechte im CBS

umfassen:
Rolle
Zugriffsrechte
Guest
Einsehen der Activities,
Einsehen der Build Request
Queue,
Einsehen der Abhngigkeiten
zwischen Softwarekomponenten
Developer
Aktivieren eigener Activities,
Anhalten und Abbrechen
eigener Build Requests
XDeveloper
Aktivieren fremder Activities
Quality
Anhalten, Abbrechen und
Manager
Neustarten aller Build Requests
Administrator
Monitoring,
Reaktivierung von Activities,
Bearbeiten der Build Request
Queue
5.1. Rollen und ihre Rechte im CBS
5.2. Rollen und ihre Rechte im CMS
Die Rollen im CBS sind Guest, Developer,

XDeveloper, Quality Manager und Administrator.
Abbildung 10 macht die Vererbungshierarchie
der Rollen deutlich. Jede Rolle ergnzt die
Zugriffsrechte der Rolle, von der sie direkt
abgeleitet wurde um weitere Rechte. Somit
vereint ein Administrator die Rechte aller Rollen
in einer Person und erweitert sie um administratorspezifische.
Die Rollen im CMS sind Guest, Configurator,

Developer, Quality Manager, Operator und
Administrator.
Alle Rollen erben die Zugriffsrechte von Guest
und (siehe Abbildung 11) besitzen eigene
spezifische Rechte. Der Administrator erbt die
Zugriffsrechte aller Rollen, ergnzt jedoch keine
weiteren.
Abbildung 9: Zusammenfhrung mehrerer

paralleler Tracks ohne inter-Track-Abhngigkeit
5. Rollen und ihre Zugriffsrechte
Abbildung 11: Vererbung der Rollenrechte im

CMS
168
Glossar
Die rollenspezifischen Zugriffsrechte im CMS

umfassen:
Rolle
Zugriffsrechte
Guest
Einsehen der Development
Configuration,
Einsehen der Consolidation
Queue,
Einsehen von Logs
Configurator
Anlegen und Verndern eines
Tracks
Developer
Release eigener Activities
Quality
Annehmen und Verwerfen von
Manager
Softwarekomponenten whrend
der Consolidation
Operator
Weitergeben von Softwarekomponenten an andere Tracks,
Erstellen von Software Component Archives
CBS
CMS
DC
DTR
J2EE
NWDI
NWDS
QM
SAP
SC
WS
Component Build Service

Change Management System
Development Component
Design Time Repository
Java 2 Enterprise Edition
NetWeaver Java Development
Infrastructure
NetWeaver Development Studio
Quality Manager
Systems, Applications, and
Products (in data processing). SAP
AG, internationale deutsche Firma
mit Hauptsitz in Walldorf
Software Component
Workspace
Referenzen
[SAPAr] SAP help online. Architecture Manual.
http://help.sap.com/saphelp_nw04/helpdata/de/
01/9c4940d1ba6913e10000000a1550b0/frameset.ht
m. Stand Juni 2005.
6. Zusammenfassung
Tracks dienen im Kontext der NetWeaver
Development Infrastructure dem Management
von Softwareentwicklungsprozessen. Sie knnen
als ein System von Speichern und Laufzeitsystemen oder als Workflow verstanden werden.
Durch die in einem Track definierten Abhngigkeiten zu anderen Softwarekomponenten und
der exakten Angabe der zu entwickelnden
Softwarekomponenten, ist eine weitestgehend
unabhngige, parallele und teamorientierte
Softwareentwicklung mglich. Der Entwicklungsprozess ist stabil; dem Developer bleibt das
Softwareprodukt
als
Ganzes
weitgehend
verborgen.
Die Definition von Rollen und den damit
verbundenen Zugriffsrechten untersttzt die
Entwicklung mit Hilfe von Tracks und schrnkt
die Verantwortlichkeiten der beteiligten Personen
ein.
Den Vorteilen fr die Entwicklung stehen ein
hoher administrativer Aufwand und die Arbeit
mit einer komplexen Infrastruktur gegenber.
[SAPAd] SAP help online. Administrator Manual.

88/9959400d9d1059e10000000a155106/frameset.ht
m. Stand Juni 2005.
[SAPD] SAP help online. Development Manual.
03/f6bc3d42f46c33e10000000a11405a/frameset.htm.
Stand Juni 2005
[KTD] Kessler, Tillert, Dobrikov. SAP NetWeaver
Essentials, Java-Programmierung mit dem SAP Web
Application Server (Kapitel 8 und 10). Galileo Press
GmbH, 2005.
[TRU] T. Truppel. Comparison of DTR and Subversion.
Seminar System Modeling, Juni 2005
[BOE] S. Bttner. NetWeaver Java Development
Infrastructure. Seminar System Modeling, Juni 2005.
169
Anhang
Abbildung 1: Die Architektur der NWDI (nach [BOE] und
Abbildung 8: Parallele, untereinander abhngige Tracks
170
Abbildung 12: Ablauf der Entwicklung im berblick, unter der Annahme, dass keine Fehler auftreten
171

Sap Web Dynpro SysmodSeminar2005

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Sap Web Dynpro SysmodSeminar2005

Diunggah oleh

Hak Cipta:

Format Tersedia

HASSO - PLATTNER - INSTITUT

fr Softwaresystemtechnik an der Universitt Potsdam

SAP Web Application Server

Technische Berichte des Hasso-Plattner-Instituts fr Softwaresystemtechnik

SAP Web Application Server Technology

Bernhard Grne, Peter Tabeling

Bibliografische Information der Deutschen Bibliothek

Die Reihe Technische Berichte des Hasso-Plattner-Instituts fr Softwaresystemtechnik an der

Professoren des Hasso-Plattner-Instituts fr Softwaresystemtechnik

Bernhard Grne, Sabine Wagner

Hasso-Plattner-Institut fr Softwaresystemtechnik an der Universitt Potsdam, 2006

Bea JRockit (Sebastian Steinhauer)

The SAP VM Container (Andreas Blher)

Administration of the SAP Web Application Server (Martin Wolf)

UME: User Management and Security (Marco Helmich)

The Eclipse Platform (Matthias Kunze)

Eclipse PlugIns (Michael Perscheid)

12 Apache Struts (Daniel Rinser)

13 Web Dynpro Overview (Andreas Fahle)

14 Web Dynpro: Navigation and ComponentOrientation (Christian Holz)

15 Web Dynpro: Context Mapping and Model Binding (Matthias Weidlich)

17 The Java Data Objects Persistency Model (Stefan Marr)

18 SAP DTR und Subversion: Zwei Versionskontrollsysteme (Tino Truppel)

19 Die SAP NetWeaver Development Infrastructure (Sebastian Bttner)

System Modeling of the SAP Web Application Server

covering the presentation and the Q&A session. It

This report presents the results of the seminar System

The first part of the report gives an overview of the

The Clustering Concept of the

Typically, these services are mission-critical,

The Java 2 Enterprise Edition (J2EE) has become

high-performance ERP2 software systems is

Enqueue Server (see section 2.2.2). The central

Clustering Architecture of the

SAP Central Services

Figure 1 shows the general structure of a

2.2.1 Message Server

abbreviation for Enterprise Resource Planning

Application Programming Interface

course affects the network performance and,

Expanding the cluster

As a part of the Central Services, the Enqueue

The SAP Web Application Server realizes load

JVM startup agent

JVM startup agent

JVM startup agent

JVM startup agent

The SAP Web Dispatcher acts as a global load

Figure 2: Structure of a J2EE-Engine during

SAP Web Dispatcher

Alternatively, it is possible to set up a thirdparty hardware solution instead of using the

The failover services supported by the SAP

Bean session failover

Each J2EE-Engine possesses a J2EEDispatcher. Within the engine, the dispatcher

HTTP session failover

A J2EE-Dispatcher receives requests that

Failover services supported by the

4.2.1 Bean session failover

The deployed applications within a cluster

supports failover mechanisms for both types

The two abovementioned failover services

HTTP session failover

Since most of the communication between

Overall system stability