Re: What is Performance -- JAVA400-L

On Sonntag, 14. März 2004 16:46, Joe Pluta wrote:
> > From: Dieter Bender
> >
> > Joe, this cant be the rule of the game. In your originating posting
>
> you
>
> > claimed performance benefits of rpg business logic components of 10 to
>
> 100
>
> > times. It can't be my work to prove that this numbers are by far too
>
> high.
>
> If you can't prove your statements, don't make them.  If you don't like
> my statements, disprove them.  Until then, my arguments are as valid as
> yours.  In this game, Dieter, only numbers talk.

Your statement by performance benefits of 10 to 100 times faster is as  proved 
or unproved as mine. One diffrence is, that yours is in contradiction to the 
official manuals of ibm.
>
> > To make it simple let us discuss this on your example for the programm
> > call (the counter).
>
> Okay.  What I'm going to do is create an architecture which disproves
> your contention that we cannot use pooling AND talk to a stateful RPG
> session.  At that point, will you then finally agree that perhaps you
> don't know as much about scalability as you contend?  And that perhaps
> some of us know how to write high-volume Java/RPG applications?

This way it would work, no doubt, what you are doing is to write some sort of 
ejb container for rpg components. 

>
> > If you would use this rpg counter to put the number of
> > transactions on every JSP increasing it by 1 for every JSP shown for
>
> the
>
> > user
> > in his session, you would have to put the AS400 Connection for the
> > programm
> > call in the session object of your Web Application, otherwise you
>
> would
>
> > loose
> > the state of the rpg counter programm from one call to the other.
>
> Wrong.  I save the name of a data queue in my session object and use a
> pooled connection to talk to the data queue.  I only need the pooled
> connection for as long as it takes to communicate with the data queue,
> which is very brief.  The data queue serves as a conduit to a stateful
> job that can do anything I need.  Synchronization is not an issue, state
> is not an issue.
>
> That's just ONE way to provide scalability and it works even for load
> balancing, since my data queues can be used to talk to remote machines.
> In fact, this is a really nice way to front one large iSeries for
> business logic processing with a number of small, inexpensive we serving
> boxes.

I would agree, that this architecture would solve most of the scaling issues 
and you will get full benefit of performance advantages of rpg components, 
what ever the factor might be.
>
> And I can think of other ways, Dieter.  Your analysis of the system is
> simply incomplete.

My goal  was not completness, I had just had a look at one way its often 
implemented.

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? 

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. Or maybe the as400 should support 
CORBA, I don't know.

This part of the code would be a little bit complex (you have to do some 
housekeeping) , but if it is encapsulated in some modules with a clear 
interface not too complex. but most implementations, the examples in the 
redbooks  and what you find in the web are just a mix of java programs 
calling rpg and rpg calling java per JNI call and you find not one word 
regarding the problems this might have.

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.

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.

Dieter

>
> > With such a design you would not survive a design review by an
>
> independant
>
> > third party in case of trouble with your custumor on the scalability
>
> of
>
> > your
> > application. (I took part on such reviews as consultant for a
> > softwarehouse
> > and we came in problems, because they stored the JDBC Connection in
>
> the
>
> > session).
>
> I couldn't care less about third party audits, because frankly most
> auditors don't have a clue about the iSeries, as we've seen over and
> over again.  The iSeries is BUILT to scale; if people used the iSeries
> (correctly) rather than Wintel platforms, we wouldn't need to have
> independent third party auditors.  But even so, by simply storing a data
> queue name in my session, I'm completely serializable and thus load
> balanceable.
>
> Anyway, hopefully I've shown you one simple example of thinking outside
> the box you've placed on the iSeries, and on Java/RPG communication.  As
> I said, the iSeries is built to scale (hey IBM, how's THAT for a
> slogan?).
>
> 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