Andy and I did a bit of brainstorming tonight on how do applications lookup "well known services". Today services are just normal threads, but we haven't specified a standard mechanism for a service to be published for consumers to easily discover. The proposed design leverages uris and namespaces which are Fan's standard mechanism for naming.

Thread will have a new virtual method isService that subclasses can override. It will default to return false.

If a thread overrides isService to return true, then that thread is implicitly mounted into the namespace under the Uri(s) "/sys/service/{qname}" where qname is all the public types implemented by the thread class. For example the HavenService would automatically be mounted as "/sys/service/sql::SqlService" and "/sys/service/haven::HavenService". If more than one service type is mounted, only the first one is published under the Uri.

Consumer services define Uri properties for their dependent services. These uris default to the presumed well known service uri. If there is a case where multiple services might be available, then the property can be explicitly configured in the boot script. Example:

class SidewalkService : Thread
{
   Uri havenService := `/sys/service/haven::HavenService`
   Uri notifyService := `/sys/service/sidewalk::NotifyService`
}

I don't get it.

This is a matter of how applications are "glued" together. For example consider SidewalkService (which manages this discussion forum) - in order for it work it needs to access to a database via the SqlService. There might be other services which need access to the database too. Ideally we want to avoid coupling and keep each of these things independent. So how does the SidewalkService figure out what SqlService it is supposed to use for database access?

What we are saying is that the SqlService will automatically publish itself under the uri "/sys/services/sql::SqlService". This provides a well known URI to find the database service within a Fan VM (much like we assume HTTP is running on port 80).

Now suppose we actually have two SqlServices running in a VM - which one should SidewalkService use? Only the first one is published under the well known URI. If we don't care we can just use whatever one happened to be registered first. However if we do care, we need to explicitly configure which one to use in our boot script. We can do this because the SidewalkService declares a configurable URI for its SqlService. It defaults to the well known URI, but in this case we would have to manually configure it.

This feature is implemented as designed. I also added a Thread.findService method, so you can lookup a service both ways:

Thread.findService(SqlService.type)
Sys.ns[`/sys/service/sql::SqlService`]

I was struggling with an issue last night, threading a SqlService object through chains of method calls. I knew it wasn't the Fan Way, but I couldn't quite find anything in the docs about how to handle this problem.

Finally, this morning, it dawned on me that what I'm looking for was a "well-known service." This thread was the latest that mentions the idea. The design was changed since then, but as far as I can tell, there is no up-to-date documentation on the subject of installed Services. Perhaps that's something you guys can tack to the end of your list.

I don't have a docLang topic on it, but there is pretty good docs in sys::Service

To register the SqlService:

sql.start

Then to look it up:

sql := Service.find(SqlService#)

Ah. I didn't see that find method tucked in there. (I really need to read more carefully).

When installing a service, it is stored under the fan UriSpace as /sys/service/{qname}. Is this a list of installed Service objects or just the first one that was installed?

The UriSpace just resolves to the first one. Note that it isn't stored in the UriSpace, the UriSpace calls Service.find lazily during URI resolve.

FYI the code to resolve fan:/sys/ URIs is in SysUriSpace.java

You can also use those URIs to resolve pods and files inside of pods. For example this is how you get a URI to resolve an icon file:

`fan:/sys/pod/icons/x16/cut.png`.get

Likewise you could resolve a service like this:

`fan:/sys/service/sql::SqlService`.get

Part of Fan's REST style

Cool. I think it "clicked". Thanks a bunch.