WCF Extensibility – Configuring the Endpoint for WCF RIA Services

Article
01/18/2012

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page .

And we’re again taking a small detour over the normal flow of the series covering the “proper” WCF extensibility points. This time, we’ll talk about how you can use (almost) all the extensibility points seen before to configure the endpoint used by a WCF RIA Service. WCF RIA Services is a framework which allows easy creation of n-tiered rich internet applications using Silverlight, by coordinating the application logic between the middle tier and the presentation tier. As the name suggests, WCF RIA Services use WCF as the communication framework underneath, by exposing endpoints which are consumed by a “transparent” proxy on the Silverlight application – unlike on “normal” WCF scenarios, if you create an application using the WCF RIA Services, there’s no need to explicitly create a proxy to the service to access it in a typed way – anytime a change is made in a domain service class in the service, that change is automatically propagated to the client so it can be used right away. Domain service is the term used to describe services a service written using the WCF RIA Services framework.

Since WCF RIA Services use WCF, it’s possible to use all of the applicable extensibility points in the server to configure the endpoint which is used by the framework. This post is about how to get to the endpoint from the WCF RIA Services framework, so that you can use all the extensions which have already been covered in this series. Notice that this is quite an advanced scenario, requiring not only that you use WCF RIA Services in the first place, but also that the existing endpoint types not being enough (which is not common), but since I’ve answered a similar question in the Silverlight forum for WCF, I decided to include it here in case other people run into this same scenario.

The “entry point” to the WCF world in the WCF RIA Service is the DomainServiceEndpointFactory class. The goal of the class is to, given a description for the domain service, return one (or more) WCF endpoints which will be used by the client to communicate with that tier. We’ll cover it as we did other “normal” extensibility points of WCF.

Public implementations in the WCF RIA Services

There are a few public domain service endpoint factories, both in the “main” framework and in the "WCF RIA Services Toolkit”, an “out-of-band” release of improvements for the framework.

PoxBinaryEndpointFactory: uses a non-SOAP endpoint where the XML data is encoded in the .NET Binary Format.
ODataEndpointFactory: uses an endpoint which exposes data using the Open Data Protocol.
JsonEndpointFactory (toolkit): uses an endpoint which accepts and returns data encoded in JSON, useful for JavaScript / Ajax applications.
SoapXmlEndpointFactory (toolkit): uses a SOAP endpoint which can be consumed by clients which understand that format.
TracingDomainServiceEndpointFactory (toolkit): exposes an endpoint which can be used to look at tracing information from the service. This is the endpoint I mentioned in the post about WCF extensibility and System.Diagnostics tracing.

The first factory is the default one used by the framework. The second one can be enabled in the Silverlight Business Application VS template, while the ones from the toolkit need to be enabled manually by editing the web.config on the web application.

Class Definition

public abstract class DomainServiceEndpointFactory
{
public abstract IEnumerable<ServiceEndpoint> CreateEndpoints(
DomainServiceDescription description, DomainServiceHost serviceHost);
}

The DomainServiceEndpointFactory class has essentially one method which needs to be overriden: CreateEndpoints. Given the description of the domain service, and the instance of the service host (which is an instance of the DomainServiceHost class, itself a subclass of the WCF ServiceHost class). Usually only one endpoint is returned by each factory, but it’s possible to have one factory return multiple endpoints.

How to use a custom domain service endpoint factory

Custom domain service endpoint factories are added by adding a reference under the <system.serviceModel> / <domainServices> / <endpoint> element of the configuration file. The “pox binary” endpoint is added by default, any other endpoints need to be added based on the assembly-qualified name class which inherits from DomainServiceEndpointFactory.

<system.serviceModel>
<domainServices>
<endpoints>
<add name="OData" type="System.ServiceModel.DomainServices.Hosting.ODataEndpointFactory, System.ServiceModel.DomainServices.Hosting.OData, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="JSON" type="Microsoft.ServiceModel.DomainServices.Hosting.JsonEndpointFactory, Microsoft.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="MyCustom" type="SLApp.Web.MyCustomFactory, SLApp.Web" />
</endpoints>
</domainServices>
</system.serviceModel>

Real world scenario: supporting HTML forms data in WCF RIA Services

This one came from the Silverlight forums for WCF (Accessing Web Services with Silverlight). A user had a simple service which was consumed not only by the Silverlight client, but also by a third-party application which used the application/x-www-form-urlencoded content-type. I don’t know whether the 3rd party was able to change the content type or not, but the user wanted to know whether it was possible to be supported on a domain service. Well, domain services are built on top of WCF, and this scenario is listed on this post, so of course this can be done Smile .

First of all, this is really not a common scenario. In most cases, clients can use the JSON endpoint to communicate to domain service. You can call all CRUD operations, and also [Invoke] operations using that endpoint which works quite well from JavaScript. You can find a good overview of the JSON endpoint for WCF RIA Services in Joseph Connoly’s blog (part 1, part 2). But in this case apparently the client couldn’t be changed, so we can create our own endpoint factory which supports that media type as well.

First, as usual, a scenario. You can start by creating a new “Silverlight Business Application” on Visual Studio (or Visual Web Developer Express), which will give a basic template for such an application, with a login feature. For this sample we’ll ignore the authentication part, as it’s not relevant to this post. Let’s then create a contact list, which will be exposed in a domain service. I’ll create a “POCO” domain service instead of the usual, database-backed, one, to make this sample simpler to run, but the idea works for all domain services.

public class Contact
{
[Key]
public int Id { get; set; }
[Required]
public string Name { get; set; }
public int Age { get; set; }
public string Telephone { get; set; }
}

And we can now create a domain service to expose it to the client. The contact repository, used below, is a simple in-memory representation of the contacts. And that’s a good point to insert the usual disclaimer: this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few operations and it worked, but I cannot guarantee that it will work for all scenarios – please let me know if you find a bug. The “repository” is an in-memory list of the objects which is definitely not what a real scenario would use. Also, as usual, I’ve kept the error checking to a minimum, which needs to happen in a real application.

[EnableClientAccess()]
public class ContactsDomainService : DomainService
{
[Query]
public IQueryable<Contact> GetAllContacts()
{
return ContactRepository.Get();
}
[Insert]
public void CreateContact(Contact contact)
{
ContactRepository.Add(contact);
}
[Update]
public void UpdateContact(Contact contact)
{
ContactRepository.Update(contact);
}
[Delete]
public void RemoveContact(Contact contact)
{
ContactRepository.Delete(contact);
}
}

We can also add “invoke” operations to domain services, which may or may not have any side effects in the domain context. We’ll add one of those operations, which we’ll use to invoke with both the “normal” JSON input, and with the modified forms-urlencoded data. The [CanReceiveFormsUrlEncodedInput] is a tagging attribute which we defined to let the inspector to know that it should try to handle this case.

[Invoke(HasSideEffects = true)]
[CanReceiveFormsUrlEncodedInput]
public Contact ImportContact(Contact contact)
{
ContactRepository.Add(contact);
return contact;
}

Now for the actual code which does the trick. There are quite a few ways we can go about it. We can build a custom message formatter which understands the form-urlencoded data and converts it to the appropriate parameters in the operation. That could work, but I don’t know if the formatter used by the domain service does anything else – it’s possible that it does. What I ended up doing instead was to use a message inspector to do a translation between the forms-urlencoded format and the JSON which should be sent to the JSON endpoint in the first place.

So, let’s start with the endpoint factory. Since we’ll just do a translation, I’ll create a class which inherits from the JsonEndpointFactory class itself. Then, when it’s asked to create the endpoints, it first gets the endpoints from the base class, then inserts the “translator” before the other behaviors in the main endpoint. The behavior itself does nothing more than add an inspector, which will do the bulk of the work.

public class FormUrlEncodedEnabledJsonEndpointFactory : JsonEndpointFactory
{
public const string FormUrlEncodedInputProperty = "FormUrlEncodedInputProperty";
public override IEnumerable<ServiceEndpoint> CreateEndpoints(System.ServiceModel.DomainServices.Server.DomainServiceDescription description, System.ServiceModel.DomainServices.Hosting.DomainServiceHost serviceHost)
{
List<ServiceEndpoint> endpoints = new List<ServiceEndpoint>(base.CreateEndpoints(description, serviceHost));
ServiceEndpoint jsonEndpoint = endpoints[0];
jsonEndpoint.Behaviors.Insert(0, new FormUrlEncodedToJsonEndpointBehavior());
return endpoints.AsEnumerable();
}
}
class FormUrlEncodedToJsonEndpointBehavior : IEndpointBehavior
{
public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
{
}
public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
{
}
public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
{
endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new FormUrlEncodedToJsonInspector(endpoint));
}
public void Validate(ServiceEndpoint endpoint)
{
}
}

The inspector will look at the request headers of the message, trying to find any with the forms encoding. If the incoming message is such one, it will then look at the last part of the request URI (which represents the operation name), and then find that operation in the endpoint description. If that operation exists, and it’s marked with the attribute that allows such input to be sent, we start the conversion process.

The translation starts by getting the data in binary format (after all, no mapper is registered for the application/x-www-form-urlencoded content type, so it will be mapped to raw / binary), and using the ParseQueryString(String) method from the HttpUtility class to convert between the input and a collection of name/value pairs. Later, we start creating the equivalent JSON, and with that in hand, we create a new message, copying the headers and properties from the original one. One property which we need to change is the WebBodyFormatMessageProperty, to tell the WCF pipeline that it’s now dealing with JSON data.

class FormUrlEncodedToJsonInspector : IDispatchMessageInspector
{
ServiceEndpoint endpoint;
public FormUrlEncodedToJsonInspector(ServiceEndpoint endpoint)
{
this.endpoint = endpoint;
}
public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
HttpRequestMessageProperty reqProp = request.Properties[HttpRequestMessageProperty.Name] as HttpRequestMessageProperty;
if (reqProp.Headers[HttpRequestHeader.ContentType] == "application/x-www-form-urlencoded")
{
string operation = request.Headers.To.AbsolutePath;
int lastSlash = operation.LastIndexOf('/');
if (lastSlash >= 0)
{
operation = operation.Substring(lastSlash + 1);
}
OperationDescription operationDescription = this.endpoint.Contract.Operations.Find(operation);
if (operationDescription != null &&
operationDescription.Behaviors.Find<CanReceiveFormsUrlEncodedInputAttribute>() != null)
{
// Decode the forms-urlencoded input
XmlDictionaryReader bodyReader = request.GetReaderAtBodyContents();
byte[] input = bodyReader.ReadElementContentAsBase64();
string inputStr = Encoding.UTF8.GetString(input);
NameValueCollection parameters = HttpUtility.ParseQueryString(inputStr);
// Create an equivalent JSON
StringBuilder json = new StringBuilder();
json.Append('{');
this.ConvertNVCToJson(operationDescription, parameters, json);
json.Append('}');
// Recreate the message with the JSON input
byte[] jsonBytes = Encoding.UTF8.GetBytes(json.ToString());
XmlDictionaryReader jsonReader = JsonReaderWriterFactory.CreateJsonReader(jsonBytes, XmlDictionaryReaderQuotas.Max);
Message newMessage = Message.CreateMessage(request.Version, null, jsonReader);
newMessage.Headers.CopyHeadersFrom(request);
newMessage.Properties.CopyProperties(request.Properties);
// Notify the application this this change happened
OperationContext.Current.IncomingMessageProperties.Add(FormUrlEncodedEnabledJsonEndpointFactory.FormUrlEncodedInputProperty, true);
newMessage.Properties.Add(FormUrlEncodedEnabledJsonEndpointFactory.FormUrlEncodedInputProperty, true);
// Change the 'raw' input to 'json'
newMessage.Properties.Remove(WebBodyFormatMessageProperty.Name);
newMessage.Properties.Add(WebBodyFormatMessageProperty.Name, new WebBodyFormatMessageProperty(WebContentFormat.Json));
request = newMessage;
}
}
return null;
}
}

The conversion between the name/value collection and the JSON is fairly straightforward. For simple operations (i.e., those taking primitive parameter types, such as strings, bools and numbers) we can just create a JSON object mapping each name/value pair as a member of that object. We can even map those non-strings parameters as JSON strings, since the JSON deserializer used by WCF is smart enough to deserialize JSON strings representing numbers (or bools) into the appropriate type. However, I thought we could go further, that we could also support simple complex types as well, such as the Contact we showed before. For that, we need to map the name value pairs not as parameters themselves, but as members of the contact object. To implement that, I used a simple wrapping technique that if there is a single parameter in the operation, and the parameter name isn’t present in the name/value pairs, then we’ll wrap the values in another JSON object, and have that as a member whose name is the same as the operation parameter. In the Contact case, for example, it will map an input such as Name=John+Doe&Age=33&Telephone=415-555-1234 into the JSON {“contact”:{“Name”:”John Doe”,”Age”:”33”,”Telephone”:”415-555-1234”}}.

private void ConvertNVCToJson(OperationDescription operationDescription, NameValueCollection parameters, StringBuilder json)
{
bool wrapRequest = false;
string firstParameterName = null;
if (operationDescription.Messages[0].Body.Parts.Count == 1)
{
firstParameterName = operationDescription.Messages[0].Body.Parts[0].Name;
// special case for inputs of complex types
if (parameters[firstParameterName] == null)
{
wrapRequest = true;
}
}
if (wrapRequest)
{
json.Append("\"" + firstParameterName + "\":{");
}
bool first = true;
foreach (string key in parameters.Keys)
{
if (first)
{
first = false;
}
else
{
json.Append(",");
}
json.AppendFormat("\"{0}\":\"{1}\"", key, parameters[key]);
}
if (wrapRequest)
{
json.Append("}");
}
}

And that’s it. Now we need to create a HTML page to test that. Since I haven’t worked with the JSON endpoint too much, I first tried using a simple JSON request just to make sure that everything was ok, before going with the simple HTML form (which uses the form-urlencoded content type). The form has two buttons, one which uses a JavaScript code (JSON-ifying the input prior to sending to the service), and another which is “pure” HTML. The JSON one will format the entry appropriately, then after submitting the data, will redirect to the main Silverlight page, which will display the added contact. The HTML post button will just submit the data. But the HTML post expects to receive a HTML page back, so I edited the [Invoke] operation to redirect to the page at the server side (see code in the gallery).

<body>
<h1>Contact importer</h1>
<form action="SLApp-Web-ContactsDomainService.svc/JSON/ImportContact" method="post">
<p>Name: <input type="text" id="Name" name="Name" /></p>
<p>Age: <input type="text" id="Age" name="Age" /></p>
<p>Telephone: <input type="text" id="Telephone" name="Telephone" /></p>
<p><input type="button" value="Import Contact (using jQuery)" onclick="Call()" /></p>
<p><input type="submit" value="Import Contact (using plain HTML)" /></p>
</form>
<script type="text/javascript">
function Call() {
var data = {
Name: $("#Name").val(),
Age: parseInt($("#Age").val()),
Telephone: $("#Telephone").val()
};
var json = JSON.stringify({ contact: data });
$.ajax({
url: "SLApp-Web-ContactsDomainService.svc/JSON/ImportContact",
type: "POST",
contentType: "application/json",
data: json,
complete: function () {
window.location = "SLAppTestPage.html";
}
});
}
</script>
</body>

And that’s it. Granted, it’s not a very common scenario, but it just shows how to get into the world of WCF extensibility from within a WCF RIA Service.

[Code in this post]

[Back to the index]

Comments

Anonymous
July 18, 2014
I have a VS Silverlight project in WCF RIA Service and my answer is: Is it necessary to have a endpoint configured?Anyway, my project do not run in IIS, just in VS enviromment. Any help?Thanks in advance.Luis
Anonymous
July 18, 2014
In the vast majority of the cases you don't need to configure the endpoint. It's often configured just the way the client needs it to be. Only if you have some non-standard scenario is that you need to use this extensibility point.

Share via