Re: What is Performance -- JAVA400-L

On Sonntag, 14. März 2004 19:15, Joe Pluta wrote:
> > From: Dieter Bender
> >
> > What you are doing, looks a lot like EJBs of your own. Your DTAQ
>
> Server
>
> > programm is in fact a rpg implementation of a statefull session bean,
>
> why
>
> > don't you like beans?
>
> Actually, EJB session beans are a Java implementation of standard job
> sessions which have been around for thirty years.  I don't like to use
> beans to do something that's already available natively on the machine.
> I choose not to sacrifice performance for portability.
>
> But I really don't have as much of a beef with session beans.  I think
> they're unnecessary given the architecture I've outlined, but they're
> also pretty easy to implement and usually don't add too much overhead
> (unless you're try to serialize large RowSets or something equally as
> poorly designed).  It's entity beans that I can't stand.  CMP introduces
> so much bloat it's not funny, while BMP basically requires you to write
> your own logic anyway, so I'd rather simply make lightweight transport
> beans that communicate with an RPG server.
>
> > I would prefer for my own the standard ways and I am thinking for most
> > programmers it would be more easy to use those standard components
> > compared to writing their own application container.
>
> But that's because your primary goal is to have your software run
> without modification on multiple operating systems.  

No, that's not the primary goal, database access code isn't really portable 
anyway. My primary goals are keeping things as simple as possible and top 
down reuse of components. Keeping it simple is one thing that has prevented 
me up to now to recommend customers usage of entity beans. But the projects I 
have seen during reviews that used entitity beans have had less design 
problems than those, who didn't use entity beans and this caused me to 
reconsider usage of entity beans.

> Your customers pay
> the price in performance.
>
> > Or maybe the as400 should support CORBA, I don't know.
>
> What does CORBA have to do with anything?  As far as I'm concerned,
> CORBA is just another bloated convention.

As far as I know, CORBA is an architecture to integrate already existing 
business components. I didn't use it yet, its not supported by as400.

>
> > Why don't you provide some kind of Open Source Framework for the
> > integration
> > of rpg components in java applications? Doing it this way, even me
>
> could
>
> > recommend the use of this for the reuse of rpg components. Maybe I
>
> should
>
> > write an article "Reuse of rpg components in java - but do it the
>
> right
>
> > way"
> > for german "midrange magazin" and of course I would make the code of
>
> the
>
> > examples open source.
>
> Feel free to do so, Dieter.  And maybe I'll write one for MCMagOnline.
>
> > Last but on this thread: most rpg applications I've seen are rather
> > monolithic
> > and don't have too much reusable components, but I don't have seen a l
>
> l
>
> > applications.
>
> You haven't seen many ILE service programs then, Dieter.  

There are not so much shops in germany writing true ILE programms, most of rpg 
users stuck with rpgIII even rpgII is out there. Others only did CVTRPGSRC 
and compile with 14 from PDM and believe they do ILE.

> ILE allows you
> to write beautiful RPG code that is as modular and powerful as any other
> linked language.  RPG may not have the OO features of Java, but it's at
> least as powerful as C, in my mind, especially because of the powerful
> integrated database functions.

Two comments: 
What really is missing in ile rpg is a strict type binding as PASCAL it has 
for instance.
I stopped using of binding at compile time and have switched to late binding 
of Service programms  at runtime and what is missing here is flexibility in 
activation. I didn't find any way to circumvent the static determination of 
the activation group a module will run in at compiletime.
Regarding the database functions of the language, I prefere usage of SQL, 
though the precompiler is very ancient and terrible. But the seperation 
between the database design and the database access layer is easyer this way.

Now going out of office, teaching rpg programmers to learn java like the 
mainstream it does :))

Dieter

>
> Joe
>
> _______________________________________________
> This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
> mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.

-- 
mfG

Dieter Bender


DV-Beratung Dieter Bender
Wetzlarerstr. 25
35435 Wettenberg
Tel. +49 641 9805855
Fax +49 641 9805856
www.bender-dv.de
eMail dieter.bender@xxxxxxxxxxxx