Teaching the right way – with principles
This semester, I’m teaching several new concepts in my web application development course. For some reason, though, I was stumped at how best to present these concepts. And then I thought, there ought to be principles for doing that. What’s more, I forget that in 2012 I published an article about the four principles for teaching new concepts to students. Those four are:
“(1) new concepts are carefully defined, (2) new concepts are related to real world examples, (3) new concepts are integrated with the learner’s prior knowledge, and (4) new concepts are motivating to the learner.”
Perhaps I should use what I already wrote to design a new lesson. This post captures my initial thinking on how best to teach one new concept – “Web services”.
Motivating students
To start, I focus on the fourth principle – motivation. A good place to start may be with user authentication, which is something I will have had introduced, but also something these use frequently. I would note that many users hate remembering 100s of passwords for all the different websites (something with which they can likely relate). Then I would ask “wouldn’t it be great for users if authentication could be handled by some sort of single entity across multiple websites, such that the entity wouldn’t have access to the website content, but could still authenticate a user? Users would then have to remember only one username and password instead of 100s.” I would then show them multiple examples of single sign-on functionality, such as those offered by Google, Microsoft, and Facebook.
Once motivation is established for authentication (hopefully), I would try to build on that motivation by listing other types of functionality that might be useful across many websites and mobile apps. Things like maps, search, weather forecasts, and SMS. I would also point out that many new web and mobile apps use a bunch of these functions in them. Not only are these things useful, but they are common.
Some instructors might at this point ask students for more examples. I’m hesitant to do that at this point because there are only a certain class of things used for web services. And since they don’t know what a web service is yet, their guesses would likely be all over the place which would cause more confusion.
Defining web services
So far, I’ve established part of the context for the definition. But we haven’t clearly defined the concept “web service” yet. That comes with the question: “What is this class of things?” I might at this point to ask the students to tell me what similarities they see between these class of things. Then I could show them several definitions provided by others, such as these three:
IBM:
A web service is a software system that supports interoperable machine-to-machine interaction over a network
TechTarget:
Web services are a type of internet software that use standardized messaging protocols and are made available from an application service provider’s web server for use by a client or other web-based programs.
Wikipedia:
A web service is a service offered by an electronic device to another electronic device, communicating with each other via the Internet.
I would highlight each of these definitions share the three common characteristics. First, a web service is Internet based. More specifically, it’s web based. Second, the end user is not involved. It’s a software-to-software (machine-to-machine in IBM language) in it’s interactions. Third, it’s a specific piece of functionality offered as a service.
Differentiation
While these three keys explain what a web service “is”, it does not explain what it “is not”. In other words, I need to differentiate the concept from other related ideas. This is where the third principle helps, tying the concept with what the students already know.
The first key – web based. The students’ experience with programming non-web based systems is minimal. Basically just one programming class before taking mine. So the focus will have to be on usage of systems. This is problematic because the second key to web services is that they are machine-to-machine interaction, not machine to user. So asking about student usage of a system may cause confusion. Furthermore, many application today contain web enabled aspects. This makes it hard to find examples. I can’t see an easy way around it. Most likely, I will ask for examples of applications that work when there is no Internet connectivity. I’ll note that we will soon see the “web” nature of a web service, once the definition is understood.
Second key – machine-to-machine interaction. As a counter example, a website is web based and may contain specific functionality (like Google.com), but is user-to-machine, not machine-to-machine. That doesn’t mean that an application using a web service doesn’t have a user interacting with it, but the service itself is designed for another machine to interpret and use. The user interface must be provided by the application consuming the web service. Since many of my students are taking a systems analysis and design course concurrently with my course, I could use Data Flow Diagrams (DFDs) to help them visualize this key.
Lastly, I need to differentiate the specific functionality or “service”. In this, a service is distinct from a product in that a web service is something that is offered to outside entities to interact with. As opposed to a product which is a onetime acquisition of software. This would hopefully be the easiest to differentiate by asking about counter examples, such as downloadable phone apps, that are clearly products, not services.
I may also take the time to discuss how web services relates to cloud computing, a concept many of them will be familiar with. Or perhaps I’ll leave that as an extra credit opportunity – let them on their own time write an essay explaining how those two concepts relate to one another.
Necessary sub-concepts
So far, I’ve provided the motivation, provided some high examples, defined the term, and differentiated it from similar concepts. However, to fully capture the meaning of web services, the students need to understand some sub-concepts , such as API, HTTP requests, JSON, XML, SOAP, and REST. Much of the the rest of class will be explaining how all these sub-concepts relate. How every web service has an API that accepts HTTP requests that must transfer data back and forth in the form of JSON or XML formats, structured using standard protocols and frameworks, such as SOAP and REST. This discussion will by necessity get very technical. More technical than I want to get into in this post.
Real world examples
The last principle to learning a concept is to provide real world examples. While I will have mentioned several examples during the motivation, one goal I have in this class is to have them work with web services such that they understand the concept intimately.
I want to focus heavily on JSON formats over a REST service. There are of course lots of options for building web services, but many are rare and would distract rather than inform. Plus, those two technologies are designed to be lightweight implementations of web services, which make them ideal for learning the concept.
Time also constrains the depth of this work. So I plan to assignments where they write code that uses a web service, requesting data that can be manipulated and displayed on a web page. However, there’s not enough time to teach them how to create a web service for consumption.
Principles for all
What’s fascinating is that I had no idea how to teach web services before starting this post. As I wrote, remembering the four principles helped me to concretize the lesson plan, to think through what I needed to cover and how to make the lesson excellent, perhaps extraordinary. I love the result. I’m sure it’ll need tweaking, especially after my first time teaching it. But the power of the principles in designing this lesson is something I need to do with all my lessons so that I can achieve my goal of making the best damn course in the college.
