RE: [ubl-dev] UBL payload and client-server integration tools

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

David,

In response to your question "que?" regarding the implications of internal
network limitations on Internet 2 mashups:

I originally said:

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 this point, you responded:

que?

My further response:

Enterprise internal networks often (or even typically) already are stressed
and are not well positioned to support Internet 2.0 demands. Many
enterprises are laggard in buying more and better hardware (servers,
routers, etc.) and more bandwidth, but even those who do end up fighting
latency.

The current reality is, to quote from a recent Intel white paper, "We have
speed, but we're not getting anywhere fast...If we have gigabit ... pipes,
and faster processors, why are our servers so sluggish?

The answer offered by Intel is latency resulting from performance mismatches
between components - e.g., "processor speeds have outstripped memory
throughput by nearly a factor of 10," while network speed increases
(especially LANs) have outpaced Moore's Law. As a consequence, queues build
up in front of lower performing components, while high performing components
merely idle.

Needless to say, Intel, like Riverbed, Citrix, Cisco, and many others offer
various "network acceleration" solutions. For example, the typical Riverbed
success story is that putting its appliances at each end of a link cuts
chattiness and increases throughput by some large double-digit percentage.
On the other hand, "network acceleration" is still an "early days" market
and most enterprise networked are yet to be accelerated.

For many Flash Internet 1.0 applications, unfavorable network latency often
does not adversely impact user perception, because the application can
buffer, prefetch, etc. On the other hand, a client-server Internet 2.0
application in which a user is, for example, doing receiving against (one
can hope) UBL-conformant purchase orders gets the Flash developer into
delay-sensitive reads and writes, in which case latency is a user
satisfier/dissatisfier.

In suggesting (as I do) that Internet 2 developers use UBL artifacts, there
is a need to do the Darwinian thing and adapt them to the environment.


						Fulton Wilcox
						Colts Neck Solutions LLC





-----Original Message-----
From: david.lyon@preisshare.net [mailto:david.lyon@preisshare.net] 
Sent: Tuesday, November 14, 2006 11:20 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>:

> RIA designers need to fight for every millisecond reduction in response
time
> budget to offset infrastructure limits.

well invite them over for discussion..

> Indeed, XMPP(jabber)is more likely to be an enemy rather than a
> friend to business-transaction-oriented RIA.

oh bah humbug...

> Enterprise internal networks
> often have less available headroom than the Internet and may have been
> engineered more for throughput than response time optimization.

que?

> 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.

I hear it all the time from stockbrockers complaining about how slow  
the systems are. Take away their computers and give them back a  
telephone, pen and paper... see what happens.

> 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).

So what. Users complain every day.

> 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:

yup - not surprised.

> Judged from an RIA perspective, a typical UBL transaction is a giant clot
of
> text to be either parsed or generated.

yeah? we have tens of thousands of ublish purchase-orders and they all  
pretty small.

> 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.

That is my philosophy also.

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