[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: RE: Traditional RPC
Do you really think the average office worker knows what the <!DOCTYPE at the top of an HTML file is for? I don't. OTOH, they don't code them. They make others do it for them. 1. The average office worker still hides behind FrontPage and it's ilk. Having spent a lot of time a week ago rebuilding several FP enabled pages and closing security holes (ODBC strings in .htms?????), I can say it wasn't too hard to do it right the first time, but these folks were career-oriented, got what they wanted, moved on to bigger and better, and left a mess behind. One reason I dig into these issues is a real-world awareness that the mess lands on my desk. 2. It is interesting to take a look at the MS pages on web services with their animation of how Visual Studio, VBA etc., will support discovery and integration. It glosses over the right to use these services, how to pay for them, the contract bits, but it looks about like what a VBA programmer is used to. Let's be honest: it isn't just programmers (the pure, the mighty, the powerful, the knowledgeable) vs everyone else (the slothful, the ignorant, the spoiled, the needy). Most web programming above the level of core technology is object scripting and that includes HTML (particularly HTML). The model the MS pages show is the model many scripters know. I have to think that is a key reason: ease of integration into VBA and the toolkits that support it and languages like it (Javascript). Point: it would be nice to get this right. Legacy builds fast and there are dimensions of that that extend into the organization, the habits of the humans, and the performance of both. I don't like to clean up the messes of the politically correct or the wild-eyed individuals. (somewhere between objectivism and vedantic beliefs, there must be a middle ground better than "do the right things for the right reasons", but I'm danged if I know what that is). Scalability worries me. Treating a WAN like a LAN worries me. Getting the scripters to not code too close the process of an individual desktop worries me. On the other hand, reliance on a global namespace has its perils too. The issue today is edge system integration; not understanding the philosophy of URI. That is corrupt on the face of it; it conveniently "webs" but the namespace as URI is corrosive. The Web Way doesn't worry me. The Web doesn't exist. Parts and assemblies exist. After that, what works had better work for long enough to get ROI. My intuition is that that is what the WSIO is about: code on the loading docks. len From: Mike Champion [mailto:mc@x...] 2/18/2002 10:03:40 AM, "Bullard, Claude L (Len)" <clbullar@i...> wrote: >So Why Traditional RPC? Why Web Services per UDDI/WSDL/SOAP? I didn't think there was much dispute -- this is the programming way, the CORBA and DCOM way, to access remote applications. It works well on LANs, so there's a solid base of experience to draw on that you can hide the network behind an RPC. It makes a lot of intuitive sense -- SOAP-RPC as a neutral wire format, WSDL as a neutral IDL, UDDI as a directory service. It has a plausible business model: vendors compete on ease of use and quality of implementation rather than on basic protocols. I can agree with the REST people that it's not "the Web way", that it forces a reinvention of things that the Web already supplies, and that it may not scale to the web as it really exists... but I understand why the Web Services people chose the "programming way" and treat the Web as simply a giant LAN. We shall see if it works out that way. I'll predict that both win: Traditional RPC really is the easiest way for programmers, and will work well enough behind firewalls and between established partners and in arenas where user simplicity matters more than system reliability (e.g., for Userland's typical customer, AFAIK). But now matter how fast the Internet that we know today improves latency, reliability, security, etc., it will be extended geographically and to smaller and more mobile devices,continually opening more niches where the REST paradigm shines. The only "REST rules, RPC drools" scenario I can imagine, i.e. that would make the WS tool vendors' inital focus on RPC ill-considered, is if the non-programmers somehow grok REST big time and find it an easy migration path from what they do now to the Wonderful World of Web Services. It's more likely than assuming they will learn to think like a programmer, no? Will non-programmers build and use web services? Maybe not, but who would have thought 10 years ago that the average student, office worker, etc. would have a basic knowledge of a markup langugage (HTML) today?
|
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
|