Windows Phone 7 Notification Services – Prerequisites

Article
12/14/2010

Some obvious prerequisites

If you are serious about Windows Phone 7 development and want to make use of Notification Servcies, you need to know a few things really well.

Technology	Why you need to know it
Silverlight	Is one of the two main programming models for Windows Phone 7. The other is XNA.
Windows Communication Foundation (WCF)	Is an SDK for developing and deploying services on Windows. WCF provides a runtime environment for services, enabling you to expose CLR types as services, and to consume other services as CLR types. Your phone app will need to communicate with something out on the web to send and receive data. A great candidate is WCF, which I will walk you through. You can implement SOAP or REST with WCF, as explained below. Windows Phone 7 works with both. What is REST and SOAP? Well, I talk about it a little below.

Both Silverlight and WCF need to be hosted somewhere. Silverlight is typically embedded in a web page at a web site. The binary Silverlight application lives on a web server as well.

Not even included below is a discussion about hosting your WCF Service or Web App in Windows Azure.

Hosting Location	What it means
IIS	This is Internet Information Server (IIS). This is simply a web server. Apache might be another one you are familiar with.
Self Hosting	This means that your application will start and host a WCF service programmatically. You program the ServiceHost() object. But this means your application must always be up.
WAS (Windows Activation Service)	The Windows Process Activation Service (WAS) manages the activation and lifetime of the worker processes that contain applications that host Windows Communication Foundation (WCF) services. It removes the dependency on HTTP. This allows WCF services to use both HTTP and non-HTTP protocols, such as Net.TCP, in a hosting environment. It supports message-based activation and offers the ability to host a large number of applications on a given machine. Important Note Requires IIS to be available

Which is better, REST or SOAP?

It is an odd comparison because they are somewhat “apples and oranges.” This debate rages, “REST is an architectural style for building client-server applications. SOAP is a protocol specification for exchanging data between two endpoints.“

WCF Service Type	Why it is used
SOAP	Developed my Microsoft in 1998. Platform neutral approach to middleware. Considered the standard for web services. No built in caching because built upon HTTP Post. SOAP can work with protocols other than HTTP. Leverages a number of additional protocols from the industry *WS- standards. Better at federated security, which is when one company can be trusted and considered authenticated by another company without the second company having to maintain the authentication information (username and password, typically). SOAP supports WS-Atomic Transactions**, which support distributed, two-phase commits. Many comment that SOAP is limited by the fact that the API on the client must match the API on the server.
REST	Often considered to be simpler and faster. Good for simple create-read-update-delete types of interactions. REST provides caching built-in from HTTP Get requests. REST has no support for distributed transactions. Generally considered more interoperable, because SOAP and the WS-* specification has a large number of different standards. Also, most all platforms support http as a protocol, even mobile devices, household devices, POS devices, DVD players, and TVs. There is no direct support for generating a client from server-side-generated metadata, as there is in the world of SOAP. Many discount the value of this metadata because you still have to learn the underlying API of the service.

Video Demo of building a SOAP and RESTful Service

What the video covers

(1) Create Sample WCF Service

To provide a connection for Windows Phone 7 devices. Later we will need this for “Windows Phone 7 / Push Notification Services”

(2) Modify sample function provided by Visual Studio

To add our business logic

(3) Modify web.config

This is where you specify the attributes of our “basic” SOAP based service. basicHttpBinding is considered far too simplistic for modern enterprise applications.

Challenge with basicHttpBinding	Explanation
Bad Security	When a client calls an operation on a service, all data in the payload is send as a plain XML, human readable, SOAP packet
Reliable delivery	basicHttpBinding does not support reliability and ordered delivery
Lost calls	When a call is lost somewhere, the client is not informed and just waits for a timeout and can not know for sure if the call has arrived at the server and if the logic behind it got executed
Ordered delivery issues	Also lacking in the basic profile is ordered delivery. This means when a client fires multiple calls to the service it's not guaranteed that they arrive in the same order
Routers could interfere with enterprise business	Maybe somewhere a router could drop a packet allowing the second call to arrive earlier than the retransmission of the first. This can lead to disasters, which cannot be allowed in enterprise solutions

(4) Work with WCF Test Client to execute the code in our WCF Service

Examine SOAP Envelopes (Request and Response) and validate our code

Click Here:

Source Code - Web.config

Source Code for Web.Config – the one I modified

The default web.config (bare bones from WCF template)

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <system.web>
     <compilation debug="false" targetFramework="4.0" />
   </system.web>
  
   <system.webServer>
     <modules runAllManagedModulesForAllRequests="true"/>
   </system.webServer>
   <system.serviceModel>
     <behaviors>
       <endpointBehaviors>
         <behavior name="myBehavior">
           <callbackDebug includeExceptionDetailInFaults="true" />
         </behavior>
       </endpointBehaviors>
       <serviceBehaviors>
         <behavior>
           <serviceMetadata httpGetEnabled="true" />
         </behavior>
       </serviceBehaviors>
  
     </behaviors>
     <services>
       <service name="NewServiceType">
         <endpoint
            address="myAddress1" behaviorConfiguration="myBehavior"
            binding="basicHttpBinding"
            contract="IService" />
       </service>
     </services>
   </system.serviceModel>
 </configuration>

Module	Purpose
IService.cs	The interface to Service.cs. Indicates a contract.
Service.cs	The entry point for the SOAP request. Basically, it is a method call into this file.
Service.svc	This is the entry point that gets code executing in Services.cs.
Web.config	Defines the attributes of our SOAP endpoint, as seen below.

Note the key snippet in web.config, which establishes our SOAP endpoint.

Some key images – things to notice

The images below….	Why it is important
WCF Test Client	Allows you to test SOAP services without requiring you to program the client. Just “Add Service”
Add Service from the “File” menu	How you connect to the predefined SOAP endpoint.
SayHello()	If you double click, it allows you to call the method passing parameters from WCF Test Client to the WCF Service Endpoint that you defined. Click “Invoke()”

Where do you get WCF Test Client? C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\WcfTestClient.exe WCF Test Client

Add Service

Double click on SayHello()

Type in your name (Bruno) and click “Invoke”

Notice the response is “Hello: Bruno” . If you click “XML” you can actually see the SOAP envelopes. More generally you should notice that SOAP requests and responses come in a SOAP envelope:

Object Type	Purpose
Request object	To call a SOAP service, passing data, getting some back
Response object	To get a response back from the SOAP service

Description: The SOAP envelope sent by client to web service

 <s:Envelope xmlns:s=https://schemas.xmlsoap.org/soap/envelope/>  <s:Header>    <Action s:mustUnderstand=1 xmlns=https://schemas.microsoft.com/ws/2005/05/addressing/none>https://tempuri.org/IService/SayHello</Action>  </s:Header>  <s:Body>    <SayHello xmlns=https://tempuri.org/>      <name>Bruno</name>    </SayHello>  </s:Body></s:Envelope>

Figure: Request Object Description: The SOAP envelope sent by the web service back to the client

 <s:Envelope xmlns:s=https://schemas.xmlsoap.org/soap/envelope/>  <s:Header />  <s:Body>    <SayHelloResponse xmlns=https://tempuri.org/>      <SayHelloResult>Hello: Bruno</SayHelloResult>    </SayHelloResponse>  </s:Body></s:Envelope>

Figure: Response Object

Description: The Main Service.cs class. Just a method that prepends “Hello: “ to the name passed in

 public class Service : IService{    public string SayHello(string name)    {        return string.Format("Hello: {0}", name);    }}

Figure: Service.cs – SOAP Based

More is coming…

Windows Phone 7 Notification Services – Prerequisites

Important Note

Additional resources