UsingCsla4 04 DataPortal

Using CSLA 4
Data Portal Configuration
Rockford Lhotka
Using CSLA .NET 4: Data Portal Configuration
Copyright © 2011 by Marimer LLC
All rights reserved. No part of this work may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopying, recording, or by any information
storage or retrieval system, without the prior written permission of the copyright owner.
Trademarked names may appear in this book. Rather than use a trademark symbol with every
occurrence of a trademarked name, we use the names only in an editorial fashion and to the
benefit of the trademark owner, with no intention of infringement of the trademark.
Editor: Teresa Lhotka
The information in this book is distributed on an “as is” basis, without warranty. Although every
precaution has been taken in the preparation of this work, the author shall not have any liability
to any person or entity with respect to any loss or damage caused or alleged to be caused directly
or indirectly by the information contained in this work.
The source code for this book (CSLA 4 version 4.1.0) is available at
http://www.lhotka.net/cslanet.
Errata or other comments about this book should be emailed to [email protected].
Revision: 1.0
Acknowledgements
Neither this book, nor CSLA 4, would have
been possible without support from Magenic.
Magenic is the premier .NET development
company in the US, and is a Microsoft Gold
Certified Partner.
You can reach Magenic at

http://www.magenic.com.
CSLA .NET has attracted a community of very

thoughtful, intelligent and dedicated people.
You can find many of them at
http://forums.lhotka.net.
The bug fixes and feature enhancements

described in this book come, in no small part,
through the encouragement and feedback
provided by this stellar community.
Thank you all!

About the Author
Rockford Lhotka is the author of more than 17 books on developing software using the Microsoft
platform and technologies. He is a Microsoft Regional Director and a Microsoft MVP. Rockford
speaks at many conferences and user groups around the world. He is the Chief Technology Officer
at Magenic (www.magenic.com), a company that specializes in planning, designing, building and
maintaining your enterprise’s most mission critical systems.
Contents
Introduction........................................................................................................................................................... 1
Organization of the Book ..........................................................................................................................................1
Framework Code and Samples ..................................................................................................................................1
Chapter 1: Data Portal Deployment ....................................................................................................................... 3

Data Portal Concepts ................................................................................................................................................3
Proxies and Hosts .................................................................................................................................................5
Data Portal Proxies ..........................................................................................................................................5
Data Portal Hosts .............................................................................................................................................5
Deployment Options .................................................................................................................................................6
1-tier Deployment ................................................................................................................................................6
2-tier Deployment ................................................................................................................................................7
3-tier Deployment ................................................................................................................................................8
4-tier Deployment ................................................................................................................................................9
Using the Local Channel ..........................................................................................................................................11
Client Configuration ...........................................................................................................................................11
.NET Configuration ........................................................................................................................................11
Silverlight Configuration ................................................................................................................................12
WP7 Configuration ........................................................................................................................................12
Serialization and AutoCloneOnUpdate .........................................................................................................13
Using the WCF Channel ...........................................................................................................................................14
Windows Communication Foundation (WCF) ....................................................................................................14
Basic WCF Configuration ...............................................................................................................................15
Customizing a WCF EndPoint ........................................................................................................................16
Troubleshooting Services ..............................................................................................................................18
Client Configuration ...........................................................................................................................................19
.NET Configuration ........................................................................................................................................19
Silverlight Configuration ................................................................................................................................21
WP7 Configuration ........................................................................................................................................24
Application Server Configuration .......................................................................................................................25
Silverlight Cross-Domain Policy .....................................................................................................................25
Hosting in IIS and ASP.NET ............................................................................................................................26
Hosting in Windows Server AppFabric ..........................................................................................................32
Hosting in Windows Azure ............................................................................................................................41
Hosting in the Windows Activiation Service ..................................................................................................44
Hosting in a Custom Windows Service ..........................................................................................................46
4-Tier Silverlight and WP7 Deployment ..................................................................................................................53
Data Portal Configuration ..................................................................................................................................55
Client Configuration ......................................................................................................................................55
Hosting the Data Portal on the Web Server ..................................................................................................55
Hosting the Data Portal on the Application Server .......................................................................................56
Implementing an Object Inspector ....................................................................................................................57
Using CSLA 4: Data Portal Configuration Page i

Copyright © 2010 Marimer LLC
Implementing an Object Inspector ................................................................................................................58
MobileFactory Attribute ................................................................................................................................62
Custom Object Inspector Loader ...................................................................................................................63
Chapter 2: Data Portal Configuration Reference .................................................................................................. 65

.NET Configuration Settings ....................................................................................................................................65
Silverlight and WP7 Configuration Settings ............................................................................................................67
Chapter 3: Serialization ........................................................................................................................................ 69

.NET Serializer Types ...............................................................................................................................................69
MobileFormatter Serializer .....................................................................................................................................70
Chapter 4: Custom Data Portal Proxies ................................................................................................................ 72

Implementing a Custom Proxy ................................................................................................................................72
Implementing the Custom Proxy .......................................................................................................................73
AppServer Attribute ......................................................................................................................................73
WcfProxy Class ..............................................................................................................................................74
SmartProxy Class ...........................................................................................................................................75
Configuring the Application to use a Custom Proxy ...........................................................................................76
Implementing a Custom Proxy Factory ...................................................................................................................77
Implementing the Custom Proxy Factory ..........................................................................................................79
Configuring the Application to use a Custom Proxy Factory ..............................................................................80
Implementing Compression for Silverlight ..............................................................................................................80
Implementing the Compressed Data Portal Channel .........................................................................................82
CompressionUtility Class ...............................................................................................................................82
Implementing the Data Portal Proxy .............................................................................................................82
Implementing the Data Portal Host ..............................................................................................................83
Configuring the Application to use the Compressed Channel ...........................................................................84
Configuring the Client....................................................................................................................................84
Configuring the Server...................................................................................................................................84
Chapter 5: Authentication Models ....................................................................................................................... 86

Authentication Concepts .........................................................................................................................................86
Principal and Identity Objects ............................................................................................................................86
Accessing the Principal Object ......................................................................................................................87
Accessing the Principal in Silverlight and WP7 ..............................................................................................88
Existing .NET Principal and Identity Types .........................................................................................................89
Creating Custom Principal and Identity Types ...................................................................................................89
Impersonation ....................................................................................................................................................90
Custom Authentication with a Smart Client ..................................................................................................91
Custom Authentication with a Web Application ...........................................................................................92
Membership Provider Authentication with a Smart Client ...........................................................................92
Membership Provider Authentication with a Web Application ....................................................................93
Windows Authentication ...............................................................................................................................93
Custom Authentication ...........................................................................................................................................93
Implementing a Custom Principal and Identity ..................................................................................................94
Implementing CustomPrincipal .....................................................................................................................94
Implementing CustomIdentity ......................................................................................................................96
Using CSLA 4: Data Portal Configuration Page ii

Application Server Configuration .....................................................................................................................100
Data Portal Impersonation ..........................................................................................................................100
Custom Impersonation ................................................................................................................................100
Client Application Configuration ......................................................................................................................102
.NET Smart Client Application .....................................................................................................................103
Silverlight and WP7 Applications.................................................................................................................106
ASP.NET Applications ..................................................................................................................................109
Membership Provider Authentication ...................................................................................................................112
Implementing a Membership Principal and Identity .......................................................................................113
Implementing CustomPrincipal ...................................................................................................................113
Implementing CustomIdentity ....................................................................................................................113
Application Server Configuration .....................................................................................................................115
Client Application Configuration ......................................................................................................................117
Silverlight and WP7 4-Tier Applications ......................................................................................................117
Windows Authentication ......................................................................................................................................119
.NET Applications .............................................................................................................................................120
Application Server Configuration ................................................................................................................121
Smart Client Application Configuration .......................................................................................................121
Silverlight Applications .....................................................................................................................................123
Implementing CustomPrincipal ...................................................................................................................124
Implementing CustomIdentity ....................................................................................................................124
Application Server Configuration ................................................................................................................125
Silverlight Client Implementation ................................................................................................................125
ASP.NET Applications .......................................................................................................................................128
Web Server Configuration ...........................................................................................................................128
Conclusion ......................................................................................................................................................... 131
Using CSLA 4: Data Portal Configuration Page iii

List of Tables
Table 1. Members of the .NET WcfProxy class used for customization 21
Table 2. Members of the Silverlight WcfProxy<T> class used for customization 23
Table 3. Methods implemented by an object inspector class 59
Table 4. Members implemented by the ObjectFactory base class 60
Table 5. Data portal configuration settings for .NET 66
Table 6. Data portal configuration settings for Silverlight and WP7 67
Table 7. Base types that implement the IMobileObject interface 70
Table 8. Members defined by the IDataPortalProxy interface 76
Table 9. Assembly references required for Csla.ApplicationContext.User 88
Table 10. Existing .NET Principal and Identity types 89
Table 11. Principal and Identity types provided by CSLA .NET 90
Table 12. Values maintained by CslaIdentityBase 90
Using CSLA 4: Data Portal Configuration Page iv

List of Figures
Figure 1. Five layer logical architecture ......................................................................................... 3
Figure 2. Client, server, and proxy/host areas of functionality ....................................................... 4
Figure 3. 2-tier smart client deployment ......................................................................................... 7
Figure 4. 2-tier web deployment ..................................................................................................... 7
Figure 5. 3-tier smart client deployment ......................................................................................... 8
Figure 6. 3-tier web deployment ..................................................................................................... 9
Figure 7. 4-tier Silverlight deployment ......................................................................................... 10
Figure 8. Creating an ASP.NET Empty Web Application ........................................................... 27
Figure 9. Adding an Application in the IIS Manager ................................................................... 29
Figure 10. Adding an application to IIS........................................................................................ 30
Figure 11. IIS Manager administration console for IISHost application ...................................... 33
Figure 12. Manage WCF and WF Services region in administration console.............................. 34
Figure 13. Configuring AppFabric monitoring for WCF services ............................................... 34
Figure 14. AppFabric Dashboard showing data portal activity .................................................... 36
Figure 15. WCF Call History from the AppFabric Dashboard ..................................................... 36
Figure 16. Enabling End-to-End Monitoring ................................................................................ 37
Figure 17. Completed Calls summary in the AppFabric Dashboard ............................................ 39
Figure 18. Query Summary for SlPortal.svc service calls ............................................................ 40
Figure 19. Related event detail for a WCF service invocation ..................................................... 40
Figure 20. Event details display in AppFabric Dashboard ........................................................... 40
Figure 21. Displaying exception detail about an error event ........................................................ 41
Figure 22. Creating a Windows Azure Project in Visual Studio .................................................. 42
Figure 23. Adding an ASP.NET Web Role to the Azure project ................................................. 42
Figure 24. Adding the net.tcp protocol to a web application ........................................................ 45
Figure 25. Project references for creating a Windows service ..................................................... 47
Figure 26. Setting multiple startup projects for the WindowsHost solution ................................ 50
Figure 27. Adding a Windows Service project to the WindowsHost solution ............................. 51
Figure 28. The DataPortalService in the Services administration console ................................... 53
Figure 29. 4-tier Silverlight deployment ....................................................................................... 54
Figure 30. Message flow in a 4-tier deployment .......................................................................... 54
Figure 31. Application server project in a 4-tier deployment ....................................................... 57
Figure 32. Projects in the CustomProxy solution ......................................................................... 72
Figure 33. Interaction between types in the CustomProxy solution ............................................. 73
Figure 34. Projects in the ProxyFactorySl solution ...................................................................... 78
Figure 35. Relationship between projects in the ProxyFactorySl solution ................................... 79
Figure 36. Projects in the SilverlightCompression solution ......................................................... 81
Figure 37. WpfUI showing successful custom authentication results ........................................ 105
Figure 38. SilverlightUI showing successful custom authentication results .............................. 107
Figure 39. WpUI showing successful custom authentication results ......................................... 108
Figure 40. MvcUI showing successful custom authentication results ........................................ 111
Figure 41. Target framework set to .NET Framework 4 ............................................................ 114
Figure 42. Security tab of the ASP.NET Web Site Administration Tool ................................... 116
Using CSLA 4: Data Portal Configuration Page v

Figure 43. WpfUI showing Windows impersonation results...................................................... 123
Figure 44. Browser prompting for the user’s Windows credentials ........................................... 127
Figure 45. SilverlightUI showing Windows authentication results ............................................ 127
Figure 46. Disabling anonymous authentication in IIS Manager ............................................... 128
Figure 47. Configuring IIS Express for the MvcUI project ........................................................ 129
Figure 48. MvcUI showing Windows authentication results...................................................... 129
Figure 49. MvcUI showing the results of 3-tier Windows authentication .................................. 130
Using CSLA 4: Data Portal Configuration Page vi

Introduction
Welcome to Using CSLA 4: Data Portal Configuration.
This book will provide you with the information necessary to use the data portal component of
the CSLA .NET framework to enable flexible 1-, 2-, 3-, and 4-tier deplyments of your application.
This book is part of a multi-part book series, consisting of several related ebooks. While each
ebook is separate, they are designed to work together to provide information about CSLA 4. This
book series will show you how to use the CSLA framework to build powerful and scalable
applications for Windows, Silverlight and the web.
This book builds on the information provided in the Using CSLA 4: CSLA .NET Overview, Using
CSLA 4: Creating Business Objects, and Using CSLA 4: Data Access ebooks. It is assumed that you
have an understanding of the content from those ebooks.
Organization of the Book

This ebook is the forth in a series of related ebooks that together comprise the Using CSLA 4 book.
Each ebook is separate, but they are designed to work together in a flexible manner so you can get
just the information you need for your application or project. All subsequent ebooks in the series
assume you have read the first four ebooks:
1. Using CSLA 4: CSLA .NET Overview
2. Using CSLA 4: Creating Business Objects
3. Using CSLA 4: Data Access
4. Using CSLA 4: Data Portal Configuration (this book)
This book covers the configuration of the data portal, including how to use it for 1-, 2-, 3-, and 4-
tier physical deployment models. It also covers the authentication models that can be used with the
data portal.
The data portal is the component in the CSLA .NET framework that supports the mobile object
concept discussed in the Using CSLA 4: CSLA .NET Overview ebook. It abstracts the network, and
manages objects and messages as they flow between client and server.
By using the data portal and the five layer architecture prescribed by CSLA .NET, an application
can switch from a 1- or 2-tier to a 3- or 4-tier deployment without changes to any code.
Additionally, an application can change from using HTTP, to TCP, or other network technologies for
communication between the client and server, again with no changes to the application’s code.
By the end of this book you will understand how to use and configure the data portal.
Framework Code and Samples

The CSLA .NET framework and related code samples are available from the download page at:
http://www.lhotka.net/cslanet/download.aspx
Using CSLA 4: Data Portal Configuration Page 1
Rev 0.4 (draft)
This ebook uses CSLA 4 version 4.1, and I may refer to samples available in the standard Samples
download for CSLA .NET.
Additionally, in the Support folder provided as part of the CSLA 4 installation you will find a
Templates folder that contains very basic sample code illustrating the structure of each business
object stereotype described in this ebook.
Any code samples unique to this ebook will be included as a separate download available from
http://download.lhotka.net
This is also where you will have downloaded this ebook.

Rev 0.4 (draft)
Chapter 1:
Data Portal Deployment
The data portal supports deployment into 1-, 2-, 3-, and 4-tier physical architectures. When I use
the word tier in this context, I am referring to the deployments of layers of the application into
separate .NET AppDomain environments, separate Windows processes, or onto separate physical
computers. In other words, communication between layers crosses a comparatively expensive tier
boundary.
As I discussed in the Using CSLA 4: CSLA .NET Overview and Using CSLA 4: Data Access ebooks,
the CSLA .NET framework is designed around the logically layered architecture illustrated in Figure
1.
Figure 1. Five layer logical architecture

All CSLA .NET applications are composed of these five logical layers. You can deploy these five
layers into a physical environment in various configurations. In this chapter, I will discuss the
configurations the data portal is intended to support.
First, though, I need to cover some basic data portal concepts and terminology.
Data Portal Concepts

The data portal manages communication between your Business layer code running on the client,
and your Business layer code running on the server. As I discussed in the Using CSLA 4: CSLA .NET
Overview ebook, the data portal enables the concept of mobile objects, where objects move
between the client and server to do their work.
It is the data portal that enables and manages the movement of the objects. This means that the
Business layer (your business library assemblies) must be deployed to the client and to the server,
so the same types are available on either side of the data portal.
The data portal is implemented in three areas of functionality:
1. Client-side data portal components
2. Proxy/host communication channel
3. Server-side data portal components

Rev 0.4 (draft)
I discussed most of the behaviors of the client-side and server-side data portal components in
the Using CSLA 4: Data Access ebook, because they are the components used when implementing
object persistence.
The proxy/host communication channel is the part of the data portal that connects the client-
side and server-side components together so they can communicate. Figure 2 shows the
relationship between these areas of functionality.
Figure 2. Client, server, and proxy/host areas of functionality

The data portal channel manages and abstracts communication between the client and server.
The purpose behind this abstraction is to enable flexibility. Your application code should remain
unchanged even if one channel is swapped out for another. CSLA 4 includes the following channel
implementations:
 Local
 WCF (for .NET)
 WCF (for Silverlight and Windows Phone 7 (WP7))
 Remoting (.NET only)
 Enterprise Services (.NET only)
The local channel (sometimes called the local proxy) doesn’t cross the network. It runs the
“server-side” components in the same AppDomain, and therefore on the same computer, as the
“client-side” components.
The other channels do cross the network, or at least AppDomain or Windows process
boundaries, and they are used in 3- and 4-tier deployments.
The WCF channel for .NET has access to the full set of WCF technologies on .NET, and uses the
NetDataContractSerializer provided by WCF. You can use any WCF binding that provides a
synchronous communication model. This excludes the MSMQ-based bindings, but allows the use of
HTTP, TCP, named pipes, and other similar bindings.
The WCF channel for Silverlight and Windows Phone 7 (WP7) has access to the features of WCF
available on Silverlight and the phone. This channel uses a custom serializer provided by CSLA .NET
Rev 0.4 (draft)
called the MobileFormatter. The custom serializer is required, because Silverlight doesn’t
implement the .NET serializers required by CSLA .NET: the BinaryFormatter or
NetDataContactSerializer.
I discuss the MobileFormatter in detail in Chapter 3.

The Remoting and Enterprise Services channels remain in CSLA .NET for backward compatibility
with older applications. I recommend using the WCF channel instead of these channels, because
they rely on older technologies that Microsoft has effectively replaced with WCF. These channels
use the older BinaryFormatter serialization technology.
It is also possible to create your own data portal channel by implementing a proxy/host pair that
abstracts the network communication. I will discuss this in Chapter 4.
Proxies and Hosts

Each channel consists of two parts: the proxy on the client, and the host on the server. The host
exposes a network endpoint that can be called by the proxy running on the client. The exact nature
of this server or network endpoint is different depending on the type of network technology used
by the channel.
For example, when using an HTTP binding, the WCF host exposes a WCF endpoint as a URL. The
WCF proxy uses that URL to interact with the host over HTTP.
The proxy and host are designed to use the same network technology, the same protocol, the
same serialization technology, and they must agree on a service-oriented API by which the client
will call the server.
Data Portal Proxies

The data portal proxy runs on the client machine, and it is created and invoked by the client-side
data portal components.
The client-side data portal dynamically loads the proxy based on the CslaDataPortalProxy
configuration setting. This configuration setting provides the assembly qualified type name of the
class that implements the data portal proxy.
The result is that the configuration on the client machine determines what data portal proxy is
used by the application. You can switch from the WCF proxy to another proxy simply by changing
the CslaDataPortalProxy configuration value. Assuming there’s a properly configured server for
the new proxy, your application will continue to function as though nothing was changed.
Data Portal Hosts

The data portal host runs on the application server in a 3- or 4-tier deployment, or on the client
machine in a 1- or 2-tier deployment. The proxy invokes the host when the proxy is invoked by the
client-side data portal components. The data portal host handles the client request by invoking the
server-side data portal components.
In a 3- or 4-tier deployment, a data portal host must run within some server-side process or
container. In many cases the host runs within IIS, or the Windows Activation Service (WAS), or the

Rev 0.4 (draft)
Windows Server AppFabric. It is also possible to create your own Windows service to contain a data
portal host.
Your business assembly is loaded and runs within the same AppDomain as the data portal host.
So if the host is running in IIS, then your Business and Data Access layers will run in that same
AppDomain.
The proxy and host work together to abstract the network, the network technology, and any
related details. The end result is that the client-side data portal components have the illusion that
they are directly communicating with the server-side data portal components the same way,
regardless of the actual network technology being used.
Given this background, I will now move on to discuss the various n-tier deployment options
supported by the data portal and the CSLA .NET layered architecture.
Deployment Options
In the Using CSLA 4: CSLA .NET Overview ebook, I discussed the architectural concerns and tradeoffs
as you deploy applications into an n-tier environment. Typically, the more tiers in your deployment,
the slower the application will perform for any one user. In many cases, adding more tiers does
provide other benefits, possibly including:
 Scalabity
 Security
 Fault tolerance
Please refer to Chapter 2 in the Using CSLA 4: CSLA .NET Overview ebook for a detailed
discussion of the costs and benefits of n-tier deployment.
1-tier Deployment
The simplest deployment model is a 1-tier deployment. If all five layers from Figure 1 are deployed
onto one physical computer, and are running in the same .NET AppDomain, that is a 1-tier
deployment.
In a 1-tier deployment the data portal is configured in local mode. This means that the “server-
side” data portal components are running on the same machine, and in the same .NET AppDomain,
as the “client-side” data portal components.
When the data portal is configured to run in local mode, there is no cross-network or cross-
AppDomain communication. The client-side data portal makes direct method calls to the server-
side data portal, all within the same AppDomain.
Local mode is supported by the local channel provided by the data portal.
In a 1-tier deployment, the client-side application components have access to the database
credentials, and to the physical database itself.

Rev 0.4 (draft)
2-tier Deployment
CSLA .NET supports a 2-tier deployment where the Data Storage layer is separate. This is common,
because many applications use SQL Server, Oracle, or other database engines that run in their own
Windows process, or on a separate database server machine. This 2-tier deployment model is
illustrated by Figure 3.
Figure 3. 2-tier smart client deployment

The deployment shown in Figure 3 is for a smart client. You might also use a 2-tier deployment
for a web application as shown in Figure 4.
Figure 4. 2-tier web deployment

The only difference in this case, is that the HTML Interface layer must run in a browser, and so is
physically separate from the Interface Control layer. All the .NET application code remains on the
web server.
In a 2-tier deployment the data portal is configured in local mode. This means that the “server-
side” data portal components are running on the same machine, and in the same .NET AppDomain,
as the “client-side” data portal components.
When the data portal is configured to run in local mode, there is no cross-network or cross-
AppDomain communication. The client-side data portal makes direct method calls to the server-
side data portal, all within the same AppDomain. In the case of a web application, the “client-side”
code is running on the web server, along with the rest of the server code.
Rev 0.4 (draft)
Local mode is supported by the local channel provided by the data portal.
In a 2-tier deployment, the client-side application components have access to the database
credentials. The database itself is on a separate server.
3-tier Deployment
A 3-tier deployment is often used to enhance security or improve scalability for smart client
applications. It can also be used in environments where the client workstations are geographically
distant from the data center, because having the client communicate with an application server is
often more efficient than having the client communicate directly with the database server.
Figure 5 shows the 3-tier deployment model for a smart client application.
Figure 5. 3-tier smart client deployment

It is also possible to use a 3-tier deployment for a web application. The motivation for doing this
is to gain security by isolating the web server from your organization’s internal network by use of a
second firewall. In Figure 6, the dashed lines represent firewall boundaries.

Rev 0.4 (draft)
Figure 6. 3-tier web deployment
In a 3-tier deployment, the data portal is configured to run in remote mode, so the server-side
components of the data portal are running on a separate machine from the client-side components.
The recommended way to configure a remote data portal is to use the WCF channel provided by
the data portal.
This involves setting up and configuring an application server host, with a network endpoint that
is available to the data portal proxy running on the client. As you can imagine, the client also must
be configured to know the address of that network endpoint.
It is important to understand that in a 3-tier deployment, the client-side application components
do not need to have the credentials for the database, or any access to the database at all. Only the
application server should have the database credentials.
If you are using a pluggable Data Access layer, like those described in the Using CSLA 4: Data
Access ebook, the data access assemblies do not need to be deployed to the client workstation.
They only need to be deployed to the application server.
4-tier Deployment
Silverlight and WP7 applications can be deployed into a 4-tier model.
Because most Silverlight applications are deployed to the client workstation from a web server,
it is often natural for the application to make service calls back to that same web server. If the web
server is allowed to interact with the database server directly, then the web server is also the
application server and you are using a 3-tier smart client deployment like that shown in Figure 5.
In some cases, the web server is not allowed to interact directly with the database server. This is
usually due to security restrictions, where the web server must communicate through a second
firewall to interact with other servers in your organization’s network. To enable this scenario, the
Silverlight data portal supports a 4-tier deployment as shown in Figure 7.

Rev 0.4 (draft)
Figure 7. 4-tier Silverlight deployment
In this deployment model, the client workstation configures the data portal to call a remote
server, typically using the WCF channel. That remote server is the web server, and the web server
has a data portal endpoint configured so it can be invoked by the client.
The client has no database credentials, nor should the application’s data access assemblies be
deployed to the client.
The web server doesn’t have database credentials or data access assemblies either. Instead, it
has the business assemblies, and it is configured to listen for data portal calls from the client. The
Silverlight data portal is configured to act as a message relay, accepting messages from the client,
and passing them through to the application server.
Before the web server passes a client message to the application server, it can choose to
examine the message for validity. In other words, you have an opportunity to check the client
request to see if you feel it is a valid request before allowing it to travel to the application server
that is running deeper in your organization’s network.
The application server is configured as a normal data portal application server, with a standard
data portal endpoint that can be called by the web server. The application server is configured the
same as in a 3-tier deployment, but it is invoked by the web server on behalf of the client, instead of
by the client directly.
The application server will have the database credentials, and it is on the application server
where you will deploy your data access assemblies.
At this point you should have a high-level understanding of the 1-, 2-, 3-, and 4-tier deployment
models supported by the data portal and CSLA .NET. The Using CSLA 4: CSLA .NET Overview ebook
discusses more models, but they are all variations on the models I am discussing in this chapter.
There are two primary points of application configuration that determine the number of tiers the
application is using:
Rev 0.4 (draft)
1. Between the client and application server
2. Between the application and the database server
Configuring an application to interact with a database server is outside the scope of this book.
That configuration is dependent on the type of database and database server technology you are
using, and can be very different for SQL Server Compact Edition, SQL Server, Oracle, XML files, text
files, or the many non-relational databases that have become popular recently.
The primary difference between 1- and 2-tier models is the configuration of the database and
database server.
The rest of this chapter will focus on how the data portal is configured to use the local channel
for 1- and 2-tier models, or the WCF channel for 3- and 4-tier models.
Using the Local Channel

The local channel doesn’t cross any network, or even AppDomain, boundary when the client-side
data portal components interact with the server-side components. The “server-side” components
are loaded and run within the same AppDomain as the client-side components.
In a smart client application, this means that the server-side components run on the client
workstation along with the rest of the application. In a web application, the server-side components
run on the web server, along with the “client-side” components.
You should use the local channel to deploy an application in 1- and 2-tier models.
Client Configuration
When you use the local channel, the client-side and server-side data portal components all run on
the same machine, and in the same AppDomain. This means that there is no “server configuration”
of the data portal, because there is no real server.
All data portal configuration is client configuration in a 1- or 2-tier deployment. The techniques
and defaults for data portal configuration are different between .NET, Silverlight, and WP7. I’ll
discuss each platform.
.NET Configuration
In a .NET application (such as WPF or ASP.NET), the data portal defaults to using the local channel.
This means you can use the data portal in a 1- or 2-tier application without the need to do any
configuration.
If you do want to explicitly configure the data portal to use the local channel, you need to add a
CslaDataPortalProxy entry to the appSettings section of the app.config or web.config file:
<appSettings>
<add key="CslaDataPortalProxy" value="Local" />
</appSettings>
This is not necessary, because it is the default.

Rev 0.4 (draft)
Silverlight Configuration
In a Silverlight application, the data portal defaults to using the WCF channel. The reason is that
Silverlight applications can’t directly interact with a database, so most Silverlight applications will
need to invoke an application server to operate.
The local channel is available in a Silverlight application to support two primary scenarios:
1. The application is a 1-tier application, and is storing its data in isolated storage
2. The application is an SOA “edge application” that is invoking services (SOAP or REST)
The data portal is typically configured through code as the Silverlight application first starts. This
means adding code to the App.xaml.cs file in the Silverlight application project:
private void Application_Startup(object sender, StartupEventArgs e)
{
Csla.DataPortal.ProxyTypeName = "Local";
this.RootVisual = new MainPage();
}
Specifically, the ProxyTypeName property of the Csla.DataPortal class needs to be set to

"Local". This will cause the data portal to use the local channel, so the “server-side” data portal
components run on the Silverlight client along with the rest of the application code.
As I discussed in the Using CSLA 4: Data Access ebook, the Silverlight data portal is designed to
support asynchronous service calls when running in a Silverlight application. Because Silverlight
requires that all server calls be asynchronous, the server-side data portal behaviors provided to a
Silverlight application support asynchronous interaction.
If you use one of the encapsulated data portal models, this means that all the DataPortal_XYZ
method signatures include an asynchronous callback handler that you must invoke when the
method completes (even in the case of an exception).
If you use one of the object factory data portal models, this means that the method signatures of
all methods in an object factory also include an asynchronous callback handler. Again, that callback
must be invoked when the method completes, even if an exception occurs.
The Using CSLA 4: Data Access ebook includes a complete discussion and examples of these
asynchronous methods.
WP7 Configuration
In a WP7 application, the data portal defaults to using the local channel. Although a WP7
application is a Silverlight application, the most common scenario for a WP7 application is that it
will store data locally in isolated storage, or that it will invoke SOAP or REST services on a server.
If you do want to explicitly set the ProxyTypeName to "Local" for a WP7 application, you need to
edit the project’s App.xaml.cs file and set the property in the constructor of the App class:
public App()
{
// other code goes here

}
Rev 0.4 (draft)
This is not necessary, because it is the default.
The same asynchronous constraints apply to WP7 as to normal Silverlight. This means that the
DataPortal_XYZ methods or object factory methods accept an asynchronous callback handler. You
must invoke this handler when each method completes, even in the case of an exception.
The Using CSLA 4: Data Access ebook includes a complete discussion about implementing data
access invocation code in Silverlight and WP7.
Serialization and AutoCloneOnUpdate

By default, when using the local channel, the data portal serializes all criteria and business objects
between the client-side and server-side data portal. This ensures that the application behaves the
same in a 1- or 2-tier deployment as it does in a 3- or 4-tier deployment, where the data portal
messages are serialized to travel over the network.
Serializing objects does incur some overhead. The serialization used by the local channel is the
same as if the data portal were calling a remote application server, and so the overhead is no
different. If you want to avoid this overhead, it is possible to disable the automatic serialization
(cloning) of the objects when using the local channel.
The option to disable this feature is only available for .NET applications. Because Silverlight and
WP7 applications always use the asynchronous data portal, the feature is required in those types of
application.
You should only disable this feature if you have a complete understanding of the
consequences, and are willing to alter your application code to deal with the
resulting behaviors.
If you use the asynchronous data portal and you disable automatic cloning, you can encounter
cross-threading exceptions. The data access code may be running on a background thread, and if
your object graph is bound to the UI then the PropertyChanged and CollectionChanged events
may be raised on that background thread. Because .NET UI technologies are not threadsafe, they
throw a cross-threading exception when this happens, to avoid corruption of the UI.
Another issue you may encounter, is that without cloning, business objects bound to the UI
through data binding will remain bound while they are being updated by your data access code.
This can lead to UI flickering and poor performance, as the UI attempts to remain current while the
object graph is being manipulated by the data access code.
The most complex issue is that a failure during a data portal update operation can leave the
object graph in an indeterminate state. Although the database update should be transactionally
protected and will roll back, the state of your objects in memory will be left partially updated, and
therefore will be invalid.
This happens because during the update operation the object graph is changed to reflect any
database-generated primary key values, updated timestamp values, and so forth. Those changes
are made to the objects in memory as the data is updated in the database. If the database update
fails part way through the process, the database typically rolls back and all changes are undone. But
the properties of your objects in memory remain changed, and are therefore wrong.
Rev 0.4 (draft)
When the data portal’s automatic cloning feature is enabled, that invalid object graph is
automatically discarded, and your application continues to use the object graph as it was before the
failed database update was attempted. This is good, because it means your application has access
to a consistent and valid object graph.
If you disable the automatic cloning feature, it is up to your application code to detect that a
database update has failed, and to discard the object graph. You must write this code, typically by
overriding the Save method of each business class, or by handling this situation in your UI code.
To disable the automatic cloning feature, you will set the CslaAutoCloneOnUpdate configuration
value to false in the app.config or web.config file:
<appSettings>
<add key="CslaAutoCloneOnUpdate" value="false" />
</appSettings>
This configuration value defaults to true. Setting it to false disables the feature.
At this point you should understand how to configure the data portal to use the local channel for
.NET, Silverlight, and WP7 applications. I will move on to discuss the use of the WCF channel.
Using the WCF Channel

There are two different WCF channels in the data portal, one for .NET and the other for Silverlight
and WP7. The reason there are different channels, is that the WCF implementation for Silverlight
and WP7 is a subset of the full WCF implementation available on the .NET platform.
Each WCF channel consists of a WcfProxy class that runs on the client, and a WcfPortal class that
runs on the server.
In many applications, using the WCF channel is a matter of configuring the client and server
appropriately. In some cases you may need to customize the behavior of the WcfProxy class by
implementing a subclass and overriding its properties or methods. This is required for certain
security configurations, or WCF bindings.
Windows Communication Foundation (WCF)

As you can imagine, the data portal’s WCF channel uses the Windows Communication Foundation
(WCF) technology to communicate between the client and server. WCF is extremely flexible and
configurable. The most complex part about using the WCF channel is typically the configuration of
WCF itself.
A complete discussion of WCF configuration is outside the scope of this book. Full coverage of
this topic would take hundreds of pages. Here are some resources you should consult for detailed
WCF configuration information:
 http://msdn.com/wcf/
 http://wcfsecurity.codeplex.com/
 http://wcf.codeplex.com/documentation
In this chapter I will focus on the configuration of the data portal, along with some WCF
configuration details necessary for common application scenarios. However, it is necessary to
Rev 0.4 (draft)
understand some of the basic WCF configuration concepts and terminology to even begin this
discussion.
Basic WCF Configuration

WCF requires that the client and server define three primary elements to establish a connection:
1. Address
2. Binding
3. Contract
This is sometimes called the “ABC” of WCF. These three elements are what define every WCF
service. And any client that calls a WCF service must configure itself to match the service’s address,
binding, and contract. For example, here’s the configuration of a client that is calling a WCF service:
<client>
<endpoint name="BasicHttpBinding_IWcfPortal"
address="http://localhost:21647/SlPortal.svc"
binding="basicHttpBinding"
contract="WcfPortal.IWcfPortal" />
</client>
You can see the address, binding, and contract in the configuration for the service.
The WCF data portal channel consists of a WCF service, and client code to call that service.
Although the contract is defined by the channel, it is up to you to choose the binding and address
for the service.
Address
The address is the URI (universal resource identifier) or network name where the service is hosted.
In many cases this is an HTTP URL, for example:
http://myserver.mycompany.com/myapplication/WcfPortal.svc
When a WCF service is hosted in IIS, all parts of the address except the name of the svc file are
defined by the web server. If you host your WCF service in a custom Windows service, then you will
explicitly define the address.
Binding
The format of the address will be different depending on the WCF binding that is used. The binding
controls how WCF communicates between client and server. There are several bindings that use
HTTP. There are also bindings that use TCP sockets, named pipes, MSMQ queues, and other
network technologies.
The address of the service will depend on the binding that is used. In the example above, the
service must be configured to use one of the HTTP bindings. If the service is configured to use one
of the TCP bindings, the address might look more like this:
tcp://myserver.mycompany.com:12004/WcfPortal.svc

Rev 0.4 (draft)
Other bindings may use different address formats. Consult the documentation for the binding
you are using to determine the address requirements.
Some bindings are synchronous, and others are asynchronous. The HTTP, TCP, and named pipes
bindings are synchronous. This means that the client code calling a service waits until the service
completes before continuing.
The MSMQ bindings are an example of asynchronous bindings. With an asynchronous binding,
services can’t directly return any values, and the client code calling a service doesn’t wait for the
service to complete or respond. The client sends the message to the service, and continues on with
its work.
The data portal is designed to work only with synchronous bindings. The client-side data portal
components are designed with the assumption that the client code will wait until the service
completes and returns its result to the client.
Contract
The service contract defines the service interface. A service contract consists of three parts:
1. Operation contract
2. Data contracts
3. Fault contracts
The operation contract defines the methods a service implements. These methods can be
invoked by the client that is calling the service.
The data contracts define the properties for the messages that are passed to and from each
service method. If a method accepts a message object of type RequestMessage, then the
RequestMessage data contract is part of the overall contract for the service.
The fault contracts define the messages returned from the service in case of failure. When
designing a service interface, it is important to view failure conditions as a valid part of the service.
Each failure condition is typically described using a fault, and an associated data contract that
contains the information about the fault.
When using the WCF data portal channel, the service contract is defined by CSLA .NET. The .NET
contract is IWcfPortal from the Csla.Server.Hosts namespace. The Silverlight contract is also
IWcfPortal, but from the Csla.Server.Hosts.Silverlight namespace.
If you create your own data portal channel that uses WCF, you need to define your own contract
for your service implementation. I describe how to create a custom data portal channel in Chapter
4.
Customizing a WCF EndPoint

Together, the address, binding, and contract of a WCF service are often referred to as the service
endpoint. Although an endpoint is defined by these three elements, many endpoints are more
complex.

Rev 0.4 (draft)
Most WCF bindings have many options that can be configured to control how the binding works.
And most application scenarios require at least some custom control over each binding. At a
minimum, the maximum message sizes allowed by bindings are almost always too small.
Additionally, you will usually have to configure the binding to fit into your network’s security model.
It is also possible to control some behaviors of a WCF service by configuring service behaviors.
These behaviors can control various aspects of a service, including how the service returns server
errors to the client, whether the service exposes metadata to callers, or how it should behave in
debug mode.
In this section, I will focus on the binding and service configuration concepts required for the
data portal. Please refer to the WCF configuration resources listed earlier for information about
security or other more advanced configuration topics.
Message Size Limits on Bindings

One important area of customization deals with the default message size and serialization limits
defined by many WCF bindings. In most cases, the default limits are too low. If you don’t raise the
limits, your application will get an exception when trying to transfer object graphs between client
and server.
Here’s an example of raising the limits for the basicHttpBinding binding on a .NET server:
<bindings>
<basicHttpBinding>
<binding name="basicHttpBinding_IWcfPortal"
maxReceivedMessageSize="2147483647">
<readerQuotas maxBytesPerRead="2147483647"
maxArrayLength="2147483647"
maxStringContentLength="2147483647"
maxNameTableCharCount="2147483647"
maxDepth="2147483647"/>
</binding>
</basicHttpBinding>
</bindings>
This bindings configuration element is placed in the system.serviceModel element in the

server’s web.config file.
It is important to understand that when WCF is running in IIS, the ASP.NET and IIS size limits also
apply. Just changing WCF to allow a larger data transfer often isn’t sufficient, because ASP.NET or IIS
can also limit the data transfer. To avoid this, you also need to adjust those limits in the web.config
file. For example:
<system.web>
<httpRuntime maxRequestLength="2147483647"/>
</system.web>
Other hosting environments might have their own limits and customization techniques. You
should understand the hosting environment you are using for your application server, and how to
configure that specific environment.
WCF may have data size limits on the client as well. Here’s an example of raising the limits for
the basicHttpBinding binding on a Silverlight client:
<bindings>
<basicHttpBinding>

Rev 0.4 (draft)
<binding name="BasicHttpBinding_IWcfPortal"
maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647"
receiveTimeout="10" sendTimeout="10">
</binding>
</basicHttpBinding>
</bindings>
These settings also override the values for the send and receive timeouts, demonstrating some
other options you can set on your bindings.
As I discuss specific configurations for .NET and Silverlight I’ll use similar configuration elements.
Returning Faults
The data portal will return detail about server exceptions to the client. This is possible due to a
configuration setting applied to the service endpoint that allows the information to be returned. On
the .NET server, a custom behavior is applied to the service. For example:
<behaviors>
<serviceBehaviors>
<behavior name="returnFaults">
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
The service configuration indicates that this custom behavior should be used through the
behaviorConfiguration property on the service element. For example:
<service name="Csla.Server.Hosts.WcfPortal" behaviorConfiguration="returnFaults">
<endpoint binding="wsHttpBinding" bindingConfiguration="wsHttpBinding_IWcfPortal"
contract="Csla.Server.Hosts.IWcfPortal" />
</service>
This configuration is required for the data portal to operate correctly.

In this section of the chapter, I have discussed some basic WCF configuration concepts. As I
discuss each client and server configuration, I will demonstrate how these WCF concepts are used
to enable the use of the data portal.
Troubleshooting Services
It can sometimes be challenging to troubleshoot WCF connection issues. Many of the exceptions
returned by WCF or the CSLA .NET data portal are obscure or don’t provide detail about the real
issue.
Perhaps the most important troubleshooting tip for WCF services is to right-click on the svc file
in Solution Explorer, and to choose the View in Browser menu option. This will bring up a
browser window to display metadata about the service. If the browser displays error or exception
information, it is a clear indication that the service configuration in the web.config file is in error.
WCF can be configured to write detailed information to a .NET trace listener. You configure this
behavior in the server’s web.config file by adding a top level system.diagnostics element to the
configuration. This element looks like this:
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing" propagateActivity="true">
Rev 0.4 (draft)
<listeners>
<add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\temp\WcfTrace.xml" />
</listeners>
</source>
</sources>
<trace autoflush="true" />
</system.diagnostics>
You should change the c:\temp\WcfTrace.xml path and filename to a location where the service
host process has write permissions on your computer. As client applications interact with the WCF
service on the server, detailed trace information, often including important exception detail, is
written to this file.
The client may be a WPF, Silverlight, WP7, or Windows Forms smart client application. Or it may be
code running on a web server for an ASP.NET or service application. The configuration techniques
and defaults for each platform are different.
.NET Configuration
A .NET client might be a smart-client WPF or Windows Forms application, or an ASP.NET
application. In the case of an ASP.NET Web Forms, ASP.NET MVC, or service interface, the “client” is
the web server that is using the data portal to communicate with an application server.
In a .NET application the data portal is configured to use the WCF channel by setting the
CslaDataPortalProxy value in the app.config or web.config file:
<appSettings>
<add key="CslaDataPortalProxy" value="Csla.DataPortalClient.WcfProxy, Csla" />
</appSettings>
The CslaDataPortalProxy configuration value is set to the assembly qualified type name of the
data portal proxy class. In this case, it is the WcfProxy class from the Csla.DataPortalClient
namespace, in the Csla assembly.
You must also provide the client with the URL of the application server endpoint. This can be
done in three ways:
1. Using the CslaDataPortalUrl configuration value
2. Configuration of WCF in the app.config or web.config file
3. Configuration of WCF in a subclass of the WcfProxy class
I’ll discuss each option.
Setting the CslaDataPortalUrl Value

The simplest way to provide the server URL to the WCF data portal proxy is to set the
CslaDataPortalUrl configuration value in the client’s app.config or web.config file:
<appSettings>
<add key="CslaDataPortalProxy" value="Csla.DataPortalClient.WcfProxy, Csla"/>
<add key="CslaDataPortalUrl" value="http://localhost:21647/WcfPortal.svc"/>
</appSettings>
Rev 0.4 (draft)
The data portal’s WCF proxy uses this URL to communicate with the server, using the
wsHttpBinding with the message size limits raised to their maximum values.
Because the most common configuration is to use wsHttpBinding with maximum message size
limits, it is very likely that you can use the CslaDataPortalUrl configuration technique in your
application.
Using a Configuration File

If you need more control over the configuration of WCF on the client, you can choose to provide
explicit client configuration for the data portal’s WCF proxy. In this case you must not provide a
CslaDataPortalUrl configuration value.
Instead, you will provide the configuration for the WCF service in a system.serviceModel
element of the app.config or web.config file on the client:
<system.serviceModel>
<client>
<endpoint name="WcfDataPortal"
address="http://localhost:22627/WcfPortal.svc"
binding="wsHttpBinding"
contract="Csla.Server.Hosts.IWcfPortal"/>
</client>
</system.serviceModel>
The endpoint name expected by the data portal proxy is WcfDataPortal. Within this endpoint
element you must provide all necessary WCF configuration values for your environment. At a
minimum, you must provide the address, binding, and contract values shown in the example,
using an address and binding appropriate for your server.
The contract value will always be Csla.Server.Hosts.IWcfPortal when you are using the
standard CSLA .NET data portal WCF channel.
Subclassing WcfProxy
Sometimes, you will need even more control over the WCF client configuration than can be
provided through a configuration file. It is also possible that you will want to avoid putting the WCF
configuration into a file, but would rather have the values hardcoded in the application, or loaded
from some other source.
In these cases, you can create a subclass of the WcfProxy class from the Csla.DataPortalClient
namespace. The WcfProxy class is designed to enable customization of the WCF client without the
need to create a completely custom data portal channel. Table 1 lists the members of the WcfProxy
class you might use for customization.
Member Description
EndPoint property Set this value to control the name of the service configuration file
element used for WCF configuration on the client; default is
WcfDataPortal
GetChannelFactory method Override this method to create the ChannelFactory<IWcfPortal>
used to create the IWcfPortal proxy object by the default
GetProxy method implementation

Rev 0.4 (draft)
GetProxy method Override this method to create the IWcfPortal proxy object; this is
normally done by using the channel factory created by the
GetChannelFactory method
Table 1. Members of the .NET WcfProxy class used for customization

The simplest customization is to change the EndPoint property to control which service
element is used from the configuration file. This can be a useful customization if your configuration
file has several service elements for different application deployment scenarios. For example, you
might have application servers in different geographic locations around the world, and the client
might select a different service element based on the user’s physical location.
You should have a solid understanding of WCF channel factories and proxy objects before
attempting to override the GetChannelFactory or GetProxy methods. Some security configurations
require client credentials or encryption certificates to be provided to the channel factory, or during
proxy creation, and that is the most common reason for overriding these methods.
I will discuss the creation of a custom WCF proxy class in Chapter 4.
Once you have a custom WCF proxy class, you must configure the CslaDataPortalProxy value to
use your custom class. For example:
<appSettings>
<add key="CslaDataPortalProxy" value="MyAssembly.MyWcfProxy,MyAssembly" />
</appSettings>
This tells the data portal to use your custom proxy instead of the standard WcfProxy class.
Many .NET applications can simply set the CslaDataPortalProxy and CslaDataPortalUrl
configuration values on the client. If you need more control over the client configuration, you can
provide explicit WCF configuration through the application’s configuration file, or create a subclass
of the WcfProxy class.
Silverlight Configuration
A Silverlight application will use the WCF data portal channel by default, so you don’t need to
configure the client to use WCF. You do need to provide the server URL, and you might provide
custom configuration of WCF on the client.
As in a .NET application, there are three ways to configure the client to communicate with the
application server:
1. Set static properties on the WcfProxy class
2. Configuration of WCF in the ServiceReferences.ClientConfig file
3. Configuration of WCF in a subclass of the WcfProxy class
Even using the maximum message size limits for WCF on Silverlight, most applications will need
to use compression to reduce the size of messages sent through the data portal. This is partially
because of WCF message size limitations on Silverlight, and partially because the MobileFormatter
(discussed further in Chapter 3) often generates large data streams.

Rev 0.4 (draft)
Most Silverlight applications will require compression for the data portal channel.
Because of this, the most common configuration technique for Silverlight applications is to
create a subclass of the WcfProxy class. I provide a detailed walkthrough in Chapter 4, showing how
to create a compressed WCF data portal channel for Silverlight and WP7.
Setting Properties on the WcfProxy Class

The WcfProxy class in the Csla.DataPortalClient namespace has two static properties you can
set to provide the WCF channel with configuration information. These properties are typically set in
the Application_Startup method in the App.xaml.cs file of the application.
The DefaultUrl property is used to specify the URL of the application server. For example:
{
Csla.DataPortalClient.WcfProxy.DefaultUrl = "http://localhost:21647/SlPortal.svc";
}
If only the DefaultUrl property is specified, the WCF data portal proxy will default to using a
basicHttpBinding binding, with the message size limits set to their maximum values.
You can also explicitly provide a WCF Binding object by setting the DefaultBinding property:
{
var binding = new BasicHttpBinding();
binding.MaxBufferSize = int.MaxValue;
binding.MaxReceivedMessageSize = int.MaxValue;
binding.ReceiveTimeout = TimeSpan.FromMinutes(10);
binding.SendTimeout = TimeSpan.FromMinutes(10);
binding.OpenTimeout = TimeSpan.FromMinutes(10);
Csla.DataPortalClient.WcfProxy.DefaultBinding = binding;
}
This example creates a basicHttpBinding with the message size limits set to their maximum
values, just like the default binding used if only the DefaultUrl property is specified.
Using a Configuration File

It is also possible to configure a Silverlight client application with values in a
ServiceReferences.ClientConfig file that is part of the Silverlight application project. For
example:
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IWcfPortal"
maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647"
receiveTimeout="10" sendTimeout="10">
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint name="BasicHttpBinding_IWcfPortal"
address="http://localhost:21647/SlPortal.svc"
Rev 0.4 (draft)
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IWcfPortal"
contract="WcfPortal.IWcfPortal" />
</client>
This example sets the address, binding, and contract for the application server. The endpoint
name is BasicHttpBinding_IWcfPortal, and that is the default name used by the WCF data portal
proxy. You can override that name by setting the DefaultEndPoint property on the WcfProxy class:
{
Csla.DataPortalClient.WcfProxy.DefaultEndPoint = "MyEndPointName";

}
The example configuration also customizes the basicHttpBinding to set the message size limits
to their maximum values.
Subclassing WcfProxy
The WcfProxy class for Silverlight is designed so you can create a subclass to customize the data
portal channel without having to write your own proxy and host from scratch.
The primary reason for creating a subclass is to implement compression to minimize the amount
of data passed between client and server. In Chapter 4, there is a section devoted to a detailed
walkthrough of adding compression to the Silverlight WCF data portal channel.
Table 2 lists the members of the WcfProxy<T> class you might use or override in a subclass.
Member Description
Binding property Set this value to create a custom WCF Binding object for use in
communications with the application server
DataPortalUrl property Set this value to the URL for the application server endpoint
EndPoint property Set this value to the name of the endpoint element in the
ServiceReferences.ClientConfig file that should be used for
WCF configuration
GetProxy method Override this method to create the IWcfPortal proxy object; this is
normally done by using the channel factory created by the
GetChannelFactory method
ConvertRequest method Override the two overloads of this method to compress the data in
the byte stream being sent from the client to the application server
on each data portal request
ConvertResponse method Override this method to decompress the data in the byte stream
being received by the client from the application server
Table 2. Members of the Silverlight WcfProxy<T> class used for customization

Normally the Binding, DataPortalUrl, and EndPoint properties are set using the default values
from the static properties on the WcfProxy class. Your subclass of WcfProxy<T> can set these
property values as you choose, instead of using those defaults.

Rev 0.4 (draft)
If you need explicit control over how the WCF proxy object is created, you can override the
GetProxy method. You should have a solid understanding of WCF proxy objects before attempting
to override this method. Controlling the creation of the proxy object enables certain security
scenarios where client credentials or certificates are required by the server.
The ConvertRequest and ConvertResponse methods will be overridden to compress the data
flowing to and from the application server. I will demonstrate the use of these methods in Chapter
4.
Any time you use a custom data portal proxy type, you must tell the data portal to use your
custom type. This is done by setting the ProxyTypeName property of the DataPortal class as the
application starts up. For example, this code in App.xaml.cs tells the data portal to use the
standard WcfProxy<T> type:
{
Csla.DataPortal.ProxyTypeName = typeof(Csla.DataPortalClient.WcfProxy<>).AssemblyQualifiedName;
}
To use your custom proxy type, provide the name of your type instead of the one shown here.
Most Silverlight applications will implement compression to minimize the data transferred
between client and server. When this is done by subclassing the WcfProxy<T> class, the static
properties on the WcfProxy class (DefaultUrl, DefaultBinding, and DefaultEndPoint) can be used
to configure the data portal. For more complete customization, your subclass of WcfProxy<T> may
completely override the creation of the WCF binding and proxy objects.
WP7 Configuration
A Windows Phone application defaults to using the local data portal channel. This is because the
data portal requires that the client and application server use the exact same business assemblies,
and it can be difficult to control exactly when (or if) a user updates your application on their phone.
If you do choose to use a remote data portal configuration for a WP7 application, you will need
to configure the client application to use the WCF data portal. This is done by setting the
ProxyTypeName property of the DataPortal class as the application starts:
public App()
{
...
You must also specify the URL of the application server, along with any other client-side
configuration.
Configuring a WP7 application is exactly the same as configuring a Silverlight application. Please
refer to the previous section on Silverlight configuration for details.
At this point, you should understand the basic configuration options for a .NET, Silverlight, and
WP7 client. I will now discuss how to set up and configure an application server using the data
portal.

Rev 0.4 (draft)
Application Server Configuration
The data portal has two WCF server implementations, one for .NET and the other for Silverlight and
WP7. These WCF data portal host components must run within some environment on the
application server. Possible environments include:
 IIS and ASP.NET

 Windows Server AppFabric
 Windows Azure
 Windows Activiation Service (WAS)
 A custom Windows service
Any environment that will host a CSLA .NET web application or the data portal must provide
FullTrust security in Microsoft .NET.
The server-side components of the CSLA .NET framework require FullTrust

security, and will not run in a partial trust environment.
When selecting a host environment or hosting provider, make sure your server-side components
will have access to FullTrust security in .NET.
Today, most organizations host application server components in IIS, but over time they will
probably move toward hosting in Windows Server AppFabric. Components hosted in Windows
Server AppFabric still run in IIS, but have additional administrative and monitoring capabilities.
It is also possible to host the data portal application server components in Windows Azure. This
means you can take advantage of the cloud-based features provided by the Windows Azure
environment in the server-side data portal, and in the code you author or invoke in your
DataPortal_XYZ methods or object factory methods.
In environments where IIS is not available on the application server, you might choose to use the
Windows Activation Service (WAS) or a custom Windows service to host the data portal. These
options allow the server-side components to be hosted without the need for IIS or Windows Server
AppFabric.
I’ll discuss each of the options in more detail, with a specific focus on Windows Server AppFabric
and Windows Azure. First though, I’ll discuss one detail that is unique to Silverlight applications.
Silverlight Cross-Domain Policy

A Silverlight application can only make server calls to the server from which the application was
downloaded, or to servers that explicitly grant permission to Silverlight through a cross-domain
policy file.
This is a security feature that is designed to prevent Silverlight applications from communicating
with arbitrary servers. Imagine a user inside your organization’s firewall that accesses a Silverlight
application from a public web site. It would not be good if that application could attempt to
communicate with your internal servers without restriction.

Rev 0.4 (draft)
A complete discussion of cross-domain policy files and all related options is outside the scope of
this book. But it is important to understand that most application servers that support Silverlight
applications will have such a policy file.
The file is named clientaccesspolicy.xml, and must be available from the top level folder of
the web site’s virtual root. Here’s an example of a file that grants open access to the site for use by
Silverlight applications:
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Most of the sample application server projects used in this ebook include a copy of this
clientaccesspolicy.xml file.
Hosting in IIS and ASP.NET

The server-side data portal components can be hosted in any ASP.NET web site running in IIS. This
includes a site dedicated to hosting WCF services, or sites running ASP.NET Web Forms or ASP.NET
MVC. If your site can host a WCF service, it can host the data portal.
In the sample code download for this ebook, you will find an IISHost solution. This solution
includes a Silverlight client application that interacts with the data portal. The data portal is hosted
in the IISHost project.
Creating the Web Project

The IISHost project is an ASP.NET Empty Web Application as shown in Figure 8.

Rev 0.4 (draft)
Figure 8. Creating an ASP.NET Empty Web Application
Again, any ASP.NET or WCF project type will work. As long as the project creates a web site, and
allows ASP.NET or WCF code to run within the site, it can host the data portal.
In many cases, including the IISHost example, the web site will not only host the data portal,
but will also serve up web or Silverlight content. In the example, the IISHost web project hosts the
data portal, and provides access to the simple Silverlight client application.
Adding Project and Assembly References

The following components must be installed in the bin folder of the web site:
 Csla.dll
 Your business library assemblies (compiled for .NET)
 Your data access assemblies
 Any other assemblies required by your server-side code
I typically reference all required projects or assemblies in my web project in Visual Studio,
because that allows Visual Studio to manage the dependencies. If you don’t want to reference the
projects or assemblies, you can use some other deployment technology to ensure that the correct
assemblies are deployed to the web site’s bin folder.
In the IISHost project, I’ve added references to Csla.dll, and to the Library.Net, DataAccess,
and DataAccess.Mock projects. This ensures that the latest versions of my server-side components
will be in the bin folder each time I run, package, or deploy the solution from Visual Studio.

Rev 0.4 (draft)
Adding the Service Endpoint Files
The endpoint for a WCF service is a file with an svc extension. The IISHost project contains two svc
files.
The WcfPortal.svc file is the endpoint for the .NET data portal. This is the endpoint that will be
used by any .NET client applications, including those built with WPF, ASP.NET, Windows Forms, or
other .NET technologies.
It contains the name of the type that implements the service:
<% @ServiceHost Service="Csla.Server.Hosts.WcfPortal" %>
This WcfPortal class is located in the Csla.Server.Hosts namespace in Csla.dll. The svc file
provides WCF with the information necessary to locate that type.
Your data portal host project should only include the WcfPortal.svc file if you want to support
.NET client applications.
You should also understand that this file can have any name you choose. The name of this file is
part of the URL the client application will use to call the application server, and you can name the
file to control that part of the URL.
The SlPortal.svc file is the endpoint for the Silverlight data portal. This is the endpoint that will
be used by any Silverlight or WP7 client applications. It contains the name of the type that
implements the Silverlight data portal service:
<% @ServiceHost Service="Csla.Server.Hosts.Silverlight.WcfPortal" %>
Notice that the type name of the Silverlight WcfPortal class is different from the .NET class.
Your data portal host project should only include the SlPortal.svc file if you want to support
Silverlight or WP7 client applications. And again, there is nothing “magic” about this file name. You
can name the svc file anything you choose, as long as the client uses the same name in its server
URL.
Configuring IIS and ASP.NET

The next step in setting up the project is to configure WCF in the web.config file.
As I mentioned earlier in this chapter, you will probably want to raise the maximum request
length limit for IIS itself by setting the maxRequestLength property in the system.web element of
the configuration file:
<system.web>
<compilation debug="true" targetFramework="4.0" />
<httpRuntime maxRequestLength="2147483647"/>
</system.web>
During development you can host the web site in one of several locations, including:
 ASP.NET Development Web Server

 IIS Express
 IIS

Rev 0.4 (draft)
Prior to Visual Studio 2010 SP1, most developers would host in the ASP.NET Development Web
Server during development. In some cases, developers host sites in IIS to avoid limitations of the
ASP.NET Development Web Server.
If you have SP1 installed, you should consider using IIS Express, as it is a more robust option. The
use of IIS Express usually means there’s no need to install or use IIS on a development workstation.
The IISHost project in the sample download is configured to run in IIS Express.
At some point, either during development or at the time of deployment, you will need to install
the web site into IIS on the server.
When creating a virtual root in IIS to host the web site, that virtual root needs to be an
Application. In the IIS Manager you can right-click on the default web site and choose the Add
Application option shown in Figure 9.
Figure 9. Adding an Application in the IIS Manager

The virtual root can be configured in the subsequent dialog shown in Figure 10.

Rev 0.4 (draft)
Figure 10. Adding an application to IIS
There are many options for configuring virtual roots and applications in IIS, and this topic is
outside the scope of this ebook. There are many books and online resources that provide in-depth
information about configuring virtual roots in IIS for different environments, including
http://msdn.com and http://technet.com.
You will also need to configure the WCF service endpoints in the system.serviceModel element
of the web.config file. I’ll discuss the .NET and Silverlight configurations separately, even though
they are both in the same part of the configuration file. You can look at the full web.config file in
the sample download to see them together.
Configuring the .NET Data Portal

The .NET data portal requires configuration of a WCF endpoint, customization of the wsHttpBinding
binding, and a custom service behavior. Here are those elements:
<services>
<service name="Csla.Server.Hosts.WcfPortal"
behaviorConfiguration="returnFaults">
</service>
</services>
<bindings>
<wsHttpBinding>
<binding name="wsHttpBinding_IWcfPortal"
maxDepth="2147483647"/>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
Rev 0.4 (draft)
</behavior>
</serviceBehaviors>
</behaviors>
As I discussed earlier in this chapter, the endpoint is composed of an address, binding, and
contract. Because this service is hosted in IIS, the address is predefined and there’s no need for an
address property in the configuration of the endpoint. The address of this service is:
http://www.mycompany.com/mywebsite/WcfPortal.svc
The specific address will depend on the name of your organization’s Internet domain, and the
name of the virtual root into which the web site is deployed. Notice how the WcfPortal.svc file
name is the part of the URL that you can control.
The wsHttpBinding element is used to override the default configuration of the wsHttpBinding
object used by WCF. In this example I’m setting the message size limits to their maximum values.
The custom returnFaults behavior is used to tell WCF to return exception fault information to
the client, allowing the data portal to provide detailed exception data to the calling code. Notice
how the behaviorConfiguration property is set on the service element so WCF uses this behavior
for the data portal service.
Configuring the Silverlight Data Portal

The Silverlight data portal endpoint is configured much like the .NET endpoint, but it uses the
basicHttpBinding instead:
<services>
<service name="Csla.Server.Hosts.Silverlight.WcfPortal"
behaviorConfiguration="returnFaults" >
<endpoint binding="basicHttpBinding" bindingConfiguration="basicHttpBinding_IWcfPortal"
contract="Csla.Server.Hosts.Silverlight.IWcfPortal"/>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="basicHttpBinding_IWcfPortal"
maxDepth="2147483647"/>
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
</behavior>
</serviceBehaviors>
</behaviors>
As with the .NET endpoint, there is no explicit address set because the URL is derived from the
IIS host and the name of the svc file:
Rev 0.4 (draft)
http://www.mycompany.com/mywebsite/SlPortal.svc
The basicHttpBinding element is used to override the default message size limits for the
binding, allowing larger messages to pass over the network. And the returnFaults custom
behavior is used to allow WCF to return exception detail from the server for use by the client-side
data portal components.
At this point you should understand how to set up an ASP.NET web project to contain the WCF
data portal host components. This involves setting up a web project, adding assembly or project
references, the svc files, and configuring the WCF endpoints in the web.config file.
I will now move on to discuss the use of the WCF data portal host in Windows Server AppFabric.
Hosting in Windows Server AppFabric

Windows Server AppFabric integrates into IIS, adding extra management, monitoring, and tracing
capabilities to WCF services. The configuration of the data portal for Windows Server AppFabric is
identical to the previous section covering IIS, but there are some additional configuration options
you may choose to add in order to take advantage of the AppFabric features.
For this discussion, I am assuming that you have installed and configured Windows
Server AppFabric and IIS on your development workstation or server. Please refer to
http://msdn.com/appfabric for full product information and documentation.
To set up the WCF data portal host for Windows Server AppFabric you need to follow the same
steps as for IIS, including:
 Create an ASP.NET web project in Visual Studio

 Reference Csla.dll, your business assemblies or projects, and your data access assemblies
or projects
 Add appropriate svc files to the web project for the .NET and Silverlight data portal
endpoints
 Add appropriate system.serviceModel entries to web.config for the .NET and Silverlight
data portal endpoints
The Windows Server AppFabric features are only available in IIS itself. This means you can’t use
them in the ASP.NET Development Web Server, or in IIS Express.
The primary benefit of running the data portal in IIS with Windows Server AppFabric is that you
gain health monitoring, and the ability to use AppFabric for event logging. This information is
available through the AppFabric Dashboard in the IIS Manager, and provides valuable information
that is not otherwise available for WCF services hosted in IIS.
When the application is run, the Silverlight client application will invoke the data portal endpoint
hosted in Windows Server AppFabric, based on the DefaultUrl property value set as the
application starts:
{
Csla.DataPortalClient.WcfProxy.DefaultUrl = "http://localhost/IISHost/SlPortal.svc";

Rev 0.4 (draft)
}
I will now discuss how to configure the web application and WCF services for AppFabric health
monitoring and custom event logging.
Enabling Health Monitoring

The AppFabricHost solution contains an IISHost project. This is the same project as in the IISHost
solution I discussed in the previous section, but configured to take advantage of the AppFabric
features.
In this solution, the IISHost project is configured to run in IIS. You must run Visual Studio as an
administrator in order to use debugging or to otherwise interact with the project while it is
configured to run in IIS.
Figure 11 shows the IISHost web application selected in the IIS Manager administrative console.
Figure 11. IIS Manager administration console for IISHost application

On the far right, is a region for managing WCF and WF services as shown in Figure 12.

Rev 0.4 (draft)
Figure 12. Manage WCF and WF Services region in administration console
Clicking the Configure… link will bring up a dialog where you can configure various AppFabric
settings for your WCF services and WF workflows. Figure 13 shows the Monitoring pane of the
dialog, where you can enable writing events to the database, and can set the monitoring level for
this web application’s services.
Figure 13. Configuring AppFabric monitoring for WCF services

The monitor levels are:
 Troubleshooting
 End-To-End Monitoring
 Health Monitoring
Rev 0.4 (draft)
 Errors Only
 Off
These are in order of verbosity and overhead. The Health Monitoring level is appropriate for
most applications.
After configuring the web application for monitoring a microsoft.applicationServer element
has been added to the web.config file:
<microsoft.applicationServer>
<monitoring>
<default enabled="true"
connectionStringName="ApplicationServerMonitoringConnectionString"
monitoringLevel="HealthMonitoring" />
</monitoring>
</microsoft.applicationServer>
This element is used to configure AppFabric monitoring for the WCF services in the web site.
The enabled property indicates whether monitoring is enabled or disabled.
The connectionStringName propery must be the name of a database connection value available
in the ASP.NET configuration. That database must be configured for use by AppFabric. During the
installation of Windows Server AppFabric, the installer will set up the database and this connection
string name.
The monitoringLevel property indicates the level of detail that should be included in the logging
performed by AppFabric. For basic health monitoring, the value should be HealthMonitoring.
Additionally, some entries have been added to the system.serviceModel element in the
web.config file. I will discuss those entries in the next section when I talk about event logging with
AppFabric.
Once the web application has been configured for health monitoring, AppFabric will
automatically collect usage statistics for your WCF services, including the data portal endpoints.
Figure 14 shows the AppFabric Dashboard for the IISHost web application after the Silverlight
client application has been used to interact with the data portal a few times.

Rev 0.4 (draft)
Figure 14. AppFabric Dashboard showing data portal activity
Focusing on the WCF Call History section shown in Figure 15, you can see the name of the
endpoints that have been invoked, along with other high level summary information.
Figure 15. WCF Call History from the AppFabric Dashboard

You can click on the blue text elements, because they are hyperlinks. Each hyperlink drills into
detail about the high level statistic shown in the dashboard. Please refer to the AppFabric
documentation on http://msdn.com/appfabric for more detail about all the information collected
by AppFabric monitoring.

Rev 0.4 (draft)
Using Event Logging
You can write custom event information into the Windows Server AppFabric log when monitoring is
enabled for a service hosted in AppFabric. Events can be written to the log with different severity
levels, including information, warning, and error.
Custom events are logged only if the AppFabric monitoring level is at least End-to-End
Monitoring as shown in Figure 16.
Figure 16. Enabling End-to-End Monitoring

This updates the monitoring element in the web.config file:
<microsoft.applicationServer>
<monitoring>
<default enabled="true"
connectionStringName="ApplicationServerMonitoringConnectionString"
monitoringLevel="EndToEndMonitoring" />
</monitoring>
</microsoft.applicationServer>
When AppFabric monitoring is enabled for a WCF service, entries are also written into the
system.serviceModel configuration element. The diagnostics element configures logging of
events for services:
<diagnostics etwProviderId="029f8aa9-30ae-472f-aaa2-42db603a20d8">
<endToEndTracing propagateActivity="true" messageFlowTracing="true" />
</diagnostics>
Additionally, a custom behavior is defined:

<behavior name="">
<etwTracking profileName="EndToEndMonitoring Tracking Profile" />
</behavior>

Rev 0.4 (draft)
To use custom event logging, your WCF service must either use this behavior, or you need to
copy the etwTracking element into the behavior your service is already using. In the web.config
file, you can see that I have copied the element into the existing returnFaults behavior:
<etwTracking profileName="EndToEndMonitoring Tracking Profile" />
</behavior>
Because the .NET and Silverlight data portal endpoints already use this returnFaults behavior,
they will now also support custom event logging.
The Microsoft Developer & Platform Evangelism team has created a helper class to simplify the
code required to generate custom events. This class is available as part of the AppFabric WCF
Service Template. This template is discussed in Ron Jacob’s blog:
http://blogs.msdn.com/b/rjacobs/archive/2011/03/09/appfabric-wcf-service-c.aspx
The DataAccess.Mock project in the AppFabricHost solution includes the
DalManagerEventProvider class, based directly on the helper class created by Microsoft. You can
look through the code in that class to see how they create information, event, and error events for
AppFabric.
This helper class requires that the project reference the following assemblies:
 System.Configuration.dll
 System.ServiceModel.dll
 System.Web.dll
The DataAccess.Mock project includes these references.

I used the methods in the DalManagerEventProvider class to enhance the DalManager class in
the DataAccess.Mock project. This class now writes information or error events each time the
application performs a persistence operation using the data access code:
public class DalManager : DataAccess.IDalManager
{
static DalManagerEventProvider _eventProvider = new DalManagerEventProvider();
private static string _typeMask = typeof(DalManager).FullName.Replace("DalManager", @"{0}");
public T GetProvider<T>() where T : class

{
var typeName = string.Format(_typeMask, typeof(T).Name.Substring(1));
var type = Type.GetType(typeName);
if (type != null)
{
_eventProvider.WriteInformationEvent("DataAccess.Mock",
string.Format("DAL request for {0}", type.Name));
return Activator.CreateInstance(type) as T;
}
else
{
try
{
throw new NotImplementedException(typeName);
}
catch (Exception ex)
{
_eventProvider.WriteErrorEvent(ex);
Rev 0.4 (draft)
throw;
}
}
}
public void Dispose()

{ }
}
Each time the GetProvider method is called, it either finds an implementation of the requested
interface or it doesn’t. If an instance of the interface is found, an informational event is generated:
_eventProvider.WriteInformationEvent("DataAccess.Mock",
string.Format("DAL request for {0}", type.Name));
If an instance of the interface can’t be found, the code now handles the resulting exception, and
generates an error event for that exception:
_eventProvider.WriteErrorEvent(ex);
The exception is then re-thrown, so the failure is reported back to the client through the data
portal after it has been logged.
For demonstration purposes, I have altered the DataPortal_Update method in the PersonEdit
business class to request a type that isn’t implemented in the DataAccess.Mock project. This means
a new PersonEdit object can be inserted into the database, but an update will cause an exception.
When the application is run, the AppFabric Dashboard provides access to the custom events.
These events are available as you drill into the details about each specific service invocation. For
example, clicking on the service hyperlink in the Completed Calls list shown in Figure 17 will
bring up details about the invocations of that service.
Figure 17. Completed Calls summary in the AppFabric Dashboard

The query summary information is shown in Figure 18.

Rev 0.4 (draft)
Figure 18. Query Summary for SlPortal.svc service calls
Each OperationCompleted event has detail. Figure 19 shows the results of right-clicking on an
event and selecting the View All Related Events menu option.
Figure 19. Related event detail for a WCF service invocation

Clicking on any of these items will result in details about the item being displayed near the
bottom of the screen in the details area. For example, Figure 20 shows the detail for the custom
ServiceException event caused by an attempt to update a PersonEdit object.
Figure 20. Event details display in AppFabric Dashboard

Because this is an error event, the Errors tab is available to get even more information about
the event. Figure 21 shows this detail.

Rev 0.4 (draft)
Figure 21. Displaying exception detail about an error event
As you can see, the monitoring and custom event logging capabilities provided by Windows
Server AppFabric provide valuable capabilities not available with only IIS. At the same time, the
basic hosting model is identical to IIS, and so is familiar to most developers and server
administrators.
Hosting in Windows Azure

Windows Azure is Microsoft’s cloud-based server product. The server-side components of the data
portal can be hosted in a Windows Azure web role when using the WCF data portal channel. The
WCF endpoint for the data portal is exposed to clients from the Windows Azure cloud-based
servers.
For this discussion I assume you have installed the Windows Azure SDK on your
development workstation. This SDK is available from http://msdn.com/azure.
To deploy the application to the development test environment, you must configure
your Windows Azure SDK development environment. For this discussion I assume
you have configured your development machine for Azure development.
To deploy the application to actual Windows Azure servers, you must establish an
account with Microsoft and pay appropriate usage fees.
The AzureHost solution in the sample code download for this ebook includes an AzureHost
project. This is a Windows Azure Project created as shown in Figure 22.

Rev 0.4 (draft)
Figure 22. Creating a Windows Azure Project in Visual Studio
As part of the project creation process, the Windows Azure roles required by the application
must be identified. The minimum requirement to host the WCF data portal channel is an ASP.NET
Web Role as shown in Figure 23.
Figure 23. Adding an ASP.NET Web Role to the Azure project

The result is that the AzureHost solution has an AzureHost project that contains the
configuration for the Windows Azure roles. And it has a WebRole1 project that is the ASP.NET web
project that will be hosted in Windows Azure.

Rev 0.4 (draft)
The WebRole1 project is set up the same as the IISHost projects in the previous two examples.
This means it:
 References Csla.dll, your business assemblies or projects, and your data access assemblies
or projects
 Contains appropriate svc files to the web project for the .NET and Silverlight data portal
endpoints
 Has appropriate system.serviceModel entries to web.config for the .NET and Silverlight
data portal endpoints
The WebRole1 project also references the SilverlightUI project, so it hosts the Silverlight client
application.
In short, the WebRole1 project is identical to the IISHost project in the original IISHost solution
I used earlier in this chapter to demonstrate hosting in IIS.
The DataPortal_XYZ methods or your object factory methods, along with your data access code,
will all run in the Windows Azure environment. This means you can make use of any Windows
Azure features in that code, including the use of SQL Azure databases, Windows Azure Storage, and
Windows Azure AppFabric.
As with the other sample applications, the AzureHost solution uses the mock database
implemented by the DataAccess.Mock project.
Running the solution in Debug mode from Visual Studio will cause Visual Studio to do the
following:
1. Build the solution
2. Create an Azure deployment package
3. Run the Azure deployment package to deploy the solution to the Windows Azure compute
emulator
4. Open the browser to display the SilverlightUI application
The Silverlight client application will invoke the data portal endpoint hosted in the Windows
Azure compute simulator, based on the DefaultUrl property value set as the application starts:
{
Csla.DataPortalClient.WcfProxy.DefaultUrl = "http://127.0.0.1:81/SlPortal.svc";
}
Hosting the data portal in Windows Azure is virtually identical to hosting the data portal in IIS.
This means that it is easy to consider using Windows Azure as a host for your CSLA .NET application
server.

Rev 0.4 (draft)
Hosting in the Windows Activiation Service
The Windows Activation Service (WAS) is a Windows component that was introduced with
Windows Server 2008 and Windows Vista. It allows the hosting of WCF services without necessarily
requiring that IIS be installed on the computer.
In this discussion I assume you have installed, enabled, and configured WAS for use
on your development workstation. Because I’ll be demonstrating the use of the
netTcpBinding in WCF, I also assume you have installed IIS.
The primary value of using WAS is that a WCF service can be hosted with a protocol other than
HTTP. Specifically, WAS adds support for these protocols:
 TCP (WCF netTcpBinding and net.tcp:// URL)

 Named pipes (WCF netNamedPipeBinding and net.pipe:// URL)
 MSMQ (WCF msmqIntegrationBinding and msmq.formatname URI)
Because the data portal requires a synchronous WCF binding, only the TCP and named pipes
protocols are useful in this discussion.
WAS is designed to host a web application, just like IIS. This means that the same steps for
creating and configuring a web application to host the WCF data portal channel for IIS apply to
WAS. The WASHost solution in the sample code download for this ebook uses WAS to host the .NET
data portal, using the netTcpBinding in WCF.
Because Silverlight doesn’t support the netTcpBinding, you can’t use this binding from a
Silverlight client application. The WASHost solution contains a WpfUI project instead of the
SilverlightUI project used in the previous examples.
Configuring the .NET Client

The WpfUI client is configured to use the netTcpBinding to communicate with the application
server. Here is the client configuration from the app.config file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="CslaDataPortalProxy" value="Csla.DataPortalClient.WcfProxy,Csla"/>
</appSettings>
<client>
address="net.tcp://localhost:808/WASHost/WcfPortal.svc"
binding="netTcpBinding"
</client>
<bindings>
<netTcpBinding>
<binding portSharingEnabled="true"
<security mode="None" />

Rev 0.4 (draft)
maxDepth="2147483647"/>
</binding>
</netTcpBinding>
</bindings>
</configuration>
Notice that the binding property for the endpoint is netTcpBinding, and that the address
property specifies a net.tcp:// URL. The default port used by WAS for TCP communication is 808.
Also notice that the netTcpBinding is customized to set the message size limits to their
maximum values, and to control the security used for communication with the server.
Enabling the net.tcp Protocol

The WASHost project is configured to run in IIS. This means you must run Visual Studio as an
administrator to open the WASHost solution, and it also means the IIS Manager administrative
console can be used to configure the web application.
To enable the use of the net.tcp protocol for a web application, right-click on the application in
the IIS Manager console, choose Manage Application and then Advanced Settings. This will
bring up the dialog in Figure 24 where the net.tcp protocol can be added to the list of enabled
protocols.
Figure 24. Adding the net.tcp protocol to a web application

This step is necessary so IIS allows the use of the net.tcp protocol, and will properly activate the
service when clients attempt to use the service via TCP.
Configuring the Server

The final step is to configure the application server to use the netTcpBinding for the data portal
endpoint. This is done in the web.config file in the WASHost project.
The endpoint is configured to use the correct binding:
<endpoint binding="netTcpBinding"

Rev 0.4 (draft)
</service>
Notice that the service name, behaviorConfiguration, and contract properties are unchanged.
Only the binding property is different.
The server configuration also customizes the netTcpBinding to set the message size limits and
security:
<bindings>
<netTcpBinding>
<binding portSharingEnabled="true"
<security mode="None" />
maxDepth="2147483647"/>
</binding>
</netTcpBinding>
</bindings>
The netTcpBinding requires that the binding values on the client and server match.
It also requires that many binding properties be consistent across all uses of
netTcpBinding by different applications on the server. See the documentation from
http://msdn.com for more information.
When the solution is run, the WpfUI application launches and uses the net.tcp protocol to
communicate with the application server using TCP and port 808.
A consistent theme in all these hosting scenarios is that the application code is essentially
unchanged. In each case, I am changing the client and server configuration so WCF communicates
using the correct WCF binding and address to reach the server. At no point are the business classes
or data access classes affected by these changes. In this WAS example the client application
switched from Silverlight to WPF, only because Silverlight doesn’t support the TCP binding I wanted
to demonstrate.
Hosting in a Custom Windows Service

The final hosting model I will discuss is the use of a custom Windows service or other Windows
executable (EXE). Any Windows application can host WCF, and therefore the data portal.
You can use any supported protocol when hosting WCF in your own application or Windows
service. This includes:
 HTTP
 TCP
 Named pipes
The protocol selection is based on how the WCF endpoints are configured.
One of the challenges with building Windows services is debugging. It is notoriously difficult to
debug code running in a Windows service. To make initial debugging simpler, I always create a Class
Rev 0.4 (draft)
Library project to contain the code that does the real work of the service. Then I reference this
project from the Windows service project, as well as a Console Window project. Figure 25 illustrates
this relationship, using the project names from the WindowsHost solution in the sample code
download for this ebook.
Figure 25. Project references for creating a Windows service

The console application can be run in debug within Visual Studio, allowing the service code to be
easily tested and debugged. Once the code is working, the WindowsHostService.exe can be
installed as a Windows service.
Creating a WCF Host

The WindowsHost project in the WindowsHost solution is a Class Library project that contains the
code that implements the service behaviors. Hosting WCF doesn’t require much code, because the
WCF API does most of the work.
The WindowsHost project references several assemblies:
 Csla
 The business library projects or assemblies
 The data access projects or assemblies
 System.ServiceModel
The references to Csla.dll, the business code, and the data access code are required because
this is the host for the data portal. Like the web application projects discussed earlier in this
chapter, the data portal host needs access to these assemblies.
The reference to the System.ServiceModel assembly is required to host WCF. The
DataPortalHost class contains the code necessary to host WCF. The Start method creates and
initializes instances of ServiceHost objects:
public void Start()
{
if (_netService != null)
_netService.Close();
var netUri = ConfigurationManager.AppSettings["NetDataPortalUri"];

_netService = new ServiceHost(typeof(Csla.Server.Hosts.WcfPortal),
new System.Uri[]
{
new System.Uri(netUri)
});
_netService.Open();
Rev 0.4 (draft)
if (_slService != null)
_slService.Close();
var slUri = ConfigurationManager.AppSettings["SlDataPortalUri"];

_slService = new ServiceHost(typeof(Csla.Server.Hosts.Silverlight.WcfPortal),
new System.Uri[]
{
new System.Uri(slUri)
});
_slService.Open();
}
The _netService field represents the .NET data portal endpoint, and the _slService field
represents the Silverlight endpoint.
Although most of the configuration for these endpoints is in the host application’s app.config
file, the endpoint URI values are specified as the ServiceHost objects are created. Rather than
hardcoding the URI values, this code reads them from appSettings entries in the application’s
configuration file.
I’ll discuss the configuration in the app.config file as I walk through the creation of the console
application and Windows service projects.
The Stop method in the DataPortalHost class closes the endpoints:
public void Stop()
{
if (_netService != null)
{
_netService.Close();
_netService = null;
}
if (_slService != null)
{
_slService.Close();
_slService = null;
}
}
These Start and Stop methods reflect the way a Windows service works. A Windows service can
be started and stopped, and so this code supports those two operations.
Configuring the Client Application

The WpfUI project is the client application in the WindowsHost solution. It is configured to use the
net.tcp protocol to interact with the WCF data portal service endpoint. This is done through the
client application’s web.config file:
address="net.tcp://localhost:8001/WindowsHost/WcfPortal.svc"
binding="netTcpBinding"
The configuration in the app.config file is identical to the configuration for the WAS hosted
service, except that the address property matches the URI specified by the WindowsHost project.

Rev 0.4 (draft)
Creating the Console Test Application
The WindowsConsole project references the WindowsHost project, so it can start and stop the service
code. The reason for the WindowsConsole project is to simplify debugging of the service code by
allowing the code to run within the Visual Studio debugger along with the WpfUI client.
The Program class in the project contains the Main method that is executed when the application
is run. This method starts and stops the service implementation by calling the Start and Stop
methods:
static void Main(string[] args)
{
var service = new WindowsHost.DataPortalHost();
service.Start();
Console.WriteLine("Service started");
Console.WriteLine();
Console.WriteLine("Press <return> to close service");

Console.ReadLine();
service.Stop();
Console.WriteLine("Service stopped");
Console.WriteLine("Press <return> to exit");
Console.ReadLine();
}
All the interesting work occurs in the WindowsHost project’s code, where the WCF endpoints are
opened and then closed.
It is important to understand that .NET applications have exactly one configuration file per
AppDomain, and that configuration file comes from the application that is executed, not by any
other assemblies being used. This means that it is the app.config file from the WindowsConsole
project that provides configuration values when the service is running through the console
application.
The appSettings element contains the URI values for each endpoint:
<appSettings>
<add key="DalManagerType" value="DataAccess.Mock.DalManager,DataAccess.Mock" />
<add key="NetDataPortalUri" value="net.tcp://localhost:8001/WindowsHost/WcfPortal.svc" />
<add key="SlDataPortalUri" value="http://localhost:8000/WindowsHost/SlPortal.svc" />
</appSettings>
Notice that the full URI for each endpoint is specified. These service endpoints are not hosted in
IIS or WAS, and so the host application has complete control over the URI that is exposed to the
clients.
The system.serviceModel entries are identical to those in the WASHost example I discussed in
the previous section. The endpoints for the .NET and Silverlight data portal hosts are configured,
along with custom bindings to set the message size limits to maximum.
The WindowsConsole and WpfUI applications should both be run when F5 is pressed to debug the
solution. To make this happen, I right-clicked the WindowsHost solution in Solution Explorer and
chose the Set Startup Projects menu item, resulting in the dialog shown in Figure 26.

Rev 0.4 (draft)
Figure 26. Setting multiple startup projects for the WindowsHost solution
The startup action for WindowsConsole and WpfUI are both set to Start in this dialog. The result
is that pressing F5 to debug the solution will run both of these applications.
The WindowsConsole application requires administrator privileges in Windows, so

debugging this solution requires running Visual Studio as an administrator.
You should be able to run the solution to launch the service in the console window, and the
WpfUI application in its own window. As you interact with the WpfUI application, it will use the data
portal to interact with the service running in the console window.
Because all the code is running in the debugger, it is easy to troubleshoot and solve any issues
with the code.
Creating the Windows Service

The WindowsHostService project is an implementation of a Windows service. It also references the
WindowsHost project, so there is very little code in the service project itself.
I created the project by adding a Windows Service project to the solution, as shown in Figure 27.

Rev 0.4 (draft)
Figure 27. Adding a Windows Service project to the WindowsHost solution
The DataPortalService class implements the service in this project. A Windows service must
override the OnStart and OnStop methods to start and stop the service on request. Here’s the code
from that class:
public partial class DataPortalService : ServiceBase
{
private WindowsHost.DataPortalHost _dataPortalHost = new WindowsHost.DataPortalHost();
public DataPortalService()
{
InitializeComponent();
}
protected override void OnStart(string[] args)

{
_dataPortalHost.Start();
}
protected override void OnStop()

{
_dataPortalHost.Stop();
}
}
Because the DataPortalHost class in the WindowsHost project already implements the service
behaviors, the OnStart and OnStop methods can simply call the Start and Stop methods, just like in
the console application.
The WindowsHostService project also contains an app.config file that contains the
configuration for the application and the WCF endpoints. The contents of this file are exactly the
same as in the WindowsConsole project.
Rev 0.4 (draft)
Installing the Windows Service
A Windows service must be installed into the operating system to run. Typically a service project
will include an installer class to make this possible. The WindowsHostService project contains the
ProjectInstaller class:
[RunInstaller(true)]
public class ProjectInstaller : Installer
{
private ServiceProcessInstaller process;
private ServiceInstaller service;
public ProjectInstaller()
{
process = new ServiceProcessInstaller();
process.Account = ServiceAccount.LocalSystem;
service = new ServiceInstaller();
service.ServiceName = "DataPortalService";
service.Description = "Example data portal service";
Installers.Add(process);
Installers.Add(service);
}
}
This requires that the project add a reference to the System.Configuration.Install assembly.
This class has the RunInstaller attribute, so the installutil.exe command line utility will
identify it as the installer for this assembly. The constructor of the class is responsible for installing
the assembly as a service. Notice how the service name and description are provided.
The installutil.exe command line utility is available from the Visual Studio Command Prompt.
The following command will install the service on your system:
installutil WindowsHostService.exe
The utility can also be used to uninstall the service:

installutil /u WindowsHostService.exe
Once the service is installed, it will appear in the Services administration console as shown in
Figure 28, with the name and description values from the ProjectInstaller class.

Rev 0.4 (draft)
Figure 28. The DataPortalService in the Services administration console
Clicking the Start link in the Services administration console will start the service.
At this point the WpfUI application can be run, and it will interact with the data portal hosted in
this service.
Make sure not to run the WindowsConsole application at the same time the service
is running, because they both attempt to use the same ports, and that will cause one
or both to fail.
At this point you should understand how to host the WCF data portal channel for .NET and
Silverlight in IIS, Windows Server AppFabric, Windows Azure, WAS, and in a custom Windows
service. These are all options for deploying the server-side components of your application to an
application server.
4-Tier Silverlight and WP7 Deployment

Thus far in this chapter I have discussed 1-, 2-, and 3-tier deployment models. When building
Silverlight and WP7 client applications it is also possible to use a 4-tier deployment model as shown
in Figure 29.

Rev 0.4 (draft)
Figure 29. 4-tier Silverlight deployment
In this type of deployment, the application server and web server are separate, and the client
application is only able to communicate with the web server. Because network security prevents
the client application from directly interacting with the application server, the web server acts as a
“relay” for messages flowing between the client and application server.
The data portal on the web server will expose a Silverlight endpoint for use by the Silverlight
client. The web server will relay client messages to a .NET endpoint exposed by the application
server. Figure 30 illustrates the message flow.
Figure 30. Message flow in a 4-tier deployment

The data portal running on the web server defaults to acting as a simple passthrough relay. You
can choose to implement object inspectors, also called mobile factory objects, on the web server.
These object inspectors can inspect the business object graphs sent from the client to the server,
and can decide whether to allow the client request to flow through to the application server.

Rev 0.4 (draft)
The assumption is that the web server is running in a less secure part of your organization’s
network, so this is an ideal location to perform initial screening of client requests to determine
whether they should be passed into the more secure application server.
I’ll walk through configuring an application using the basic passthrough configuration. Then I will
discuss how to create and use object inspectors with the MobileFactory attribute.
Data Portal Configuration

There are three places where the data portal must be configured in a 4-tier deployment:
1. Silverlight client
2. Web server
3. Application server
There is nothing special or unique about the Silverlight client and application server
configuration to support a 4-tier deployment.
The web server configuration is unique, in that the web server is configured to accept incoming
requests from the Silverlight client, and it is also configured to use the .NET data portal to
communicate with the application server. In other words, the web server configures the data portal
as both a server and a client.
The Silverlight client can be configured as I discussed earlier in this chapter. You can configure the
data portal using the ServiceReferences.ClientConfig file, or through code in the App.xaml.cs
file.
The Silverlight4Tier solution in the code download for this ebook includes a SilverlightUI
project. This is the Silverlight client application, and the data portal configuration is in its
App.xaml.cs file:
{
}
As I discussed earlier in the chapter, when running in Silverlight, the data portal defaults to using
the WCF data portal channel. The only required configuration is the URL of the server.
This URL is the address of the web server, not the application server. Again, the typical 4-tier
scenario is one where the Silverlight client can’t directly interact with the application server due to
network security limitations, so the only server it can call is the web server.
Hosting the Data Portal on the Web Server

The web server is implemented in the WebServer project in the Silverlight4Tier solution. This is a
web application configured to run in IIS Express.

Rev 0.4 (draft)
The WebServer project references Csla.dll and the Library.Net business library project. It
does not reference the data access assemblies, because the data access code will not be invoked on
the web server.
Data Portal Server Configuration

The project includes a SlPortal.svc file that acts as a public endpoint for Silverlight clients. This
endpoint is configured in the web.config file, exactly like the Silverlight data portal endpoints in all
the previous examples in this chapter:
<services>
<service name="Csla.Server.Hosts.Silverlight.WcfPortal"
behaviorConfiguration="returnFaults" >
<endpoint binding="basicHttpBinding" bindingConfiguration="basicHttpBinding_IWcfPortal"
contract="Csla.Server.Hosts.Silverlight.IWcfPortal"/>
</service>
</services>
The web.config file also overrides the basicHttpBinding to set the message size limits and
includes the custom returnFaults behavior.
Data Portal Client Configuration

The interesting part about the web server configuration is that the web.config file also contains
data portal client configuration, starting with setting the CslaDataPortalProxy value:
<appSettings>
<add key="CslaDataPortalProxy" value="Csla.DataPortalClient.WcfProxy,Csla"/>
</appSettings>
It also configures the client WCF endpoint, including the URL for the application server:
<client>
address="http://localhost:4109/WcfPortal.svc"
binding="wsHttpBinding"
</client>
Because the data portal is configured as a client, any data portal calls made by code running on
the web server will result in calling the server-side data portal components on the application
server.
The “magic” is that when a Silverlight client calls the data portal on the web server, the default
action is for the Silverlight data portal to call the .NET data portal to service the request. When the
.NET data portal is called, it is configured to invoke the server-side components on the application
server.
The result is that the data portal request from the Silverlight client is relayed through the web
server to the application server. The web server acts as a relay router for all data portal messages,
effectively allowing the client to interact with the application server.
Hosting the Data Portal on the Application Server

The application server is implemented in the AppServer project in the Silverlight4Tier solution.
This is also a web application configured to run in IIS Express.

Rev 0.4 (draft)
The configuration of the application server is the same as all the previous application server
configurations in this chapter. As shown in Figure 31, this project only includes the WcfPortal.svc
file and related endpoint configuration. There is no Silverlight data portal configuration in this
project, because the web server is the only client for the application server.
Figure 31. Application server project in a 4-tier deployment

The AppServer project references Csla.dll and the Library.Net business library project. It also
references the data access assemblies, because the data access code will run on the application
server. The assumption is that the application server is running inside the organization’s network
and has access to the database server.
This means that the web.config file for this project configures the Data Access layer. In this
sample application this means setting the DalManagerType value:
<appSettings>
<add key="DalManagerType" value="DataAccess.Mock.DalManager,DataAccess.Mock" />
</appSettings>
In a real application the web.config file would probably contain the database connection strings
as well.
The web.config file also configures the .NET data portal endpoint:
<services>
</service>
</services>
This is the standard endpoint configuration like in the previous examples, and the web.config
file also includes a customized wsHttpBinding and the returnFaults behavior.
The application server accepts data portal calls from the web server “client”. The web server is
acting as a relay point for messages from the actual Silverlight client.
Configuring this basic pass-through configuration is relatively straightforward. As you can see,
only the web server configuration is different, because it is configured as both a server endpoint
and data portal client.
I will now move on to discuss the ability to create and run object inspectors on the web server.
Implementing an Object Inspector

In some environments or application scenarios you may not trust the integrity of the Silverlight
client, or the network between the client workstation and your web server. You may be concerned
that the user, or another malicious entity, has hacked the Silverlight runtime, the client workstation,

Rev 0.4 (draft)
or has inserted themselves in the network between the client and web server. In short, you might
not trust that the messages coming from the Silverlight client are authentic.
Some of these concerns can be addressed through the use of SSL network communication. If
your web server is configured to support SSL communication, the client can use an https:// URL
for the server. This brings the same level of network security to your application, as people use
when doing banking or credit card transactions over the Internet on a regular basis.
Additionally, I am unaware of any reported instances where the Silverlight runtime has been
compromised such that a hacker or malicious user could alter the running application or its data in
memory.
At the same time, if the potential for this to occur is a problem for your application or
organization, you may consider a couple solutions.
One solution is to switch from an n-tier application architecture to a service-oriented
architecture (SOA). In that case the Silverlight client would be considered a 1-tier standalone
application, or “edge application”.
This Silverlight edge application would make calls to your server application’s service-based
interface. The result is that you would implement two separate applications (client and service) that
interact with each other through well-defined messages encoded in XML or JSON format as they
move over the network.
The creation of an SOA system composed of multiple applications is outside the scope of this
ebook.
Another solution is to implement an n-tier architecture using the data portal, and to write code
that runs on your web server to validate each incoming client request. This is supported by the data
portal through the use of the MobileFactory attribute and the concept of object inspectors.
An object inspector is a specialized object that runs on the web server for the purpose of
validating the client requests before they are relayed to the application server. These object
inspectors, and the web server, become the first line of defense against invalid client requests.
Because each client request materializes on the web server as an object graph composed of
business objects or criteria objects, the object inspectors have complete access to the application’s
business objects, including their properties, methods, and business logic.
You should also be aware that the per-type authorization rules for each business object type are
automatically enforced by the data portal on the web server. The process of relaying the client data
portal request through to the application server automatically checks (or rechecks) the
authorization rules.
This means that object inspectors only need to be implemented for business objects where it is
possible and desirable to add extra checks on the client request before it is relayed to the
application server.
Implementing an Object Inspector

An object inspector is a public class that implements public methods to handle the data portal’s
Create, Fetch, Update, and Delete operations.

Rev 0.4 (draft)
If you have read the Using CSLA 4: Data Access ebook, you can think of an object
inspector as being similar to a factory object used in the factory implementation or
factory invoke data portal persistence models.
The methods implemented by an object inspector class are listed in Table 3.
Method Description
Create Invoked by the data portal when a client-side request for a create operation arrives
at the web server
Fetch Invoked by the data portal when a client-side request for a fetch operation arrives
at the web server
Update Invoked by the data portal when a client-side request for an update operation
arrives at the web server
Delete Invoked by the data portal when a client-side request for a delete operation arrives
at the web server
Execute Invoked by the data portal when a client-side request for an execute operation
arrives at the web server
Table 3. Methods implemented by an object inspector class

The Create, Fetch, and Delete methods must accept zero or one parameter. If they accept one
parameter, the parameter type must match the type of parameter value passed to the client-side
data portal’s Create, BeginCreate, Fetch, BeginFetch, Delete, or BeginDelete method. It is
possible to have multiple overloads of the methods in the object inspector class that correspond to
different static factory methods in the business class.
The ObjectInspectors solution in the code download for this ebook is a copy of the
Silverlight4Tier solution I discussed in the previous section. This new solution includes an
ObjectInspectors project that contains the object inspector classes for the solution. The
WebServer project references the ObjectInspectors project, so this assembly is available on the
web server.
The ObjectInspectors project references Csla.dll and the Library.Net project. Because the
object graphs that will be inspected are composed of the business types in the Library.Net project,
these references allow the object inspector code to interact with the business object graphs.
It is also important to realize that the client-side context is present on the web server as well.
This means the User, ClientContext and GlobalContext properties of the ApplicationContext
object in the Csla namespace are available for use by object inspector code.
ObjectFactory Base Class

An object inspector class contains code that interacts with business objects. In many cases the
object inspector will need to read non-public property values, or invoke non-public methods on the
business objects. Although this breaks encapsulation, it is necessary for the object inspector to do
its work.

Rev 0.4 (draft)
In the Using CSLA 4: Data Access ebook I discussed the ObjectFactory base class from the
Csla.Server namespace. This base class exists specifically to allow the creation of classes that
break encapsulation by interacting with non-public properties and methods of CSLA .NET business
objects. It is useful for creating object factories, and also for creating object inspectors. Most object
inspector classes will subclass the ObjectFactory class.
For example, the PersonEditInspector class in the ObjectInspectors project inherits from the
ObjectFactory class:
public class PersonEditInspector : Csla.Server.ObjectFactory
{
}
This allows the code in the inspector class to use the protected members of the ObjectFactory
class. Those members are listed in Table 4.
Member Description
LoadProperty Loads a property value without invoking authorization or business rules
ReadProperty Reads a property value without invoking authorization rules
MarkAsChild Invokes MarkAsChild on the target object (editable object only)
MarkNew Invokes MarkNew on the target object (editable object only)
MarkOld Invokes MarkOld on the target object (editable object only)
BypassPropertyChecks Gets the BypassPropertyChecks object from the target object (editable
object only)
CheckRules Invokes the CheckRules method on the target object’s BusinessRules
object (editable object only)
FieldExists Gets a value indicating whether a managed backing value already exists for
the target property
GetDeletedList Gets the DeletedList collection from a BusinessListBase or
BusinessBindingListBase object
SetIsReadOnly Sets the IsReadOnly property on a ReadOnlyListBase,
ReadOnlyBindingListBase, or NameValueListBase object
Table 4. Members implemented by the ObjectFactory base class

The responsibility of a PersonEditInspector object is to verify that each client data portal
request related to the PersonEdit editable root object is valid before allowing the request to flow
through to the application server. In fact, when you implement an object inspector for a root
business type, that object inspector assumes the entire responsibility for relaying the request
through the data portal to the application server.
Create Operation
For example, the PersonEdit class is implemented so the data portal create operation always
occurs on the client, not on the server. This means that any request from a Silverlight client to
create a PersonEdit object on the server is invalid.
Rev 0.4 (draft)
The Create method in the PersonEditInspector rejects all create requests:
public PersonEdit Create()
{
throw new NotSupportedException("Server-side create not supported");
}
If a client request shouldn’t be allowed to flow through to the application server, the object
inspector throws an exception to stop further processing of the request. The exception should
indicate why the request was rejected, so that information is available to the client application.
Fetch Operation
The data portal fetch operation is validated by the Fetch method in the PersonEditInspector
class:
public PersonEdit Fetch(int id)
{
return DataPortal.Fetch<PersonEdit>(id);
}
In this case, all client requests are relayed to the application server. This call to the data portal
Fetch method will automatically enforce any authorization rules associated with getting
PersonEdit objects, and the object inspector isn’t applying any additional rules to the process.
The fact that the authorization rule for the fetch operation is running on the web server adds a
level of security to the application. Even if a malicious user managed to hack the Silverlight runtime
on the client and bypass the authorization rules that would normally run on the client, the
appropriate authorization rules are run on the web server before the request is relayed to the
application server.
The assumption is that it is harder for a malicious user to alter running code on the web server
than for them to hack into the Silverlight runtime on the client.
Update Operation
The data portal update operation occurs when the editable root object is saved on the client with
the BeginSave method. That results in a client-side call to the data portal’s BeginUpdate method,
causing the data portal to invoke the server-side data portal on the web server. The server-side
code on the web server will invoke the Update method of any object inspector associated with the
editable root business class.
The PersonEditInspector implements the Update method:
public PersonEdit Update(PersonEdit obj)
{
CheckRules(obj);
if (!obj.IsValid)
throw new InvalidOperationException("Can not update invalid object");
else
return DataPortal.Update<PersonEdit>(obj);
}
This implementation demonstrates the most common action for an object inspector: re-running
the business rules for the business object.
On the Silverlight client, the BeginSave method only calls the data portal if the business object’s
IsValid property is true. Only valid objects can be saved.
Rev 0.4 (draft)
If you assume that the code running on the client has been compromised by a malicious user,
they may attempt to save an invalid object. They might do that by rewriting your business rules in
memory, or by bypassing the IsValid property check.
Again, I am not aware of any reported instances of the Silverlight runtime being
hacked in this manner. Everything I’m discussing in this section is to protect against
hypothetical threats.
Acting under the assumption that it is harder for a malicious user to hack into your web server,
re-running the rules on the web server adds a level of security. The business code running on the
web server is presumably not compromised by the malicious user, so the rules that are run by the
CheckRules method in the PersonEditInspector object’s Update method are authentic rules.
If the resulting IsValid property remains true, then the data portal’s Update method is invoked
to relay the client request to the application server for processing.
Delete Operation
The data portal delete operation is handled just like the fetch operation. The data portal
automatically checks authorization rules before relaying the request to the application server, and
no additional checks are added by the object inspector:
public void Delete(int id)
{
DataPortal.Delete<PersonEdit>(id);
}
The application server handles the delete operation request as normal.
Execute Operation
There is no Execute method in the PersonEditInspector class, because the data portal execute
operation only applies to command object stereotypes that subclass CommandBase. An Execute
method for a command object looks much like the Fetch or Update methods shown earlier.
For example:
public MyCommand Execute(MyCommand obj)
{
return DataPortal.Execute<MyCommand>(obj);
}
The command object can be verified before relaying the request to the application server.
MobileFactory Attribute
At this point you know how to implement an object inspector class. The MobileFactory attribute is
used to link the root business type to its associated object inspector class.
For example, the PersonEdit class in the Library.Net project includes this attribute:
[Serializable]
[Csla.Server.MobileFactory("ObjectInspectors.PersonEditInspector,ObjectInspectors")]
public class PersonEdit : BusinessBase<PersonEdit>

Rev 0.4 (draft)
The MobileFactory attribute requires a string parameter that provides the name of the object
inspector to be used by the data portal when handing requests for this root business type.
By default, this object inspector name parameter is interpreted as an assembly qualified type
name. In the example PersonEdit code shown here, the data portal will look for a
PersonEditInspector class in the ObjectInspectors namespace of the ObjectInspectors
assembly.
There are overloads of the MobileFactory constructor that allow you to specify the method
names for the create, fetch, update, delete, and execute methods that will be invoked on the object
inspector instance. If the default Create, Fetch, Update, Delete, and Execute method names won’t
work in your scenario, you can use the MobileFactory overloads to select different method names.
Custom Object Inspector Loader

As I mentioned earlier, the object inspector name parameter required by the MobileFactory
attribute is interpreted as an assembly qualified type name by default. You can override this default
behavior and interpret the object inspector name parameter in any way you choose.
The data portal uses something called a mobile factory loader to create each object inspector
instance based on the object inspector name parameter provided to the MobileFactory attribute.
The default mobile factory loader interprets the parameter value as an assembly qualified type
name.
The MobileFactoryLoader class in the ObjectInspectors project is a custom implementation of
a mobile factory loader. It interprets the MobileFactory parameter value as being only the class
name. For example:
[Serializable]
[Csla.Server.MobileFactory("PersonEditInspector")]
public class PersonEdit : BusinessBase<PersonEdit>
That class name is combined with a specific namespace and assembly name to create the
assembly qualified type name in the mobile factory loader:
public class MobileFactoryLoader : Csla.Server.Hosts.Silverlight.IMobileFactoryLoader
{
public object GetFactory(string factoryName)
{
return Activator.CreateInstance(GetFactoryType(factoryName));
}
public Type GetFactoryType(string factoryName)

{
var typeName = string.Format("ObjectInspectors.{0},ObjectInspectors", factoryName);
var result = Type.GetType(typeName);
if (result == null)
throw new ArgumentException("Can not find type for object inspector " + factoryName);
else
return result;
}
}
A mobile factory loader must implement two methods as defined by the IMobileFactoryLoader
interface in the Csla.Server.Hosts.Silverlight namespace.
The GetFactoryType method is responsible for creating a .NET Type object for the object
inspector class. In this example you can see how the factoryName parameter is combined with a
Rev 0.4 (draft)
hardcoded namespace and assembly name to create a full type name. That value is passed to the
GetType method of the .NET Type class to create the Type object.
The GetFactory method is usually simpler, and uses the CreateInstance method of the
Activator type to create an instance of the Type object returned by the GetFactoryType method.
The reason CSLA .NET allows the creation of a custom mobile factory loader is to enable flexibile
creation of object inspector instances. You might use direct type loading techniques like I show in
this example. Or you might choose to create the objects using the Managed Extensibility
Framework (MEF), or an IoC container, or other object creation technologies.
Most applications can use the default mobile factory loader, where the MobileFactory
parameter is the assembly qualified type name of the object inspector class.
In this chapter you have learned how to configure and use the data portal to deploy CSLA .NET
applications in 1-, 2-, 3-, and 4-tier physical scenarios. This includes the use of the local data portal
channel for 1- and 2-tier deployments. The chapter also provided an in-depth discussion of the WCF
data portal channel for 3- and 4-tier deployments.

Rev 0.4 (draft)
Chapter 2:
Data Portal Configuration Reference
The CSLA .NET data portal is flexible and configurable in several different ways. This chapter is
designed to provide quick reference to the configuration settings available for the data portal.
The data portal is designed to run on .NET, Silverlight, and WP7. There are differences between
the .NET implementation, and the implementation for Silverlight and WP7. Additionally, the way
the data portal is configured in .NET applications is different from the way it is configured in
Silverlight or on WP7.
.NET Configuration Settings

When an application is running on a .NET server, or a .NET smart client, the data portal is typically
configured through the appSettings region of your app.config or web.config file. Table 5
summarizes all the configuration settings you can use with the .NET data portal.
Setting Description
CslaDataPortalProxy Specifies the assembly qualified type name of the client-side
data portal proxy to be used by the data portal; the value
Local is a special value indicating that the data portal
should run in 1- or 2-tier local mode (Local is the default);
proxy types must implement IDataPortalProxy
CslaDataPortalUrl Set this value to the URL of the remote service to be used
by the client-side proxy; the WcfProxy and RemotingProxy
objects default to using this value to locate the service on
the application server
CslaSerializationFormatter Set this value to NetDataContractSerializer to indicate
that CSLA .NET should use the WCF
NetDataContractSerializer type for all serialization
operations, including in-memory object serialization as well
as in the data portal
CslaAuthentication Set this value to Windows to indicate that the data portal
should use Windows integrated authentication, allowing the
operating system to follow its normal impersonation rules;
any other value indicates the use of custom authentication
and the data portal will automatically transfer the client
principal to the server with every data portal call
CslaAuthorizationProvider Specifies the assembly qualified type name of a server-side
type that implements IAuthorizeDataPortal; this type is
used to create an object that authorizes every data portal
call immediately after the request has been deserialized and
before any further work occurs on the server
CslaObjectFactoryLoader Specifies the assembly qualified type name of a server-side
type that implements IObjectFactoryLoader; this type is
Rev 0.4 (draft)
responsible for interpreting the factory name specified in
each ObjectFactory attribute; this type implements the
code that creates the specified factory object
CslaMobileFactoryLoader Specifies the assembly qualified type name of a server-side
type that implements IMobileFactoryLoader; this type is
responsible for interpreting the factory name specified in
each MobileFactory attribute; this type implements the
code that creates the specified inspector object used to
verify calls from Silverlight and WP7 clients
CslaDataPortalExceptionInspector Specifies the assembly qualified type name of a server-side
type that can re-write server exceptions before they are
returned through the data portal to the client
CslaAutoCloneOnUpdate Set this to False to disable the automatic cloning of the
object graph before Update and Execute operations; make
sure you have implemented an alternative solution to
handle persistence failure scenarios before altering this
value
CslaDataPortalProxyFactory Specifies the assembly qualified type name of the client-side
data portal proxy factory, which is the object responsible for
creating instances of the data portal proxy type; this type
must implement IDataPortalProxyFactory; the value
Default is a special value indicating that the data portal
should use its default factory that creates an instance of the
type specified by the CslaDataPortalProxy setting
CslaAlwaysImpersonate (RemotingProxy only) Set this value to true to cause the
RemotingProxy to always pass the client-side Windows
user identity to the application server
CslaEncryptRemoting (RemotingProxy only) Set this value to true to cause the
RemotingProxy to use encryption for server
communication
Table 5. Data portal configuration settings for .NET

You can use these settings to control the behavior of the data portal on .NET clients and servers.
These settings are designed to be applied through the application’s app.config or web.config file.
I’ll demonstrate how to configure the data portal for WPF and ASP.NET applications in later
books in this ebook series.

Rev 0.4 (draft)
Silverlight and WP7 Configuration Settings
Table 6 lists the properties used to configure the data portal on Silverlight and WP7 clients. Unless
otherwise noted, these are static methods on the specified type.
Setting Description
DataPortal.ProxyTypeName Specifies the assembly qualified type name of the client-side
data portal proxy to be used by the data portal; the value
Local is a special value indicating that the data portal
should run in 1-tier local mode; proxy types must
implement IDataPortalProxy; WP7 default is Local,
Silverlight default is the CSLA .NET WcfProxy type
DataPortal.ProxyFactory Gets or sets a reference to the ProxyFactory object that is
used to create an instance of the client-side proxy object;
this value defaults to a factory that creates an instance of
the DataPortal.ProxyTypeName property
WcfProxy.DefaultUrl This URL value is used to locate the data portal service on
the application server; default is null (meaning settings in
ServiceReferences.ClientConfig are used)
WcfProxy.DefaultBinding Specifies the default WCF binding to be used by the
WcfPortal proxy; default is BasicHttpBinding with
maximum message size and timeout values
WcfProxy.DefaultEndPoint Specifies the end point name the WcfProxy should use to
load its configuration from the application’s
ServiceReferences.ClientConfig file; the config file
values are used if either the DefaultUrl or
DefaultBinding properties are null
Csla.ApplicationContext. If set to Windows, the client-side principal will not flow to
AuthenticationType the server on each data portal request, otherwise the data
portal will always impersonate the client-side user on the
application server; default is “Csla”
Table 6. Data portal configuration settings for Silverlight and WP7

These configuration properties are typically set in the ApplicationStartup event handler in the
code-behind file for the app.xaml file before the RootVisual property is set. For example:
{
}
In a WP7 application this code will typically be in the constructor for the App class:
public App()
{
// other code goes here

}

Rev 0.4 (draft)
Either way, the configuration values are set as the application starts.
This chapter provides reference information for all the configuration settings related to the data
portal. The configuration settings are different for .NET and Silverlight, based on the features and
capabilities of each platform.

Rev 0.4 (draft)
Chapter 3:
Serialization
The key to implementing mobile objects is the ability to convert the public and non-public state of
an object graph into a byte stream, and to then convert that byte stream back into an exact clone of
the original object graph. This process is called serialization and deserialization.
.NET Serializer Types

The .NET Framework provides numerous serialization components. These components generate
byte streams in different formats, such as binary data, XML, binary XML, and JSON. It is important
to understand that these components do not all provide the same functionality.
One set of serializers is designed for creating or calling standards-based services that expose
XML or JSON interfaces. These serializers are primarily concerned with standards compliance, and
are not capable of cloning an object graph with 100% fidelity.
They include the XmlSerializer, DataContractSerializer, DataContractJsonSerializer, and
others. These serializers can not be used to serialize CSLA .NET object graphs, because they have
limitations that prevent their use. You should use these serializers when implementing public
service APIs that expose XML or JSON to consuming applications.
Another set of .NET serializers is designed for cloning object graphs with 100% fidelity. These are
the BinaryFormatter and NetDataContractSerializer (NDCS). The BinaryFormatter was the
original serializer, and is used by .NET Remoting, Enterprise Services, and core elements of the .NET
Framework itself. The NDCS is part of WCF, and is essentially a replacement for the
BinaryFormatter.
The .NET data portal channels use either the NDCS or the BinaryFormatter to serialize and
deserialize your object graphs. The WCF data portal channel uses the NDCS, because that is how
WCF serializes data for transfer over the network. Even when the WCF data portal channel is used,
CSLA .NET defaults to using the BinaryFormatter for all serialization operations outside the data
portal. You can use the CslaSerializationFormatter configuration setting to override this default
behavior.
The Silverlight and WP7 platforms have restrictions on .NET reflection that prevents reflection
from getting or setting non-public property values in an object. Because the BinaryFormatter and
NDCS rely directly on that feature of reflection, those serializers do not exist in Silverlight.
To overcome the fact that those serializers don’t exist in Silverlight, and the fact that CSLA .NET
requires the features provided by those serializers, CSLA 4 includes the MobileFormatter. The
MobileFormatter is a serializer that operates without needing reflection to access non-public
property values, and yet is able to serialize and deserialize object graphs with 100% fidelity.
When CSLA .NET is running on Silverlight and WP7 it uses the MobileFormatter in place of the
BinaryFormatter or NDCS. Additionally, a .NET application server that exposes a data portal
endpoint for a Silverlight client will use the MobileFormatter to serialize and deserialize messages
that flow between the client and server.

Rev 0.4 (draft)
MobileFormatter Serializer
The MobileFormatter has some limitations when compared to the BinaryFormatter or NDCS. It is
important that you understand the limitations, so you can work around or properly address them in
certain application scenarios.
The BinaryFormatter requires that a class be marked with the Serializable attribute. Any class
marked as serializable can be serialized by the BinaryFormatter. The BinaryFormatter does this
serialization by reflecting against the object to pull out all the field values (not property values) from
the object. This is done for all fields, irregardless of their scope.
The NetDataContractSerializer does the same thing as the BinaryFormatter, but it can
serialize objects marked with the Serializable attribute, or with the DataContract and
DataMember attributes. The important thing to understand is that the NDCS also uses reflection to
pull out the field or property values from the object, even if they aren’t public in scope.
The MobileFormatter provides many of the same capabilities as the BinaryFormatter and
NDCS, but it avoids the use of reflection. This means that it works in Silverlight and WP7.
To avoid the use of reflection, the MobileFormatter relies on each object to actively participate
in the serialization and deserialization process. Every object serialized by the MobileFormatter must
be marked with the Serializable attribute, and must implement the IMobileObject interface
defined in the Csla.Serialization.Mobile namespace.
The MobileFormatter can only serialize primitive values, or objects that implement
the IMobileObject interface.
The Csla.Core namespace includes the set of base types listed in Table 7 that already
implement this interface.
Base type Description

MobileObject Subclass this to create an object with read-only or read-
write properties
MobileList Subclass this to create a List<T> collection that contains
objects that implement the IMobileObject interface, or
that contains primitive values
MobileBindingList Subclass this to create an IBindingList collection that
contains objects that implement the IMobileObject
interface
MobileObservableCollection Subclass this to create an ObservableCollection<T>
collection that contains objects that implement the
ImobileObject interface
MobileDictionary Subclass this to create a Dictionary<K,V> where the key
and value types are either primitive types, or implement the
IMobileObject interface
Table 7. Base types that implement the IMobileObject interface

Rev 0.4 (draft)
The BusinessBase, ReadOnlyBase, and other standard CSLA .NET base classes are subclasses of
the types in Table 7. This means that any class you create by subclassing a standard CSLA .NET base
type automatically supports serialization with the MobileFormatter.
That is only true, however, if your types use only managed backing fields when implementing
their properties. The way these base types avoid the use of reflection to get and set the non-public
property values, is by serializing the values stored in the managed backing fields.
If you implement a class that has a private manual backing field for a property, you are
responsible for serializing that property value. To do this in a subclass of a standard CSLA .NET base
class, you need to override the OnGetState and OnSetState methods.

Rev 0.4 (draft)
Chapter 4:
Custom Data Portal Proxies
You can alter or enhance the data portal by creating a custom client-side proxy type. It is also
possible to create a custom server-side data portal host, but that is an advanced scenario, and is
only necessary in the rare case that WCF isn’t sufficient to meet the application requirements.
In this chapter I will discuss creating a custom proxy to address two common requirements:
1. The application uses multiple application servers, where some objects need to be routed to
one server, and other objects need to be routed to a different server
2. The application supports online and offline functionality, and the data portal should use the
local proxy when offline, and the WCF proxy when online
I will also discuss how to implement compression for the Silverlight data portal. This involves
customizing the client-side proxy and server-side host types.
Implementing a Custom Proxy

If your application needs to interact with multiple application servers, where some objects use one
server, and other objects use a different server, the most direct solution is to implement a custom
data portal proxy.
This custom proxy can examine the data portal request, and can route the call to the appropriate
application server. Normally this custom proxy will use an existing proxy type, such as WcfProxy, to
handle the server communication, allowing the custom proxy to do nothing more than act as a
router.
The CustomProxy solution in the code download for this ebook provides an example of a custom
proxy implementation. Figure 32 shows the projects in the solution.
Figure 32. Projects in the CustomProxy solution

The WpfUI project is the client application, providing a simple user interface for the business
types in the Library.Net project.
The WcfAppServer and OtherAppServer projects are the application server projects, each one
configured as a WCF data portal host.

Rev 0.4 (draft)
The CustomProxy project is the custom data portal proxy implementation. This project also
contains an AppServerAttribute class that is applied to each root business class. This attribute is
used by the custom proxy to indicate the application server that should be used for that business
type.
The custom proxy class is SmartProxy, and it contains code to examine each data portal request,
looking at the root business type to find the AppServer attribute. The value of the AppServer
attribute is used to identify the application server that is used by the WCF data portal proxy.
The CustomProxy project also includes a subclass of the standard WcfProxy type. This subclass
includes a constructor that accepts the application server URL, so that value is used instead of the
normal value from the configuration file.
Figure 33 illustrates how these types fit together.
Figure 33. Interaction between types in the CustomProxy solution
Implementing the Custom Proxy

The custom proxy implementation consists of three types: SmartProxy, AppServerAttribute, and a
subclass of the standard WcfProxy type. I’ll discuss the SmartProxy class last, because it requires the
other two types.
AppServer Attribute
The AppServerAttribute class implements the AppServer attribute. This attribute is applied to root
business types in the Library.Net project to indicate the application server that should be used for
that business type. For example:
[AppServer(ServerName = "Server1")]
[Serializable]
public class OneTest : BusinessBase<OneTest>

Rev 0.4 (draft)
The Library.Net project references the CustomProxy project (or assembly), so it has access to
this attribute.
For this simple example, I’ve implemented the attribute to accept the name of the application
server. The SmartProxy class will use this name to find the URL of the server from the application’s
configuration file.
The AppServerAttribute class itself is not complex:
[AttributeUsage(AttributeTargets.Class)]
public class AppServerAttribute : Attribute
{
public string ServerName { get; set; }
}
The class inherits from the .NET Attribute type, and defines the ServerName property that
contains the name of the application server.
The AttributeUsage attribute restricts the usage of this new AppServer attribute so it can only
be used on class definitions.
WcfProxy Class
The standard CSLA .NET WcfProxy type is found in the Csla.DataPortalClient namespace. It gets
the application server URL from the application’s configuration file. The value comes from either
the CslaDataPortalUrl configuration value, or from the endpoint definition in the
system.serviceModel configuration section.
Because the new SmartProxy data portal proxy will be setting the URL dynamically at runtime, it
is necessary to customize the default behavior of the standard WcfProxy type by overriding the
GetChannelFactory method. This is done by implementing a subclass:
public class WcfProxy : Csla.DataPortalClient.WcfProxy
{
public WcfProxy(string serverUrl)
{
_serverUrl = serverUrl;
}
private string _serverUrl;
protected override System.ServiceModel.ChannelFactory<Csla.Server.Hosts.IWcfPortal>

GetChannelFactory()
{
var binding = new WSHttpBinding()
{
MaxReceivedMessageSize = int.MaxValue,
ReaderQuotas = new System.Xml.XmlDictionaryReaderQuotas()
{
MaxBytesPerRead = int.MaxValue,
MaxDepth = int.MaxValue,
MaxArrayLength = int.MaxValue,
MaxStringContentLength = int.MaxValue,
MaxNameTableCharCount = int.MaxValue
}
};
return new ChannelFactory<IWcfPortal>(binding, _serverUrl);
}
}

Rev 0.4 (draft)
This new subclass has a constructor that requires the URL of the application server be provided
as a parameter. The GetChannelFactory override then uses this URL value to create the WCF
channel factory object. This replaces the standard behavior that gets the URL from the application’s
configuration file.
SmartProxy Class
The SmartProxy class contains the implementation of the custom proxy. This data portal proxy uses
the AppServer attribute to get the name of the application server, and it uses that name to retrieve
the server’s URL from the application’s configuration file. It then creates an instance of the
WcfProxy subclass to communicate with that application server at that URL.
Because the network communication is handled by the WcfProxy object, the code in the
SmartProxy class is completely focused on getting the server URL. Here’s the code:
public class SmartProxy : Csla.DataPortalClient.IDataPortalProxy
{
private WcfProxy GetProxy(Type objectType)
{
string serverName = null;
var att = objectType.GetCustomAttributes(typeof(AppServerAttribute), false);
if (att.Length > 0)
{
var asa = (AppServerAttribute)att[0];
serverName = asa.ServerName;
}
var serverUrl = ConfigurationManager.AppSettings[serverName];
return new WcfProxy(serverUrl);
}
public bool IsServerRemote

{
get { return true; }
}
public Csla.Server.DataPortalResult Create(

Type objectType, object criteria, Csla.Server.DataPortalContext context)
{
return GetProxy(objectType).Create(objectType, criteria, context);
}
public Csla.Server.DataPortalResult Delete(

{
return GetProxy(objectType).Delete(objectType, criteria, context);
}
public Csla.Server.DataPortalResult Fetch(

{
return GetProxy(objectType).Fetch(objectType, criteria, context);
}
public Csla.Server.DataPortalResult Update(

object obj, Csla.Server.DataPortalContext context)
{
return GetProxy(obj.GetType()).Update(obj, context);
}
}
The first thing to note is that the SmartProxy type implements the IDataPortalProxy interface
from the Csla.DataPortalClient namespace. This interface is used by the data portal to
Rev 0.4 (draft)
communicate with all proxy objects. The interface requires that the class implement the members
listed in Table 8.
Member Description
IsServerRemote Gets a value indicating whether the application server is physically remote, or is
running in the same AppDomain as the client code
Create Invokes the server-side data portal to perform a create operation
Fetch Invokes the server-side data portal to perform a fetch operation
Update Invokes the server-side data portal to perform an update or execute operation
Delete Invokes the server-side data portal to perform a delete operation
Table 8. Members defined by the IDataPortalProxy interface

Because this proxy is always delegating to an instance of the WcfProxy type, the IsServerRemote
property always returns true.
The GetProxy method is where the real action happens:
private WcfProxy GetProxy(Type objectType)
{
string serverName = null;
var att = objectType.GetCustomAttributes(typeof(AppServerAttribute), false);
if (att.Length > 0)
{
var asa = (AppServerAttribute)att[0];
serverName = asa.ServerName;
}
var serverUrl = ConfigurationManager.AppSettings[serverName];
return new WcfProxy(serverUrl);
}
This method uses reflection to get the AppServer attribute from the root business object type,
and then gets the server name from the attribute. The server name is used as the key to look up the
server’s URL from the application’s configuration file. That URL is used to create an instance of the
WcfProxy subclass.
Configuring the Application to use a Custom Proxy

Client applications on .NET use the CslaDataPortalProxy configuration value to tell the data portal
the proxy that should be used. To use a custom proxy, the custom proxy type is provided to the
data portal using this attribute.
For example, the app.config file in the WpfUI project contains the following:
<appSettings>
<add key="CslaDataPortalProxy" value="CustomProxy.SmartProxy, CustomProxy"/>
<add key="Server1" value="http://localhost:10086/WcfPortal.svc"/>
<add key="Server2" value="http://localhost:10464/WcfPortal.svc"/>
</appSettings>
This tells the data portal that it should use the SmartProxy type from the CustomProxy assembly
to handle all data portal requests.
Also notice that the Server1 and Server2 key values are associated with the URLs of the two
application servers.
Rev 0.4 (draft)
Client applications on Silverlight or WP7 set the ProxyTypeName property of the DataPortal class
to specify the client-side proxy. This is typically done as the application starts up, in the
App.xaml.cs class. For example:
Csla.DataPortal.ProxyTypeName = typeof(CustomProxy.SmartProxy).AssemblyQualifiedName;
Because there is no System.Configuration API on Silverlight, you would need to use a different
technique to maintain the mapping from application server name to server URL on a Silverlight
client.
At this point you should understand how to create a custom client-side data portal proxy that
routes data portal requests to concrete proxy objects for server communication. You can use this
technique to support the use of multiple application servers for an application.
Implementing a Custom Proxy Factory

A relatively common application requirement is the need to run online or offline depending on
whether the application server is available. These are sometimes called occasionally connected
systems, because they are usually designed to work offline, with extra features or capabilities
available when they do have a connection to the server.
A full implementation of this requirement can be extremely complex, and usually involves having
a client-side database that is synchronized with the master database on the server while the
application is online. I won’t discuss the full architectural ramifications or implementation of
building an occasionally connected system in this ebook.
In some ocassionally connected application architectures, the application will interact with an
application server when online, and with a local database when offline. This requires that the data
portal be able to switch between the use of the WcfProxy and the LocalProxy as necessary.
This also requires that your application implement two data access layers, one for
the application server and one for the client.
The client-side data portal uses a data portal proxy factory to create the proxy object that is used
by the data portal. The default data portal proxy uses the CslaDataPortalProxy configuration value
to identify this type on .NET, and the ProxyFactory property on the DataPortal type on Silverlight.
You can implement your own proxy factory, and your implementation can create the proxy
object following more complex rules. The ProxyFactorySl solution in the code download for this
ebook is an example of a custom proxy factory implementation. Figure 34 shows the projects that
make up this solution.

Rev 0.4 (draft)
Figure 34. Projects in the ProxyFactorySl solution
The ProxyFactorySl project is the Silverlight client, and it is hosted in the ProxyFactorySlWeb
project. That web project also hosts the server-side data portal.
The Library.Net and Library.Sl projects contain the business types, and those types use the
encapsulated invocation data access model as discussed in the Using CSLA 4: Data Access ebook.
The interesting thing with this solution is that there are two data access implementations.
The DataAccess.Net and DataAccess.Sl projects implement the pluggable data access provider
model described in the Using CSLA 4: Data Access ebook. These projects contain the same code
through the use of linked files, and they both compile to create a DataAccess.dll assembly for
.NET and Silverlight.
The ClientDal project implements the DAL for use on the client, and the ServerDal project
implements the DAL that runs on the application server. These projects reference the
DataAccess.Sl and DataAccess.Net projects respectively, and they each contain a TestDal class
that implements the ITestDal interface defined in the DataAccess assembly.
It is important to understand that that DataAccess assemblies compiled for .NET and Silverlight
are the same, just compiled for each platform. This means that the DAL interfaces defined in the
DataAccess projects are identical.
The implementation of the DAL interfaces in the ClientDal and ServerDal projects will almost
certainly be different, because they are running on the client and server and will use different data
access technologies and databases. The key is that their interfaces are the same, and so the code in
the business classes remains reasonably consistent for online and offline environments.
Figure 35 illustrates the relationship between the projects in the solution.

Rev 0.4 (draft)
Figure 35. Relationship between projects in the ProxyFactorySl solution
In Figure 35 you can see how the ProxyFactorySl client application interacts with the business
types in the Library assembly (compiled for Silverlight). When the business types call the data
portal, the custom ProxyFactory type is used to determine whether to use the WcfProxy or the
LocalProxy to communicate with the “server-side” data portal components.
If the WcfProxy is used, the server-side components will run on the .NET application server, so
the Library assembly compiled for .NET invokes the data access components available on the
application server, so the DAL implementation is in the ServerDal project.
On the other hand, if the LocalProxy is used, the “server-side” components run on the
Silverlight client, and so use the Library assembly compiled for Silverlight. That assembly invokes
the data access components available on the Silverlight client, where the implementation is in the
ClientDal project.
Implementing the Custom Proxy Factory

The custom proxy factory is implemented by the ProxyFactory class in the ProxyFactorySl project.
This class inherits from the default ProxyFactory class in the Csla.DataPortalClient namespace:
public class ProxyFactory : Csla.DataPortalClient.ProxyFactory
{
protected override Csla.DataPortalClient.IDataPortalProxy<T> GetProxy<T>()
{
return GetProxy<T>(Csla.DataPortal.ProxyModes.Auto);
}
protected override Csla.DataPortalClient.IDataPortalProxy<T> GetProxy<T>(

Csla.DataPortal.ProxyModes proxyMode)
{
var offline = (bool)Csla.ApplicationContext.LocalContext["Offline"];
if (proxyMode == DataPortal.ProxyModes.LocalOnly || offline)
return new LocalProxy<T>();

Rev 0.4 (draft)
else
return new WcfProxy<T>();
}
}
The class overrides the GetProxy method overloads, making use of an Offline value from the
LocalContext dictionary in Csla.ApplicationContext to determine whether the application
should run in online or offline mode.
If the application is configured to run offline, or a local proxy is specifically requested, an
instance of LocalProxy is returned, otherwise an instance of WcfProxy is the result.
In a complete application, you would implement manual or automatic detection of the
application’s online or offline state, and would set the configuration value based on the application
state. The sample application sets the value in the TestItemViewModel class in the ProxyFactorySl
UI project. The value is data bound to a check box control in the UI, making it easy to switch
between online and offline modes.
Configuring the Application to use a Custom Proxy Factory

In a .NET client application the proxy factory is set in the application configuration file with the
CslaDataPortalProxyFactory setting. For example:
<appSettings>
<add key="CslaDataPortalProxyFactory" value="MyApp.ProxyFactory, MyApp"/>
</appSettings>
In a Silverlight application like the ProxyFactorySl sample, the proxy factory is set through code
as the application starts up. The App.xaml.cs file contains this code:
{
Csla.ApplicationContext.LocalContext.Add("Offline", false);
Csla.DataPortal.ProxyFactory = new ProxyFactory();
DataAccess.DalFactory.DalType = typeof(Dal.DalManager);
}
The ProxyFactory property of the DataPortal class is set to an instance of the custom proxy
factory type:
Csla.DataPortal.ProxyFactory = new ProxyFactory();
This will cause the data portal to use the custom type to create instances of the data portal
proxy objects as necessary.
At this point you should understand how to implement a custom proxy factory by subclassing
the ProxyFactory class in the Csla.DataPortalClient namespace. A proxy factory allows you to
control the proxy object created by the data portal to service data portal requests, and you can see
how this can be used to support online and offline application models.
Implementing Compression for Silverlight

When running on Silverlight or WP7, the data portal uses the MobileFormatter as discussed in
Chapter 3. The MobileFormatter can generate a substantial amount of XML when serializing an
object graph. Additionally, the WCF client technology for Silverlight and WP7 has limits on the size
Rev 0.4 (draft)
of messages that can be transferred over the network. These factors combine to make compression
of the serialized data a requirement for any meaningful application.
The CSLA .NET data portal implementation for Silverlight includes support for adding
compression of the serialized data. I chose to make this an open solution, instead of selecting a
specific compression product, to avoid coupling CSLA .NET to any one vendor’s compression library.
There are several compression products available, open source and commercial, and you can select
the product that best meets your requirements.
The SilverlightCompression solution in the code download for this ebook uses an open source
compression library that supports .NET and Silverlight. The library is available from these locations:
 http://www.icsharpcode.net/OpenSource/SharpZipLib/
 http://www.codeplex.com/slsharpziplib
There are two assemblies, one for .NET and one for Silverlight. The important feature is that they
use the same compression algorithms on both platforms, and so can compress and decompress
each other’s data.
Any compression library that can compress and decompress byte arrays or .NET
Stream objects can be used, as long as the library supports both .NET and Silverlight.
The SilverlightCompression solution contains several projects as shown in Figure 36.
Figure 36. Projects in the SilverlightCompression solution

The SilverlightCompression project is the Silverlight UI project. The
SilverlightCompression.Web project hosts the Silverlight application, and the server-side data
portal components.
The Library.Net and Library.Sl projects are simple CSLA .NET business libraries. There is no
special code required in the business library to accommodate use of the compressed data portal
channel.
The CompressedProxy project is a Silverlight project containing the implementation of
compression for the WcfProxy on the client.
The CompressedHost project is a .NET project containing the implementation of compression for
the WcfPortal on the server.

Rev 0.4 (draft)
Implementing the Compressed Data Portal Channel
So far in this chapter you have seen how to implement a custom client-side proxy. To implement a
data portal channel you must implement a proxy on the client, and a host on the server. The
Silverlight WcfProxy and WcfPortal classes are designed to allow you to add compression on the
client and server by creating your own proxy and host subclasses.
Before getting into the creation of the proxy and host, I will briefly discuss the compression
technique used in the sample application.
CompressionUtility Class
The open source SharpZipLib library used in the solution provides a low-level API that is used to
compress and decompress Stream objects. The CSLA .NET API provided to the subclasses of
WcfProxy and WcfPortal works with byte arrays. Fortunately the .NET MemoryStream type can be
used to easily convert between a byte array and a stream.
The CompressionUtility class in the CompressedHost and CompressedProxy projects
implements Compress and Decompress methods that encapsulate the use of the SharpZipLib
library.
You can look at this class to see how it works if you are interested. For the purposes of the
discussion in this ebook, it is enough to understand that the Compress method accepts a byte array
containing the original data and returns a byte array of compressed data. Similarly, the Decompress
method accepts a byte array of compressed data, and it returns a byte array of uncompressed data.
The CompressionUtility is used to implement the custom proxy and host.
Implementing the Data Portal Proxy

The CompressedProxy project includes a CompressedProxy class. This class uses the
CompressionUtility methods to compress data before it is sent to the server. It also decompresses
data returned from the server. Here’s the class:
public class CompressedProxy<T> : Csla.DataPortalClient.WcfProxy<T>
where T : Csla.Serialization.Mobile.IMobileObject
{
protected override Csla.WcfPortal.CriteriaRequest ConvertRequest(
Csla.WcfPortal.CriteriaRequest request)
{
Csla.WcfPortal.CriteriaRequest returnValue = new Csla.WcfPortal.CriteriaRequest();
returnValue.ClientContext = CompressionUtility.Compress(request.ClientContext);
returnValue.GlobalContext = CompressionUtility.Compress(request.GlobalContext);
if (request.CriteriaData != null)
returnValue.CriteriaData = CompressionUtility.Compress(request.CriteriaData);
returnValue.Principal = CompressionUtility.Compress(request.Principal);
returnValue.TypeName = request.TypeName;
return returnValue;
}
protected override Csla.WcfPortal.UpdateRequest ConvertRequest(Csla.WcfPortal.UpdateRequest request)

{
Csla.WcfPortal.UpdateRequest returnValue = new Csla.WcfPortal.UpdateRequest();
returnValue.ClientContext = CompressionUtility.Compress(request.ClientContext);
returnValue.GlobalContext = CompressionUtility.Compress(request.GlobalContext);
returnValue.ObjectData = CompressionUtility.Compress(request.ObjectData);
returnValue.Principal = CompressionUtility.Compress(request.Principal);
return returnValue;
}
Rev 0.4 (draft)
protected override Csla.WcfPortal.WcfResponse ConvertResponse(Csla.WcfPortal.WcfResponse response)
{
Csla.WcfPortal.WcfResponse returnValue = new Csla.WcfPortal.WcfResponse();
returnValue.GlobalContext = CompressionUtility.Decompress(response.GlobalContext);
returnValue.ObjectData = CompressionUtility.Decompress(response.ObjectData);
returnValue.ErrorData = response.ErrorData;
return returnValue;
}
}
This class inherits from the standard WcfProxy class provided by CSLA .NET. The CSLA .NET class
exposes three protected methods that are overridden to implement compression. The two
ConvertRequest method overloads convert a criteria-based and update request respectively.
The request parameter provided to each of these methods contains the serialized object graphs
that will be sent to the application server. You may choose to compress some or all of this serialized
data.
In many cases you’ll compress all the data as shown here. But you may choose to implement a
more sophisticated algorithm where you only compress the data if it is of a certain size. There is a
performance cost involved in compressing and decompressing data, and it can be argued that small
byte arrays shouldn’t be compressed, because the reduction in network bandwidth usage can’t
offset the performance cost of the compression.
The ConvertResponse method is invoked to decompress data coming from the server. Again, the
request parameter contains the byte arrays of compressed data, each of which corresponds to a
serialized object graph from the server. The data must be decompressed before it is returned, so
the data portal can properly deserialize the byte arrays into object graphs on the client.
Implementing the Data Portal Host

The CompressedHost project contains a CompressedPortal class. This class is a subclass of the
standard CSLA .NET WcfPortal class that implements the WCF endpoint on the server. Here’s the
class:
public class CompressedPortal : Csla.Server.Hosts.Silverlight.WcfPortal
{
protected override Csla.Server.Hosts.Silverlight.CriteriaRequest ConvertRequest(
Csla.Server.Hosts.Silverlight.CriteriaRequest request)
{
var returnValue = new Csla.Server.Hosts.Silverlight.CriteriaRequest();
returnValue.ClientContext = CompressionUtility.Decompress(request.ClientContext);
returnValue.GlobalContext = CompressionUtility.Decompress(request.GlobalContext);
if (request.CriteriaData != null)
returnValue.CriteriaData = CompressionUtility.Decompress(request.CriteriaData);
returnValue.Principal = CompressionUtility.Decompress(request.Principal);
returnValue.TypeName = request.TypeName;
return returnValue;
}
protected override Csla.Server.Hosts.Silverlight.UpdateRequest ConvertRequest(

Csla.Server.Hosts.Silverlight.UpdateRequest request)
{
var returnValue = new Csla.Server.Hosts.Silverlight.UpdateRequest();
returnValue.ClientContext = CompressionUtility.Decompress(request.ClientContext);
returnValue.GlobalContext = CompressionUtility.Decompress(request.GlobalContext);
returnValue.ObjectData = CompressionUtility.Decompress(request.ObjectData);
returnValue.Principal = CompressionUtility.Decompress(request.Principal);
return returnValue;

Rev 0.4 (draft)
}
protected override Csla.Server.Hosts.Silverlight.WcfResponse ConvertResponse(

Csla.Server.Hosts.Silverlight.WcfResponse response)
{
var returnValue = new Csla.Server.Hosts.Silverlight.WcfResponse();
returnValue.GlobalContext = CompressionUtility.Compress(response.GlobalContext);
returnValue.ObjectData = CompressionUtility.Compress(response.ObjectData);
returnValue.ErrorData = response.ErrorData;
return returnValue;
}
}
Like the proxy, this class overrides the two ConvertRequest methods to process the data coming
from the client. The client has compressed this data, so on the server the data is decompressed.
The ConvertResponse method is invoked as data is flowing from the server back to the client.
The byte arrays contain serialized object graph data, and must be compressed before they are
returned to the client.
Notice how the client and server are mirrors of each other. Where one compresses data, the
other decompresses the data. The end result is that the serialized object graphs flowing to and from
the server are serialized and compressed before going across the network.
Configuring the Application to use the Compressed Channel

Once the compressed proxy and host have been created, the application’s client and server must be
configured to use the new types.
Configuring the Client

The Silverlight client application must be configured to use the new CompressedProxy type instead
of the standard WcfProxy type. This is done in the App.xaml.cs file:
{
Csla.DataPortal.ProxyTypeName = typeof(Compression.CompressedProxy<>).AssemblyQualifiedName;
}
The ProxyTypeName property of the DataPortal class is set to the type name of the
CompressedProxy type. This causes the data portal to use this custom proxy instead of the default
proxy, ensuring that all data flowing to and from the server is compressed and decompressed.
Configuring the Server

The .NET application server must be configured to use the new CompressedPortal type instead of
the standard WcfPortal type. This impacts the SlPortal.svc file, and the WCF endpoint
configuration in the web.config file.
The SlPortal.svc file is the physical endpoint of the WCF service. It contains the type name of
the object that handles incoming WCF service requests. This type name must be CompressedPortal,
as shown here:
<% @ServiceHost Service="Compression.CompressedPortal" %>

Rev 0.4 (draft)
Also, the web.config file contains the endpoint definition for the service, and the service name
must match the name from the svc file:
<service behaviorConfiguration="WcfPortalBehavior" name="Compression.CompressedPortal">
The rest of the endpoint configuration is no different from the configurations you’ve seen
throughout this book.
At this point the client and server are configured to use the CompressedProxy and
CompressedPortal respectively, and the data flowing across the network is compressed.
This chapter has demonstrated how to create custom data portal proxy and host types to enable
some common scenarios, including support for multiple application servers, online and offline
mode, and data compression for Silverlight and WP7 client applications.

Rev 0.4 (draft)
Chapter 5:
Authentication Models
In the Using CSLA 4: Creating Business Objects ebook, I discussed how to create and use
authorization rules at a per-type and per-property level. In most cases, an authorization rule needs
access to the current user’s identity and related user information.
The default rules provided by CSLA .NET in the Csla.Rules.CommonRules namespace are
IsInRole and IsNotInRole. These rules act against the current user’s list of roles, getting that
information from the .NET principal object representing the user.
In .NET the principal object is attached to the current thread or HttpContext object. In Silverlight
and WP7 the principal object is available through the User property of the
Csla.ApplicationContext type.
If you implement your own authorization rules, you can use any data or information available to
your application’s code. But in almost all cases, authorization rules rely on access to the current
user identity and related information.
Authentication is the process of confirming the identity of the user, and establishing a principal
object for that user. This chapter will focus on the options available within CSLA .NET for
authenticating the user, and for making user information available to the rest of the application.
CSLA .NET supports three authentication models:
1. Custom authentication
2. ASP.NET Membership Provider authentication
3. Windows domain authentication
The implementation of these authentication models is slightly different on .NET and Silverlight,
but the basic concepts and overall coding structure are consistent.
Authentication Concepts
The .NET Framework stores the current user’s identity and information in a principal object. This
principal object can be accessed through several techniques.
The .NET Framework provides some pre-existing principal types you can use in your applications.
It also defines interfaces you can implement to create custom principal types. The primary
mechanism you’ll use to maintain additional user information for your application is to create a
custom identity class.
Principal and Identity Objects

The .NET Framework defines two important interfaces in the System.Security.Principal
namespace: IPrincipal and IIdentity.

Rev 0.4 (draft)
The IPrincipal interface defines a principal object. The principal object represents the current
user, and exposes two members: IsInRole and Identity.
The IsInRole method returns a Boolean result, indicating whether the current user is in a
specified role. The Identity property returns the user’s IIdentity object.
The IIdentity interface defines an identity object. Every principal object has exactly one
identity object, and an identity object is accessed through the Identity property of its principal. In
other words, the principal and identity objects have a one-to-one relationship.
The IIdentity interface defines three members: IsAuthenticated, AuthenticationType, and
Name.
The IsAuthenticated property returns a Boolean value indicating whether the current user has
been authenticated. The AuthenticationType property returns a string value indicating how the
user was authenticated. There is no standardization for the AuthenticationType value, so you’ll
have to experiment to find out what values it might contain, before using the value.
The Name property returns a string value containing the username of the current user. This is
only the Windows username when Windows authentication is used. When using custom or
Membership authentication, the username value comes from the security database.
Accessing the Principal Object

The .NET Framework provides several ways to access the current user’s principal object, depending
on the runtime environment. Some techniques are available in pure .NET, others in ASP.NET, and
some behaviors change when running in a WPF application.
The User property of the Csla.ApplicationContext class provides a safe and consistent way to
access the current user’s principal in all situations. In this section I’ll discuss how .NET exposes the
principal in each runtime scenario, and I’ll discuss how to properly use the CSLA .NET User property.
Accessing the Principal in .NET

In .NET the current principal object is accessed through the CurrentPrincipal property of the
Thread class in the System.Threading namespace. For example:
var principal = System.Threading.Thread.CurrentPrincipal;
In Visual Basic you can also use My.User to access this value.
In an ASP.NET application you can access the current principal through the User property of the
current HttpContext object. For example:
var principal = HttpContext.Current.User;
The fact that the value is available from at least three different locations in the .NET Framework
is confusing. To make things more complex, only the HttpContext value is reliable when building
web applications, but HttpContext isn’t available at all when building non-web applications.
This means that if you want to write code, such as a reusable business library, that works
properly in ASP.NET and other non-web applications, you need to write code to get the principal
object correctly depending on the environment in which your code is running.

Rev 0.4 (draft)
If that wasn’t complex enough, the WPF client environment has rules of its own. Most WPF
applications use at least some multi-threading. The WPF runtime goes to great lengths to ensure
that the principal object is reset (typically to null or GenericPrincipal) when a background thread
completes. This can make normal use of the user’s principal object quite challenging.
Fortunately CSLA .NET addresses these issues, providing a single, consistent location to access
the current principal: the User property of the Csla.ApplicationContext type:
var principal = Csla.ApplicationContext.User;
This User property automatically adapts, and retrieves the principal from the HttpContext or the
Thread when appropriate, and overcoming the auto-reset behaviors of WPF.
The way CSLA .NET adapts the User property behavior is by having different implementations for
each runtime scenario. The implementations are contained in technology-specific assemblies
included with the CSLA .NET framework. Table 9 lists the runtime scenarios and required assembly
references.
Runtime scenario Required assembly references

WPF Csla.dll
Csla.Xaml.dll
ASP.NET Web Forms Csla.dll
Csla.Web.dll
ASP.NET MVC Csla.dll
Csla.Web.dll
Csla.Web.Mvc.dll
Other .NET Csla.dll
Table 9. Assembly references required for Csla.ApplicationContext.User

Your application must reference the listed assemblies to get the correct behavior of the User
property for your runtime scenario. Your business libraries do not need to reference anything
beyond the core Csla.dll assembly.
Accessing the Principal in Silverlight and WP7

Although the Silverlight platform defines the IPrincipal and IIdentity types, it does not provide a
standard location to store or access the current principal. For example, there is no
CurrentPrincipal property on the Thread type.
CSLA .NET addresses this issue by supporting the User property on the
Csla.ApplicationContext type on Silverlight just like it does on .NET. The result is that any code
using this User property will compile and work on .NET or Silverlight interchangeably.
The consistency between .NET and Silverlight is another reason why you should prefer to access
the current principal through the User property of the Csla.ApplicationContext type.
The standard Csla.dll assembly for Silverlight and WP7 includes the correct User
implementation for those runtime scenarios. This means that your application doesn’t have to
reference the Csla.Xaml.dll assembly to get the correct behavior (although it probably will
reference that assembly for other functionality).
Rev 0.4 (draft)
When building applications with CSLA .NET you should prefer to access the current principal
through the User property of the Csla.ApplicationContext type over the other platform or
scenario-specfic techniques.
Existing .NET Principal and Identity Types

The .NET Framework defines the principal and identity types listed in Table 10.
Type Description
GenericPrincipal Simple implementation of principal that contains an IIdentity object, and a
list of roles for the current user
GenericIdentity Simple implementation of identity that contains values for IsAuthenticated,
AuthenticationType, and Name
WindowsPrincipal Principal that contains a WindowsIdentity object, and provides access to the list
of Windows domain or Active Directory groups for the user
WindowsIdentity Represents the Windows identity for the current user, or an impersonated user
FormsIdentity Identity that contains the current user’s ASP.NET security token for ASP.NET
forms authentication; typically contained within a GenericPrincipal
RolePrincipal Principal that contains a user’s roles from the ASP.NET RoleProvider; used as
part of Membership Provider authentication
Table 10. Existing .NET Principal and Identity types

The Silverlight runtime doesn’t provide any existing implementations of the IPrincipal or
IIdentity interfaces.
Creating Custom Principal and Identity Types

You can create custom principal and identity types just by implementing the IPrincipal and
IIdentity interfaces.
In a CSLA .NET application, the principal and identity objects must be serializable, because they’ll
often flow through the data portal from the client to the application server. This means that the
objects must meet the requirements for serialization described in Chapter 3. If they will be used in a
Silverlight application, the types must also implement the IMobileObject interface.
To minimize the effort involved in creating custom principal and identity types for CSLA .NET
applications, the framework provides the types listed in Table 11.
Type Description
ICheckRoles Interface that enables a principal to ask its identity to check roles
CslaPrincipal Principal base class that contains an IIdentity object; if the identity
object implements ICheckRoles the principal delegates all IsInRole
checks to the identity object; subclass CslaPrincipal to create your
own custom principal

Rev 0.4 (draft)
CslaIdentityBase Subclass this type to create a custom identity class; this type
implements ICheckRoles, and so contains a list of roles for the user
for use by a CslaPrincpal subclass
UnauthenticatedPrincipal Principal that contains an UnauthenticatedIdentity object and no
roles
UnauthenticatedIdentity Identity that represents an unauthenticated user with no roles
Table 11. Principal and Identity types provided by CSLA .NET

Because principal and identity objects always have a one-to-one relationship, the CslaPrincipal
and ICheckRoles types work together to shift all knowledge of the user’s identity, information, and
roles to the identity object. This means the CslaPrincipal object implements its IsInRole method
by delegating the call to the identity object, if the identity object implements ICheckRoles
interface.
The result is that there’s almost never a need to create a custom principal class, only custom
identity classes. The CslaIdentityBase class is much like the CSLA .NET ReadOnlyBase class, in that
it provides a base class that makes it easy to implement a custom identity type.
A custom identity type based on CslaIdentityBase can use managed property declarations, and
may use the pre-defined property values listed in Table 12.
Value Description
IsAuthenticated Boolean property indicating whether the current user is authenticated
AuthenticationType string property that returns the type of authentication used
Name string property that returns the username of the current user
Roles List of string values, each value representing a role to which the user
belongs
Table 12. Values maintained by CslaIdentityBase

If you subclass CslaIdentityBase you can add more managed properties, just like you would
when subclassing ReadOnlyBase to create an object based on the read-only stereotype.
The CslaIdentity class is a subclass of CslaIdentityBase that exposes the properties listed in
Table 12. If your application doesn’t need to add extra properties for the user, you can use a
CslaIdentity object as the identity for your application.
Impersonation
In a 3- or 4-tier physical deployment, it is usually desirable for the application server code to run
under the same security context as the client code. This means that the application server’s
principal object should be the same as the principal object on the client.
The process of ensuring that the application server uses the same principal as the client is called
impersonation, because the application server is impersonating the client user.
Implementation of impersonation depends on the type of authentication used by your
application, and by the types of technologies being used on client and server.
Rev 0.4 (draft)
Although I’ll demonstrate several common impersonation scenarios as I walk through the
authentication sample applications throughout this chapter, this section will provide an overview of
the concepts and techniques involved for each type of authentication and client/server technology.
Custom Authentication with a Smart Client

In most smart client applications, the data portal is responsible for managing impersonation when
using custom authentication. By default, the data portal serializes the client-side principal object to
the application server on each data portal request. This ensures that the same principal is used on
client and server.
For most applications the existing data portal behavior just works, providing automatic
impersonation.
There is a cost to serializing the principal and including its data in the byte stream that flows
from client to server. Sometimes it can be cheaper to recreate the principal on the server for each
data portal request. Recreating the principal usually involves connecting to the security database
and retrieving the user’s profile information and roles. You need to decide whether your application
will perform better using the default data portal behavior, or by recreating the principal on each
request.
To prevent the client-side data portal from passing the client-side principal to the server, set the
client-side authentication type to Windows. In a .NET application, this is done by setting the
CslaAuthenticationType value in the application configuration file. For example:
<appSettings>
<add key="CslaAuthentication" value="Windows"/>
</appSettings>
In a Silverlight application, this is done by setting the AuthenticationType property of the

Csla.ApplicationContext class as the application starts up. For example, this code would be in the
App.xaml.cs file:
Csla.ApplicationContext.AuthenticationType = "Windows";
If you decide to recreate the principal on each request, the client should pass the username to
the server using the ClientContext dictionary in the Csla.ApplicationContext class. On the
application server, you should implement an IAuthorizeDataPortal provider (as shown later in this
chapter) that uses the username value to retrieve the principal and identity objects from the
security database. The resulting principal object should be set as the User property of the
Csla.ApplicationContext class, effectively providing the server with the same principal as the one
on the client.
Server Configuration for .NET Clients

For .NET client applications, if the client-side authentication type is set to Windows, the server-side
authentication type must also be set to Windows in the web.config file, or the result will be an
exception on the first data portal request.
The exception will occur, because the .NET data portal on the server requires a non-null
principal object if the authentication type is not Windows, and requires a null principal object from
the client if the authentication type is Windows.

Rev 0.4 (draft)
Server Configuration for Silverlight Clients
For Silverlight and WP7 client applications, the server-side data portal does not verify that the
principal sent from the client is null or not null based on the authentication type. This means that
the authentication type on the client and server don’t have to match.
You should understand the ramifications of the values not matching.
If the client’s authentication type is custom and the server’s authentication type is Windows
authentication, impersonation will not work properly because the server will ignore the principal
object sent from the client.
If the client’s authentication type is Windows and the server’s authentication type is custom, you
must implement an IAuthorizeDataPortal provider to create the custom principal on the server
for each data portal request. This is because the client won’t pass the client-side principal to the
server if its authentication type is Windows, so the server will need to create its own principal.
Custom Authentication with a Web Application

Web applications are different from smart client applications, because web servers are typically
stateless. This means that no information is maintained in server memory between page requests.
This includes the user’s principal object.
If your web application uses a stateless server, you must recreate the principal object on each
page postback or MVC controller request. This recreated principal should be set as the User
property of the Csla.ApplicationContext class so it is the current principal while the web request
is processed on the server.
Some web applications are not stateless, and use the ASP.NET Session object to maintain state
between page requests. If your application uses a stateful server, you can put the principal object
into Session so it is maintained in memory over the lifetime of the user’s session. In this case, on
each page postback or MVC controller request you must retrieve this principal from Session and
set it as the User property of the Csla.ApplicationContext class so it is the current principal while
the web request is processed on the server.
Membership Provider Authentication with a Smart Client

Smart client applications that use the ASP.NET membership provider for authentication are
effectively using custom authentication. The client-side principal object consists of a custom
principal and identity object that contain information retrieved from the membership and role
provider databases on the server.
Because the client-side principal is a custom principal, you can make the same decision about
impersonation as I just discussed for custom authentication. By default the data portal will serialize
the client-side principal to the server on each page request.
Alternately, you can set the client-side authentication type to Windows, and implement an
IAuthorizeDataPortal provider to retrieve the user’s data from the membership and role
databases on each data portal request.
Either way, the application server will have access to a principal object created based on the
ASP.NET membership and role provider information.

Rev 0.4 (draft)
Membership Provider Authentication with a Web Application
ASP.NET natively supports the use of the MembershipProvider and RoleProvider technologies. If
you have properly configured and implemented your web application to use these technologies,
each page request will automatically use the correct user information.
Windows Authentication
Windows authentication relies on the Windows operating system to manage the user’s identity,
and to implement impersonation.
You should be aware that Windows impersonation can only take one “network
hop”. This means the application server can impersonate the client user, but then
the database server can’t impersonate the same user because that would be two
hops. This is a limitation of Windows security, and can be overcome by configuring
your Windows security domain to use Kerberos security. The use of Kerberos
security is outside the scope of this book.
When using Windows authentication, the user provides their credentials to the Windows
operation system, and Windows authenticates the user. The current principal is then a
WindowsPrincipal, containing a WindowsIdentity object.
You must configure IIS and ASP.NET on the application server to perform impersonation, at
which point Windows will automatically impersonate the client user on the application server.
The CSLA .NET authentication type should be set to Windows on the client and server. This causes
the data portal to not attempt to pass the client-side principal to the server. The WindowsPrincipal
and WindowsIdentity types are not serializable, so if the data portal does attempt to serialize them
to the server the result will be an exception.
At this point you should have a basic understanding of the .NET principal and identity object
concepts, and how they are accessed in .NET and Silverlight applications. You should also realize
that the .NET Framework and the CSLA .NET framework supply pre-existing principal and identity
types you can use in your applications.
I will now move on to discuss specific implementations of the custom, ASP.NET membership, and
Windows authentication models.
Custom Authentication
The Authentication folder in the code download for this ebook contains three solutions: Custom,
Membership, and Windows. I will be walking through the key parts of each solution through the rest
of this chapter. You should understand that ASP.NET membership authentication builds on the
concepts of custom authentication. In Silverlight and WP7, the Windows authentication solution
also builds on the concepts of custom authentication.
Custom authentication is demonstrated in the Custom solution in the Authentication folder of
the code download for this ebook. The solution contains several projects, including WPF, ASP.NET
MVC, Silverlight, and WP7 applications that share common business library code. Because there are
differences in how authentication is implemented in different application types, I will discuss each

Rev 0.4 (draft)
type of application. First though, I’ll walk through the code and concepts that are common across all
the application types.
Implementing a Custom Principal and Identity

Custom authentication is achieved by implementing custom principal and identity classes for your
application. The idea behind custom authentication is that you are not relying on the user’s
Windows domain or Active Directory identity, and instead are authenticating the user against your
own database, an LDAP server, or any other user identity or security database or service.
The CslaPrincipal class in the Csla.Security namespace is designed to act as a base class for
your custom principal. Usually the only code you’ll need to write in your custom principal are
static methods to support login and logout operations. The CslaPrincipal class implements the
IPrincipal interface from the System.Security.Principal namespace, and so your subclass will
act as a standard .NET principal object.
The CSLA .NET authentication model is designed to put all the information about the user’s
profile, roles, and other identity information into the custom identity. This means the principal
object is very small and simple, and your effort will go into creating the custom identity class.
The CslaIdentityBase<T> class in the Csla.Security namespace is designed to act as a base
class for your custom identity. This is class implements the read-only stereotype as described in the
Using CSLA 4: Creating Business Objects ebook. It also implements the IIdentity interface from the
System.Security.Principal namespace, and so your subclass will act as a standard .NET identity
object.
Implementing CustomPrincipal
The CustomPrincipal class can be found in the Library.Net project. It is also linked into the
Library.Sl and Library.Wp projects to support Silverlight and WP7 applications with the same
code.
As I mentioned earlier, this is a subclass of the CslaPrincipal base class, and most of the code
implements static methods for the login and logout operations:
[Serializable]
public class CustomPrincipal : CslaPrincipal
{
private CustomPrincipal(CustomIdentity identity)
: base(identity)
{ }
public static void BeginLogin(string username, string password, Action<Exception> completed)

{
Library.CustomIdentity.GetCustomIdentity(username, password, (o, e) =>
{
if (e.Error != null)
Logout();
else
Csla.ApplicationContext.User = new CustomPrincipal(e.Object);
completed(e.Error);
});
}
#if !SILVERLIGHT
public static void Login(string username, string password)
{

Rev 0.4 (draft)
var identity = Library.CustomIdentity.GetCustomIdentity(username, password);
Csla.ApplicationContext.User = new CustomPrincipal(identity);
}
public static void Load(string username)

{
var identity = Library.CustomIdentity.GetCustomIdentity(username);
Csla.ApplicationContext.User = new CustomPrincipal(identity);
}
#endif
public static void Logout()

{
Csla.ApplicationContext.User = new UnauthenticatedPrincipal();
}
}
There are four static methods: BeginLogin, Login, Load, and Logout. I’ll discuss the two login
methods, then the Load method, and finally the Logout method.
Login Methods
The login methods are called by the application to login the user, using the credentials supplied by
the user to prove their identity.
Although the example BeginLogin and Login methods require a username and password, your
methods could require other types of credentials. For example, some applications might also
require a PIN number, or a byte array containing fingerprint or smartcard data. Your methods must
require whatever credential values are required to authenticate the user against your custom
security database or service.
Notice how the BeginLogin and Login methods invoke the static factory methods on the
CustomIdentity class. Those static factory methods are normal read-only stereotype factory
methods that invoke the data portal to retrieve an instance of the CustomIdentity type.
The resulting CustomIdentity object is then used to create a new instance of the
CustomPrincipal type. Remember that all principal objects contain one identity object. To create
an instance of a principal object, you must pass its identity object into the constructor.
The resulting CustomPrincipal object is used to set the User property of the
Csla.ApplicationContext type. Setting the User property automatically makes this new value the
principal the current principal for the .NET thread, current HttpContext, or Silverlight application.
It is important to recognize that this process doesn’t throw an exception if the user’s credentials
are invalid. In other words, if the user provides an incorrect username or password, the result is not
an exception. Instead, the result is that the current principal is set to a valid principal object that
contains an identity object with an IsAuthenticated property value of false. Additionally, the
principal contains no roles, so the user is unauthenticated and isn’t in any roles.
On the other hand, if the user provides valid credentials, the result is that the current principal
will be set to an authenticated value that contains the user’s roles.
Load Method
The Load method is similar to the login methods, except that it only requires the username, not the
full set of credentials. This method is used by the ASP.NET MVC application to load the user’s
Rev 0.4 (draft)
principal and identity on each HTTP request. The same technique would be used in a Web Forms or
WCF service application that follows a stateless web server architecture.
In a stateless web server architecture, the web server remembers nothing between page
requests or server calls. This means the server doesn’t have an instance of the user’s principal when
a request comes in from the browser or consumer.
ASP.NET does keep track of the user’s username and whether the user’s security cookie or token
is still valid. As you’ll see when I walk through the ASP.NET MVC implementation, code in
Global.asax.cs runs on each request and uses that username value to call the Load method of the
CustomPrincpal class to load the principal and identity objects.
The Load method requires that the CustomIdentity class have a factory method that only
requires the username.
Logout Method
The Logout method sets the User property of the Csla.ApplicationContext type to a new instance
of the UnauthenticatedPrincipal type. When an UnauthenticatedPrincipal object is created, it
automatically sets its identity to a new instance of the UnauthenticatedIdentity class. The result is
that the current principal and identity is set to represent an unauthenticated user with no roles.
Implementing CustomIdentity
The CustomIdentity class is also found in the library projects. This class inherits from the
CslaIdentityBase class, and follows the read-only object stereotype described in the Using CSLA 4:
Creating Business Objects ebook:
[Serializable]
public class CustomIdentity : CslaIdentityBase<CustomIdentity>
The CslaIdentityBase class already implements the properties required by the IIdentity
interface from the System.Security.Principal namespace. These properties were listed earlier in
the chapter, in Table 12.
Implementing Custom Properties

You can add your own read-only properties if your custom identity needs to maintain extra profile
data about the user. For example, the CustomIdentity class includes a FullName property:
public static readonly PropertyInfo<string> FullNameProperty =
RegisterProperty<string>(c => c.FullName);
public string FullName
{
get { return GetProperty(FullNameProperty); }
private set { LoadProperty(FullNameProperty, value); }
}
When adding custom properties, it is important to remember that these properties add to the
object’s state. In most cases, this means they increase the size of the data flowing between the
client and server on each data portal call. By default, a custom principal (and its identity object) flow
from the client to the server on each data portal call.

Rev 0.4 (draft)
If you put a lot of extra properties into the identity, this can have a performance impact on the
application. Sometimes you need these properties, and in that case there are two alternatives to
consider.
One is to prevent the principal from flowing to the server on each data portal call. In that case
you will need to load the principal on the server for each call, and that will result in more load on
your security database or service. This can be a good approach, but you do need to evaluate the
overall performance ramification. I will discuss this alternative in more detail later in this chapter.
Another is to maintain the user’s additional profile in a completely separate object. That object
would typically be a read-only object, and would be stored in the LocalContext dictionary of the
Csla.ApplicationContext class on the client. Because LocalContext values don’t flow from client
to server through the data portal, the values would only exist in memory on the client. If the values
are also required on the server, they’d need to be loaded from the security or user profile database
on each server request.
Many applications are able to use the standard IIdentity interface properties, with perhaps
one or two relatively small additional values such as the user’s email, or department name. I usually
just add these values as properties to my custom identity as shown in the example CustomIdentity
class.
Implementing the Factory Methods

The class also implements standard static factory methods that invoke the data portal to
retrieve the object:
public static void GetCustomIdentity(
string username, string password, EventHandler<DataPortalResult<CustomIdentity>> callback)
{
DataPortal.BeginFetch<CustomIdentity>(new UsernameCriteria(username, password), callback);
}
#if !SILVERLIGHT
public static CustomIdentity GetCustomIdentity(string username, string password)
{
return DataPortal.Fetch<CustomIdentity>(new UsernameCriteria(username, password));
}
internal static CustomIdentity GetCustomIdentity(string username)

{
return DataPortal.Fetch<CustomIdentity>(username);
}
#endif
There are asynchronous and synchronous methods to validate the user’s identity and retrieve a
CustomIdentity object based on the username and password values provided by the static login
methods in the CustomPrincipal class.
These methods make use of the UsernameCriteria class from the Csla.Security namespace.
This is a standard criteria class that contains Username and Password property values.
The UsernameCriteria class does not encrypt the password. In a 3- or 4-tier

deployment, you should consider using SSL (HTTPS) or WCF transport security to
ensure sensitive data like the password is encrypted as it flows across the network.

Rev 0.4 (draft)
There’s also a synchronous method to retrieve the user’s identity based on the username. This
method is internal in scope to help limit its use, and it is intended for use throught the Load method
in the CustomPrincpal class.
The important thing to understand is that these are all just normal static factory methods
following the read-only object stereotype. The CustomIdentity class is nothing more than a
specialized subclass of the ReadOnlyBase class.
Implementing Data Access

All the code so far has been focused on passing the user’s credentials through the login methods of
the CustomPrincipal class, to the factory methods in CustomIdentity, and ultimately through the
data portal to the data access code.
It is in your data access fetch operation that the credentials are verified, and if they are correct,
the user’s roles are loaded into the identity object.
The exact code you write to verify the credentials and load the user’s data depends on the
security database or service you are using. In the example code I’m using a mock database, but a
real application might store the data in a SQL Server database, an LDAP server, or using the
Windows Identity Foundation (WIF).
From a CSLA .NET perspective, it doesn’t matter where the user data is stored, as long as you can
accomplish three functions:
1. Verify the user’s credentials against the security store
2. Retrieve the user’s list of roles (if using a role-based authorization model)
3. Retrieve any user profile data required by your custom identity (if any)
The example CustomIdentity class is implemented using the encapsulated invoke data access
model as discussed in the Using CSLA 4: Data Access ebook. You may choose to use the factory
implementation, or any of the other data access models in your application. Remember that this is
just a read-only business object, so any data access model will work.
Here’s the business class code from the Custom solution:
private void DataPortal_Fetch(UsernameCriteria criteria)
{
AuthenticationType = "Custom";
var dal = new DataAccess.IdentityDal();
if (dal.VerifyUser(criteria.Username, criteria.Password))
LoadUserData(criteria.Username, dal);
}
private void DataPortal_Fetch(string username)

{
AuthenticationType = "Custom";
var dal = new DataAccess.IdentityDal();
LoadUserData(username, dal);
}
private void LoadUserData(string username, DataAccess.IdentityDal dal)

{
var userData = dal.GetUser(username);
IsAuthenticated = (userData != null);
Rev 0.4 (draft)
if (IsAuthenticated)
{
Name = userData.Username;
FullName = userData.FullName;
Roles = new Csla.Core.MobileList<string>(dal.GetRoles(Name));
}
}
The two DataPortal_Fetch overloads are required because the factory methods pass either a
UsernameCriteria or the single username value.
The overload that accepts the UsernameCriteria parameter calls a VerifyUser method exposed
by the data access provider. This method returns a value indicating whether the credentials
supplied by the user match those in the security database or service.
If the credentials don’t match, no exception is thrown. Instead, the CustomIdentity is returned
with its default values. Most importantly, the IsAuthenticated property is false, indicating that
the identity represents an unauthenticated user.
You should not throw an exception when the credentials can’t be verified. The .NET
Framework’s authentication model is not designed to support an exception-based
model, and expects a valid (if unauthenticated) identity to be returned when
authentication fails.
If the credentials are verified, the LoadUserData method is invoked to load the user’s profile and
role information. The DataPortal_Fetch overload that accepts only the username value always
invokes the LoadUserData method.
The LoadUserData method calls the data access provider to get the user’s profile information.
That’s the FullName value in the example code. It also retrieves the list of roles or groups to which
the user belongs.
The CslaPrincipal base class provides an IsInRole method implementation that delegates to
the identity object if that object implements the ICheckRoles interface from the Csla.Security
namespace. The CslaIdentityBase class implements ICheckRoles by checking the list of roles in
the object’s Roles property. This simplifies retrieval of the user information, because the user’s
authentication status, profile data, and roles are all maintained by one object: the custom identity
object.
You can look at the IdentityDal class in the DataAccess project to see the implementation of
the data access code. The code uses LINQ queries against an in-memory mock database as
described in the Using CSLA 4: Data Access ebook.
At this point you should understand how to implement custom principal and identity classes to
support custom authentication for any CSLA .NET application. The one area you’ll need to focus on
is the data access implementation, where the user’s credentials are verified, and the user profile
and role information is retrieved.
I will now cover how to configure the application server, and then briefly discuss how the static
login methods implemented in the CustomPrincipal class are used by the various types of
applications supported by CSLA .NET.

Rev 0.4 (draft)
The Custom solution is configured for a 3-tier deployment of each application. The Custom.Web
project is the application server that hosts the data portal for .NET and Silverlight clients.
Because the entire authentication process is implemented through a data portal fetch operation
on the CustomIdentity class, you can use the code and techniques discussed in this chapter for 1-,
2-, 3-, and 4-tier deployments. There is no application server in a 1- or 2-tier deployment, and the
data access code runs on the client workstation. I’ll discuss some issues around 4-tier deployments
later in the chapter as part of the Silverlight application. Many .NET applications are deployed in 3-
tier environments as demonstrated by the Custom solution.
The basic configuration of the application server is the same as I discussed in Chapter 1, and I
won’t repeat that content here. In summary, the application server includes two svc files that act as
endpoints for the .NET and Silverlight data portal. The web.config file contains the WCF
configuration for those services, and the project references Csla.dll, the Library.Net project, and
the DataAccess project, ensuring that those assemblies are in the bin folder on the server.
As I mentioned earlier in this chapter, the data portal will, by default, transfer the client-side
principal and identity objects to the server on each data portal call. Part of configuring the
application server is deciding whether to allow this default impersonation, or to implement your
own impersonation. I will discuss both models.
Data Portal Impersonation

There is no unique or special requirement for the application server configuration to support
standard custom authentication.
The default authorization type for CSLA .NET on a server is Csla, meaning that the .NET data
portal will require the client to provide a principal object on each data portal request. The Silverlight
data portal doesn’t require the principal object, but if one is provided by the client it will be
automatically set as the current principal on the server.
CSLA .NET is designed with the assumption that the application server will be used by many
concurrent users. When the current principal is set, it is set on the specific thread that is servicing
one user request. As that request completes, the principal value on that thread is set to null to
prevent a subsequent user request from accidentally impersonating the wrong user.
Custom Impersonation
You can configure the client application to not pass the client-side principal to the server on each
data portal request. I’ll discuss how this is done as I talk about each type of client application.
The value of preventing the principal from being serialized to the server on each request is that
your application will consume less bandwidth on the network. The downside to this choice, is that
the server will need to retrieve the user’s identity object from the security database or service on
every data portal request.
Setting CslaAuthorization
The first step is to configure the data portal to use the Windows authentication type in the server’s
web.config file:
Rev 0.4 (draft)
<appSettings>
</appSettings>
This may be a little confusing, because the application is not using Windows authentication, it is
using custom authentication.
When the server-side data portal is configured with the authentication type of Windows, it
requires that the client not pass a principal to the server through the data portal. And this setting
will cause the data portal to not explicitly set the server-side principal value.
Normally the assumption is that the Windows operating system will perform the impersonation,
but in this case ASP.NET is not configured to impersonate the client user. The result is that the
server principal isn’t set to any explicit value.
That works well, because the application will be setting the value in a custom authorization
provider.
Implementing IAuthorizeDataPortal
Retrieving the principal on each server request is done with a custom authorization provider.
Immediately after deserializing the client request, the data portal can invoke an authorization
provider. This is a class that implements the IAuthorizeDataPortal interface from the
Csla.Server namespace.
This provider will have access to the ClientContext and GlobalContext dictionaries from the
client, as well as other information about the data portal request. This provider can set the current
principal of the server thread based on that information.
If the client doesn’t pass the client-side principal to the server, it does need to pass the
username value. I typically pass the username value to the server by using the ClientContext
dictionary.
The Custom solution contains a custom authorization provider in the AuthorizeDataPortal class
in the Library.Net project. The application server’s web.config must tell the data portal to use this
type by setting the CslaAuthorizationProvider value:
<appSettings>
<add key="CslaAuthorizationProvider" value="Library.AuthorizeDataPortal, Library"/>
</appSettings>
The AuthorizeDataPortal class implements an Authorize method:

public class AuthorizeDataPortal : IAuthorizeDataPortal
{
public void Authorize(AuthorizeRequest clientRequest)
{
if (Csla.ApplicationContext.LocalContext["FirstRun"] == null &&
Csla.ApplicationContext.AuthenticationType == "Windows")
{
// the firstrun check is required, because server-side code
// can call the data portal, so the data portal may be invoked
// many times to handle a single client request
// LocalContext is used to ensure this value is per-user,
// because the application server is probably servicing
// many users at once on different threads
Csla.ApplicationContext.LocalContext["FirstRun"] = false;

Rev 0.4 (draft)
// the app is configured to not auto-impersonate, (the
// authentication type is "Windows", so create principal
// from database, using the username value provided
// by the client in the ClientContext dictionary
var username = (string)Csla.ApplicationContext.ClientContext["Username"];
if (string.IsNullOrWhiteSpace(username))
Csla.ApplicationContext.User = new UnauthenticatedPrincipal();
else
CustomPrincipal.Load(username);
}
}
}
The Authorize method is invoked by the data portal for each data portal request. It is important
to remember that server-side code can invoke the data portal too, so one client-side data portal
request might result in numerous calls to the Authorize method. Only the first call on the thread is
the one that came from the client.
The implementation in the AuthorizeDataPortal class is designed to automatically enable if the
CslaAuthentication configuration value is Windows. Otherwise it does no work.
Also, the implementation only runs on the first data portal request on the thread. That is the
request that came from the client, and all subsequent requests are known to be completely server-
side data portal calls. The LocalContext dictionary is used to maintain a FirstRun flag for this
purpose.
Although you might be tempted to use a static field for this value, it is important to remember
that static fields are shared across the AppDomain, and so are not per-thread. A static field
would be shared across multiple concurrent data portal requests from different users, and so would
not work. The CSLA .NET LocalContext dictionary is per-thread.
The username value is retrieved from the ClientContext dictionary. This dictionary flows from
the client to the server with each data portal request, and is designed to be used for this type of
scenario.
Once the code has the username value from the client, it can call the Load method on the
CustomPrincipal class. That method uses the synchronous factory method on the CustomIdentity
class to retrieve the user’s identity object. It then sets the current principal to an instance of the
CustomPrincipal type.
The result is that, on each data portal request from the client, the thread servicing that request
has the correct principal object, loaded fresh from the security database or service.
You can use the default data portal impersonation, or custom impersonation, as appropriate for
your application. The important thing to keep in mind is that the client and server must be
configured to use the same type of impersonation.
I’ll now move on to briefly discuss the configuration of each type of client application.
Client Application Configuration

The configuration of smart client applications on .NET and Silverlight are very similar, but there are
some subtle differences between the platforms. Web applications, ASP.NET MVC or Web Forms,
will have different implementations depending on whether a stateless or stateful web server model
is used by the application.
Rev 0.4 (draft)
.NET Smart Client Application
The .NET Framework supports smart client applications through WPF, Windows Forms, and console
applications. When using custom authentication, it is the application’s responsibility to prompt the
user for their credentials and to pass the credentials to the login methods on the CustomPrincipal
class for verification.
You can choose to implement the login process synchronously or asynchronously. If you choose
an asynchronous implementation, it is important to realize that the application will have an
unauthenticated principal until the asynchronous data portal operation returns the authenticated
CustomIdentity (assuming the user’s credentials are valid). This means that the application must
implement proper authorization behaviors to prevent an unauthorized user from using the
application until the login process is complete.
The WpfUI project in the Custom solution follows a very basic MVVM (Model-View-ViewModel)
implementation pattern. The MainWindow view is bound to a MainWindowViewModel viewmodel
object, and that object interacts with the underlying model object. In this case, the model object is
the User property of the Csla.ApplicationContext class.
The application uses the CustomPrincipal class to authenticate the user as the application starts
up. For the purposes of the sample application, the user credentials are hard-coded into the
MainWindowViewModel class. The viewmodel object exposes an ApplicationReady property that
indicates whether the authentication process is complete.
The MainWindow view has a Canvas that acts as an overlay to prevent the user from clicking on
elements of the UI until ApplicationReady is true. The Visibility property of the Canvas is bound
to the ApplicationReady property of the viewmodel:
<Canvas Background="Gray" Opacity=".2"
Visibility="{Binding Path=ApplicationReady,
Converter={StaticResource VisibilityConverter}}"/>
The viewmodel also exposes the identity object so the view can bind to its properties. For
example:
<TextBox Grid.Column="1" Grid.Row="0" Height="23" HorizontalAlignment="Left" Margin="3"
Name="authenticationTypeTextBox"
Text="{Binding Path=Identity.AuthenticationType, Mode=OneWay}"
VerticalAlignment="Center" Width="120" IsReadOnly="True" />
The application can be configured to use the default data portal impersonation, or custom
impersonation.
Using Data Portal Impersonation

The data portal defaults to implementing impersonation by passing the client-side principal to the
application server on every data portal call. No special configuration is required to use this feature.
It is important that the application have some valid, serializable principal before any data portal
call. This includes the initial data portal call to authenticate the user. By default, a .NET application
will have an unauthenticated GenericPrincipal and GenericIdentity as the current principal.
Because this is a serializable type, the default value is supported by the data portal and no special
code or configuration is required.

Rev 0.4 (draft)
Here’s the code that makes the asynchronous call to authenticate the user as the application
starts up:
public MainWindowViewModel()
{
CustomPrincipal.BeginLogin("rocky", "test", (ex) =>
{
if (ex != null)
MessageBox.Show(ex.ToString());
OnPropertyChanged("Identity");
OnPropertyChanged("IsAdmin");
OnPropertyChanged("IsGuest");
ApplicationReady = true;
});
}
If you wanted to perform the login operation synchronously, the code would look like this:
{
CustomPrincipal.Login("rocky", "test");
}
Either way, the static login method on the CustomPrincipal class is invoked to authenticate
the user’s credentials. When that process is complete, the current principal will be set to an
authenticated or unauthenticated principal object, depending on whether the credentials were
verified.
In a more complete application, this code would run once the user has entered their credentials
into some sort of login dialog or UI control. I’ll show a more complete example of the login process
in the Using CSLA 4: Silverlight 4 and WPF ebook.
The OnPropertyChanged method calls in MainWindowViewModel raise the ProperyChanged event
so WPF data binding refreshes the display. The results are shown in Figure 37.

Rev 0.4 (draft)
Figure 37. WpfUI showing successful custom authentication results
You can see that the result is an authenticated user, with a FullName property. The user is in the
Admin role, but not the Guest role.
This is expected, based on the data loaded into the mock database in the Database project:
static MockDb()
{
Users = new List<User>
{
new User { Username = "rocky", Password="test", FullName = "Rocky Lhotka" }
};
UserRoles = new List<UserRole>
{
new UserRole { Role = "Admin", Username = "rocky" }
};
}
This principal object will flow from the client to the application server with each subsequent data
portal call, ensuring that any authorization code running on the application server will run against
the same user principal and identity as the code on the client workstation.
Using Custom Impersonation

If the application server is configured to use the Windows authentication type and a custom
IAuthorizeDataPortal implementation as I discussed earlier in this chapter, then the client must
also be configured to use custom impersonation.
Configuring a .NET client to use custom impersonation is a two part process.
First, the client must be configured to use the Windows authentication type in the app.config
file:
<appSettings>
</appSettings>
Setting the CslaAuthentication value to Windows causes the client-side data portal to not pass
the client-side principal to the server with each data portal request.
Second, the client must pass the username value to the application server. You may remember
that the IAuthorizeDataPortal implementation shown earlier in this chapter expected the
username to be in the ClientContext dictionary. The client application must set that value as part
of the login process.
The MainWindowViewModel is where the login process occurs in the example code, and that’s
where the username value is added to the dictionary:
{
{
if (ex != null)
Rev 0.4 (draft)
// if we are not using auto-impersonation, then
// set a ClientContext value so the username flows
// to the server, so the server can create its own
// principal object on each data portal request
if (Csla.ApplicationContext.AuthenticationType == "Windows")
Csla.ApplicationContext.ClientContext["Username"] =
Csla.ApplicationContext.User.Identity.Name;
});
}
In this case the code only adds the username to the dictionary if the authentication type is
Windows.
The result is that the client will not pass the client-side principal to the server, but it does pass
the username. This allows the application server to retrieve the principal directly from the security
database or service based on the username. Less data is passed over the network from the client to
the server, but the load on the security database will be higher.
At this point you should understand how to configure a .NET smart client to use custom
authentication. Next, I’ll discuss the configuration of a Silverlight or WP7 client application.
Silverlight and WP7 Applications

The SilverlightUI and WpUI projects in the Custom solution demonstrate the basic
implementations of Silverlight and WP7 client applications.
Both projects follow the same MVVM pattern as the WpfUI project. Each has a main view that
binds to a viewmodel. That viewmodel is essentially the same as the viewmodel in the WpfUI
project, including the ApplicationReady property that is bound to a Canvas control.
Because all server access from Silverlight must be asynchronous, the login process must be
implemented asynchronously. The MainPageViewModel class contains a hard-coded call to the
BeginLogin method of the CustomPrincipal class:
public MainPageViewModel()
{
{
if (ex != null)
// if we are not using auto-impersonation, then

// set a ClientContext value so the username flows
// to the server, so the server can create its own
// principal object on each data portal request
if (Csla.ApplicationContext.AuthenticationType == "Windows")
Csla.ApplicationContext.ClientContext["Username"] =
Csla.ApplicationContext.User.Identity.Name;
});
}
This code should be familiar, because it is the same as the asynchronous code used in the WpfUI
project.

Rev 0.4 (draft)
Configuring a Silverlight or WP7 application for custom authentication is very similar to
configuring a .NET client application, but the configuration occurs in code instead of in a
configuration file.
Using Data Portal Impersonation

Just like in .NET, Silverlight defaults to the correct configuration for custom authentication with
automatic impersonation. The App.xaml.cs file in the Silverlight application contains this code:
{
}
No special configuration is required. When the application is run the results are the same as in
WPF. Figure 38 shows the Silverlight UI:
Figure 38. SilverlightUI showing successful custom authentication results

The App.xaml.cs file in the WP7 application contains similar code, but in the App class
constructor:
public App()
{
UnhandledException += Application_UnhandledException;
if (System.Diagnostics.Debugger.IsAttached)
{
Application.Current.Host.Settings.EnableFrameRateCounter = true;
}
InitializeComponent();
InitializePhoneApplication();
}

Rev 0.4 (draft)
The primary difference between Silverlight and WP7 is that the data portal defaults to using the
LocalProxy in WP7, so this code also sets the ProxyTypeName property to the WcfProxy type.
Figure 39 shows the Windows Phone UI:
Figure 39. WpUI showing successful custom authentication results

The data portal defaults to the correct configuration for custom authentication.

Assuming the application server is properly configured for custom impersonation, configuring a
Silverlight client is a two step process.
First, the authentication type must be set to Windows as the application starts up. This is done by
setting the AuthenticationType property in the App.xaml.cs file:
{
}
This authentication type prevents the data portal from passing the client-side principal to the
application server with each data portal call.

Rev 0.4 (draft)
Second, the username value must be added to the ClientContext dictionary. This is done as
part of the login process, and is exactly the same as the code in the WpfUI project.
The WP7 application follows the same steps, setting the AuthenticationType property in the
constructor of the App class, and passing the username to the application server through the
ClientContext dictionary.
At this point you should understand how to configure .NET, Silverlight, and WP7 applications to
use custom authentication. I will now discuss web application configuration.
ASP.NET Applications
ASP.NET applications include ASP.NET Web Forms, ASP.NET MVC, web services, and WCF services
applications. All of these applications run on a server in ASP.NET, and have access to ASP.NET core
features.
Perhaps the most important decision for any web application is whether the server will be
stateless or stateful. A stateless server doesn’t maintain any information in memory between client
requests. A stateful server typically uses the ASP.NET Session object to maintain information in
memory between client requests.
ASP.NET provides support for authentication, including managing an encrypted user token in a
cookie or on the URL. This encrypted user token, at a minimum, contains the username and an
expiration time, after which the token becomes invalid.
When a user is authenticated, ASP.NET generates this user token, and the token is provided to
the server on each client request so ASP.NET is able to maintain the user’s identity and
authentication status.
Optionally, the token can contain the list of user roles. Normally this is not the case, because
there are limits on cookie sizes, and sending the data over the network on each request is
considered wasteful. For the purposes of this discussion, I’ll assume the default behavior, where
only the username and authentication status is available from ASP.NET on each client request.
When the server is stateless, the user’s principal and identity objects must be retrieved on each
client request. This is done by passing the username from the ASP.NET security token to the Load
method of the CustomPrincipal class.
If the server is stateful you can choose to put the principal object into the ASP.NET Session
object so it is available on each client request without retrieving the data from the security
database or service.
This approach does increase the size of the state maintained between page requests. The web
site can be configured to use an out-of-proc or SQL Server location to maintain Session. In such a
scenario the Session object (and therefore the principal and identity objects) is deserialized from
state storage into memory at the start of each page request, and it is serialized from memory into
state storage at the end of each page request.
You should evaluate whether storing the principal in Session provides better performance for
your application than retrieving it from the security database on each client request.

Rev 0.4 (draft)
Because the recommended architecture for web applications is to use a stateless server, that is
what I’ll focus on in the rest of this chapter.
The MvcUI project in the Custom solution is an example of an ASP.NET application that uses
custom authentication in a stateless web server scenario.
The Home\Index view displays data from the ViewModels\UserViewModel viewmodel object. That
object exposes information from the current principal and identity object provided by the User
property of the Csla.ApplicationContext class.
This application interacts with the same application server (the Custom.Web project) as the
previous applications, and so is configured to run in a 3-tier model. You can deploy web applications
in a 2-tier model as well, as long as the web server has access to the database server so the data
access code can function correctly.
Basic Data Portal Configuration

The MvcUI project follows the normal configuration for a client application. This means it configures
the data portal through settings in the web.config file:
<appSettings>
</appSettings>
The data portal defaults to the correct configuration for custom authentication, so no special
configuration is required.
Setting the Principal on Each Client Request

The interesting part about writing a web application is that you must write code that runs at the
start of each client request to set the current principal object for the user. This code is in the
Global.asax.cs file:
protected void Application_AcquireRequestState(object sender, EventArgs e)
{
var identity = HttpContext.Current.User.Identity;
if (identity.IsAuthenticated)
{
CustomPrincipal.Load(identity.Name);
}
}
ASP.NET does create principal and identity objects based on its security token. Unfortunately
those objects don’t contain the user’s roles or any profile information. Only the username and
authentication status is available.
You can see how this code uses the authentication status and username from the ASP.NET
identity object to invoke the synchronous Load method on the CustomPrincipal class. The result is
that the real CustomPrincipal and CustomIdentity objects are set as the current principal for the
duration of this client request.
This code runs before any MVC controller code, Web Forms page code, or service
implementation code. By the time your regular application code is executed, this code will have run
and so the current principal will be set to the correct value.

Rev 0.4 (draft)
Login Process
In a full ASP.NET MVC or Web Forms application the login process is typically handled by a custom
membership provider. This is a subclass of the MembershipProvider class from the
System.Web.Security namespace. I will cover that in detail in the Using CSLA 4: ASP.NET MVC
ebook.
For the purposes of the example MvcUI application, the user credentials are hardcoded, and the
user login process occurs on the request to the web site. This code is included in the
Global.asax.cs file:
CustomPrincipal.Login("rocky", "test");
if (Csla.ApplicationContext.User.Identity.IsAuthenticated)
FormsAuthentication.SetAuthCookie(Csla.ApplicationContext.User.Identity.Name, false);
The first time the user hits the MvcUI web site this code runs to verify the user. If the user is
authenticated the code sets up the ASP.NET security token. All subsequent client requests will
retrieve the principal based on the username in the security token.
Figure 40 shows the results displayed in the browser when the MvcUI application is executed:
Figure 40. MvcUI showing successful custom authentication results

As with the previous applications, you can see that the correct values are provided from the
CustomPrincipal and CustomIdentity objects for the user.

In a 3-tier deployment, where the web server is interacting with an application server, it is possible
to use a custom impersonation model to avoid sending the serialized principal from the web server
to the application server on each data portal request.
As with the previous application types, this requires that the application server implement
custom impersonation. The web application configuration is a two step process.
First, the web.config file of the web application needs to configure the data portal with the
Windows authentication type:
Rev 0.4 (draft)
<appSettings>
</appSettings>
This prevents the data portal from sending the principal from the web server to the application
server on each data portal request.
Second, the username must be placed into the ClientContext dictionary. This must occur on
each client request to the web site, and so it is implemented in the Global.asax.cs file:
protected void Application_AcquireRequestState(object sender, EventArgs e)
{
var identity = HttpContext.Current.User.Identity;
{
CustomPrincipal.Load(identity.Name);
Csla.ApplicationContext.ClientContext["Username"] = Csla.ApplicationContext.User.Identity.Name;
}
}
In this configuration, each client request will cause the web application to retrieve the principal
through the data portal. Then, each subsequent data portal request will cause the application
server to retrieve the principal based on the username in the ClientContext dictionary. This will
increase the load on your security database or service, but will reduce the network load between
the web and application servers.
At this point you should understand how to configure and implement custom authentication on
an application server, and in .NET, Silverlight, WP7, and ASP.NET applications. Custom
authentication is the basis for all membership authentication, as well as the basis for Windows
authentication for Silverlight and WP7 applications.
I’ll now move on to discuss membership authentication.
Membership Provider Authentication

The ASP.NET membership and role provider implementations have become one of the most widely
used authentication models for applications. CSLA .NET applications can make use of these
providers in all application types, as long as the application server is hosted in ASP.NET and is
configured to use the membership and role providers.
When using this type of authentication, your application will use custom authentication against
the membership and role providers. Because of this, make sure you fully understand the use of
custom authentication as described in the previous section of this chapter before reading this
section on the membership provider.
The Membership solution in the Authentication folder of the code download for this ebook
contains a sample implementation of membership authentication. The structure of this solution is
the same as the Custom solution from the previous section in this chapter, with one exception.
This solution implements a pluggable data access provider model, so there’s a DataAccess
project and a DataAccess.Net project. The DataAccess project dynamically loads the provider
based on configuration, and the DataAccess.Net project is a provider implementation. This type of
implementation is described in the Using CSLA 4: Data Access ebook.
Rev 0.4 (draft)
I’ll discuss the implementation differences for membership authentication in more depth
throughout this section of the chapter.
Implementing a Membership Principal and Identity

The Library.Net project in the Membership solution includes CustomPrincipal and
CustomIdentity classes. These classes are also linked into the Library.Sl and Library.Wp projects,
so they are available to Silverlight and WP7 applications.
The CustomPrincipal class is the same as in the Custom solution. It implements static methods for
login and logout operations, including BeginLogin, Login, Load, and Logout methods. These
methods invoke static factory methods on the CustomIdentity class, and use the resulting
identity object to establish the current principal for the application.
The CustomIdentity class is similar to the one in the Custom solution.
Instead of a FullName property, this class adds an Email property to the pre-existing properties
required by the IIdentity interface:
public static readonly PropertyInfo<string> EmailProperty = RegisterProperty<string>(c => c.Email);
public string Email
{
get { return GetProperty(EmailProperty); }
private set { LoadProperty(EmailProperty, value); }
}
This is because the membership provider exposes the user’s email address, but doesn’t provide a
full name value.
The class implements the same static factory methods as the version in the Custom solution,
allowing for synchronous and asynchronous verificaition of the user’s credentials. The membership
provider uses username and password credentials, so those are the values that flow through the
data portal to the server-side data portal code.
Implementing Data Access

The data access implementation follows the encapsulated invoke model described in the Using
CSLA 4: Data Access ebook. The CustomIdentity class includes DataPortal_Fetch methods that
invoke the data access layer (DAL) provider to verify the user’s credentials, and to retrieve the
user’s profile and role information.
This solution uses a pluggable data access provider model, and that is a requirement in this case.
The reason it is a requirement is that the data access code will use types from the
System.Web.Security namespace in the System.Web.dll assembly. That assembly is part of the full
.NET Framework 4 project profile in Visual Studio. The setting is shown in Figure 41.

Rev 0.4 (draft)
Figure 41. Target framework set to .NET Framework 4
The Library.Net project targets the .NET Framework 4 Client Profile, and so can’t reference an
assembly that targets the full profile. The way around that limitation is to use a dynamically loaded
assembly for the DAL provider. To accomplish this, the DataAccess project also targets the .NET
Framework 4 Client Profile, and it dynamically loads the DataAccess.Net DAL provider
implementation.
As a result, the DataPortal_Fetch methods are similar to those from the Custom solution, but
they get a DAL manager, and use that manager to get the dynamically loaded provider:
private void DataPortal_Fetch(UsernameCriteria criteria)
{
AuthenticationType = "Membership";
using (var mgr = DataAccess.DalFactory.GetManager())
{
var dal = mgr.GetProvider<DataAccess.IIdentityDal>();
LoadUserData(criteria.Username, dal);
}
}
private void DataPortal_Fetch(string username)

{
AuthenticationType = "Membership";
{
LoadUserData(username, dal);
}
}
private void LoadUserData(string username, DataAccess.IIdentityDal dal)

{
IsAuthenticated = (userData != null);
if (IsAuthenticated)
{
Name = userData.Username;
Email = userData.Email;
Roles = new Csla.Core.MobileList<string>(dal.GetRoles(Name));
}
}
This is the exact model discussed in detail in the Using CSLA 4: Data Access ebook, so this code
structure should be familiar to you.
Rev 0.4 (draft)
Notice that the LoadUserData method is virtually identical to the one in the Custom solution. If
the user’s credentials are verified, this method is called to load the user’s profile and role data from
the DAL provider.
The DAL provider implementation is in the DataAccess.Net project in the IdentityDal class:
public class IdentityDal : IIdentityDal
{
public bool VerifyUser(string username, string password)
{
var result = Membership.ValidateUser(username, password);
return result;
}
public UserDto GetUser(string username)

{
var user = Membership.GetUser(username);
var result = new UserDto { Username = user.UserName, Email = user.Email };
return result;
}
public IEnumerable<string> GetRoles(string username)

{
var data = Roles.Provider.GetRolesForUser(username);
return data;
}
}
This project targets the .NET Framework 4 profile, and references the System.Web.dll assembly.
The VerifyUser method calls the ValidateUser method of the Membership class from the
System.Web.Security namespace. The ValidateUser method verifies the user’s credentials,
returning true if the credentials are valid.
The GetUser method gets the user profile data from the membership provider. In this case, the
username and user’s email address are retrieved. These values are returned in a data transfer
object (DTO). The UserDto type is defined in the DataAccess project, and so is available to the code
in the DataAccess.Net and Library.Net projects.
Finally, the GetRoles method gets the user role data from the ASP.NET role provider. The
GetRolesForUser method of the roles provider from the System.Web.Security namespace is used
to retrieve the role data.
Notice that the Provider property of the Roles type is used to make this call. There is a
GetRolesForUser method on the Roles type itself, but that method throws an unexpected
NullReferenceException when invoked from a WCF service such as the data portal. This didn’t
occur prior to .NET 4, and is presumably a bug in the .NET Framework. Calling the method through
the Provider property avoids the unexpected exception and is a viable workaround.
The data access code runs on the application server. Before this code will work, the application
server must be configured to use the membership and role providers.

Before an application can use the ASP.NET membership and role providers, the application server’s
web application must be configured to use those providers. This includes the creation of an
ASP.NET security database, and configuration of the providers in the web.config file.
Rev 0.4 (draft)
The Custom.Web project in the Membership solution has been configured to use the membership
and role providers. The simplest way to do this in a web application is to select the web project in
the Solution Explorer window in Visual Studio, and to then choose the Project|ASP.NET
Configuration menu option. This will bring up the ASP.NET Web Site Administration Tool shown
in Figure 42.
Figure 42. Security tab of the ASP.NET Web Site Administration Tool
The Security tab is selected in Figure 42, showing that this application has been configured to
enable membership and roles.
When the membership and role providers have been configured, they’ll have entries in the
system.web element of the web.config file, usually along with a database connection string for the
ASP.NET security database:
<connectionStrings>
<add name="ApplicationServices"
connectionString="Data Source=.\SQL2008;AttachDbFilename=
|DataDirectory|aspnetdb.mdf;Integrated Security=True;User Instance=True"/>
</connectionStrings>
<system.web>
<compilation debug="true" targetFramework="4.0" />
<authentication mode="Forms" />
<membership userIsOnlineTimeWindow="15">
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider"
connectionStringName="ApplicationServices"
enablePasswordRetrieval="false" enablePasswordReset="false"
requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6"

Rev 0.4 (draft)
minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
applicationName="/" />
</providers>
</membership>
<roleManager enabled="true" cacheRolesInCookie="false">

<providers>
<clear />
<add connectionStringName="ApplicationServices"
applicationName="/" name="AspNetSqlRoleProvider"
type="System.Web.Security.SqlRoleProvider" />
</providers>
</roleManager>
</system.web>
In this case the ASP.NET security database is a SQL Server Express database named
aspnetdb.mdf. The file is located in the web site’s App_Data folder.
The ASP.NET membership and role providers are flexible. Details on configuring all aspects of
these providers are outside the scope of this book. The authentication techniques shown in this
chapter will work against the membership and role providers as long as their configuration is valid
within your environment.
The data access code in the DataAccess.Net project uses the Membership and Roles types from
the System.Web.Security namespace. Those types use the providers configured in the web.config
file to interact with the security database to verify the user’s credentials, and to retrieve profile and
role data.
Client Application Configuration

The Membership solution includes WPF, Silverlight, WP7, and ASP.NET MVC client applications. The
client applications all use the CustomPrincipal and CustomIdentity types in the same with
membership authentication as with custom authentication.
In other words, the client applications are constructed and configured the same in this section of
this chapter as in the previous section. You can look through the client applications in the code
download, but I won’t walk through their code, as that would be repetitive.
The exception is Silverlight. In the case of Silverlight and WP7 applications, it is possible to
implement a 4-tier solution where the client application communicates with the web server, and
the web server communicates with the application server.
Silverlight and WP7 4-Tier Applications

The Membership solution demonstrates how to implement a 3-tier deployment for Silverlight and
WP7 applications. The client applications use the data portal to communicate with the application
server, where the data access code interacts with the Membership and Roles types to authenticate
the user.
In a 4-tier deployment, you might choose to run the membership and role providers on the web
or application server.
If you choose to run the providers on the application server, then no special configuration is
required. The Silverlight default data portal behavior on the web server is to relay every data portal
request to the application server, so the code and configuration shown in the Membership solution
is unaffected.
Rev 0.4 (draft)
If, on the other hand, you choose to run the providers on the web server, then some code
changes are required for authorization. Specifically, the “data access” code for the CustomIdentity
class must run on the web server, not the application server.
To make this happen, the CustomIdentity class must have a MobileFactory attribute that
directs the data portal on the web server to invoke a mobile factory object. That mobile factory
object, running on the web server, will then invoke a data access component on the web server that
uses the Membership and Roles types to authenticate the user.
The CustomIdentity class is declared like this:
[Serializable]
[Csla.Server.MobileFactory("Library.CustomIdentityFactory, Library")]
public class CustomIdentity : CslaIdentityBase<CustomIdentity>
The MobileFactory attribute causes the data portal on the web server to create an instance of
the CustomIdentityFactory class, and invoke a Fetch method on that object. That Fetch method is
responsible for managing the data access process. In this case that means calling a data access
component to authentication the user.
The CustomIdentity class would no longer contain any DataPortal_Fetch methods, because all
data access is managed by the mobile factory object.
Implementing the Mobile Factory

An example of a mobile factory implementation can be found in the Library.Net project. The
CustomIdentityFactory class shows how to construct the code that would run on the web server.
This class uses the factory invocation data access model discussed in the Using CSLA 4: Data
Access ebook. This means the Fetch methods in the factory class invoke a data access layer:
public class CustomIdentityFactory : Csla.Server.ObjectFactory
{
public CustomIdentity Fetch(Csla.Security.UsernameCriteria criteria)
{
var result = new CustomIdentity();
LoadProperty(result, CustomIdentity.AuthenticationTypeProperty, "Membership");
{
LoadUserData(criteria.Username, dal, result);
}
return result;
}
public CustomIdentity Fetch(string username)

{
var result = new CustomIdentity();
LoadProperty(result, CustomIdentity.AuthenticationTypeProperty, "Membership");
{
LoadUserData(username, dal, result);
}
return result;
}

Rev 0.4 (draft)
private void LoadUserData(string username, DataAccess.IIdentityDal dal, CustomIdentity identity)
{
LoadProperty(identity, CustomIdentity.IsAuthenticatedProperty, (userData != null));
{
LoadProperty(identity, CustomIdentity.NameProperty, userData.Username);
LoadProperty(identity, CustomIdentity.EmailProperty, userData.Email);
LoadProperty(identity, CustomIdentity.RolesProperty,
new Csla.Core.MobileList<string>(dal.GetRoles(userData.Username)));
}
}
}
As you can see, the code in this class is very similar to the code in the DataPortal_Fetch
methods used in the 3-tier implementation. I have chosen to use the same DataAccess and
DataAccess.Net DAL implementations.
It is important to note that the DAL assemblies must be installed on the web server
for this code to work. Additionally, the membership and role providers must be
configured on the web server.
The result is that the Silverlight or WP7 client applications will invoke the data portal normally.
When the data portal request arrives at the web server, the data portal will route the call to an
instance of the CustomIdentityFactory type. The CustomIdentityFactory object uses the DAL to
authenticate the user, and to create a CustomIdentity object. That CustomIdentity object is then
returned to the client.
At no point is the application server involved in the authentication process, because the security
database and providers are all on the web server. Other business classes will flow through to the
application server as normal, only the CustomIdentity class is different due to its MobileFactory
attribute.
When using this 4-tier approach, you will typically want to allow the data portal to perform its
default impersonation by including the client-side principal object as part of each data portal
request. The reason is that your application server probably won’t have access to the web server,
and so won’t be able to directly create a principal object for each request. Therefore you should
expect to pass the principal from the client through the data portal to the application server to
provide a consistent security environment for your business objects.
At this point I’ve covered custom and membership authentication. The final type of
authentication I’ll discuss is Windows domain or Active Directory authentication.
Windows Authentication
Many organizations rely on Windows authentication to secure their applications, and to provide
some level of single sign-on functionality across the organization. In these cases the servers and
workstations in the organization are typically part of a Windows Active Directory domain, and all
user credentials and roles are managed as part of that domain.
This is particularly nice for .NET smart client and internal ASP.NET web applications, because all
the authentication and role management is provided automatically by the Windows operating
system. From a CSLA .NET application perspective, the application must simply be configured to not
Rev 0.4 (draft)
perform any explicit user authentication or impersonation, so the application relies entirely on the
operating system to do the work.
Silverlight applications are a different story. These technologies assume the application will be
running outside the organization’s security domain, and so there’s no provision on these platforms
to automatically integrate with a Windows domain. However, CSLA .NET does support Windows
authentication for Silverlight applications. This is implemented as a form of custom authentication,
where the user is authenticated against the Windows domain.
The Windows solution in the Authentication folder of the code download for this ebook
provides an example of using Windows authentication with CSLA .NET. At a high level the structure
of this solution is similar to the Custom and Membership solutions I discussed earlier in this chapter,
but there are differences throughout the solution.
WP7 applications can not currently use Windows authentication through WCF, so there is no
WpUI project in the Windows solution.
You should be aware that executing and testing applications that use Windows security can be
complex. Certain scenarios require a Windows domain, others require being in a network
configured as a workgroup. Some features are only available with a real IIS server, while others can
be used with IIS Express.
The business library projects (such as the Library.Net project) in the Windows solution include a
UserInfo class that is used by the sample applications. This is a read-only business object that
retrieves user information from the application server. Each application displays the user
information on the client and the information from the server to establish that the client identity
has been impersonated on the server.
As I discuss each scenario I’ll discuss the configuration requirements. In most cases you will need
to change or apply those requirements to the projects in the Windows solution before it can
successfully execute.
.NET Applications
Windows client workstations are often members of the Windows domain, and when a user logs into
the workstation, they log in using a Windows domain account. Such domain accounts are available
to all machines in the domain, including the workstation and the application server, and the user
identity can flow from client to server automatically.
If the workstation and server are part of a workgroup instead of a domain, Windows will still
attempt to flow the client Windows identity to the server. To do this, Windows looks for a user
account on the server with the same username and password as on the client. If it can find one, it
assumes the accounts represent the same user.
The real magic comes from the use of the wsHttpBinding in WCF, because that binding carries
the client’s Windows identity to the server when the server is configured to use Windows
authentication. The application server and client must be configured properly for this to occur.

Rev 0.4 (draft)
In a 3-tier deployment, the application server must be configured to use the client identity through
Windows impersonation. This is done by setting some configuration values in the web.config file
for WCF and CSLA .NET.
Not all WCF bindings support impersonation, but the commonly used wsHttpBinding does
support this feature. The wsDualHttpBinding and netTcpbinding also support impersonation. Also,
basicHttpBinding supports impersonation, as I’ll discuss when I cover Silverlight clients.
Configuring WCF to use the client’s Windows identity is done by adding a serviceAuthorization
element to the custom behavior used by the service endpoint. The Custom.Web project in the
Windows solution is the application server, and it contains this endpoint configuration:
<service name="Csla.Server.Hosts.WcfPortal" behaviorConfiguration="windowsAuthReturnFaults">
</service>
The behaviorConfiguration value has been changed from previous examples to point to a new
custom behavior. That custom behavior is declared like this:
<behavior name="windowsAuthReturnFaults">
<serviceAuthorization impersonateCallerForAllOperations="true" />
</behavior>
Notice the serviceAuthorization element with the impersonateCallerForAllOperations

property set to true. This will cause WCF to impersonate the client user before calling any service
operations.
The web.config must also include a CslaAuthentication value to set the authentication type to
Windows:
<appSettings>
<add key="CslaAuthentication" value="Windows" />
</appSettings>
The result of this setting is that the server-side data portal won’t change the server-side principal
value, allowing the Windows operating system to perform impersonation.
Smart Client Application Configuration

There are three steps required to configure the client application for Windows impersonation.
First, the .NET Framework must be told to use the Windows identity of the user logged into the
client workstation. This is done by setting the current AppDomain object’s principal policy as the
application starts up. In the WpfUI project, the App.xaml.cs file contains this code:
public partial class App : Application
{
{
System.AppDomain.CurrentDomain.SetPrincipalPolicy(
System.Security.Principal.PrincipalPolicy.WindowsPrincipal);
}
}

Rev 0.4 (draft)
This will cause the .NET Framework to set the current principal to a WindowsPrincipal object
that represents the identity of the user that is logged into the client workstation.
Second, a CslaAuthentication setting must be added to the app.config file. For example, the
WpfUI project in the Windows solution has this configuration:
<appSettings>
<add key="CslaDataPortalProxy" value="Library.WcfWindowsProxy, Library"/>
</appSettings>
Setting this value to Windows ensures that the data portal won’t attempt to pass the client-side
principal to the server as part of the data portal request. The WindowsPrincipal isn’t serializable, so
if this value isn’t set you will get a serialization exception on any attempt to use the data portal.
Finally, the client application must use a custom data portal proxy instead of the standard
WcfProxy class from the Csla.DataPortalClient namespace. This custom proxy configures WCF to
enable impersonation. The WcfWindowsProxy class in the Library.Net project provides this
implementation:
public class WcfWindowsProxy : Csla.DataPortalClient.WcfProxy
{
protected override System.ServiceModel.ChannelFactory<Csla.Server.Hosts.IWcfPortal>
GetChannelFactory()
{
var factory = base.GetChannelFactory();
factory.Credentials.Windows.AllowedImpersonationLevel =
System.Security.Principal.TokenImpersonationLevel.Impersonation;
return factory;
}
}
The default WcfProxy implementation is used to create the channel factory object. Then the
AllowedImpersonationLevel property of the Windows credential object associated with the
channel factory is set to allow impersonation.
If you look back at the appSettings block from the app.config file shown earlier, you should
notice that the CslaDataPortalProxy setting indicates that the data portal should use the
WcfWindowsProxy type from the Library assembly.
You can see the results of running the WpfUI project in Figure 43.

Rev 0.4 (draft)
Figure 43. WpfUI showing Windows impersonation results
You can see that the user information from the server is the same as that on the client.
Although the WpfUI application can run against an application server hosted in IIS Express, that
doesn’t prove that impersonation has occurred. This is because IIS Express runs under the user
account of the user logged into the workstation. To prove that impersonation occurs, you need to
host the application server in IIS, in an application pool that runs under a different user account
from the user logged into the workstation.
At this point you should understand the steps required to configure the application server and
the .NET client application to use Windows authentication and impersonation between the client
and server.
Silverlight Applications
Silverlight applications interact with Windows authentication and impersonation quite differently
from .NET smart clients. The Silverlight runtime itself has no concept of Windows principal or
identity objects. It relies on the browser hosting the Silverlight runtime to manage any identity
negotiation with the server.
Your Silverlight application can use Windows authentication against the server. When the
application attempts to interact with the server, the browser will prompt the user for their
Windows credentials, or the browser will perform an automatic credential negotiation process. The
specific behavior depends on the browser and the browser’s configuration for the web site.
Assuming the user, the browser, and the server are able to authenticate the user’s credentials,
the WCF data portal service on the server will run under the user’s Windows domain account.
As I mentioned, the Silverlight runtime has no concept of Windows identities. To make the
Windows username and domain groups available to the Silverlight application, custom principal and
identity objects are used. The custom identity object is created on the server, and it is loaded with
the username and roles for the user account under which the service is running on the application
server.

Rev 0.4 (draft)
Because the server is configured to require Windows authentication, the service will be running
under the user account based on the credentials supplied by the user and their browser, so the
custom identity object returned to the Silverlight client will contain a copy of the user’s Windows
username and domain roles.
The Library.Net project contains a CustomPrincipal class, and that class is linked into the
Library.Sl project so it is also available to Silverlight applications.
This CustomPrincipal class is the same as the class used in the Custom and Membership
solutions, except that it has no Load method. The Load method is not required for Silverlight clients,
and so is not necessary in this solution.
The custom principal object contains a CustomIdentity object, and it is the CustomIdentity
class that contains the code to retrieve a copy of the user’s Windows username and domain roles.
The Library.Net project contains the CustomIdentity class, and that class is linked into the
Library.Sl project so it is also available to Silverlight applications.
The CustomIdentity class inherits from the WindowsIdentity class in the
Csla.Silverlight.Security namespace. The WindowsIdentity base class is an implementation of
the read-only object stereotype, as well as of the IIdentity interface from the
System.Security.Principal namespace. You can think of it as a specialized version of the
CslaIdentityBase class discussed earlier in this chapter.
The WindowsIdentity base class exposes a protected method named

PopulateWindowsIdentity. This method loads the identity object with the username and domain
group (role) values from the current .NET WindowsIdentity object. The .NET WindowsIdentity
object represents the Windows account for the current thread on the server, and that should
correspond to the user if the application server is properly configured for Windows authentication.
The CustomIdentity class looks like this:
[Serializable]
public class CustomIdentity : Csla.Silverlight.Security.WindowsIdentity
{
public static void GetCustomIdentity(EventHandler<DataPortalResult<CustomIdentity>> callback)
{
DataPortal.BeginFetch<CustomIdentity>(callback);
}
#if !SILVERLIGHT
public static CustomIdentity GetCustomIdentity()
{
return DataPortal.Fetch<CustomIdentity>();
}
private void DataPortal_Fetch()

{
PopulateWindowsIdentity();
}
#endif

Rev 0.4 (draft)
As you can see, it implements the normal factory methods, and a DataPortal_Fetch method
that simply calls the PopulateWindowsIdentity method on the base class. The result is an identity
object that contains a copy of the current user’s Windows username and domain roles.
The reason you are required to create a subclass of the WindowsIdentity base class, is so you
are able to customize the process as necessary. For example, you might add code in the
DataPortal_Fetch method to invoke a more traditional data access provider to get extra user
profile or role information beyond that pulled from the user’s Windows account.

To configure the application server, ASP.NET must be set to use Windows authentication.
Additionally, the service endpoint for the Silverlight data portal must be configured to require
Windows credentials from the caller. These configuration details are set in web.config file for the
server application.
This article contains useful information about server configuration for Silverlight
clients: http://msdn.microsoft.com/en-us/library/dd744835(VS.95).aspx.
The Custom.Web project in the Windows solution has this entry in the system.web element of the
web.config file:
<authentication mode="Windows" />
And the custom basicHttpBinding used by the Silverlight data portal endpoint includes a
security element:
<basicHttpBinding>
<binding name="basicHttpBinding_IWcfPortal" maxReceivedMessageSize="2147483647">
maxDepth="2147483647" />
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
The security mode property is set to TransportCredentialOnly, and the clientCredentialType

value is set to Windows. This configures the service to require that Windows credentials be supplied
by the caller before the service is invoked. Those credentials are used to set the current principal for
the thread that will run the service.
The result is that when a Silverlight application calls this service, the browser provides the server
with the user’s credentials, and the service runs under the corresponding Windows domain
account.
Silverlight Client Implementation

The Silverlight client is configured as the application starts up, using code in the App.xaml.cs file.
The SilverlightUI project includes this code:

Rev 0.4 (draft)
{
}
The important setting here is that the AuthenticationType property of the

Csla.ApplicationContext type is set to Windows. This prevents the client-side data portal from
passing the client-side principal to the application server with each data portal request. The
application will rely on the browser to provide the server with the user’s Windows credentials, so
there’s no need to send the custom principal object to the server.
The client application must “log in” by calling the data portal to retrieve the CustomIdentity
object containing a copy of the user’s Windows account information. The MainPageViewModel class
in the SilverlightUI project performs this task by calling the BeginLogin method on the
CustomPrincipal class:
CustomPrincipal.BeginLogin((ex) =>
{
if (ex != null)
{
}
else
{
}
});
Once the CustomIdentity object has been retrieved, the User property of the
Csla.ApplicationContext type will be set to the CustomPrincipal object containing the
CustomIdentity object that has the user’s Windows account information. From that point forward,
the client application has access to a principal that is essentially the same as the user’s Windows
principal.
It is important to use something like the ApplicationReady property to prevent the user from
interacting with the application until the client-side principal has been set. Remember that the
Silverlight client has no knowledge of the user’s identity until the login process is complete.
If you look at the actual code in the MainPageViewModel class it is a bit more complex. After the
login process is complete, the code calls the GetUserInfo factory method of the UserInfo class to
retrieve information about the principal being used by the server.
When the application is run, the browser will appear, and will immediately prompt the user for
their Windows credentials as shown in Figure 44.

Rev 0.4 (draft)
Figure 44. Browser prompting for the user’s Windows credentials
When the client attempts to interact with the server through the data portal as part of the login
process, the browser must provide the server with the user’s credentials. Your browser may be
configured to automatically provide that information, but in many cases the user will be prompted
as shown here.
This way the application can display the client-side and server-side user information as shown in
Figure 45.
Figure 45. SilverlightUI showing Windows authentication results

Looking at Figure 45, you can see that the client and server expose similar values. This is because
the client code is using the values from the CustomIdentity object, and they are a copy of the
information being used on the server.
This application can be run against an application server hosted in IIS or IIS Express. Either way,
the browser will prompt the user for their credentials, establishing that the server is configured to
require Windows authentication for the data portal service.
At this point you should understand how Silverlight applications rely on the browser to provide
the application server with the user’s Windows credentials. This is triggered by the application
server being configured to require Windows authentication. The Silverlight client uses a custom
identity object to retrieve a copy of the Windows account information from the application server.

Rev 0.4 (draft)
ASP.NET Applications
Web applications can often only use Windows authentication in a 2-tier deployment. The user’s
credentials flow from the browser to the web server, which is one network hop. Unless your
network is configured with Kerberos security, the user’s credentials can’t flow through the web
server to an application server or database server.
The MvcUI project in the Windows solution is configured as a 2-tier deployment, so the user’s
identity doesn’t flow past the web server. This means the “client-side” and “server-side” data portal
components are all running on the web server, in the same security context. As long as the web
application requires Windows authentication, the user’s domain account will be used for
authorization.
A 3-tier deployment is a scenario where the web server interacts with the application server
through the data portal. Because the default NTLM security model won’t allow the user’s identity to
flow from the browser to the web server to the application server, it is not normally possible to
have the application server use the same identity as the web server.
I’ll discuss the configuration of the MvcUI web application for Windows authentication.
Web Server Configuration

The web server is configured to require Windows authentication in the system.web element of the
web.config file. This is in the MvcUI project:
<authentication mode="Windows"/>
There is no explicit data portal configuration. The default data portal configuration is to use the
LocalProxy, and to rely on the existing principal object provided by the operating system or
runtime.
The web site must be configured to disable anonymous authentication in IIS, thereby requiring
that the user provide Windows credentials to access the site.
Figure 46 shows the display in the IIS Manager console where the security settings are
controlled.
Figure 46. Disabling anonymous authentication in IIS Manager

If you are using IIS Express, you must also enable Windows authentication. This is done by
selecting the MvcUI project in Solution Explorer and setting the properties in the Properties window
as shown in Figure 47.
Rev 0.4 (draft)
Figure 47. Configuring IIS Express for the MvcUI project
Notice that anonymous authentication is disabled, and Windows authentication is enabled.
The result is that the user must provide Windows credentials before they are allowed to access
the web application, and the web application will run under the user’s Windows account. Before
the user can access the web site, the browser will prompt them to supply their domain credentials.
The user will see a dialog similar to the one shown earlier in this chapter in Figure 44.
When the application is run it will display the user information being used by the logical client-
side and server-side code in the application. This is shown in Figure 48.
Figure 48. MvcUI showing Windows authentication results

If I did configure the application to use an application server in a 3-tier deployment, the results
would look something like Figure 49.

Rev 0.4 (draft)
Figure 49. MvcUI showing the results of 3-tier Windows authentication
In this case I logged into the web application with a username of WebHost, but the application
server (running in IIS Express) is clearly running under a different user account. This is because the
user identity already went across one network hop from the browser to the web server, and can’t
then flow to the application server.
This chapter has covered custom, membership, and Windows authentication for .NET smart
client, Silverlight, WP7, and ASP.NET web applications.
Security and authentication is a complex topic, and there are many more permutations on
security than I’ve covered in this chapter. The content in this chapter should provide you with an
understanding of the way CSLA .NET approaches authentication, and you should be able to adapt
these techniques to accommodate other authentication scenarios.

Rev 0.4 (draft)
Conclusion
This book has provided you with the information necessary to use and configure the data portal in
1-, 2-, 3-, and 4-tier physical deployments of an application. If your application follows the five layer
architecture prescribed by CSLA .NET, you can reconfigure the data portal with no impact on the
application code.
In 3- and 4-tier deployments, you can host application server code in IIS, Windows AppFabric,
and Windows Azure. Other hosting options are avaiable, such as WAS or a custom Windows service.
This is the forth in a series of ebooks. Subsequent ebooks will demonstrate how to use the
concepts and techniques from these first four books to create various types of application interface
that leverate a CSLA .NET based business layer composed of domain objects.

Rev 0.4 (draft)

UsingCsla4 04 DataPortal

Uploaded by

Copyright:

Available Formats

UsingCsla4 04 DataPortal

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UsingCsla4 04 DataPortal

Uploaded by

Copyright:

Available Formats

Using CSLA 4

Data Portal Configuration

Copyright © 2011 by Marimer LLC

Editor: Teresa Lhotka

Errata or other comments about this book should be emailed to [email protected].

You can reach Magenic at

CSLA .NET has attracted a community of very

The bug fixes and feature enhancements

Thank you all!

Chapter 1: Data Portal Deployment ....................................................................................................................... 3

Using CSLA 4: Data Portal Configuration Page i

Chapter 2: Data Portal Configuration Reference .................................................................................................. 65

Chapter 3: Serialization ........................................................................................................................................ 69

Chapter 4: Custom Data Portal Proxies ................................................................................................................ 72

Chapter 5: Authentication Models ....................................................................................................................... 86

Using CSLA 4: Data Portal Configuration Page ii

Conclusion ......................................................................................................................................................... 131

Using CSLA 4: Data Portal Configuration Page iii

Using CSLA 4: Data Portal Configuration Page iv

Using CSLA 4: Data Portal Configuration Page v

Using CSLA 4: Data Portal Configuration Page vi

Organization of the Book

1. Using CSLA 4: CSLA .NET Overview

2. Using CSLA 4: Creating Business Objects

3. Using CSLA 4: Data Access

4. Using CSLA 4: Data Portal Configuration (this book)

Framework Code and Samples

Using CSLA 4: Data Portal Configuration Page 2

Figure 1. Five layer logical architecture

Data Portal Concepts

1. Client-side data portal components

2. Proxy/host communication channel

3. Server-side data portal components

Figure 2. Client, server, and proxy/host areas of functionality

I discuss the MobileFormatter in detail in Chapter 3.

Proxies and Hosts

Data Portal Proxies

Data Portal Hosts

Using CSLA 4: Data Portal Configuration Page 5

Using CSLA 4: Data Portal Configuration Page 6

Figure 3. 2-tier smart client deployment

Figure 4. 2-tier web deployment

Figure 5. 3-tier smart client deployment

Using CSLA 4: Data Portal Configuration Page 8

Using CSLA 4: Data Portal Configuration Page 9

2. Between the application and the database server

Using the Local Channel

This is not necessary, because it is the default.

Using CSLA 4: Data Portal Configuration Page 11

Specifically, the ProxyTypeName property of the Csla.DataPortal class needs to be set to

// other code goes here

Serialization and AutoCloneOnUpdate

Using the WCF Channel

Windows Communication Foundation (WCF)

Basic WCF Configuration

Using CSLA 4: Data Portal Configuration Page 15

Customizing a WCF EndPoint

Using CSLA 4: Data Portal Configuration Page 16

Message Size Limits on Bindings