There is no magic cure-all
Bill Hilf, Platform Strategy Manager, details Microsoft's
interoperability efforts in a discussion with Anil Patrick R.
Interoperability is not a strong point of IT. What is your
take on this?
My view is realistic, when it comes to interoperability. Im
not a philosopher, but a pragmatist, since Ive spent most of my life trying
to get interoperability happen in a real manner. I look at interoperability
in different ways, but I always start architecturally. This is in terms of building
blockswhat should and what needs to be interoperable. There is no magic
interoperability cure-all for the IT worlds illnesses.
I look at it in terms of what needs to interoperate. For example, a laptop computer
needs to interoperate with a USB device, be it a mouse or a USB stick. Thats
a different type of interoperability than software communicating with software.
These are different layers of the architecture. For each of these layers, the
real question is whether there is a common theme between how these things interoperate.
One term I like to use a lot in this context is translation. You can use it
in any context. For example, what is the translation between the USB stick and
the OS? The translation between .Net and Java? The translation between Microsoft
Offices document format and OpenOffice? How does it all translate?
How can this translation be achieved?
When it comes to interoperability,
we must realise that things are not going to change overnight. We are
not just going to open source everything and find that it all works magically
When it comes to interoperability, we must realise that things are not going
to change overnight. We are not just going to open source everything and find
that it all works magically. What we need to do is to translate between one
system and another and vice versa so as to communicate with each other. This
will involve translatability of platforms at the data and protocol levels. Such
data translations are things that Microsoft and the rest of the industry are
going to do more.
Are Microsofts efforts in this direction bearing
There is the OpenXML work that we have done with Office where everything is
XML-based (Extensible Markup Language-based) so that people can translate their
data to another system if they want. There is a considerable amount of work
that we are doing around Web services. They are mostly XML-based so that we
can have Apache and IIS (Internet Information Server) translating data back
and forth which does not necessarily mean that they have to be the same. So
we can differentiate, which brings up the issue of standards of translation
because they are fundamentally different or diagonal than the open sourcing
of the code. They are different things. This has to be done in an open standards
way so that we can have interoperability between systems.
What does this open standards approach equate to in real
We take that premise and apply it specifically to the domain of open source
and Microsoft software. We use the same constructions and frameworks to think
through the interoperability issues. So when we think about interoperability
with JBoss, the open source Java server, it is on the same lines. This brings
up questions like what needs interoperation? How do we translate data back and
forth? How does it have to be created with the database? How does it communicate
with the database, what needs to be translated? Information flow back and forth
over SQL? What it means is that it needs to be certified with JBoss and certified
with SQL Server so that it works correctly.
The fundamental thing for people is not to have the perception that open source
and open standards are the same. They are actually not.
The good news is that Web services are a strong initiative trying to learn from
mistakes of the past. The vendors including Microsoft, IBM and others are collaborating
to ensure that we have that translation capability.
How do you decide where to start?
We kind of prioritise what is essential
so as to decide what to fix first. For example, we chose JBoss over any
other app server because they had a broad customer base with a lot of
The first question I ask is whether it is a broad customer need. The number
one customer need I see right now is on the server side.
The biggest issue in this area is Active Directory integration.
The reason I know that is because this is the number one support question Red
Hat has had for the past two years. They let us know about it.
So we kind of prioritise what is essential so as to decide
what to fix first. For example, we chose JBoss over any other app server because
they had a broad customer base with a lot of needs. The same themes were popping
up time and again on the integration front. That is why we prioritised JBoss.
What is your roadmap on the open source interoperability
In some ways we actually approach the open source interoperability issue the
same we do interoperability with any Independent Software Vendor (ISV). In some
ways it is different because in many cases these new solutions have made a difference.
We do interoperability projects with companies like JBoss. The actual infrastructure
used to get technologists working together are the same tools that are used
for any ISV. The dynamic that makes it interesting is that in many cases it
is competitive. JBoss is an example. Another aspect is that many of these might
not be companies but rather a couple of guys from a university. So in a lot
of cases it is about managing communications and expectations.
Is Microsoft getting anything from from its collaborative
As we go and talk to companies like JBoss, SugarCRM and others, we find that
many of them if not all of them, have a substantial base on Windows. Many people
use JBoss and Linux, i.e., Java and Linux, but a lot of their users run on Windows.
So we look at that as an opportunity in terms of business as well as providing
more options for our customers. Now our customer has Linux and Java as standard
in addition to .Net and Windows.
Do you envision a future where products work together out
of the box without middleware like those from BEA or Microsoft Biztalk?
Thats an interesting question and my answer is that this will not happen
directly. Let me talk with respect to BizTalk here. Lets say I have a
process where I have to sell a part thats stocked in a warehouse. I can
take the part and put it in a box. The box has to get an invoice and a shipping
statement on it. It then has to go to a shipping house and from there shipped
to the customer. This is a business process.
What things like BizTalk do is that they broker this process in a way that it
creates a workflow for other systems in the right sequencethe right order,
right SLA (Service Level Agreement)and makes these things easier. This
is a type of interoperability that requires what used to be known in earlier
years as TP (Transaction Processing) monitors. Earlier we had Tuxedo, IBM also
had a lot of these tools. Then we have BizTalk.
The concept is similar. Can we take a business process and sequence it and package
it in the right way so that it can then translate to other systems. This need
cannot be met by just a Web service since this is a complicated transaction.
In interoperability it is important to make sure that this is done in a way
where we can get things done properly with a mix of different platforms. If
all the systems have to be Microsoft for things to work, that defeats the purpose.
We want to be at a stage where systems can be any platform, but the workflow
processing engines like BizTalk will be able to orchestrate business processes.
So these solutions will always exist.
On the interoperability front, there are Enterprise Service
Bus (ESB), Business Process Execution Language (BPEL), and so on. How do they
fit into the big picture?
I think they will all have to aggregate around Web services or perish. That
is because there is so much momentum behind Web service initiatives. While not
everything is going to be a Web service, they will have to be standardised and
part of the World Wide Web Consortium (W3C) processes for them to succeed. The
days of expecting everything to work as silos cannot be the way ahead.