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