none
Facade Pattern for WCF Application RRS feed

  • Question

  • We are in the process defining the architecture of a fairly large customer facing financial application where performance and scalability are the key requirements. 

    We proposed n-tier architecture which primary consists of Web Tier, Application Tier (Mid-Tier) and Data Tier WCF being the communication mechanism between web tier and app tier.   Some of the stakeholders are concerned that WCF would cause performance overhead and want configurable architectural provision to support In-process calls and WCF. Their vision is to start with in-process calls and change it to WCF based communication if horizontal scalability is a concern.

    We are considering the following approaches:

    1. One architectural approach would be to introduce a client facade layer which can act as a facade between web and application layers. The façade layer would simply hide the complexity of the remote calls and allows for easy swapping of the façade for another one that might possibly implement a different remote call technology (ie. WCF)
    2. Another approach is to simply use WCF and use different bindings for different scenarios. For example, use IPC binding (Namedpipes) when web and application components are deployed in the same machine or use TCP binding when the application components are deployed in a different service (Both the ends use .NET so interoperability is not a concern )

    We are looking for the right architectural approach for the above mentioned scenario.

    Kindly advice.


    Monday, October 27, 2014 8:34 AM

Answers

  • We are in the process defining the architecture of a fairly large customer facing financial application where performance and scalability are the key requirements. 

    We proposed n-tier architecture which primary consists of Web Tier, Application Tier (Mid-Tier) and Data Tier WCF being the communication mechanism between web tier and app tier.   Some of the stakeholders are concerned that WCF would cause performance overhead and want configurable architectural provision to support In-process calls and WCF. Their vision is to start with in-process calls and change it to WCF based communication if horizontal scalability is a concern.



    Option One-
    Put all service code to a WCF service library project. Please note that A WCF service library is a dynamic-link library (DLL) and then include the library to your consuming application i.e. Simple Add Reference and use that as a simple class library. DLL/assembly calling is always –IN-Process. Near future when you need horizontal scalability , just host the WCF library in to a service host or convert that service library project to a wcf service application project. Conversion is easy.
    Option Two-
    Host your WCF service and asp.net application on the same IIS with same AppPool. This way both the application is going to consume the same process. Later you can move the WCF service part to some other server.
    Option Three- You might try using IDesign's ServiceModelEx assembly which simplifies the process of creating an in-process client for a WCF service. The assembly includes an InProcFactory class which dynamically creates a Net.Pipe endpoint and a proxy for your service.

    Lingaraj Mishra

    • Marked as answer by arasheed Monday, November 3, 2014 5:43 AM
    Friday, October 31, 2014 10:44 AM

All replies

  • Surly the point of using WCF is to use (2)? I.e. If you believe in WCF then you believe in the config file? Sure I would make that as easy to use as possible but once it's setup correctly it shouldn't impact on the caller what it eventually uses to implement the call.

    http://pauliom.wordpress.com

    Thursday, October 30, 2014 9:27 AM
  • We are in the process defining the architecture of a fairly large customer facing financial application where performance and scalability are the key requirements. 

    We proposed n-tier architecture which primary consists of Web Tier, Application Tier (Mid-Tier) and Data Tier WCF being the communication mechanism between web tier and app tier.   Some of the stakeholders are concerned that WCF would cause performance overhead and want configurable architectural provision to support In-process calls and WCF. Their vision is to start with in-process calls and change it to WCF based communication if horizontal scalability is a concern.



    Option One-
    Put all service code to a WCF service library project. Please note that A WCF service library is a dynamic-link library (DLL) and then include the library to your consuming application i.e. Simple Add Reference and use that as a simple class library. DLL/assembly calling is always –IN-Process. Near future when you need horizontal scalability , just host the WCF library in to a service host or convert that service library project to a wcf service application project. Conversion is easy.
    Option Two-
    Host your WCF service and asp.net application on the same IIS with same AppPool. This way both the application is going to consume the same process. Later you can move the WCF service part to some other server.
    Option Three- You might try using IDesign's ServiceModelEx assembly which simplifies the process of creating an in-process client for a WCF service. The assembly includes an InProcFactory class which dynamically creates a Net.Pipe endpoint and a proxy for your service.

    Lingaraj Mishra

    • Marked as answer by arasheed Monday, November 3, 2014 5:43 AM
    Friday, October 31, 2014 10:44 AM
  • Many thanks for your feedback!
    Monday, November 3, 2014 5:44 AM