|
Wow...very nice explanation...thanks. On Tue, 11 May 2004 17:00:30 -0400, "Buck Calabro" <buck.calabro@xxxxxxxxxxxx> said: > > Web-Facing is simply a process of building/converting > > a Graphical User Interface (GUI) on top of a > > new or existing business application. > > The term 'web-facing' and its ilk has been adopted by who knows how > many people as a generic term meaning 'uses a web UI.' This is all > too often confused with the IBM product called WebFacing which is part > of WDSCi. It reads the DDS source and creates Java servlets and jsp > pages for deployment on WAS or Tomcat. > > JWalk is a screen scraper, which is a process of reading the 5250 data > stream and interpreting the look & feel based on what it sees. > Neither WebFacing nor JWalk change the underlying RPG programs which > make up the application, but at least WebFacing uses industry standard > Java to create its UI. > > Why is this important? With IBM's WebFacing, you can convert your > application once, and re-use the converted components (JSP, servlets, > classes) in your own design. You've already deployed WAS and Apache > and have literally all the infrastructure you need to add brand new > servlets to the application. > > With a screen scraper, you get none of that and you are 'locked in' to > their solution. You can't incrementally add to your existing deployed > web code base because you haven't got any. When you want to make a > change, you must go back to the DDS and make your changes there. > Modern screen scrapers all have some way to customise the look of a > screen, which often means that once you've changed the DDS you have to > revisit the 'customiser' and make the GUI panel look good again. > > What to choose? It all boils down to the reason you are contemplating > a web UI. If you don't want to pay for a leased line and want the new > office in Guatemala to access your app via a browser, you have a > different set of criteria and problems than if you are trying to use > Java because it meshes with the corporate goal of interoperability > with some other vendor's application, which in turn is a different > problem than being an ISV who needs the cachet of a web based product > in order to make sales. > > In general, the screen scrapers are very easy to use and deploy, but > they have quirks in their recognition engines which are 'customised' > so the panels look good. There's often a double maintenance penalty > (DDS and customiser) but since everybody knows DDS already it isn't > seen as that big a deal. Scrapers often don't need source code, and > handle IBM panels like WRKSPLF. > > The re-facing crowd often require source, and often make changes to > it. Almost invariably, those changes can be reused to enhance the > application in the future. Because they use source, they don't have > to make a guess about what the panel should look like, and thus have > fewer glitches in the recognition engine. > > If your company wants to go to the web in a real way (learn Java, > learn web infrastructure, good change management) then choose one of > the re-facing products (PSC or WebFacing come to mind). If you aren't > going to invest the effort in becoming web experts, then choose a > scraper (JWalk, Newlook and I think aXes fall into this category.) > --buck > > > > _______________________________________________ > 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. > -- michaelr_41@xxxxxxxxxxxxxx -- http://www.fastmail.fm - The professional email service
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.