|
Chuck I've looked at different iSeries legacy application and the available options for integrating those apps to the web and the good news is that there are several excellent ways to bring legacy applications to the web , integrate to a unified corporate system and give legacy development teams a way to keep in synch with the new technologies. We looked mainly at two different methodologies here, screen scraping and migrating. Screen scraping offers a way to extend green screen systems to the web and then manipulate the inputs and outputs like a database (think Jacada). Migrating means taking those green screens and converting them to JSPs and Java using a conversion tool without modifying the underlying applicaiton. Websphere webfacing is recommended not only because it costs less than screenscraping, has a shorter development time and runs faster but also because it opens a path to migrate out of your legacy solution in an iterative process that can match the businss pace. For instance, once you have webfaced you can take the generated code and add your own JSP custom tag library (read:incorporate corporate design easily), connect to other databases, make on screen mods, change the underlying code with java calls etc. Importantly webfacing fits most enterprise strategies by keeping the data and business rules more closely aligned, leverages existing assets and is a step towards a single enterprise solution. As a technology that uses Java and websphere, it's a migration, not another layer and you already own the tool to do it. Webfacing is, as such, an iterative migration process that will open your iSeries to one of its strongest asset - web serving and will leverage your already considerable investment in that system. Yes, its astounding how we still use the iSeries like it's an old jalopy, but as you start tinkering with websphere and webfacing, the possibilities to provide your customers with superior solutions becomes more and more apparent and the results will be obvious. One of the best benefits of webfacing is that it works out of the box. You could have all your users on the web tomorrow. OK, that's an exageration in reality- as your users might want to be trained, some keywords need reconfiguring etc. but it is true that it works straight out of the box and you can then modify those screens to change the order of the fields,styles, insert combo boxes, radio buttons with little or no training. I'll address some of the issues below. But the short answer to your questions: 1. You don't absolutely need a consultant - give yourself the gift of knowledge by doing it yourself. If you need to bring in a consultant to answer all your questions, make sure they are a java, oo, WAS, WSAD (studio), IBM Toolbox guru and can deconstruct the generated code from webfacing - not just someone who knows how to do webfacing (that can be learned in an afternoon). 2. Read "The IBM Webfacing Tool" to show you how to webface. see http://www-1.ibm.com/servers/enable/site/ebiz/webfacing/start.html for more Webfacing resources 3 Put your free copy of Websphere Studio on every developer's desktop and go through the tutorials 4. Start a path to transform your developers into a Java and OO team. Give yourself a year. Bring in a training company that will help you make the transition over a period of time, e.g. One class every quarter with workshops in between. THE IRONIC THING. Webfacing scares many and many more think it's too good to be true. This is why you may have a hard time convincing senior management that they don't have to go out and spend a $100K on a third party package. The sales teams from vendors will come up with a million reasons to buy their product. Worse, by choosing an inhouse solution you are putting all the risk on your plate. We all know about corporate insecurity - there is that unspoken assumption that another company can do a better job than you can. I encourage you to ask around and get other's experiences - my experience that inhouse web transformation of legacy apps through webfacing works and works exceedingly well in a number of configurations. We have our legacy apps on our iseries, the webfacing code running on an AIX Websphere App server in another city talking to those legacy apps with our static content from another server. That's about as complicated as a scenario as you can find - but it all runs very smoothly. We did upgrade our old 700 box though for performance (see below). SOME ARGUMENTS Read the excellent article by ted jensen 'TOP TEN THINGS TO HATE ABOUT WEBFACING - and its response at http://www.acsltd.com/Web/cmshome.nsf/attachmentweb/MGLY-5KHK9X/$file/Top+Ten+Things+To+Hate+About+WebFacing.pdf?OpenElement SCREEN SCRAPING METHODOLOGIES Let me address the screenscrapers like Jacada. The irony of purchasing a screenscraping solution is that the very product that brings legacy applications to the web is the same product that also locks you back INTO your legacy apps. Screenscrapers generally needs your legacy system in a fossilized state in order for it to work. Additionaly when you DO make changes to the legacy app you're faced with a triple maintenance assault on resources. The legacy engine, the screenscraper middleware and the front end that uses it. Screen Bunching Argument. Some people comment that Webfacing locks people into a single screen by screen replication of your legacy whereas screenscrapers and others can bunch several screens together.The simple answer is No - WSAD 5.1 allows bunching. The screen bunching thing is a bit of a red herring anyway. Vendors says their product an bunch screens together, but only where there is a real redunancy in the input process. I question how it would be able to bunch on screens depend on a previous choice or database update. For example, if you enter data into screen A and depending on what you enter then either B, C or screen D will appear next. Now regardless of how you makewhat they call' trails; in screen scrapers, If screen B popping up depends on whay data being added to a table on screen A, then you simply can't enter data into A and B at the same time. You can make a trail of it, one can't happen without another input from the user. Screenscrapers add layers. At first glance, tools from other vendors appear to be a feature rich, impressive screenscraping tool, however once faced with all this middleware in between the user and busines engine then it begins to look more like lumbering,expensive wedge from which once attached may be quite difficultt to extricate yourself from. Webfacing is a lean and mean solution which will migrate legacy apps to the web in a controllable, extensible way. YOU MAY NEED TO UPGRADE Upgrading your iSeries If you don't have a powerful enough machine, you will need to upgrade your iSeries - Nothing is faster than a green screen. It's a fact of life. If you put Websphere App server on the iSeries, expect reduced response time. However subsecond response time is still possible. - Web access requires more processing power, memory and L2 Cache. This is true regardless of the method used to bring the application to the web. Your current configuration will impact users through a noticeable degradation in response time. - A minimum CPW (transaction power) of 1000 is recommended for WebSphere application server. - Workload analysis typically shows a minimum DASD requirement of 175 GB (yours may vary) - The WebFacing Server must reside on the iSeries causing a heavier workload. Webssphere Application Server can reside anywhere but if it is on your iSeries expect a chunk of resources eaten up. - Increased transactions and heavier demands need to be accommodated. If you're going to the web, expect more users. - iSeries will continue to return a better Total Cost of Ownership than comparable Windows or Unix servers but machine cost is higher if you are thinking of going to another machine altogether. - The upgrade will put you in a strong position to leverage the system's excellent web development and deployment capabilities and free you from legacy applications with better resources to iteratively migrate to Java. - if you go for the zero CPW option you can get a super fast high end iSeries at a savings from 30-150K. Zero CPW means you can not have any green screens active anymore. That's my two cents - don't take my word for it. There are extensive chats on this forum about webfacing - check them out for other people's opinions. Regards Colm Byrne Senior Developer web400-request@xxxxxxxxxxxx@midrange.com on 01/17/2004 01:00:25 PM Please respond to web400@xxxxxxxxxxxx Sent by: web400-bounces@xxxxxxxxxxxx To: web400@xxxxxxxxxxxx cc: Subject: WEB400 Digest, Vol 2, Issue 15 Send WEB400 mailing list submissions to web400@xxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://lists.midrange.com/mailman/listinfo/web400 or, via email, send a message with subject or body 'help' to web400-request@xxxxxxxxxxxx You can reach the person managing the list at web400-owner@xxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of WEB400 digest..." Today's Topics: 1. RE: webfacing JD Edwards (Eric Kempter) ---------------------------------------------------------------------- message: 1 date: Fri, 16 Jan 2004 14:24:28 -0800 from: "Eric Kempter" <EKempter@xxxxxxxxxxxxxxx> subject: RE: [WEB400] webfacing JD Edwards Chuck, You may want to post your question on the jdedwards forum / mailing list at http://www.jdelist.com/forums. -----Original Message----- From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Chuck Bower Sent: Wednesday, January 14, 2004 6:14 AM To: web400@xxxxxxxxxxxx Subject: [WEB400] webfacing JD Edwards For the group: Is anyone running a webfacing application in JD Edwards, or the whole JDE application webfaced? If so, did you do it yourselves, or have it done by a consultant? What webfacing application did you use? How did you evaluate webfacing apps if you are not using Websphere webfacing? On a side note, has there ever been a survey done to get an idea of how many companies are using Websphere webfacing vs.. a 3rd party product? Chuck Bower _______________________________________________ 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) digest 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. End of WEB400 Digest, Vol 2, Issue 15 *************************************
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.