Note: if the two terms are presented as options in installing a system, then they probably refer to the way in which the dependencies this system will be managed - and not the way the life cycle the program is managed (as my answer assumes). See response from Gypsy Morrison Mendez for more details.
The two concepts are orthogonal, ie have no relation to each other. You can have a system that is standalone and one background process, you can have one that is only one or only the other, and you can have one that is neither of the two.
As explained in response from Gypsy Morrison Mendez, an app standalone is self-sufficient, possessing everything you need to function without dependency on external applications. However, there is a limit - programs are usually compiled for a specific architecture, and usually also for a specific operating system. This means that there is rather dependence on the OS, there is only in relation to others applications and libraries that are not native part of this OS. Even a distributed system in source code format requires at least one compiler to turn it into executable code.
The concept of service, on the other hand, is more or less the following: when the operating system starts, a series of other programs are put into execution, until it is ready to receive commands from the user (either via graphical interface or via terminal). All these programs are called "services" (with the exception of the "normal" applications that the user has chosen to start when "turning on the computer"). They usually don’t have a window, or an icon on the taskbar, and the only way to interact with them is through their service interface (which can be via socket, pipe, http requests, etc.). They may also not be "opened" or "closed" by the user (except forced closure), as their life cycle is controlled by the OS itself.
It should be noted that background process is different from service: in *NIX systems at least any process may be sent to the background (and later brought back to the foreground) through a specific command. But that doesn’t make it a service - because if you close the terminal/log out, all the processes that that terminal started are closed as well. For the "survive closure" process, it is necessary that it has been 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 the case of a graphical interface, it means that the program no longer has a window)
Do you have an example program that offers these two options? I saw that you accepted my answer, but maybe it doesn’t apply to your case - because one thing is the life cycle of the system (who starts, who ends, how the user interacts with it) and another is its dependencies (whether it is "tied" to the current OS configuration or not).
– mgibsonbr