Marc recently published a short tutorial on how to use Apache Abdera with Apache Abdera with our reference implementation of JAX-RS, Jersey. His code is server side, i.e. it explains using Jersey and Abdera for creating RESTful web services with Atom payload^[1]. In this article I will give an example on how the Jersey client API can be used to consume such a service with realitve ease.

It is hopefully known that Jersey contains a very simple, yet effective HTTP client API. Core to it is the heavy use of the builder pattern for creating and configuring requests. For our example, I start with creating the client:

  Client c = Client.create();

  WebResource r = c.resource(new URI(someLocation));

We can now get the InputStream from the WebResource to read the Atom feed into an Abdera Feed:

  InputStream is = (InputStream) r.get(InputStream.class);

  Document<Feed> doc = Abdera.getNewParser().parse(is);
  Feed feed = doc.getRoot();

  for (Entry entry : feed.getEntries()) {

      doSomething(entry);

  }

Now let's say we want to post an entry to the resource in Marc's article. In this case we would also have to use his AbderaSupport class, which implementes the proper MessageBodyReader and MessageBodyWriter interfaces for the Abdera objects. On the server side providing these interfaces is enough, but on the client side we need to configure the Jersey client. The following code helps doing this:

  public static class AbderaClientConfig extends DefaultClientConfig {

      @Override

      public Set<Class<?>> getProviderClasses() {

          Set<Class<?>> classes = new HashSet<Class<?>>();
          classes.add(AbderaSupport.class);
          return classes;
      }
  }

Thus completing our sample app: 

  ClientConfig cf = new AbderaClientConfig();

  Client c = Client.create(cf);

  WebResource r = c.resource(new URI(someLocation));
  
  Entry entry = AbderaSupport.getAbdera().newEntry(); 
  entry.setTitle(...); 
  entry.setContent(...);          
            
  ClientResponse cr = r.type(MediaType.APPLICATION_XML).put(ClientResponse.class, entry);  

Done.

tags: Jersey Apache Abdera Atom JAX-RS

[1] Tim pointed out that this style should properly called "AtomPub", and not APP, AtomPub/Sub or similar.

During TechEd 2008, I participated in a Panel discussion on Web Services Interoperability. Microsoft just put up the tape on their TechNet Library site. They also have a WMV video feed, and a MP3 audio-only feed.

Just back from Orlando, here are some takeaways from this year's TechEd 2008 for IT-pros:

• Interoperability with SOAP based web services is progressing: I was part of a panel on interoperability, moderated by Chris Haddad. It was a fairly diverse panel, with speakers from Microsoft, WSO2, Tibco, and Sun. While there was general agreement on the usefulness of the more basic WS-* specifications like WS-Security, opinions differed on where the future lies and how it can be achieved. In my opinion, the relatively high fidelity of interoperability within the WS-SX family of specifications is a direct result of the proper standardization process at OASIS that these specs were subjected to, comparable to that of ebXML or SAML 2.0. Thus, it is my expectation that the WS-RX and WS-TX protocol families will eventually yield similarly good interoperability.
• For the "Demo that almost made it (TM)", we made some serious progress: After talking to Greg Leake of Microsoft and Jonathan Marsh of WSO2, I am quite optimistinc that we can get easily inject a Metro based STS and/or OpenSSO with WS-Trust and CardSpace support into the StockTrader sample application to allow authentication through a SAML token. At the same time, I think that this demo application in particular lends itself quite nicely to showcase the strength of the Liberty framework for web services: you have a web application that needs to interact with the Business Services and the Order Processing Service. Identity has to be preserved across these different tiers, yet privacy protection would be highly desirable.
  
• It was very interesting to see that Microsoft is continuing on the path of interoperability in the systems management area. Three years after we demonstrated MOM 2005 managing and monitoring a Sun v40z with Solaris, Microsofts System Center beta features an open source Solaris management adapter. An interesting question is where this code will be hosted ...

Dare wrote an interesting piece on why RESTful service are much better off without an interface definition language. He is especially picking up on teve Vinoski’s IDLs vs. Human Documentation post, which emphasizes human readable documentation over IDLs.

I am sure that Marc has a somewhat different opinion on this ...

tag: development, REST, WADL

Here is a small update on available .NET FastInfoset (X.891) libraries:

• Noemax FastInfoset.NET - I have been talking to them from very early on.
  
• Liquid XML Compression - a relatively new (at least to me) implementation that supports .NET 2.0 and the Compact Framework.
  

There is a trial available from both vendors.

If there is still interest in the community, I would be happy to revisit my FIFI code and release it publicly. Please send me a message if this was important to you.

tag: FastInfoset, .NET

OASIS has published a draft web service profile for XACML, called WS-XACML. Now, this seems to get very interesting, since it has the potential to truely deliver 'User-Centric' identity (as opposed to Infocard's ServiceProvider-centric identity).

The significant difference here is the availability of two sections in the XACML assertion: one defining the requirements, and the other the capabilities - for BOTH, server and client. InfoCard (and its implementations like Windows CardSpace or Higgins) do not really negotiate requirements, but the service provider (i.e. Relying Party) dictates its requirements and the client will only present Infocard conforming to such requirements. With WS-XACML (which - by the way - also works out-of-the-box with rich client applications) there is an initial policy matching of the server's requirements with the client capabilities AND vice versa. The superiory becomes obvious, when thinking about how easy it is with an InfoCard system to present a card with too much information.

tag: Privacy, Standards, Web Services, OASIS, XACML

WS-Federation 1.1 is out... and skipping through the TOC, I have this strange feeling of deja vu.

Interesting news from the Compact Framework group: They are planning on releasing a subset of WCF on the Compact Framework (i.e. their mobile edition). This is quite interesting, not the least because a lot of their mobile devices are frequently used in a disconnected mode and only updated at scheduled times. One solution to the problems that arise with this mode of operation is the use of SMTP as a transport protocol for SOAP.

My paper on persistent AJaX is to be published in the Research Disclosure Journal. Please find it here.

There are no new additions, just a formal publication.

Here you can find the OSIS response to the OSP.

I think that this reposonse is - particularly in the context of OSIS and related efforts - quite appropriate. The obvious issues with the covenant, as also pointed out by quite a few of my colleagues (see e.g. Eve or Simon) are addressed, including the concern that Microsoft is not the only stake holder in the WS-* space.

Microsoft today announced their "Open Specifications Promise", essentially a non-assertion covenant for a huge chunk of WS-* protocols. This OSP means (as fas as I can tell - and I am NOT a lawyer ) that people can start implementing WS-* specifications without having to fear any action from Microsoft, as long as they do not sue Microsoft over these specs - duh!

This is quite good news for a number of reasons:

1. All existing implementations of WS-* technology are safe from any legal harassment from Microsoft. Not that they would do this necessarily, but this covenant gives peace of mind.
   
2. Since pretty much all security specs are out, OSIS and Higgins are now in a much better position to implement a WCS compatible InfoCard selector.
3. The best thing about this is the fundamental mindshift at Microsoft. A couple of years ago this would have been unthinkable. Now it is real. This is really major change in the way Microsoft deals with the open source community. It can be hoped that this OSP is just the beginning of a much more open discussion with Microsoft.
   

Here is a very nice introduction to ontologies within the context of the semantic web and - in particular - OWL:

http://www.cs.man.ac.uk/~horrocks/ISWC2003/Tutorial/

Here is a little article on Persistent AJaX (P-AJaX) I will be publishing:

---

Persistent AJaX

Applications using Asynchronous JavaScript

There are a growing number of applications that use Asynchronous JavaScript with the XMLHttpRequest object to dynamically update the contents of the user interface. This style of application creation is commonly referred to as AjaX and it is used widely for web based applications. Typically these application can only be used while the client is connected to the internet, since they update the content of the user interface dynamically. A big benefit of AjaX applications is that they can present a very rich user interface and can be used across a large variety of platforms and browsers.

At the same time, it is possible to use similar techniques for creating dynamic applications that are hosted on a local machine and do not require a connection to a server. Such applications tend not to use the XMLHttpRequest object, since network connections are not used.

The boundary of connected and disconnected applications is usually not crossed: either an application requires a network connection or it does not. However, there are many applications that can operate in connected and in disconnected mode, such as email, calendar, etc. Users are usually online, but also take the application to places where network connections are not available and use them in an offline mode.

This paper describes a pattern to create AjaX applications that can be used in connected and in disconnected mode. Ideally, a Persistant AjaX (P-AJaX) application and its data could be stored on a portable mass storage device, such as a USB “thumb drive,” and taken to any computing platform whether connected or not.

Connection State Discovery

It is important to determine for an application whether it is connected to the server or not. This can be done very easily by sending an initial XMLHttpRequest synchronously and setting a boolean variable to online or offline:

var online = false;

function testState() {

req.onreadystatechange = testOnline;

req.open('GET', url, false);

req.send('');

}

function testOnline() {

if (req.readystate == 4) {

if(req.status == 200) {

online = true;

}

}

}

Persistence Technique

In order to be able to use the P-AJaX application on a disconnected computer, it has to locally cache at least some data it receives from the server while connected. This can be done is a variety of ways, e.g. through HTML browser cookies. A more powerful way to cache data is by using a Java^TM technology-based RDBMS system, as it has been described in [1].

There are some major drawbacks to these techniques: browser cookies are stored in installation specific parts of the file system and cannot easily be transferred from there to a USB drive. While the database table and the engine code for the Derby Java RDBMS can be stored anywhere, there is no guarantee that all platforms have a Java runtime installed, thus losing cross platform interoperability.

A simple way to store data in arbitrary locations is a flat file. Such files can contain XML, text or any other data that would be fit for use with a P-AJaX application. This can be easily achieved in Internet Explorer using the FileSystemObject:

var fso = new ActiveXObject('Scripting.FileSystemObject');

var f = fso.createTextFile("C:\\temp\\file.txt",true);

f.Write(time);

f.Close();

f = null;

The FileSystemObject is an ActiveX object and therefore only available on IE. For Firefox there exists the jslib library [2], which implements a similar file JavaScript API for file access.

Cache Updates

In order to allow offline updates to the application data, changed data should get flagged if it changes. This can be done by encapsulating the application data in an XML node and preceding this node with a 'dirty-flag' node. This should include a time stamp of the last write access to the data, like this:

<root>

<status changed=”1”>

Wed Aug 16 10:28:40 EDT 2006

</status>

<data>

...

</data>

</root>

[1] http://java.sun.com/developer/EJTechTips/2005/tt1122.html

[2] http://jslib.mozdev.org/

Kirill posted his session schedule for TechEd. Just as a final reminder, FIFI s on:

CONTLC37 - Enterprise Web Services Interoperability between .NET and Java Using WCF and Sun's GlassFish

Connected Systems Theater 2, Blue Arena in TLC, Wed June 14th, 14:00 - 15:15

 

The FIFI segment of his talk should be particularly interesting for you if you want to learn more about writing your own MessageEncoder and XmlWriter and XmlReader. There will be some discussion on the architecture of the encoding layer and the serialization as well.
We will also talk about WS-ReliableMessaging interoperability and Infocard identity interoperability between the NetFX stack and Java.

Here is the link for the Chalk Talk sessions at TechEd:

http://wcf.netfx3.com/content/TechEd2006ChalkTalkSchedule.aspx

Note the FIFI session at about two-thirds of the page: it is on Wednesday at 2pm in theater CON2.

Andre Durand is blogging today about his demo at the upcoing Catalyst conference: an Infocard Server that can connect to any federation source and 'translate' this into Infocard. Kim Cameron has a few things to say about as well. Now what exactly is the current public availability of the Infocard protocols?

Here is the poster from Ping:

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.

Finally - the confusion is complete: WinFX is now NetFX. Huh?

The (likely) final name for the collection of .NET APIs formerly know as WinFX 3.0 (aka Avalon, Indigo and Workflow, but NOT WinFS) have a new name and community portal: They are now called NetFX and hosted at http://netfx3.com/, with Indigo/WCF being located at http://wcf.netfx3.com/.

I have finally come around to summarize some of the architectural ideas around FastInfoset For Indigo. You can find the initial version on my Wiki.

I will continue to update this article and also put the various presentations there. This should be a good primer for my Chalk Talk next week at TechEd in Boston.

Francois Orsini is working on JavaDB, a derivant of the Apache Derby RDBMS. In one of his recent articles he is talking about the possibility of using JavaDB for offline AJaX. This is - as far as I am concerned - a very promising step in the right direction: We all love the rich UI that AJaX can provide - the problem is only when we are offline, all those applications do not work anymore. By caching the various requests on the client and synchronizing them upon reconnect, you can make web applications into real applications. As Francois points out, this can be achieved by simply modifying the client side call behavior (check if connected -> synchronize -> use local copy).

I would have a whole bunch of applications that would be useful:

• Calendar
• Email
• Spreadsheet & Word Processing
• Bloging
  

Actually, with these four applications I could do about 60% of my work offline - as long as I have a browser that is AJaX and JavaDB enabled.

So, I am deep in FIFI right now. There will be two presentations on the project in the next couple of weeks:

SunLabs Open House 2006
June 1-2, 2006, Sun Menlo Park Campus, Bldg. 16
Track: 6
Room: 1281
Title: Project FIFI
Abstract: Fast Infoset is a ITU-T/ISO standard for effricient XML encoding. It is available for Java through the JWSDP and the Java.Net open source project. FIFI provides an implementation on Microsoft's .NET platform.
Time: June 1, 2:30-3:00pm PST


Microsoft TechEd 2006
June 11-16, 2006, Boston Convention Center
Track: Connected Systems
Code: CON-TLC307
Title: Enterprise WebServices interoperability between .Net and Java using WCF and Sun's GlassFish
Abstract: Web Services matured to address enterprise needs.
Interoperability between Java and .Net on Secure, Reliable and Binary messaging is a reality. Come and see .Net and Java interoperating in a real world enterprise scenario using Microsoft's Windows Communication Foundation and Sun's GlassFish web services stacks
Time: Breakout 13, CON Theatre 2; Wed, 14 Jun, 2:00 - 3:15 (Eastern)

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?

Finally, with a lot of help from sgen.exe and a number of very talented inidividuals, I got the complex types to work this morning. The biggest issue was the way WCF compares Strings:
Java does sttring interning, .NET does not do this by default (this is why (object) string1 == (object) string2 is without further consideration a bad idea). Within the XML serialization framework however, WCF uses a NameTable to "atomize" (i.e. intern) strings. The Reader must return interned versions of the name, localName, namespace, etc. or the string comparisons in the generated classes will fail. Here is a sample from the generated code:

while (Reader.NodeType != System.Xml.XmlNodeType.EndElement &&
        Reader.NodeType != System.Xml.XmlNodeType.None) {

    if (Reader.NodeType == System.Xml.XmlNodeType.Element) {
        if (!paramsRead[0] && ((object) Reader.LocalName ==  (object)id4_agedHelloResponse &&
                (object) Reader.NamespaceURI == (object)id2_Item)) {
            o.@agedHelloResponse = Read4_agedHelloResponse(false, true);
            paramsRead[0] = true;
        }
        else {
            UnknownNode((object)o, @":agedHelloResponse");
        }
    }
    else {
        UnknownNode((object)o, @":agedHelloResponse");
    }
}

After fixing the Properties on XmlFiReader, it can now deserialize complex objects, and - as such - also use doc/lit in addition to rpc.

Well, I really do not have any big secrets to uncover, but I wanted to point you WCF developers to an extremely useful tool: sgen.exe.

In itself the tool is quite handy, since you can pre-generate and compile serialization code that would otherwise be generated and compiled by WCF during runtime. The cost for doing this (while only during startup) is quite significant, so using sgen.exe, you can avoid this penalty.

The by far best part of sgen.exe is, however, the '/keep' switch. If you turn this on, WCF keeps the source code for the custom IXmlSerializable implementation, and you can tweak, adjust or - in my case - debug - your serialization process.

There is the obvious question on why FastInfoset and - more importantly for me at this time - why on Indigo (WCF)?

A lot of customers - particularly in the financial industry - have expressed their concern about XML and its 'bloatiness': it is simply to verbose to be useful in 10M, 100M or even Gigabyte sized transactions. This makes a lot of sense and thus, FastInfoset (and similar efficent XML initiatives) were born out of this need.

Sun has been behind FastInfoset from its inception and the current JWSDP and the Glassfish application server fully support FI. It has been a clearly stated goal that we see FI as our strategic binary Infoset representation scheme and we would like to achieve ubiquity.

To achieve such ubiquity, it is mandatory to cover as much server and client platforms as possible. With FI being available for the Java platform - supported and open source - this goal is actually achievable. But in order to be truely successful, it is also necessary to enable non-Java platforms to exchange messages in FI. FIFI aims at just that: to enable FI processing for .NET 2.0 and FI message exchange for WCF.

Reminder: the FIFI BOF at JavaONE is tomorrow, May 17, at 9:30pm in Hall E.

Huh? How are these two things related at all?

Well ... On last Friday I had a terrible Hard Drive crash, eliminating about 10 days worth of FIFI coding. That resulted - obviously - a lot of unhappy coding over the weekend. Fortunately, I was able to redo pretty much all code loss by Monday morning... which shows that trying to get a completely new MessageEncoder working with WCF is a lot of reengineering and much less actual coding (thank the gods of Redmond Kobol for stop and continue in Visual Studio).

Anyway, with some substantial help from Paul and my rejuvenated FIFI code, we got RPC/encoded working.

As for doc/lit: the deserialization framework in .NET 2.0 is quite complex. Having said that, here is a little question for anybody knowledgable about the XmlFormatter (and/or DataContractSerializer et al.):

How does WCF deserialize the SOAP message Body exactly?

If you know the answer, please let me know.

Coming back to the original question: a hard drive crash prompted me to recode portions of FIFI, enabling me essentially to dig a little deeper into the WCF stack. And the glass is half-full.

WS-Addressing is as of today eleveated to a full W3C recommendation.

Congratulations to Marc Hadley ... (for making the web services world a little bloatier )

WCF can be quite annoying - that is, it sometimes does thing in a way I personally don't like.

While happily coding FIFI (the Fast Infoset implementation for WCF that will be demoed on JavaOne), I noticed that the System.ServiceModel.Message.Write(XmlWriter) method does not use WriteStartDocument and WriteEndDocument. This is quite annoying, since nodes in FI need to be properly terminated. Sigh ...

XML and Web services are loosely coupled, right? And loosely coupled and object references do usually not play nice together...

This is quite interesting: It looks like you can preserve object references and pass them along when setting the preserveObjectReference flag to true in a new DataContractSerializer.

I will play around with this and see how this looks on the wire ... stay tuned.

If you are at all interested in non-SOAPy web services, you might want to take a close  look at WADL, the Web Application (!) Description Language. It is an XML based language that can be used to describe general HTTP-based service APIs that can not be described reasonably in other meta-description frameworks, such as WSDL.

Ultimately, this technology will allow web service providers (such as Amazon, Ebay, Google, Yahoo!) to focus on providing their respective services, and not on creating new APIs in a variety of languages to use these services.

On May 17, 2006 at 9:30pm Paul, Santiago and I will host a BOF on "Project FIFI - Bridging the Interoperability Chasm"</