yeah, man...I hear ya. I have already discussed this with the system owners and they think I have been given a wild-goose chase by marginally technically competent people.
ouch -----Original Message----- From: Sherman, Dennis (END-CHI) [mailto:[EMAIL PROTECTED] Sent: Friday, May 14, 2004 4:20 PM To: '[EMAIL PROTECTED]' Subject: RE: Project from hell? When you go from 10,000 ft. to 30,000 ft. to 50,000 ft., things look simpler and simpler... :-) I don't (yet) think your task is impossible -- but I do think you need to better define what your task *is*. If the task is "use web services so we can say we did it", that's one thing. But as I noted earlier, if you've got user sites with telecom issues that prevent them from periodically updating local db copies, users at that site are going to scream when the telecom issues prevent them from getting to the centralized service, no matter whether you've got web services, servlets, applets, JWS, Struts, telnet, or anything else behind the covers. The general architecture of presentation <-> servlet(Struts) <-> web service <-> repository seems quite reasonable, overall. But you're assuming network availability on demand all the way from presentation to repository. Given your description of the global environment in which this needs to work, I'd worry about that. If I were in your shoes, I'd be digging in to what is the real goal of the project * use web services because we can * speed up client response time * remove the need to propagate data repository copies * use centralized user authentication * or whatever Web services are appropriate for some goals, and irrelevant for others. -- Dennis R. Sherman Endeavor Information Systems 847-227-2976 [EMAIL PROTECTED] http://www.endinfosys.com -----Original Message----- From: Galbreath, Mark A [mailto:[EMAIL PROTECTED] Sent: Friday, May 14, 2004 3:06 PM To: '[EMAIL PROTECTED]' Subject: RE: Project from hell? so...you feel my pain.... My idea is to remove the applet functionality to a Struts framework. The framework would handle the back-and-forth between the client and the Web service. Am I being too simplistic? Personally, I think I have been given an impossible task. Mark -----Original Message----- From: Dennis Sosnoski [mailto:[EMAIL PROTECTED] Sent: Friday, May 14, 2004 3:54 PM To: [EMAIL PROTECTED] Subject: Re: Project from hell? Galbreath, Mark A wrote: >EXACTOMUDO! :-( > >-----Original Message----- >From: Sherman, Dennis (END-CHI) [mailto:[EMAIL PROTECTED] >Sent: Friday, May 14, 2004 9:12 AM > >Your task sounds to me suspiciously like someone at an executive level >having heard about web services, and thinking they've found the silver >bullet to all their problems. > > Then you've got two choices I'd see as reasonable. The first is to use an actual web service, with the clients converted from applets to standalone applications (perhaps deployed using JWS, a great solution). You could use JMS or SMTP for the actual web services, to get the queuing advantages you said were important. This should let you preserve much of the UI and avoid a total rewrite. The second alternative is to either modify your existing applet-based code or design a pure HTML approach that talks to servlets, with the servlets implementing queuing behind the scenes. I don't know how much this would help with your basic problems, though. Using an applet based frontend for web services is possible, but really only makes sense if you've already got a web service that you just want to access from the applet - I really wouldn't recommend this as an up-front design. - Dennis -- Dennis M. Sosnoski Enterprise Java, XML, and Web Services Training and Consulting http://www.sosnoski.com Redmond, WA 425.885.7197
<<application/ms-tnef>>
