Re: Calling ILE from Java

Aaron Bartell wrote:

And seriously, I don't think you need threads in i5/OS, just dedicated

jobs. You start the job when the user authenticates and end it when the
user logs off or times out.

So how does that architecture work for an Internet app where there are going
to be thousands of users?

Before we wander too far down this theoretical road, I think you might want to spend some time getting really specific about your requirements. Thousands of users won't make a System i blink. That's one of the beauties of the architecture. It requires a bit of horsepower, but then again, it requires a bit of horsepower to run thousands of users on Windows or Unix.

Where you run into problems is when you hit tens or hundreds of thousands of users, or even millions. There are physical limitations such as ports, and bandwidth limitations and just the overhead of creating and maintaining thousands of user profiles. At that point, you have to get very careful about terminology. Are you really talking about 100,000 simultaneous authenticated user sessions, or are you talking about 100,000 stateless anonymous requests? The needs for those two architectures is very, very different.

I guess that is where I was going with the idea
of doing threads on the RPG side. Don't know if those would all reside in a
single job or not. Nor do I know how much performance is gained/saved by
going the thread vs. job route. In the end I would guess that the main
savings is in the startup of a thread vs. a job, and after that the same
amount of resources would be consumed (i.e. ODP's, program storage, static
variable storage, etc).

And in the case of authenticated users, which is my real problem domain, since I start the job when the user authenticates, the startup overhead is negligible. I could see the issue if you were talking about startup for every request, especially if a single page used dozens of requests as we're beginning to see in Web 2.0 implementations.

Would be an interesting test to run: Start 10,000 jobs and time it. Start
10,000 threads and time it.

I think when the new website comes up, that will be one of the benchmarks.

BTW, I agree that with the IWS it is very appealing to just install a thin
J2EE layer that communicates with the RPG. Especially given the significant
performance enhancements to Java in V6R1 with the Power6 chips. In your
mind are you still consuming the resulting data from RPG by manually typing
out JSP code? Or do you have an "engine" of sorts that takes the data (with
additional markup for names and coordinates) and have the JSP/Servlet
dynamically display the results? I know this is usually where we disagree,
but if you had the latter, then the RPG programmer wouldn't have to know a
lick of Java/JSP/JSF/EGL/Servlet/etc. They would simply have to know how to
send and receive messages from the relaying mechanism (i.e. data queues).

I don't know that we disagree so much as have different areas of focus. The majority of my design work is at the model level - encapsulating business logic to be consumed. You're talking about the controller and view, and that's a really complex subject. You're positing a controller layer that sends the model data interspersed with view information (names and coordinates) to a presentation layer, and while that's a powerful concept, it's not where I spend my time.

Personally, if I need a fast, powerful interface I'll use JSP Model 2, or EGL if Java is a stumbling block. But really it doesn't matter; if you design the business logic properly, it will support any UI. Heck, you can use those same servers as the back end to green screen programs.

On a slightly separate note, do you see an advantage for server initiated
communication to the client? This would be more of a true async model and
removing polling from the browser using AJAX.

In general, push technology has limited usefulness in standard business applications. Of course, it has great utility in social software such as IM, so there's probably a need. But it's not my center of focus right now.

Joe