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
ea浰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.
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο