WCF SOA solution project layout RRS feed

  • Question

  • Hi All,

    I am trying to create a Visual Studio Solution for a WCF service, in a soon to be SOA environment. 
    Below is the project layout that I came up with trying to comply with SOA/SAA principles.


    Has anyone divided the solution like this before?

    Shall I just include proxy within Contracts project? Why ?

    1- Service Manager Project : Which consumes Business Project
    2- Contract Project: This project contains 1) Service contracts 2) Data contracts related to the service.
    3- Business Project: This project contains all Business Logics of the service.
    4- Proxy Project: This project provides client apps, access to service

    Any hint will help,



    Tuesday, November 17, 2009 1:53 AM

All replies

  • Robert
    This looks fine.

    At times i have seen Service Manager Project being called Service Interface project.
    Contract project can additionally have Entities project having entities definition like customer, project, etc..i presume you intend to cover through DataContracts, apart having indepenedent entity project along side can help in building DataContracts.

    hope this helps.

    Tuesday, November 17, 2009 2:18 PM
  • Greetings,

    The folder structure looks fine. But all the projects which you are mentioned are inter dependent. Their should be common bin folder where all the assemblies should be kept.  The use team foundation server will help you in project . You need to think about of installing the assemblies in GAC or run a build script using msbuild. Build and Integrations guys will take care of it.

    Where the solution folder for hosting the WCF Service. For example you are hosting the service in WAS or IIS 7.0 or in WAS.

    Hope this helps.

    Take Care

    Helping People To Solve Technical Problems
    Tuesday, November 17, 2009 5:07 PM
  • Thanks for the reply Suds.

    What do you think about the proxy project with idea of providing clients/consumers a ready to use proxy/client class which takes care of opening/closing service channels?
    How about I merge the contract and proxy projects providing consumers everything (Data contracts, service contracts and proxy class) in one Dll?
    My initial thought was to decouple proxy from contract project since there could be some logic in proxy which didn't want to have them in contact project.


    Tuesday, November 17, 2009 7:02 PM
  • Build output folder will be a common folder for all the projects in the service solution.
    Projects are references with project dependency.

    I was planning to host the service in Windows 2008 server R2 using WAS, my impression was hosting it in IIS7.5 automatically means using WAS.
    I defenitly do not want to use http binding but netTcpBinding.


    Tuesday, November 17, 2009 7:09 PM
  • Hello Robert

    Having proxy along side Contract would be a good idea. Dont keep any logic in proxies.

    You can host your services with Dublin (WAS) and IIS 7.5 , had been playing with Dublin and found it good to support for hosting services, workflows, persistence, scaling, life cycle management, monitoring functionality.

    hope this helps.
    Wednesday, November 18, 2009 8:33 AM
  • Hi Suds,

    By having logic in proxy I was referring to 1) having a mechanism to check for max calls/ connections of the service 2) potentially having caching at proxy (client side caching). Depending on the nature of the service sometimes you could have an instance of proxy (singleton) and do some caching.


    That was the reason I thought proxy should be separate from Contract.


    Let me know what is your opinion?



    Wednesday, November 18, 2009 5:49 PM
  • Hi,

    You can also use Channelfactory instead of proxy to implement this.For more on this, please refer to

    Please mark this as answer if it helps you

    Thursday, November 19, 2009 4:39 AM
  • Hi RB

    All the logic you plan to put in proxy like to check for max calls, connections, etc. is supported OoB through Dublin/WAS.
    Things like Singleton, Caching etc. is also supported and you can manage it through service config as well.

    hope this helps.
    Thursday, November 19, 2009 6:32 AM