Analysis and modeling of OSGi-based SOA-applications
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Analysis and modeling of OSGi-based
SOA-applications
Benjamin Schroth, Grigorij Aronov, and Sarah Oppold
IAAS, University Stuttgart,
Universitätsstraße 38, 70569 Stuttgart, Germany
{schrotbn,aronovgj,oppoldsa}
@studi.informatik.uni-stuttgart.de
http://www.iaas.uni-stuttgart.de/
Abstract. The OSGi framework can be used to develop modular java-
based applications which are configurable dynamically at runtime. With
OSGi Declarative Services complex service oriented architectures can be
realized. But this part of the OSGi framework is not supported very well
by development tools. Many tasks, such as analysing existing architecture
or the initial modeling of a new application has to be performed by hand.
In this project we developed a graphical modeling tool with automatic
analysis and generation for such applications.
Keywords: OSGi, Declarative Services, SOA, Modelling
1 Introduction
The Declarative Services of the OSGi framework provide an easy way to im-
plement SOA-based architectures. Declarative Services are described in special
XML-files, the component-XML-files. That is a description of a component and
its provided or referenced services in XML. These descriptions contain all param-
eters needed by the OSGI Service Component Runtime to appropriately handle
the dynamic activation and deactivation of such services at runtime.
The tooling for this initial modeling or later analysis of these implementations
is not very satifying. That means that the developers have to write the needed
XML documents and all needed classes by hand. The later analysis and validation
of such architectures is not supported as well and developers or architects have
to look at each XML file and draw their diagrams manually to analyse the
complete architecture. This is a big error source in the evaluation process of the
architectures of these applications.
Within this project we developed an Eclipse-based graphical editor to provide
an easy-to-use tool for modeling new applications and to create diagrams of
existing architectures. For this purpose we implemented an automatic analysis-
tool to parse existing architectures to a diagram. In addition we implemented a
generator which can generate a complete project-structure including the needed
Java-classes and -intefaces and the Component-XML files.
2 Analysis and modeling of OSGi-based SOA-applications
The rest of this chapter describes the goals and use-cases of this project. Sec-
tion 2 describes the used technologies and section 3 the the plug-ins we developed
in the context of this project before we conclude in section 5.
1.1 Goals
To make the development of SOA-based applications using Declarative Services
easier, within this project the IDE Eclipse PDE should be extended to provide a
possbility to analyse such architectures, for initial modeling and for modifications
with a graphical editor.
The result of this project should be able to
– Analyse existing Declartive Service-based architectures
– Create an editable model instance from analysis
– Provide a graphical editor for model instances
– Generate new project-stubs from a given model instance
1.2 Use cases
Figure 1 shows the identified use cases of this project.
Fig. 1. Diagram of all possible use cases
These are in detail:
Analysis and modeling of OSGi-based SOA-applications 3
Initial Modeling An architect wants to model the initial architecture of his
SOA-based application and uses the graphical editor to model all needed bundles
with its components and the services referenced/provided by these components.
Model editing During the modeling of new architectures the architect wants
to modify his architecture in an easy and intuitive way. To do this he can use
either the EMF-provided graphical editor (see Figure 2) or the diagram editor.
Code generation The developer who implements the modeled architecture
wants to create the stubs as the base for his implementation according to the
model of the architect. The project provides automatic code generation with a
given model instance as input and a complete project structure in the current
workspace as output.
Analysis of existing architectures The most important use case is the anal-
ysis of already implemented architectures. To do this the architect who wants
to analyse the architecture can use the build-in parser to create a correspond-
ing model instance for an Eclipse WorkingSet, a whole Workspace or a single
Project.
2 Used technologies
To implement the requested features we decided to use the following technolo-
gies/frameworks:
2.1 Eclipse Modeling Framework (EMF)
The Eclipse Modeling Framework is a modeling framework and code generation
facility for building tools and other applications based on a structured data
model. From a model specification described in XMI, EMF provides tools and
runtime support to produce a set of Java classes for the model, along with a set
of adapter classes that enable viewing and command-based editing of the model,
and a basic editor.
We used EMF to design the data-model and to generate the needed code.
The framework enables the user to design a data model in a graphical way and to
generate the needed code. We used the diagram-editor (provided in the plug-in
Ecore Tools [4] ) to design the data model. We only needed edit-, editor- and
model-code for this project. This provides a graphical tree-editor to view and
edit existing model-instances and a useful API to programmatically read, save
and modify a model instance.
EMF also provides the EMF Validation Framework which can provide a
validation of single model elements or entire model instances.
4 Analysis and modeling of OSGi-based SOA-applications
Fig. 2. The graphical editor provided by EMF
Analysis and modeling of OSGi-based SOA-applications 5
2.2 GMF
The Eclipse Graphical Modeling Project (GMP) provides a set of generative
components and runtime infrastructures for the development of graphical editors
based on EMF and GEF (Graphical Editing Framework).
By specifying a tooling-, graphical- and mapping model definition, one can
generate a fully functional graphical editor based on the GMF Runtime. [2] The
tooling-definition defines all needed tools for the tool palette (e.g., Creation-Tools
to create new nodes/links). In the graphical definition the user defines all needed
nodes and their graphical representation. The mapping model definition brings
tooling and graphical definition together and defines the mapping of nodes to the
underlying model-elements. Based on this mapping model definition a genmodel
is generated, which can be used to generate the editor code.
All GMF definition models are fully customizable through a graphical tree
editor and provide much functionality.
2.3 JET
Java Emmitter Templates is typically used in the implementation of a ”code
generator”. A code-generator is an important component of Model Driven De-
velopment (MDD). The goal of MDD is to describe a software system using
abstract models (such as EMF/ECORE models or UML models) and then re-
fine and transform these models into code. Although is possible to create abstract
models and manually transform them into code, the real power of MDD lies in
the automation of this process. Such transformations accelerate the MDD pro-
cess and result in better code quality. The transformations can capture the ”best
practices” of experts, and can ensure that a project consistently employs these
practices.
However, transformations are not always perfect. Best practices are often
dependent on context - what is optimal in one context may be suboptimal in
another. Transformations can address this issue by including some mechanisms
for end-user modification of the code generator. This is frequently done by us-
ing ”templates” to create artifacts and allowing users to substitute their own
implementations of these templates if necessary. This is the role of JET. [3]
We used JET for code-generation by the Generator. There are three tem-
plates used for the generation of the project-stubs from a model instance:
– Manifest
– Component-Implementation-Class
– Service-Interface
Eclipse compiles JET automatically on-save to corresponding Java-classes
which can be used to generate the output as a String-object.
2.4 Log4j
Eclipse PDE comes with a log4j-bundle. To use log4j we had to provide a frag-
ment bundle which contains the configuration and a custom Appender to inte-
grate log4j in the Eclipse PDE ILog system.
6 Analysis and modeling of OSGi-based SOA-applications
3 Components
Figure 3 shows all provided plug-ins and their relationships. The project provides
Fig. 3. Overview of all components and their relations
the following plug-ins:
– com.dsanalyser.model
– com.dsanalyser.parser
– com.dsanalyser.generator
– com.dsanalyser.editor
– com.dsanalyser.editor.custom
– com.dsanalyser.help
In the following the plug-ins will be described in detail.
3.1 Data model
Figure 4 shows the developed data model as an ecore-Diagram. It is de-
signed closer to the later developed graphical diagram-editor than to the OSGi-
specifications. This decision makes it easier to generate the basic GMF-models
and minimizes the manual work in the GMF-models after generation.Analysis and modeling of OSGi-based SOA-applications 7
This determines the corresponding aggregation-relations between the root-
element (Bundle-Diagram) and the other entities. In figure 4 it can be seen that
a Component resides inside a Bundle. The root-element only contains Bundles
and Interfaces.
We added two extra attributes, which aren’t part of the OSGi-specification.
The projectname-attribute to provide a projectname, if it is not equal to the sym-
bolic name of the bundle and the extern-attribute of the Interface-class which de-
termines if the generator should generate a new project for this service-interface.
This implies the diagram-design where only the Bundle and Interfaces are top
level nodes and the Component resides in the Bundle as a subnode.
Fig. 4. Data model as ecore-Diagram
3.2 Parser
The parser for automatic analysis of existing architectures resides in the
com.dsanalyser.parser.impl plug-in. It provides three different modes:8 Analysis and modeling of OSGi-based SOA-applications
Workspace Parses the current Workspace completely and builds a model in-
stance for all projects contained in this Workspace.
WorkingSet Builds a model instance of one particular WorkingSet. A Work-
ingSet is a user-defined set of projects.
Project Parses only one particular project.
The parser begins with the manifest of a project to fill a new bundle object
of the model with its parameters. The manifest is also used to determine if it
has component-XML-files (as named in the Service-Component-header of the
manifest). If a manifest doesn’t have components declared the project will be
skipped because we only want to model the Declarative Services. A component-
XML-file which doesn’t exist, will be skipped too. If none of the Component-
XML-files exist the parser will generate an empty bundle object and add it to
the model. This can happen if the component-XML-files resides in a fragment
bundle.
After parsing the manifest each component-XML-file will be parsed on its
own and the parser will determine the parameters of the component and its
service references and providers. The parser manages a global list of all the
services found to create the links in the model correctly.
After all projects are parsed, the parser determines if a service-interface has
to be created (resides in the Workspace at parsing-time) or if it is external (e.g.,
one of the OSGi-provided service-interfaces).
The final step saves the model instance as a .ds-file to the specified target-
location. These files are an XML-representation of a single instance of the data
model (see Listing 1.1).Analysis and modeling of OSGi-based SOA-applications 9
< i n t e r f a c e i n t e r f a c e N a m e=” datumserv . DatumService ” />
Listing 1.1. Example model instance
3.3 Generator
The generator resides in com.dsanalyser.generator.impl plug-in. For a given
model instance it generates all necessary projects (bundles) including all mani-
fests, component-XML-files and Java compilation units.
First, all needed service-interface-projects will be generated. They are named
after its package name (Substring of the attribute InterfaceName until last ’.’)
and will only be generated if the extern-attribute is false. They contain one (or
more, if they have the same package name) empty java interfaces.
The projects are named using the underlying bundle-objects projectname
or, if this attribute is null, its symbolic name. For the needed manifest,
build.properties- and Java classes JET is used to generate the needed code.
3.4 Graphical GMF-based Editor
Based on the data model we were able to use GMF to generate a correspond-
ing diagram-editor. GMF takes the ecore-Model and the generated genmodel as
input and tries to create the needed tooling definition, graphical definition, map-
ping model and genmodel on its own. With our data model as base the generated
GMF-models needed some manual adjustments in the graphical definition and
in the mapping model to provide all needed functionality. GMF was not able to
recognize our links (Service and ServiceReference) as well as the compartment
of the Component-node.
Figure 5 shows a page of our mockup we designed before we began
to model the editor. Figure 6 shows the editor after all manual work
was done. The editor also uses the provided inline-help-system (see sec-
tion 3.6). To be able to integrate this, we needed to edit the generated
com.dsanalyser.sheet.DsmodelPropertySection and provide our own Proper-
tySource-implementation.
3.5 Menus - The Eclipse Extensionpoints
To integrate the Parser and Generator in Eclipse we used the Eclipse Extension-
points to provide a menu entry for each of these components. The generator can
be called via the context menu of a .ds-file as well.10 Analysis and modeling of OSGi-based SOA-applications
Fig. 5. The mockup for the designed Editor
Fig. 6. The generated GMF-editorAnalysis and modeling of OSGi-based SOA-applications 11
Menu-Entries The plug-in provides an additional menu for the Eclipse menu
bar which represents the calls of the parser and generator (see Figure 7). In addi-
tion the plug-in provides a context-menu-action for .ds-files to call the generator
directly on model instances inside the current workspace (see Figure 8). The
menu entries are implemented as actions and declared via the extensionpoints
org.eclipse.ui.popupMenus and org.eclipse.ui.actionSets.
Fig. 7. New menu provided by the plug-in
Analyse-Wizard The Analyse-Menu-Entry opens a wizard to configure the
parameter for the analysis. This wizard (and the called parser, see section 3.2)
can be run in three different modes (see figure 9). After the selection of the de-
sired mode, the user can select the corresponding target in project/workingset-
mode(see Figures 11 and 10) and the output-filename (see Figure 12). If all
selections are done and valid (input files should exist and the output file should
be stored in a valid container) the user can click finish to start the analysis. To
implement this, we extended the abstract Eclipse classes Wizard and Wizard-
page.
Each mode requires the selection of an outputfile (see figure 12).
3.6 Custom editor-extensions and inline-help system
To make the usage of the graphical editor easier we decided to provide helptexts
for each attribute in our data model.
To achieve this goal we extended the EMF-Standard-CellEditors. These
classes provide the editing-functions and the appearance of the cells in
the Property View. We added a Help-button which opens the eclipse-help-
system with predefined paths on a click to show our helptexts provided by
com.dsanalyser.help (see Figure 13).
The plug-in com.dsanalyser.editor.custom provides these custom editors and
the needed PropertySource, PropertyDescriptor and PropertySourceProvider
implemenations to integrate the editors in our model as well as in the diagram-
editor.
The helptexts are stored in the plug-in com.dsanalyser.help which also pro-
vides a static helper-class to get the needed paths in the eclipse helpsystem.12 Analysis and modeling of OSGi-based SOA-applications
Fig. 8. Contextmenu entry provided by the plug-inAnalysis and modeling of OSGi-based SOA-applications 13
Fig. 9. First page of the wizard: Selection of the parser-mode
Fig. 10. Selection of a WorkingSet14 Analysis and modeling of OSGi-based SOA-applications
Fig. 11. Selection of a project
Fig. 12. SelectionPage of the wizzard for a WorkingSetAnalysis and modeling of OSGi-based SOA-applications 15
Fig. 13. Custom CellEditor which provides an additional Help-button
4 Validation
In early development phase we implemented JUnit Plug-in Tests for generator
and parser. This allows automatic testing with some small example project sets
with 2 services and 3 bundles.
Finally we tested the project with a real world example: OpenTOSCA. Open-
TOSCA is an open source browser-based TOSCA runtime environment (also
called TOSCA Container) for running TOSCA-based applications. The system
supports installing Cloud Service Archives (CSAR) that contain all files needed
to instantiate the service, e.g., TOSCA Service Templates, software artifacts as
well as management plans. Based on these archives, the management plans are
used to create and managet instances of the corresponding application [5].
Fig. 14. Part of the OpenTOSCA-Diagram generated by our project (manual layout)16 Analysis and modeling of OSGi-based SOA-applications
The part of OpenTOSCA we used for testing contained 25 bundles, 44 com-
ponents, 71 service references, 30 service provides and 23 different service inter-
faces. Figure 14 shows part of the resulting diagram after parsing part of the
OpenTOSCA project set. OpenTOSCA contains some fragment bundles, which
we can’t parse at the moment (see section 5).
5 Conclusion
We were able to implement a graphical editor for Declarative Services-based and
service oriented architectures with the ability to automatically analyse existing
projects and to generate stubs for new architectures. This implementation is
able to handle real world architectures with many bundles and services such as
OpenTOSCA and provides an easy-to-use tool which covers all identified use-
cases.
A possible and needed extension is the handling of fragment bundles. This
special sort of bundles sometimes provides the XML-files for Declarative Ser-
vices of other bundles. This enables the user to provide services dynamically by
removing or adding the corresponding fragment bundles (e.g., for testing). Our
impolementation is not able to parse and interpret such dependencies, yet.
References
1. http://www.eclipse.org/modeling/emf/
2. http://www.eclipse.org/modeling/gmp/
3. http://www.eclipse.org/modeling/m2t/?project=jet#jet
4. http://www.eclipse.org/modeling/emft/?project=ecoretools#ecoretools
5. http://www.iaas.uni-stuttgart.de/OpenTOSCA/indexE.phpYou can also read
