A web service isn't needed unless you plan on having your clients (web/mobile/windows) call the service to check what meetings are coming up in the next hour or if your app/job that checks for meetings calls the web service to handle the sending of emails. If you were trying to do a push notification to your clients (web/mobile/windows) instead of a pull, then you would want to use something like WebSockets to keep a connection open to a server and have the server push notifications back to the client when new meetings are available. As the above indicates, like you clued in on, web services provide the ability to call a "function" (model) remotely/out of process.
To schedule something that will run within the app and continually check the database for new meetings or meetings that are now within the 1 hour mark you could use a scheduler like @stuartd suggested. Then at the end of the job, send emails.
If you need to go bigger with more decoupling you could have a job that simply watches the data for meetings that are new/within the period of time you need. Instead of that job sending the email, you could have a messaging system, like Kafka, running that you send these messages to. At that point you setup a simple app that would read the message from the messaging system to process it and send emails. This is no doubt a larger design and implementation, however it will give you more flexibility with regards to the workflow flexibility, scaling out, and the use of the messaging for other things.