WSRP 2.0 support in MOSS and Oracle WebCenter

The long-awaited (5-6 years since WSRP 1.1...) approval of the WSRP 2.0 specs have arrived. Microsoft have promised support for it in MOSS 2007, probably by adding an OOTB Web part working as WSRP 2.0 Consumer (the product has a WSRP 1.1 consumer today). No time plan for that work have been communicated though. I have also evaluated Oracle's Webcenter recently and it turns out WebCenter uses WSRP 2.0 for all portlet-to-portal container communication, even in cases where the portlets resides on the same server as the portal container!

. © Copyright 2008, Tomas Elfving

Using the WSRP 1.1 Consumer Web part in MOSS 2007

Having Java/JSP apps too expensive/timecomsuming to migrate to MOSS 2007? Maybe the apps works just fine as is, and the migration adds no business value. Besides IFraming them, the way to go is WSRP. Check out this architecture picture:


Package your existing apps as WSRP producers and use the MOSS OOTB Web part acting act a WSRP 1.1 consumer. Some advice on the way:

1. Keep portlets simple - In general for MOSS and WSRP, if you keep the portlets fairly straightforward, you should not run into problems. If you start to use a lot of script, DOM modification, AJAX calls, etc. then you may run into issues.

2. Start small - I would try a “real” part of the application that includes navigation, form submission, script, user identity, session state and persistent state.

3. Namespacing - Microsoft WSRP implementation is not great. MOSS uses an IFrame to implement it’s WSRP browser side container so you typically do not have to be concerned with namespacing. In fact, you may run into problems if you try and use “wsrp_rewrite” prefix (consumer namespace re-writing). There is a bug in their namespacing. You may need to rely on producer namespacing instead (if you plan on consuming those portlets elsewhere or back in your Java Portal server).

4. Test - Thoroughly test WSRP functionality in MOSS first to uncover issues first.


© Copyright 2008, Tomas Elfving

Java/.NET web service interoperability issue regarding checked exceptions

Using web services as integration technology is an obvious choice when service-orienting your companys IT architecture, especially when having a mixed Java and .NET environment. One strategy many companies choose is to package business logic in Java-based web services while developing web user interfaces on the .NET platform.

The problem

There is one interoperability issue that I'll like to shed some light on, and that is "checked exceptions". Checked exceptions is userdefined exceptions. Java supports this construct whereas C# doesn't. The C# development team have chosen to exclude checked exceptions by design (why? -> pls read the interview with the lead C# architect Anders Hejlsberg at http://www.artima.com/intv/handcuffs.html). This imposes a risk of having unhandled exceptions. A java-based web service may throw checked exceptions that the .NET-based client is unaware of. The .NET client developer needs to manually analysis the WSDL file to see what type of exceptions the web service method may throw. This is a tedious and error-prone way to work compared to the Java/Axis that autogenerates a complete interface including exceptions in object-form on the client side.

The solution

C# doesn't support checked exceptions by design, but Windows Communication Foundation supports automatic analysis of the WSDL-file when creating the proxy on the client (you must use svcutil.exe, not wsdl.exe. Svcutil.exe is default in Visual Studio 2008, but not in 2005. Or run on the command line). Exceptions are serialized in objects that can be analyzed and handled on the client without needing to parse XML-strings for error codes and messages. The exceptions are catched in regular try-catch blocks just as any other .NET Exception. This way, you get type safe userdefined exceptions. You'll also get the "intellisense" in Visual Studio on exception objects.

© Copyright 2008, Tomas Elfving