Pablo M. Cibraro (aka Cibrax)

One of the features that you get out of the box with SO-Aware is the ability of monitoring your services. You can either monitoring the traffic for your REST or SOAP services, and see the details of all the incoming or outgoing messages, or any fault that got generated during the execution. In addition, that data is used to compute some metrics and provide several reports about the service usage.

As I discussed in my last post, the new WCF Http Model includes http processors that you can use to inject cross cutting aspects into an existing service. We can use processors for supporting a versioning schema based on content types as it discussed here by Peter Williams. 

The code drop recently released as part of wcf.codeplex.com introduced a new feature for injecting cross-cutting concerns through a pipeline into any existing service. The idea is simple, when you move to the http world, there are some aspects that might want to move out of your operation implementation. A typical example is content negotiation, in which the http messages are serialized or deserialized into specific entity or object graph expected by the service based on the “content-type” or “accept” http headers.  You don’t want to have all that logic spread across all the service implementations or tie your operation to an specific format as it happened with previous model with the WebInvoke and WebGet attributes. For that kind of logic, it’s really useful to have that concern implemented in a specific class that you can test individually and inject into your service to support new message formats.

As part of the simplification in service configuration that we want to provide in SO-Aware, we have added two new commands in the PowerShell provider for generating the service configuration at design time in case you don’t want to rely on SO-Aware for resolving all that at runtime.

One of the things that caught my attention when WCF Data Service was released a couple of years ago was the ability of using URI segments for passing queries directly to an underline linq provider. This represented a very powerful feature for allowing clients to filter and manipulate a large data result set on the server side with a simple API and without incurring in any unnecessary performance penalty (the queries are performed and resolved in the data source itself most of the times) and having all that logic implemented in the service itself.

One of the common problems that you might find when using the generated DataServiceContext for consuming an existing WCF data service is that you have magic strings everywhere for handling links (expanding, adding, deleting, etc). The problem with all those magic strings is that they make your code to compile correctly, but you might run into some error at runtime because you used a link that does not exist or it was just renamed.

A UI driven service is usually a service implementation that only makes sense in the context of the UI for solving an specific use case, and not something that you might want to share or expose to third parties. Typical examples of UI driven services are AJAX endpoints, which you build for supporting partial updates in a page. The implementation of this kind of services can take the form of a simple http endpoints, which could adhere to the REST principles or not, or SOAP web services.   

I am happy to announce today the support in Visual Studio 2008 for adding new service references from the SO-Aware service repository. We have created a simple plugin that you can register in Visual Studio to support this new functionality.