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