A Cup of Silverlight, RIA & Interoperability : Cross Domain

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

B2C scenario : Customer Environement

Steve SFARTZ — Thu, 31 Jul 2008 17:50:00 GMT

The B2C scenario corresponds to Web applications accessed by customers, traditionnaly built with some dynamic HTML/AJAX technology running on the server side, that have been elected to leverage the Silverlight capabilities (enriched user experience, vector based contents, scaling, rich media…).To comply with the scope of this blog, we’ll concentrate on RIA scenarios, where the customer accesses private data from a Silverlight Client.

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

Infrastructure security is mandatory : it includes a DMZ to protect the Web Server and access to the Web Services and optional SSL/HTTPS communications depending on the confidentiality of the data accessed.
Protocol adaptation is required if the application is interfaced with pre-existing Web Services that cannot be immediatly consumed by Silverlight. This extract work is performed by a mediation layer, materialized in the schema below by the Services Gateway. Moreover, the Services Gateway in the Customer scenario can enforce the alignement of the incoming messages with the entreprise governance policies.
Authentication & authorization is required for Line of Business Applications to secure read and write access to Entreprise Data. Form based authentication would be the preferred way in this scenario. If you need Claim based authentication, take a look at the B2B scenario.
A cross domain security file is required to access the Services Gateway

We plan to document this scenario by extending the “B2E with mediation” scenario, with Form Based Authentication & Authorization constraints. If you have technical requirements not list here, there’s good chance the B2C scenario can be enriched from the B2B scenario.

Cross Domain : Trouble while accessing Web Services

Steve SFARTZ — Thu, 31 Jul 2008 14:56:00 GMT

When Silverlight attempts to access a Web Service, if the SOO is different from the Web Service host, you have to deal with a cross domain issue. This issue can occur in various scenarios as described in Silverlight scenarios for Rich Internet Applications

The issue can be treated as follow :

1. I am encountering a ProtocolException

Reason

Silverlight is attempting to access a Web Service which is across its own domain boundaries. For security reasons, a policy file must exist at the root of the Web Service host. It allows this cross-domain access : it’s either clientaccesspolicy.xml or crossdomain.xml files which were not found by Silverlight.

2. Even if the clientaccesspolicy.xml is found, my Silverlight application access the service

Reason

Indeed, the clientaccesspolicy.xml file is here but is not accepted by the Silverlight application : there is some missing information.

There has been some modifications since Silverlight 2 beta 2 : Ensure that ‘http-request-headers’ attribute is correctly set in ‘allow-from’ element in the clientaccesspolicy.xml file. See below for a basic and working policy file :

<?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>

More information can be found at

http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx

- Ronny Kwon

B2B scenario : Partner Environment

Steve SFARTZ — Thu, 31 Jul 2008 13:10:00 GMT

The B2B scenario corresponds to Enterprise Web Services exposed to a partner through a Rich Client application, traditionnaly built with some dynamic HTML/AJAX technology running on the server side, that have been elected to leverage the Silverlight capabilities (enriched user experience, vector based contents, scaling, rich media…).

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

Infrastructure security is mandatory : it includes a DMZ to protect the Web Server and access to the Web Services and SSL/HTTPS communications to protect the confidential data owned by your enterprise and shared with your partner.
Protocol adaptation is required if the application is interfaced with pre-existing Web Services that cannot be immediatly consumed by Silverlight. This extract work is performed by a mediation layer, materialized in the schema below by the Services Gateway. Moreover, the Services Gateway in the Customer scenario can enforce the alignement of the incoming messages with the entreprise governance policies.
Authentication & authorization is required to secure read and write access to Entreprise Data. Claim based authentication would be the preferred way in this scenario. If you want wish to use Form based authentication, have a look at the B2C scenario.
A cross domain security file is required to access the Services Gateway if not host on the Site of Origin.

We plan to document this scenario by extending the “B2E with mediation” scenario with a Services Gateway (such as Managed Services Engine) and SSL/HTTPS.

B2E scenario : Intranet Environment

Steve SFARTZ — Thu, 31 Jul 2008 12:10:00 GMT

The B2E scenario corresponds to internal Web applications, traditionnaly built with some dynamic HTML/AJAX technology running on the server side, that have been elected to leverage the Silverlight capabilities (enriched user experience, vector based contents, scaling, rich media…).

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

Infrastructure security is optional as we are in a IT governed environment,
Protocol adaptation is required if the application is interfaced with pre-existing Web Services that cannot be immediatly consumed by Silverlight. This extract work is performed by a mediation layer, materialized in the schema below by the Services Gateway .
Authentication & authorization is required for Line of Business Applications to secure read and write access to Entreprise Data. Windows integrated authentication would be the preferred way for an intranet scenario. If you want wish to use Form or Claim based authentication, take a look at the B2B and B2C scenarios.
A cross domain security file is needed if the Services Gateway is implemented or 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 SOAP/RPC and XML/REST configuration in Full Windows, Full Java and Mixt environment.

We’ll also demonstrate how Web Services invoked from Silverlight can leverage the Authentication & Authentication facilities provided by IIS/ASP.NET through interoperabiliy.

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