Tietronix Software, Inc.

hushedsnailInternet και Εφαρμογές Web

12 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

180 εμφανίσεις



Tietronix Software, Inc.



SDA DRUPAL INTERGRATION

Software Architecture Document


Version 3.0




SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/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


SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page
3


Table of Contents

1

Introduction

5

1.1

Purpose

5

1.2

Scope

5

1.3

Definitions, Acr
onyms, and Abbreviations

5

1.4

References

5

1.5

Overview

6

2

System Overview

7

3

Design Considerations

8

3.1

Assumptions and Dependencies

11

3.2

Constraints

11

4

System Architecture

12

4.1

Overview of System Architecture

12

4.2

High Level Block Diagram:

14

5

Design Details

15

5.1

Subsyste
m


SDA View Module
-

Drupal

15

5.1.1

Data Flow Diagram

16

5.1.2

Behavior

19

5.1.3

Data Structure

22

5.1.4

De
pendencies

23

5.2

Subsystem

SDA Communication Module

23

5.2.1

Static Structure

24

5.2.2

Behavior

25

5.2.3

Components

26

5.2.4

Dependencies

27

Appendix A: Cross
-
platform communication using XMLRPC

28

Appendix B: Evaluation Criteria

29

SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page
4


Software Architecture Document


SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page
5


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, the SDA Drupal integration high l
evel
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
Drupal as a replacement for Lifera
y 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 project

3)

the whole capstone project qu
ality

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: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page
6


1.5

Overview

The remaining of the document describes the system overview which provides a general
description 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
functionality and responsi
bilities 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: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page
7


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 time 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
con
solidated 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
management framework with an emph
asis 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 design
ed 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 Drupa
l 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 this re
sponse and will display the result. (SVG files)


SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page
8


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
convert

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 live acti
on, 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 as 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 includin
g 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 architectu
re 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 multi
ple 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
operating syste
ms, running in different environments to make procedure calls over the
SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page
9


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癡⁶楲瑵 氠
浡m桩湥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 co
mmunications 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 neede
d.

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 with 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 future SDA needs to integrate with other systems, most of the work in
xml
rpc 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 other systems then almost
nothing can be reusable.

So, we weight xmlrpc h
igher than PHP/Java Bridge




SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/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 envir
onments.


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 weight 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)

P
erformance:

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: 3.0

Software Architecture Document


Date: 10/15/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 an
y 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 system. Unit testing for the functionalities of
the two modules can be performed.


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

SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



4

System Architecture

4.1

Overview of System Architecture



Figure 4.1 Overview of System Architecture

SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/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 data.

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/C
SS are
used mainly to make up the presentation layer.


2)

Communication Layer

The purpose of Communication 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
on
version 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 en
vironment for its Presentation layer. It
can also provide

other
services like groups, user management, message boards, calendars etc.







SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



4.2

High Level Block Diagram:




















Figure 4.
2 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
links. In addition, a breadcrumb is created. The complete SVG image and breadcrumb are
displayed on the fly in Drupal to users.

DB

ParentID

ChildID


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: 3.0

Software Architecture Document


Date: 10/15/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 then Java XML RPC server (5.2).


5.1

Subsystem


SDA View Module
-

Drupal

The main tasks
of the SDA View module are:

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 infor
mation 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 breadc
rumb on the fly


SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



5.1.1

Data Flow Diagram

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


Figure 5.1 Data Flow Di
agram of SDA View Drupal Module

As shown in the data flow diagram Figure 5.1, 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: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



1)

process
_http_request_session_object:

this function 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_svg_file, parse_svg

-

as
input parameters. If no, then the function will check session, if session contains th
e
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 backend 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, $version in string. The section 5.1.2.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 parameters which are values passing from
process_http_request_session_object

and the svg file naming conventio
n, 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
repres
ent 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 the input is the SVG file name and path to it while the
output is a DOMDocument object.

4)

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

5)

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


xmlrpc and retrieve the children
processes information. The function sent over to SDA backend the string parameters
as $project_name, $package_name, $process_name, and $vers
ion of the parent
(current process). It then, receives string values including $package_name,
$process_name, $version, and $state of all children processes 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 addition,
the links to children processes are also formed in this function. These links are also
appended to process
es shape of SVG. Last but not least, the function create
SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



扲ba摣牵浢r扡獥搠潮o瑨t 楮灵i 楮景i浡瑩潮⸠周T牥景feⰠ瑨攠潵瑰畴 潦o瑨t猠晵湣瑩潮o楳ia
c潭灬e瑥t䑏䵄潣畭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 object ($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: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



5.1.2

Behavior

5.1.2.1

Sequence

Diagram:



Figure 5.2: Sequence Diagram


SDA View module


Drupal

Figure 5.2 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. Please have a look at section 5.1.2.2 for
SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



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

5.1.2.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 will happen:


-

Organic Group module will be enable
d

as a requirement by this module


-

A content type called sda_project is created and make as group node

2)
When

users

create a project by create a n
ode of content type sda_project. Project Name
($project_name) is provided in the sda_project submission form. A node type sda_project
creation

means an organic group is created having the name as project_name and the
appropriate SVG file is display in Drupal with state color and link in it.

3)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 session 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 f
unction
1



process_http_request_session_object
in Figure 5.2. Detail
diagram of this function is shown in Figure 5.3 below:


Figure 5.3 Process http request/session objects

So initially, the module will check HttpRequest object to see if it contains value
s
(package_name, process_name, and version). If it is, these values are saved in session
and passed to function
3


locate_svg_file
(
Figure 5.2
)as input
s parameters

for this
SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



晵湣瑩潮
.
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.2
) as input
s parameters. Otherwise, the module will connect to
SDA backend and retrieve the initial values from SDA database using we
b service
-

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


locate_svg_file
(
Figure 5.2
) as input
s parameters

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


locate_svg_file
(
Figure 5.2
)
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 ad
dition, 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 the
input parameters for the

next function
4


parse_svg
(
Figure 5.2
).

5) 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
.

6) Depending 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.2). 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 hashtabl
e 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.2
)

as an input paramet
ers.

7) 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.2). 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
r
etrieve the children information based on the received parameters and then response to
the module all children package_name, process_name, version, and state. This response
information is sent to Function
7


process_svg

(Figure 5.2).

8) Function
7


proce
ss_svg

(Figure 5.2) accepts standard DOMDocument object (output
SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



晲潭o 晵湣瑩潮o 㔠


standardize_domdocument_object) and values (package_name,
process_name, version, state) of all children processes as input parameters. Based on the
state (inactive, active, i
n process, etc), style element 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 e
lements and links are appended 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.

9) Until this stag
e, the DOMDocument object is ready to display. The function
8


display_domdocument_object

(Figure 5.2) 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


proc
ess_svg

above. The code displays 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 gro
up.
We can define the
project 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.3

Data Structure

SDA_project table

Fields

Type

Functions

Nid

int(10)

Node id

project_name

text

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

SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



5.1.4

Dependencies

The module depends on the following modules of Drupal:

1)

Organic Group: The module locates at
http://drupal.org/project/og
. I
t enables users to
create and manage their own 'groups'. Each group can have subscribers, and
maintains a group home 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.


5.2

Subsystem

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 mechan
ism
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 act as server,
han
dle the requests sent by client.

Client will be th
e 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 parameters gather state information of that process/sub
-
process and
return
back to Drupal module.




SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



5.2.1

Static Structure

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


Figure 5.4 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
.

This servlet has following methods:

1)

init

2)

StartXMLRPCService


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

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

StartXMLRPCService
:
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)
.


There is another class called ProcessInfoService.java which actually contains calls to
SDA’s core modules. Servlet will make calls to this class when a request from client is
received.

The class ProcessInfoServic
e.java
contains following methods:

1)

GetInitialProcessDetails

2)

GetProcessDetails



SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/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 Drupal client.

Get
ProcessDetai
ls
:
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 Process State
associated with the

children of that process. These values are returned back to Drupal
client.


5.2.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 identifie
d
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
server is to create an object like instance of this server for the client to connect. When
server starts, it continuously listens on the port for client's requests.

2) The
details

needed by the Drup
al client are already identified. This server code will
have a function for each of these
details
. The function will call SDA's back
-
end code
using SDA's API and return the required values when called.

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

-

ProjectName

-

PackageName

-

P
rocess
Name

-

V
ersion


Client will receive following details:

-

PackageName

-

P
rocess
Name

-

V
ersion

-

Process states

SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



5.2.3

Components

ProcessInfoService.java

Member
variables:

-

PackageName


Data type: String


Purpose: Contains name of the package

-

P
rocess
Name


Data type: String


Purpose: Contains name of the process

-

ProjectName


Data type: String


Purpose: Contains name of the project


Methods:

-

GetInitial
ProcessDetails
:

Input parameter: Project Name (String)

Returns: Process Name, Package Name, and Version (Hashtable)

-

Get
ProcessDetails
:

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

Returns: Process Name, Package Name, Version and
Process State (Hashtable)


XMLRPCServlet.java

Member variables:

-

PortNumber


Data type: int


Purpose: Contains port number for XMLRPC service



Methods:

-

init:

Input parameter: Servlet Config object

SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



Re瑵牮猺t
癯楤

-

StartXMLRPCService
:

Input parameters:
none

Returns:
true if service has started successfully, false if there is an error.


5.2.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.SectionManager


SDA Drupal Integration


Version: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



Appendix A: Cross
-
platform communication using XMLRPC

The communication layer between SDA and Drupal is implemented using XMLRPC calls which
facilitate interaction b
etween 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 procedure 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: 3.0

Software Architecture Document


Date: 10/15/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.

Cr
iteria

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)

Yes => 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 no
t.

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
communication

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) =>
controllable using
configuration

No, not at all. It does
suppo
rt 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: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



distributed deployment

good example.

Ease of upgrade: 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 history
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 and 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: 3.0

Software Architecture Document


Date: 10/15/2010


Confidential


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

Page



need more on it …

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

These are the most typical
examples:

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

2. white
house:
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: 3.0

Software Architecture Document


Date: 10/15/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 int
egrate 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,
Ke
rberos.


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.