Re: Fwd: IceBreak as an alternative to Apache?

Hi Neils

You wrote - Just a simple RPG - ASPX program that explains it all

I do not doubt that you understand the functionality of IceBreak very well
but I have to ask again what you mean by a simple RPG - ASPX program?) The
.aspx extension refers to a Microsoft ASP.NET Page (which is compiled by the
Microsoft .NET framework). It has nothing whatsoever to do with RPG and will
run (unless I'm off my head) on a windows server?

In short what is "a simple RPG - ASPX program", to my knowledge no such
thing exists?

Best Regards

Maurice O'Prey


Hi Maurice;

Maorice O'Pery wrote: (<And please get the spelling write...>)
I for one would sure like to understand how this works?

Well - basically IceBreak is "just" a servlet-container. Just like Tomcat
implements a servlet container for java - this is what IceBreak does for RPG
- or rather for ILE. So more precise - IceBreak is a ILE servlet container,
written in ILE for ILE running only on IBMi - with the same functionality
you find in tomcat. Or if you work with Microsoft: IceBreak is a container
similar to how IIS can instantiate OLE/.NET objects and bring the interface
to the client using and hiding the HTTP / HTTPS protocol.

And the fact that IceBreak is the ILE servlet container also underlines the
misunderstanding of the title of this Thread: "IceBreak as an alternative to
Apache" - Well is Tomcat an alternative to Apache? no - not really.
Typically you use Apache and tomcat very closely together. We also use
Apache and IceBreak closely together.

If you have made servlets or Enterprise Java Beans for Tomcat you will know
what I am talking about- if not; let me just say that I doubt you will find
many (or any) java programs on the net that struggles with using CGI the
always runs within some container. So I can't get my head around the ILE /
RPG dudes have to deal with CGI - if you can have some container to
incapsulate the nasty stuff.

The concept of the "container" in RPG terms is: you have loads of API's you
can call to communicate with the client, the server, the session, the
environment - so you can forget about the client, the server, the session
and the environment code - and only have business logic in your code

And quite frankly: I have no idea why IBM did not give us ILE / RPG dudes a
container for ILE written in ILE along ago ... this is what we have been
waiting for.

Could you please explain the processing cycle which occurs i.e. how the

final

.aspx page is compiled and the results returned to the clients browser?.

Just a simple RPG - ASPX program that explains it all - and remember guys -
there are also alternative to the ASPX/JSP approach in IceBreak by
externalizing the response - but for the simplicity let me make a small
IceBreak RPG program that tells it all:

<%
D name 256 varying
/free
name = qryStr('name');
%>Hello: <%= name %><%
return;
%>

.... Aint RPG just great ....

Lets assume you develop in plain RPG - but have in mind, however COBOL, C++
and CLP is also supported in IceBreak .

First. IceBreak contains a Just-In-Time or JIT-compiler, which is a combined
pre-compiler and the traditional IBM RPG compiler. The first time a resource
is referred from in the browser and the object does not exists ( or is
outdated) it will recompile the ASPX code. Now - if you have some
JSP/ASPX/PHP like syntax ( the <% and %> in you code) it will expand to
response.Write for anything that goes to the client.

The later feature also explain why IceBreak is faster: the static part of
the client response is actually compiled. So no parsing nor "iconv"
translation is required at runtime.

If you have clean RPG - the precompiler does not much except for setting up
bindings and linking to the IceBreak core.

If you have made typos in the code it will now show that in the browser -
otherwise it will create the program object, and call that.

This all happens as long the server is in development mode. When you switch
it into production mode, the JIT is deactivated and IceBreak will always
just call the program object - hence in production you don't need to install
the source code.

Try it out:

www.icebreak-community.com



Best regards


Niels Liisberg

Chief Technology Officer


System & Method
Håndværkersvinget 8, DK-2970 Hørsholm
Phone: +45 70 20 30 10
Fax: +45 70 20 30 11
Direct: +45 45 166 135
Mobile: +45 31 158 861
E-mail: nli@xxxxxxxxxxxxxxxxx
Web: www.system-method.com and www.Icebreak.org





Den 31/12/2010 kl. 09.55 skrev Maurice O'Prey:

If you like the ASP / ASPX JSP was - it is supported by IceBreak

Hi Niels

With particular reference to ASPX pages (.NET Pages) if I submit an HTTP
request for an .aspx page to the IceBreak Server (running on the i?) could
you please explain the processing cycle which occurs i.e. how the final
.aspx page is compiled and the results returned to the clients browser?. I
for one would sure like to understand how this works?

Regards

Maurice O'Prey



-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Niels Liisberg
Sent: 30 December 2010 22:42
To: AS400 iSeries
Subject: [WEB400] Fwd: IceBreak as an alternative to Apache?

Gents;

To many tools out there are based on "one-size-fits-all". IceBreak

follows

an other path and was designed to work with any RPG skill-level you might
have. If you like the ASP / ASPX JSP was - it is supported by IceBreak. If
you like to make Rich Clients like ExtJs - icebreak supports the RESTfull
services datastores behind with one line of code. SOAP services - All
services programs becomes SOAP services.

IceBreak is simply an application server and a webserver in one, that

handles session stability, multithreading, security, SSL, pooling,
No-single-point-of-failure, loadbalancing etc.. - and all the nasty stuff
you will find in microsoft IIS, Oracels GlassFish etc etc - But IceBreak

is

writte 100% for the IBMi platform in mind.

So yes - you will find some fixed formats IceBreak samples - and thats is

also the intention to show you can move real old "Input Primary" program

to

the web.

Btw- I see all the references is to www.IceBreak.org .. and yes it's a

little rusty. However we have just released the new:
www.IceBreak-community.com

IceBreak - you can have it with chocolate and vanilla - it is you choice.




Best regards


Niels Liisberg

Chief Technology Officer


System & Method
Håndværkersvinget 8, DK-2970 Hørsholm
Phone: +45 70 20 30 10
Fax: +45 70 20 30 11
Direct: +45 45 166 135
Mobile: +45 31 158 861
E-mail: nli@xxxxxxxxxxxxxxxxx
Web: www.system-method.com and www.Icebreak.org





Den 30/12/2010 kl. 17.49 skrev Kevin Turner:

Bent

I have changed the thread title for this. I was also slightly misled by

the examples into thinking it was an ASP approach and nothing else, so

maybe

the examples could do with an update? I say that in the full knowledge

that

it is easier said than done and we don't manage to do it very well either!

That aside, is it possible to use the IceBreak HTTP server as a

replacement for Apache for applications that have already been written? To
be more specific, if I have an RPG program that reads from stdin using
QtmhRdStin and returns output via QtmhWrStout can I call that program via
the IceBreak HTTP server and have content returned to the browser? Even

if

it is not possible now, would it be possible after a little bit of pain on
my part?

Is it really 10 times faster than Apache as was claimed earlier by Jim?

Rgds
Kevin



-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]

On

Behalf Of Bent Rønne

Sent: 30 December 2010 15:00
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] 5250 programmer to web programmer

Hi Maurice

With IceBreak, you can choose which path you will go with your web

development. You are not bound by any methods or mask programs, but can
freely choose from all shelves. All the freedom which IceBreak makes
available means of course that you must find the method that suits you

best.

Some choose the ASP route, while others choose to split HTML, JavaScript

(JS) and RPGLE in different files. Eg. I have recently programmed an "edit
system value" maintain application - in ExtJs by the Way. I have divided

the

pieces into html, JS and RPGLE source in three different files.

You can find all sources here http://www.icebreak.dk/sysvaledit.zip

First there is my HTML (sysValEdit.html) who is just used to link things

together with references to my JS and of course the primary link to the
application (http://myserver:8080/sysValEdit.html) from the URL in the
browser.

Eg.:

<html>
...
<script type="text/javascript" src="sysValEdit.js"> </ script> ...
</ Html>

sysValEdit.js is a larger file that is written in 100% JS and it is the

one that contains the ExtJS code. It uses AJAX to retrieve my data from my
System i. When the browser is ready for showing, it calls my RPGLE program
SYSVALEDIT directly on my System i and returns data to the browser. The
RPGLE program is written in pure RPGLE except for the first line of code

in

this example. This line is used by the IceBreak pre-compiler to switch to
RPGLE. But if you like to have your RPGLE isolated in a source file in a
library, you simple make your own 100 % RPGLE code and compile the source
without the IceBreak pre-compiler - use whatever you like, WSDL, RDi, SEU

to

edit and compile - I don't care. All you need is a binding directory and
guess what - it is called ICEBREAK.

This is just one way to use IceBreak on! You can choose the path that

you

yourself seem to suit you.

You should also know that there is an IceBreak community where you can

find lot more information:

http://www.icebreak-community.com/

I hope that you can use my information in your quest for the perfect

solution for Web and System i.

Regards

Bent Ronne
Technical Manager
System & Method A/S


NOTICE: The information in this electronic mail transmission is intended

by CoralTree Systems Ltd for the use of the named individuals or entity to
which it is directed and may contain information that is privileged or
otherwise confidential. If you have received this electronic mail
transmission in error, please delete it from your system without copying

or

forwarding it, and notify the sender of the error by reply email or by
telephone, so that the sender's address records can be corrected.

----------------------------------------------------------------------------

----

CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT

Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.