chaplin_white_paper - CGI Treasury Services

knifedamagingInternet and Web Development

Feb 2, 2013 (5 years and 5 months ago)


Zerobase Chaplin

Architecture White Paper

1. Hello

This is Zerobase’s Chaplin White Paper. It’s goal is to tell you about Chaplin, what it is,
what it does, and how it does it. Learn with pleasure, knowledge is power.

2. Goals

After acknowledging t
he limits of their current software technology, Zerobase’s R&D
software engineers had to find ways to continue evolving their FX system. Customers
demanded new features that were becoming more and more difficult to implement, like a
lightweight Internet cl
ient and standard object server integration.

So, work on a new generation architecture began. First known as the “Mass Deployment”
project, the result of this effort is now known as “Chaplin”. It is a set of complementary
software subsystems geared toward

ease of use, performance and interoperability for end
users, support personnel and administrators.

Using proven software technologies as a foundation (such as web servers and Java),
Zerobase is able to better focus its energies on delivering quality bus
iness solutions.
based, modular software has the advantage of aging well as it takes advantage
of newer implementation and extensions of the standards it is built on.

It was also of primary importance to the design team to make sure that Chaplin

elegantly conceived, cleanly coded, and well
documented, since it is be the basis of
future software developpement at Zerobase for the coming years. We think we have
succeeded in meeting our goals, and think you will be pleased by the results too.

3.1 Technological platforms

Chaplin is a multi
tier application based on Sun’s Java 2 Enterprise toolkit. The
portability, robustness and scalabilty provided by this framework goes along with
Zerobase’s architecture
neutral philosophy. It al
so enables developpers to take advantage
of best
breed developpment and server tools from both commercial and public

The first layer of the system is made up of two web
based client programs : one using
classic dynamic HTML, one using Macro
media Flash. Common features of these
interfaces are centralized in a “display rules server”, generating HTML pages and XML
messages from Java Server Pages (JSP). This centralization creates less redundancy and
allows for future front
ends to plugged in mo
re easily. As a matter of fact, the
extensibility of this platform has been proven by the recent addition of a third client
based on Zerobase’s own lightweight Java Applet technology.

The “display rules server” is the heart of Chaplin. It is based on Apac
he’s Jakarta
web application framework, and currently tested using Apache’s Tomcat 4.0. Its Java
nature enables it to run on any J2EE 1.2 compliant application server such as IBM
WebSphere and BEA WebLogic.

All Java development is made with Borland

JBuilder 4.0 Enterprise, which features are
matched to other technologies used in the project.

3.2 Modularity

Chaplin is to replace currently existing Zerobase programs gradually, and so it must
integrate well with legacy systems such as OCharlie,

for the two will still co
exist for
some time, often on the same site, complementing one another. Chaplin development
starts at the client and progressively invades server territory, and it is expected that
deployment will follow the same path.

For that

incremental rollout to be as smooth as possible, the system has been split into
many modules, relying on each other through well
defined interfaces. These are split in
to categories : core modules and bridge modules. Core modules are an integral part of
haplin, and are assumed to be permanent parts of the system. Bridge modules are
interfaces to the outside world, acting as traducers between external systems and
Chaplin. Some of the bridge modules will be used to connect to legacy software, and over

those will be transparently replaced by core modules as Chaplin moves in to replace
parts of the old infrastructure.

3.3 Overview

The architecture of Chalpin is that of a standard three
tiered system, to the exception that
provisions have been made fo
r multiple client technologies, the optional bypass of the
object server (for small sites) and the retrofit of Zerobase’s Legacy FX Server :

In-prcess method call
(Process List &
Business Valves)
Chaplin Web Application
Engine / Display Rules
native or ODBC connection
zbfx protocol
FX Database
Legacy FX Server
(phasing out)
in-process method call
Bridge (optional)
Dynamic HTML client
Flash client
Applet Client

An exploded view of these components is given in their respective design sections.
4. Design Notes

4.1 Display Rules Server

The next generation FX clients had to perform well through slow internet connections
and does not require to be setup on the user’s computer prior to use. In other words, it
would have to be what is known as a “thi
n” client. Web applications using dynamically
generated HTML pages are obviously one of the ways to achieve such a goal.

But HTML has its shortcomings : limited display abilities, limited user interactivity,
tiresome maintenance. One answer to these weak
nesses is Macromedia Flash which has,
over the last two years, been gaining acceptance as a standard, capable way of creating
interesting and functional user interfaces.

Chaplin’s design team decided to allow for multiple front
end technologies to be used

parralel, . The challenge was to limit technology
specific coding of these interfaces only
to the graphics level, and have the “display rules” centralized in one place to minimize
redundancy. Assuming that all clients have the same interface features,
rules such as
“User Z can not click button B until he entered valid information in field A” can be coded
only once and be interpreted differently by each client.

The original plan was to have a specialized “rules server”. As the functionnality of the

clients was to replicate the same features already found in Zerobase’s previous
generation “Webtrader” applet, the user interface elements and rules were rapidly
identified and a list of possible interaction scenarios was built. A dictionnary of possible
request and associated response messages was derived from this.

These messages are encoded in XML, for its portability and its structured data
representation. Messages are transferred back and forth over HTTP, a well
protocol for which many robust s
ervers already exist, enabling Zerobase to skip
development of yet another proprietary server and instead focus on business logic. The
engine for accepting requests is implemented as a two Java servlets (one for HTML, one
for XML). Finally, response messag
es are forged out of Java Server Pages (JSP)

url-encoded POST
ActionForm bean
Html generator JSP
XML generator JSP
writes, exposed
as a std bean
reads, exposed
as a std bean
Flash 5.0
EJB Server

The end result is surprisingly similar to a standard web application, to the exception that
clients are to converse by sending and receiving XML messages to the web serv
er rather
than sending URL encoded form data and receiving HTML documents. The similarity
between the two models eventually lead to the architectural merging of the HTML client
and the rules server, with the separation being made at the programming level.
Since both
servers now reside within the same Java Virtual Machine, this arrangement provides a
substantial performance gain for the HTML client without sacrificing the flexibility of the
original design.

4.2 Web application framework

As mentionned in t
he architecture section, all of Chaplin’s HTML content is generated
fly from JSP templates. The use of scripted templates (such as ASP, JSP or PHP)
has become standard practice when constructing web applications. When used properly,
they provide se
paration between business and display logic, enabling programmers to
split work efficiently and build high quality code.

The downside is that unhindered proliferation of scripted templates can fast lead to a
mess of pages, chaotically linking to one anot
her, directly manipulating remote data
sources, implementing business rules in non
obvious places, and making maintenance
much harder. To prevent this, their use has to be constrained by some form of framework.
The facilities this framework has to provide
are as diverse as they are numerous :

Security : determine which pages are accessible by who

Navigation : forward request data from one page or action to another

Sesssion Management : keep session data between each request

Error Handling : gracefully repo
rt application and user errors

Application Configuration : manage settings of the application

Management : allow administrators to control the application

Research for a good third
party framework rapidly converged towards Apache’s open
source libraries.
Apache’s Jakarta project has many useful Java webapp related
subprojects, two of which were more closely evaluated : Turbine and Struts.

Although Turbine seemed like a more complete and mature project it showed to have a
steep learning curve, no support
for J2EE features and a generally more closed, self
reliant design. On the other hand, Struts, although smaller in scope, demonstrated to be
less invasive, more customizable and better documented. Although still in beta version,
Struts was already a very u
sable toolkit and frequent releases convinced Chaplin’s design
team that Struts would be maturing rapidly enough to be ready for prime
time before
Chaplin itself saw the light of day.

The merging of the HTML client and display rules server (see end of sec
tion 4.2.1)
required an extension of Struts, which did not have provisions for receiving XML
encoded form data. The Zerobase
developped extension library, called Zbotz, stands on
top of an unmodified Struts, inheriting functionnality from base Struts class
es and
providing a level of indirection for routing both XML and HTML messages through the
same display rules.

4.4 Flash Client

Flash technology has become so popular since the release of version 4.0, that it has
become one of the web’s standards, endor
sed by the W3C (who are also responsible of
the HTML standards). A Flash plug
in is now bundled in all recent Web browsers
distributions, and many media software companies are now building SWF file format
converters and generators in their toolkits. Flash
is one of the most promising web
technologies for the coming years, not because of the hype surrounding it, but simply
because it is one of the most used as of now.

Some of the features that made Flash successful are its relative simplicity and its use of

based graphics. Combined, these two features enable artists to create impressive
animation sequences for a rather small file size. Flash is also multiplatform (not unlike
Java), running on Netscape, Internet Explorer, Windows, Macintosh, Linux and
other OS and browsers.

Apart from simple games and interactive promotional web sites, not many applications
have been found up to here for Flash
built software. One of the principal reasons for this
is that a capable scripting language only appeared
in the newer version (5.0). Building a
fledged business client out of it was a novel approach, and so the associated risk
factor was rather high, whatever the client features might be. The Flash version had to be
very tempting indeed to be a goal wort
h pursuing, and the design team thought of it as
nothing situation. Chaplin turns out to be one of the few applications which pushes
the bounds of the Flash environment with its window
based GUI and pervasive use of

front-side application movie
approx : 240-260kb
application background and
area size
approx. 25kb preloaded
chaplin flash communication
Chaplin application server
"screen name".FLA
screen graphic and
script, gui items
coordinates and
approx. 2-12kb
loaded dynamically on
gui items library, windows, engine script and
communications functions.
approx. 220kb preloaded
Window container and
GUI items
Engine and Communication

The use of Flash has an interesting side
effect for Zerobase’s customers : the design of
the client makes it easy to change the look
feel. The interface engine and graphics
being cleanly separated makes it easy for a bank employee to update images

to suit
corporate standards, without requiring knowledge of the client’s inner working or Flash
programming. Buttons and edit boxes can also be moved around, for more design

Special attention has been taken to maintain the “lightness” of th
e client. New data entry
screens can be defined with minimum impact on the application size, since all screens use
a common graphics library. While initial download is about 250 kilobytes, screens vary
between 2 and 12 kilobytes each and are downloaded as
needed. All communication with
the server uses XML messages transmitted over HTTP. These messages are much smaller
than the full HTML pages generated for the HTML client, so once the Flash client code
and graphics has been downloaded, it is very quick to p
rocess business requests.

4.5 Business Server

4.5.1 Framework

The latest step in the development of the Chalin project has been to migrate business
logic running on Zerobase’s legacy server to a state
art Enterprise Java Bean
framework. Such a pla
tform is an ideal complement to the work that has already been
performed on the web side, for it is scalable, rugged and plugs in neatly with other Java
based technology. But just as JSP pages were only the beginning of the solutions, just
choosing EJBs is
n’t nearly enough to have a complete solution.

In order to recreate the whole slew of functions currently offered by the C++ server in an
orderly manner and still have room left for new features, Chaplin’s design team had to
come up with a full server
de objects strategy. Prior study of the EJB architecture was
necessary for this plan to take advantage of EJB features and avoid potential pitfalls such
as nomenclature constraints and “no threads” limitations. Work on the original server
design took place

over several weeks, iterating across the range of required and possible
features such as customer
side alterations, distribution of complex processes across
servers and external authentication mechanisms.

The conclusion of this research is that a detaile
d implementation model targeting each
and every task the server will have to perform would prove too restrictive to be useful in
the long run. Instead, the design promotes strict business interfaces coupled with a highly
customizable implementation. Client
s make requests through well
defined interfaces, but
on the inside, the strategy that the server will employ to perform those tasks can be
changed at the configuration level, without needing to recompile the server or restart it.

4.5.2 Design

(Process List)
Session Bean
Indicates what
process list to use
(context Ref)
(Context ref)
Context Ref)
Session Bean
- Session Managment
- Context Creation
- Process List configuration &
- Exception Handling (Retry,
fail etc.)
Business Managers
- Process Lists
- Business Flow Control
Entity Bean
- Single Atomic Tasks
- Data access and storage via FX Server
or Entity Beans or JDBC
FX Server

The “process list” could have been coded using another language than Java (like Python
or Ruby) for accelerated development, but it was judged that Java, when calling Sun’s
JDK compiler dynamically, was as good as any scripting languag
e could get. This
mechanism is also what is used when processing JSP pages. For now, the processors are
still compiled statically.

The valves are small, discard
use, single
purpose objects to be called by the
business managers. Together, they consti
tute a library of all available server functions.
The first processes to implemented will route calls to FX Server. Then, new processes
will be added, replacing the “legacy” ones with direct calls to the database stored
procedures or Entity Beans.

engine is latched onto EJB constructs such as session and entity beans, providing
integration with the supporting platform’s (an EJB container such as IBM WebSphere or
BEA WebLogic) security, load
balancing, fault tolerance and management tools.