While I already answered Tim's support ticket I would like to share the answer in here, so that it is available for everybody. Do let me know if you have any comments or find something not entirely to your liking. As always we are open to suggestions and would like to provide a better services story. Here goes:
Unfortunately we haven't designer the wizard to be capable of generating into a WCF Service Library projects. Of course if that is the case we shouldn't have allowed you to use the wizard in the first place. We will consider adding support for that (or hide the project entirely).
As to fetch plans, they are not automatically applied to services. Let me shed some light on the matter, a WCF service will work (and load) the same whether it is exposed trough web or netTcpBinding. The question now becomes how to transfer object graphs trough a service and whether fetch plans apply.
First of all I will suggest using the new "Generate OpenAccess Domain Service..." wizard. It is build so that it can be easily extended and should be pretty straight forward and easy to understand. The DataManager on the other hand, handles most of the stuff automatically but it can be a bother to tweak.
So when using the new wizard a DTO layer will be generated for you. Each service method will call a domain service that will retrieve the OpenAccess objects from the database and construct DTO object from them that will in turn be returned through the service. Now is a good time to point out that fetch strategies apply only for loading OpenAccess objects. You need to keep in mind that if a property that is now loaded is access the integrated lazy loading will kick in and load the data in a separate query (and this cannot be turned off).
You will see that the Assembler classes that are used to translate a DTO object to an OA object, and the reverse will not populate the collection and reference properties (i.e. related entities). This is done on purpose, because usually loading object graphs and sending them trough a service is not a good idea. The message size quickly becomes too much. This is why the SDK example load data in different calls to the service, exactly because loading everything in a single call might be too big. Loading only needed data is what we tried to achieve.
You can easily extend the generated code so that related entities are loaded and sent, however you should be careful in doing so.
Unfortunately we do not have such a sample right now. I hope this is helpful, please let us know if you have further question or face more trouble.
the Telerik team