Tietronix Software, Inc.

Tietronix Software, Inc.



SDA DRUPAL INTERGRATION

Software Architecture Document


Version
4
.0




SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
2


Revision History

Date

Version

Description

Author

09/14/2010

1.0

First Draft of Design Document

Aditya

Macherla

Arun Mahankali

Shruti Damle

Truyen Le

Vishakha

Kadam

09/30/2010

2.0

Second Version of Design
Document



Change System Architecture
Diagram



Specify which techniques to
choose XML
-
RPC or
PHP
-
Java Bridge



Appendices (XML DTD,
XML request
-
response
format)


Aditya

Macherla

Arun Mahankali

Shruti Damle

Truyen Le

Vishakha

Kadam

10/14/2010

3.0

Third Version of Design Document



Adding technical
motivations to choose
Drupal and XMLRPC



Adding the
Appendix B for
Evaluation Criteria


Aditya

Macherla

Arun Mahankali

Shruti Damle

Truyen Le

Vishakha

Kadam

11/03/2010

4.0

Fourth Version of Design Document



Adding design detail of
myworklist module



Add the high level block
diagram for MyWorklist
Module



Restructure Section 5

Aditya

Macherla

Arun Mahankali

Shruti Damle

Truyen Le

Vishakha

Kadam


SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
3


Table of Contents

1

Introduction

6

1.1

Purpose

6

1.2

Scope

6

1.3

Definitions, Acronyms, and Abbreviations

6

1.4

References

6

1.5

Overview

7

2

System
Overview

8

3

Design Considerations

9

3.1

Assumptions and Dependencies

12

3.2

Constraints

12

4

Overview of System Architecture

13

5

Desi
gn Details

15

5.1

SDA View Module

15

5.1.1

Main Tasks of
-

SDA View Module

15

5.1.2

High Level Block Diagram

16

5.1.3

Data Flow Diagram
–

SDA View

17

5.1.4

Behavior
–

SDA View

20

5.1.5

Data Structure
–

SDA View

23

5.2

SDA Worklist Module

24

5.2.1

Main Tasks of
-

SDA Worklist Module

24

5.2.2

High Level Block Diagram

24

5.2.3

Data Flow Diagram
-

Worklist

25

5.2.4

Behavior
-

Worklist

26

5.2.5

Data Structure
–

Worklist

27

5.2.6

Dependencies

27

5.3

SDA Communication Module

28

5.3.1

Static Structure

29

5.3.2

Behavior

30

SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
4


㔮㌮5

Components

31

5.3.4

Dependencies

33

Appendix A
: Cross
-
platform communication using XMLRPC

34

Appendix B: Evaluation Criteria

35

SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
5


Software Architecture Document


SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
6


1

Introduction

1.1

Purpose

The design document provides a comprehensive architecture of the integration of SDA
and Drupal. This document is the blueprint

for the implementation phase.

The document includes a brief overview about the current SDA system and its propose
presentation layer in Drupal, options to integrate Drupal and SDA, trade
-
off between the
available options for communication between them, th
e SDA Drupal integration high level
and detail architecture diagram and conclusion.

The audiences for the document are team members, Instructor Dr. Yue and Project Mentor
Mr. Abbasi, management of Tietronix to make decision whether to go or not go with
Dru
pal as a replacement for Liferay at presentation layer.

1.2

Scope

This document is applied to the integration of SDA with Drupal. This document is
addressed to:

1)

Tietronix decision to go with Drupal for presentation layer or not.

2)

the coding phase of the projec
t

3)

the whole capstone project quality

1.3

Definitions, Acronyms, and Abbreviations

SDA: Software Development Assistant.

Drupal: An open source content management system and more than that.

XMLRPC: XML Remore Procedure Call.

Modules: A piece of code that make up

to do certain tasks in Drupal.

SVG: Scalable Vector Graphic

1.4

References

1)

Tietronix website:
www.tietronix.com

2)

Drupal community: http://drupal.org

3)

Drupal Developer: API
http://api.drupal.org

4)

XMLRPC standard:
http://www.xmlrpc.com/

5)

W3C SVG Working Group:
http://www.w3.org/Graphics/SVG/





SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
7


1.5

Overview

The remaining of the document describes the system overview which provides a general
de
scription of the Drupal and SDA and available communication mechanisms between
them. Followed by design consideration, it states the current limitations and constraints of
this project. Then system architecture

provide
s

a high
-
level overview of how the
fun
ctionality and responsibilities of the system were partitioned and then assigned to
subsystems or components.

The final section provides design details including diagrams,
behavior and mechanism, data structure, and dependencies.


SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
8


2

System Overview

As per objective, SDA is needed to integrate with Drupal.
Let us have brief overview SDA
and Drupal.


SDA is an engineering automation product that guides engineers through their project
specific standard, processes and procedures. It is a complex real ti
me process system that
provides real time graphical status. It is a collaboration tools for project’s state
-
holders
including: software engineering, project lead, management, and event observers. It
provides a Tailored tool
-

Collaborative environment. With

SDA, information or data is
consolidated in one place and then can be viewed or manipulate in a flexible way
depending the user’s roles. It is a strict
-
compliance system.


Drupal is used to build web sites. It’s a highly modular, open source web content
m
anagement framework with an emphasis on collaboration. It is extensible, standards
-
compliant, and strives for clean code and a small footprint. Drupal ships with basic core
functionality, and additional functionality is gained by enabling built
-
in or third
-
party
modules. Drupal is designed to be customized, but customization is done by overriding the
core or by adding modules, not by modifying the code in the core. Drupal’s design also
successfully separates content management from content presentation.


So

to integrate the SDA with Drupal the communication mechanisms should be
considered.

1)

XML
-
RPC Server (java), XML
-
RPC Client (PHP)

2)

PHP
-
Java Bridge

We will see the pros and cons of these mechanisms in next section.

Suppose considering XML
-
RPC Server option

1)

Drupal (XML
-
RPC Client) is going to communicate with SDA via XML
-
RPC Server.

2)

Drupal will send the request to XML
-
RPC Server and XML
-
RPC Server will
generate the response by communicating with SDA. This response is send to Drupal.

3)

Drupal will then receive t
his response and will display the result. (SVG files)


SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
9


3

Design Considerations

This project implementation targets to remove/solve the limitations of the current system
of the SDA. This design document is followed by feasibility study of the possibility of
c
onvert the presentation layer of SDA in Java to PHP using DRUPAL.


Tietronix Company may want to upgrade the system in future and this implementation is
a prototype for it. The development of our project does not target bringing the whole
SDA system in liv
e action, but only two modules with the functions and interfaces
required for the system. Considering the complexity of the modules in the SDA, we are
limited only two modules (Life Cycle and Perform Work) to come up with design in a
semester to implement.

When it requires for further development

of the complete SDA
upgrade,

it requires implementing the functionalities of the other modules and the
interfaces required for it.


Why we choose Drupal?

Based on the current limitations of Liferay in SDA as well a
s the feature requests, a list of
technical criteria is come up and used to evaluate the alternative systems among Liferay,
Drupal, and Joomla. See
Appendix B: Evaluation Criteria

for further details.

In general, Drupal does fulfill most of the criteria in
cluding java backend support,
flexible modular architecture, organization boundary support, less time and effort in
implementation and customization, easy upgrade, highly scalability, and strong
community support. Among the above, the flexible modular arch
itecture and organization
boundary support are the limitations of current Liferay. The flexible modular architecture
of Drupal allows removing/installing modules at will. This save resources and improve
performance. The organization boundary support allows

multiple organizations using the
same code base which is also save system resources.

The result of this evaluation helps us decide to choose Drupal for the migration.
Therefore, the two modules above will be implemented in Drupal.


Why we choose XMLRPC
?

The current implementation uses Java via Liferay, which supports Java and is thus natural
to integrate with the backend J2EE business layer by calling Java classes.

One of the
biggest challenges may be that Drupal is PHP based and thus its integration
with the
backend Java business layer is a tricky part.

There are two ways to achieve that: one is using web services (XMLRPC) and other is
using PHP/Java Bridge.

What is XMLRPC: It's a set of implementations that allow software running on disparate
operati
ng systems, running in different environments to make procedure calls over the
SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㄰


I湴n牮r琮t
It'猠 re浯me 灲pce摵牥 ca汬楮g 畳楮u H呔倠 a猠 瑨攠 瑲t湳灯牴n an搠 塍L a猠 瑨t
e湣潤楮g⸠塍L
-
RPC 楳i摥獩s湥搠瑯tbe a猠獩s灬攠a猠灯獳p扬攬b睨楬攠a汬潷楮o c潭灬e
摡瑡⁳瑲畣瑵
牥猠瑯⁢e⁴牡湳浩瑴e搠灲dce獳敤⁡湤n牥t畲湥搮

W桡琠楳iP䡐HJa癡 B物摧r㨠周T P䡐HJa癡 B物摧r 楳ia渠業p汥浥湴慴楯渠o映a 獴牥a浩湧,
塍L
-
扡獥搠湥瑷t牫r灲潴潣潬Ⱐ睨楣栠ca渠扥 畳u搠瑯tc潮湥c琠a 湡瑩癥 獣物灴re湧楮攬i景f
ea浰me⁐䡐ⰠHc桥浥m⁐y瑨潮Ⱐ睩瑨⁡⁊a癡
癩牴畡氠lac桩湥h

呯Tc桯潳h 扥瑷te渠瑨敳e 瑷漠潰瑩潮猠睥 ca浥m異u睩瑨w獯浥se癡汵慴l潮oc物瑥物r a湤
獴畤se搠瑨敳d⁴睯散桡湩獭猠扡獥搠潦⁴桥洮

周T⁥癡汵慴楯渠l物瑥物r are:

1)

Ease of implementation:

Since this project involves quite a bit of feasibility study,

this criterion is weighted the
most
.

Web Service XMLRPC: it's easy to implement this technique because Drupal does
support web
-
services. In the SDA (Java side), it's also easy to build xmlrpc server class to
let client in Drupal connect to. Most parts of
the communications have been tested.

PHP/Java Bridge: Till now, Drupal doesn't support PHP/Java Bridge unless we have to
start from scratch. In addition, PHP/Java Bridge can directly access the native libraries of
Java backend. But we do need it to access

to the custom classes of SDA also. For this, a
lot extra work is needed.

So because of time constraint of capstone project, we weight web service (xmlrpc) higher
than PHP/Java Bridge.


2)

Standard compliance:

In the future, if SDA needs to be integrated wit
h other system (not Drupal), then which
technique is more reusable?

Web Service XMLPRC: Together with XML, web service protocol standards provide an
industry
-
wide means to realize interoperability and platform
-
neutral communications. For
that, if in the fu
ture SDA needs to integrate with other systems, most of the work in
xmlrpc server side can be reusable.

PHP/Java Bridge: It is not an industry standard and it has lack of adherence to standard
interfaces. So in the future, if SDA needs to integrate with ot
her systems then almost
nothing can be reusable.

So, we weight xmlrpc higher than PHP/Java Bridge




SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
ㄱ


3)

Conversion of data types and objects between PHP and Java:


Web service XMLRPC: True conversion of data types and objects from Java to PHP and
vice
-
versa.
It has high levels of interoperability between separate operating environments.


PHP/Java Bridge: Java/PHP object compatibility is not provided for all data types.
Some
data types should be handled
by the programmer while converting them.

Therefore, we wei
ght xmlrpc higher than PHP/Java Bridge


4)

Ease of updates:

Web service XMLPRC: It has a larger community of users than bridge, so it should not
have problems with updates, resolving technical issues and backward compatibility.

PHP/Java Bridge: It has a small

number of users than XMLRPC so maintenance issues
might be faced.


5)

Performance:

Web service XMLPRC: It does have performance issue due to overhead but it can be
improve through optimization

PHP/Java bridge: As mentioned, on the webpage of is vendor, it is

50 times faster than
xmlprc but haven't clarified the metrics for this in terms of time.

So, we weight php/java Bridge higher than xmlrpc.


6)

Security:

XMLRPC has some sort of secure channel for communication. But, more or less, both
options have security
issues.

Thus the comparison of these two
techniques is

shown table below.










SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
ㄲ


Evaluation Criteria

Web service
(XMLRPC)

PHP/Java Bridge

Ease of implementation



Standard compliance



Conversion of data types
and objects between PHP
and Java



Ease of updates



Performance




So, we have finalized our decision to go with XMLPRC as a communication mechanism
between SDA and Drupal.

Although performance is not the most weighted criteria in this design, the performance
goal

is

to achieve

the turnaround time for any request made by the end user should be
within 1
-
3 seconds given a good internet speed connection.


3.1

Assumptions

and Dependencies

The end users look and feel may slightly vary but provides all the features which include
the two
modules with the new design implementation. The new frontend implementation
is provided using the PHP using Drupal.

3.2

Constraints


The complete system testing cannot be performed, since the design development is
provided only for two modules of the SDA syste
m. Unit testing for the functionalities of
the two modules can be performed.


As the output in the browser uses of SVG files, the end user may use Firefox, Safari or
chrome (where they come as in
-
built features) as their web browser. If the end user
wishe
s to use Internet Explorer from Microsoft they need to install plug
-
in such that it
supports SVG files.

SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
ㄳ


4

Overview of
System Architecture



Figure 4.1 Overview of System Architecture

SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
ㄴ


1)

SDA Presentation

The purpose of SDA Presentation is to provide an interface for end users to interact with
the system. The layer will include logic to present data to the users. It should not include
any business or data access logics. It may include some validation of dat
a.

This presentation layer is handled by Drupal which is an open source CMS based on
PHP. It has been emerged in the web application for a while. PHP/HTML/JS/CSS are
used mainly to make up the presentation layer.


2)

Communication Layer

The purpose of Commun
ication Layer is to provide an interface for Drupal to interact
with
SDA

server. In this layer we can use different
communication techniques. They can
be either
Web Services
-

XMLRPC, SOAP, JSON etc.
or

PHP/ Java Bridge
.

Based on the requirements, we have

evaluated and decided to implement Web Service
–

XMLRPC instead of PHP/Java Bridge. The evaluation criteria are:

-

Ease of implementation

-

Standard compliance

-

C
onversion of data types and objects

between PHP and Java

-

Ease of updates

Therefore, we will
address the Web Service
–

XMLRPC in this design document. Drupal
plays xmlrpc client role and SDA backend plays xmlrpc server role.


3)

SDA Core

SDA Core is grouping of core subsystems of SDA. They include the business layer, data
access layer, events, model
and utility classes, and interfaces to SDA dependencies. This
group provides the
major services for all clients.


4)

SDA Dependencies

SDA depends on two major systems to function: the TieFlow pr
ocess automation engine
and the Drupal

engine. The TieFlow engine provides services related to workflow
automation and the enactment of the software development process. The
Drupal

engine
provides SDA the environment for its Presentation layer. It
can also provide

other
services like groups, u
ser management, message boards, calendars etc.









SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
ㄵ


5

Design Details

This section describes in detail about the design of SDA View Drupal module and Java
XMLRPC Server of the integration system. We will concentrate first on the Drupal modules
(5.1) and th
en Java XML RPC server (5.2).


5.1

SDA View
Module

5.1.1

Main Tasks of
-

SDA View Module

1)

Input SVG file from SVG package via HTTPRequest/session or from SDA backend.

2)

Parse the SVG as a DOMDocument object

3)

Standardize the DOMDocument object to include style elements
and hashtable.

4)

Retrieve the children processes information from SDA Backend including states

5)

Create and update the style element based on state received and hashtable.

6)

Add links to processes (for subprocesses if any).

7)

Form the breadcrumb for processes/sub
-
processes.

8)

Display the DOMDocument object and breadcrumb on the fly




SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
ㄶ


5.1.2

High Level Block Diagram




















Figure
5.1

High Level Block Diagram


Based on the request from users, SDA View Drupal module locates the SVG file from SVG
package. This is

a raw SVG file with no state
-
color and links to sub
-
processes. The module,
firstly, processes the file with parameters input from SDA backend through Web Service
–

XMLRPC communication layer. It, then, generate a complete SVG image with state color and
li
nks. In addition, a breadcrumb is created. The complete SVG image and breadcrumb are
displayed on the fly in Drupal to users.



DB


Input parameters/
arguments

Output



SDA View
Drupal Module



SVG image

1

Color: fill

2

Links

3

Breadcrumb







SDA
Backend

Communications
Layer

Web services
-
XMLRPC

Input

SVG file

1.

Entity

2.

Links to
other entity




SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
ㄷ


5.1.3

Data Flow Diagram
–

SDA View

Although PHP is object
-
oriented programming language now, Drupal was built on top of
a version of P
HP that didn’t support object
-
oriented. This is inherited until today’s
Drupal. It is not really using PHP object
-
oriented version fully, but it is using the object
oriented concepts. Each entity in Drupal such as node, content type, etc. is an object.
The
refore, the following diagram is a similar to that of UML static structure of SDA
View module.


Figure 5.
2

Data Flow Diagram of SDA View Drupal Module

As shown in the data flow diagram Figure 5.
2
, we have the following functions:

1)

process_http_
request_
session_object

2)

locate_svg_file, parse_svg

3)

parse_svg

4)

standardize_domdocument_object

5)

connect_get_children_processes

6)

process_svg

7)

display_domdocument_object




Let’s have a look at each of them in more details.

SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
ㄸ


1)

process
_http_request_session_object:

this functio
n is used to check the
HttpRequest object or session to see if either of them contains values (package_name,
process_name, version). If HttpRequest object contains the values, these values will
be stored in session and passed to the next function
-
locate_s
vg_file, parse_svg

-

as
input parameters. If no, then the function will check session, if session contains the
values, these values are passed to
locate_svg_file, parse_svg
.

Finally, if the values
are not in session, then the function will connect to SDA b
ackend using web service
-

xmlrpc to retrieve the initial values, store these initial values in session, and pass it to
the next function
locate_svg_file, parse_svg
. Therefore, the input parameters of this
function are HttpRequest object and session while
the output are $package_name,
$process_name, $vers
ion in string. The section 5.1.4.2

will also describe more detail
about this function.

2)

locate_svg_file
:
The main task of this function is to form the name of svg file and the
path to it. Based on the input p
arameters which are values passing from
process_http_request_session_object

and the svg file naming convention, the
function forms the svg file name as $package_name_$process_name_$version.svg.
The path to this file is also known. Hence, the input of this
function are string
parameters $package_name, $process_name, $version while the output are also string
represent the $svg_file_name and $path_to_file.

3)

parse_svg
: this function is used to handle a simple task. It parses the SVG to a
DOMDocument object. So t
he input is the SVG file name and path to it while the
output is a DOMDocument object.

4)

standardize_domdocument_object
: the SVG packages are not always follow a
standard format. There are packages that do not have style template elements and
hashtable in S
VG file. In order to make it easier for the following processing, this
function is used to standardize the SVG files so that they always contain style
template elements and hashtable. The function requires DOMDocumet object
($domdocument) as input paramete
r and the output also a DOMDocument object but
standardized.

5)

connect_get_children_processes
: this is a straight forward function which is used to
connect to SDA backend through web service
–

xmlrpc and retrieve the children
processes information. The func
tion sent over to SDA backend the string parameters
as $project_name, $package_name, $process_name, and $version of the parent
(current process). It then, receives string values including $package_name,
$process_name, $version, and $state of all children p
rocesses from SDA.

6)

process_svg
: The output from function 4 and 5 are the input parameters for this
function. It processes the standard DOMDocument ($standard_domdocument) using
the information received from SDA of function 5 ($package_name, $process_name,
$version, $state). Depending on the $state values of sub
-
processes, the appropriate
style element is created with fill color value. Then the old style in class attribute of
svg process tags (<path> tags) is substituted by the new style elements. In additio
n,
the links to children processes are also formed in this function. These links are also
appended to processes shape of SVG. Last but not least, the function create
SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
ㄹ


扲ba摣牵浢r扡獥搠潮o瑨t 楮灵i 楮景i浡瑩潮⸠周T牥景feⰠ瑨攠潵瑰畴 潦o瑨t猠晵湣瑩潮o楳ia
c潭
灬整p 䑏䵄潣畭en琠潢橥o琠⠤(潭灬e瑥彤潭c潣畭敮琩 睩瑨wc潬潲oan搠汩湫猠a湤
瑨攠扲eadc牵浢r

7)

display_domdocument_object
: The task of this function is to display the complete
DOMDocument object and the breadcrumb on the fly. This function accept
DOMDocument ob
ject ($complete_domdocument) and breadcrumb ($breadcrumb) as
input parameters. It then used the embed tags to call a php code. This php code is
used to add the content type to the header and then display the DOMDocument object
together with the breadcrumb.



SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㈰


5.1.4

Behavior
–

SDA View

5.1.4.1

Sequence

Diagram



Figure 5.
3
: Sequence Diagram
–

SDA View module
–

Drupal

Figure 5.3

show the behavior in sequence of the SDA View Module in Drupal starting from http
request object until the SVG images are shown to users. Ple
ase
have a look at section 5.1.4
.2 for
SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㈱


瑨攠摥獣物灴楯渠楮⁤整n楬.

5.1.4.2

Behavior Description

The general idea of this module is to l
oad, process, and then display SVG

from the
packages/templates in Drupal.

1)
When the module

is completed and

enable
d, the following w
ill happen:


-

Organic Group module will be enable
d

as a requirement by this module


-

A content type called
process

is created and make as group node

2) The project is temporary created by create an organic group. So the organic group
name should be the
same as the project name created in SDA side. In addition, a package
is selected for this project or organic group.

3)
When

users

create a n
ode of content type l. Project Name ($project_name) is retrieved
from the organic group. A node type process creatio
n means a lifecycle portal is created
for this organic group having the name as project_name.

4)When users navigate through the project processes/sub
-
processes,
an

appropriate SVG

file will be loaded.
The module has to process HttpRequest object and/or se
ssion to find
the correct package_name, process_name, and version (values). These values are needed
for forming the SVG file name. The task of process HttpRequest object and/or session is
handled by function
1

–

process_http_request_session_object
in Figure

5.
3
. Detail
diagram of this function is shown in Figure 5.
4

below:


Figure 5.4

Process http request/session objects



SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㈲


S漠 楮i瑩a汬yⰠ 瑨t 浯摵me 睩汬 c桥c欠 䡴瑰He煵e獴s 潢橥o琠 瑯t 獥e 楦i 楴 c潮瑡楮猠 癡汵敳
⡰(c歡来彮_浥Ⱐp牯re獳彮慭sⰠa湤n癥牳楯温⸠I映楴 楳i

瑨敳t 癡汵敳la牥 sa癥搠楮i獥獳s潮o
a湤n灡獳敤 瑯t晵湣瑩潮o
3
–

locate_svg_file

(
Figure 5.3
)

as input
s parameters

for this
function
.
If

it’s not, then the module will check the session to see if it contains the values.
In case the session contains the values
, these values will be passed to function
3
–

locate_svg_file

(
Figure 5.3
) as input
s parameters. Otherwise, the module will connect to
SDA backend and retrieve the initial values from SDA database using web service
-

xmlrpc. These initial values are saved
in session and passed to function
3
–

locate_svg_file

(
Figure 5.3
) as input
s parameters

5) After processing of HttpRequest and/or session object, function
3
–

locate_svg_file

(
Figure 5.3
)
receives the values (package_name, process_name, version) as input
parameters. It then, forms the name of the SVG file from these values based on SVG file
naming convention. The file name starts with package_name, follow by process_name,
version, and then
the file extension .SVG. There are underscore “_” separation between
these values. So the file name is package_name_process_name_version.SVG. For
example, if the package_name is
SDANonGFE
, the process is 0, and version is 1.0, then
the file name is
SDANonGFE
_0_1.0.SVG. In addition, this function also forms the path
to the file. Therefore, the input parameters of this function is values (package_name,
process_name, version) and the output values are SVG file name and path to the file.
These will be th
e input parameters for the next function
4
–

parse_svg

(
Figure 5.3
).

6) Using the the file name and path to it, the module loads the file and parse it as a
DOMDocument object for further process later on. This is done through function
4
–

parse_svg
.

7) Dep
ending on the software used to create SVG file, the SVG file may have style
element templates (st1, st2, st3, etc) and state/color hashtable or not. We need these
elements to easily manipulate the DOMDocument object, so we need to standardize the
SVG file
to include these elements. This is done in function
5
–

standadize_document_object

(Figure 5.3
). This part of the module will check the input
parameter DOMDocument object received from function 4 above to see if it contains
style elements and hashtable or
not, if it’s not, the code will add these elements.
Therefore, the output of this function will be the standard DOMDocument object with
style element and hashtable. This object will be passed to function
7
–

process_svg

(
Figure 5.3
)

as an input parameters.

8) At this stage, the module needs to connect to SDA backend to retrieve the values of all
the children processes of the current process including package_name, process_name,
version, and state. This is handled by function
6
–

connect_get_children_process

(Figure 5.3
). The function uses the values output by function
1
–

process_http_request_session_object

and project_name as input parameters. These
parameters are sent to SDA backend using web service
-

xmlrpc. SDA backend will
retrieve the children informa
tion based on the received parameters and then response to
the module all children package_name, process_name, version, and state. This response
SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㈳


楮景i浡瑩潮⁩猠獥湴⁴漠s畮u瑩潮o
7
–

process_svg

(Figure 5.3
).

9) Function
7
–

process_svg

(Figure 5.3
) accepts
standard DOMDocument object (output
from function 5
–

standardize_domdocument_object) and values (package_name,
process_name, version, state) of all children processes as input parameters. Based on the
state (inactive, active, in process, etc), style eleme
nt templates, and hashtable, the
function creates new style elements with appropriate fill color values. In addition, the
function also creates links and breadcrumb based on current and children processes
values. The new style elements and links are append
ed in the DOMDocument object tags
for each process/sub
-
process that has value of addlinks tag attribute as “yes”. Hence, the
outputs of this function are DOMDocument object with color and links and breadcrumb.

10) Until this stage, the DOMDocument object i
s ready to display. The function
8
–

display_domdocument_object

(Figure 5.3
) is built to handle this task. The input
parameters for this function are the DOMDocument object and breadcrumb which are the
output of Function
7
–

process_svg

above. The code dis
plays the DOMDocument object
and breadcrumb on the fly. That means no SVG file is created in this case. Finally, we
have the SVG image display on project page.

Project users
: to add users to project, we

add users to organic group.
We can define the
proje
ct roles as:

-

group lead <=> project lead

-

group member <=> project member

And more roles

added using Organic Group user roles and Organic Group Users role
access.

5.1.5

Data Structure
–

SDA View

SDA

organic group

table

Fields

Type

Functions

Nid

int(10)

Node id

project_name

T
ext

A string to specify the
project name

project_user table

Fields

Type

Functions

project_id

int(10)

An integer id number to
specify the project id that
the user is belonged to

user_id

Int (10)

A integer to specify the id of
the user

Role

Text

A text field to specify the
SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㈴


牯汥映畳 爠楮⁴桩猠灲潪sct

5.2

SDA Worklist Module

5.2.1

Main Tasks of
-

SDA Worklist Module

1)

Inputs are current user, current project, and filter getting from
request object or

session,
or default.

2)

Connect to SDA backend to
retrieve an array of worklist

3)

Rendering the received worklist in a tree format
.


5.2.2

High Level Block Diagram































Figure
5.5 High Level Block Diagram

Based on the request from users, SDA Worklist module get the current user, current
projects and
DB

Input parameters/
arguments

Output


SDA Worklist
Drupal Module



Worklist

4

Tree format

5

Color states







SDA
Backend

Communications
Layer

Web services
-
XMLRPC

Input

Request

3.

current_user

4.

project_nam
e

5.

workstatus




SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㈵


睯w歳瑡瑵猠a湤n獥湤n楴 瑯 S䑁 扡c步湤n瑨牯tgh We戠Se牶楣e
–

XMLRPC communication layer.
It, then, receives the wordlist in an array format and display it in tree format to user.

5.2.3

Data Flow Diagram
-

Worklist



Figure 5.6

Data Flow Diagram of SDA Worklist module

As shown in
the data flow diagram Figure 5.6
, we have the following functions:

1)

worklist_process_request_session_object

2)

worklist_connect

3)

create_tree_object

4)

generate_tree


1)

worklist_process_request_session_object
:

this function is used to retrieve the
values of current user, current project, workstatus from either request object or
session. If not then, it will get the default value.

2)

worklist_connect
:

Send the current user, current p
r
oject, and workstaut to SDA
bac
kend to retrieve the worklist array.

3)

create_tree_object
:
based on the current username, project name, and process name,
it will create a tree object and its attributes icon, title, alt.

4)

generate_tree
: this is a recursive function used to generate the workl
ist in a tree
format based on the input parameters from
worklist_connect

and
create_tree_object
.

SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㈶


5.2.4

Behavior
-

Worklist

5.2.4.1

Sequence Diagram


Figure 5.7
: Sequence Diagram
–

SDA Worklist module

Figure 5.7

shows the behavior in sequence of the SDA Worklist Modu
le
in Drupal
starting from HttpR
equest object
until the worklist tree structure is shown to users. P
lease
have a look at section 5.2
.
4
.2 for the description in detail.


5.2.4.2

Behavior Description

The general idea of this module is to retrieve and display the workl
ist in a tree format.

1) When the module is completed and enabled, the following will happen:


-

Organic Group module will be enable as a requirement by this module


-

A content type called worklist is created and make as group node.

2) When users create a

node of this content type, it is part of organic group. The organic
group name already created will be the project name.

3) When users view this content node, the functions are run behind to render the node
content as:

-

worklist_process_request_session_o
bject
: will retrieve the current user, current
project, workstatus, and root process from request object initially. If the values are in
there, it will pass these to the next function and store them in session. If the values are not
SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㈷


楮⁲i煵q獴Ⱐs琠睩t氠捨l
c欠k桥⁳ 獳s潮⁡湤nge琠t桥獥 癡汵敳⸠I映瑨fy a牥潴⁩渠獥獳s潮Ⱐ楴⁷楬
ge琠t桥⁤e晡畬u⁶ 汵e.

-

worklist_connect
: this function used the output of the above function and send over to
SDA backend to retrieve the worklist in an multi
-
dimension array
format.

-

create_tree_object
: this function is based on the inputs like current username, project
name, and process name to generate the tree object and set its attributes (icon, title, alt).

-

generate_tree:

This recursive function is used to actually gen
erate the tree of worklist
and output to users.

5.2.5

Data Structure
–

Worklist

SDA organic group table

Fields

Type

Functions

Nid

int(10)

Node id

project_name

T
ext

A string to specify the
project name

project_user table

Fields

Type

Functions

project_id

int(10)

An integer id number to
specify the project id that
the user is belonged to

user_id

Int (10)

A integer to specify the id of
the user

Role

Text

A text field to specify the
role of user in this project


5.2.6

Dependencies

The module depends on the
following modules of Drupal:

1)

Organic Group: The module locates at
http://drupal.org/project/og
. It enables users to
create and manage their own 'groups'. Each group can have subscribers, and
maintains a group ho
me page where subscribers communicate amongst themselves.

2)

Service module: The module locates at
http://drupal.org/project/services
. It provides a
standardized solution of integrating external applications
with Drupal. Service
callbacks may be used with multiple interfaces like XMLRPC,
JSON
,
JSON
-
RPC
,
REST
,
SOAP
,
AMF
, etc. This allows a Drupal site to provide web services via
multiple interfaces while using the same callback code.

3)

All Drupal core

modules.

SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㈸


5.3

SDA Communication Module

This module will act as a communication layer between back
-
end SDA and presentation
layer of SDA which is Drupal. It will reside on top of SDA's base modules.

Communication mechanism used:

Web service
-

XMLRPC

This
module uses

Apache's XMLRPC APIs to provide a communication mechanism
between SDA code in java and Drupal side code in PHP. XMLRPC is used to make RPC
calls via XML based on request
-
reply mechanism.

The main tasks of the SDA Communication module are:

1)

To ac
t as server,
han
dle the requests sent by client.

Client will be the module on
Drupal side.

2)

Implement the functionality of a server. Make the server listen continuously on a pre
-
defined port number. This port number will be used by client to connect.

3)

Based

on client requests, call the required functions of SDA code.

4)

Get the inputs from SDA back
-
end and send them to Drupal client.

5)

The parameters required from Drupal module are Project

Name

or (Process

Name
,
Package Name
and
Version).

6)

Based on these parameter
s gather state information of that process/sub
-
process and
return back to Drupal module.




SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㈹


5.3.1

Static Structure

Following class diagram shows static structure of the module at SDA side.


Figure 5.6

Class diagram for SDA’s java module

As shown in the figure,

this java module will reside on top of SDA’s core java modules.
This module cont
ains a servlet called XMLRPCServlet
.java.

The main task of this servlet

is to start the XMLRPC service
.

Th
is servlet has following method
:

1)

init

Let’s have a look at
it

in more details.

init
: This
default
method
for servlet
initializes the servlet. It also obtains the port number
from servlet configuration defined in application’s web.xml file.

This method will start the XMLRPC service on the port number obtained in init
()
method. It will listen continuously for reques
ts from
client

(Drupal module)
.


1)

LifeCycle Module:

There is
a

class called ProcessInfoService.java which
contains calls to SDA’s code
related to LifeCycle module
. Servlet will make calls to this class when a

request from
client is received.

The class ProcessInfoService.java
contains following methods:

1)

GetInitialProcessDetails

2)

GetProcessDetails



SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㌰


Let’s have a look at each of them in more details.

GetInitialProcessDetails
:
Input parameter to this function is
Project Name sent by
Drupal client. This method will call corresponding SDA codes with this Project Name to
obtain the (Process Name, Package Name, and Version) associated with initial process
defined for that project. These values are returned back to Dru
pal client.

Get
ProcessDetails
:
Input parameters to this function are
Process
Name, Package Name,
and Version sent by Drupal client. This method will call corresponding SDA codes with
these values to obtain the Process Name, Package Name, Version and Proces
s State
associated with the children of that process. These values are returned back to Drupal
client.


2)

MyWorklist Module:

There is a class called
ProcessWorklist
.java which
contains calls to SDA’s code related to
MyWorklist
module. Servlet will make calls to this class when a request from client is
received.

The class
ProcessWorklist
.java contains following methods:

3)

GetWorklist

4)

CreateWorklistTree


Let’s have a look at each of them in more details.

Get
Worklist
:
Input paramete
r
s to this functionare

Project Name
, current user name and
filter selected by the current user

sent by Drupal client. This method will call
corresponding SDA codes with this Project Name to obtain the
worklist assigned to
current user for that
project.
The
n it will make a call to the method CreateWorklistTree()
with the worklist as input parameter. CreateWorklistTree() will return the worklist in a
tree format. This worklist tree is

returned back to Drupal client.

CreateWorklistTree
:
Input parameters to thi
s function are
Process
Name, Package
Name, and
workilist for current user for that project
. This method
will form a tree
structure of worklist items and return this tree structure.


5.3.2

Behavior

This
module

will be primarily written in java. It will import SDA
's code into it,
which is
needed to communicate with SDA's

back
-
end
. Following are some broadly identified
tasks which are
required to perform by this module
:

1)
To start the XMLRPC server,
the servlet code will create

a Web Server object and
assign a port number to it which will be
used by the client to connect. It will a
ssign a
unique handler (string value) to it. The purpose of assigning a unique handler to this
SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㌱


獥牶r爠楳i瑯tc牥a瑥ta渠潢橥o琠汩步 楮獴a湣e 潦o瑨ts 獥r
癥爠景f 瑨攠c汩e湴n瑯tc潮湥c琮tW桥n
獥牶r爠獴r牴猬⁩r⁣潮瑩湵潵獬y 獴敮猠潮⁴桥⁰潲琠景t c汩e湴n猠se煵q獴s.

㈩2周T
摥瑡楬t

湥e摥搠by 瑨攠D牵灡氠c汩e湴na牥 a汲lady 楤敮瑩晩i搮d周楳Tse牶r爠c潤o 睩汬
桡癥 a 晵fc瑩潮o景f eac栠潦o瑨敳t
摥瑡楬t
⸠周T f畮u瑩潮ow
楬氠ca汬 S䑁'猠扡ck
-
e湤nc潤o
畳楮u⁓䑁'猠䅐I⁡湤n牥t畲渠瑨u⁲ 煵楲e搠癡汵敳⁷桥渠na汬e搮

For the LifeCycle Module:

Client will call these methods using the handler defined.
Input parameters which will be provided by client will be:

-

ProjectName

-

PackageName

-

P
rocess
Name

-

V
ersion


Client will receive following details:

-

P
rocess
Name

-

Process states


For the MyWorklist Module:

Client will call server methods using the handler defined.
Input parameters which will be provided by client will be:

-

P
rojectName

-

CurrentUser

-

Filter


Client will receive following details:

-

WorklistItems in a tree format


5.3.3

Components

ProcessInfoService.java

Member variables:

-

PackageName


Data type: String


Purpose: Contains name of the package

-

P
rocess
Name


Data type: String

SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㌲


†
P畲灯獥㨠:潮瑡楮猠湡浥m⁴桥⁰ 潣e獳

-

P牯橥c瑎t浥

†
䑡瑡⁴y灥㨠:瑲楮t

†
P畲灯獥㨠:潮瑡楮猠湡浥m⁴桥⁰ 潪散t


䵥瑨潤t:

-

GetInitialProcessDetails
:

Input parameter: Project Name (String)

Returns: Process Name, Package Name, and Ver
sion (Hashtable)

-

Get
ProcessDetails
:

Input parameters:
Process
Name, Package Name, and Version (String)

Returns: Process Name and
Process State (Hashtable)




ProcessWorklist.java

Member variables:

-

ProjectName


Data type: String


Purpose: Contains project name received from Drupal client



-

CurrentUser


Data type: String


Purpose: Contains current user name received from Drupal client

-

Filter


Data type: String


Purpose: Contains filter name received from Drupal client


Met
hods:

-

GetWorklist:

Input parameter:
Current user name, project name and filter

Returns:
Hashtable of worklist items for that user for that project


SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㌳



-

CreateWorklistTree:

Input parameter: Project name, package name and worklist

Returns: Hashtable of
worklist items in a tree format


XMLRPCServlet.java

Member variables:

-

PortNumber


Data type: int


Purpose: Contains port number for XMLRPC service


Methods:

-

init:

Input parameter: Servlet Config object

Returns:
void


5.3.4

Dependencies

This module is
dependent on following (or more) codes which are part of SDA’s base
modules
:

-

com.tietronix.portal.manager.ProcessManager

-

com.tietronix.portal.manager.ProjectManager

-

com.tietronix.portal.manager.
User
Manager

-

com.tiet
ronix.portal.model.ProcessModel

-
c
om.t
ietronix.portal.Constants.State

-
com.tietr
onix.portal.model.WorkItemModel

-
com.tietronix
.portal.model.WorkItemModelList


SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㌴


Appendix A: Cross
-
platform communication using XMLRPC

The communication layer between SDA and Drupal is implemented using XMLRPC ca
lls which
facilitate interaction between two different platforms: Java based SDA and PHP based Drupal.
This project uses
Apache XML
-
RPC

APIs, which are Java impl
ementation of XML
-
RPC, a
standard

protocol that uses XML over HTTP to implement remote procedur
e calls.


http://en.wikipedia.org/wiki/XML
-
RPC

http://ws.apache.org/xmlrpc/

http://php.net/manual/en/book.xmlrpc.php

http://www.xmlrpc.com/

http://www.ibm.com/developerworks/xml/library/j
-
xmlrpc.html

http://oreilly.com/catalog/progxmlrpc/chapter/ch03.html



SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㌵


Appendix B
:
Evaluation Criteria

Based on the current system limitations and the feature requests, the following list of criteria

is
used to evaluate the three system: Liferay, Drupal, and Joomla.

Criteria

Liferay

Drupal

Joomla

Support for groups where
members of the groups are the
only one that can access the
contents. No other user is
allowed access (not even read
only access)

Ye
s => Groups,
Roles &
Permissions
available

Yes


The module organic
group at
http://drupal.org/proj
ect/og

should fill the bill

No

Support for organization
concept, where users belong to
an organization. Modules

are
shared between organizations,
but data is not.

No organization
boundary support
in Liferay

Yes => Drupal supports
multisites.

No

Support for inter module
communication both in peer to
peer and broadcast mode.

Yes Liferay does
support inter
module
com
munication

Yes =>
events/triggers/actions
management

Yes

Support for adding/removing
modules at will for certain
users (they have to be non
-
administrators)

No

Yes => can be done
through organic group
and its dependent
modules


No

Modular architecture:
ability
to remove/add modules at will.

It is modular
architecture but
can’t remove the
module at will. The
whole package is
installed.

Yes

Yes

Time to implement a module,
given that the developer knows
the target language and the
tool architecture

Depends

on
module
requirement.

Need to create .info and
.module files. Getting
start at
http://drupal.org/node/206
754

It’s easy

Complexity in setting it up and
using it

It is on J2EE
standards,
complex/easy
accordingly

Couple of weeks to get
start.

Couple of weeks

Scalability: Besides the
hardware is there a limit on
the number of users, groups,
modules etc. Does it have
support for load balancing,
Quite scalable
(proven) =>
controllab
le using
configuration

No, not at all. It does
support for load balancing
+ distributed deployment.

Http://acquia.com

is a
No limit on number
of Users, modules.
It does support load
balancing.

SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㌶


distributed deployment

good example.

Ease of upgra
de: what does it
take for going from one
version to another? Are the
API's stable enough, or do they
keep changing drastically from
version to version

Not that easy and it
seem to be a
limitation of
Liferay.

Half of a day to do the
upgrade from version to
version. Drupal does
support upgrade from
version to version. The
post here
http://drupal.org/upgr
ade

show the detail.
There are two types of
upgrade: Minor and
Major releases. If Minor
release like 6.1 to 6.x,
core and API don't
change. If Major release
like 6.x to 7.x, there are
changes in Core and API.
Procedure is given in such
case. The release histo
ry
can be found here:
http://api.drupal.org/a
pi/drupal/CHANGEL
OG.txt/6/source
.

Drupal 3.x from 2001
–

2002

Drupal 4.x from 2002
–

2007

Drupal 5.x from 20007
–

now

Drupal 6.x from 2008
–

now

Drupal 7.x is coming

So although Drupal is
developing, but it does a
very good job in support
either non
-
paid or paid
services. So in general a
version of it could be last
from 4
-
5 years.

Maximum 48 hours
(Joomla source)

Platform stability: how long

has this tool be in use? How
many users/groups/companies
use it?

Follows quite some
JSR standards,
(search for
companies using it,
some are there on
their site itself) …
It has been use for almost
10 years since 2001. It is
developing an
d getting
bigger and bigger.
1% of
all
websites

worldwide

are using Drupal (source:
It has been there
since 2005. The
first release is in
2005, the second is
in 2008, and the
third is this year
SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㌷


need more on it …

http://en.wikipedia.or
g/wiki/Drupal
).

These are the most typ
ical
examples:

1. Woldcup 2010:
http://www.sa2010.gov.za
/

2. whitehouse:
www.whitehouse.gov
,
www.data.gov.uk
,

3. US Department of
commerce:
http://www.commerc
e.gov/

4.
London gov:
http://london.gov.uk/

5. Intel
http://appdeveloper.in
tel.com/en
-
us/

6. Grammy
http://www.grammy.c
om/

7. King of Belgium
http://www.monarchi
e.be/

8. Jamaican Priminister

http://www.opm.gov.
jm/

9. Queen of Jordan
http://www.queenrani
a.jo/

10. Grammys

http://www.grammy.com/

The long list can be found
here



2010.

Community Support: how
large is the community. What
is a general turnaround time
Very good free
community support
-

It is a lar
ge community
with 365,000 pages on
drupal.org comprise:
-

A large
community with
paid services
SDA Drupal Integration


Version:
4
.0

Software Architecture Document


Date: 1
1
/
04
/2010


Confidential


呩T瑲潮楸⁓潦瑷a牥ⰠInc⸬.
㈰ㄳ

Page
㌸


for an issue? Is there paid
support service available?

is available.


In Enterprise
edition even paid
service available as
well.

news, featured sites,
featured requests, bugs,
patches, themes, modules,
forum threads,
documentation (source
http://drupal.org/com
munity
-
initia
tives
).

-

There are a lot of paid
good support services
such as acquia.com,
lullabot.com, etc. The
issue tickets normally
solved in 24 hours at
latest.

provided.

How easy is it to support a
backend java tool?

Not
difficult as it
follows JSR specs

-

It is quite easy since
Drupal provide a
standardized API to
provide web services
communicate over
XMLRPC (SOAP, REST,
AMF) protocol to a Java
application (either web
server/client/desktop
applications).

-

Support
communi
cation
s

to
Java backend

What kinds of modules/tools
are bundled in the application?

Most of the
popular web
functions are
bundle with the
tools such as:
blogs, chat,
message, contact,
social networking.
etc. Visit
http://drupal.org/pr
oject/modules

Most of

the popular web
functions are bundle with
the tools such as: blogs,
chat, message, contact,
social networking. etc.
Visit
http://drupal.org/project/
modules

It shifts with most
of the popular web
function: blogs,
chat, message,
contact.

Does it integrate
with other
authentication sources like
LDAP, Kerberos etc?

Yes => quite well

Yes it is. It integrates with
LDAP, Kerberos, etc. The
modules webserver_auth,
and LDAP does help to
handle these things.

Support other
authentication
sources like LDAP,
Kerberos.


Note:

The inputs for Joomla are taken from the Joomla community contribution.

Based on the above result, we decide to choose Drupal for this feasibility study.