XAML has recently come to light as a Microsoft [admittedly] version of XML used to initialize objects. There may be some early indications of an interoperability play for XAML.It is fairly robust technology – and thus not necessarily easy to develop. We are talking XML and objects here. As Ted Neward said earlier this year at The ServerSide Java Symposium in Las Vegas: “XAML is effectively a way to create an object model.”

By Jack Vaughan

What’s all this talk about XAML? XAML has recently come to light as a Microsoft [admittedly] version of XML used to initialize objects. So far its principle association has been with presentation-level software, specifically the Windows Presentation Foundation. It is a base technology for Microsoft’s much discussed Silverlight client, although Silverlight at this point is mostly about JavaScript. Microsoft began to discuss XAML at PDC a few years ago, and there was even one third-party XAML tool provider, Xamalon, on hand. Since then, Xamalon, which could output XAML as Flash, has morphed into an Ajax client provider. Not a bad idea; the last few years would have been a bit sparse if you made your living on XAML.

In some samples, XAML can accomplish much with minimal coding. But some may find some simple tasks unnecessarily complex. After all, it is XML-based and not every developer’s cup of tea.

Just now, a few other third-party XAML tools are coming online, but even among these, as in the case of ComponentOne’s Sapphire Suite of controls are waiting for Silverlight 1.1 to be released. TheServerSide.com and TheServerSide Interoperability blog recently noted that Soyatec announced eFace, a library implementing XAML in Java.

This is, perhaps, an early indication of an interoperability play for XAML. Of course, the Java vendors, and JavaScript vendors, for that matter, are at work on client alternatives to Microsoft technology. The idea of Java servers outputting pages to XAML-clients may be far fetched. It is still early too tell.

Clearly, XAML will take a few years to develop. Microsoft is packing XAML, Silverlight and WPF with the modern types of functionality that one sees in Flash and YouTube. It results in some part of Microsoft’s experience with eye-boggling game technology. It is fairly robust technology – and thus not necessarily easy to develop. We are talking XML and objects here. As Ted Neward said earlier this year at The ServerSide Java Symposium in Las Vegas: “XAML is effectively a way to create an object model.”

As Ted’s take on interoperability has been central to the germination of this site, we thought we’d take a look again at our notes from The Java Symposium 2007, where interoperability and XAML were among Neward’s areas of interest, recreated here with some, but not all, of The Ted Man’s usual panache.

At The ServerSide Java Symposium in Las Vegas last spring Ted Neward’s freewheeling presentation on .NET/Java interoperability included a demo of XAML working with JBoss. In the early days of .NET, said Neward, the similarities with J2EE were quite extraordinary. We might add that Windows Communication Foundation [WCF] is probably not indecipherable to a typical J2EE trooper. More recently, Neward correctly noted, Java has come to include more architectures with light-weight object containers. Still, at the conference, interoperability advocate Neward said:

These are things for which we do not have natural complements on the Java side. There are times when it would be nice to take advantage of WPF stuff, WW [Windows Workflow Foundation] stuff etc.  Java does not necessarily have a direct corollary to those.

In fact, the graphics area has yet to prove a strong point of Java. What of Microsoft’s new WPF? Is it a game changer? In his own style, Neward said:

WPF is a complete rewrite of the user interface stack from Microsoft.  This was borne out of a realization that when you go and buy this really, really nice desktop machine, you get a video card that is about this big, right?  And it has got like all kinds of memory and processing power on it, 64 Meg, 32 Meg, 128 Meg.  I have actually heard of video cards that are in design right now with one gig of video memory on them.  They are just covered in silicon.  And then you fire up your Windows Operating System or even your Linux Operating System in many cases and all of the calls that are used to do all of the drawings to the screen that you see, with the exception of when you fire up your favorite game, all of that drawing, all of that rendering, is handled by a chip that is about this big tucked away in the lower right corner of the card.  All of that processing power on that graphic card is going completely to waste unless you are playing Doom, and the moral of the story here is, we should be playing more Doom. 

What WPF does, Neward continued, is leverage the graphics library that Microsoft calls DirectX “and brings it basically up through the stack directly into the hands of the programmer.   XAML is effectively a way to create an object model.  This is not necessarily directly tied to presentation.

How many developers use Swing to build interfaces? How many use Flash? Java on the applet side has seen hard going from the get-go. Adobe Flash – when it was Macromedia Flash – made a middling effort a few years ago to propose Flash as a developer tool. The effort is underway again with a bit more push. For some developers, Neward seemed to suggest at TSSJS, a few lines of XAML may be the choice.

I, Interop. The interoperable approach which this site asks people to consider says, to use Ted Neward’s words at TSSJS: “My Java code lives here and I leave it alone and my .NET code lives here, and somehow they talk to one another.”

“Why do you do this?  Well, in some cases because you have to.  Various analyst companies have spent billions of dollars in analysis and research and discovered that neither platform is going away anytime soon.  That is a great racket. Neither of these platforms is going away. “

And the last word here of course belongs to Neward:

Both of these platforms, however, have viable options that are interesting and useful. It used to be .NET 1.x and the JVM 1.4 environments were exact mirror images of one another.  What was present in one was present in the other.  There was no compelling reason to go one way or the other.  I used to tell people, look, the decision is far more deeply rooted in corporate culture and what you already know, than it is in terms of any particular technological approach that you might have regarding .NET or Java.

This entry was posted on Wednesday, September 26th, 2007 at 8:35 am and is filed under Interoperability, Applications. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.