[Info-ingres] Re: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code to J2EE

#1

Jim,
Agreed that Java has some good points which are not present in OpenROAD.
Probably the best ones are parameters which are validated at compile time,
the boolean data type, C style +=, -=, *=, /= and ?: operators, multi
threading and probably better IDEs. Possibly try/catch pairs.

I maintain that openroad's solution for listening for a button (ON click) is
simpler than Java's. I'll grant that this probably isn't the worst
limitation.
However, I consider the SQL point to be quite major if you are writing a
database application. This is something which was possible in 3GL's in the
1980s (1970s?), albeit with a pre-compiler. I don't think it is acceptable
for a tool which works this way to be touted a solution for writing a
database application. Many may disagree.

I'm not familiar with a problem dropping a session table, are you sure that
still applies? If so, it doesn't seem to apply on 4.1/0403.

With regard to your comments about tools not being good or bad, I was
meaning to criticise Java as a tool for writing a database application
(since we are surely talking about database applications in this forum), not
necessarily Java for writing any application. Perhaps I should have
clarified this initially.

----- Original Message -----
From: "Antill, Jim" <jantill (AT) revenue (DOT) ie>
To: "Simon Lovell" <simon (AT) delta-link (DOT) com.au>; <info-ingres (AT) cariboulake (DOT) com>
Cc: "OpenROAD Users (E-mail)" <openroad-users (AT) peerlessit (DOT) com>
Sent: Wednesday, March 02, 2005 11:37 PM
Subject: RE: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code to
J2EE

Simon,

I found this interesting as I'm starting to do a bit of Java myself. From
what I've found so far it has good and bad points, just like any language.
Some lift it above OpenROAD's level and some seem clumsy by comparison but
that's probably largely down to my lack of experience with it.

I don't agree with your points about getting a button click (simple matter
of
registering a listener and coding event code for it) or the SQL point.
OpenROAD is the only language I've seen where you can put SQL directly into
scripts. VB, Perl etc. all require the use of some form of data access
object
e.g ADO, DBI involving submitting SQL as a string and looking at a returned
resultset. It's a pain when you're used to using OpenROAD's nicer solution.
However, even OpenROAD comes adrift in some circumstances e.g dropping a
session table (resulting in a syntax error picked up), requiring the SQL to
be specified in a string.

There would be a variety of reasons for wanting to move an ABF application
to
Java e.g class-based environment, nicer GUI. As you say though, and given my
limited experience with Java, I can't think of that many "technical" reasons
for wanting to take an OpenROAD app into Java.

IMHO most popular languages have good and bad points, good and bad being
decided upon by the purpose of using the language, level of experience etc.
However, very few languages could be described as being "good" or "bad" as a
whole.

There, lit the touch paper.... time to stand back and be flamed or not!

Regards,
Jim

-----Original Message-----
From: Simon Lovell [mailto:simon (AT) delta-link (DOT) com.au]
Sent: 02 March 2005 01:23
To: info-ingres (AT) cariboulake (DOT) com
Cc: OpenROAD Users (E-mail)
Subject: Re: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code
to J2EE

*************************************

This e-mail has been received by the Revenue Internet e-mail service.

*************************************

Hi All,
I've bit my tongue on this for a while, but since no-one else has commented;
why would you want to migrate to Java?
OpenROAD is a much better development platform, especially now that there is
an eClient available. What you have to do in Java to just get a button to
listen for clicks, not to mention the requirement to format a string to run
an SQL statement; there has to be a better way. Perhaps some IDEs overcome
these limitations in ways I haven't seen or heard of, but barring this, I
think the better way is to use a different tool.

I've been involved in 2 Transforge projects, and while it's far from
perfect, it beats a re-write from scratch. Especially if the proposed
re-write were in Java.

My 2 cents worth.

----- Original Message -----
From: "Paul White" <pwhite (AT) peerlessit (DOT) com.au>
To: <info-ingres (AT) cariboulake (DOT) com>
Cc: "OpenROAD Users (E-mail)" <openroad-users (AT) peerlessit (DOT) com>
Sent: Friday, February 25, 2005 12:00 PM
Subject: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code to J2EE

Quote:

Hi Dennis and Roy,

What about converting to OpenROAD AppServer? ABF easily converts to
OpenROAD at about 1 frame/process per day in my experience, or you could
Transforge which takes you to 3 tier as part of the conversion.

This way you end up with a scalable easily maintained solution which can
run
with any front end you like - java, vb, OpenROAD, eClient, , asp and any
back end you like - Ingres, Oracle, MSSQL, many more.

All without having to risk your core business logic.

Look at http://supportconnectw.ca.com/public...enroadsupp.asp
TEC265123 gives the recipe for converting ABF to OpenROAD.

These CAWorld2004 presentations are appropriate too.
http://agendas.ca.com/Agendas/Presentations/DO301SN.pdf
http://agendas.ca.com/Agendas/Presentations/DO111SN.pdf
There are many more.

Also you should find some lively conversation on this subject over at the
OpenROAD camp.
Sign up at http://www.peerlessit.com/mailman/li...openroad-users

Paul White
OpenROAD Users List Administrator

-----Original Message-----
From: Roy Hann
Sent: Friday, 25 February 2005 10:38 AM
To: info-ingres (AT) cariboulake (DOT) com
Subject: [Info-ingres] Re: Migrating ABF code to J2EE

"Dennis Adams" wrote in message
Anyone out there been looking at a way of migrating ABF code to JBOSS?

What I am thinking is that Ingres Forms contain display & validation
code, which could be converted to Java servlets (or maybe JSP / Struts
?). The OSQ Frame behind them could then become EJBs which communicate
with the front-end.

Fantasy?

It would take a lot of careful design to put together a cross-compiling
utility which could generate the new code from reading the abf database
and underlying osq files. By my estimates, it would take about 6 months
to get a proof of concept together.

Any thoughts ?

Anyone out there with hot "C" parsing knowledge ? From what I have seen
so far, it may require a 2-phase parser, firstly to identify all the
event code entry points and common variables, the second to actually
parse the source code and generate the Java class files.

First part of the project would require mapping all the ABF elements to
the target Java types (Servlet, JSP, EJB, Session Beans etc. etc.). For
that, we need a hot Enterprise Java architect, to sit alongside someone
with understanding of ABF construction.

This idea has been nagging me ever since CA Open Sourced Ingres.
Please, someone put me out of my misery by either telling me it's a
stupid idea, or that it has some potential.

It's a fine idea, and Cognesis thought so too. But they went bust trying.

There is also the problem that you would be using an OO paradigm to
implement procedural code, so you'd end up with a dead-end solution: your
Java code wouldn't really serve as the basis for future development.

Perhaps my colleague Wojtek Rappak will elaborate. He has spent much more
time thinking about this than I have. I am probably grossly simplifying
his
views, but I think he feels it's a no-hoper. All you can do is attempt to
manually extract the business logic from the ABF (usually a titanic
struggle
all by itself), and then use that to design and implement an OO solution
in
the traditional way. The fundamental problem is that you can't write
tools
that will intuit meaningful business objects from traditional "4GL" code.

A couple of years ago we tried to develop a server to run ABF by proxy:
the
idea was to provide an interface to the ABF logic so that it could be
invoked from Java clients. We sorta got it working, but ABF's limited and
patchy ability to "introspect" and fully expose its own meta-data made it
impossible to use except in special cases, so we abandoned it. I suppose
that we could now fix ABF so that it could give us the meta-data we would
need, but I can think of about 20 other things I'd rather spend my energy
on
now. I still think this would be a better approach though, because you
would use good Java to run good ABF/4GL, instead of generating
(necessarily)
crap Java to do things in an inescapably crap way. And you could continue
to develop the 4GL code, so it wouldn't be a dead-end.

However, the ideal solution is much more radical than anything we've
mentioned above...but that's another thread for another time.

Roy Hann (rhann at rationalcommerce dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres
_______________________________________________
Openroad-users mailing list
Openroad-users (AT) peerlessit (DOT) com
http://www.peerlessit.com/mailman/li...openroad-users

_______________________________________________
Openroad-users mailing list
Openroad-users (AT) peerlessit (DOT) com
http://www.peerlessit.com/mailman/li...openroad-users

************************

This message has been delivered to the Internet by the Revenue Internet
e-mail service

*************************

#2

Hi Dennis,

You can have your cake and eat it too. Conversion from ABF to n-tiered is
relatively easy - it can be automated and it can be cheap. You can have
your html, java, vb.net or anything else you like at the front end. OpenROAD
Application server allows you to run as many tiers as you like.
Paul

Dennis writes...

Quote:

However, as Roy and others have pointed out, it's no simple job to
morph a procedural language into an Object-Orientated one. The
resulting code would be a mess.

-----Original Message-----
From: Dennis Adams [mailto:dennis (AT) dennisadams (DOT) net]
Sent: Saturday, 5 March 2005 5:02 AM
To: info-ingres (AT) cariboulake (DOT) com
Subject: Re: [Info-ingres] RE: [Openroad-users] RE: [Info-ingres] Re:
Migrating ABF code to J2EE

Hi All,
I can see that I stirred things up by introducing the ABF to J2EE topic
:-)

The reason I was suggesting moving to J2EE, instead of OpenRoad, is
because many people these days are interested in web-based
applications. Last time I looked (a long time ago!) OpenRoad was a
client-server environment.

So I was thinking about a front-end based around HTML (or Java Server
Pages using Tag libraries or Struts), with a Middle layer holding the
Business Logic,

So the environment would look like this:
Browser ->
WebServer for Display Logic ->
EJB Application Server for Business Logic (such as JBOSS, also
OpenSource from CA ) ->
Relational Database

Knowing that ABF apps consist of Forms (Display Logic) and Frames
(Business Logic), I was wondering whether they could be mapped.

However, as Roy and others have pointed out, it's no simple job to
morph a procedural language into an Object-Orientated one. The
resulting code would be a mess.

The only real value is that you would have "web-enabled" your app.
Which might be quite a plus for some people, because it would preserve
their Ingres investment, and provide an interim solution until they are
able to re-write the business logic "properly".

Dennis

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

#3

re: AppServer plug

If anyone wants further inspiration on getting from ABF (or client server OR)
to SOA and AppServer and the brave new world of clients that it opens up I did this talk
at the last CAWorld (remember them?!) http://agendas.ca.com/agendas/Sessio...?SessionId=177

Whilst it over simplifies the process the reality isn't so far
removed from the theory. As Paul points out, parts of the
conversion can be automated; provided you use your
brain to work out the tricky bits - popups in select loops,
temporary tables etc - you'll be surprised at just how quickly
you get results. And you can be as OO as you dare, from
simple procedural services, through to a fully buzzword
compliant domain/proxy/assembler/CAO/DTO/DAO/bpm/façade
SOA object-fest!

If you pilot the approach on one functional area and move
your data access plus some 'business logic' to AppServer that's
a good start which enables 'quick win' web/mobile front ends which get the
attention of management and hopefully the commitment to go further.

For folk already in the fat client-server OpenROAD connundrum
you can combine this approach with an eClient deployment of your
app minus the SQL to begin with. http://www.iua.org.uk/conference/Spr...ock_062004.pdf
A cosmetic facelift at the same time probably wouldn't hurt, and
again would get some buy-in from the bean counters et al. The devil
is in the details and YMMV of course but this isn't impossible, makes
the most of your investment in ABF/OpenROAD and enables integration
with other .NET and Java technologies as well.

Yes, I'd love folk to get Luminary involved to help on this but there
are plenty of people doing this successfully on their own. Make the most
of what you have got. We do Java and C# too. Both about 3-5 times as much
code per function we reckon. I bet you think your ABF/OpenROAD system
has a lot of code in it! Cue Smashie and Nicey hitting the faders for Bachman
Turner Overdrive classic... (sorry, aged UK 'comedy' it's my day off. Forgive me) http://www.bbc.co.uk/comedy/guide/ar...603841_1.shtml

Regards

Neil Warnock

-----Original Message-----
From: Paul White [mailto

white (AT) peerlessit (DOT) com.au]
Sent: 07 March 2005 07:00
To: 'Dennis Adams'; info-ingres (AT) cariboulake (DOT) com
Cc: OpenROAD Users (E-mail)
Subject: RE: [Info-ingres] RE: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code to J2EE

Hi Dennis,

You can have your cake and eat it too. Conversion from ABF to n-tiered is relatively easy - it can be automated and it can be cheap. You can have your html, java, vb.net or anything else you like at the front end. OpenROAD Application server allows you to run as many tiers as you like.
Paul

Dennis writes...

Quote:

However, as Roy and others have pointed out, it's no simple job to
morph a procedural language into an Object-Orientated one. The
resulting code would be a mess.

-----Original Message-----
From: Dennis Adams [mailto:dennis (AT) dennisadams (DOT) net]
Sent: Saturday, 5 March 2005 5:02 AM
To: info-ingres (AT) cariboulake (DOT) com
Subject: Re: [Info-ingres] RE: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code to J2EE

Hi All,
I can see that I stirred things up by introducing the ABF to J2EE topic
:-)

The reason I was suggesting moving to J2EE, instead of OpenRoad, is because many people these days are interested in web-based applications. Last time I looked (a long time ago!) OpenRoad was a client-server environment.

So I was thinking about a front-end based around HTML (or Java Server Pages using Tag libraries or Struts), with a Middle layer holding the Business Logic,

So the environment would look like this:
Browser ->
WebServer for Display Logic ->
EJB Application Server for Business Logic (such as JBOSS, also OpenSource from CA ) -> Relational Database

Knowing that ABF apps consist of Forms (Display Logic) and Frames (Business Logic), I was wondering whether they could be mapped.

However, as Roy and others have pointed out, it's no simple job to morph a procedural language into an Object-Orientated one. The resulting code would be a mess.

The only real value is that you would have "web-enabled" your app. Which might be quite a plus for some people, because it would preserve their Ingres investment, and provide an interim solution until they are able to re-write the business logic "properly".

Dennis

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com http://mailman.cariboulake.com/mailm...py/info-ingres

_______________________________________________
Openroad-users mailing list
Openroad-users (AT) peerlessit (DOT) com http://www.peerlessit.com/mailman/li...openroad-users

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

[Info-ingres] Re: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code to J2EE

comp.databases.ingres comp.databases.ingres

[Info-ingres] Re: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code to J2EE - 03-02-2005 , 06:31 PM

RE: [Info-ingres] RE: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code to J2EE - 03-07-2005 , 12:59 AM

RE: [Info-ingres] RE: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code to J2EE - 03-07-2005 , 04:24 AM