As you know, any stand-alone .NET resource such as ASPX webform or web service can be associated with a Sitecore context. With this in place, will be able to access all nice stuff from Sitecore.Context such as "ContentDatabase", "Domain", etc.

In order to do that, you can just drop the resource into one of the folders referenced by a site definition in the <sites> section.
For example, if your stand-alone resource is working with the back-end, "modules_shell" would be the best option:

<site name="modules_shell" virtualFolder="/sitecore modules/shell" physicalFolder="/sitecore modules/shell" rootPath="/sitecore/content" startItem="/home" language="en" database="core" domain="sitecore" content="master" enableWorkflow="true" />

As you can see, the "modules_shell" site is referencing the "/sitecore modules/shell" folder, so this would be the location for your resource.

It works great for aspx and asmx resources but fails for a WCF service that you may be using.

The reason for that is the FilterUrlExtensions processor in preprocessRequest pipeline that does not allow SVC extensions through. If you simply adjust the value of the first "allowed extensions"  parameter as it is shown below, your WCF service will be able to access Sitecore context:

<processor type="Sitecore.Pipelines.PreprocessRequest.FilterUrlExtensions, Sitecore.Kernel">
 <param desc="Allowed extensions (comma separated)">aspx, ashx, asmx, svc</param>
 <param desc="Blocked extensions (comma separated)">*</param>
 <param desc="Blocked extensions that stream files (comma separated)">*</param>
 <param desc="Blocked extensions that do not stream files (comma separated)"></param>
</processor>

Note, there are two processors with the same class name in web.config so don't confuse it with the one defined in the *httpRequestBegin *pipeline.