Notes from SDForum's Interoperability event
Yesterday I spent the morning at the
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.
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,
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
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
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
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.
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
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
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,
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).
There were two more panels but I had to leave for other work.