chaplin_white_paper - CGI Treasury Services

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

2 Φεβ 2013 (πριν από 4 χρόνια και 8 μήνες)

242 εμφανίσεις

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.
Standards
-
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

was
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.
Architecture


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
-
of
-
breed developpment and server tools from both commercial and public
organisms.


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
-
Struts
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
well
-
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
C
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
time

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 :



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


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

in
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
new

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
-
known
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)
templates.

calls
PostActionServlet
XmlActionServlet
url-encoded POST
XML
ActionForm bean
Action
Controllers
jndi
Html generator JSP
XML generator JSP
Taglibs
HTML
XML
Forwards
Reads
writes, exposed
as a std bean
reads, exposed
as a std bean
Flash 5.0
Forwards
Html
Html
EJB Server
IIOP
populates
calls


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
on
-
the
-
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

vector
-
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
many
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
full
-
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
all
-
or
-
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
XML.


text
CLIENT
front-side application movie
players
approx : 240-260kb
CHAPLIN800X600.FLA
application background and
area size
approx. 25kb preloaded
2001-06-20
chaplin flash communication
WEB SERVER
Chaplin application server
"screen name".FLA
screen graphic and
script, gui items
coordinates and
parameters
approx. 2-12kb
loaded dynamically on
request
MAIN.FLA
gui items library, windows, engine script and
communications functions.
approx. 220kb preloaded
Window container and
GUI items
Engine and Communication
functions
XML



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
-
and
-
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
flexibility.


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
-
of
-
the
-
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
-
si
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


Processor
(Process List)
Session Bean
Valve
Y
Valve
X
Valve
Z
DB
Request
Configuration
Indicates what
process list to use
(context Ref)
(Context ref)
Context Ref)
Context
Session Bean
- Session Managment
- Context Creation
(Marshalling/Demarshalling)
- Process List configuration &
call
- Exception Handling (Retry,
fail etc.)
Business Managers
- Process Lists
- Business Flow Control
Entity Bean
JDBC
Valves
- 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
-
after
-
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.



This
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.