The first thing that I looked at was the method signature of the webservice. The documentation indicates that you need to use one of the following method signatures :

..OR..

What the documentation doesn’t tell you is that the name/spelling/capitalization of the method signature must match EXACTLY. If you decide that you don’t like the camelcase on the prefixText and want to use prefixtext instead….IT WON’T WORK. So make sure you have those signature matching correctly. I have seen some indications on the internet that you should use a static method such as :

DON’T DO THIS. It doesn’t work. Only the exact methods defined in the documentation and shown above will work.

Back to my project, I get these methods defined properly, compile the project, go to my textbox start to type and still I get NOTHING. So I look over the documentation and see some information about the class/method attributes that must be added. The documentation shows the following :

What they don’t show in the documentation is that you need to also add the following to the class definition

So I make these changes and run the application again, and STILL it doesn’t work. I’m stumped. I put a break at the webservice method and run again and it’s not even hitting the webservice. After a little bit of digging I come across Adding ASP.NET AJAX Configuration Elements to an Existing Web Site and a lightbulb goes on. This project was not setup as an AJAX.NET site, in fact it predates ASP.NET AJAX by a couple of years. Sure enough as I start to dig through the documentation I notice mappings to handlers for the webservice calls. So I follow the changes specified and run the site and it worked!

It took me a while to get this figured out, and I suspect there might be a few others out there that might have some problems getting this working. Below is a complete class that you can use as a reference. I haven’t included any of the code defining the AutoCompleteExtender because the documentation seems sufficient and I didn’t have any problems. There is also a video on the ASP.NET AJAX site that walks you through configuring your first AutoCompleteExtender and does a good job, as long as your site is configured properly!

Good luck!

The big problem we were both having was that while the apps were decent enough for their initial use we were being asked to extend them and both of us wanted to do some refactoring of the application before we released them into the wild. The best approach for this sort of thing is to develop unit tests so that, once refactored, we could be sure that we hadn’t broken anything important.

The biggest problem with dropping unit testing into an application after the fact is that sometimes you run into problems where you have to refactor just to get the unit tests access to all of the routines that you want to test. This isn’t an ideal situation, as you quickly end up wondering if you are breaking things just trying to get some unit tests built that are supposed to ensure you aren’t breaking anything. So you start wondering if instead of refactoring if you simply make functions that wrap your private functions and expose the behaviour might be the answer, pretty soon you have stuff everywhere and you wonder which is your testing code and which is your unit testing code to make all of this possible. Madness.

As we dropped off of the fire trail back into a heavily wooded area with a nice creek, it came up in conversation that perhaps partial classes were the way to go. If you haven’t used c# partial classes, you will. You can write class code in multiple files and yet at compile time it is assembled into a single logical unit. Several days later I had some free time and was able to verify that this would indeed work, I could drop all of my unit testing code into a single file that would provide all of the unit testing logic and wouldn’t muddy up the existing class. Furthermore, with a couple conditional complilation statements I could get rid of all of the unit testing code from the final release of the new library.

This is obviously not the approach you want to take if you can avoid it. It is arguable that you do not want your classes invaded in such a way for the purposes of unit testing. This is something you can work around if you use unit testing from the beginning, but what if you inherit a project and it doesn’t have any unit test capabilities built into it? What if the way that the classes are structured make unit testing pieces of the application difficult? Do you just plow forward and hope for the best? I hope not, and hopefully this stop gap measure to get unit tests built into the classes so that you can test existing functionality is the way to go. With these “nunit partials” in place you should be able to then start refactoring the rest of the application to be a little bit better structured for unit tests without having to risk dropping anything.

HttpWebResponse resp = (HttpWebResponse)req.GetResponse();
Stream reader = resp.GetResponseStream();
// you might want to set your responses content type here
System.IO.Stream r = Response.OutputStream;

int Length = 256;
Byte [] buffer = new Byte[Length];

int bytesRead = reader.Read(buffer, 0, Length);
while(bytesRead > 0){
r.Write(buffer, 0, bytesRead);
bytesRead = reader.Read(buffer, 0, Length);
}

Let’s take a look at input validation to see what we mean about relying too heavily on exceptions. Validation is a bear, you want to try and have your validation rules in one spot only. This way you can avoid the chore of duplicating validation logic on the client and the server. This seems to be one of the main reasons people are looking at bubbling exceptions over the wire because if they can simply put the validation logic in the server side, then they can throw an exception back to the client and deal with it there. It solves the the problem of duplication of validation logic and allows developers to deal with validation errors in the same way that they do within desktop application environments.

The question now becomes can we avoid exceptions and still provide for a rich validation environment? I believe that we can and I’m going to spend the rest of this article describing an approach. It may not be the best approach, it may not be the only approach, but it was worked well for me on the last few projects and enough people I’ve talked to about the approach seem to feel that it’s powerful enough to consider for their future efforts along these lines.

In order to provide a framework upon which to hang our theory let’s consider a simplified method of a web service named “CreateAccount” that takes as it’s only parameter an Account object.

When we want to create a new account we will fill out the information about the account as described and then pass it to the CreateAccount method of the webservice. However, instead of just having a void for the return value and throw exceptions if there are errors you simply use a response object such that the method signature would look something like the following :

CreateAccountResponse  CreateAccount( Account acct)

This is certainly not a new concept. Response objects litter many namespaces, but in this particular situation they allow us to avoid having a lot of exceptions flying out of our webservice and doing all sorts of ridiculous plumbing hacks to get it all to operate nicely.  Now let’s take a quick look at the CreateAccountResponse class and see what it looks like, then we can talk about how a response object allows us to avoid duplicate validation and exceptions. Below is the UML for the CreateAcountResponse object

We see that this class mmics the Account class pretty closely with the addition of a couple of routines that would be needed to actually communicate results. The Success flag would indicate whether the account creation was successful and the error message would only be filled out if there was a particular error that you wanted to communicate to the user such as “You do not have the rights to create accounts” or something along those lines. The other fields would be filled out if there were problems with the validation of the individual fields of the account object. This would allow us to have all of the validation/error messages specified on the server side in a single location and still be able to get the information out to your users. Such that if you require the state field to be only 2 characters long and someone puts in 4 you could set the success flag to false and then add error text to the State field of the response object that could then be displayed to the end user.

WIth this approach if there was an exception generated in the webservice, we could trap it server side and provide the appropriate message to the CreateAccountResponse object and not have to require the client to exception handling just to know what is happening.

Now one of the complaints  that I have heard about this approach is “but now you have to create all of these response objects”. Well yeah, but one way or another you’re going to have to write some code to deal with errors and wouldn’t it be nice if you could deal with the errors and the error messages in a single place? Also you could simply create a generic results object that would suffice for most of the calls that you want to make. Then again consider that in some of the more mature environments such as .NET WebServices  you can easily create webservices that provide this sort of functionality and the WSDL’s and whatnot are all created for you.So it’s not nearly as much work to do this as it could be.

What about the overhead of all of these custom classes? Is it really any more overhead than the throwing of exceptions? Exception throwing, and handling are expensive operations. I find it a little be cleaner to my thinking because now you have a clear and concise definition of what you need to program against when you are dealing with your WebService’s API.

I’m not saying this is necessarily the best approach for all occassions, and I’m not really down on exceptions in general, or even for web services. However I think that there are many times when the extra effort you have to go through just to get robust exception handling done will lead you into a lot of needless efforts. Especially if you are just trying to provide validation/failure information back to the client applications.Keep in mind that what I’ve presented here isn’t a blueprint, it’s more like a pattern of how you might consider structuring your webservices in certain situations.

Your mileage may vary.

]]> http://www.joelhainley.com/index.php/2009/02/07/alternatives-to-throwing-exceptions-to-flexsilverlight-clients-from-a-net-web-service-part-2/feed/ 0 http://www.joelhainley.com/index.php/2009/02/04/silverlight-communication-exception-was-unhandled-by-user-code/ http://www.joelhainley.com/index.php/2009/02/04/silverlight-communication-exception-was-unhandled-by-user-code/#comments Wed, 04 Feb 2009 18:13:20 +0000 joelhainley http://www.joelhainley.com/?p=124 Ran into the following error the other day :

An error occurred while trying to make a request to URI ‘http://localhost/T2WS/AdminServices.asmx’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. Please see the inner exception for more details.

The error message was self-explanatory but it didnt’ solve the problem. I had my cross domain file setup appropriately and yet I was still receiving the error. As seen below the stack trace didn’t offer much help either:

System.ServiceModel.CommunicationException was unhandled by user code
Message=”An error occurred while trying to make a request to URI ‘http://localhost/T2WS/AdminServices.asmx’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. Please see the inner exception for more details.”
StackTrace:
at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.ClientBase`1.ChannelBase`1.EndInvoke(String methodName, Object[] args, IAsyncResult result)
at T2SL.T2AdminService.AdminServicesSoapClient.AdminServicesSoapClientChannel.EndgetAccountList(IAsyncResult result)
at T2SL.T2AdminService.AdminServicesSoapClient.T2SL.T2AdminService.AdminServicesSoap.EndgetAccountList(IAsyncResult result)
at T2SL.T2AdminService.AdminServicesSoapClient.EndgetAccountList(IAsyncResult result)
at T2SL.T2AdminService.AdminServicesSoapClient.OnEndgetAccountList(IAsyncResult result)
at System.ServiceModel.ClientBase`1.OnAsyncCallCompleted(IAsyncResult result)
InnerException: System.Security.SecurityException
Message=”"
StackTrace:
at System.Net.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)
at System.Net.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelAsyncRequest.CompleteGetResponse(IAsyncResult result)
InnerException: System.Security.SecurityException
Message=”Security error.”
StackTrace:
at System.Net.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
at System.Net.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)
at System.Net.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)
InnerException:

Still no luck, i spent some time fiddling with the clientaccesspolicy.xml file but it didn’t seem to be the problem. After a bit of digging and avoiding the obvious, it finally hit me right between the eyes. I had setup the Silverlight project to be the startup and it was running the file locally, instead of running it through the web project I had setup to wrap Silverlight with.

Once I changed the startup project to the Web project and the file to the Silverlight testpage everything worked just fine and dandy except that the Silverlight project wasn’t updating. Looking through the Silverlight project properties I was able to point the build for the Silverlight “executable” to the Web project’s ClientBin directory and everything fell into place.

I just mention this hear because I’m sure I’ll forget how I solved this problem the next time I run into it.

Recently I was at a .NET users group meeting and heard some people talking about throwing exceptions to Silverlight clients in much the same way that I had been looking at doing for my Flex clients. The problems that they encountered and the solutions that they came up with were essentially the same. “IIS does dumb stuff with the response codes when there’s an exception in a webservice”. (There’s a pretty simple work around for this one ) “You can trap the exception and then make the exception object a property of the service response object”, “There’s a third party product X, that wil…blah blah blah”. It was nice to see that noone had come up with an elegant solution to this “problem” of throwing exceptions over the wire.

I started to wonder if it really was a “problem”. I took a step back and did some critical thinking about such an approach. I had a lot of questions about what I, and the rest of the people out there are trying to accomplish by throwing exceptions “over the wire”.

• What benefits do you get from handling server exceptions in the UI?
• Is it really correct to handle exceptions in the UI for problems that occurred in the web service?
• What are the valid uses for exceptions?
• What is the definition of an exception?
• What are people trying to do with these exceptions?/ What problems are they trying to solve by the use of exceptions?

In an effort to clear up my thinking on such things I’m going to go through some of the above questions below.

What is the definition of an exception?

The tongue in cheek response to this question is “it’s when something exceptional happens”. The longer explanation is that when your code encounters something that that is outside the scope of what it was intended to handle. I think there’s a clue in there that addresses the problem I’m trying to deal with, but we’ll have to get back to it after we talk about a few more of the questions.

What are the valid uses for exceptions?

Answering this question is difficult without having a problem domain to work with. The answer can vary depending upon the environment that your code is expected to run in, how reliable various parts of the environment are, how critical certain operations within your application are, etc..etc.. What I would like to say about this is that like we said above your exceptions should handle exceptional situations.

I also think that there is often too little thought put into the implementation of exceptions within an application. There’s a pretty good argument floating around that your exception model should be diagrammed and managed in the same way that your business objects are. I might talk about this at a later date, but for now give it some thought.

Is it really correct to handle exceptions in the UI for problems that occurred in the web service?

In a windows application that is self contained, handling exceptions in the form code  seems to be something that a lot of people are comfortable with (  judging by the codebases I’ve had to maintain ). In fact most books that I run across that show beginning development have the exception handling directly in the form itself. This is arguably correct, if not desirable, for quick and dirty applications, because you’re really just trying to get something done. Besides you don’t want to throw the actual exception out to the user to look at so you catch the exception and give the user a nice “Something really bad happened, try again” message and exit the application.

Now in a situation where you have a client application talking to a server application. You have a different scenario. The server is providing services to the client, if something bad happens in the server it should handle the problem in some way, (i.e. capturing the exception ) and then notify the client that there has been an error.

In the same way that you would never want to throw raw exceptions from your self contained application out to your users. You really don’t want to throw raw exceptions to the clients that use your server API. If there was a problem with your server code handle it gracefully in your server code and provide your clients with a decent error message.

There should be a separation between your server code and your client code, when you start to throw exceptions from your server out to your clients  you begin to tie them together in ways that are not extensible. Consider if you start using a new library in your server code that throws a different type of exception that you felt should be bubbled out to your client. This means that all of your clients will need to be updated to handle the new exception instead of handling a “call failed” response sort of message. Encapsulation is a metaphor for good design at all magnification levels of developement not just at the object/class level.

There is more I could say here but I’m going to move on for now. I might come back and talk some more about this in another posting.

What are people trying to do with these exceptions?/ What problems are they trying to solve by the use of exceptions?

From what I’ve observed most people are trying to ease their burden on the server side by throwing exceptions out to the clients when there are problems. The most common example of this is input validation, or even a little deeper would be business object validation (i.e. Does this user have the right to add another user to this account ) Call me crazy but I don’t see how you can call a user entering incorrect values to be an exceptional situation. At least with my users it never is. If there is a wrong value that can be typed, they are going to type it. I don’t start throwing exceptions and stepping out of the program flow to deal with these errors because they are not exceptional circumstances.  I have a really hard time believing that validation of input is a good place to start throwing exceptions. Yes, the system should reject bad input, or illegal operations but do you really need to start throwing exceptions over the wire to deal with this? Is it necessary to tightly couple your UI code base to your server codebase just to get the proejct done and avoid duplication of validation efforts?

I really don’t think so.

In the next part of this article I am going to provide some diagrams, patterns and maybe even a little sample code to show how you might avoid “exceptions over the wire”

I started started out working with NHibernate because I was familiar with Hibernate in the java world. Well actually, I was familiar with the Repository from ATG which is pretty similar to Hibernate. (My general impression is that ATG’s Repository is a bit more polished than Hibernate) NHibernate worked out great and very quickly I was able to get the database access up and running and had a working prototype. Once this was done, I did some more digging to see what other ORM implementations were available for .NET.  There are quite a few projects out there but I came across LINQ, and specifically LINQ for Entities.

LINQ could probably best be described as a generalized approach at data access from various datasources that is intended to replace all of the customized query languages/approaches ( SQL, XPath, iteration through various collection classes, etc ) with a single language. Ostensibly this will reduce the amount of stuff a developer needs to know to be effective. According to the available documentation LINQ for Entities is the most customizable implementation of ORM functionality available in LINQ. There are some other ways to do similar things with a little less control using LINQ to SQL but I decided to just dig deep as the sort of control I was used to with Hibernate was most similar to LINQ for Entities.

I had to upgrade Visual Studio 2008 to sp1 to use LINQ for Entities, but this was trivial and I soon had things up and running. In short order I had everything working with LINQ and the application was moving forward again. At this point I’m mostly impressed with LINQ and I think I’ll end up using it for this project. There are a bunch of tools available in the IDE to support the mapping operations, and it will autogenerate initial classes by simply pointing the IDE at the database you are using.

I’m not sure if LINQ is the be all end all that microsoft is hoping it will be. I’m not convinced that a generalized query language is needed. It has been said, by several philosophers and more than a couple of programmers, that the language that you have available to express yourself has an impact on your thinking. In this case specialized languages such as XPath and SQL give your mind a set number of ways to express yourself that are consistent with the underlying implementation. Yet a generalized approach abstracts that away and removes you another step farther away from the realities of the toolset you are using. Is this a good thing? Time will tell and at the very least it will be interesting to see how far people can take this approach to querying various datasets. 

The thing I am convinced about is that ORM technology is making it much easier on developers to quickly and easily get database code up and running. The increases in productivity are real. It is nice to interact with the data as objects instead of as sql queries, stored procedures, etc. Somehow I suspect that the Smalltalk crowd is sitting in the wings chuckling at all of the other technology platforms touting their ORM solutions.

namespace HelloWebService
{
[WebService(Namespace = "http://www.examplenamespace.com/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ToolboxItem(false)]

public class Service1 : System.Web.Services.WebService
{

// implementation …

}

This value is required by .NET for a web service, or at the very least .NET gets VERY upset if this value is not set.

You will then need to let Flex know about this namespace in order to access the results. To do this you simply add the following lines to Flex:

private namespace lh = “http://www.examplenamespace.com/”;
use namespace lh;

Not much to it, but it can be a bit of a pain when you’re not aware of this. Flex doesn’t complain, it just gives you empty values when you try to access the values.