|
Pete,
How have your experiences with HATS been? How much work has it taken
to implement HATS transformed applications? How is the performance?
Our results have been mixed. For inquiry applications it's been OK.
For heads-down data entry applications it's been unacceptable. We had
a situation where we bought a zero-interactive system to run Lawson,
then realized that Lawson users also used custom-written 5250
applications. We were up against a wall and decided to go with HATS.
When we had to punt on the one data entry app the users used, we
DDM'ed the files back to another system that has 5250 capability and
let them run the app there.
So HATS is fine for that. We're also thinking about using it in a
situation where we need to provide access to 5250 applications from a
browser-based application (when we're not given the opportunity to
rewrite all the 5250 apps).
My problem with HATS is that it's a dead-end (as others have stated).
IBM has tried to put some serious lipstick on this pig and position it
as a way to convert a 5250 app into a service, but the work involved
is just not worth it in my opinion. I've done the lab, so I know it's
possible. I just can't imagine doing what they require for a real,
production application. If IBM provided a quick and easy way to
provide both HTML and web services interfaces to a 5250 app, that
would really facilitate modernization. We could quickly leverage our
business logic that's locked into 5250 apps, using any virtually
front-end language we'd like (Java, PHP, EGL, RPG-CGI, etc) to
modernize our application. Then we could take our time and modernize
our RPG, decoupling business logic from presentation.
Sorry to flog this same dead horse.
Mike E.
On Tue, Jul 15, 2008 at 11:26 AM, Pete Helgren <Pete@xxxxxxxxxx> wrote:
I am going to weigh in here because I have been involved in several of
the issues that have been discussed.
A Webfacing technology like HATS or what ever, that uses a 5250 data
stream and "interprets" it, always had to be an interim strategy. I
can't see how it could be anything else. So, if someone bet the farm on
building 5250 applications indefinitely while relying on an interpretive
technology to present it to the web, then I am guessing that they really
didn't understand the tool that they were using. The HATS tooling I
have done was always stopgap, primarily because the end user need always
outstripped the ability of the tool to deliver. Web applications are
very different than 5250 applications so I really can't see how HATS
could have ever been a "final" solution for 5250 shops.
Actually, there is no "final" solution because the technology out there
is evolving at such a rate that you can't "bet the farm" on anything.
The best approach, expensive and difficult, or not, is to use
multi-lingual, multi-tiered flexible architectures that can evolve with
the technologies. This business will require lifelong learning and
agile techniques to stay within the power curve (let alone getting ahead
of it!). Your development strategies have to reflect that. Fortunately
we have bet the farm on a platform that can accommodate that rapid pace
of change.
Whether you decide to use something like EGL to marry the presentation
layer and the business logic is a business/personal decision that I
don't think you can ever permanently make. It can be part of your
*current* total multi-tiered solution, or some other technology may be
your choice. In any case, it *will* change. There will be a *new*
tool, within a few years that will impact your development. It's
reality. It's gonna happen. So plan for that in your design strategy
so as you rip out one layer and replace it, it will have a minimal
impact on your overall solution.
I do a lot of technology "tasting" (for lack of a better term) because I
know that the next development tool will reflect what is learned from
existing tools. I can sometimes leverage the small things I pick up on
the way to produce a better solution but I never assume that I am done.
I'll wake up tomorrow and find out that EGL is now replaced with the NBT
(next big thing). I am fine with that. Innovation results in constant
change. I am cool with that as well.
Could IBM do better in laying out a long term development tool
strategy? I don't think so. I am just glad that they are constantly
developing new stuff for us to try on for size. It is the way things
are. It ain't 1980 any more. Things will never stay the same.
My 2 cents.
Pete Helgren
Aaron Bartell wrote:
--Webfacing was never a modernization strategy.I think we are just having differences with word definitions here.
Webfacing is most definitely a modernization strategy! It was simply meant
as a stepping stone part of the modernization strategy to get to the
endpoint that we both agree on to be Java.
The future is multi-lingual, multi-tiered, multi-interface, multi-platform,and the fastest way to get there is EGL.
What an incredibly expensive way to do business.
Aaron Bartell
http://mowyourlawn.com
This is the Websphere Development Studio Client for iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
