Tietronix Software, Inc.
SDA DRUPAL INTERGRATION
Software Architecture Document
Version 4.0
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
Revision History
Date
09/14/2010
Version
1.0
Description
First Draft of Design Document
Author
Aditya Macherla
Arun Mahankali
Shruti Damle
Truyen Le
Vishakha Kadam
09/30/2010
2.0
Second Version of Design
Document



10/14/2010
3.0
Third Version of Design Document


11/03/2010
4.0
Adding technical
motivations to choose
Drupal and XMLRPC
Adding the Appendix B for
Evaluation Criteria
Arun Mahankali
Shruti Damle
Truyen Le
Vishakha Kadam
Aditya Macherla
Arun Mahankali
Shruti Damle
Truyen Le
Vishakha Kadam
Fourth Version of Design Document Aditya Macherla



Confidential
Change System Architecture
Diagram
Specify which techniques to
choose XML-RPC or PHPJava Bridge
Appendices (XML DTD,
XML request-response
format)
Aditya Macherla
Adding design detail of
myworklist module
Arun Mahankali
Add the high level block
diagram for MyWorklist
Module
Truyen Le
Shruti Damle
Vishakha Kadam
Restructure Section 5
Tietronix Software, Inc.,
2016
Page 2
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
Table of Contents
1
Introduction
1.1 Purpose
6
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
3.1 Assumptions and Dependencies
9
12
3.2
12
Constraints
4
Overview of System Architecture
13
5
Design Details
5.1 SDA View Module
15
15
5.2
5.3
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
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
SDA Communication Module
28
5.3.1 Static Structure
29
5.3.2 Behavior
30
Confidential
Tietronix Software, Inc.,
2016
Page 3
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
5.3.3 Components
31
5.3.4 Dependencies
33
Appendix A: Cross-platform communication using XMLRPC
34
Appendix B: Evaluation Criteria
35
Confidential
Tietronix Software, Inc.,
2016
Page 4
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
Software Architecture Document
Confidential
Tietronix Software, Inc.,
2016
Page 5
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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 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
Drupal 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 project
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/
Confidential
Tietronix Software, Inc.,
2016
Page 6
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
1.5
4.0
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 provides a high-level overview of how the
functionality 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.
Confidential
Tietronix Software, Inc.,
2016
Page 7
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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
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
management framework with an emphasis on collaboration. It is extensible, standardscompliant, 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 this response and will display the result. (SVG files)
Confidential
Tietronix Software, Inc.,
2016
Page 8
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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 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 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 including 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 architecture 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
operating systems, running in different environments to make procedure calls over the
Confidential
Tietronix Software, Inc.,
2016
Page 9
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
Internet. It's remote procedure calling using HTTP as the transport and XML as the
encoding. XML-RPC is designed to be as simple as possible, while allowing complex
data structures to be transmitted processed and returned.
What is PHP/Java Bridge: The PHP/Java Bridge is an implementation of a streaming,
XML-based network protocol, which can be used to connect a native script engine, for
example PHP, Scheme or Python, with a Java virtual machine.
To choose between these two options we came up with some evaluation criteria and
studied these two mechanisms based of them.
The evaluation criteria 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 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
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 other systems then almost
nothing can be reusable.
So, we weight xmlrpc higher than PHP/Java Bridge
Confidential
Tietronix Software, Inc.,
2016
Page 10
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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 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) 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.
Confidential
Tietronix Software, Inc.,
2016
Page 11
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
Evaluation Criteria
Web service
(XMLRPC)
4.0
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 system. 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
wishes to use Internet Explorer from Microsoft they need to install plug-in such that it
supports SVG files.
Confidential
Tietronix Software, Inc.,
2016
Page 12
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
4 Overview of System Architecture
Figure 4.1 Overview of System Architecture
Confidential
Tietronix Software, Inc.,
2016
Page 13
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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/CSS 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
- Conversion 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 process 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, user management, message boards, calendars etc.
Confidential
Tietronix Software, Inc.,
2016
Page 14
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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
SDA View Module
5.1.1
1)
2)
3)
4)
5)
6)
7)
8)
Main Tasks of - SDA View Module
Input SVG file from SVG package via HTTPRequest/session or from SDA backend.
Parse the SVG as a DOMDocument object
Standardize the DOMDocument object to include style elements and hashtable.
Retrieve the children processes information from SDA Backend including states
Create and update the style element based on state received and hashtable.
Add links to processes (for subprocesses if any).
Form the breadcrumb for processes/sub-processes.
Display the DOMDocument object and breadcrumb on the fly
Confidential
Tietronix Software, Inc.,
2016
Page 15
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
5.1.2 High Level Block Diagram
SVG file
1. Entity
2. Links to
other entity
Output
Input
SDA View
Drupal Module
SVG image
1
2
3
Color: fill
Links
Breadcrumb
Input parameters/
arguments
Communications
Layer
SDA
Backend
Web servicesXMLRPC
DB
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
links. In addition, a breadcrumb is created. The complete SVG image and breadcrumb are
displayed on the fly in Drupal to users.
Confidential
Tietronix Software, Inc.,
2016
Page 16
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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 PHP 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.
Therefore, 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)
2)
3)
4)
5)
6)
7)
process_http_request_session_object
locate_svg_file, parse_svg
parse_svg
standardize_domdocument_object
connect_get_children_processes
process_svg
display_domdocument_object
Let’s have a look at each of them in more details.
Confidential
Tietronix Software, Inc.,
2016
Page 17
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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 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 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.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 parameters 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 the 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 SVG 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 parameter 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 function 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 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 processes shape of SVG. Last but not least, the function create
Confidential
Tietronix Software, Inc.,
2016
Page 18
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
breadcrumb based on the input information. Therefore, the output of this function is a
complete DOMDocument object ($complete_domcocument) with color and links and
the breadcrumb.
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.
Confidential
Tietronix Software, Inc.,
2016
Page 19
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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. Please have a look at section 5.1.4.2 for
Confidential
Tietronix Software, Inc.,
2016
Page 20
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
the description in detail.
5.1.4.2 Behavior Description
The general idea of this module is to load, process, and then display SVG from the
packages/templates in Drupal.
1) When the module is completed and enabled, the following will happen:
- Organic Group module will be enabled 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 node of content type l. Project Name ($project_name) is retrieved
from the organic group. A node type process creation 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 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 function 1 – process_http_request_session_objectin Figure 5.3. Detail
diagram of this function is shown in Figure 5.4 below:
Figure 5.4 Process http request/session objects
Confidential
Tietronix Software, Inc.,
2016
Page 21
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
So initially, the module will check HttpRequest object to see if it contains values
(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.3) as inputs 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 inputs 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 inputs 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 the 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) 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.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 information based on the received parameters and then response to
the module all children package_name, process_name, version, and state. This response
Confidential
Tietronix Software, Inc.,
2016
Page 22
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
information is sent to Function 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 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 elements 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.
10) Until this stage, the DOMDocument object is 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 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 group. 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.5 Data Structure – SDA View
SDA organic group table
Fields
Type
Functions
Nid
int(10)
Node id
project_name
Text
A string to specify the
project name
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
project_user table
Confidential
Tietronix Software, Inc.,
2016
Page 23
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
role of user in this project
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
Request
3. current_user
4. project_nam
e
5. workstatus
Input
SDA Worklist
Drupal Module
Output
Worklist
4
5
Tree format
Color states
Input parameters/
arguments
Communications
Layer
SDA
Backend
Web servicesXMLRPC
DB
Figure 5.5 High Level Block Diagram
Based on the request from users, SDA Worklist module get the current user, current projects and
Confidential
Tietronix Software, Inc.,
2016
Page 24
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
workstatus and send it to SDA backend through Web Service – 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)
2)
3)
4)
worklist_process_request_session_object
worklist_connect
create_tree_object
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 project, and workstaut to SDA
backend 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 worklist in a tree
format based on the input parameters from worklist_connect and
create_tree_object.
Confidential
Tietronix Software, Inc.,
2016
Page 25
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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 Module in Drupal
starting from HttpRequest object until the worklist tree structure is shown to users. Please
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 worklist 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_object: 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
Confidential
Tietronix Software, Inc.,
2016
Page 26
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
in request, it will check the session and get these values. If they are not in session, it will
get the default value.
- 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 generate 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
Text
A string to specify the
project name
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
project_user table
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 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.
Confidential
Tietronix Software, Inc.,
2016
Page 27
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
5.3
4.0
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 act as server, handle 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 predefined 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.
Confidential
Tietronix Software, Inc.,
2016
Page 28
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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 contains a servlet called XMLRPCServlet.java. The main task of this servlet
is to start the XMLRPC service.
This 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 requests 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
Confidential
Tietronix Software, Inc.,
2016
Page 29
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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.
GetProcessDetails: 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.
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.
GetWorklist: Input parameters 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. Then 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 this 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 assign a
unique handler (string value) to it. The purpose of assigning a unique handler to this
Confidential
Tietronix Software, Inc.,
2016
Page 30
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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 Drupal 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.
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
- ProcessName
- Version
Client will receive following details:
- ProcessName
- 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:
- ProjectName
- 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
- ProcessName
Data type: String
Confidential
Tietronix Software, Inc.,
2016
Page 31
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
Purpose: Contains name of the process
- ProjectName
Data type: String
Purpose: Contains name of the project
Methods:
- GetInitialProcessDetails:
Input parameter: Project Name (String)
Returns: Process Name, Package Name, and Version (Hashtable)
- GetProcessDetails:
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
Methods:
- GetWorklist:
Input parameter: Current user name, project name and filter
Returns: Hashtable of worklist items for that user for that project
Confidential
Tietronix Software, Inc.,
2016
Page 32
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
- 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.UserManager
- com.tietronix.portal.model.ProcessModel
-com.tietronix.portal.Constants.State
-com.tietronix.portal.model.WorkItemModel
-com.tietronix.portal.model.WorkItemModelList
Confidential
Tietronix Software, Inc.,
2016
Page 33
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
Appendix A: Cross-platform communication using XMLRPC
The communication layer between SDA and Drupal is implemented using XMLRPC calls which
facilitate interaction between two different platforms: Java based SDA and PHP based Drupal.
This project uses Apache XML-RPC APIs, which are Java implementation 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
Confidential
Tietronix Software, Inc.,
2016
Page 34
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
4.0
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)
Yes => Groups,
Roles &
Permissions
available
Yes
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
communication
Yes =>
events/triggers/actions
management
Yes
Support for adding/removing
modules at will for certain
users (they have to be nonadministrators)
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
support for load balancing
+ distributed deployment.
No limit on number
of Users, modules.
It does support load
balancing.
Confidential
The module organic
group at
http://drupal.org/proj
ect/og should fill the bill
Http://acquia.com is a
Tietronix Software, Inc.,
2016
Page 35
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
good example.
distributed deployment
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
4.0
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
Maximum 48 hours
(Joomla source)
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.
Platform stability: how long
has this tool be in use? How
many users/groups/companies
use it?
Confidential
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:
Tietronix Software, Inc.,
2016
It has been there
since 2005. The
first release is in
2005, the second is
in 2008, and the
third is this year
Page 36
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
need more on it …
http://en.wikipedia.or
g/wiki/Drupal).
4.0
2010.
These are the most typical
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
Community Support: how
large is the community. What
is a general turnaround time
Confidential
Very good free
community support
- It is a large community
with 365,000 pages on
drupal.org comprise:
Tietronix Software, Inc.,
2016
- A large
community with
paid services
Page 37
SDA Drupal Integration
Version:
Software Architecture Document
Date: 11/04/2010
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
4.0
provided.
http://drupal.org/com
munity-initiatives).
- 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.
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
communications 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.
Confidential
Tietronix Software, Inc.,
2016
Page 38