Architecting a large-scale system

T

Tanguero .

I've been working for quite a number of years as an architect for a
large-scale financial system in the insurance industry. It is
essentially one huge applet which presents a couple dozen different
screens and graphs to the user. The architecture is rather out of
date but for many of the economic and political reasons many of us
know well, it has been chugging along, quite successfully.

Now the time has finally come to rearchitect it. However, I am
wondering what people are *using* these days to accomplish such tasks.
I have a pretty good knowledge of many different technologies and
methodologies: thin client, DHTML, XML, EJB's, Web services- but what
I really want to know is what people think is practical both for
development and maintenance.

We distribute the app to hundreds of clients with thousands of users
all together, and can mandate their platforms/browser environments to
some degree. Some have low bandwidth though. (hence the desire for a
thin client).

One possibility is XML generated by a J2EE server, massaged into HTML
via XSL and CSS. However, our firm does not maintain a stable of HTML
designers and probably never will, and it strikes me that creating
masterful HTML pages may be an unwieldy skill for us (all java
programmers). Also, some I've seen some prototypes using this
technology and it looks very murky and hard to maintain.

Also, since all our GUI work is currently done within the sandbox of
the applet, we do virtually no Javascript. I've been studying it
recently and while it seems very useful as a supplement to HTML, it
also seems very hard to standardize or maintain on a large scale.

So what are most people doing these days for such a project: a
large-scale heavy-duty financial web-app that needs to be made
available on an extranet to thousands of users at hundreds of firms,
with some control over things like browser version, but less control
over bandwidth?
* * * * * * * * * * * * * * * * * * * *
To email me, remove the gag in my address.
 
C

Chris Smith

Tanguero said:
I've been working for quite a number of years as an architect for a
large-scale financial system in the insurance industry. It is
essentially one huge applet which presents a couple dozen different
screens and graphs to the user. The architecture is rather out of
date but for many of the economic and political reasons many of us
know well, it has been chugging along, quite successfully.

I don't want to sound incredulous, but you called this a "large-scale"
system in the subject. To most people, that implies upwards of 500,000
lines of code or so. Is that what you meant, too? And this thing is
all an applet?!?
Now the time has finally come to rearchitect it. However, I am
wondering what people are *using* these days to accomplish such tasks.
I have a pretty good knowledge of many different technologies and
methodologies: thin client, DHTML, XML, EJB's, Web services- but what
I really want to know is what people think is practical both for
development and maintenance.

That really depends on requirements. You say something about your
requirements below, but it's part of your job at this point to have a
very clear idea of what those requirements are. I'm mostly thinking not
of functional requirements, which I'm sure you're familiar with, but
requirements for performance, scalability, portability, high-availabity,
and everything else-ability.

I'd tend to start with a design that definitely separates business logic
with pluggable user interfaces, just because that seems to be the way of
things these days. That resolve is strengthened by your talk of not
wanting to implement an HTML-based interface. The world being what it
is, you can count on someone eventually telling you to put this thing in
a web application; if you're not going to do it now, you may as well at
least design to make it easier later.
We distribute the app to hundreds of clients with thousands of users
all together, and can mandate their platforms/browser environments to
some degree. Some have low bandwidth though. (hence the desire for a
thin client).

Actually, a thick client gives you the best opportunity to conserve
bandwidth. In fact, it's the thinnest clients (e.g., X servers) that
consume the most bandwidth of anything. Some kind of web delivery WILL
help you to manage all those installation sites, though. That doesn't
have to mean thin. That could mean an application delivered through
Java Web Start.

In fact, to try to make the transition as smooth as possible, I'd be
looking very hard at converting the existing applet into a Java Web
Start application, while simultaneously defining a decent client/server
split and a good general published interface to the server. This looks
like it may help to conserve as much of the work as possible on your
existing project, while opening the road to expanding into new delivery
mechanisms down the road when you get there.
One possibility is XML generated by a J2EE server, massaged into HTML
via XSL and CSS. However, our firm does not maintain a stable of HTML
designers and probably never will, and it strikes me that creating
masterful HTML pages may be an unwieldy skill for us (all java
programmers). Also, some I've seen some prototypes using this
technology and it looks very murky and hard to maintain.

Web apps can be a pain, yes. But, keep in mind that you will almost
certainly be asked to write one eventually, unless your company is
completely isolated from the rest of the known universe (in which case
I'd wonder how your USENET article made it through the interdimensional
portal).

More to the point, though, than whether maintaining a web application
looks appealing, you don't currently have code written to run in a web
application. You currently have code that runs in an applet, which is a
lot closer to an application. That's why I'd be interested in going
that way.

The critical piece for long-term maintenance is the server-side. Look
hard at defining a decent API for client/server interaction. It won't
matter, then, whether one technology or another is chosen for the
client, and that can change over time as your requirements change.
Don't tie yourself to client implementations in the server. That is,
before you decide that the server is going to serve out some XML to be
sent through an XSL engine and delivered to the client, think about how
that XML will be handled by a GUI client, or by a batch processing
client, or by a client producing WML, etc. In general, you want a more
semantic interface to the server, using something like EJB session
beans, CORBA, RMI, or SOAP web service calls.

You've got a lot of thinking to do. Good luck.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
T

Thomas Weidenfeller

Andy Fish said:
My two cents:

If you have a fairly high functionality user interface and your users are
happy with the concept of an applet, I would be very tempted to keep it.

I would be very tempted to change it to a Java WebStart application :)
You get all the benefits that you listed, but you avoid the loading of
the applet over the network everytime the user starts the application.

/Thomas
 
T

Tanguero .

I don't want to sound incredulous, but you called this a "large-scale"
system in the subject. To most people, that implies upwards of 500,000
lines of code or so. Is that what you meant, too? And this thing is
all an applet?!?

It's a fraction of that, and certainly "large-scale" is a misnomer. I
used the term to connote that the app is much more complex than a few
discrete screens (such as a typical consumer e-commerce site); also, I
want a "large-scale" architecture that can handle very complex
interactions and functionality. But- agreed, "large-scale" is not an
accurate description.


I'm mostly thinking not
of functional requirements, which I'm sure you're familiar with, but
requirements for performance, scalability, portability, high-availabity,
and everything else-ability.

Yes- plus functionality and band-width.

The world being what it
is, you can count on someone eventually telling you to put this thing in
a web application;

Silly question: How do you define "web application"?
Actually, a thick client gives you the best opportunity to conserve
bandwidth. In fact, it's the thinnest clients (e.g., X servers) that
consume the most bandwidth of anything. Some kind of web delivery WILL
help you to manage all those installation sites, though. That doesn't
have to mean thin. That could mean an application delivered through
Java Web Start.

We had some bad experiences once upon a time with Marimba, but I do
believe Web Start does solve some of them (EG, need to reinstall the
platform in order to upgrade the jvm).



[snip of some good general advice]

Any good pointers towards sources for researching current
architectural methodologies and their pros and cons? I find that many
of the whitepapers, not to mention books, are mostly devoted toward
selling the architecture they describe.

Thanks.
* * * * * * * * * * * * * * * * * * * *
To email me, remove the gag in my address.
 
C

Chris Smith

Tanguero said:
Yes- plus functionality and band-width.

Yes? The point was that the specific requirements in these areas will
drive your design.
Silly question: How do you define "web application"?

I agree it's a vague term. What I mean in this context is an
application that builds its user interface in HTML and interacts via
standard browser-based uses of the HTTP protocol.
Any good pointers towards sources for researching current
architectural methodologies and their pros and cons? I find that many
of the whitepapers, not to mention books, are mostly devoted toward
selling the architecture they describe.

Sorry, I don't know of a good written description of the kind of thing
you're looking for.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
A

alexis rzewski

It is essentially one huge applet
We distribute the app to hundreds of clients with thousands of users
all together, and can mandate their platforms/browser environments to
some degree. Some have low bandwidth though. (hence the desire for a
thin client).

there is a product that allows Java Applets to run in low-bandwidth
browsers and still "feel" like they are stand-alone applications
running on the same machine. Product is called Classic Blend, at
www.appliedreasoning.com.

This way, you may still use your java development skills to develop
classic Java GUI apps, and use this tool to "tunnel" the UI
visualization process to the browser transparently enough that it
doesn't feel "remote" or slow.

- alexis
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top