There is no magic cure-all

Bill Hilf, Platform Strategy Manager, details Microsoft's interoperability efforts in a discussion with Anil Patrick R.

Bill Hilf

Interoperability is not a strong point of IT. What is your take on this?

My view is realistic, when it comes to interoperability. I’m not a philosopher, but a pragmatist, since I’ve 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 blocks—what should and what needs to be interoperable. There is no magic interoperability cure-all for the IT world’s 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. That’s 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 Office’s 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. 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 Microsoft’s efforts in this direction bearing fruit?

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 life terms?

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?

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 front?

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 efforts?

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?

That’s an interesting question and my answer is that this will not happen directly. Let me talk with respect to BizTalk here. Let’s say I have a process where I have to sell a part that’s 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 sequence—the 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.