Re: Some experience - as400 server side java -- JAVA400-L




>Jacada Connects allows you not only to execute legacy programs, but also
>to interact with them via the "green-screens" in a high-level manner.
>The two important points here are the interaction (by emulating a user)
>and the fact that there's no need to rewrite the legacy program (which
>is almost always the first requirement about reusing legacy systems).

Screen emulators are certainly a class of solutions that have merit for a very
specific niche; primarily that of face-lifting existing systems which you do NOT
intend to re-engineer.  In that case, they provide a relative quick and painless
path to making an old system easier to use, and giving it some limited
interaction with real desktop applications.


>While it's certainly possible to do all that with other technologies,
>some of which may be free, the main difference is the level of
>abstraction you get.  It's like saying that you can code object-
>oriented GUI-based programs in assembly language.  It's certainly
>possible, but would anyone do that knowing there's Java (or even
>C++), even if the assembler was free but Java wasn't?

Interesting analogy, if slightly stretched.  Object oriented development is a
goal in its own right; screen emulation is not.  If I a method that would create
real objects from my legacy code with as little effort as applying an emulator,
I'd never go the emulation route.  However, that's not the case today, so
products like Jacada exist to provide a temporary solution.


>Given all of that, I think Jacada Connects does solve a specific
>problem, and I don't view executing a Java class from RPG as Java
>interacting with a legacy program, although if RPG can execute
>any other program it can certainly execute Java programs in the
>same manner (not to mention JNI).

Another interesting opinion.  When I'm re-engineering my legacy system, my goal
is to have three distinct layers: presentation, business rules and persistence
(the classic 3-tiered model).  The server side usually encompasses the latter
two.  First I separate the user interface out into the client, then I separate
the server into business rules and persistence.  Clients are rewritten in Java
(for WORA), leaving the servers as legacy code.  The next step is to separate
the persistence from the business rules.  The persistence portion is easier to
rewrite than the business rules (it's usually a lot more repetitive and strictly
definable), which is where legacy code will need to directly call Java.

Also, it is not true that RPG can execute Java in the same manner as any other
programs.  On the AS/400, Java programs are of a distinct type (*JVAPGM) which
does not interact with other programs of type *PGM in the same manner that they
interact with one another.  Java programs only operate inside of the QShell
emulation.  The closest you can get is the equivalent of a command line call
from a .BAT file in MS-DOS.  Parameters are strictly unidirectional, and that,
together with the call overhead, prevents using Java programs as part of the
AS/400's normal multi-language development environment.


>Final comment - My initial reply was brief and incomplete because
>I didn't want to turn it into a marketing pitch - I opted to
>point you to our Web site instead.  I think you can see now that
>my plug has merit, but if not, then I sincerely apologize for
>wasting your bandwidth.

Your plug has merit in that it answered a specific question about interacting
with legacy applications, and I welcome any postings of a like nature.  As you
might guess, though, this forum is primarily devoted to developing Java
solutions on the AS/400.  Redeployment of legacy systems as objects is a major
goal, and Jacada is not a strategic part of that goal.  Note the word
"strategic", however.  Jacada can definitely be a tactical tool to allow
prioritizing systems, even to the point of saying "we're NEVER going to redeploy
this one".  However, those decisions are outside the scope of this humble little
mailing list.

Anyway, thanks for your input, Nimrod.



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---