This is seriously groundbreaking: Clemens (also here) just finished an example of a Metro client accessing Microsoft's BizTalk Services (aka Internet Service Bus). "Well", you might ask, "what is so groundbreaking about this? Isn't this what this whole web services thingy was supposed to achieve? Interoperability?!"

Yes, indeed. However, this is the first time ever (to my knowledge) that Microsoft is releasing JEE code, built with Metro within NetBeans, as part of an SDK. Getting there took quite a while, and was largely enabled by Sun and Microsoft working very closely together in a series of interop-plugfests. The latest installment of these got (especially) WS-Trust interoperability to a point where you can now use the client implementation in Metro to access the STS provided by the .NET Framework.

Congrats to Clemens, but also the Metro team (namely Jiandong and Harold).

tag: Interoperability, WS-Trust, Metro, BizTalk Services

When you are working with Glassfish (like I am doing now), you might need to capture your HTTPS traffic. In an earlier post, I explained how to capture and decrypt any SSL/TLS traffic, as long as you have the server private key.

While this method is quite effective and universal, it is still a little cumbersome, especially since the actual SSL decoder in Wireshark is not yet fully integrated into the analyzer itself.

For Sun's Glassfish application server, there is a fairly simple way to monitor any web services HTTPS traffic:

simply go into the domain.xml file of your domain and add the following <jvm-options>:

<jvm-options>-DWSIT_HOME=${com.sun.aas.installRoot}</jvm-options>
<jvm-options>-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true</jvm-options> <jvm-options>-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true</jvm-options>

The server.log (in <installRoot>/domains/domain1/logs) will then contain the fully assembled web services exchanges.

tag: glassfish, java, wsit, SSL, HTTPS

keytool is a useful utility for dealing with Java keystores, but it has a significant disadvantage: you can not export private keys with a certificate using keytool. Therefore, the only thing you can so is to add the certificate as a trustedCert into the keystore, but not as a keyEntry.

Obviously, this is easily possible through the programmatic interface, but that can be hasslesome at times. At http://couchpotato.net/pkeytool/ you can find a really nice little tool that allows you to extract the private key in a separate file, and then re-import the private key file and the cert into a new keystore.

tag: security, java, keytool

In order to go through some exercise here, I recently needed to create a few Java classes from XSD schema. "Well," I thought, "JAXB with its integrated XJC is your friend!" And so it is, but you might have to dig a little deeper.

The problem I was facing was a schema that had references to WS-Security, XML Encryption and XML Signature. As such, it imported all these schemas from the web using <xsd:import namespace="..." schemaLocation="http://..." />. Since xjc is pretty flexible, accessing these schemas on the web was a charm, even through the firewall. After all, this is much better than downloading all the referenced schemas (and all schemas they reference) and edit the imports to point to the right location in the file system.

Well, not so quick. In their infinite wisdom and foresight, the schema developers at OASIS and W3C decided to use different schema locations for XML Dsig. They reference the same schema (with identical namespace, obviously), but import through different schemaLocation URIs. That confuses xjc to no end, since it detects a re-definition of the same object and gives up.

In order to resolve this problem, you can create an XML Catalog, that allows you to rewrite (or redefine) URLs referenced in you schema. Here is an example:

<?xml version="1.0"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
  <system
      systemId="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"
      uri="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd" />
</catalog>

This simple catalog redefines the URI used by the XML encryption schema to point to the one used by OASIS. The XML Catalog specification provides many more options, and it is good to know that xjc supports this.

While this is quite simple, I found it relatively hard to find concrete examples on how to use this mechanism.

tag: XML Catalog, XML Schema, XSD, JAXB, XJC, Data Binding

Marina Fisher and I will be presenting on AJAX interoperability here at JavaOne on Thursday at 5:30pm in Esplanade 302. We will be covering jMaki, WCF, Silverlight/ASP.NET AJAX and Java REST API interoperability. For more details, go here. 

tag: AJAX, jMaki, Silverlight, Interoperability

Now - here is something quite interesting about Java directions: I was only remotely aware of JSR 277 - Java Modules - and took really no big interest in it. However, this effort might solve some of the self-inflicted problems that I had to deal with regarding OSGi bundles.

JSR 277 (which is currently in early draft) aims at provinding a simple class versioning mechanism that allows some of the features of OSGi bundles. Stanley Ho has written some explanatory material on this JSR - from what I could gather, it should be - at least principally - not too hard for OSGi to deal with Java Modules. Now if we only could get it working the other way round ...

tag: JSR 277, OSGi

David Chappell made some interesting remarks on Java and NetFX during his TechEd session and on his blog. He compares the creation of SCA by IBM, BEA and some others to the creation of the .NET Framework in 2000.

I would put this somewhat differently: .NET in 2000 was a (somewhat late) reaction to the success of the Java platform. As .NET evolved, itwent - essentially - through the same issues as Java: 1.0 was essentially unusuable, 1.1 kinda worked, and 2.0 (or 1.2 in Java) is/was the first truely usable platform. In this sense, SCA is comparable to the announcement of the Longhorn pillars, at best.

In his TechEd session this morning, David was trying to compare SCA with WCF. He noted that while WCF is in its final beta stages, SCA is just starting with the definition. This is certainly true. However, there are other simplifying APIs (such as EJB3, JBI/OpenESB, WSIT) that have a similar architectural scope as WCF and are in final beta as well. I strongly recommend reading the comment section of David's blog article as well, since it contains a lot of interesting pointers.

At this time, most of you have probably heard about the Web Services Interoperability Toolkit for Java (a.k.a. Project Tango), which enables maximal interoperability between the upcoming Windows Communication Foundation on .NET and the Java world. If not, go see http://wsit.dev.java.net/ ASAP.

WSIT will be tightly integrated with the Glassfish Sun Application Server, which also features full FastInoset support. In fact, Glassfish will - based on the HTTP header content type - automatically switch between text+xml and application/fastinfoset.

Now, with the WCF integration that FIFI will deliver, you will be able to configure an Indigo client at deploy time (or even after) to use the by far more efficient FI encoding. And this (re)configuration will only take a change in a single line in the .config file of that client (assuming that you are using a CustomBinding in the first place ).

So, at the end of the day, you can start you deployment of SOAP and RESTful Web Services with angle brackets and as soon as you need a more efficient encoding, you switch to FI by simply setting the right config parameter in the WCF client. Can it be less painful?

You might know that StAX (JSR 173) and the System.Xml.XmlReader/Writer classes are quite similar, at the very least in scope. A very interesting difference (that gave me a lot of grief in porting/implementing these APIs) is the way namespace attributes are being treated.

In StAX, namespace attributes are typically dealt with through different calls than those used for 'normal' attributes. This special treatment also comes with a table, where defined namespaces can be stored and referenced. In .NET, a namespace attribute is just another attribute, but they also have an XML namespace table, managing prefixes and scope.

While the differences are only significant on layer 8 and 9 of the ISO stack (politics and religion), porting from one to the other API is quite interesting and - at times - forces you to think about the infoset in new ways.

On May 17, 2006 at 9:30pm Paul, Santiago and I will host a BOF on "Project FIFI - Bridging the Interoperability Chasm". FIFI (Fast Infoset For Indigo) is a prototype project that aims at bringing the Fast Infoset ITU-T/ISO standard to the .NET 2.0 platform and furthermore integrating it with the upcoming Windows Communication Framework (WCF - aka Indigo).

BOF 2535: Project FIFI - Bridging the Interoperability Chasm
Track: Web Tier
Room: Hall E 135
Date: 17-MAY-06
Start Time: 21:30

Stay tuned for more.

Fresh from Washington state: Indigo to support POX in TextEncoder

Combine this with Marc Hadley's adventures with REST in JAX-WS, and you might actually get something interoperable ..

Today, Sun opens their Enterprise tools to the NetBeans community. This is really good news for Java developers, since they now get a truly modular, extensible, easy-to-use and easy-to-install IDE, that features:

• UML modelers (both ways)
  
• XML tools
• SOAP orchestration
  

This is obviously in addtition to the Matisse UI builder, the profiler, the J2ME development tools etc. Also, the NetBeans platform is now also being used for non-development applications (see e.g. the Stocktrader application).

Marc is working on a nice and *clean* web application description language (WADL) that can be used for non-SOAP web services as well.

For an introduction to RESTful web services with JAX-WS, please take a look at his recent post. It might be an interesting excercise to get this to work with Clemens' RESTful extension for WCF.

Pat found this interesting article by Chuck. It is on a Java implementation of the InfoCard protocol.

Tags: InfoCard, Interoperability, Java, Identity

While XUL is definitively an interesting alternative to XAML for creating application through XML, Java now has its own: JAXX

If you are interested in UI design, using XML in new ways or XAML (the markup language for creating .NET applications in WPF), you might want to check out JAXX as well.

Tags: JAXX, Java, XML, XAML

It's a little geeky and doesn't carry much importance, but I just liked it from a political point of view...

NetBeans 5.0 Beta on Windows Vista September 2005 CTP:

I used the 1.5.0 update 5 JDK (from http://java.sun.com/) and the recently released NB installer ... worked like a charm and even the bugs are the same as under 2003 and XP. The icons in the file chooser dialog were also matched to the new Vista UI .. looked nice.

The new NetBeans web services client is quite nice. It is now almost as easy as with Visual Studio to integrate a web service into your application: After pointing the IDE to the WSDL, it generates the necessary proxies and you can then integrate them by right clicking your methods in the source editor and add web operations:

This works right out of the box with ASP.NET 2.0 web services, although it has some issues with complex types (like e.g. an ArrayList). Those get deserialized as SOAPElements which is workable, but requires some SOAP DOM coding.

Indigo (WCF) web services seem to have more issues - I guess this is related to Microsoft splitting up the WSDL into some smaller files (wsdl1, xsd0, etc.)

If you are looking for a Java IDE, please take a look at the latest Netbeans 5.0 beta: http://www.netbeans.org/

Some of the new features:

• Support for Tomcat, Sun Application Server, BEA WebLogic and JBoss
• Massively improved GUI builder (Matisse)
• Web Services client support built-in
• Web Frameworks (JSF or Struts), including palette drag-and-drop

I will post more about this a little later.