Windows Phone 7 Notification Services – Prerequisites


  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

Step Purpose of Step
(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
 
hyperlink2  

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>

image

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.

image
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.

image 

 

  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

image

Add Service

image

Double click on SayHello()

image

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

image

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=http://schemas.xmlsoap.org/soap/envelope/>
  <s:Header>
    <Action s:mustUnderstand=1 xmlns=http://schemas.microsoft.com/ws/2005/05/addressing/none>http://tempuri.org/IService/SayHello</Action>
  </s:Header>
  <s:Body>
    <SayHello xmlns=http://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=http://schemas.xmlsoap.org/soap/envelope/>
  <s:Header />
  <s:Body>
    <SayHelloResponse xmlns=http://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…

Comments (2)
  1. jackhu says:

    I really like this models, the main recommendation thank you!

    http://www.nokiae72.net

  2. Carl Oren says:

    If you wish to skip the step of building a notification server, you can use a <a href="https://PushBug.com">Notification service for Windows Phone 7</a>, which allows for registering devices, and sending all types of notifications through API or web interface.

Comments are closed.

Skip to main content