By hubertsblog on Jan 12, 2008
Let's imagine the following scenario: I book a trip on a Travel.com. Part of the features that makes this site attractive to me is that it can automatically update my online calendar, which it offers to do as soon as I have purchased my ticket. It is important to note that my calendar service (let's call Calendar.com) has no particular relationship with the travel service I use to book my trip. In fact I could change my calendar service at any time (or use another travel site). This scenario is quite simple but it will allow me to go through the various phases that need to take place.
At the highest level, 4 steps need to take place:
- I visit Travel.com and book a ticket.
- Travel.com offers to update my online calendar, should I have one. Since I do have such service (at Calendar.com), I accept the offer.
- Travel.com finds out that my calendar service is hosted at Calendar.com and figures out the specifics of this service (more details on that later).
- Travel.com contacts Calendar.com and updates my calendar there (on my behalf).
How do we go about solving this discovery problem? One solution, proposed by Liberty Alliance, is the concept of a Discovery service. A Discovery service is an online service where a user can federate many services around his identity thus enabling their discovery. This is a powerful concept and our RESTful solution uses the same concept.
At a slightly more technical level, by including the Discovery Service notion we now have the following steps:
- At some point in time (prior to my ticket purchase) I visited Calendar.com and was asked if I wanted to associate this service with my account (i.e. my identity) at my Discovery service (I'll leave the details on how the Calendar service knows about my Discovery service out for now).
- When I consent, Calendar.com sends a request to associate itself with my identity there. Doing so, my calendar resource becomes discoverable by other services that can talk to my Discovery service.
- I visit Travel.com, purchase a ticket and accept the offer to update my online calendar.
- Travel.com performs a lookup query at my Discovery service to find out where my calendar service resides and retrieve details about it.
- After it gets the information, Travel.com can now update my calendar that is hosted at Calendar.com.
This scenario highlights the 3 core steps I described in my previous blog entry:
- A service provider (e.g. Calendar.com) registers itself at my Discovery service and then associates itself with my identity there (at my Discovery Service)
- A service consumer (e.g. Travel.com) discovers the location and metadata of the service that it wants to access on my behalf
- This service consumer invokes the service provider to carry out some function (e.g. update my calendar).