A Cup of Silverlight, RIA & Interoperability : D2D

How-To : Silverlight accessing Java SOAP services (Part 2 – No Cross Domain : Tomcat/Eclipse)

Steve SFARTZ — Thu, 14 Aug 2008 16:52:00 GMT

The HowTo series demo Silverlight accessing Web Services in various configuration. In this post, we will demonstrate you a SOAP service consumed by a Silverlight client application where the Site of Origin hosts the Web Services. This scenario is categorized as a D2D scenario without cross-domain policy.

The SOAP service Eclipse project and the Silverlight Eclipse project are available as an attachment to this post.

Technical Environment

SOAP services are built with the JAX-WS and JAX-B Api and hosted in Tomcat
The Silverlight application is also hosted in Tomcat

Because the Site of Origin and the Web Service reside in the same host, no Cross Domain policy is required.

Hosting the Web Service in Tomcat

In case you haven’t done the How-To : Silverlight accessing Java SOAP services (Part 1 – Cross Domain : IIS + Tomcat), you can directly import the SOAP-Sum service Eclipse project into your Eclipse Workspace.

Export it as a WAR in %TOMCAT_INSTALL%/webapps folder
go to http://localhost:8080/SOAP-SumService/services/sum (assuming that Tomcat is running on port 8080) to access the service.

Hosting the Silverlight Application using a Servlet

In the REST way, we showed you how to host a Silverlight Application using a JSP. Now we are going to host a Silverlight application using a Servlet

In Eclipse, create a new dynamic web project named Silverlight-SOAP-SumService_NOSSL
In WebContent folder, add a folder named ClientBin and copy in the latter, the xap file in the attachment. The Silverlight Application is already configured to access the SOAP service at http://localhost:8080/SOAP-SumService/services/sum?wsdl.
Add a Servlet named SilverlightServlet to a package ‘servlet’ and add the following code :

Instance of Silverlight plugin :

private void responseHandler(HttpServletResponse response) throws IOException{

    PrintWriter pw = response.getWriter();

    pw.println("" +

            "<div id=\"silverlightControlHost\">" +

            "    <object data=\"data:application/x-silverlight,\"" +

            "             type=\"application/x-silverlight-2-b2\"" +

            "             width=\"100%\" height=\"100%\">" +

            "       <param name=\"source\" value=\"ClientBin/SOAP-Sum.xap\"/>" +

            "       <param name=\"background\" value=\"white\" />" +

            "       <a href=\"http://go.microsoft.com/fwlink/?LinkID=115261\"" +

            "          style=\'text-decoration: none;\'>' +

            "         <img src=\"http://go.microsoft.com/fwlink/?LinkId=108181\""+

            "              alt=\"Get Microsoft Silverlight\"" +

            "              style=\'border-style: none\'/>' +

            "        </a>" +

            "    </object>" +

            "    <iframe style='visibility:hidden;height:0;width:0;border:0px'>' +

            "</iframe>" +

            "</div>");

    pw.close();

protected void doGet(HttpServletRequest request, HttpServletResponse response)

  throws ServletException, IOException {

    responseHandler(response);

    super.doGet(request, response);

Export the project as a WAR file in %TOMCAT_INSTALL%/webapps folder.
Go to http://localhost:8080/Silverlight-SOAP-SumService_NOSSL/SilverlightServlet (because In the web.xml file located in WebContent/WEB-INF directory, the servlet is configured to handle every requests made on /SilverlightServlet/*)

Silverlight will access the SOAP-Sum service without cross-domain

- Ronny Kwon

Tip : Cross Domain Policy when Self-Hosting your Services

Steve SFARTZ — Mon, 11 Aug 2008 15:24:00 GMT

This tip is about self hosting of services with the .Net WCF or Java Restlet framework. Cross-domain access is mandatory here since the Site of Origin does not host the services.

Self hosting a service represents a quick & easy way to expose a Web Service for tests purpose. Yet, customization is extermely limited since self hosting does not provide you all the capabilities of Web Servers such as delivering static content (cross domain policy file).

The first thing you need to know is that when Silverlight attempts to access services in cross-domain, it will send a HTTP GET method on http://<domain:port>/clientaccesspolicy.xml or http://<domain:port>/crossdomain.xml (in case clientaccesspolicy.xml wasn’t found). If you plan to self host your Web Service, you will agree that there is no possible way to host a physical Cross Domain policy file at the root of the Web Server.

You must handle this request through your Service implementation. It usually matches the /clientaccesspolicy.xml or /crossdomain.xml URI pattern.

WCF way (inspired from Carlo’s blog)

Self-hosted Service

class Program

    static void Main(string[] args)

        // URI of the Service

        Uri uri = new Uri("http://localhost:8081/");

        // create a new WebServiceHost specifying the implementation of the Service

        // and the specified uri to bind with

        WebServiceHost host = new WebServiceHost(

                new REST_ItemsServiceLibrary.ItemsREST(),

                uri);

        // add the Service Endpoint specifying the Service Interface

        host.AddServiceEndpoint(typeof(REST_ItemsServiceLibrary.IItemsREST),

                                new WebHttpBinding(), "");

        // open the WebServiceHost

        host.Open();

        Console.WriteLine("Service hosted at {0}", uri.OriginalString);

        Console.ReadLine();

        // close the WebServiceHost

        host.Close();

Handling cross-domain file requests

As we said earlier, we have to manage the /clientaccesspolicy.xml, specify in the Service Interface that HTTP GET method on the URI /clientaccesspolicy.xml will be handled by GetSilverlightPolicy();

[OperationContract]

[WebGet(UriTemplate ="/clientaccesspolicy.xml")]

Stream GetSilverlightPolicy();

this also applies to /crossdomain.xml

Finally, in your Service implementation, return a clientaccesspolicy.xml content:

public Stream GetSilverlightPolicy()

    string result = @"<?xml version=""1.0"" encoding=""utf-8""?>

<access-policy>

    <cross-domain-access>

        <policy>

            <allow-from http-request-headers=""*"">

                <domain uri=""*""/>

            </allow-from>

            <grant-to>

                <resource path=""/"" include-subpaths=""true""/>

            </grant-to>

        </policy>

    </cross-domain-access>

</access-policy>";

    return StringToStream(result);

Stream StringToStream(string result)

    WebOperationContext.Current.OutgoingResponse.ContentType = "application/xml";

    return new MemoryStream(Encoding.UTF8.GetBytes(result));

Restlet way

Self-hosted Service

public static void main(String[] args) {

    try {

        // Create a new Component.

        Component component = new Component();

        // Add a new HTTP server listening on port 8182.

        component.getServers().add(Protocol.HTTP, 8182);

        // Attach the sample application.

        component.getDefaultHost().attach(

                new FirstResourceApplication(component.getContext()));

        // Start the component.

        component.start();

    } catch (Exception e) {

        // Something is wrong.

        e.printStackTrace();

Handling cross-domain file requests

Following the same philosophy as the WCF way, we need to handle HTTP GET method on /clientaccesspolicy.xml file request :

In the Application implementation you must bind the URI pattern with the Ressource that will handle it :

Finally, implement the ClientAccessPolicy class, specially the HTTP GET method within getRepresentation method :

package firstResource;

import java.io.IOException;

import org.restlet.Context;

import org.restlet.data.MediaType;

import org.restlet.data.Request;

import org.restlet.data.Response;

import org.restlet.resource.DomRepresentation;

import org.restlet.resource.Representation;

import org.restlet.resource.Resource;

import org.restlet.resource.Variant;

import org.w3c.dom.Document;

import org.w3c.dom.Element;

public class ClientAccessPolicy extends Resource{

    public ClientAccessPolicy(Context context, Request request,

            Response response) {

        super(context, request, response);

        getVariants().add(new Variant(MediaType.TEXT_XML));

    @Override

    public Representation getRepresentation(Variant variant){

        if (MediaType.TEXT_XML.equals(variant.getMediaType())) {

             try {

                DomRepresentation representation = new DomRepresentation(

                      MediaType.TEXT_XML);

                // Generate a DOM document representing the list of

                // items.

                Document d = representation.getDocument();

                Element accesspolicy = d.createElement("access-policy");

                d.appendChild(accesspolicy);

                Element crossdomainaccess = d.createElement("cross-domain-access");

                accesspolicy.appendChild(crossdomainaccess);

                Element policy = d.createElement("policy");

                crossdomainaccess.appendChild(policy);

                Element allowfrom = d.createElement("allow-from");

                allowfrom.setAttribute("http-request-headers","*");

                Element domain = d.createElement("domain");

                domain.setAttribute("uri", "*");

                allowfrom.appendChild(domain);

                Element grantto = d.createElement("grant-to");

                Element resource = d.createElement("resource");

                resource.setAttribute("include-subpaths","true");

                resource.setAttribute("path", "/");

                grantto.appendChild(resource);

                policy.appendChild(allowfrom);

                policy.appendChild(grantto);

                d.normalizeDocument();

                // Returns the XML representation of this document.

                return representation;

             } catch (IOException e) {

                e.printStackTrace();

          return null;

- Ronny Kwon

How-To : Silverlight accessing Java REST services (Part 2 – No Cross Domain : Tomcat/Eclipse)

Steve SFARTZ — Wed, 06 Aug 2008 11:43:00 GMT

The HowTo serie demoes Silverlight accessing Web Services in various configuration. In this post, we will demonstrate a REST service consumed by a Silverlight client application where the Site of Origin hosts the Web Services. This scenario is categorized as a D2D scenario without cross-domain policy.

The XAP package, the REST service Eclipse project and the Silverlight Eclipse project are available as an attachment to this post.

Technical Environment

REST services are built with the Restlet framework and hosted in Tomcat
The Silverlight application is also hosted in Tomcat

Because the Site Of Origin and the Web Services reside in the same host, no Cross Domain policy is required.

To successfully install the technical environment, please take the following step :

Build the scenario detailled in HowTo : Silverlight accessing Java REST services (Part 1 - Cross Domain : IIS + Tomcat)

If you don’t feel like doing the previous step, the XAP package available as an attachment contains a Silverlight client which is configured to access a REST service at http://localhost:8080/Restlet-servletfirstResource/items.

The REST service is also available as an attachment to this post allows to do a GET and POST method to get a list of items or to insert a new one.

Download the attachment and unzip it. There are two needed parts : the Silverlight XAP package and the Restlet Eclipse project.

Host the REST service with Tomcat

Import the Reslet-servletfirstResource project into your Eclipse workspace :

go to File –> Import
Then chose General—>Existing Projects into Workspace
Select the root directory, Browse to the Restlet-servletfirstResource folder, then click on Finish. The Restlet-servletfirstResource has now been imported into your workspace

Run the project on Tomcat Server. check that http://localhost:8080/Restlet-servletfirstResource/items is accessible you should get the following result :

Host the Silverlight application in an Eclipse project running on Tomcat

Create a new Dynamic Web Project

Press Ctrl+n to go to the New Wizard Project, under Web select Dynamic Web Project.
Call it REST-SilverlightClient and ensure that the Target Runtime is set to Apache Tomcat 6.0
If Eclipse prompts you to switch to J2EE perspective, accept it.

In the REST-SilverlightClient project, create the WebContent\ClientBin folder and copy the XAP package into it.
Now we need to host it through an Active X control :

Right click on WebContent folder and select New—>JSP, call it index
Edit index.jsp, in the Head part put the following script that catches Silverlight Error.

 <script type="text/javascript">

     function onSilverlightError(sender, args) {

         var appSource = "";

         if (sender != null && sender != 0) {

             appSource = sender.getHost().Source;

         var errorType = args.ErrorType;

         var iErrorCode = args.ErrorCode;

         var errMsg = "Unhandled Error in Silverlight 2 Application " +  appSource + "\n" ;

         errMsg += "Code: "+ iErrorCode + "    \n";

         errMsg += "Category: " + errorType + "       \n";

         errMsg += "Message: " + args.ErrorMessage + "     \n";

         if (errorType == "ParserError")

             errMsg += "File: " + args.xamlFile + "     \n";

             errMsg += "Line: " + args.lineNumber + "     \n";

             errMsg += "Position: " + args.charPosition + "     \n";

         else if (errorType == "RuntimeError")

             if (args.lineNumber != 0)

                 errMsg += "Line: " + args.lineNumber + "     \n";

                 errMsg += "Position: " +  args.charPosition + "     \n";

             errMsg += "MethodName: " + args.methodName + "     \n";

         throw new Error(errMsg);

 </script>

In the Body part, instantiate a Silverlight control by adding the following HTML code, ensure that the param named “source” has is value set to the XAP package URI relative to index.jsp Web Page:

<div id="silverlightControlHost">

    <object data="data:application/x-silverlight,"

            type="application/x-silverlight-2-b2"

            width="100%" height="100%">

        <param     name="source" value="ClientBin/REST-JavaServiceItem.xap"/>

        <param     name="onerror" value="onSilverlightError" />

        <param     name="background" value="white" />

        <a     href="http://go.microsoft.com/fwlink/?LinkID=115261"

            style="text-decoration: none;">

               <img src="http://go.microsoft.com/fwlink/?LinkId=108181"

                 alt="Get Microsoft Silverlight"

                 style="border-style: none"/>

        </a>

    </object>

    <iframe style='visibility:hidden;height:0;width:0;border:0px'></iframe>

</div>

Run the project on Tomcat Server and the Silverlight control will appear in the Eclipse Web Browser :

The great thing about that is that you will be able to test your REST Service and the Silverlight application without running multiple Development Environments.

- Ronny Kwon

How-To : Silverlight accessing Java SOAP services (Part 1 – Cross Domain : IIS + Tomcat)

Steve SFARTZ — Mon, 04 Aug 2008 18:35:00 GMT

The How-To series demo Silverlight accessing Web Services in various configuration. In this post, we will demonstrate a SOAP service consumed by a Silverlight client application. This scenario can be categorized as a D2D scenario with a cross domain policy.

Both the Silverlight and SOAP service are available as an attachment to this post. Since Metro libraries are too large, you will need to copy all jar files from metro\lib\ folder into WebContent\WEB-INF\lib project folder. Steps are described below.

Technical environment

SOAP services are built with JAX-WS and JAX-B APIs and hosted in Tomcat.
The Silverlight application is hosted under the Visual Studio embedded Web Server code name “Catalina” (which delivers a subset of the IIS capabilities)

Requirement

For this How-To, we use the Metro framework which contains both JAX-WS and JAX-B APIs which will be used to develop SOAP Services in JAVA.

Configuring Tomcat

Download the jar file from https://metro.dev.java.net/1.2/ and launch it. A “metro” folder has been created at the jar location. metro\lib folder contains all the needed libraries for the Java SOAP service development and Tomcat configuration. Here is a good link that describes how to configure your Tomcat server http://blogs.sun.com/arungupta/entry/metro_on_tomcat_6_x

Implementing the SOAP / RPC service

In Eclipse, create a new Dynamic Web Project called “SOAP-SumService”
copy all jar files from metro\lib\ folder into WebContent\WEB-INF\lib project folder.
Create a package called “service” and add a new Java class called “ServiceSumImpl” to this package.
Add a xml file to WebContent\WEB-INF called “sun-jaxws.xml”.

Your project structure now looks like this :

Implementation of the Web Service endpoint

In ServiceSumImpl.java, import the following libraries :

Declare the class as a Web Service endpoint with the following annotations, for more informations about annotations refer to this site.

The only method that our service exposes is getSum. It returns the sum of two integers. But we want this method to be known over the service as “SumTwoInt”. Within the annotations we can configure all these parameters.

Now build the project to generate the bytecode as the WSGen tool need it.

Generation of the required artifacts for the Web Service deployment and invocation

For this step, Metro provides a generation tool called “wsgen”.

Open a Windows Command Prompt : Start->Run and type “cmd”
set a METRO as a path variable to metro\bin folder (in our case it is C:\metro\bin path)

Go to your build project folder (by default in Eclipse: ProjectName\build\classes). In our example it is the SOAP-SumService\build\classes folder

Type the following command line to generates the artifacts in the project “src” folder.

%METRO%\wsgen –cp . service.ServiceSumImpl –s ../../src

Refresh the Project Explorer and observes that two java files have been generated

They represent the message that will be shared in the Web Service process

Configuring the Web Service Deployment

To configure the deployment, we need to instantiate a Servlet that will handles JAX-WS Web Services requests.

In web.xml, add a Servlet element. We use a pre-existing Web Service Servlet :

<servlet>

    <servlet-name>jaxservlet</servlet-name>

    <servlet-class>

        com.sun.xml.ws.transport.http.servlet.WSServlet

    </servlet-class>

    <load-on-startup>1</load-on-startup>

</servlet>

This servlet will handle every requests on /services/* URI, so let’s map to it with its name:

<servlet-mapping>

    <servlet-name>jaxservlet</servlet-name>

    <url-pattern>/services/*</url-pattern>

</servlet-mapping>

To provide the right context, we need a listener (which also already exists):

<listener>

    <listener-class>

        com.sun.xml.ws.transport.http.servlet.WSServletContextListener

    </listener-class>

</listener>

Finally, we need to expose the endpoint ServiceSumImpl within an URI, for example /services/sum.

Edit the sun-jaxws.xml file and add the following elements :

<?xml version="1.0" encoding="UTF-8"?>

<endpoints xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime" version="2.0">

    <endpoint

        name="sum"

        implementation="service.ServiceSumImpl"

        url-pattern="/services/sum"/>

</endpoints>

Save all files, then Run the project on the Tomcat Server
Right click on the project node : Run As –> Run on Server

The service is now hosted on Tomcat at http://localhost:8080/SOAP-SumService/services/sum?wsdl

Enabling Cross Domain Access

Since the SOAP service and the Silverlight application reside on different hosts, we need to overpass the Cross Domain Issue. Create at the root of the SOAP service host, a clientaccesspolicy.xml file with the following content :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<access-policy>

    <cross-domain-access>

        <policy>

            <allow-from http-request-headers="*">

                <domain uri="*"/>

            </allow-from>

            <grant-to>

                <resource include-subpaths="true" path="/"/>

            </grant-to>

        </policy>

    </cross-domain-access>

</access-policy>

Consuming a SOAP service with Silverlight

Now that the Web Service is exposed, we are going to generate the client proxy to consume the Web Service with Silverlight.

Open Visual Studio 2008 and create a new Silverlight Project called SOAP-Sum and paste the following XAML code in Page.xaml to obtain a simple interface that will manipulate the web service.

<UserControl x:Class="SOAP_Sum.Page"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Width="400" Height="300">

    <Canvas x:Name="LayoutRoot" Background="White">

        <TextBox Text="0" x:Name="_int1" Width="50" Height="20"

                          Canvas.Top="10" Canvas.Left="30" TextChanged="_TextChanged"/>

        <TextBlock Canvas.Top="10" Canvas.Left="95" Text="+"/>

        <TextBox Text="0" x:Name="_int2" Width="50" Height="20"

                          Canvas.Top="10" Canvas.Left="120" TextChanged="_TextChanged"/>

        <TextBlock Canvas.Top="10" Canvas.Left="175" Text="="/>

        <TextBlock x:Name="_result" Canvas.Top="10" Canvas.Left="190" Text=""/>

    </Canvas>

</UserControl>

Add a Service Reference
Right click on References then chose Add a Service Reference

In Address field, type the Sum service address then click Go (it should be http://localhost:8080/SOAP-SumService/services/sum?wsdl).

We actually have the Sum service named ServiceSum and one operation exposed as SumTwoInt, this is exactly what we did parameter in “Implementation of the Web Service endpoint” (see above)

In Namespace field, type ServiceSum : this is how the service will be accessible through the Silverlight project. Click OK. In the Solution Explorer you see the ServiceSum reference in Service References.

Implementation of the client proxy

In Page.xaml.cs, add an import to SOAP-Sum.ServiceSum reference library.

   1:  using SOAP_Sum.ServiceSum;

Now we need to handle the TextChanged event in _TextChanged method :

Instantiate a client proxy
```
ServiceSumClient client = new ServiceSumClient();
```
Add an event handler corresponding to the operation we are going to use so we can get the result
```
client.SumTwoIntCompleted += 
```
```
   new EventHandler<SumTwoIntCompletedEventArgs>
```
```
      (
```
```
         client_SumTwoIntCompleted
```
```
      );
```
Use Async operation to send our two integers.
Operations are made asynchronous so Silverlight UI won’t freeze
```
client.SumTwoIntAsync(a,b);
```

The whole method looks like this :

   1:  private void _TextChanged(object sender, TextChangedEventArgs e)

   2:  {

   3:      // check if fields contain some text

   4:      if (_int1.Text == "" || _int2.Text == "") return;

5:

   6:      int a = int.Parse(_int1.Text);

   7:      int b = int.Parse(_int2.Text);

8:

   9:      // generate a client proxy to the Web Service

  10:      ServiceSumClient client = new ServiceSumClient();

  11:      client.SumTwoIntCompleted += new EventHandler<SumTwoIntCompletedEventArgs>(client_SumTwoIntCompleted);

  12:      client.SumTwoIntAsync(a,b);

  13:  }

Then we can process the result in the event handler

void client_SumTwoIntCompleted(object sender, SumTwoIntCompletedEventArgs e)

    _result.Text = e.Result.ToString();

Run the project and type some integers in the text boxes : Silverlight is consuming a JAX-WS SOAP service.

- Ronny Kwon

How-To : Silverlight accessing Java REST services (Part 1 - Cross Domain : IIS + Tomcat)

Steve SFARTZ — Wed, 30 Jul 2008 15:42:00 GMT

The HowTo serie demoes Silverlight accessing Web Services in various configurations. In this post, we will demonstrate a REST service consumed by HTTP GET and POST requests issued from a Silverlight client application. This scenario can be categorized as a D2D scenario with a cross domain policy.

The Silverlight example described below is available as an attachment to this post.

Technical environment

REST services are built with Restlet and hosted in Tomcat
The Silverlight application is hosted under the Visual Studio embedded Web Server code name "Catalina" (which delivers a subset of the IIS capabilities)

Because the Site of Origin and the Web Services reside in different hosts, a Cross Domain policy is required at the Services host’s root (/clientaccesspolicy.xml">http://<serviceshostname:port>/clientaccesspolicy.xml)

Implementation of the REST service

To get an overview of the Restlet framework, complete the tutorials : First Steps and First Resource.

Service development with Restlet can be summarized as follow :

The Application class is the entry point to the Restlet service. It binds a URI to a specific Resource.
The Resource class describes how the service behaves on a specific URI invokation.

After completing the tutorials above, deploy the firstResource service as a Servlet hosted by Tomcat.

Invoke the Restlet service with the URI http://localhost:8080/Restlet-servletfirstResource/items. Assuming that Tomcat is running on port 8080 and that your Restlet project name is Restlet-servletfirstResource, you get the following response :

  <?xml version="1.0" encoding="UTF-8" standalone="no" ?>

  <items>

     <item>

        <name>item1</name>

        <description>description of item1</description>

     </item>

   </items>

Enabling Cross Domain Access

Since the REST service and the Silverlight application are hosted in different hosts, we need to overpass the Cross Domain Issue. Create at the root of the REST service host, a clientaccesspolicy.xml file with the following content :

<?xml version="1.0" encoding="UTF-8"?>

<access-policy>

    <cross-domain-access>

        <policy>

            <allow-from http-request-headers="*">

                <domain uri="*"/>

            </allow-from>

            <grant-to>

                <resource include-subpaths="true" path="/"/>

            </grant-to>

        </policy>

    </cross-domain-access>

</access-policy>

Consuming a REST service with Silverlight (GET method)

We chose the WebClient API to request the REST service, and LINQ to process the XML response. XmlReader is another parsing option, and Serialization (Xml or DataContract) is another one.

Invocation of the REST service

First of all, in your UserControl, declare a MyItem class that will map the XML response elements.

   1:  public class MyItem

   2:  {

   3:      public string myName { get; set; }

   4:      public string myDescription { get; set; }

   5:  }

   1:  // List of Items

   2:  IEnumerable<MyItem> Items = null;

Now, let's send a HTTP GET method request to /items URI so we can retrieve every items

   1:  private void getAction()

   2:  {

   3:      WebClient webclient = new WebClient();

   4:      webclient.DownloadStringCompleted +=

   5:        new DownloadStringCompletedEventHandler(client_DownloadStringCompleted);

   6:      webclient.DownloadStringAsync(new Uri("http://localhost:8080/Restlet-servletfirstResource/items"));

   7:  }

Processing the XML results

Let’s process the results using LINQ support for XML :

   1:  void client_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)

   2:  {

   3:      if (e.Error == null)

   4:      {

   5:          XDocument xmlItems = XDocument.Parse(e.Result);

   6:          // use LINQ to XML to parse the response

   7:          Items = from child in xmlItems.Element("items").Descendants().ToList()

   8:                  // restrict the selection to item children

   9:                  where child.Name.LocalName=="item"

  10:                  select new MyItem

  11:                      {

  12:                          myName = (string)child.Element("name"),

  13:                          myDescription = (string) child.Element("description")

  14:                      };

  15:      }

  16:  }

Sending Data to a REST service with Silverlight (POST method)

Use the WebClient to send a HTTP POST request to the /items URI, by adding two parameters : name = "Foo" and description = "Bar" :

   1:  private void postWebClient()

   2:  {

   3:      WebClient webclient = new WebClient();

   4:      webclient.UploadStringAsync(

   7:        new Uri("http://localhost:8080/Restlet-servletfirstResource/items"),

   8:        "name=Foo&description=Bar"

   9:      );

  10:  }

Warning : Notice that if you try to hit the same URI several time with the HTTP GET method, the results do not get refreshed but remain the same. Further explanations about this caching issue are available here.

- Ronny Kwon

D2D scenario : Developer Environment

Steve SFARTZ — Mon, 28 Jul 2008 17:17:00 GMT

This scenario is typically used in development phase when you are building a Silverlight rich client that connects to new business Logic. It is mandatory that the business logic is new to ensure you have enough control to enforce a configuration where the Site Of Origin and the Services Host reside on the same node. If you face a configuration where you need to interface with Business Logic exposed by existing Web Services from a distinct node or requiring protocol adaptation, turn to the B2E scenario.

As listed in Silverlight scenarios for Rich Internet Applications, the following constraints apply to the Developer Environment scenario :

No infrastructure security constraints since this is a dev/test env (No HTTPS, no DMZ)
No protocol adaptation is necessary as we develop brand new services here (ie, messages format & exchange protocol correspond to the Silverlight client capabilities, they can be directly consumed)
Authentication & authorization may need to be handled if required at production/deployment time : this point is covered in the B2E scenario.
A cross domain security file is needed if the Site Of Origin does not host the Web Services, as in interoperability scenarios where the Site of Origin and the Web Services rely on two different technologies.

We plan to experiment the following configurations :

SOAP/ RPC style (operation oriented)
1. Mixed configuration : IIS for Site of Origin + Tomcat and JAVA-WS for Web Services
  - with a cross-domain policy
  - or by servicing Web services request from IIS through the Tomcat connector for IIS
2. Full Java configuration : Tomcat for Site of Origin + JAVA-WS for Web Services
3. Full Windows configuration : IIS for Site or Origin + WCF services (SOAP style) for Web Services
  - with a cross-domain policy
  - or with the IIS built-in integration of WCF services through SVC resources
XML/ REST style (resource oriented)
1. Mixed configuration : IIS for Site of Origin + Tomcat and the Restlet framework for Web Services
  - with a cross-domain policy
  - or by servicing Web services request from IIS through the Tomcat connector for IIS
2. Full Java configuration : Tomcat for Site of Origin + Restlet for Web Services
3. Full Windows configuration : IIS for Site of Origin + WCF services (REST style) for Web Services

Silverlight scenarios for Rich Internet Applications

Steve SFARTZ — Mon, 28 Jul 2008 15:56:00 GMT

From the architecture described in the previous post a cup of Silverlight, a drop of Architecture, you may experience several technical requirements :

Infrastructure Security
- DMZ (if the application is internet facing),
- Secured transport (HTTPS) if private communication has to be enforced (Mandatory in B2B and B2C environments)
Application Security
- Authentication may be Form, Windows or Claim based depending on the consumer (employees, subcontractors, partners or customers)
- Authorization may be role based from various repositories (Active Directory, Claims, SQL Database)
Application Topology
- The consumed Web Services are likely to be hosted on a distinct node in case of re-use or interop scenario.
- In new project development scenario, the Site of Origin may also host the Web Services.
Services Gateway and Protocols Adaptation
- The consumed Web Services may not be directly accessible due to security topology (ie, requires some kind of Gateway, Reverse Proxy)
- In case of Web Services re-use, they are likely to be exposed through protocols and/or formats incompatible with the Silverlight WCF client capabilities (ie, requires some kind of Mediation, Adaptation)

To comply with these Real World variants, we propose to categorize Silverlight Rich Client Applications into scenarios that you 'll may mix to conform to your requirements.

D2D (Developer To Developer) - Development Env

B2E (Business To Employee) - Silverlight App on an Intranet, eventually consuming pre-existing Web Services

B2B (Business to Business) - Silverlight App delivered to partners, consuming pre-existing Web Services with federated security enforcement

B2C (Business to Consumer) - Silverlight App delivered to customers, eventually consuming pre-existing Web Services with form based security enforcement

In future posts, we discuss the architecture and an implementation sample with interoperability in mind.