(X) Hide this
    • Login
    • Join
      • Say No Bots Generate New Image
        By clicking 'Register' you accept the terms of use .

Building a Silverlight Line-Of-Business Application – Part 3

(42 votes)
Chris Anderson
>
Chris Anderson
Joined Sep 29, 2008
Articles:   8
Comments:   62
More Articles
27 comments   /   posted on Nov 10, 2008
Categories:   Data Access , Line-of-Business

This article is compatible with the latest version of Silverlight.

Introduction

In Part 2 of this series I completed implementing the inventory list screen. The focus of this article is to describe the process of transferring data between the server (a WCF service) and the client (the Silverlight application), securely and sharing common business logic where possible.

Source Code* and Live Demo**

*To run the source code take a look at the "Using the sample application" section of the previous article first.

**To login in the sample application use the following Username: demo and Password: demo.

Be sure to check all articles of the series: Part 1, Part 2, Part 3, Part 4, Part 5 and Part 6

Securing Your WCF Service

It is important that any data you make available via the internet is accessible by only those with permission to view that data, and they can only make the modifications or perform the actions they are permitted based upon their role. When you make data available via the internet you need to view it as if you were a hacker (cracker is probably the proper term, but mildly savvy users can also exploit a number of weaknesses) and attempt to identify any ways that someone may attempt to work around your security measures. It is then your task to ensure these holes are plugged. 

This is a Line-Of-Business application, therefore by definition you are dealing with critical and sensitive business data that in the wrong hands could potentially bring a business to its knees. The larger and more public a company is the higher the risk someone will attempt to find a hole and circumvent the system, but small companies should not be lax on this point either despite their reduced target size. Angry ex-employees are often the culprits in system break-ins and can potentially wreak havoc. Corporate espionage from rivals is not unknown either. So it is vital that you secure access to your business critical data.

In Part 1 I touched on transferring data between the server and the client, with a method to validate user credentials (Login) and retrieving a list of products (GetProductList). User credentials were validated against the built in SQL Server membership providers. However you may have noted that anyone regardless of whether they had previously logged in who wanted to “hack” the system could directly call the GetProductList function and still retrieve a product list as this function didn’t check whether this user had previously logged in and had the permission to call this method. This is a security hole that we need to plug by ensuring that with every service call the user has permission to perform that action.

There are numerous means of securing access to your WCF service (only permitting access to logged in users or users assigned to a particular role), each with a number of pros and cons. I will detail two of these methods that make it to the top of my list – the first using forms authentication cookies, and the second using message headers.

Security Using the ASP.NET Forms Authentication Cookie

If you’ve worked with ASP.NET previously you’ve no doubt used the built in forms authentication functionality. Essentially once the user has been authenticated (using the SQL Server membership provider or a custom provider that you implement yourself) they are issued with a cookie that they send to the server with each additional page request, containing their authentication information. This cookie holds a forms authentication ticket containing the user name, the issue date, the expiry date, and miscellaneous other information, all encrypted (with the machine key) so the details can’t be read without knowing the key to decrypt it. This cookie and the ticket it contains exhibit the following behaviours:

  • The cookie (and separately the ticket inside it) expires after a set period of time (by default 30 minutes). This means that if someone was sniffing your network traffic and attempted to “spoof” your cookie it would quickly become invalid as the expiry date contained within the ticket would soon be reached and access would thus be denied.
  • So that the user would not have to log in every 30 minutes whilst they are actively interacting with the server (or whatever the timeout period is set to) the cookie/ticket implements a sliding expiration scheme where with each request to the server the cookie will be updated with a new ticket that extends the expiry to 30 minutes from that request. Note however this behaviour includes a few caveats which you can explore further in the articles in the resources at the end.
  • You can set the cookie to be persistent (across browser sessions). Note that creating a persistent cookie does not mean that the cookie will remain forever – it will still expire at its set expiry date (generally after 30 minutes). I have to admit previously being rather confused by this point as I expected that a persistent cookie would last forever, but found that the meaning of persistent in this case did not equate to being permanent.
  • The cookie is created with the HTTPOnly cookie attribute that prevents client side script (and Silverlight!) from reading the cookie for security purposes.

You can override all these behaviours between configuration in the web.config and through code if you need to – but it can make identifying issues difficult when other programmers come to maintain the code, and these are configured this way by default for security purposes so it’s not really recommended to override the behaviour in code.

I describe this at a rather high level because there is actually quite a bit of complexity in how this cookie works and its behaviour – more than what I want to go into here. However I’ve included some resources at the end that you can use to investigate this further.

In Silverlight we can also leverage the ASP.NET forms authentication cookie to provide authentication functionality to our WCF service. By using the following function to send a cookie back to the client when the user successfully logs in:

FormsAuthentication.SetAuthCookie(userName, false);

this cookie will automatically be sent with each additional call to our WCF service (until it times out) and we can use this to identify the user. If we configure our service (in its web.config) to be compatible with ASP.NET by adding the following node under the system.serviceModel section:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

and configuring our membership and role providers in the web.config file (as you would in a standard ASP.NET project) the user will automatically be authenticated and assigned as the current user of the HTTPContext.

The next thing that we need to do is actually accept or deny this user access to each method on our WCF service, based upon whether the caller is authenticated and possibly whether they are assigned to a particular role. An elegant means of doing this is by using declarative security, decorating each method with a PrincipalPermission attribute and the associated access permission.

Declarative security uses the current principal of the thread (a role principal). This is not automatically assigned when using ASP.NET forms authentication, but it is automatically assigned to the current user of the HTTP context so we can assign that value to the current principal of the thread in the constructor of the service like so:

Thread.CurrentPrincipal = HttpContext.Current.User;

We can then apply our attributes to each method to demand that the user is authenticated first:

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]

Or that the user is assigned to a particular role:

[PrincipalPermission(SecurityAction.Demand, Role="Administrator")]

In the prior version of this application (see the code for Part 2) I used this functionality to authenticate the user, so you can see the above method in action there. However there are some issues when using the forms authentication scheme which turned me away from using it (though I will still continue to use the declarative security). My primary issue against transparently having the cookie containing the authentication ticket passed between the client and the server is that this cookie expires, and there is no way of knowing from Silverlight when it has expired (other than making a call to the service and it failing). Because it is created with the HTTPOnly cookie attribute (as previously described) we can’t determine through Silverlight whether it exists or not, and re-login automatically when it doesn’t. We could attempt to determine when it would have expired by monitoring when the last call was made to the service, but due to the complexity of the sliding expiration scheme it just becomes too unwieldy and complicated to make it worth the effort. We could override the default behaviour of the cookie on the server side (ie. set the expiry of the cookie to sometime long into the future) but I wasn’t particularly fussed with this approach either (though it would work, and you may choose to use this method for this reason).

Security Using SOAP Message Headers

As of RC0 of Silverlight, functionality was added to Silverlight to support SOAP message headers. I decided to investigate this as a means of passing the user credentials to the service as a per call authentication scheme. To implement this we need to create an operation context which has the outgoing message headers to add the credentials object to before making our call. I have created a class to hold the credentials with two properties – UserName and Password. Using this class we create an object containing the user credentials which we pass to the service in the message header. For example this is the code now required to request the product list:

// Add our user credentials to the message headers
using (OperationContextScope scope = new OperationContextScope(service.InnerChannel as IClientChannel))
{
    MessageHeader header = MessageHeader.CreateHeader(typeof(UserCredentials).Name, 
        UserCredentials.WS_NAMESPACE, new UserCredentials(Globals.UserName, Globals.Password), false);
 
    OperationContext.Current.OutgoingMessageHeaders.Clear();
    OperationContext.Current.OutgoingMessageHeaders.Add(header);
 
    // Now request data from the service
    service.GetProductListCompleted += 
        new EventHandler<GetProductListCompletedEventArgs>(AWDataService_GetProductListCompleted);
    service.GetProductListAsync(SummaryListToolbar.CurrentPageNumber, 
        Globals.LIST_ITEMS_PER_PAGE, m_lastFilterString, string.Join(", ", sortBy));
}

Note that we need to initiate the call to the service while within the using block of the OperationContextScope. We would also need to add the code to add the message header every time we wanted to call the service – not particularly elegant (ie. repeated code, extra lines with each call, etc). The next section on instantiating the WCF service from a central location will describe a better method of adding the credentials in the message header for each service call to reduce the above code to this:

// Now request data from the service
AWDataServiceClient service = AWServiceFactory.GetService();
service.GetProductListCompleted += 
    new EventHandler<GetProductListCompletedEventArgs>(AWDataService_GetProductListCompleted);
service.GetProductListAsync(SummaryListToolbar.CurrentPageNumber, Globals.LIST_ITEMS_PER_PAGE, 
    m_lastFilterString, string.Join(", ", sortBy));

which is much more acceptable and elegant, reducing the code required to make a call to the service the same as when using the first method of authentication.

On the server we can now retrieve the user credentials object from the incoming headers, validate the user name and password, create a role principal for that user, and assign it to both the user of the current HTTP context and to the current principal of the current thread. Our declarative security attributes will take care of the rest.

MessageHeaders messageHeaders = OperationContext.Current.IncomingMessageHeaders;
int headerIndex = messageHeaders.FindHeader(typeof(UserCredentials).Name, UserCredentials.WS_NAMESPACE);
 
if (headerIndex != -1)
{
    UserCredentials userCredentials = messageHeaders.GetHeader<UserCredentials>(headerIndex);
    AWBusinessObjects.Security.User user = Login(userCredentials.UserName, userCredentials.Password);
 
    if (user != null)
    {
        // Generate a role principal representing the security context for this user, and
        // assign it to the current HTTP context and the current thread for them to run under
        RolePrincipal securityPrincipal = new RolePrincipal(new GenericIdentity(userCredentials.UserName));
        HttpContext.Current.User = securityPrincipal;
        Thread.CurrentPrincipal = securityPrincipal;
    }
}

For the purpose of this sample application (based upon the pros and cons I’ve identified) I have decided to use the second authentication method – passing the user credentials in the header of each call to the service. However either of the two methods described above are valid to use as an authentication scheme and you are free to use whichever you feel is appropriate.

Using SSL

Despite the above security measures it is still possible for someone to break into your system. Someone monitoring (aka “sniffing”) the traffic to your server could watch for users logging in and capture their login credentials or authentication ticket/cookie, as they are being sent in plain text across the internet. They could then use these to impersonate that user and obtain access to your system. You could encrypt these details (very easy considering it would be easy to write an encryption/decryption routine in Silverlight) making it harder for someone sniffing your traffic to identify these details. But it’s still not a robust solution as a Silverlight application can easily be decompiled using Reflector (especially easy when combined with the Silverlight Spy tool) so a hacker could easily gain access to your encryption/decryption key and algorithm rendering it useless). Or they could just impersonate you using the encrypted details as easily as if they were decrypted. You can make life harder for hackers but you are unlikely to discourage them from ultimately reaching their goal. To test how easy it is to sniff the data being transferred try using Fiddler or use Silverlight Spy – both can capture and show all network traffic between your machine and the server.

If you didn’t want to pass the user name and password with every service call when using the second forms authentication method, you could instead generate a forms authentication ticket on the server (the same as is stored in the cookie using the first authentication method), return that from the Login method, and pass that with each call to the service in the header instead of the user credentials object. Either could be sniffed and spoofed (and the ticket would still face the expiry problem) so I believe there is little advantage to doing so. The ticket doesn’t contain the password, so even if the user being spoofed changed their password the ticket would remain valid. But if someone managed to sniff the traffic and find the username and password combination then a spoofing attack would not be necessary – the hacker could just log into the application normally using that user’s credentials. Ultimately neither is perfect so the only viable solution in this case is to use SSL for all data communication between the server and the client.

With the release version of Silverlight we are now able to call our WCF service using a https (encrypted) connection, whilst our application is run from a http (non-encrypted) connection. To do this you will first need a valid SSL certificate installed on your server. Note that you cannot use a self signed certificate when calling a WCF service over a https connection from Silverlight – it must be a authentic certificate with trusted roots that you purchase from a certification vendor, otherwise you will receive a security exception when making a call to the service.

I’ve updated the code that determines the url of the WCF service in the framework so that it uses the security mode set in the ServiceReferences.ClientConfig file for the basic http binding. If you set this to ‘None’ then it will use the http scheme, if you set it to ‘Transport’ then you will be using the secure https scheme.

Note that if you decide to secure communication with the WCF service (in a cross scheme implementation) then you will need to place a client access policy file at the root of the domain to permit this cross scheme access (similar to if you were to call a service on a different domain). I have included a sample client access policy file in the AWWeb project in the sample application accompanying this article.

Ultimately I have to leave you to decide which method is the most suitable for you and the extent to which you believe security of the system is of importance. But for a real LOB application implementation I highly recommend secure communication with the WCF service.

Centralised WCF Service Instantiation

As we’ve seen, to support our more secure infrastructure we need to pass the client credentials in the message header with every WCF service call, in addition to specifying the url of the service. To do this for every call would mean a lot of additional and repeated code, so we need a single and centralised means of instantiating the web service and attaching/specifying these details. So essentially what we require is a factory for instantiating our WCF service. This poses a major issue however – as previously discussed I’ve chosen to go with the method of sending user credentials in the message header, and to do so we need to use an operation context with every service call. This is still a lot of extra repeated code – you can’t just set this when instantiating an instance of the service. Usually we’d just write a message inspector to attach these details, but IClientMessageInspector isn’t a part of Silverlight so that omission poses a problem. However we are lucky in that Microsoft has provided us with sample code which implements this functionality which we can add into our project. We can then implement our message inspector that adds the client credentials to the message header and pass this inspector to our service when instantiating it. Problem solved! We can now create our factory that allows us to easily instantiate an instance of our service by this code:

AWDataServiceClient service = AWServiceFactory.GetService();

I made one minor change to the sample code from Microsoft to allow the security binding to be passed in with the constructor of the inspector binding (to support communicating with the WCF service over https) as this couldn’t be set via a public property.

You may have noted that I am requesting data from the web service directly from the code behind the presentation layer, which in my mind isn’t ideal. I’ve been doing this up to this point just for simplicity’s sake, but if you need to make the same web service call from different parts of the application then you need to reproduce the call in each of those parts which tightly couples the presentation with calls to the server. For this instalment I will leave the project as it is, but looking to the future I will move this out into a service layer pattern architecture for a better structure.

Sharing Business Logic Between The Server And Client

On the server we have some classes (we’ll call them entities – though this term is not to be confused with the classes modelling our database tables in the Entity Framework) that we use to pass data between the service and the Silverlight client in. Any validation and other business logic (eg. maximum length of a string, etc) that you do on the client should also be done on the server – the server shouldn’t just trust that the data it receives is valid, it should check it itself. Since these rules would be the same between the client and the server it would be ideal to reuse this logic between both. Assuming you don’t have server specific logic in those classes it would be ideal to reuse these same classes in the Silverlight client project. We could split these entity classes out into their own DLL to reuse between both projects but unfortunately a DLL compiled to run on the full .NET Framework isn’t compatible to be used on the Silverlight platform. What we can do however is create two class library (DLL) projects – one compiled for the full .NET Framework and the other for Silverlight, and link the files from one to the other. We are therefore reusing the same source files between both platforms.

I have added two additional projects to the solution: AWBusinessObjects and AWBusinessObjectsSL (the former being for the full framework and the latter for Silverlight). The AWBusinessObjects project contains the files, and the AWBusinessObjectsSL project links to these files. To link the files you add an existing file to the project the normal way, but instead of pressing the Add button in the dialog click the dropdown arrow next to it and select ‘Add As Link’ instead. Any changes you make to a class in one project will be reflected in the other (considering they are the same file).

 

In my web application project I will add a reference to the AWBusinessObjects project, and in my Silverlight application I will add a reference to the AWBusinessObjectsSL project.

Usually adding a service reference creates a set of data contract classes matching those used by your service on the server. These contain just the public properties (or the properties marked with the DataMember attribute) and none of the logic or methods from the classes on the server. What we actually want is rather than having these generated classes populated with data from the server (or using them to send data back to the server) instead automatically populating the classes from our “shared entities” DLL saving us having to copy data from one structure to another. This can be achieved by selecting to reuse the types in the referenced assembly when adding the service reference. After selecting the service when adding a service reference, click the Advanced button. Select the “Reuse types in specified referenced assemblies” option and select the “shared” DLL (in this case it will be the AWBusinessObjectsSL DLL). Now the classes from our DLL will be used and we will get the benefit of our shared business logic.

Conclusion

We now have a firm and secure base for transferring data between the server and the client. Business logic can now be shared between the server and the client and these classes in Silverlight are populated automatically with the data from the server. Stay tuned for my next article which will cover building a form to add, edit, and delete products from the inventory.

Resources

Forms Authentication Cookie Behaviours:

http://www.codeproject.com/KB/aspnet/Forms_Auth_Internals.aspx

http://support.microsoft.com/kb/910443

http://www.eggheadcafe.com/tutorials/aspnet/198ce250-59da-4388-89e5-fce33d725aa7/aspnet-cookies-faq.aspx

http://www.hanselman.com/blog/WeirdTimeoutsWithCustomASPNETFormsAuthentication.aspx

http://www.asp.net/LEARN/security/tutorial-03-cs.aspx

Declarative Security:

http://www.code-magazine.com/article.aspx?quickid=0611051&page=4

Silverlight Web Services Examples:

http://code.msdn.microsoft.com/silverlightws/Release/ProjectReleases.aspx?ReleaseId=1660


Subscribe

Comments

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Balázs on Nov 10, 2008 10:22

    I'll will read through the article. Thank you. Are you planing Part 4 ? What will it be about ?

     

  • chrisanderson

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by chrisanderson on Nov 10, 2008 20:28

    Hi Balázs

    There are a number of articles planned for this series, and you can find a rough guide to the topics of each article here:

    http://www.silverlightshow.net/news/Welcome-Chris.aspx

    Hope this helps.

    Chris Anderson

  • Omnius

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Omnius on Nov 11, 2008 12:19

    Have you actually tried to enable SSL on the WCF service? I have been unable to get it to work. Once the WCF service is switched over to using a binding with "<security mode="Transport" />" the service starts throwing "Request for principal permission failed." exceptions on any methods flagged with the PrinciplePermissionAttribute.  For example, in this configuration the call to Login works but once I click on Inventory the call to GetProductList fails.  Hopefully I'm just missing something obvious, but so far I have been unable to figure it out.

  • chrisanderson

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by chrisanderson on Nov 12, 2008 06:41

    Hi Omnius

    Unfortunately I wasn't able to fully test the web service over SSL as I don't have a certificate and as described in the article you can't use self-signed certificates.  I was aware of this problem however but forgot to add the node to the web.config file that should fix the problem.  The problem is described here with a solution:

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=369445

    In summary you need to add the following as a behaviour of the service in the web.config file:

    <serviceAuthorization principalPermissionMode="None" />

    Please let me know if this solves the problem and I'll ensure the sample project is updated accordingly.  Thanks for the report.

    Chris Anderson

  • Omnius

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Omnius on Nov 12, 2008 07:15

    Yep, that fixes it!

    I knew it had to be something simple, but unfortunately I did not stumble upon that myself yesterday when I spent several hours randomly trying different configuration options. :) I had however figured out that Thread.CurrentPrinciple was being wiped out and had actually implemented my own version version of PrinciplePermissionAttribute and used Spring.Net AOP advice to intercept and used HttpContext.Current.User instead.  Oh well, I'll back that back out and switch back to the built in version.

  • chrisanderson

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by chrisanderson on Nov 13, 2008 05:34

    Thanks for letting me know Omnius.  I'll update the sample application to include the line in the web.config file.

    Chris

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Marc Gervais on Nov 17, 2008 15:38

    Chris,

    Is there any reason why the Live Demo is not working? I click the link, but all I get is an error from IE claiming it cannot display the webpage.

    I have downloaded the source and have tried running it locally (after installing the AW database, installing the Membership tables, altering the connection strings and creating a login). However, I am not able to get into the Inventory Page without getting an error. I am obviously missing something, but I am not sure what it is. The error is:

    "Cannot open database \"AdventureWorks\" requested by the login. The login failed.\r\nLogin failed for user 'machineName\\MarcG'."

    This exception is thrown in the AWDataService.GetProductList method (Line 108).

    Thanks.

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Marc Gervais on Nov 17, 2008 15:40

    Chris,

    Is there any reason why the Live Demo is not working? I click the link, but all I get is an error from IE claiming it cannot display the webpage.

    I have downloaded the source and have tried running it locally (after installing the AW database, installing the Membership tables, altering the connection strings and creating a login). However, I am not able to get into the Inventory Page without getting an error. I am obviously missing something, but I am not sure what it is. The error is:

    "Cannot open database \"AdventureWorks\" requested by the login. The login failed.\r\nLogin failed for user 'machineName\\MarcG'."

    This exception is thrown in the AWDataService.GetProductList method (Line 108).

    Thanks.

  • iiordanov

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by iiordanov on Nov 17, 2008 16:17

    Hi Marc,

    The live demo should be working now.
    Sorry for the inconvenience but we had some troubles with changing the hosting.

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Marc Gervais on Nov 17, 2008 21:41

    Thanks, Chris. It does work now.

    I also figured out my issue with the source...I neglected to change one of the connection strings (AdventureWorksEntities).

    Thanks.

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by IrishChieftain on Nov 19, 2008 19:54

    Why does it look like something that crawled out of FrontPage? The design is about as bad as it gets....

  • chrisanderson

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by chrisanderson on Nov 19, 2008 23:04

    IrishChieftain: that's on purpose - most developers aren't designers and the design is pretty average of what a developer may produce.  If you look at the upcoming article list you will notice that there will be an entire article devoted to styling the application as per a graphics designer may do once introduced to the project, and references to the look in past articles and why I haven't focused on this yet.  I am focusing on implementing functionality first as would a new Silverlight developer when undertaking this project on a step by step basis to produce a proof of concept .  If you spend too much time initially focused on developing an attractive UI then you will have wasted work when you need to make changes, and you won't get any closer to having a functional application.  I believe very strongly in the importance of attractive applications, from a sales perspective and also from encouraging users to accept the new application in their work environment.  But there is no use in an application that looks good but does absolutely nothing, and making it attractive can consume considerable development time.  As a proof of concept (as most companies will be at currently when determining whether Silverlight is a suitable technology for their applications) the first thing is to determine whether the required functionality can be implemented in the technology - which is the focus of these first few articles.  In the meantime if you believe you can come up with a simple more attractive UI or a better order for these articles you are more than welcome to contact me via my blog until I get to the styling article.

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Rob Galante on Nov 26, 2008 07:45

    I really liked these articles. I should be able to use them in my work. Could you provide a link to the sources for the Microsoft.Silverlight.Samples.SilverlightMessageInspector. Thanks.

  • chrisanderson

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by chrisanderson on Nov 27, 2008 01:56

    Hi Rob

    Sorry, I omitted the link to the message inspectors source.  This is the link:

    http://code.msdn.microsoft.com/silverlightws/Release/ProjectReleases.aspx?ReleaseId=1660

    Hope this helps.

    Chris

  • chrisanderson

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by chrisanderson on Nov 27, 2008 02:04

    Actually I did include the link, it was under the Silverlight Web Services Examples link in the resources.

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Trifee on Dec 11, 2008 15:49

    Very nice series of articles on silverlight + wcf + ef

    Do you have a pop-up and drag and drop window module that we can easily integrate with your framework?

    Also, I downloaded your source code and run it from Visual Studio.  However, it is not as complete as the one found in the 'live demo' link.

    Where can we download your most updated source code for your framework?

    Lastly, not sure if you already have ADD, EDIT, and DELETE routines in your framework that can be used.

    Thank you so much and more power to you!

    trifee

  • iiordanov

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by iiordanov on Dec 12, 2008 02:35

    Hi trifee,

    All articles of that series point to the latest 'live demo', thus we do not have to have different data bases for each part. If you want to download the latest version of the source code navigate to part 5, which is the latest part of the series so far, and download the source.

    ilia

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Trifee on Dec 15, 2008 09:26

    Hello again!

    I saw Part 4 and Part 5 of this series and even got more excited with this Framework!

    I would like to know if you have any code sample of popup and ... also draggable windows that we can easily integrate with this Silverlight framework.

    Thank you!

    trifee

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Jonathan Pugh on Dec 16, 2008 15:39

    Dude, you rock.  I have been wanting to figure out how to attach business logic to my WCF objects in Silverlight for over 6 months.

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Mark on Jan 15, 2009 04:16

    Great article. Do you know how to make the the SIlverLightMessageInspector work with an HTTPS binding?

  • chrisanderson

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by chrisanderson on Jan 15, 2009 05:45

    Hi Mark

    I'm not aware of any issues with the message inspector and https.  Do you have any more details you can fill me in with please?

    Chris

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by Joe Cracker on Jan 20, 2009 15:32

    Alas - it would be nice if we has wsHTTPBinding support in SL's WCF stack.

  • bhaidar

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by bhaidar on May 12, 2009 05:06
    Hello,

    I have a question related to "AWServiceFactory" Why didn't you have this class as a Singleton object? Wouldn't that be better so that not every time a new instance of the Service is being created?

  • chrisanderson

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by chrisanderson on May 13, 2009 12:00
    Hi bhaidar, it's true you could probably make it a singleton object.  I tend to close connections at the end of each request (or batch of requests) to reduce the load on the server (minimising the number of concurrent open connections the server needs to maintain).  If this isn't an issue then you probably could just make it a singleton object.  The advantages you'd gain by making it a singleton object and maintaining an open connection is each server request would be a bit faster, and you wouldn't have to create an instance of the web service with each request (or request batch).  Of course you'd need to keep track of whether that connection was terminated and reopen it if necessary.  It's a good point, I guess it depends on your scenario.  Any further comments on this point are welcome.

    Chris


  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by davedrat on Nov 01, 2009 18:12

    Excellent.. thanks for this article.

    The method of re-using business logic between two projects via links is great...

  • -_-

    RE: Building a Silverlight Line-Of-Business Application – Part 3


    posted by lpj on Mar 15, 2010 23:13

    Hey Chris,

       I have a WCF service working in Silverlight 3 and would now like to pass the username and password via the Soap header just as in your example above but I'm struggling with how to define the UserCredential class ... I keep getting object is not serializable...

  • gsandher

    Re: Building a Silverlight Line-Of-Business Application – Part 3


    posted by gsandher on Jun 15, 2011 22:01

    Hi Chris,

    I am using silverlight 4.0.  I created two library for my business objects. Aftrer I refer BusineessObjectsSL in my silverlight application and adding service reference, I start getting the following error. What is the solution to this?

     

    No error if i remove the reference of  BusineessObjectsSL in my silverlight application. But I need it to share the business objects with silverlight client.

    "Error 3 The Complex Type 'PestMonitorBusinessObjects.PropertyInfo.Property' already exists in another assembly. Complex Types cannot be defined in multiple assemblies. PestMonitor"

     

     

Add Comment

Login to comment:
  *      *       

From this series