Re: The "Presentation" Layer

P2P is when the two sides on a connection can be either a client, a server, or both. Specifically, client/server is an architectural approach which is simple, robust, and scalable (i never said client/server is a bad thing).

By designating a specific role (client or server) to each side it makes implementing a scalable and robust distributed app simple. A client always initiates a request to the server, and a server simply processes requests. A client also typically knows the address of the server wher to send the requests to.

If you have simply TCP/IP, you actually have a peer-to-peer network. Each program can connect to any other program and take on whichever role. But distributing code over different processes which are "peers" (i.e. they are equal) is more difficult to implement.

You can say that APPN is peer-to-peer and TCP/IP is not, because APPN implements additional functionality that is specifically for peer-to-peer networking such as discovery of neighbor peers. In TCP/IP you have to implement this yourself with e.g. UDP. In APPN, the LU6.2 logical unit is the "peer" on the network. LU6.2 supports different protocols for dealing with peer-to-peer networking.

A green-screen terminal is also a peer in the network, but in practice it acts more as a server, and the program running on the host is the client. E.g. the program requests the terminal to display a format. So most of the time a terminal takes on the server role. However, at first, when logging into the system, a terminal initiates a session and has the client role.

Date: Fri, 18 Jul 2008 07:52:52 -0500
From: aaronbartell@xxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] The "Presentation" Layer

Good point, I should be more careful of how I relate the architectures when
we are describing lower level details. So what would be the ramifications
of developing such a peer-to-peer in a GUI world? I guess it would be the
same issues of having persistent HTTP programming put in place where each
user had their own job, which could because a resource issue for a large
website.

Let me ask this: What exactly makes 5250 peer-to-peer vs. client/server? Is
it the "thin-ness" of the client (i.e. the terminal) ? Is it the
statefulness of the client in that it never loses connection and has a
direct line into the machine (brings back coaxial memories :-)?

And based on how that is answered, couldn't a guy create a "peer-to-peer"
with the JT400 classes as that will give you a handle to a specific
session/job on the AS400?

If a guy could make a JT400 connection from a thin client (like Flex/Flash)
to the AS400 then it could be seemingly peer-to-peer as there would be a
dedicated job. The reason I think dedicated jobs are ok in *some* instances
is because in *some* instances they work great. Just look at how successful
your 5250 programming has been to date. For most all new intranet
development a peer-to-peer/one-job-per-user would be perfectly acceptable
(because you already have that performance load on your AS400 through 5250
sessions).

Thoughts?
Aaron Bartell
http://mowyourlawn.com

On Fri, Jul 18, 2008 at 6:31 AM, john e wrote:

Aaron wrote:

What's so very interesting to me is that IBM chooses not to develop their
own Flex/Silverlight/JavaFX. Now this is most likely because of their

love

of Java, but I feel they forgot how successful they were with their
proprietary 5250 spec/implementation. Adobe/Microsoft/Sun are following

in

their footsteps 25 years later and saying it is "new".

5250/APPN which is the architecture the green screens are built upon is
completely different. The underlying architecture is not client/server, but
peer-to-peer. There is simply one program running on the host and it drives
the terminal, which is the other peer. This is completely different from
Flash etc. Flash/Silverlight is not new, indeed. It's simply client/server
but where the client code is provided by the server dynamically, eliminating
lots of deployment problems. And, of course, it has the "cool" factor, which
seems to be quite important these days.

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

_________________________________________________________________
De leukste online filmpjes vind je op MSN Video!
http://video.msn.com/video.aspx?mkt=nl-nl