InfoQ Homepage Articles Silverlight and Java Interoperability

Silverlight and Java Interoperability

This item in japanese

Bookmarks

Aug 05, 2008 20 min read

Write for InfoQ

Feed your curiosity. Help 550k+ global
senior developers
each month stay ahead.Get in touch

Introduction

Abstract

For those in the Java community interested in incorporating Silverlight in their solutions, this paper provides useful information to help then get started. Microsoft Silverlight is a cross-browser, cross-platform, and cross-device browser plug-in designed to help deliver next generation media experiences and rich interactive applications for the Web. Included is background on Silverlight to provide context on interoperability scenarios covering: the basic Silverlight features, Silverlight development concepts, how Silverlight is well positioned for creating rich internet, media enabled, “reach” applications and the Silverlight architecture including its benefits and constraints.

Three Silverlight-Java interoperability scenarios: SOAP web service, REST web service and Syndication (RSS) feed service are reviewed. The SOAP web service and REST web service are created using tools currently available in NetBeans. A review of each interoperability scenario, along with demonstration code, includes some thoughts on where the interoperability scenario may be best used. Note that Silverlight also works with sockets, a more complex, less common interoperability scenario, which may be the subject of a future paper. The paper concludes with a review of Silverlight- Java interoperability for Silverlight 2 Beta 2 as well as some architectural guidance.

Scope

This document focuses on Java-Silverlight interoperability using Visual Studio to create a Silverlight application, enabling the developer to utilize the following interoperability scenarios:

SOAP web service interoperability
REST service interoperability
Syndication (RSS) service interoperability

Silverlight also works with sockets, a much more complex interoperability scenario, which is not in the scope of this document.

Goals

Provide the Java community with options for implementing basic Silverlight-Java service interoperability.

Objectives

The reader will have a reasonable understanding what Silverlight is and where it may be used.
The reader will have a good basic understanding of the Silverlight architecture including its benefits and constraints.
The reader will have useful guidance to the as to how a Silverlight client can interoperate with Java services using the three basic service interoperability scenarios mentioned in the Scope section above.

Introducing Silverlight

Microsoft Silverlight is a cross-browser, cross-platform, and cross-device browser plug-in that delivers media experiences and rich interactive applications for the Web. Silverlight targets “reach” scenarios where rich internet applications can be quickly deployed to browser clients the internet. “ Silverlight is designed for Web page content that is connected to its host, that deeply engages the user, and that can render on any browser. Scenarios for Using Silverlight

There is improvement in Application Development Life Cycle (ADLC) productivity through the separation of the user interface design and the logic concerns. By using Microsoft Expression and Microsoft Visual Studio, user interface designers and developers can collaborate more effectively using the skills they have today.

Extensible Application Markup Language (XAML), a declarative, XML-based language with flow control support, is the language used for user interface design. .NET languages such as VB.NET, C#, IronRuby and IronPython are be used to program the logic behind the user interface. Both the Windows Presentation Foundation (WPF) and Silverlight use XAML.

The Silverlight runtime is the base of the Silverlight architecture. Silverlight 2 Beta 2 has a onetime 4.6 MB download that plugs into the Internet Explorer, Firefox, Opera and Safari browsers. A zip formatted ‘.xap’ file is the deployment package for a Silverlight application. The ‘.xap’ package contains the application and entry point for the Silverlight plug-in control to run. The ‘.xap’ file is developed in Visual Studio .NET; every time there is a build, Silverlight updates the ‘.xap’ file on the client. The Silverlight application (‘.xap’ file package) is deployable from any web server.

Figure 1: Silverlight in Web Browser Sandbox

The Silverlight control is contained within an HTML page, which in turn is contained within the web browser sandbox. The MSDN technical article on Silverlight Architecture Overview gives a high level over view of the Silverlight architecture, explains the positioning of Silverlight in the Microsoft User Experience (UX) continuum, an reviews Silverlight deployment and packaging. It is important to note that .NET installation is not required on any client machine for Silverlight to run. All that is required to run a Silverlight application is contained within the Silverlight browser plug-in. The interoperability scenarios are on Silverlight 2 Beta 2. The new features of Silverlight 2 Beta 2 are:

Framework languages (Visual Basic.NET, C#, IronPython, IronRuby)
Isolated Storage
JSON, REST, SOAP/WS-I, POX, and RSS Web Services (as well as support for Sockets)
WCF support
ADO.NET Data Services
LINQ to Objects and LINQ to XML
Deep Zoom technology
XML programming
Media content protection
Rich managed control framework
New set of controls to improve developer productivity (Checkbox Cross Domain Network Access
LINQ to Objects
StackPanel, Grid and Panel Layout Support
Managed Control Framework
Full suite of Controls (TextBox, RadioButton, Slider, Calendar, DatePicker, DataGrid, ListBox, TabControl, and others)
Deep Zoom Technology
Managed HTML Bridge
Managed Exception Handling
Media - Content Protection
Rich Core Framework (e.g. Generics, collections)
Security Enforcement
Type Safety Verification
XMLReader/Writer

The Silverlight Web Services team blog, Detailed Overview of Silverlight 2 Beta 2 Web Service Features, gives an excellent web service background for Silverlight 2 Beta 2. Currently Silverlight does not have WS-* support beyond WS-I Basic Profile.

Figure 2: Silverlight Architecture Service Interoperability

Both Java Script and the .NET runtime code communicate to the Silverlight plug-in through events and method calls. The Silverlight control can communicate with the HTML page and its contents through JavaScript. The MSDN page Silverlight Programming Models (Silverlight 2) explains the Silverlight object model fits within the web page (DOM object model).

Resource binding and data binding occur in XAML (Page.xaml) through references to code in (Page.xaml.cs). The Silverlight plug-in renders the XAML on the user interface.

The event model in Silverlight is asynchronous -the asynchronous model should be embraced to effectively use Silverlight. There is a common User Interface (UI) thread for the entire browser, if the UI thread is ever blocked the whole browser may become unresponsive. A background thread can perform network calls or execute any other code that may otherwise block the UI thread.

Security

Authentication

Since Silverlight is a browser plug in it relies on the security provided by the browser. The majority of authentication scenarios should work with HTTPS and Basic Authentication. HTTPS is the Secure Socket Layer (SSL) protocol which provides authentication and communication security. Using HTTPS should mitigate spoofing and the threat of exposing sensitive information through the transport layer (Security Considerations for Service Access).

In-message authentication, such as embedding authentication info in 1) the URI or 2) the message body e.g. the SOAP Header, is an alternative authentication approach.


     
       MyName
       MyPassword

Figure 3: SOAP Header Authentication

WS-*

WS-* scenarios are being considered for future releases of Silverlight.

URL Access Restrictions

Silverlight prevents networking threats by restricting access of three classes of URLs: Cross-scheme URL, Cross-domain URL and Cross-zone URL URL Access Restrictions in Silverlight 2

Transport Layer Security

Silverlight 2 Beta 2 supports HTTP and HTTPS URI schemes. There is very limited HTTPS and cross-scheme support in Silverlight 2 Beta 2 there should be full support for HTTPS cross-scheme support in the Silverlight 2 RTM.

Figure 4: HTTPS support in Silverlight 2 Beta 2

For SOAP services used with generated proxies, configuration for HTTP and HTTPS is in the ServiceReference.ClientConfig file. The security mode element is set to “Transport” for HTTPS or “None” for HTTP.

Figure 5: Setting the security mode

Silverlight and .NET Framework

The .NET Framework for Silverlight namespaces are a subset of the .NET Framework namespace, the inclusion of these namespaces balances the utility of any given .NET assembly against the cost in terms of size of including it in the Silverlight runtime.

Silverlight 2 Beta 2 supports both XML and Java Object Serial Notation (JSON) formats. (Working with JSON Data in Silverlight?, How to: Serialize and Deserialize JSON Data)

Browser Limitations

Silverlight is a cross-browser plug-in. Much of the functionality in Silverlight is dependent on, and limited by the functionality of all of the browsers supported by Silverlight. For instance, since some of these browsers do not support PUT and DELETE HTTP methods, Silverlight does not support the PUT and DELETE HTTP methods. In other words, many limitations are really limitations of “broad browser support” not specifically a Silverlight limitation.

Other browser limitations include:

Limitations that occur only in cross-domain scenarios, for instance custom GET headers cannot be created for cross-domain requests and
Response headers other than Content-Type cannot be read.

Service Interoperability Scenarios

The service interoperability scenarios are simple “proof points” that show how the various scenarios work with “real-world” implementations.

The first step to get up and running on Silverlight is to go to the Silverlight Get Started page. These scenarios were developed on NetBeans 6.1 and Visual Studio 2008. Refer to Get Started Building Silverlight 2 Applications to see how to configure Visual Studio to support the latest release of Silverlight.

Cross Domain Scenarios

Since domain boundaries are crossed in these scenarios the Silverlight ‘clientaccesspolicy.xml’ file is in the document root directory of the Java web server to make the service available (by opting-in).

To prevent cross domain threats Silverlight allows only domain-of-origin communication for all requests other that images and media unless the service host of the other domain enables an opt-in policy file. The opt-in files are: 1) the Silverlight ‘clientaccesspolicy.xml’ which may be used to grant fine grain access to the service or2) the Adobe ‘crossdomain.xml’. The Silverlight client checks first for ‘clientaccesspolicy.xml’, then for ‘crossdomain.xml’. If neither is found, a “404 Not Found” HTTP standard response code is returned. Tim Heur has an in depth explanation of cross-domain services in: Silverlight cross domain services and a helpful tool.

It is important to note that the policy flies (‘clientaccesspolicy.xml’ and ‘crossdomain.xml’) need to specifically enable SOAP by allowing either 1) all headers or 2) the Content-Type and SOAPAction headers.

Access to documents originating from any domain may be permitted by entering domain="*" or access to documents originating from specific domain(s) may be permitted e.g. domain="*.microsoft.com". The Silverlight Policy file format description is available: Network Security Access Restrictions in Silverlight 2. A sample crossdomain.xml file is available at “Make a Service Available Across Domain Boundaries”. Note that for all of the service scenarios in this paper, clientaccesspolicy.xml or crossdomain.xml must be at the root of the domain.

Figure 6: http://localhost:8081/clientaccesspolicy.xml

REST Service Scenario

REST (REpresentational State Transfer), a concept first put forth by Roy Thomas Fielding in his doctoral dissertation in 2000. Its growing popularity is in its simplicity and its familiarity -the World Wide Web has a REST architecture. Principles REST is based on:

Every resource has a resource identifier
Representations (methods) are standard
Resources may have multiple representations
Connectors encapsulate resource access and transfer activities, connector types are: client, server, cache, resolver and tunnel
REST interactions are stateless

The simplicity and familiarity of REST contribute to its growing popularity. A simple way of thinking of REST is: the state of a resource is changed by operating on a URI.

The “Pure REST” ideology encompasses the idea that 1) everything is represented as a resource with an address and 2) only four operations are needed to work with resources: create, read, update and delete.

The “REST-to-HTTP mapping” camp, the way many people view REST, is the same as “Pure REST” but the addresses are URIs and the four operations are HTTP methods: GET, PUT, POST and DELETE.

When a POX service does not follow the “Pure REST” architecture this approach is sometimes referred to as “low REST”. There may be multiple custom operations instead of the standard four operations. A custom operation is a URL parameter on a POST HTTP method rather than utilizing a specific HTTP method for the operation.

Though REST is simple to develop and maintain it does not handle message security, transactions, routing and messaging; this is more the domain of WS_I SOAP web services. SOAP web services in Silverlight do not handle message security, transactions, routing and messaging either. Silverlight does not automatically generate REST proxies in the same manner it can automatically generate SOAP proxies.

HTTP Methods

Most REST implementations use the following HTTP methods that operate on the underlying resource with Create, Read, Update, Delete (CRUD) operations.

Figure 7: HTTP Methods

Silverlight supports only the GET and POST HTTP methods. Some firewalls restrict the use of PUT and DELETE HTTP methods.

It is important to point out that true RESTful service can be created (conforming to all the REST principles listed above) only using the GET and POST HTTP methods, in other words the REST architecture does not require a specific mapping to HTTP. Google’s GData X-Http-Method-Override header is an example of this approach.

The following HTTP methods overrides may be set in the header to accomplish the PUT and DELETE actions if the web services interpret the X-HTTP-Method-Override header on a POST:

X-HTTP-Method-Override: PUT
X-HTTP-Method-Override: DELETE

Another approach to work around the browser limitation of not supporting the PUT and DELETE HTTP methods is to use Asynchronous JavaScript and XML (AJAX) on the HTML page that hosts the Silverlight control. The use of XMLHttpRequest in JavaScript events could send the right HTTP method at the right time through an HTML Bridge. The MSDN article HTML Bridge: Interaction Between HTML and Managed Code indicates how this can be accomplished. This technique works only if the HTML page, the ‘.xap’ and the service endpoint are all in the same domain.

REST Schema Definition WADL and XSD

One limitation of REST is that schemas are unknown and may change; there is not contract to validate the REST service against.

The Web Application Development Language (WADL) is an alternative to WSDL that specifically supports RESTful web services. WADL is not yet widely adopted.

An XML Schema Definition (XSD) may be utilized as a “contract” for any given resource in REST service.

Java REST Support

A number of tools, frameworks and IDEs support the development of RESTful services. The NetBeans Java IDE is fully integrated for: 1) automatic REST service generation from entities and 2) integrated REST service testing (NetBeans Getting Started with RESTful Web Services on GlassFish) The Eclipse IDE also supports the development of REST services (Eclipse REST support in STP). JSR 311, the Java API for RESTful Web Services) currently supports PUT and DELETE HTTP methods. Jersey is an open source reference implementation that is tracking JSR 311.

Silverlight .NET REST Support

Silverlight can support REST through:

The WebClient class (using the DownloadStringCompleted (GET) and UploadStringAsync and UploadStringAsync (POST) methods, for example), or the HttpWebRequest class (harder to use but enables some more advanced scenarios). The simple and straightforward WebClient class approach was used in this scenario.
Using the HTML Bridge mentioned above
Through AJAX either through JavaScript and the XMLHTTP object or an AJAX toolkit

There are various techniques may to create the request URI. To work with XML message bodies (“POX” services), use either the XmlSerializer or LINQ-to-Xml (System.Xml.Linq). To work with JSON message bodies, use the DataContractJsonSerializer or LINQ-to-JSON (System.Json). The LINQ techniques enable rapid ad-hoc consumption. To work with RSS/Atom message bodies, see below.

Figure 8: REST Interoperability Architecture

This REST scenario shows how a current Java REST implementation can work with Silverlight and what the limitations are for that particular interoperability scenario. NetBeans 6.1 has the ability to create “RESTful web services from Entity Classes” out-of-the-box. A simple REST services created in NetBeans accesses a table (resource) in a database. The table DiscountCodes has a DiscountCode string field and a Rate integer field.

Figure 9: DiscountCode Table

Summary of REST Actions

Summary of the HTTP methods (REST actions) used in this scenario:

GET: http://localhost:8081/resouces/discountCodes
- returns list of all DiscountCode records
GET: http://localhost:8081/resouces/discountCodes/A/
POST: http://localhost:8081/resouces/discountCodes
- creates a DiscountCode record

Figure 10: POST XML

GET: http://localhost:8081/resouces/discountCodes

The Silverlight application first does a “GET” (DownloadStringCompleted) call on the /resources/discountCodes URI.

Figure 11: GET all discountCodes

The XML is displayed to understand exactly what the response is. Next a single resource is obtained by specifying /A/ in the URI. By viewing the response from the /resources/discountCodes/ URI one can infer the schema of the resource.

GET: http://localhost:8081/resouces/discountCodes/A/

Figure 12: GET resource /A/

POST: http://localhost:8081/resouces/discountCodes

Now a new resource is added by copying the newly obtained /A/ resource and creating a new /D/ resource in the POST textbox.

Figure 13: POST resource /D/

Verify that the resource was added by adding /D/ to the GET URI and pressing the GET button.

Figure 14: GET (verify) resource /D/

WebClient is used to communicate with the Java service in the Get_Xml_Click and Post_Click events. Note that exception handling has been removed for the sake of clarity.

Figure 15: Page.xaml.cs

On the “Get_Click” event, the request sends the contents of the getUri TextBox then the response XML is placed into the TextBox_GET TextBox.

On the “Post_Click” event, the request sends the contents of the postUri TextBox, then the response XML is placed into the TextBox_POST TextBox.

Figure 16: Page.xaml

Since neither the PUT nor DELETE HTTP methods are available in Silverlight this particular REST implementation can neither update nor delete a resource, however a REST implementation utilizing POST for the update and delete actions could be developed (see Silverlight supports o). The article on >Why REST Failed addresses the issue that most browsers do not support PUT and DELETE HTTP methods therefore limiting the adoption of REST on the browser.

Syndication (RSS) Service Scenario

Remote Site Syndication 2.0 (RSS) is a lightweight, publish-subscribe standard that typically subscribes to content such as a blog. Netscape originally developed RSS and today, RSS 2.0 is the de facto RSS standard. The Atom syndication format, has been through the IETF standardization process and has an ITEF RFC describing what an Atom feed is and how it can be parsed. Most syndication sites support both formats.

Silverlight has the System.ServiceModel.Syndication.dll assembly devoted to Syndication. (Silverlight Syndication). Syndication Feeds as well as Syndication Items are Syndication Items are included in this framework. Using Language Integrated Query (LINQ) with RSS or Atom makes parsing out the feed elements a breeze.

This scenario is a “poll” scenario where a client asynchronously accesses the RSS service feed to view updated feed content. A simple Java RSS feed is accessed by a Silverlight client through the feed URI.

Figure 17: Syndication Interoperability Architecture

Since the results are in XML, only three lines of code are required to render the feed result on the Silverlight control.

Figure 18: Syndication (RSS 2.0) reader

The OpenReadCompleted event is used, the response result is put into and XmlReader which in turn is loaded into a SyndicationFeed. The SyndicationFeed is bound to the itemsList control in XAML. Note that error handling has been removed for the sake of clarity.

Figure 19: Page.xaml.cs

Figure 20: Page.xaml

For a good Silverlight Quick Start overview of syndication, refer to Accessing Syndication Feeds with Silverlight and Databinding and the SyndicationFeed class.

SOAP Web Service Scenario

The web services standards, defined by the Web Services Interoperability Organization (WS-I ), are based on Simple Object Access Protocol (SOAP); SOAP is an XML based protocol that allows messages to be passed over HTTP/HTTPS. W3C has a Web Services Architecture document that lays the foundation for SOAP web services. If a Java based SOAP web service already exists, it is straightforward to create a proxy for that web service, then utilize that web service in Visual Studio. One must caution that the use of complex data types in a web service can be problematic, especially in Java-.NET interoperability scenarios. Java SOAP web service data types should map to the .NET supported data types .

Debugging web services can also be problematic. Tools like the Fiddler web debugging proxy or the Web Development Helper can be useful in debugging web services.

Silverlight does not have WS-* support beyond WS-I Basic Profile, “but it is still possible to consume services that use these protocols by manually implementing the required protocol” (Accessing SOAP Services). WS-I Basic Profile 1.0 and SOAP 1.1 over HTTP are supported. Be aware that SOAP faults throw an exception on the client but do not specify information about the fault that occurred.

Silverlight supports the WCF (Windows Communication Foundation) client-side technology, which is able to consume SOAP services subject to certain interoperability constraints. Services that can be consumed are WCF services, ASP.NET Web Services (“.asmx”), as well as some Java services .

The Silverlight Web Services Team blog has a Detailed Overview of Silverlight 2 Beta 2 Web Service Features. The major concerns for Java-Silverlight interoperability using SOAP are: does the proxy compile, and are there any data type or serialization issues with the web service.

Configuration

The configuration support in ServiceReference.ClientConfig allows the change of a binding or an address without recompiling the Silverlight control.

Figure 21: ServiceReference.ClientConfig

Windows Communications Foundation (WCF)

In Silverlight 2 Beta 2 there is “Silverlight-enabled WCF service” template so when a WCF service is added using this template, the service is automatically configured to use protocols supported by Silverlight. BasicHttpBinding utilizes plain SOAP1.1 over HTTP, and is a binding that conforms to the WS-I Basic Profile 1.1. See “Accessing SOAP Services”.

ASMX

“Add Service Reference” creates an ASMX proxy for the service referenced under the Address: label.

Figure 22: Add Service Reference

SOAP Faults

“Receiving SOAP faults is not supported due to Web browser limitations. When the service does send a fault, an exception is thrown on the client, but it does not specify any information about the fault that has occurred.” (Accessing SOAP Services)

Figure 23: SOAP Web Service Interoperability Architecture

A simple web service endpoint in NetBeans has the following methods: findAll and find. Note that exception handling has been removed for the sake of clarity.

Figure 24: Page.xaml.cs

A proxy in Visual Studio references the Java Soap2Service endpoint.

Figure 25: Soap2Service proxy reference

The web service is call passes in a request parameter then receives the web service response. The web service response (String) is bound to the XAML. The XAML is rendered into the user interface by the Silverlight control.

Figure 26: SOAP Web Service -Find All

Figure 27: SOAP Web Service -Find 'B'

The proxy object has a binding and an endpoint. The proxy uses the findAllAsnyc events to send the findAll request and the findAllCompleted event to receive the findAll response. The findAll response is displayed on the findAllResponse TextBox in the XAML. Note that exception handling has been removed for the sake of clarity.

Figure 28: Page.xaml.cs

Figure 29: Page.xaml

The proxy configuration information comes from ServiceReferences.ClientConfig. ServiceReferences.ClientConfig configuration file supports the configuration of multiple endpoints.

Changing the ServiceReferences.ClientConfig configuration file does not require the Silverlight application to be re-built.

Figure 30: ServiceReferences.ClientConfig

Summary

The Silverlight / Java interoperability story is evolving. Simple SOAP web service, REST service and Syndication feed service interoperability work in Silverlight. SOAP web services have potential data serialization issues, only a basic level of WS-I support, and they are inherently more complex, but they are quick to implement once a proxy has been successfully created in the Visual Studio Silverlight client. One must rely on documentation that may be outdated or incorrect when developing a REST service. Existing RESTful implementations that utilize just the GET and POST HTTP methods work best with Silverlight. REST services are a good fit for query type services and SOAP web services are a better fit for CRUD services. Syndication services are simple to implement would have few limitations.

Developers are free to choose whatever interoperability style they choose and they find most appropriate for their particular development and deployment scenarios.

A fundamental concept to understand is that Silverlight runs in the browser context. The cross domain, cross scheme and cross zone issues, limitations on the number of browser connections, support for various MIME types, –are all important considerations in developing and deploying not Silverlight but any application running on the browser platform. When working with browsers, the lowest common denominator is often the benchmark for defining browser limitations.

It is interesting to note that JAXB-style object references will likely be supported in Silverlight 2 RTM, in a similar fashion to the way they will be supported in .NET Framework 3.5 SP1 (DataContractSerializer).