Re: Fwd: IceBreak as an alternative to Apache? -- WEB400

This is very nice, as lots and lots of printstatements frequently get very tedious.

Perhaps these should be named "ISP"-files or "RSP"-files to say that they are _like_ JSP and ASP but still different?

And just a note from history class (yes, that is a Java class). The JSP-developers found that large JSP-files were hard to maintain. The concept of two languages weaved together does not scale well, so the current consensus in the Java world has been to move to pure XML based facelets which then list operations from one or more independent libraries. In other words going up a level of abstraction.

Perhaps this is not relevant here as it is easier to move complexity into the called program and leave it at that?

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Henrik RÃtzou
Sent: 4. januar 2011 21:42
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Fwd: IceBreak as an alternative to Apache?

Let me try to explain this without fancy buzzwords:

In Icebreak you place your sourcecode in an IFS files. This file looks and
behaves like an ASP or PHP page
where you with a special syntax can switch between server side code and
client code (HTML etc.) so the
sourcecode can hold both.

What Icebreak does, is that it translate this IFS file to a RPGLE
sourcemember where all client code (HTML etc.)
is imbedded in procedure call like WrtNoSection('bla bla bla') in CGIDEV2 or
echo('bla bla bla') in my frame-
work that both write the embedded client code into the HTTP output buffer.

The smart thing is that you do not have to code ...

echo('<html>');
echo('<body>');
echo('hello world');
echo(</body>');

but can code large sections of client code like this

some rpgle serverside code
%> // start client code
<html>
<body>
hello world
</body>
<% // end client code
*inlr =on;

The Icebreak precompiler then breaks op the clientcode in RPGLE code like
the above "echo's", generates the
RPGLE program in a sourcefile and copiles it automatically.

One very nice feature in Icebreak that you don't have to do any activity to
make this happen - it is automatically
done if you change the IFS sourcefile in testmode.

On Tue, Jan 4, 2011 at 9:19 PM, Maurice O'Prey <Maurice.Oprey@xxxxxxxxx>wrote:

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 <http://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 <http://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<http://www.icebreak.org/>.. and yes it's a

little rusty. However we have just released the new:
www.IceBreak-community.com <http://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<http://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.

--
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.