Home  /  Questions  /  Question



70   96.1
Sep 08, 2010


Service Facade Definition

Patterns in Action 4.0 describes the Service Facade as "being grouped by functionality", and one possible implemenation using the sample application would be to have a Membership Facade, Employee Facade, Reporting Facade, etc., and to "organize these Facades so they match 'Vertical Tiers'...", but "to keep things simple" the sample application uses only one Facade.

In the application our team is building we are grouping the application facades by functionality, but are encoutering an issue with request validation. Specifically, how would the _username private field value get set in a Service Facade that does not contain a Login method? Or, do all Service Facades require a Login in method? If so, that begs the question what am I logging into a Service or an Application? It's not clear to me what a 'Vertical Tier' represents.

If the sample application were broken out into multiple Service Facades how would each Service validate the request and more specifically the _username? The user logging into the application happens once so how would the multiple service facades be aware of the authenticated user?

Any insight and guidance is appreciated.



830   99.9
Sep 10, 2010
From your description, I don't think the issue is breaking the Service class up in mulitple 'Vertical Tier' classes, like, MembershipService, CustomerService, ShoppingService, etc.  Rather, what you are asking is: How do we know who is calling the particular method and is he/she authenticated and authorized?   And if the user is authenticated give me UserId, UserName, etc.

This can be a fairly complex area. There are numerous ways to deal with this, but it is easiest if you are using Microsoft Membership (for the sake of this discussion I assume you are dealing with a simple 3 tier app, running all tiers on the same machine). Membership provides the necessary information whether he/she is authenticated and authorized (its role). In addition Membership lets you find out who the currently logged in user is by looking at the thread: 

Thread.CurrentPrincipal.Identity.Name
If you maintain your own User table (in addition to the Membership User or User Profile), you can 

1)  retrieve User information from your database for each call (but this may be expensive)
2)  maintain a list of Users in Cache (which is what we use on DoFactory)
3)  maintain logged-in User information in Session.

Another area to explore is TLS (Thread Local Storage) which allows you to store custom data that is local to each thread.

If you have a distributed application, with public WebServices, then storing the user in Session may be a reasonable approach.
If you have multiple load-balanced servers then some sort of authentication token may be your best bet.

Again, this can be a fairly complex topic (depending on your requirements and configuration), but I hope this gets you going. 
 

70   96.1
Sep 10, 2010

Thanks for your response. Your suggestions serve as a good starting point. 

Yes, we are storing the authenticated User in Session so after authentication completes I know who the User is. In the sample application, the ActionService is the Service authenticating the User, and then subsequently setting _username which later may get validated when other ActionService methods are called (snippet from ActionService): 

public LoginResponse Login(LoginRequest request)
{ 
  // ... 

  if (!Membership.ValidateUser(request.UserName, request.Password))
  { 
     response.Acknowledge = AcknowledgeType.Failure;
     response.Message = "Invalid username and/or password.";
     return response;
  }

  _userName = request.UserName; 
  
  // ... 
}


private bool ValidRequest(RequestBase request, ResponseBase response, Validate validate)
{ 
   //...

   // Validate user credentials
   if ((Validate.UserCredentials & validate) == Validate.UserCredentials)
   {
      if (_userName == null)
      {
          response.Acknowledge = AcknowledgeType.Failure;
          response.Message = "Please login and provide user credentials.";                     
          return false;
      }
   } 
   // ...
}

Now I know who the Authenticated user is. If the Validate token is set to confirm user credentials for other methods on the service the service is aware if _userName has been set or not.

Let's continue with the example assuming there are other services. For example let's say there is an InventoryService exposing Product based methods and is referenced by the same MVC project, and the authenticated user, now via the UI, calls methods on the InventoryService. If the Validate token is set to confirm user credentials it will fail in the InventoryService because _userName is null. With the Service Facade pattern for applications with multiple services how would the authenticated user information now stored in session get passed to the other services? Or, does each service require a login authentication method?

If possible, can you please extend the sample application used in the documentation with a small snippet of code showing how the _userName value would get set in another service, for example the InventoryService or the CustomerService.

I appreciate your insight.