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();

 

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

Today Microsoft has released production ready BETA version of BizTalk RFID 2009.

The key features of BizTalk RFID 2009 include:

·         BizTalk RFID Mobile (RFID platform for Windows Mobile and Windows CE based devices)

o   BizTalk RFID Mobile consists of a runtime engine, tools and components to develop, deploy and manage RFID solutions on mobile devices.

o   Store and Forward: BizTalk RFID Mobile supports the ability to store events locally as well as forward them to the server.

o   Remote Management: BizTalk RFID Mobile allows remote management of Windows Mobile-based devices.

o   SQL Sink service: BizTalk RFID Mobile supports using a SQL database to store events and information on the mobile device, in much the same way that BizTalk Server RFID does.

·         Support for industry Standards

o   LLRP Provider: Out-of-the-box connectivity with readers using the EPCglobal-ratified Low-Level Reader Protocol (LLRP) reader-host standard.

o   TDT: Services to decode tag attributes natively via the Tag Data Translation (TDT) standards library

o   WS Discovery: A library for providers to discover devices using the standard web services based discovery mechanism.

·         Support for newer platforms             

o   Windows Server 2008

o   SQL Server 2008

o   .Net 3.5 SP1 and Visual Studio 2008

 

 

 

The Azure is the Windows operative system designed for “Cloud”.  It is a scalable platform
which provide support for: Live Services, .NET services, SQL Services, SharePoint Services and  Dynamics CRM Services.

If provides a life cycle management of services and applications in the cloud. It is important that Azure does not only manage server. Moreover it also manages services.

The goal of WS-Discovery protocol is to enable a client to search for one or more target services. For this reason WS-Discovery is specified as multicast discovery protocol. As I already announced one of message enhancements in .NET 4.0 will be support for WS-Discovery protocol. Note that this post is not about .NET 4.0, but about WS-Discovery.
This protocol is very usefully when clients need to find services. The term service in this context can be a usual Web Service in SOA environment or even some hardware device. For example Windows Vista implements WS-Discovery to support the Device Profile for Web Services (DPWS). DPWS provides standards-based connectivity to network devices including printers, RFID readers, wireless cameras, projectors, and more. The DPWS lightweight protocol fits into small devices and enables a new wave of experiences with across-the-Internet connectivity between devices, PCs and Web services. Web Services on devices allows devices and PCs to connect to each other across the Internet, even as they roam and change IP addresses.

WS-Discovery specification assumes DISCOVERY_PORT 3702 [IANA], IPv4 multicast address: 239.255.255.250 and IPv6 multicast address: FF02::C (link-local scope).

Discovery Model

Note that all messages are sent over SOAP/UDP protocol. Here are four different scenarios defined by WS-Discovery specification, which corresponds to the model shown below.

(a) When a target service joins the network, it sends an announcement message (1) to the same multicast group. By listening to this multicast group, clients can detect newly-available target services without repeated probing. This reduces network traffic, because clients doe not have to send pooling requests to find the target service.

(b) To find a target service by the type of the service or by scope in which the target service resides (or both), a client sends a probe message (2) to a multicast group. Service(s) which matches the probe sends the response called Probe Match (3) to the client directly.

(c)The client can also try to find the service by its name. In this case client should send the resolve message (4) to the multicast group. Response to this message is called resolve match (5).

(d) Additionally WS-Discovery specification defines multicast suppression behavior. This is when a proxy called discovery proxy is available on the network. When a discovery proxy detects a probe [resolution message - (b)] , the discovery proxy sends an announcement for itself. By listening for these announcements, clients detect discovery proxies and switch in multicast suppression behavior (use a discovery proxy-specific protocol). If a discovery proxy is unresponsive for some reason, clients revert from this mode.

(e) When the service lives the network it sends the Bye message (6).

Note that WS-Discovery protocol does not provide any information about liveness of the target service.

 

 

Here is one example which uses Probe request (2) and Probe Match response (3).

Probe Message

Following message is an example of querying for the printer-service. Note that this request does not contain ReplyTo-tag (see in this post for one example of WS-Addressing). Because of that the reply message will be an UDP-packet according to SOAP/UDP, which is also a part of .NET 4.0.

<s:Envelope
xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery"
xmlns:i="http://printer.example.org/2003/imaging"
xmlns:s="http://www.w3.org/2003/05/soap-envelope" >
<s:Header>
    <a:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</a:Action>
    <a:MessageID>uuid:0a6dc791-2be6-4991-9af1-454778a1917a</a:MessageID>
    <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
  </s:Header>
  <s:Body>
    <d:Probe>
      <d:Types>i:PrintBasic</d:Types>
      <d:Scopes MatchBy="http://schemas.xmlsoap.org/ws/2005/04/discovery/ldap">        
       ldap:///ou=engineering,o=examplecom,c=us</d:Scopes>
    </d:Probe>
  </s:Body>
</s:Envelope>

The game between Type and Scope in this example illustrate the usage of these two terms. The client is locking for service of type PrintBasic in the specific group defined by LDAP.

Probe Match

The Probe Match response message is sent as response to the Probe Message. First of all this message contains the instance identifier of the service which responses the message.

<s:Envelope
xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery"
xmlns:i="http://printer.example.org/2003/imaging"
xmlns:s="http://www.w3.org/2003/05/soap-envelope" >
<s:Header>
<a:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</a:Action>
 <a:MessageID>uuid:e32e6863-ea5e-4ee4-997e-69539d1ff2cc</a:MessageID>
  <a:RelatesTo>uuid:0a6dc791-2be6-4991-9af1-454778a1917a</a:RelatesTo>
  <a:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:To>
    <d:AppSequence InstanceId="1077004800" MessageNumber="2" />
  </s:Header>
  <s:Body>
    <d:ProbeMatches>
    <d:ProbeMatch>
      <a:EndpointReference>
        <a:Address