Yesterday I spent the morning at the SDForum Interoperability Forum. Two Sun engineers, Graham Hamilton and Nick Kassem, participated in two different panels. The interop discussions are directly related to the Sun/Microsoft Web Services interop effort I'll be talking about in this blog. Here are my notes on the event.

Keynote

The morning started with Anne Thomas Manes of the Burton Group. She noted that the IT industry tends to view homogeneity as ideal, thinking it makes life easier. But IT homogeneity is unattainable. So plan to live with IT diversity. As an aside, she pointed out that diversity is good in social situations.

Since Infosystems run your business, when your diverse systems do not work together then you have missed opportunities and security risks. Therefore we need interoperability.

What enables interoperability? Standards (she referred to WS-* specs as WS-Veritigo, "it makes your head spin"). But just because its "standard" does not mean it works. Therefore WS-I profiling. Better, but issues remain that can't be resolved with profiling (e.g., attachments), therefore new W3C standards (e.g., MTOM). And still more standards: composable Web Service Framework (e.g.,WS-RX, WS-AT, WS-Trust - the ones we are focusing on in our Sun/Microsoft interop work), competing standards (e.g., WSDM/WS-Management; WS-Notification/WS-Eventing; BPEL/WS-CDL; SAML/WS-Trust; Liberty ID-FF/WS-Federation) and unsubmitted "specs" (e.g., WS-Federation, WS-Policy, WS-MetadataExchange, WS-Eventing, WS-Transfer, WS-Enumeration).

Her conclusion: Interoperability is the goal. Standards are the solution. Standardization takes time. Vendors do the standardization and pursue their own agenda.

Web Services Interoperability Panel

This panel, moderated by Andy Daecher of Deloitte, featuring Edward Cobb of BEA, Nick Kassem of Sun and Weston W. Swenson of Forum Systems. Answering a question of web service adoption Nick pointed out that Java Web Services Developer Pack adoption has been very good. He pointed out that the next wave (e.g., WS-AT, WS-RM, WS-Security/Trust) will make web services enterprise class.

Ed said that even with the wire protocol standards to enable interop in place there is still a need for tools to build web services. Wes focused that statement by saying that his customers gravitate towards simpler standards and that the standards are way ahead of implementations.

This lead to a discussion of ease-of-use in general. Nick agreed that the next wave needs to be simpler to use. He pointed out that in our interop work, instead of introducing a bunch of JSRs/APIs we plan to use existing JAX-WS APIs enhanced with QoS introduced via policies set with graphic tools. Ed followed saying we need to do more with infrastructure and metadata and less with APIs. Everyone agreed that ease-of-use needs to be addressed to foster adoption.

On a different topic, Wes said none of his customers directly expose a web service endpoint. Instead, they intercept and firewall web services at the XML level. For example, his company does that now for that IRS - e.g., they scan a 6 GB submission from GM to the IRS - including scanning for *.exe attachments).

Responding to a question regarding scaling and performance when using QoS features (e.g., WS-Security, WS-RM) Nick said that in many case you can flow the XML infoset over multiple types of bindings (e.g., JMS, SMTP, Binary/TCP) besides over HTTP.

The panel concluded with Wes saying that his customer's are not waiting for perfection in standards - just adequate coverage.

Fireside Chat

This panel, moderated by Anne Thomas Manes, featured Graham Hamilton of Sun, Kelvin Lawrence of IBM, and Andrew Layman of Microsoft.

Andrew started out saying programmer's expect things to work. Within one language that is generally attainable. But it is hard to accomplish across languages. So we do not expose objects any longer - just data. Anne suggested that when writing web services that one should not think one is working in Java. Instead one should think one is working in XML. Andrew seemed to agree by saying one should focus on the schema. Anne noted the lack of tooling to indicate when violating "contracts."

Graham disagreed with this position, saying programmer's should not reach down into details of XML. Stay at language level and let infrastructure handle protocol details. Disagreeing with Graham, Andrew pointed out that EDI is celebrating its 30 year anniversary - they did it right: they defined a wire format. In response, Graham clarifies benefits of staying at the language level: do not bind too early - stay at high level of language types and let infrastructure negotiate protocols to use (e.g., fast infoset, TCP, etc). Graham regards it as a measure of success if the programmer does not need to know about "it." Andrew seemed to move closer to Graham's position when he said that one should get the application data types agreed upon (e.., schema) then let infrastructure use metadata to negotiate protocols.

Anne said we already have a minor form of that success in deployment descriptors that separate security from the program so that programmers without security expertise can still write business logic, letting the security be applied by administrators.

Anne directed the chat to a new question: where do you draw the line between what should be handle by infrastructure and what should be handled by middleware? Andrew said that vendors recognize patterns in applications and move into the middleware infrastructure. Graham said that middleware should make common cases simple (rather than cover everything via a multitude of options). Tools help, but cannot hide complexity. The platform must be simple too. Andrew said some things move into the middleware due to pressure from customers to automate the boundaries between their systems. Kelvin noted that customers want to talk in terms of their business (e.g., supply chain), not protocols. Tools should implement industry profiles. Graham said middleware should simplify programmer's job, even if it make the middleware implementation harder.

A member of the audience pointed out that Graham's last statement contradicted Dick Gabriel's "Worse is Better" thesis - that Multics attempted to do the right thing even if it made the implementation harder whereas Unix just gave up and returned an error code that the application must handle. Graham responded by noting balance of power has shifted since those days: programmer's are now far more expensive than computers, so let computers do the work, not the programmer.

Identity Management panel

This panel, moderated by Rena Mears of Deloitte, featuring Prateek Mishra or Oracle Karen Wendel of Identrus and Kim Cameron of Microsoft

Prateek started with a mini-tutorial. Your identity is stuck at your employer or bank (and identity provider) but needs to be used at other places (services). So you need to transmit your identity from your provider to the service via a protocol and token representation (e.g., SAML). You need to determine under what conditions you should let your identity travel: governance (e.g., liberty). And finally, how do "normal" people manage their identities.

Kim noted the Internet was built without an identity layer, so we have an immense variety of ad hoc solutions. To solve this chaos we need an identity metasystem above these solutions analogous the TCP over Ethernet. In other words, the other solutions are not replaced. Instead, an identity metasystem gives a common interface. He claims a simpler user experience leads to a more secure environment.

Kim also pointed out that we do not have one single identity. Our identity depends on our context. When we read the paper we use one identity, for filling out a tax return we use another. He gave an example of the Belgium national identity system. When he visited there he said city mayors were upset because they were required to sign documents with their single citizen identity rather than their previous "mayor stamp." Karen gave an analogy: VISA - simple interface to user but manages a complex relationship of credit, risk, trust.

Rena said that the area of security has different definitions for the same terms. Kim said assertions are identical to claims but that he likes the term 'claim' better. A claim is an assertion that is in doubt. And, in security, everything is in doubt.

Karen noted that identity is often confused with security. Identity enables you to sign things, to incur a liability, to enter into regulatory transactions. But if is hard to separate real identity from technologies that support it. Identity is not necessarily equivalent to security nor authentication, but some technologies blend identity and security (e.g., PKI).

etc

There were two more panels but I had to leave for other work.