The first chapter of the WCF extensibility guide that Jesus and I have been working on during the last few months went live in MSDN this weekend. You can find it here, http://msdn.microsoft.com/en-us/library/ee672186.aspx
The first chapter gives an overview of the channel layer, and some of the extensibility points you can find there to implement custom channels.
Enjoy!!
I was wondering these days what would be the point in using WS-Passive when there is another simple sign-on solution, OpenID, that works really well and it’s getting a great adoption in the community. I can not say the same about WS-Passive, I haven’t seen any concrete implementation yet (For instance, Microsoft is planning to release a first implementation as part of the WIF framework before the end of this year).
However, I reached the conclusion that both technologies are prepared for addressing different scenarios. For me, OpenID is more suitable for community or social networking web sites that expect to have a great number of users, and can benefit from using the large user databases that some of the existing OpenID providers already have. This is also a great thing for the final user as he can reuse his public OpenID identifier to log into all these web sites.
On the other hand, WS-Passive seems to work better for enterprise scenarios in companies that might have some sort of security infrastructure in place (Customer user databases, active directory, active STSs for services) and do not want to have third parties (other than the parties involved in the business) to participate in the business transactions or to share their user databases with these parties. This is closely related to one of the identity laws that Kim Cameron announced a time ago. Law #3, “Justifiable Parties”, Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
This was one of the big failures in the adoption of Passport as Single-Sign-On technology. Some relying parties did not understand the purpose of having Microsoft (and Passport) involved in their business transactions.
In addition, WS-Passive only specifies a way to interchange a security token with user claims between the involved parties (Client, STS and Relying Party), so it provides the flexibility of using any security token profile. The most common token profile used today is SAML, as it can be customized with custom assertions or claims specific to the business. OpenID also specifies a way to exchange custom data (other than Simple Registration or SReg data) through the “Attribute Exchange” spec. However, it looks like many of the existing relying parties or identity providers do not support this spec as it is discussed here.
I am just guessing :). What do you think ?.
As Dr Nick announced in this post, WCF 4.0 will ship with a new feature to configure a client channel from a configuration source other than the traditional section in the application configuration file (I discussed a workaround for doing the same thing in WCF 3.0 a time ago in this post)
This will provide the flexibility to deploy some binaries with the client proxies together with an independent configuration file (which might be a resource file, a stand alone file included with your application or something you can download from an specific place), so the main configuration file does not need to be touched at all.
A new channel factory “ConfigurationChannelFactory” is included as part of the System.ServiceModel.Configuration namespace to create channels from an alternative configuration source.
var fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = "otherFile.config";
var configuration = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
var factory = new ConfigurationChannelFactory<IService1>("BasicHttpBinding_IService1", configuration, new EndpointAddress("http://localhost:49187/Service1.svc"));
var client = factory.CreateChannel();
var s = client.GetData(3);
Console.WriteLine(s);
The file “otherFile.config” is just a simple configuration file that contains the client definition and configuration for using the “IService1” service.
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IService1" >
<security mode="None">
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:49187/Service1.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IService1" contract="ServiceReference1.IService1"
name="BasicHttpBinding_IService1" />
</client>
</system.serviceModel>
</configuration>
All this code is based on the .NET 4.0 beta 1, so it might change in the final release.
The other day I came across a pretty cool project, Linq2Twitter, that basically implements a linq provider for consuming the Twitter REST Api. This project is not only interesting because it provides an intuitive model for incorporating Twitter calls into any existing application, but also because it shows how to use the OAuth authentication mode that the Twitter Api supports.
As it is common with other linq providers, this library provides a root class “TwitterContext” for executing queries or calling other services in the API.
So you can do things like this,
var twitterCxt = new TwitterContext();
var tweets =
from tweet in twitterCtx.Status
where tweet.Type == StatusType.Friends
select tweet;
tweets.ToList().ForEach(
tweet => Console.WriteLine(
"Friend: {0}\nTweet: {1}\n",
tweet.User.Name,
tweet.Text));
The example above shows some code to gets the status of all your friends.
Before using any of the services available in the API, you must first authenticate in Twitter using either basic authentication (The traditional way with username and password) or OAuth. The authentication mode is specified in the twitter context.
In case you decide to go with OAuth, it is very simple to use. You only need to provide the OAuth secret and key associated to an application that you previously registered in Twitter.
Console.Write("Consumer Key: ");
twitterCtx.ConsumerKey = Console.ReadLine();
Console.Write("Consumer Secret: ");
twitterCtx.ConsumerSecret = Console.ReadLine();
string link = twitterCtx.GetAuthorizationPageLink(false, false);
Console.WriteLine("Authorization Page Link: {0}\n", link);
Console.WriteLine("Next, you'll need to tell Twitter to authorize access. This program will not have access to your credentials, which is the benefit of OAuth. Once you log into Twitter and give this program permission, come back to this console and press Enter to complete the authorization sequence.\n\nPress Enter now to continue.");
Console.ReadKey();
// launches browser so you can log in and give permissions
Process.Start(link);
Console.WriteLine("\nYou should see your browser navigate to Twitter, saying that your application wants to access your Twitter account. Once you've authorized this program, return to this console and press any key to execute the LINQ to Twitter code.");
Console.ReadKey();
var uri = new Uri(link);
NameValueCollection urlParams = HttpUtility.ParseQueryString(uri.Query);
string oAuthToken = urlParams["oauth_token"];
twitterCtx.RetrieveAccessToken(oAuthToken);
if (twitterCtx.AuthorizedViaOAuth)
OAuth requires a browser session so you can log into twitter and authorize the client application to get your data. This is not a problem if the client application is a web application, the authentication and authorization processes flow very natural. However, in the case of Windows or Console Application, a browser instance needs to be created, this is what the example above is doing in the line “Process.Start”. If you are already authenticated in twitter, you will see this page where you need to authorize the application that wants to get access to your data.
It looks like Andrew Arnott have been involved in the OAuth implementation for this library, which is a really good thing since he is the main contributor in two of the most stables projects for OpenID (DotNetOpenId) and OAuth (DotNetOpenAuth) in the .NET world.
El proximo sabado 26 de septiembre vamos a tener la oportunidad de tener nuevamente un codecamp en buenos aires de la mano de Microsoft.
El evento como en otras oportunidades va a ser mas que interesante, con un monton de charlas prometedoras y algunas novedades que Microsoft tiene para darnos.
Para mas informacion, podes visitar el sitio oficial en
http://www.codecamp.com.ar/
Los esperamos a todos.
In the previous post, I discussed how bad was to expose EF entities directly as data contracts from a perspective of “interoperability”. This also revealed a lot of internal implementation details about EF that the client applications should not worry about.
As Daniel Simmons pointed out, the next version of Entity Framework (4.0) will ship with a new and very useful feature to represent the data entities using POCOs (Self-tracking entities). This new support for POCOs will make possible to simplify a lot the final representation of entities on the wire, hiding all those annoying details about EF. You will also able to decorate the entities with DataContract/DataMember attributes if you do not want to expose the whole entity in the service.
However, I still do not buy the idea of using the EF entities as data contracts. By doing that, you are coupling your service interface to the final data model, which is not a good idea since both layers usually evolve at different rates. What is worse, any change in the database model might affect your service interface as well, breaking the contract that any potential consumer have with the service.
This last aspect is related to versioning. The versioning between the two layers is completely different, you might have for instance an User entity in the data model, and different versions of the same entity in the service interface, UserV1, UserV2, etc (Any of these corresponding to a different version of the service). The service is the responsible of making the transition between the different data contracts to the final data model entities.
I think this might be only useful for RIA applications where you use the services as a mechanism to interchange data between your backend layer and the UI, for instance web applications that use Ajax Callbacks or Silverlight applications. So, the number of potential consumers of the services is really low.
A common misconception is to think that a WCF proxy can be used and disposed as any other regular class that implements IDisposable. However, the IDisposable implementation in the WCF client channel is not like any other, and it can throws exceptions. A phrase I got from this thread in the WCF forum will give you a better context about this scenario,
“I think a key thing to notice is that Close() often implies doing "real work" that may fail, including network communication handshakes to shutdown sessions, committing transactions, etc.”
As consequence of this, we should add some code to handle any possible exception for network errors when a proxy is closed/disposed.
The common pattern for cleaning up a proxy is the following,
try
{
...
client.Close();
}
catch (CommunicationException e)
{
...
client.Abort();
}
catch (TimeoutException e)
{
...
client.Abort();
}
catch (Exception e)
{
...
client.Abort();
throw;
}
The problem is, I do not want to have that code everywhere in my application. A good solution for that is to use a helper class like this one.
Michelle recently announced a new project that automatically generates a proxy helper class like that in Visual Studio. http://wcfproxygenerator.codeplex.com/
That is a feature I would like to see out of the box in the next version of WCF :).
Do you want to see something very ugly ?. Try to send a complete EF entity directly as a data contract over the wire with WCF,
<Order xmlns:i="http://www.w3.org/2001/XMLSchema-instance" z:Id="i1" xmlns:z="http://schemas.microsoft.com/2003/10/Serialization/" xmlns="http://schemas.datacontract.org/2004/07/ClassLibrary2">
<EntityKey xmlns:d2p1="http://schemas.datacontract.org/2004/07/System.Data" i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.Data.Objects.DataClasses" />
<Description>My new order</Description>
<OrderId>1</OrderId>
<OrderItem>
<OrderItem z:Id="i2">
<EntityKey xmlns:d4p1="http://schemas.datacontract.org/2004/07/System.Data" i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.Data.Objects.DataClasses" />
<Currency>USD</Currency>
<Description>item 1</Description>
<ItemId>1</ItemId>
<Order z:Ref="i1" />
<OrderReference xmlns:d4p1="http://schemas.datacontract.org/2004/07/System.Data.Objects.DataClasses">
<d4p1:EntityKey xmlns:d5p1="http://schemas.datacontract.org/2004/07/System.Data" i:nil="true" />
</OrderReference>
<UnitPrice>10</UnitPrice>
</OrderItem>
<OrderItem z:Id="i3">
<EntityKey xmlns:d4p1="http://schemas.datacontract.org/2004/07/System.Data" i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.Data.Objects.DataClasses" />
<Currency>USD</Currency>
<Description>item 2</Description>
<ItemId>2</ItemId>
<Order z:Ref="i1" />
<OrderReference xmlns:d4p1="http://schemas.datacontract.org/2004/07/System.Data.Objects.DataClasses">
<d4p1:EntityKey xmlns:d5p1="http://schemas.datacontract.org/2004/07/System.Data" i:nil="true" />
</OrderReference>
<UnitPrice>145</UnitPrice>
</OrderItem>
</OrderItem>
</Order>
That is the result of serializing a complete object graph. I do not know what the folks in Microsoft were thinking when they decided to enable a feature like this. They made a good work teaching us about how evil Datasets were for interoperability with other platforms, and now they came up with a solution like this, no way.
I always like the idea of making boundaries explicit, that is the approach the WCF team took with the first version of the framework (Every data contract should be decorated with DataContract and DataMember attributes). If you break that rule, you will end up with things like this.
I know this a solution for people that want to develop things quickly with no need to create DTOs, and do all the mapping stuff, but there are good tools and frameworks like AutoMapper to help with that. Or you can use ADO.NET Data Services today, which is also prepared to handle this kind of scenarios, all the transformations between layers are made by the framework itself, and still you get a very nice RESTful api. We still need some more features in ADO.NET DS to have a more complete framework, there is not good support today for injecting business logic, it can be done but it is complicated, it looks like the next version will address that aspect better.
Como Jesus menciono en su post “We are still hiring..”, en Tellago estamos buscando gente que quieran unirse a nuestro equipo de desarrollo. En estos momentos tenemos algunas posiciones para Arquitectos y Desarrolladores con buenos conocimientos de Biztalk e idioma ingles.
Si queres ser parte de una empresa joven, jugar con las ultimas tecnologias o involucrarte en proyectos con diversos equipos de trabajo en Microsoft, enviame tu curriculum a pablo [dot] cibraro [at] tellago [dot] com
Las posiciones pueden ser tanto en Buenos Aires como en los Estados Unidos.
ADO.NET Data services represent today one of the most powerful alternatives to build RESTful services in the .NET platform. This framework basically creates a RESTful API on top of any IQueryable data source. Most of the steps required to publish a set of resources through http and make them available for any client are automatically implemented.
Only Entity Framework data models are supported out of the box as read/write data sources, and any other IQueryable data source is considered by default read only. If you want to perform write operations on any other data source different from Entity Framework, you have to implement an additional interface IUpdatable as it is showed in this post. (Update: The new CTP 1.5 seems to have a new class to implement custom data providers, I have not had a chance to play with it yet)
Usually, you will need to inject custom logic in the services for performing validations or implementing business rules.
ADO.NET services comes with two built-in extensibility points for adding custom logic or code to a service, Service Operations and Interceptors.
Service operations represent a simple way to define custom read/write views on top of the data source exposed by the service. It is intended to be used in scenarios where you need to create complex queries, or simple data aggregations that are not supported out of the box in framework. If you want to expose those queries directly as another resource in the service, you have to use service operations.
The classic example given to show this feature in action is a query that returns all the customers in an specific city. That query would be translated in a service operation as follow,
public class MyService : DataService<MyDataSource>
{
// This method is called only once to initialize service-wide policies.
public static void InitializeService(IDataServiceConfiguration config)
{
config.SetEntitySetAccessRule("Customers", EntitySetRights.AllRead);
config.SetServiceOperationAccessRule("CustomersInCity", ServiceOperationRights.All);
}
[WebGet]
public IQueryable<MyDataSource.Customers> CustomersInCity(string city)
{
return from c in this.CurrentDataSource.Customers
where c.City == city
select c;
}
}
As you can see in the code above, the service operation for this example is a simple method decorated with a WebGet attribute that returns an IQueryable implementation (With a pre-defined query in this example). The WebGet attribute specifies that is a read-only view. As soon as we have that service running, you can navigate to that service operation with an URI like this,
http://localhost/MyService.svc/CustomersInCity?city=BuenosAires
Since you are returning an IQueryable implementation, you are also free to define additional transformations on top of this base query, such as projections, filtering, or ordering among others.
WebInvoke can be also used in case you want to implement a write operation. Since a service operation works as a black box, only the post verb is supported for WebInvoke, which means that you can not use other verbs like DELETE or PUT. Regarding this limitation, this is the answer you can find in the forums
“We currently support only POST and GET verbs on the service operations (even in the recently released CTP). Is there a reason why you want to support DELETE verb on service operation? The main reason for not supporting all the verbs is that from the client side, discovery becomes a issue - there is no way to know what verb to send for a service operation. Also service operations are black box to us - so we try and categorized them into side-effecting and non-side effecting ones. We recommend to use GET for non-side effection service opertions and use POST for side-effecting ones.
Please let us know if you think there is a good reason why DELETE verb should be supported.
Thanks
Pratik”
Another problem with service operations is that only scalar values are supported as arguments. Therefore, you can not pass entities or complex data types as arguments to a service operation.
These limitations make hard to use service operations as a way to inject custom logic like validations or business rules into a data service.
Fortunately, there is another extensibility point that becomes handy at the moment of implementing this kind of logic, the Interceptors. There are two kind of built-in interceptors, Query Interceptors, and Change Interceptors.
A query interceptor represents a mechanism to change or transform the initial projection over an entity set. For example, if an user only allowed to see a subset of all the available data in an entity set, a query interceptor is the right place to filter the data for that user.
[QueryInterceptor("Orders")]
public Expression<Func<Orders, bool>> QueryOrders() {
return o => o.Number > 100;
}
The syntax of a query interceptor is quite simple, you basically returns an expression that describes a function (the Func), which takes an input value (an order being evaluated) and returns a bool value (whether the order passes the filter or not). Since an expression is used there rather than a piece of code, that expression can be passed directly to the query provider, which ultimately will generate the appropriate SQL in the database server.
A change interceptor on the other hand, intercepts all the calls that generates changes in the data source exposed by the service. Therefore, this interceptor is the right mechanism for performing some validations before the data is changed in the data source. This is the place where we can enforce the business rules or validate the data for an specific entity set in our application (Entity set in this scenario also represents a collection of resources, where each resource is the entity itself).
[ChangeInterceptor("Orders")]
public void OnChangeOrders(Order o, UpdateOperations operation)
{
if (operation == UpdateOperations.Add || operation == UpdateOperations.Change)
{
if (o.Number > 100)
{
throw new DataServiceException(400,
"You are not allowed to create or change an order with number greater than 100");
}
}
}
A change interceptor method receives two arguments, the entity that will be persisted, and an enumeration UpdateOperations that specifies the operation currently performed on the entity. Possible values for this enumeration are, Add, Change and Delete.
This interceptor is not just to perform validations, you are still free to call additional services or change some data in the entity before it is persisted. However, this method call is synchronous, so you should be careful about executing long running code there.
More Posts
Next page »