Re: IceBreak as an alternative to Apache?

On 1/4/2011 10:22 AM, Niels Liisberg wrote:

Joe - you are absolutely right. The IBMi is especially good a one specific feature: job management. So we just let IBMi do what it is best at - task switching - keeping track of QTEMP, filepointers, units of work/commit control, paging, prioritizing etc.
The only difference Joe is that IceBreak don't need that much RAM - we don't use Java. Our application stack is so tiny - it is ILE, so we only have one procedure your app waits on. If your app terminates with *INLR the complete persistent job only requires 8MB per session - I will not go into the *INLR / or not discussion - but just say that the IceBreak stack just reflects the stack of an old 5250 app. - If you open lots of files and keep the open : it is not my business - If you use *INLR or return it is not my business - My business is that you can have it with vanilla or strawberry as you like....

I really don't want to turn this into a marketing discussion about IceBreak. People can call you to learn more about your product. If IceBreak does everything someone needs and they're willing to pay the price, then that's fine. But let's not compare apples and oranges. IceBreak is smaller than Java because it doesn't have the vast number of features Java has, whether it's JSF 2.0 or JAX-WS/RS or Servlet 3.0. Java EE is not a tool, it's a platform.

Java EE is just as flexible as IceBreak. Every architecture you support in IceBreak is available in Java EE. JSP Model 1 is the same as ASP or standard IceBreak; write HTML and insert code to get data. JSP Model 2 allows you to build a complete MVC environment with a very thin UI layer over RPG. On the far end of the spectrum is JSF 2, which provides persistence, navigation, exception handling and a host of other features for advanced Web 2.0 design. In any of those designs, your business logic can be stateless or stateful. Java provides vanilla, strawberry, and some really good mint chocolate chip as well <smile>.

So, sure, IceBreak is smaller. And it's perfectly suited for a specific business requirement. Java EE addresses a different need.

Joe