Making Web Services Work- Performance Isn't Optional–Interview with Richard Campbell [3:42m]: Play Now | Play in Popup | Download

 

 Making Web Services Work- Performance Isn't Optional–Interview with Richard Campbell [3:22m]: Play Now | Play in Popup | Download

Greetings WOW members and Web professionals everywhere. Bill Cullifer here with the World Organization of Webmasters (WOW) and the WOW Technology Minute.

Today’s podcast is a continuation of the media coverage of Web Builder Conference, Las Vegas. If you’ve been following along with the series, then you know I sat in on a variety of great sessions covering the world of Web Development. I also had the pleasure of interviewing a number of speakers including Richard Campbell Product Evangelist Strangeloop Network based in Vancouver, British Columbia. Richard presented on the topic of “Performance Isn’t Optional Making Web Services Work”.

Often the motivation for bringing web services into the enterprise is not performance - its about interoperability. But performance is not optional, without performance, interoperability becomes an exercise in frustration. Richard’s session dug into the strategies that an architect can employ in the design web services so that performance is a feature of web services, rather than an obstacle.

Check out the three minute interview on today’s WOW Technology Minute website.

Today’s WOW Technology Minute is brought to you by WebProtraining.org, offering a complete solution for all your Web professional training needs including WOW certification options. Check it out at Web Professional Training website.

Transcript of Making Web Services Work-Performance Isn’t Optional–Interview with Richard Campbell

BILL CULLIFER: Bill Cullifer here with the World Organization of Webmasters (WOW) and the WOW Technology Minute at Web Builder 2.0 Las Vegas. I have the pleasure of interviewing Richard Campbell, Product Evangelist at Strangeloop Networks out of Vancouver, BC. Good morning, Richard. Excellent presentation today on “Performance Isn’t Optional, Making Web Services Work.” Can you summarize that session for us?

RICHARD CAMPBELL: Sure. Web Services are usually built mostly for interoperability. Folks are really focused on what does it take to get all of my different disparate systems working together and the Web services are the lowest common denominator. It’s not a really performant protocol. Often it tests well, because we don’t have a lot of requests running at once and we’re inside that nice, fast LAN connection and Web Services often end up being bigger than they thought, the packages come back much larger than they thought and requested a lot more. Often these interoperability exercises are really successful and they have apps that are in high demand because they work across all those different systems.

This talk really came from my experiences as a consultant dealing with these companies that get caught by surprise. Really it came from their own success. I cited a particular case where a client went from maybe 10,000 requests a day off of mainframe when they wrapped it in Web Services it jumped up to 750,000 requests a day and it was just burying the machine. It turned out that those requests were almost all identical, so by adding a caching layer in we were able to take a lot of stress off that server in a big hurry. The net effect ultimately is that they didn’t have to upgrade their mainframes or rewrite any systems. Understanding where they performance problem is, is the biggest challenge.

A great deal of the talk that I just did here was really about, what do we instrument, where do we instrument, because most people don’t understand where their Web Service pain is coming from. They’re looking at the far end, at that consumer end, and saying, “This site’s too slow.” As the owners of that product we have to dig in deeper and say, “Well where are we too slow?” One of the big whammies I see with Web Services over and over again is that requests end up coming back as much too large; they’re marshalling megabytes of data and they didn’t really need it. It’s just that it hasn’t been thought through enough to be efficient.

BILL: Yeah. Well said. You had a couple of specific walk-aways too. For example, for the listeners of this podcast or developers out in the world, what would you like us to walk away with?

RICHARD: Really there’s a couple of elements we talked to. I talked to the performance equation, which really decomposed our overall request time. It looked at the payload and the bandwidth but we also broke out, what’s our latency like? Are we dealing with a long-range communication here? Do we have problems with connection speeds? And also separating out the time it takes for the server to compute it and the time it takes for the client to compute it.

One of the pains we get in with Web Services is really we’re translating binary data into text, then we’re translating it back again. That marshalling overhead is expensive. It takes a long time. And it’s one of those hidden penalties to Web Services. So one of the suggestions I made, and there was a variety of them, not only tricks around cache and doing work once and taking only the data we really need, but do we really need a Web Service here? If we have a really popular app, could we go to a more performant protocol? Does it make sense for this scenario? I know that Web Services are a good choice overall, and I’ll leave that layer in place so that it’s very compatible and works with everything, but for a particular app we might find that it’s worth making the S and A call, just skip over all that translation. Or maybe we’re calling out to java and we’ll use a java interoperability layer for it. That’s the choice we can make. It makes sense once we’ve properly instrumented the column and once we’ve properly diagnosed it, this is the issue, that it’s the marshalling or it’s the time it takes to translate that data back and forth, that we can eliminate those pieces.

BILL: Yeah. Great summary and excellent walk-aways. We appreciate that.

RICHARD: My pleasure. Anytime.

 

 Fundamental Progressive Enhancement-Interview with Aaron Gustafson [3:42m]: Play Now | Play in Popup | Download

 

 Fundamental Progressive Enhancement-Interview with Aaron Gustafson: Play Now | Play in Popup | Download

Greetings WOW members and Web professionals everywhere. Bill Cullifer here with the World Organization of Webmasters (WOW) and the WOW Technology Minute.

Today’s podcast is a continuation of the media coverage of Web Builder Conference that took place in Las Vegas earlier this month. I had the pleasure to sit down with Aaron Gustafson, Founder and Principal Easy! Designs LLC, based in Tennessee.

I asked Aaron to summarize his two sessions: Web Standards: Fueling Innovation and. Fundamental Progressive Enhancement.

Web standards are all about rules and structure, formalities that many people find restrictive and stifling. From another perspective, however, the rigid structure of Web standards can be seen as a boon to creativity on the Web. In this session, Aaron talks about how to use smart JavaScript to leverage the extensibility of XHTML and CSS and push the boundaries of Web design and development, all while still adhering to the best practices of Web standards.

Aaron also covered the current best practice in Web standards development: progressive enhancement and the best ways to apply style and behavior to your pages, providing concrete examples and implementations that you can start using right away.

Check out the three minute interview on today’s WOW Technology Minute website.

Today’s podcast is sponsored by the Webmaster Survival Guide. Check out all of the great resources and links on the Webmaster Survival Guide

Transcript of Fundamental Progressive Enhancement-Interview with Aaron Gustafson

BILL CULLIFER: Bill Cullifer here with the World Organization of Webmasters (WOW) and the WOW Technology Minute with Aaron Gustafson, a supporter of WOW for a number of years. Aaron, we’re here at Web Builder 2.0 Las Vegas. You presented a couple of sessions. I’m curious if you could summarize those sessions for the subscribers of this podcast and provide us a couple of walk-aways that we can use as well.

AARON GUSTAFSON: OK. The second session I did was Fundamentals of Progressive Enhancement, which talks about the content-added approach of progressive enhancement verses graceful degradation which used to focus on making sure that sites degraded gracefully. Older browsers, they provided a worse experience that was expected, essentially, as you got older and older browsers. Progressive enhancement looks at it from a content-out standpoint and aims to improve the experience of users based on the capabilities of their browsers as opposed to looking at it the other way around.

They’re really two sides of the same coin, the same general purpose of making sure that people get the best experience they can possibly have and that nobody’s left behind. But progressive enhancement I think of as more of a positive spin on it as opposed to progressive degradation which assumes the worst for some people. And progressive enhancement really focuses on content, which is obviously the most important thing when you’re dealing with semantic HTML. So that was the second session that I did.

The first session that I did actually was about innovation on the Web and how the W3C really hasn’t been a great source of innovation for us over the last eight years. They really haven’t innovated on XHTML very much at all since HTML, for one which really wasn’t all that much of a departure from 3.2. We saw a much steeper increase of innovation in HTML back in 1 to 2 shift and 2 to the draft of 3. Three itself actually looked like it was going to be a great spec if it had ever really been released but then they dropped it backward, HTML 3.2 they actually cut out a ton of stuff. And HTML 5 is still on the horizon and we don’t have that yet.

So it was essentially a session to look at the problems we have, that baseline problem. How can we address that problem and really be the change that we want on the Web, be the innovation that we need in order to accomplish what we were trying to do on the Web and taking the fundamental stuff that’s available to us in these standards like XHTML and CSS and being able to extend upon those, either via extensions to XHTML with new elements or new attributes to accomplish certain functions using modular XHTML possibly or just rewriting or adding on to an existing DTD or using CSS using vendor-specific extensions? Instead of just leaving the vendors to do vendor-specific extensions actually creating our own vendor-specific extensions and then utilizing java script in a progressively enhanced way to make whatever it is that we need to have happen out of that particular code. So that was a little bit more of a heady talk about interesting things that we could do, hopefully it inspired a few people.

BILL: Yeah, good stuff. I appreciate that. I’m curious to know, you have a couple of resources, can we throw some links up for subscribers?

AARON: Yeah. People can take a look at all of the slides from the two sessions this week on Slide Share, that’s Aaron’s Slides. All the slides are available there. They can download them, they can view them in their browser, wherever they want. All of that will be freely available.

BILL: Excellent. Thank you so much Aaron.

AARON: No problem.

BILL: And thank you for all that you do for the profession.

AARON: Thank you very much.
website.