Note: If the two terms are presented as options when installing a system, then they probably refer to how dependencies of that system will be managed - and not to how the the life cycle of the program is managed (as my answer assumes). See Cigano Morrison Mendez for more details.
The two concepts are orthogonal, that is, they have no relation to each other. You can have a system that is standalone and a process background , you can have one that is just one or just another, one that is neither.
As explained in Gypsy Morrison Mendez , a standalone application is auto - enough, having everything you need to work without dependence on external applications. However, there is a limit - programs are typically compiled for a specific architecture, and usually also for a specific operating system. This means that there is a lot of dependence on the OS, there are no other other applications and libraries that are not a native part of that OS. Even a distributed system in the source code format requires at least one compiler to turn it into executable code.
The concept of service is more or less the following: when the operating system starts, a series of other programs are run, until it is ready to receive user commands (either via graphical interface or via terminal). All such programs are called "services" (with the exception of the "normal" applications the user has chosen to start when "turning on the computer"). Usually do not have a window, or an icon in the taskbar, and the only way to interact with them is through their service interface (which can be via socket, pipe, http requests, etc). Also they can not be "opened" or "closed" by the user (except for forced closing), since its life cycle is controlled by the OS itself.
It should be noted that background process is different from service : on * NIX systems at least, any process can be sent to the background ( and then brought back to the foreground ) via a specific command. But that does not make it a service - because if you close the terminal / log out, all processes that that terminal started are closed too. For the "survive close" process, it must be explicitly configured for this (as described above).
(and if this is not clear, "send to the background" means that the terminal is free to execute other commands, or in case of a graphical interface, means that the program does not have a window)
