On this lecture it is important not to go too slowly.  The instructor must touch on the many topics covered here without bogging down, since our goal is to work down to fundamental questions.  A slow and detailed exposition would spend 2 weeks on this one slide set and yet would be almost entirely superficial!  You might consider trimming slides if you don't like my pace on the first parts of the lecture, where I tend to really blast through the material.

The lecture starts by asking "what really happens" when a program first tries to find and connect with a Web Service.  The point is that with this architecture one often has many options for a desired service.

In this lecture hall, I want my slides to project on the overhead projector.  But the room is full of devices that might support that interface, even including cell telephones, other laptops, the projector just on the other side of the wall in the next room (perhaps it can "hear" me), etc.  How will my computer wisely pick the right device?

The main topic here is discovery: naming.  My objective is for the students to realize that there are many "layers" at which name resolution occurs: the URLs in a web page, which are often generated on demand just for the client; the DNS mapping of names to IP addresses, the interpretation of IP addresses, the routing infrastructure, load-balancers, etc.  Potentially logic is needed both on the client side of each of these layers and on the server side.

Yet Web Services has a rather inadequate naming mechanism; services describe themselves using UDDI.  The lecture spends a few minutes looking at a WSDL description and a UDDI database to illustrate the ideas.  Beyond this we can hack solutions, like the DNS mechanisms just mentioned, but there is no uniformity and poor platform support for such things.

Hari Balikrishnan and some colleagues are arguing for a new multi-layer naming and discovery architecture.  Presumably, if the architecture was standard we would also have standard ways to supply the needed logic in order to specialize a given "path". 

For example, the client may have a choice: buy the books for CS514 from Amazon, Barnes and Noble, or directly from Springer.  Having picked the supplier, perhaps Amazon, Amazon may want this request to go to its New Jersey warehouse; within that warehouse we may want the transaction to hit the right services, the right subgroup within that service, the right member.  And then we need to deal with routing...   Quite a mess, yet this is the world in which we live today.  If you work in distributed systems, it doesn't get better than this! 

Balikrishnan has written a good paper on this topic (cited on the slide set); it is well worth reading.

Take-aways?  Web Services only go "so far" and often, real developers simply must go beyond the limits.  Such is the case for naming, and it will happen for other technologies too.  We'll see this again and again.