Here is a couple of questions I'd love to put out - if you have the time, please let me know since I am genuinely curious:

• Who has implemented a successfully chained service, with some propagation of identity?
  
• If you have, what architectural approach/technology stack have you used?
  
• How are you propagating identity - "sender vouches", "holder of key", "just trust me"?
• How complex is the chain? Single step, multiple steps, complex orchestration?

There are really very few actual success stories I can find on this subject ... I have a sense why this could be, but I'd love to verify my suspicion.

Who does not know and dread the recurring discussion of a topic long thought dead? The most egregious one lately was a discussion about the applicability of RFC 2119 to a particular standard I was working on (to protect the innocent I will not disclose the name of the SDO) - the last time I had a discussion about the meaning of "SHOULD" was about 11 years ago... sigh!

But this is not the reason for my current urge to vent - a bug long thought dead is reappearing once more: the old discussion about REST vs. SOAP. It is really annoying for two reasons. Firstly, it is settled - both have their place, and pitting them against each other is pointless. But secondly, posing the question of "Is SOAP or REST better?" is - to paraphrase Mona Lisa Vito - a bu****it question.

Representational State Transfer (REST) is an architectural style, i.e. a general approach on how to design distributed computing architecture. While it was initially described by Roy Fielding using HTTP, and also uses constraints familiar from the web, it is not tied to a particular technology.

The Simple Object Access Protocol (SOAP) is - in contrast - a specific technology; more precisely an XML based protocol designed to transport data across a variety of different underlying transports. In real-world deployments it often uses HTTP (actually almost exclusively its POST method) as underlying transport for the SOAP Infoset. The architectural style used by many (if not most) SOAP designs is best captured by describing it as remote procedure call (RPC) oriented [1]. 

So a correct (in the sense of "apples to apples") comparison would align itself along the lines of comparing HTTP web service using an RESTful architectural style with SOAP web services using an RPC-based architectural style. A simple, incomplete table might look like this:

Architectural Style	RPC	REST
Commonly used protocol	SOAP over HTTP/POST	HTTP
Common payload	XML	Any Internet Media TYpe
Number of methods/verbs	many	four (PUT, GET, POST, DELETE)
Scalability technology	ESB	Load balancer

That's it - rant over.

[1] Note that while SOAP operates typically in two different modes (rpc/encoded and doc/literal), these have nothing to do with the architectural style of the distributed design.

Service chaining is - in my mind - somewhat underappreciated as use case is identity management. It is being paid some lip service, but often put off as too hard to solve. Yet, many of the issues I face in the mapping of complex business processes to a set of decomposed services involves service chaining. For the purpose of this article, here is a simplistic definition (made up by myself):

"Service chaining occurs when a service must invoke another service to complete a transaction."

In other words, a user invokes a service A. That starts working on the problem, but figures that it needs information from service B. Now, service B is being invoked, but there needs to be good understanding on who is invoking service B to perform a satisfying access control decision. Service B should ideally know the identity of the user and the invocation path (in this case just service A) to perform an access control decision.

Interestingly enough, this process can be decomposed into two important steps: the final access control decision by service B, and a reverse authorization decision by the user. For the following steps, strong cryptographic identification through public/private key pairs is assumed:

Step 1: The user invokes service A (authentication and authorization occurs somehow).

Step 2: Service A decides that it needs to invoke service B for completing the operation and tries to access.

Step 3: Service B challenges the access request with a signed statement (access request statement - ARS) that documents:

• Its identity by including an identifier (such as e.g. a URI) and its public key
• The operation service A is trying to perform
• The identity of service A, again through e.g. a URI and public key.

Step 4: Service A receives the ARS and forwards it to the user. The user evaluates the request, andauthorizes the ASR by signing it.

Step 5: Service A forwards the signed ARS to service B. Service B verifies the signature and returns service A the required information.

It is obvious that this process it WAY to expensive to implement in large systems, but these are the steps that are - explicitly or implicitly - taking place in any service chaining scenario. It gets a little more complicated once you allow delegation of authorization, i.e. service A might have permission to authorize access on behalf of the user for service B trying to access yet another service C.

The two major performance impacts in this model are: (i) signature creation and verification, especially over XML constructs, and (ii) ASR parsing and policy evaluation.

Today, we released the hData technical specifications: hData Record Format and hData Packaging and Network Transport. This is the mail that went out to the mailing lists:

Today we are releasing the first public version of the hData specification for the record format and the packaging and network transport (REST API). They are available here:

http://www.projecthdata.org/documents.html

We will be making some changes to the documents in the next few days to add a simple meta data model and streamline certain elements. Once this is complete, we are planning on moving the specification to a wiki and open up the process of editing. Until this is done, we would like to ask you sending your comments to hdata-general@googlegroups.com

At this time we are also exploring how the hData specifications can be licensed in an open source friendly way. Possible options include an OASIS style non-assertion covenant – please contact us if you have suggestions.

So far, this covers the core data and exchange architecture, but we have started to work on a RESTful security architecture, as well. The scenario we are trying to solve is outline in a recent presentation at NIST's IT Security Automation Conference. In support of this I have come up with a meta data schema, which I will put into the v0.8 version of the hData Record Format specification. Hopefully, I can upload that new version some time next week.

We are very much looking for comments and suggestions. 

tags: hData ehr health care hl7 hitsp

Marc just made my day by sending me the link to the official submission of WADL to the W3C. Quick background: WADL (Web Application Description Language) is a simple interface definition language, specifically targeted at RESTful applications. It is significantly easier than WSDL 2.0 (or WSDL 1.x for that matter), and has some good tooling support through the Jersey implementation of JAX-RS.

tags: wadl rest web services

User-centricity - often expressed in the "7 Laws of Identity" - has been a common theme in identity management for a while now. At the heart of these principles lies the desire to empower the end-users of a computer systems and enable them to negotiate with the provider of service the amount of PII data the users have to disclose for getting access. Beyond the initial authentication and authorization steps for resource access also lies an ocean of other problems such as delegation, pre-authorization, and emergency overrides. These issues play into a vast number of use cases in very different areas such as financials, health care, and social networking.

At the same time, a rather important aspect of identity has been completely ignored: the systems we interact with and their component services and devices do have identities as well, and these identities must be managed with the same details as person identities. The need for non-person identity management goes well beyond the realm of security sensitive environments such as various government services: we are getting ever more dependent on a growing number of devices and services including mundane things such as smart phones and ebook readers, but also critical items such as health monitors. In many cases, high-value or critical services rely on less valued service (such as a health monitors that use the mobile phone system for notification). Overall, we are seeing a polynomial growth of interdependencies of such services of devices.

With these problems looming, it becomes more and more urgent to extend the practices learned in identity management for persons to non-person entities. The solutions for this new class of identities will have to be significantly different, since devices and services will interact with the IdM systems in very different ways and might also have significantly different needs. For example, while privacy protection is important for end-users, devices and services and their operators will likely be more concerned with secrecy, which might borrow from some privacy best practices, but be different in other respects. 

Interestingly enough, PKI has had a notion of non-person identities already for some while. We are relying on the internet PKI for authenticating servers to users and services. At the same time, PKI has been very cumbersome to roll-out to end-users and edge devices. As such, there are some lessons that PKI can provide, so that the efficiencies and abstractions of SAML and related technologies can to go beyond simple user-centricity.

As a challenge, here are some questions that I have with regards to identity management of non-person entities:

1. What identity can devices and services have? How are these identities different from human identities?
2. What are the minimal requirements on machine identities?
3. What new and different interaction patterns are required for enabling machine identities?
4. How do concepts such as reputation translate into the machine world? 
5. When machine and human identities interact, is there a need for disclosure that one party is non-human? Or human?

tags: identity management idm privacy non-person entities

For some time I have been working with a number of folks at MITRE on a simple representation for electronic health data. Digging into the depth of various standards organizations such as HL7, HITSP, or HIMSS was interesting, painful, and enlightening at the same time. Since last week, our project is online at http://projecthdata.org/, and the hData project has announced releasing specifications, schemas, and code there soon. At this time, you can get the hData white paper, which was also presented at the recent Balisage 2009 conference in Montreal. Overall, hData's approach is very much focused on implementability and ease-of use for developers (since - quoting Mike Kay at Balisage - "As a developer I am also human.")

Interestingly enough, the combination of ODF/Jar style packaging and RESTful integration (taking a ZIP archive of hierarchically organized component documents and representing it as a collection of resources) has some folks interested. If there are more, I will suggest taking this out of hData and creating an independent specification.

tags: hData ehr health care hl7

For this year's Balisage in Montreal, we (R. Dingwell, A. Gregorowicz, H. Sleeper, and myself) have been accepted as a late-breaking proposal for our work on hData, which addresses some problems that are currently plaguing electronic health records. Our session is scheduled on Thursday at 11:00am. This is the abstract:

Title: hData - A Simplified Approach to Health Data Exchange

Interoperability issues have limited the expected benefits of Electronic Health Record (EHR) systems. Ideally, the medical history of a patient is recorded in a set of digital continuity of care documents which are securely available to the patient and their care providers on demand. The history of continuity of care standards includes multiple standards organizations, differing goals, and ongoing efforts to reconcile the various specifications. Existing standards define a format that is too complex for exchanging continuity of care information effectively. We propose hData, a simplified XML framework to describe health information. hData addresses the challenges of the current HL7 Continuity of Care Document format and is explicitly designed for extensibility to address health information exchange needs, in general. hData applies established best practices for XML document architectures to the vertical health domain, which has experienced significant XML-based interoperability issues.

As you might imagine, we will have to say a few things about identity, access, and privacy management for electronic health records, as well. Looking forward to seeing you there.

tags: balisageConference09 EHR HIT health care health records hData

tinyarro.ws: http://➡.ws/榾 (wood chip)

Working currently on an RelaxNG project, I needed to automate conversion of RNG schemas to a W3C compliant schema in NetBeans. The tool I used to perform the transform is Trang. I added this macro to the build.xml file:

All necessary libraries reside in the ./resources/tools directory. Now, in order to use this macro on a number of RNG files, I decided to use the <for> directive from ant-contrib. James Allen has good instructions on how to integrate ant-contrib within NetBeans (or arbitrary ant environments) without having to drop the ant-contrib Jar into the ant/NetBeans installation.

Here I am iterating over the ${rng-files} property that contains a comma delimited list of the RNG files you want to convert (without the .rng extension). I filled this through <pathconvert>:

Obviously, these XSDs can then be used with any other tools, such as JAXB.

It took a long time, but it seems that the time for an older idea of mine has come: Jeff Hodges is reporting on a report he prepared for the MIT Kerberos group to explore the use of SAML tokens in traditional security systems. A while ago, I was exploring a similar idea - then with Eve and Nico - on how to use SAML attribute and bearer token in the context of the GSS-API. 

The ideas and concepts we had then would still seem valid to me, although a lot of things have moved on since then. I will definitively follow this, if only from a distance.

tags: saml gss-api kerberos

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". 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).

Through Tim's ongoing: Check out this post on WS-SopranosDesperateHousewivesKwisatchHaderach ...

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.

Here is a really nice article on InfoCard. Not only does it cover the implementation and APIs, but also the message flow.

I am currently working on getting a better grip on why DIX should matter at all, particularly with SAML around. Granted, DOX offers a few neat features, but I cannot see why SAML should not be able to support most of them either by profiling SAML 2 or adding a few details. My fear is that the DIX folks will re-invent SAML, only this time within the IETF.

I have created a page on my wiki (that contains only this blog entry so far) where I will collect some thoughts and ideas.

Tags: DIX, SXIP, SAML

... is a no-go. Please read Rob's blog entry about WinFX not being supported on the October 05 CTP release of Vista.

I was getting a little interested in learning more about how the Indigo/WCF transport listener architecture works. This is what I found so far:

The center of this is the TransportListenerFactory. Its inheritance tree can be found on MSDN but here is a quick overview:

System.Object
   System.ServiceModel.Channels.CommunicationObject
      System.ServiceModel.Channels.ChannelManagerBase
         System.ServiceModel.Channels.ListenerFactoryBase
            System.ServiceModel.Channels.TransportListenerFactory
               System.ServiceModel.Channels.ConnectionOrientedTransportListenerFactory
                  System.ServiceModel.Channels.NamedPipeListenerFactory
                  System.ServiceModel.Channels.TcpListenerFactory
               System.ServiceModel.Channels.HttpListenerFactory
               System.ServiceModel.Channels.MsmqListenerFactoryBase
               System.ServiceModel.Channels.PeerListenerFactory

Now let's look at a self-hosted example: You first create your ServiceHost and then decorate it with the endpoint and binding information. Custom bindings are most interesting, since you can see a little of what's going on under the cover. Encoding and Transport Channels are required, and you need to add your transport binding last. Also you MUST properly configure the EndpointListener; in particular you need to select the right transport protocol prefix (e.g. http:// for HTTP or net.tcp:// for SOAP over TCP). The EndpointListeners themselves point (Factory property) to the transport factory.

It seems reasonable to assume that the relevant optimizations (e.g. connection multiplexing, pooling) are implemented in the TransportListenerFactory class which is abstract.

Another guess on my part is that I expect that the HTTP listener factory has some special implementation, since it needs to address IIS6 hosting and self-hosted environments.

Now here is a continuation of my little science project "How does TCP Transport work in Indigo?"

I noticed that the preamble that contains the location URL and the content type has a few length headers:

Now the $64000 question is what are the initial 00 01 00 01 02? And also: are the above fields really identifiers, and if so, what other are there (e.g. 00, 01, 03, ..?) Any takers?

 

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.)

It seems obvious that the data in our web services needs to be framed. In the good old days, where all transport was HTTP this was rather trivial: HTTP headers are rich, and can describe Content-Type, Length etc.

But what happens if you select e.g. the net.tcp transport channel in Indigo?

Well, after pointing ethereal to the wire exchange, I came to the following conclusions:

• All session relevant settings (charset, etc.) are exchanged during the connection setup
• The length of the data is framed based on the relative TCP sequence number:
  • The initial relative TCP sequence number is 1
  • The next relative TCP sequence number is computed by adding the number of Bytes in the packet to the current TCP sequence number.

Interesting approach - standard TCP framing.

During PDC, I learned that the WS-Policy vocabulary in WCF (formerly "Indigo") can be extended through IPolicyImporter/IPolicyExporter and IWSDLConverter. I guess I will play around with this in the next couple of week ...

Meanwhile, anybody who did this already?

There are a lot of things happening in the Indigo world, particularly in the interoperability area. Some notable pieces of information:

• The latest build include the WSFederationBinding, which enables the use of SAML tokens within WCF. Based on the Claims model, it is really easy to convert between claims type like e.g. SAML or X.509, simply by writing our the claims in their respective formats.
• Microsoft encourages two mode of activation for the ServiceHost: outside-in and inside-out. The former constructs a new ServiceHost(), configures it, and then Open() it. This is particularly useful for self-hosted applications. Inside-out is used in the context of container hosted services and requires sub-classing and overriding of the OnActivation() event handler.
  There are quite a few extension points (e.g. for Behaviors) in these approaches: during contstruction and by overriding the OnCreateDescription(), OnApplyConfiguration() event handlers, and when calling AddServiceEndpoints().
  Behaviors are very useful e.g. for putting state information into the ServiceHost.
• The InfoCard subsystem of WCF is acting as an Identity Selector. It mainly uses WS-MEX, WS-Security, and WS-Trust. The latter is optional, but used by ADFS.
• Channel Extensibility is necessary for remote operations, while ServiceModel extension typically handle local issues.
• The BufferManager class is most useful to increase performance in the WCF stack – in fact, it might be the single most important performance booster they are using.
• The XmlDictionaryReader for the Message body is used in the context of binary encoding, to improve the available initial vocabulary for the binary encoder.

The sessions I went to were not quite as architecture and strategy focused as they were in some of the past PDCs, but focused instead on how to use the API. Still, with a little processing, you could get a much better insight into the architecture.

Please check out this excellent article on te Windows Communication Foundation (formerly "Indigo") by Clemens Vasters. He explains the basic ABC (Address, Binding, Contract) in Indigo and shows how it maps to WSDL service, binding, and portType.

It is a fairly introductory article, that does not dive deep, but instead a very neat primer for developers staring to use Indigo.

While Liberty has a very rich framework for SSO, it does not define a comprehensive infrastructure protocol framework for SOAP/XML web services. While this might look as a limitation, it can also be a strength: it's non-dependance on SOAP, WSDL et al. makes Liberty a truely componentizable architecture, where SSO and Identity functionality can be applied to all kinds of Web Service technologies, including e.g. RESTful web services.