A Framework for Distributed Development Environment -

weaverchurchSoftware and s/w Development

Aug 15, 2012 (5 years and 29 days ago)

206 views


1

A Framework for a Distributed Integrated Development Environment Based on
Jini


Gary Hoi Kit Lam

Carfield Wai Him Yim Stephen Chi Fai Chan

Department of Computing, Hong Kong Polytechnic University



Abstract


This paper discusses the work on develop
ing a
dynamic and extensible framework for an open,
distributed software development environment. Internet
Integrated Development Environment Framework
(Internet
-
IDEF) is a set of APIs built on top of Jini,
making use of JavaSpaces and a number of design
p
atterns. Major components in the framework include a
platform infrastructure, utility classes, a file
management system, tool startup, communication, plug
-
in and tool administration facilities. These components
help tool developers plug tools into the fram
ework
eff
icient
ly. A remote Java compiler and a collaborative
UML editor, which includes a version engine as another
tool, were used as sample applications
for

testing
and
validating the framework.


1.

Introduction


Software development is a complex process

i
nvolving
m
any activities

and
requir
ing a

variety of tools.
Integrated Development Environment
s

(IDEs)
are

developed
to reduce the

repetiti
ve

installations
of
large
number
s

of development tools. However,
an
IDE
often
does not support particular tools requir
ed by specific
projects. Productivity is reduced when tool
s

required
are

not readily available.

Most IDEs are close
d

systems with
low extensibility. In addition, IDEs are
generally
limited
by location boundary and geographic issue which limit
collaborative

work supported to LAN level
. Finally,
t
edious re
-
installations are required when developer
s

move to different
location
s
.

A

distributed software development environment
should have the

following characteristics: open, high
extensibility, high scalability,

dynamic and collaborative
support
at the

WAN level. This paper
discusses the
construct
ion of

a dynamic and extensible framework, the
Internet
-
IDEF (
IIDEF), to support such a
software
development environment.

The framework
is
built on
top of Jini and ma
kes

use of JavaSpaces and
a
number of
design patterns [4, 6, 8, 15, 16]. Architectural design and
core API designs for dynamic plug
-
in and
communication in the framework are included.

S
ection 2
presents
related works and a brief technical
background. Major r
equirements of
the
Internet
-
IDEF
are described in section 3. Design and Implementation of
Internet
-
IDEF is shown in section 4
, where
the
framework architecture
and
critical design issues on
dynamic plug
-
in and communication
are discussed
.
Section 5 present
s the validation of the framework.
Finally, section 6

concludes
this

paper
.


2. Background


O
ur aim is to provide a framework for the software
development environment
,
and
PRINCEPS [22] is a
framework with similar objectives for providing feasible
services

in the distributed environment
, aiming to
support

a

variety of services in different application
domains. The work is focused on the service and client
interaction
, and t
he interaction between tools is not
included. It provides a web
-
based mechanism for
s
electing desired services with different service types on
client side.
In t
his
aspect, it is
similar to
IIDEF
but
IIDEF
use
s

a
different strategy to solve the problem

-

an
a
pplication based tool browser
is
implemented in our
framework at this stage. Rich G
UI application support is
not discussed in [22] but this provided in IIDEF.
W
hile
the communication issue was not discussed in detail in
[22], JavaSpaces
is
used in
IIDEF
to provide
a
flexible
communication channel
.

Jtop
[21] is
a proposed system that aim
s

to
provid
e

a
Java integrated development environment on top of Jini
.
It seems to be mainly
a conceptual
design, where the
system
architecture
seems to be in
complete
, and we are
not aware of a prototype
implement
ation
.

Recently, several integrated
but ext
ensible
development environments had been developed.
Two
emerging IDEs, Netbeans[18] and Eclipse[10], are
typical example
s
.

The
y

are

capable of supporting
dynamic module plug
-
in for enhancing functionality by
having their own plug
-
in mechanism
s

for tool pr
oviders
,
and b
oth are open
-
sourced.

In order to support dynamic
module plug
-
in,
the
two vendors provided their own base
platform for plugging other tools into the systems
,
through a
set of API
s
.



2

2.1 Plug
-
in Mechanism and Technology Used


A m
anifest is a f
ile used to describe the components
or modules that are going to be plugged into the IDE
platform. It contains a set of defined tags
which
describe

the

plug
-
in related information
, and
give instructions
for

component
install
ation
. Netbeans use
s
its own def
ined
tag in the manifest [12, 13], similar to Java JAR
manifest, while Eclipse used XML in the manifest [11].

Open APIs in NetBeans, which provide classes and
interfaces for new JAR
-
based modules as NetBeans
plug
-
ins, provided a way to insert pluggable too
ls
,
based
on the Java Extension Mechanism [13]. In Eclipse,

a
new module is plug into an extension point, which is
provided by predefined extension points from the base
platform or others
defined by other tool providers. The
result is a
hierarchical struct
ure of plug
-
ins.
B
oth
Netbeans and Eclipse are standalone Integrated
Development Environment. Eclipse

does provide support
for team development, although only for
local teams.

The notion of plug
-
in
has proven to be u
seful
for
dynamic extension
. The basic
features

of the framework
proposed
in IIDEF
are as follow
s:


1.

Software development tools are distributed.

2.

The framework
fits in

the
Internet

environment

3.

The framework is open
, with h
igh extensibility.


Internet
-
IDEF is a distributed software development
fra
mework for other tool providers to plug their tool on
it. It is also benefic
i
al to application software developers
,
since

m
anual

installation of tools is not required
. T
he
project
delivers
a set of APIs
that
tool provider
s can
use

to
plug
-
in their software

development tools into the
environment.



3. Requirements

of IIDEF


In general, the framework is a middle layer
to
hide
the backend details (such as Jini and JavaSpaces)
from
the t
ool
d
evelopers
, who
only need to focus on their
tools' function
ality
.
T
he f
ramework is
also
a middle layer
to provide

a

basic
but
sufficient
interface for application
developers, i.e.
the

end users. The framework should
facilitate tools interactions and client interactions.
In
addition to these functional requirements, the framew
ork
should also be

dynamic, scalable,
and
adaptive. In
concrete terms
, the framework should fulfill the

following

requirement
s:




Tools
can

be added
to
and removed
from

the
framework/system transparently.



N
ew tools
may have

unforesee
n functionality
.



Clien
t
s

should
be able to
use
new tools

without
modification in client code after the application is
released.



The framework should allow integration of additional
service/tools without requiring modifications to its core
architecture.



The framework should su
pport existing/legacy tools,
which may be command line application or tightly
coupled GUI application with rich GUI.



Tools may be either local or remote.



Tools can interact with each other
through

communication
facilities
provided

by the framework.



Multi
-
user support should be
possible
. This involves user
management.



Automatic startup or plugging mechanism is needed to
solve the problem of writing
repetitive

code to startup
development tools, which involves finding lookup
services, joining
,
creating tool
information and
etc
.



4. Design and Implementation


Based on the requirements above,
the design of
an
architectur
e a
nd
the
core components
were carried
out.
Figure 1(a) depicts the layered architecture for the whole
distributed environment while figure 1
(b) depicts the
components architecture in the Internet
-
IDEF
framework.


















Figure 1: (a) Development Environment Architecture, (b)
Framework Architecture


4.1 Framework Architecture


Internet
-
IDEF consists of a set of component
s

for
helping

tool developer
s

to plug
-
in

their tools
efficiently

as shown in Figure 1(b).

The

API for Jar file tools
,
API
for Remote Service

and
Startup Facility

offer the
foundation for dynamic plug
-
in functionality.

The

API
for Jar file tools

is the API for plug
-
in t
ools in Java Jar
file format and
API for Remote Service

is the API for
plug
ging
-
in remote access tools.

The

Startup Facility

provides an easy way for
plugging
tools
in
.

The

Communication Facility

provides the standard
Java


Jini network technology

Internet
-
IDEF

JavaSpaces


Tool

Tool

Tool

Tool

Project
Resource
Management

Communication

Facility

Network
Resource
Management


Util

Startup
Facility

Tool
Administration

ToolProxy
Interface

API for JAR file

tools

API for

Remote Serv
ice


Client

Application


3

communication mechanism for clients an
d tools
to
collaborat
e
. Detail
ed

design issue
s

will be discussed in
the following sub
-
sections.


4.2 Dynamic Plug
-
in API


The system provides a
n interactive and adaptive

distributed software development

environment
. New
tools can be added
to
and removed

fr
om the system
dynamically and transparently. Client
s

can use the new
system without any modification
to

the client code.

Jini technology
allows

any kind of services
to
be
registered to a lookup service [1, 2, 5, 14, 20]. That is,
any kind of developing to
ol can be added to the system
as a service
of

a
ny
Java type. For example, a java
complier can be implemented
as

Compiler

Java type
while a text editor can be implemented as
Editor

Java
type.
For

tools implemented in this
manner
, modification
of client appl
ication code is necessary to support all the
possible
Java service type
s
. As a result, Jini’s service
matching mechanism
creates
problem
s

during
the
development of
a
framework

as proposed
. Further
discussion on t
he

Jini service matching mechanism can
be fo
und in [1, 2,14, 20].

Vayssiere [3] provides a solution in the form of an
Adapter service, which wraps the unsupported Java
service type into a supported Java service type.
However, this solution is not suitable for IIDEF. Firstly,
it only solves the probl
em partially. If there is a tool that
does not belong to any registered service type, the client
application code still needs to be modified. In addition, it
is necessary to encapsulate concepts of Jini as much as
possible to reduce the burden of software
tool
development. However, since the Adapter is a service,
developers must have sufficient knowledge of Jini
technology. On the other hand, developers are required
to know the semantics of all registered services but the
documentation for those services ma
y not be available.

A client application can accept all the service types.
Users can choose the tools to be used. However, they
may not know how to request the services from the tools.
This implies that if the client wants to make use of a new
tool with a
new interface type, the client application may
need to make undesirable code modifications.

To solve these problems, a standard service interface,
called
ToolProxy
,

is defined. Similar to the Java
applet, there is an
init

method which can be overridden
by
tool developers.

The

Command

and
Adapter

patterns [4] are applied
in the API design for the plugging
-
in of command line
tools. These two patterns allow tool developer to
implement the pre
-
processing and post
-
processing tasks
before executing the real comm
and and to wrap the
existing command line tool respectively.

Tool developers have to “JAR” their tools as a JAR
application to plug
-
in rich GUI tools. Internet
-
IDEF uses
the
Java Extension Mechanism

[9] to load the tools from
remote hosts into the client s
ide. Tool developers have to
follow the manifest convention. The whole API is shown
in the class diagram below:


Figure 2: Dynamic Plug
-
in API for remote development tools.


Startup Facility

This component helps tool developers to join
Internet
-
IDEF autom
atically. The component also
encapsulates the joining process from the developer so
that tool developers do not have to write repetitive code
for joining different tools. The startup process should be
performed automatically as much as possible. A single
s
tartup process should be adopted for all tools, since the
proxy that is needed is not known at the compilation
time. How can a startup object determine which proxy
class is used to create the proxy object at run time is
another problem. The
Template Method

pattern is used
for providing a template of an algorithm [4], while the
Abstract Factory

pattern was used for encapsulating the
creation of the proxy of specific tools [4]. The Java
Reflective API is used in the factory for dynamic
instantiation of
ToolPr
oxy

objects. Figure 3 shows the
actions involved to join a tool to the framework.


Figure 3: Sequence diagram for the startup mechanism.





4

Client Tool Browser

The client tool browser is the last step needed to
support dynamic plug
-
in’s.

It searches for all tools
belonging to the
ToolProxy

type and provides the most
up
-
to
-
date status in the environment. Information on the
tools will be shown to users for selecting the most
suitable one.


4.3 Communication Facility


Tools often do not jus
t operate on their own. Client
interactions and tool interactions should also be
supported by the framework. Thus, it is necessary to
define a standard data structure and protocol for tools to
communicate. JavaSpaces technology [7, 17] provides a
flexible
way for the implementation of the
communication channel.

The
DataObject
data structure stores the data to be
written into JavaSpaces including
Receiver
,
Sender

and
Message

Number

identifies the data object
uniquely.
Message

Number

will be assigned when th
e
data object is written to a space.

MessageNumber

is an object that indicates the
largest message number used in this channel, which is
identified by the
from

and
to

attributes. A
number

attribute stores the largest message number.


Figure 4, shows one s
cenario of the high
-
level
protocol design involved when a client object requests a
tool to execute a certain task. A typical use case of the
protocol is as follow:







Figure 4: A collaborative diagram of the protocol design


5 Validat
i
on


A compiler to
ol and a collaborative UML editor were
used in the testing and validation of software
development tools in our framework.


5.1 Compiler plug
-
in approach


The compiler is a command line tool and is a native
Java compiler. Based on these characteristics, it
was
decided that the compiler should be plugged in as a
remote complier so that clients can compile Java
program remotely. Figure 5 shows how Dynamic Plug
-
in
API for remote development tools was instantiated in
handling a client compilation request.

: client
: MainFrame
: CompilerTool
: CompilerDoTaskCommand
: CompilerResultHandler
: Channel
1: <<run compiler>>
2: init(ServiceItem, CommandOption[], ServiceID, String)
: OptionDialog
3: <<create>>
4: doTask(Channel, CommandOption[],ResultHandler)
: CompilerAdapter
5: sendData(DataObject)
6: doCommand(Channel, CommandOption[], int)
7: handleResult(Channel, CommandOption[], int)

Figu
re 5: Collaboration diagram of how a client compilation
request is handled


5.2 Integration of a collaborative ArgoUML to
the framework


Another test of the validity of framework is to
integrate a collaborative ArgoUML system into the
framework. All core A
PIs in the framework were fully
utilized in the integration of the editor, including an API
for remote tools, an API for communication and an API
for rich GUI tools. The integration was designed and
partially implemented. The following section will
discuss

problems we encountered in the integration and
the design approach we used.

Distributed ArgoUML is a collaborative UML editor.
It is an interactive application, with a rich GUI.
Communication is a critical core function for a
collaborative application. A
versioning engine was
implemented to provide collaboration support. The
integration of distributed ArgoUML could be separated
into two parts. It was required to integrate 1) the
versioning engine and 2) ArgoUML. For further
information, please refer to [19
]. For part 1, the design
was similar to the Java remote compiler illustrated in
section 5.1. For part 2, the design should ensure that
clients can download the whole ArgoUML application
and support the communication with other ArgoUML
users in the Jini ne
twork at the same time.

From the above, it is found that support for multiple
commands in one tool is required, which is supported by
addTool

method in
LocalToolProxy

class, which is
responsible for registering all tools that are added to the
LocalToolPro
xy

object.

To support user collaboration in the UML editor, we
developed a tool that is like a Communicator for clients
and
addTool
method is used in the implementation of
ProxyFactory
. Thus, the Communicator will be
automatically joined to the Lookup Ser
vice and any new
UML editor client user will get the Communicator and
can do the real time collaboration.




1: Write(source)

6: read(result)

3: read(source)

2: doCommand()

5: write(result)

Remote

Service

JavaSpace

ResultHandler

Exist
Application

Client

4: reques
tService()


5

6. Conclusion


A set of APIs was implemented to realize IIDEF. It
aims at helping tool developers to plug their
development tools into the framewor
k. A compiler and a
UML editor were used to validate the design of
framework. It was found that the integration of the Java
compiler was successful and the compiler runs properly.
The design and partial implementation for the integration
of UML editor [19]

were also achieved. A list of
components that were implemented, includes: dynamic
plug
-
in APIs,
ToolProxy

interface, service utilities, tool
administration, client tools browser, communication and
tool startup facilities.

From the experience in integratio
n of the two tools, it
validates that the main features of the framework were
basically sufficient in order to provide an open, dynamic
and distributed framework for software development.
However, it is found that further investigation in the
adaptability
of the framework is required. More
development tools are needed so that the framework can
evolve as more tools are plugged in. On the other hand,
improvement in multi
-
users collaboration support is
required from the experience in the integration of the
col
laborative UML editor. Although the framework
supports multi
-
function services, the framework design
can be enhanced when more non
-
functional requirements
are taken into account such as performance. Refinement
on interface abstraction of the framework coul
d be done
in order to provide an adaptable, functional, easy
-
to
-
use
interface abstraction to tool providers.

Alternative designs and exploitation of existing
technologies that are appropriate for the problem domain
would be necessary. Investigation on core

notions or
mechanisms behind Applet, Servlet and MIDlet is
required. These three technologies are similar in nature
in providing an interface abstraction for application
developers for implementation according to the
requirement for client users or client

objects. Further
research into how to control the Servlet and MIDlet by
internal component such as Servlet container for Servlet
and application manager for MIDlet would be useful for
improvement of the framework. Those technologies will
be investigated f
or further framework enhancement in
the future.


References

[1]

W. Keith Edwards (2001),
Core Jini 2
nd

Edition
, Sun
MicroSystems Press Java(tm) Series.

[2]

Scott Oaks, Henry Wong,
Jini in a Nutshell: a Desktop
Quick Reference
, O’Reilly.

[3]

Vayssiere, J
.,
Transparent dissemination of adapters in
Jini
, Proceedings. 3
rd

International Symposium on
Distributed Objects and Applications, 2001, pp. 95

104.

[4]

Gamma, E., et al.
Design Patterns: Elements of Reusable
Object
-
Oriented Software
, Addison
-
Wesley, R
eading,
MA, 1995.

[5]

Sun MircoSystems (2001).
Jini(tm) Technology
Datasheet
.
http://wwwwswest.sun.com/jini/whitepapers/jini
-
datasheet0601.pdf

[6]

Frank Buschmann, et al.


P
attern
-
oriented software
architecture: a system of patterns
,
Chichester, England:
Wiley, 1996.

[7]

Eric Freeman, Susanne Hupfer, Ken Arnold
,
JavaSpaces
Principles, Patterns, and Practice
,
Addison
-
Wesley,
1999

[8]

Linda Rising,
Design Patterns: elements o
f Reusable
Architectures
, Annual Review of Communications,
Vol.49, 1996, pp.907
-
909.

http://www.agcs.com/supportv2/techpapers/patterns/paper
s/patterns.htm

[9]

Mary Camp
ione, Kathy Walrath, Alison Huml, Tutorial
Team,
The Java(TM) Tutorial Continued: The Rest of the
JDK(TM)
, Addison
-
Wesley, 1998.

http://java.sun.com/docs/books/tutorial

[10]

An official web site of
Eclipse Integrated Development
Environment:
http://www.eclipse.org

[11]

Object Technology International, Inc.,
Eclipse Platform
Technical Overview
, 2001.

http://www.eclipse.org/whitepapers/eclipse
-
overview.pdf

[12]

The Netbeans IDE.

Netbeans IDE

Java Doc
-

Modules
API
.

http://ww
w.netbeans.org/project/www/download/apis/org
/openide/modules/doc
-
files/api.html#how
-
manifest

[13]

Sun Mircosystem,
The NetBeans

API
-
A Developer’s
Guide
.

http://www.sun.com/forte/
ffj/whitepapers/netbeansapiwp.
pdf

[14]

Jim Waldo, Ken Arnold (Editor), The Jini Team
,

The
Jini(TM) Specifications, 2
nd

Edition
, Boston, Mass.:
Addison
-
Wesley, c2001

[15]

Douglas Schmidt, et al.


Pattern
-
oriented software
architecture:

Patterns for concu
rrent and networked
objects
,
Chichester; New York, N.Y.: John Wiley &
Sons, 2000

[16]

James O. Coplien,
Software Patterns,

SIGS Books, New
York, New York, 1996.

h
ttp://www.bell
-
labs.com/user/cope/Patterns/WhitePaper/SoftwarePatterns
.pdf

[17]

Sun Mircosystem,
JavaSpaces(TM) Service Specification
,
pages 1
-

9.

http://java.sun.com/products/javaspaces
/index.html

[18]

An official web site of Netbeans IDE:

http://www.netbeans.org/

[19]

Yim Wai Hin,
A Framework for an agent
-
based
development environment with Jini/Javaspaces (Real
-
time
collaboration support)
, Th
e Hong Kong Polytechnic
University, Final Year Report, 2002.

[20]

Jan Newmarch,
Jan Newmarch's Guide to JINI
Technologies
, 2001.

http://pandonia.canberra.edu.au/java/jini/tutorial
/Jini.xml

[21]

Web site of Jtop Project:

http://developer.jini.org/exchange/projects/jtop/

[22]

Cotroneo, D. Di Flora, C. Russo, S.,
A JINI framework
for distributed service flexibility
,
Proceedings of the 10th
Euromicro Workshop on Parallel, Distributed and
Network
-
based Processing (EUROMICRO
-
PDP.02).