[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Wasting half a trillion dollars?
Umm... that is pretty much what we are doing (actual deployment): 1. Browser-based apps for external systems that need less features and less performance. 2. Fat-client, stateful systems with industrial database servers for the internal systems. There is actually less and less discussion of migrating these any time soon. Cooler heads are prevailing. 3. Means to feed item one from item two without exposing item two to unwarranted security risks. XML is great for this. XML is showing up more and more as was predicted in the interfaces among otherwise encapsulated systems. The rest is resource management. We don't see Java in the picture much here. We don't usually need it. Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Charles Reitzel [mailto:creitzel@m...] I think one needs to look at actual deployment and use cases to get a good handle on where the ERP apps are going with browser based solutions. A few facts: 1) The bread and butter is still in the fat client. That's where the installed base is. It takes years to migrate these things (hardware and software upgrades, training costs, contingency planning, etc.). 2) Although desktop management tools have improved, the fat client is still very expensive to maintain. To quote Dave Barry, "I am not making this up." And, yes, last I checked, even the non-profits want to reduce overhead. This is all definitely overhead. Folks will look hard at web based solutions for new applications or new use cases. 3) Not all users use all the features of these application suites. The classic example of where it pays to do something on the browser is self-help 401K and health plan applications. Only folks in HR need the full functionality, decidedly fat client. If you can avoid many of the aforementioned costs with a web deployment - and you can - many will pay additional development costs and sacrifice some usability. So fine, give 50 people in 5 offices the full, native GUI interface. Give 5000 people in 50 offices the limited web interface. 4) Java applets and Active-X can fill in some of the blanks. In the Content Management space, I have recently seen a few products successfully use either Java applets or COM controls in IE to provide something resembling a GUI. For example, Interwoven has a decent XML instance document editor implemented as a Java applet. I saw another that provides some basic HTML formatting (Bold, Bullet, etc.) in a text entry form via Active-X. It can be made to work for certain key pieces. The rest is HTML + Javascript dogfood in front of the same app server as the fat client. Altogether - not pretty, but not terrible either. A separate, compelling argument for web based solutions is extranets. This is a done thing for supply chain, purchasing, etc., etc. Web base apps do make inter-organization integration (say that 3 times fast) easier technologically. Finally, there are a bunch of plain socket apps out there. These tend to be easily ported between Win32 and Unixen. So your <simplisticSolution> has been around for a while now. Indeed, the basic interoperability of TCP/IP and other web protocols is perhaps the greatest reason why Linux has done so very well. I don't think we are really talking about fat or thin clients. A browser is pretty darned fat. I think we are really talking about dynamic code deployment and update - preferably portable. So far, Java is winning this game, with Javascript coming in second. The only other contender, client-side XML, isn't really happening yet.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|