[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] UBL payload and client-server integration tools
David Lyon, With respect to your view that "computers are a lot faster today ...latency is not a real problem now," that is not the perspective of today's RIA designers. They are at risk of being crunched between two opposing forces, limits of IT infrastructure "supply" and user "demand." RIA designers need to fight for every millisecond reduction in response time budget to offset infrastructure limits. Their RIA transaction-oriented applications are contesting for client, server, firewall, and network resources against new or growing services such as VOIP, IPTV, sensor inputs and "chat." Indeed, XMPP(jabber)is more likely to be an enemy rather than a friend to business-transaction-oriented RIA. Enterprise internal networks often have less available headroom than the Internet and may have been engineered more for throughput than response time optimization. With respect to demand, your quote "Speed is, like Einstein said, relative," is apropos. Speed is relative to user think time and expectations, and there are quite predictable user perceptions regarding what is "sluggish" response time. The RIA designer has to accommodate user perception, even if the user is in a branch office or is using cellular data service (e.g., EV-DO). Given the crunch between supply and demand, within the RIA world, there is something an XML backlash, because of its overhead. For example, below is an advisory from an RIA tools oriented site: "The benefit of electing the "return XML" option is "...a nice, clean, standardized interface on the server..." Well, it is good that RIA developers recognize the benefits of XML and standardization. Unfortunately, the advisory continues with the response time downside: "As an example, JavaScript has no good high-level support for [XML parsing], so you will need to traverse a DOM tree to extract the data you need - probably translating it into some intermediate JavaScript data structures in the process. Two or more passes over the same data does not a snappy application make, and your performance may suffer from this approach." http://dojo.jot.com/RemoteScriptingRevisited Judged from an RIA perspective, a typical UBL transaction is a giant clot of text to be either parsed or generated. At the same time, as the RIA developer jettisons what looks like overhead, the result probably will be a transaction that is not only non-standard, but in many cases not fit for purpose. IP built into the standard (e.g., what currency is involved in the transaction, what tax domain) will be forgotten. Note that, network and server-side considerations may be even more important than client-side parsing, so scripting limitations are just the "usual suspect." We can of course leave the client-server RIA designers to their own devices, but what I have been looking to accomplish is to see if there is a way of working within their performance framework, while preserving the essential value proposition of UBL. Fulton Wilcox Colts Neck Solutions LLC -----Original Message----- From: david.lyon@preisshare.net [mailto:david.lyon@preisshare.net] Sent: Monday, November 13, 2006 6:49 PM To: ubl-dev@lists.oasis-open.org Subject: RE: [ubl-dev] UBL payload and client-server integration tools Quoting Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>: > One further point with respect to "light" is that it is extremely difficult > to "buy" latency reduction. Internet 2.0 "mashups" (front end, often client > side applications that depend in invoking multiple applications, services > and databases) have very constrained response time budgets, so they must be > built for speed. Indeed, many client-server applications of the 1990's > (which themselves often were "mashups") often had sluggish performance > because they were built for "richness" rather than speed. That was then, this is now. Computers are a lot faster. Everything has changed since those days. Latency is not a real problem now. Stuff like XMPP protocols deliver instance presence anywhere around the globe. Along with any XML payload. Speed is, like Einstein said, relative. Regards David --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]