Language Feasibility Report University Workflow ... - Google Code

groanaberrantInternet and Web Development

Feb 2, 2013 (4 years and 6 months ago)

413 views

Language Feasibility Report





U
U
n
n
i
i
v
v
e
e
r
r
s
s
i
i
t
t
y
y


W
W
o
o
r
r
k
k
f
f
l
l
o
o
w
w


M
M
a
a
n
n
a
a
g
g
e
e
m
m
e
e
n
n
t
t


S
S
y
y
s
s
t
t
e
e
m
m






Project Code: UWMS


FAST


NU



Internal Advisor: Mr. Waqas Zyad


External Advisor:

Submitted By:

Project Team

Rabia Akhtar

L10
-
5082

Mahwish Sonia

L10
-
5021

Bushra Maqbool

L10
-
5111

Nida Sarwar

L10
-
5106

Muhammad Aamir

L10
-
5032



Submission Date:
Dec
ember
17
, 2011




___________________

Project Manager’s Signature
University Workflow Management System


Version:
1
.0

Language Feasibility Report


Date: 1
7
/
Dec/
2011



Confidential


䙁協S


N唠U慨o牥

P慧攠
2


Revision History


Date

Version

Description

Author

1
7
-
D
ov
-
2011

1.0

This document is meant to
evaluate
feasibility of
programming language.


Team
Work


Document Information

Category

Information

Customer

FAST
-
NU

Project

University Workflow Management System

Document

Language Feasibility Report

Document Version

1
.0

Identifier

UWMS01
-
2011
-
FR

Status

Deliverable v
1
.0

Author(s)

Mahwish, Nida, Aamir, Rabia, Bushra

Approver(s)

PM

Issue Date

Dec
ember
17
, 2011

Document Location


Distribution

1.

Advisor

2.

PM

3.

Project Office












University Workflow Management System


Version:
1
.0

Language Feasibility Report


Date: 1
7
/
Dec/
2011



Confidential


䙁協S


N唠U慨o牥

P慧攠
3


Table of Contents


1.

Preface
................................
................................
................................
................................
...................

4

2
.

Introduction

................................
................................
................................
................................
...........

4

3
.

Benefits

................................
................................
................................
................................
.................

4

4
.

Justification

................................
................................
................................
................................
...........

7

5.

Comparative Analysis

................................
................................
................................
...........................

8

6
.

R
efe
rences

................................
................................
................................
................................
.............

9





University Workflow Management System


Version:
1
.0

Language Feasibility Report


Date: 1
7
/
Dec/
2011



Confidential


䙁協S


N唠U慨o牥

P慧攠
4


1.

Preface

This document was written as part of our process of (re)evaluating platforms for deployment of a large
-
scale
UWMS. A number of the perceived shortcomings of Ruby On Rails have been eliminated, alleviated, or
mitigated. For instance, we foun
d to our surprise that it was trivially simple to deploy Rails on Windows and to
automate build and testing.

2.

Introduction

The Ruby on Rails framework is an open
-
source web application development framework developed initially
by David Heinemeier Hansson at

37signals in Chicago while working on the BaseCamp productivity
application. The framework uses the popular Model
-
View
-
Controller paradigm for separation of concerns in
application development. Ruby on Rails is written in the highly
-
dynamic open
-
source ob
ject
-
oriented Ruby
programming language, developed in the early 1990’s in Japan.

3.

Benefits

There are a number of notable upsides to moving UWMS development from our Java development stack to the
Ruby on Rails framework:

Vastly reduced code footprint

We
have read our Fred Brooks and respect the fact that there has never been a “Silver Bullet”, and there is
unl楫敬y 瑯 敶敲 b攠such. oai汳 慲攠not 愠卩pv敲 Bu汬整⸠䡯wev敲I w楤敬y r数or瑥t r敳e汴s p污捥 produ捴楶楴y
楮捲敡s敳 ov敲 mod敲n g慶愠m整eodo汯g楥猠E
攮g.I g2bbI 却牵瑳I 整挮F in th攠S
J
fo汤 瑯 1M
J
fold r慮g攠Ewi瑨 many
of 瑨es攠捬慩ms 捯ming from long
J
瑩m攠g慶愠lum楮慲楥猩i mr敬emin慲y 瑥s瑳 by our q散hn楣慬ai敡d pu琠th攠捯de
r敤u捴楯n for 愠norm慬amodul攠楮 our g慶愠s瑡tk 捯nv敲瑥t 瑯 o慩汳 慴aroughly 2
M㨱. o慩汳 us敳e瑨攠dynam楣楴y
of ouby 瑯 數瑲em攠慤van瑡g攠慮d produ捥 4䝌
J
汩k攠敦f散瑳 w楴iou琠r敳er瑩tg 瑯 捯d攠g敮敲慴楯n 瑥捨n楱u敳
Ewh楣i suff敲 from inf汥l楢i汩ly post
J
gen敲慴楯nF. qh攠 repor瑥t produ捴楶楴y in捲敡ses po楮琠 慳a w敬氠 瑯
und敲r数or瑥t p
rob汥ls 楮 th攠楮dus瑲y㨠w敢 dev敬epment 慳aa who汥 汩k敬y 污gs 慰p汩捡瑩ln d敶e汯pm敮琠
produ捴楶楴y signif楣in瑬y du攠 瑯 瑨攠 r敬慴楶攠 youth of 瑨攠 p慲慤楧m Es瑡瑥汥tsI d楳瑲楢u瑥tI 瑨in
J
捬楥nt
慰p汩捡瑩lnsF㬠慮d 瑨攠g慶愠d敶敬epmen琠mod敬efor w敢 慰p汩捡l
楯ns 楳 慤d楴楯n慬ay verbos攠慮d n敥d汥獳ly
捯mp汥x. Argu慢lyI ouby der楶敳emuch of 楴i produ捴楶ity b敮ef楴s from 楴i pm慬汴慬k h敲楴ig攬 and many
would view Rails’ productivity to be bounded from above by the productivity of Smalltalk. The Rails
p慲慤楧m

h慳ainsp楲敤 oa楬i
J
慬楫攠proj散瑳 楮 n敡rly ev敲y mod敲n w敢 d敶敬epm敮t 污lgu慧攮 o慩汳 慰p敡r 瑯
rem慩a mor攠produ捴楶攠瑨an 敶敮 th攠mos琠produ捴楶攠of th敳攠o慩as
J
alkies, probably primarily due to Ruby’s
su楴慢楬楴y for sp敥dy d敶敬epm敮琠in th楳 on攠
p慲瑩tu污l doma楮 of w敢 慰p汩捡瑩ln d敶敬epmen琮t fn shor琬
o慩汳 汥l敲ag敳 ouby 瑯 br楮g w敢 慰p汩捡瑩ln d敶敬epm敮t b慣k 捬cs敲 瑯 th攠produ捴cv楴y of produ捴楶攠non
J
w敢 慰p汩捡瑩ln d敶敬epmen琠frameworks.

Zero configuration

Rails applications require
a few lines of specification to identify each database connection you will use, as
well as a line of configuration for each different type of routing you will use (typically 3
-
4 lines for an entire
application). Both of these are necessary in any environme
nt. By contrast, rather than the 20 or so lines
required in a Rails application, typical medium
-
scale Java applications require thousands of lines of XML
configuration, many of which are strongly
-
coupled across application layers.

DRY Principle

Simply pu
t, “Don’t Repeat Yourself”. Rails embrace the DRY principle and strive to maintain orthogonality
among 捯n捥rns. qh楳 r敤uc敳e捯up汩ngI wh楣h r敤u捥s m慩n瑥tan捥 捯s琠Eand in捲敡s敳em慩n瑥n慮捥 and
development productivity), and eliminates the “shotgun cod
e smell” which pervades modern Java web
d敶敬epm敮t㨠when 愠捨ang攠楳 m慤攠慴aon攠污y敲 Efor 數amp汥l 慤d楮g 愠捯汵mn 瑯 愠d慴慢慳攠瑡t汥l 捨慮ges
prop慧慴攠瑨rough 捯d攠楮 o瑨敲 污y敲s. A prob汥m wh楣h h慤 汯ng b敥n p敲捥楶敤 慳a愠shor瑣tm楮g of 瑨e
“mode
l
J
v楥w
J
controller (MVC)” architecture, shotgun code smell is exposed by Ruby on Rails to have instead
b敥n 愠prob汥l w楴h 瑨攠污ngu慧攠Eg慶愩 慮d frameworks in us攠瑯 imp汥men琠tsC
.

Rapid Development Methodology

Rails targets zero turnaround time development, where developer changes to the system are made instantly
University Workflow Management System


Version:
1
.0

Language Feasibility Report


Date: 1
7
/
Dec/
2011



Confidential


䙁協S


N唠U慨o牥

P慧攠
5


available for use and testing. Rails development eliminates the build cycle, the deploy cycle, and the container
restart cycle. Java, at its best, only

approaches zero turnaround time development, attempting to compile and
deploy in the background with certain IDEs in certain environments. Ultimately, changes to configuration files
such as those used by Struts end up causing container restarts which sap
developer time.

Single
-
stack application framework

Ruby on Rails includes all the components necessary to build complete web applications from the database
forward (even including a pure
-
Ruby web server for those who wish to develop immediately without setting
up a web server such as Apache or lighttpd), p
roviding object
-
database linkage, a Model
-
View
-
Controller
framework, unit and functional testing tools, out
-
of
-
the
-
box support for AJAX and style sheets, support for
multiple tinplating systems, multi
-
environment deployments, support for automated local an
d remote
deployments (via the included Switchtower utility), inbound and outbound email support, web services
support, etc. With Java, choices abound, and we have seen that there is actually too much choice: core
architectural components in wide usage are
being actively deprecated by their developers and well
-
considered
choices made at one point in time are revealed to be dead
-
ends 6
-
12 months later. The Java web community is
in a state of high flux, and the apparent direction that the community at large is

taking appears to not bode well
for the type of architecture we had envisioned
.

AJAX UI Support

The most viable technology for streamlining user interaction is AJAX (“Asynchronous JavaScript and XML”).
Ruby on Rails’ support for AJAX is powerful, flexib
le, terse, and well
-
integrated into the framework. The
development of the Prototype AJAX library (a popular AJAX and JavaScript effects library) has been driven
by Rails development feedback. AJAX development in Java has proven to be extremely difficult.

IDE Automation not Required

It is well
-
documented that much productivity in Java comes from the widespread use of tools to automate code
writing and change. The “shotgun code smell” which permeates the Java web stacks is reigned in with editors
such as Ec
lipse which support XDoclet annotations. The verbosity of Java Bean getter and setter methods
(code which must be written to read and write every value accessible in a Java Bean object) is mitigated by
editors which support hotkeys or other automation meth
ods for creating those methods. Other tools (e.g.
Middlegen) use known data to write code or verbose XML configuration files. Java is widely defended as
“productive”, so long as the proper tools are in use to mitigate the impact of voluminous code and
conf
iguration data. The learning curve, however, for the use of these tools is high. Indeed, even the process of
choosing which tools to use comes with a high research burden and high risk of abandonment (see above,
under “Single
-
stack application framework”).

It is this author’s belief that much of the research into
annotations and Aspect
-
oriented programming is geared toward making the widely adopted Java language
productive for developers and maintainers. In contrast, Ruby and Rails are terse and dynamic, su
pport AOP
-
style separation of concerns (Rails also has AOP tools available, though not widely used), minimize
configuration, and consequently are productive outside the use of code/config generators and IDE
environments designed to minimize necessary (to J
ava) redundant typing. We have found Ruby to be
extremely flexible in this regard, allowing us to quickly alter functionality without touching framework code.

Dependency Injection (IoC)

Dependency Injection (or Inversion of Control) is a pattern widely u
sed in Java development to help
streamline the process of connecting and/or replacing components and services inside an application. Java’s
type system, as well as the abundance of components available (and, some would argue, the high degree of
volatility
in the availability of usable components) makes Dependency Injection a necessary technique.
Dependency Injection is also useful in testing under Java’s typing system, where replacing components with
stubs or mock objects can be cumbersome. There exist smal
l Ruby libraries for implementing Dependency
Injection, but Ruby’s dynamic nature and open typing makes Dependency Injection much less of a necessity
than in the Java world
.

Database Agnosticism

Rails support a wide array of databases, including all the common production database platforms.

Open
-
source

:

Both Ruby and Rails are freely downloadable and redistributable open source products. While parts of our
University Workflow Management System


Version:
1
.0

Language Feasibility Report


Date: 1
7
/
Dec/
2011



Confidential


䙁協S


N唠U慨o牥

P慧攠
6


Java stack are open source (under lic
enses of varying flexibility), much of Java is encumbered by restricted
licenses, and despite Sun’s PR push to cast Java tools as “open source” software. A true open source language
and framework provides an ultimate escape from both vendor lock
-
in and unl
atched software defects: simply
read the code and change things yourself.

Integrated unit and functional testing support

Our iterative development process for relies heavily on the ability to build comprehensive automated tests.
Testing in Rails is simpl
e, well
-
documented, terse, and integrated into the Rails framework. Rails build the
necessary scaffolding for unit and functional tests automatically, and tracks test/code ratios automatically.
Rails include native support for mock object testing and datab
ase fixtures, streamlining out
-
of
-
container
testing. Since Rails doesn’t require a heavy object container, the headaches of Java
-
style “in
-
container” testing
are alleviated

allowing for faster http
-
level and in
-
browser testing. In contrast to Java, with it
s numerous
heavy testing frameworks, where Java requires the absorption of entire 300
-
page texts for each layer of the
testing hierarchy, everything one needs to know about Rails testing, which covers the same scope, can be
learned from a couple of short c
hapters. The availability of ready testing has greatly eased our development
and caught a large number of early defects which would have been difficult to otherwise exorcise.

Production vs. Testing vs. Support

Rails enforce the concept of deployment
environments. Rails comes stock with three environments:
production, where caching and performance enhancements are enabled, code is assumed not to be under
development, and developer information is not passed back to the end user; testing, where a volatil
e database
is made available for the purpose of running test suites; and development, where performance enhancements
are disabled, a development database is in use, developer tools and feedback are in force, and the emphasis is
on agile development methodo
logies expecting zero turnaround time development. Selection of an
environment is enabled through one master switch. Rails allows for any number of additional environments to
be created, and setting up an environment is trivial (a new file with a few lines

of configuration information).
In contrast, while Java allows for distinguishing environments, tool support is lacking, and any configuration
switch must necessarily touch numerous components in an application.

MVC separation of concerns

Rails integrate

the Model
-
View
-
Controller architecture in a lightweight manner. Separation of business logic
from database logic and from user interface is handled cleanly, decreasing coupling and providing the benefits
of orthogonality. The Java MVC architecture of choi
ce, Struts

which is being deprecated by its author in
favor of non
-
MVC “component” tools which are the current rage in the Java world

places heavy overhead on
the developer creating the controller and action building blocks of the front
-
end, while the stru
ts
-
config.xml
XML configuration file is verbose, unwieldy, untyped, and requires container reloads on changes, thwarting
attempts at “zero turnaround time” development.

Share
-

nothing horizontal scalability

While Rails benefits from increasing the horsep
ower of servers on which it runs, Rails is designed from a
“share
-
nothing” mindset. Each Rails thread is self
-
contained horizontally (i.e., it shares nothing with other
Rails threads), and vertically (i.e., it shares nothing with the web server or the data
base server). When
deploying Rails for scalability it is typical to use lightweight high
-
speed server tools such as lighttpd and Fast
CGI to allow for cheap and easy horizontal scalability. Add more cheap commodity PC hardware and the
application handles m
ore load. Add memcached (essentially, a distributed memory cache on the local network)
to some of those cheap systems and even the database tier is scaled cheaply and horizontally. Java also offers
horizontal scalability

the baseline deployment being highe
r (Java + application server tends to have a heavy
footprint), the configuration burden is typically higher than that for scaling Rails, and it is often harder to set
up a Java framework in a “share nothing” manner.

Memcached support

Rails provides integ
rated support for memcached, written by the developers at LiveJournal to allow them to
scale their Perl+MySQL application to handle traffic loads on their 2.5M+ user base.

Utilities

The Rails breakpointer allows developers to set a breakpoint in web appl
ication code, which is nothing
revolutionary. What is impressive is that once this breakpoint is hit by the web application, the developer has a
University Workflow Management System


Version:
1
.0

Language Feasibility Report


Date: 1
7
/
Dec/
2011



Confidential


䙁協S


N唠U慨o牥

P慧攠
7


console available at that line of code where he can inspect and modify any and all Ruby constructs (including
c
lasses, methods, etc.), and then can send the application running from that point (tellingly, the breakpoint
library’s source code is shorter than a typical Java Hibernate XML mapping file for a single database table).
Additionally, there are tools for run
ning short automation scripts at the model level, and even an interactive
console for working with Rails models and model constructs. Java’s verbosity, typing, and compiled nature
makes development of a comparable tool not only complex (if not impossible),

but would make its use
cumbersome.

Language Stability

Ruby as a language is stable, with the language developers historically working hard to maintain backwards
compatibility. Java, the language, has undergone significant changes with each point
-
release
. The newest
standard, Java 1.5 (or “Java5”) introduces annotations, generics, and other constructs which are significant
language changes reportedly geared towards addressing shortcomings in the Java language. It is also worth
noting that Ruby is of compa
rable age to Java (Ruby is about 2 years older).


4.

Justification

UWMS team is solely working on its first project that can have risks and problems that have not been identified
up till now. Being entrepreneurs, UWMS team wants to be on the safer side while adopting the development
tool which requires lesser training tim
e and fast development for production of productive software.
Comparatively, it seems that for ROR, the time to market, Costs and Long term scalability is more reliable as
compared to Java.


Table 01: Java vs Ror

5.

Comparative Analysis:


Benefits

Java

RoR

Library Support

Yes

Yes

Two Phase Commit

Yes

No

Ease of integration with back end

Yes

Yes

Developer productivity and learning curve for
new developers

Time taken

Quicker

Manageability of a complex code base

Difficult

Easy

Scalability

Best

Good

Stability

Best

Best

University Workflow Management System


Version:
1
.0

Language Feasibility Report


Date: 1
7
/
Dec/
2011



Confidential


䙁協S


N唠U慨o牥

P慧攠
8


Reliability

Best

Best

Maintainability

Good

Best

Testability and robustness

Easy

Easier

Long
-
term support

Yes

Yes

Tool chain support

Yes

Yes

Table 01:
Comparative Analysis


Both of the languages have proven their need therefore being used in many of the commercial projects.
Both languages have almost the same ages. Both languages are open source and free of cost. But there are
some differences as well like; Java is well know
n for its scalability and performance. Being more specific
J2EE environment has no competitor in performance and heavy work load management. But as our project
is not an enterprise level application so for that matter, RoR has also proved to be more usefu
l.

The only and major most threat for using Ruby as a fundamental language would be a Linux server setup.
In our communication to our Lab Administrators we have found that university is already using Linux as a
server setup which therefore remedify this t
hreat.


For maintenance, Ruby can be configured externally through its configuration files. These configurations
can be dynamically loaded which results in dynamic behavior of the application. Whereas in Java, you
must re
-
compile the code, re
-
deploy the e
xecutable.


Also for one of the main aspects Time, we will be given almost 4 months to develop, test and deploy this
application. In this short span of time it would be extremely difficult to achieve this target. Java has a long
learning graph whereas RoR

has shorter learning graph. Which mean, RoR can be quickly learned.


So taking all above facts and putting deep analysis, we have concluded that RoR would be our final
language to be used in development of this project.


6.

References



http://martin.kleppmann.com/2008/05/11/ruby
-
on
-
rails
-
vs
-
java
-
enterprise.html



http://www.pardontheinformation.com/2008/09/java
-
vs
-
ruby
-
on
-
rails
-
it
-
is
-
dead
-
heat.html



http://rewrite.rickbradley.com/pages/moving_to_rails/



A Comparative Study of Maintainability
of Web Applications on J2EE,.NET and Ruby
onRailsLok Fang Fang Stella, Stan Jarzabek and BimleshWadhwa*National University of
Singapore