This Blog

Home

Syndication

DamirDobric

studeni 2008 - Posts

.NET 4.0 : Enabling WCF service for discovery

In this post I described how .NET 4.0 clients can make a usage of WCF-discovery functionality. This post describes how to enable WCF-service to be discoverable. In order for a service to be discoverable in an ad-hoc manner it needs to respond to so called probe messages. Ad-hoc discovery implies that these probe messages come in through a well known port over UDP multicast (DISCOVERY_PORT 3702 [IANA], IPv4 multicast address: 239.255.255.250 and IPv6 multicast address: FF02::C (link-local scope). Discovery APIs (System.ServiceModel.Discovery) allow you to add this functionality either imperatively or through configuration.
If you are interested on discovery details this post describes some important topics of WS-discovery protocol specification.

To enable discovery of the service by using of the configuration you need to do two things:

1. Add one endpoint with attribute kind = “udpDiscoveryEndpoint”:

2. Add one Service Behavior which contains anouncment endpoint:

Next picture shows the final configuration:

Personally I do not like the way how the configuration in this case is designed. For example, assuming that MEX requires httpMexBinding and interface IMetadataExchange I would expect that all other “special endpoints” work the same way. Unfortunately or even fortunately discovery works different way. You do not need any kind of discoveryBinding. To me this is not consistent and it should be changed. How about kind=”MEX”?

Behavior Extensions

As long your client connects to well know fixed endpoint (.NET < 4.0) the client might have some knowledge of the endpoint. However, when the endpoint is discovered, the client is obtaining the knowledge about endpoint dynamically. For this reason it is useful to inject more metadata in the endpoint. This data could represent some kind of description (extension) of the endpoint.

Following example shows how to add such extensions:

             foreach (System.ServiceModel.Description.ServiceEndpoint ep in host.Description.Endpoints){
              if (ep.Contract.ContractType == typeof(IService1))
              {
                  if (ep.Binding is BasicHttpBinding)
                  {
                      System.ServiceModel.Discovery.EndpointDiscoveryBehavior endpointDiscoveryBehavior = new
                        System.ServiceModel.Discovery.EndpointDiscoveryBehavior();

                      endpointDiscoveryBehavior.Extensions.Add(new XElement("MyExtensionRoot", new XElement
                       ("CevapNode", "Cevapi preko basic bindinga")));

                      endpointDiscoveryBehavior.Extensions.Add(new XElement("MyExtensionRoot", new XElement
                       ("MyNode", "Using of basic binding.")));

                      ep.Behaviors.Add(endpointDiscoveryBehavior);
                  }
                  else if (ep.Binding is WSHttpBinding)
                  {
                      System.ServiceModel.Discovery.EndpointDiscoveryBehavior endpointDiscoveryBehavior = new
                          System.ServiceModel.Discovery.EndpointDiscoveryBehavior();

                      endpointDiscoveryBehavior.Extensions.Add(new XElement("MyExtensionRoot", new XElement
                      ("CevapNode", "Cevapi preko WS* bindinga")));

                       endpointDiscoveryBehavior.Extensions.Add(new XElement("MyExtensionRoot", new XElement
                       ("MyNode", "Using of WSHttpBinding")));

                      ep.Behaviors.Add(endpointDiscoveryBehavior);
                  }
              }
          }

Next picture shows where the client can find this information:

Posted stu 27 2008, 06:24 by anonymous

WCF and Service Discovery in .NET 4.0

This post describe how to implement the client able to perform discovery the service based on WS-Discovery protocol.
If you are interested on discovery details this post describes some important topics of WS-discovery protocol specification.

The client (or thread) performing discovery should make a usage of the class DiscoveryClient, which is currently implemented in the namespace System.ServiceModel.Discovery and assembly System.WorkflowServiceModel.Dll.
To discover the service the client has to create FindCriteria. This criteria simply contains the interface of the target service:

FindCriteria criteria new FindCriteria(typeof(IService1)

After the criteria is defined the discovery process can be started either synchronous or asynchronously by using of Find or FindAsync methods respective. Practically you will probable mostly use the FindAsync (see example below).

During discovery you can register several events handlers. For example FindProgressChanged is invoked each time one of service endpoints has been discovered. This is interesting when the clients is looking for any endpoint.
If you want to be notified when the discovery process is finished then the handler FindCompleted would be the better solution. This handler is invoked at the end of discovery when all endpoints have been discovered.

Following example shows how to implement the client which asynchronously discovers the service IService1:

static void Main(string[] args)
{
    DiscoveryClient discClient =
    new DiscoveryClient(new UdpDiscoveryEndpoint());

    discClient.FindCompleted += new EventHandler<FindCompletedEventArgs>
    discoveryClient_FindCompleted);

    discClient.FindProgressChanged +=
    new EventHandler<FindProgressChangedEventArgs>(discoveryClient_FindProgressChanged);

    discClient.FindAsync(new FindCriteria(typeof(IService1)));

Console.ReadLine();

}

   static void discoveryClient_FindProgressChanged(object sender,
                                                   FindProgressChangedEventArgs e)
   { }

static void discoveryClient_FindCompleted(object sender, FindCompletedEventArgs e)
{ }

Next picture shows the result of discovery process. The result shown at the picture is the value of the parameter FindCompletedEventArgs of the event handler (discoveryClient_FindCompleted) DiscoveryClient.FindCompleted:

The picture shows that the target service has been discovered at two endpoints. The second one shows that the service supports
listening based at wsHttpBinding.

Posted stu 23 2008, 08:54 by anonymous

udpDiscoveryEndpoint error

When enabling discovery functionality of the service in .NET 4.0 you may get following error:

"The 'address' property cannot be specified for endpoint of kind 'udpDiscoveryEndpoint'. To configure the multicast address and port, use 'multicastAddress' property on a standardEndpoint element defined in the standardEndpoints\udpDiscoveryEndpoint section and reference it to this endpoint element using ‘endpointConfiguration’ property"

This happen when the discovery endpoint is used with address property (which is endpoint's relative address).

Here is the example which shows how to set this property:

Because, the discovery endpoint is discoverable the address is not required (it wouldn't make a sense) and by default not allowed. Next line shows how to setup the right endpoint configuration:

Posted stu 23 2008, 08:54 by anonymous

Live Services Summary

At the PDC 08 Microsoft has announced many new technologies. The good thing is that the general strategy seems to incorporate all these technologies in the unique global strategy. Disadvantage of this strategy might be that such kind of big-bang could confuse people in term of understanding dependencies between all these technologies (including Microsoft employees).

This post is related to live services strategy and it should explain most important topic behind live services.

What is Live Services?

“Live Services” is set of building blocks for handling user data and application resources which can connect one application to huge number of users. Huge number means several hundred millions of users. For example 500E+06 users.

What services are included in Live Services?

1. Identity Services
Enables managing of identities for users, devices and applications.

2. Directory Services
Enables management of associations between principals.

3. Storage Services
Scalable storage for storing of metadata and blobs.

4. Comms & Presence Services
Enables Communication and presence including pub/sub features.

5. Search & Geospatial Services

What is Mesh Services?

Mesh Services extends (meshefies) Live Services to provide more powerful capabilities around data in four specific dimensions: Users, Devices, Applications and Synchronization.
The Live Framework behind Mesh provides developers symmetric API on the client and in the cloud and easy way to build application eco-system.

Architecture of Live Services including Mesh Services

What can I do with Mesh?

Mesh enables you to easily deal with:

1. Devices
Registered devices in your Mesh Desktop

2. Mesh Objects
Pretty anything you can add to device desktop (Pictures, recordings, Music etc)

3. Data Feed Files
Collection of files of files one Mesh Object. For example collection of pictures of the Mesh Object “My Pictures” (which is a kind of folder.)

4. News
News is a kind of eventing subsystem in the mesh related to Mesh Object. Several actions in the mesh like adding of the file results in one news item. Note that additionally to news there are also notifications, which can be client or cloud based.

5. Media Resources
Binary data of an item in the collection of items (feed) of one mesh object.

6. Contacts
People in the mesh.

7. User Profiles
Keeps information about user’s profile. For example user’s interests, which can be used to build social graph?

8. Members
The list of people which share a Mesh Object.

Live Framework Resource Model?

How to describe Mesh in three words?

“Feed of feeds”

Live Operation Framework

This is the runtime which hosts Live Services and all required functionalities behind the scene (analytics (who does what – it might be interesting for the billing in the future J), caching, synchronization etc.).

There are two versions of Live Operation Framework: Cloud Operating Environment and Client Operating Environment. If you take a look on the resource model, this operation environment is the root of everything in the “Live Universe”.

What application can be developed by using of Mesh?

The Mesh and Live Services is in interesting and innovative platform which enable building of applications we probably have never seen before. This will give us a possibility to think about totally new scenarios in the near future.
To give you some idea how Microsoft thinks about this here are some examples:

1. Devices
Connecting of different devices and sharing of data between them.

2. Social and Community Sites
Seamlessly integrate social applications across invites, news feeds, local devices experiences, and more

3. Web to the client
Enables offline experience by pushing of the content to the client.

4. Client to the web
Service enabled client applications.

The Big Picture

The biggest picture without Mesh focus

Following picture shows the strategy place of Live Services in the Windows Azure idea.

Live Framework for Developers?

1. Live Framework (liveFX)

2. Live Framework API

3. Live Framework .NET Kit

What are Life Framework API Kits?

Kits are a set of libraries which can be used to program LiveFx. Currently there are few kits like .NET 3.5 API-s, Silverlight API-s and JavaScript API-s. Moreover they also offer several Client Controls and Wev Controls.

For example Life Framework .NET Kit exposes the core Live Services in a cohesive and consistent way. It makes dealing with Live Services easy and natural for .NET developers and provides a symmetrical programming model between client and server.

Following example shows how to connect to Live Operative Environment, which is the very first step in by developing of such applications:

NetworkCredentials creds = new NetworkCredentials(username, pwd, endpoint);
LiveOperatingEnvironment loEnv = new LiveOperatingEnvironment();
loEnv.Connect(creds);

Note that connection in this example is established to the cloud environment to address https://username.windows.net.
The API provides additionally a connection to the local environment too, which is a kind of the copy of the cloud environment. (Note that following example does not use credentials.)

LiveOperatingEnvironment loEnv = new LiveOperatingEnvironment();
loEnv.ConnectLocal();

Posted stu 20 2008, 08:21 by anonymous

WCF vs. WCF.CF

Here is the table which represents comparison between WCF desktop and compact framework version 3.5.

Feature	Desktop WCF	Compact WCF
Bindings:
· BasicHttpBinding	Yes	Yes
· CustomBinding	Yes	Yes
· WindowsMobileMailBinding	N/A	Yes
· ExchangeWebServiceMailBinding	Yes, via NetCF install	Yes
Formatters:
· SoapFormatter	Yes	Yes
· BinaryFormatter	Yes	No
Encoders:
· TextMessageEncoder	Yes	Yes
· BinaryMessageEncodingBindingElement	Yes	No
· MTOMEncoder	Yes	No
· GzipEncoder	Sample available	Sample available
Transports:
· HttpTransportBindingElement	Yes	Yes
· HttpsTransportBindingElement	Yes	Yes
· MailTransportBindingElement	Yes, via NetCF install	Yes
· MsmqTransportBindingElement	Yes	No
· TcpTransportBindingElement	Yes	No
· (other transports)	Yes	No
XmlDictionaryReader/Writer	Yes	Yes; stub around XmlTextReader/Writer
DataContractSerializer	Yes	No; but can be wire-compatible with DCS via XmlSerializer
Service proxy generation	Yes; via SvcUtil.exe	Yes; via NetCFSvcUtil.exe, not integrated into VS2008
· Non-HTTP transports in generated proxies	Yes	Not built-in
· Custom headers in generated proxies	Yes	Not built-in
WS-Addressing	Yes	Yes
WS-Security message level security
· X.509	Yes	Yes
· Username/password	Yes	No
· SecurityAlgorithmSuite.Basic256Rsa15	Yes	Yes
· SecurityAlgorithmSuite.Basic256	Yes	No
WS-ReliableMessaging	Yes	No
Patterns
· Service model	Yes	No
· Message layer programming	Yes	Yes
· Buffered messages	Yes	Yes
· Streaming messages	Yes	No
· Endpoint descriptions in .config files	Yes	No
Channel extensibility	Yes	Yes
Security channel extensibility	Yes	No

Posted stu 06 2008, 11:01 by anonymous

Community Blogs