× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: The Types of Distributed Architectures
  • From: jemason <JEMason@xxxxxxxxxxxxxx>
  • Date: Thu, 15 Jun 2000 20:03:44 -0400

Hi Joe.

Interesting comments on architectures for web applications.
I feel your thoughts are relatively 'mainstream' in most people's minds.
Servlets are more than web '5250'.  They provide a message based
interface to an application for multiple client types and protocols...
I look forward to seeing how strong, fast and flexible IBM's new Web Facing
tool will be for existing 5250 applications moving to the web !

I do see a few other opportunities differently today for e-business.

A surprising small but growing number actually benefit more from
distributed application models that allow either end to be a client or
server
based on a business event ( eg automated applications that synchronize
with each other over the web ).  This clearly is NOT the common scenario
now
but one which has very high value in some customer situations....
Applets and distributed Java applications do this well...
Java 2 offers real opportunities for effective distributed applications
without
traditional install problems and much less communication overhead than
the applets in JDK 1.1x.

My experience is very different than most of the AS/400 community today
for web applications.  I've built some large transaction based applications
that leverage SQL and DB2 very well for distributed environments
including the web and client / server.  In those situations, real SQL
database
access for both data and transactions has worked very well for 
development cost, functionality and performance.

Somehow the importance of remote SQL access for e-business has been
overlooked by the majority of the AS/400 community including vendors.
Many vendors have spent tons of $$$$ building custom connectors that
replicate the functions available in DB2 for remote access...

Tools can automate the building of SQL data and transaction access.
The database framework in many cases lowers development costs when
compared with frameworks like record level access in the AS/400 toolkit,
the program call class etc....

That's my 2 cents...

It would be interesting to hear more experiences....

Jim Mason



Message text written by INTERNET:JAVA400-L@midrange.com
>

There have been some interesting comments on the board of late, and I
thought perhaps it was time to jump in and get some discussion going.

First, to my mind, is the issue of architecture.  Up until fairly recently,
I pretty much had centered on three basic architectures:


Thick Client - Client/Server (TCCS):

A thick client on the PC would make requests to a server on the AS/400.
The application logic and user interface are all on the PC, while the
business logic is on the host.  I like this architecture best when creating
highly graphical desktop integration products.  For example, an MRP inquiry
screen that could easily be "dragged and dropped" to an Excel spreadsheet.

Browser Client - Client/Server (BCCS):

Here we have a browser talking to a servlet, which in turn makes calls to
HLL servers on the host.  I prefer this architecture when creating
brand-new browser-based versions of traditional applications, such as most
ERP applications.  File maintenance, reports and inquiries all fit quite
nicely into this model.

Browser Client - Server/Client (BCSC):

When going thin client (that is, browser-based), I like the server/client
approach.  I use a servlet/JSP combination to emulate the 5250 display,
then put API calls into the existing green-screen application in place of
the original I/O opcodes like EXFMT.  This is the approach I use for
revitalization (or "modernization") of existing legacy systems.  That's
what I give away for free at http://www.zappie.net/revitalization, and what
Jacada is selling for $10,000 a pop.


So there you have three basic architectures.  I've left out the other
combination of the above architectures, namely thick client server/client
(TCSC).  While I haven't done much work with it yet, TCSC is important when
trying to directly integrate your existing legacy systems with desktop
applications, such as standalone data collection systems.  The fact that
all of these architectures are viable, and the fact that they may need to
be expanded (for instance, to WML), almost cries out for a common midpoint.
Which is why my next direction is probably to use XML as the interface
between the client code and server code.

What else have I left out?  Applets, SQL and EJB.  Here is my reasoning:

Applets I still don't like because of bandwidth issues.  I don't hear about
a lot of successful applet-based systems these days.  While they may be
great for a limited number of user interface panels, I somehow don't think
the typical ERP system with hundreds of screens is going to translate
nicely to applets (unless we have a very flexible applet that can handle
any of the screens, but that's a completely different architecture to be
investigated another day).

I have yet to hear a good argument for using SQL as a transaction
processing language.  I love SQL for adhoc user queries, but its syntax and
the high level of binding (at the column and table level) between the
client and and the host database make SQL unsuitable for flexible
distributed application, in my estimation.

And finally there's EJB.  Love the concept, gotta see it working before I
jump on the bandwagon.  I just got V4R4 running, so I'll try to get
WebSphere 3.02 going and see if I can do some EJB work.  However, it's
pretty low on my priority list at this point.  I'd love to hear how other
people have reacted to it.

There are other architectures.  One that particularly intrigues me these
days is the PC-based task server.  In this environment, certain
high-intensity tasks (such as converting spool files to PDFs!) could be
shipped off to a PC, which would then process the data and send the result
back to either the host or forward it directly on to the user.  Offloading
the AS/400 this way could greatly increase the AS/400's throughput for
database serving, which is its forte, anwyay.


How about that for some food for thought?  Which architectures do you see
as useful?  Which do you see as useless?  Which do you see as critical?
Let's do a little brainstorming here.


Joe Pluta
www.java400.net
www.plutabrothers.com

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---
<

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.