May, 2009

  • Interoperability @ Microsoft

    Announcing PHP SDK for Windows Azure… and much more!


    I’ve just arrived at TechEd India where I’m going to talk about interoperability in my sessions “Build Mission Critical Applications on the Microsoft Platform Using Eclipse, Java & Ruby” and “Developing PHP Applications using Microsoft Software & Services”. In addition to presenting the on-going activities that Microsoft is driving to strengthen interoperability, I’m excited to be able to demo a new set of interoperability projects related to PHP. I’m going to give you a glimpse of these projects in this post for those that are unable to join us in India.

    The first PHP interoperability bridge that we’re announcing is the PHP SDK for Windows Azure. This SDK is the result of an open source development project by RealDolmen, for which Microsoft is providing funding. I’d like to personally thank Maarten Balliauw of RealDolmen for his work on the project. The goal of the SDK is to provide high-level abstractions that enable PHP developers to interoperate readily with Windows Azure.

    Keep in mind that the Azure Services Platform has been designed to be open, standards-based and interoperable.

    The Azure Services Platform’s support for XML, REST and SOAP standards means that any of the Azure services can be called from other platforms and programming languages. To facilitate the interoperability between the Azure Services Platform and non-Microsoft languages and technologies, Microsoft has  provided funding for two other SDK projects that support 3rd party programming languages: Java SDK for Microsoft .NET Services and Ruby SDK for Microsoft .NET Services

    The PHP SDK for Windows Azure focuses on REST and provides the following core features:

    • PHP classes for Windows Azure blobs, tables & queues
    • Helper Classes for HTTP transport, AuthN/AuthZ, REST & error management
    • Manageability, instrumentation & logging support


    Windows Azure is the foundation of the Azure Services Platform and it includes the services hosting environment for the platform. At MIX 2009, Microsoft announced the inclusion of FastCGI in Windows Azure’s hosting environment. The FastCGI protocol enables developers to run web applications on Windows Azure that were written using 3rd party programming languages including PHP. This opens up new options for PHP developers to deploy their applications. For example, in the context of the PHP SDK for Windows Azure you have the 2 following options for deploying your PHP web applications:


    A Technology Preview of the PHP SDK for Windows Azure will be released by RealDolmen under a “BSD” license. This version of the SDK supports interoperability with Windows Azure blog storage. A functionally complete version of the SDK – additionally supporting tables and queues - is expected to be available from the download project site by the fall of 2009. Of course you're welcomed to try out and provide suggestions & feedback to the project by joining the user forum.

    The second piece of announcement, I’m excited to make is the launch of a series of third party projects that offer samples and toolkit that enable PHP developers to easily include in their web applications the following Microsoft technologies:


    Features for PHP developers

    Embedding Silverlight in PHP

    Include Silverlight controls in PHP web applications

    Web Slices and Accelerators in PHP

    Include IE Webslices & Accelerators in PHP web applications

    SQL CRUD Application Wizard for PHP

    Automatically generated a simple “Create, Read, Update, Delete (CRUD)” PHP application from a table in SQL Server

    Virtual Earth Integration Kit for PHP

    Include Microsoft Virtual Earth maps in PHP web applications

    Microsoft is providing funding for a series of projects, of which this first batch have been developed by Accenture. The third party projects are available on under a BSD license:

    More to come; stay tuned and once again I encourage you to take a look. Feedback is very welcomed.

    Vijay Rajagopalan, Principal Architect, Microsoft Corp.

  • Interoperability @ Microsoft

    Binary to Open XML (B2X) Translator: Interoperability for the Office binary file formats


    [05/18- Update:
    this translator is highlighted in today's Document Interoperability Inititice (DII) event that just happened in London ]

    In support of Microsoft’s ongoing efforts to increase the interoperability of its various technologies, we have partnered with Dialogika to create a translator that converts the Microsoft Office binary file formats (.DOC, .XLS, and .PPT) into the Office Open XML standard format (.DOCX, .XLSX, .PPTX).

    A majority of the world’s documents are available in the binary Office formats and, for developers working with these formats (including .DOC, .PPT, and .XLS.), Microsoft published the specifications under the Open Specification Promise (OSP) in June 2008.


    A new version of the Binary to Open XML (B2X) Translator has just been released ; this version adds support for PowerPoint (.PPT) and Excel (.XLS) files:

    Supported .XLS Features

    Supported .PPT Features

    • Shared Formulas
    • String Formatting
    • Data Type Formatting (number, date, currency, etc.)
    • Cell Formatting


    • Textbox Formatting
    • Shapes
    • Animations
    • Notes (including Formatting)

    (Detailed features )

    From an architectural point of view, the translator can be seen as a series of pipelines during which transformation steps are applied to translate from the binary to Open XML format:


    (more details on )

    While it has been possible to manually convert documents between formats by opening the file in the relevant application and saving in the other format, before the release of the translator there was no software tool to automate this task as a stand-alone application, or in a batch mode.

    So from the end-user point of view the translator offers two options:


    While using Windows’ context menus to translate the files is self-explanatory (right-click, convert to…) doing so from the command line warrants a bit more study. The command line utility consists of three separate executables, one for each file type (ppt2x.exe for spreadsheet, doc2x.exe for document, and xls2x.exe for presentation). The executables use the same command line syntax, and support the usual basic command line options:
    This includes the input filename, output filename, and the level of debug verbosity. The resulting command is easy to include in automation scripts, and batch processes.

    The command-line architecture allows the translators to be integrated into existing systems such as document management systems running on a server.

    Using the source of B2X translator (ppt2x.exe, doc2x.exe, xls2x.exe), you can rebuilt them using the .NET Framework on Windows or Mono on Linux, thus ensuring portability across operating systems and platforms.

    As an open source project, the Translator is a solid foundation for engineering work around the Office binary format. Dialogika’s development team has put together a few “how to” guides, including the Freeform Shapes in the Office Drawing Format guide, that helps to explain the specification and give some valuable tips. For developers and ISVs the code of this translator can be reused in their own applications enabling a wide range of document interoperability solutions.

    We’re excited by this latest release making the translators more functional and addressing practical document conversion scenarios. Of course, there’s still work ahead of us! We are currently in the planning stage for the next version. In addition to the goals outlined above, it is very important to us that the translator adequately addresses practical user scenarios. To this end, we would love to hear feedback on this release as well as your feature requests for the next version. Please provide your feedback on the Sourceforge site.

  • Interoperability @ Microsoft

    OpenXML Document Viewer v1 released: viewing .DOCX files as HTML


    [05/18- Update:
    this translator is highlighted in today's Document Interoperability Inititice (DII) event that just happened in London ]

    The OpenXML Document Viewer project idea came from the discussions with the participants of the Document Interoperability Initiative (DII) workshops (in particular last year’s Cambridge event). The point was to find a way to simply be able to view Open XML files as HTML. Following up, Microsoft provided funding to start the Open XML Viewer project, an open source project developed by MindTree Limited. The first beta version was unveiled at the last DII in Brussels, giving a first peak of the viewer (see a demo here).

    Today I’m excited to announce the version 1.0 of Open XML Document Viewer. It provides direct translation for Open XML Documents (.DOCX) to HTML, enabling access to the information in the Open XML format from any platform with a Web browser. The project, which already includes a plug-in for Firefox IE7 and IE8 and now also offers a plug-in for Opera, allows users to view Open XML documents (.DOCX) within the browser on Windows and Linux platforms without the need to install Microsoft Office or other productivity products.
    Check out the demo my colleague Jean-Christophe Cimetiere has recorded to see the Open XML Document Viewer in action from the end user perspective:

    For more detail on the supported features go visit the project site 

    In principle, the functionality of the viewer is simply to translate OpenXML files into HTML for direct consumption in a web browser.

    Here’s a scenario (the sample document is attached):

    · You have an Open XML document (.DOCX). Let’s view it in Office Word 2007 first:


    · Then, let’s say you email this file to your friend who’s using OpenSUSE Linux. Your friend saves the document on the desktop and drags & drops it into the Opera browser:


    · The Open XML Document Viewer kicks off and creates the HTML that’s displayed by the browser:


    The experience is similar with Firefox on Linux and and with Internet Explorer 7/8, Firefox 3.0.x, and Opera 9.x on Windows:


    Next let’s examine the high level architecture:


    The core of the project is the Translation Engine that does most of the work, meaning opening the .DOCX document, reading, mapping and transforming to HTML. The Translation engine is exposed as a client side browser plug-in with support for Firefox, Opera, and Internet Explorer, and as a cross platform command line translator for use in server side applications.

    The result is a translator that enables Open XML document (.DOCX) visibility within browser applications without the use of any of the usual office productivity or word processing applications, across multiple platforms and environments, as either a server side application or as a client side end user solution. Developers, Independent Software Vendors (ISVs), Solutions Integrators & Mobile Solution providers can use these tools to enable their customers to view Open XML documents on heterogeneous platforms and browser applications. Be sure to check out the Demo web site. It showcases server side document processing scenarios that represent very typical use cases.

    We’re very excited with this new version and look forward to your feedback.

    Join us at

    Sumit Chawla, Technical PM/Architect, Microsoft Interoperability Team

  • Interoperability @ Microsoft

    Apache Stonehenge, interoperability at work



    When Microsoft decided to participate in the Apache Stonehenge project our goal was to deliver guidance through practical applications that span languages and platforms and demonstrate how to achieve interoperability. As I mentioned a few months ago multiple implementations including .NET, Java, Php, Python & Ruby of the Stonehenge Stocktrader sample application have been committed to the repository (check the code here:

    Since then we’ve been working and I’m glad to report that we’ve reached a key milestone: to deploy a first set of these samples and make them work together. The Stonehenge community is currently going through the final testing required for the “M1 release”, and it is taking votes on a release. From a simplified architecture point of view the Stonehenge Stocktrader application is built as follows:



    • A User Interface layer delivering the web front end (HTML)
    • A middle tier layer including a Business Services layer (login, account processing) and an Order Processing layer (buy/sell transactions)
    • A Data Access layer to provide access to the database for the middle tier layer (Business Services and Order Processing)
    • And finally the database where the application data lives

    So far we have been focusing on the .NET, PHP, and Java interoperability scenarios, and have deployed the three Stocktrader implementations in multiple configurations. If you want to reproduce the environment, you can get the installation and configuration steps for the .NET, PHP and Java versions at The PHP and Java implementations were contributed by WSO2 using their Web Services Frameworks (

    Then we ran a series of tests mixing and matching the layers from the three implementations, playing with the configurations and leveraging the Web Services standards, including WS-Security, to provide message integrity and security.

    In short (that’s only a partial view of the scenarios), the following diagram shows where we were able to achieve interoperability using Web Services (each arrow represents Web Service based dialog):


    A detailed “interoperability walkthrough” explaining all the different configurations has been posted at

    From the end user perspective whichever middle tier layer (Business Services or Order Processing) is activated during the scenario is completely transparent, since each of the implementations executes the same transactions. Even though the most interesting part of the interoperability walkthrough happens at the Web Services standard level, I wanted to give you a sense of how the scenario looks from multiple perspectives. In the following example, we are looking at the “Buy Stocks” transaction in both the .NET & PHP applications (the current Java version does not implement any UI):

    Stocktrader .NET

    Stocktrader PHP

    Buying stocks




    Transaction confirmation




    Portfolio summary information




    This new outcome from the Stonehenge project is very encouraging. With the implementation of the WS-* Standards, we get the benefit of distributed applications and platforms. We recognized that it is not always easy to achieve these goals, but I really feel this type of practical guidance will be helpful for these types of scenarios.

    We’re very encouraged by the success of this first step, and we invite you to take a closer look to give comments and feedback.  There are lots of roles for you to participate in the project, whether you are a developer or a user: developing code on your preferred platform, suggesting new scenarios and applications that will provide real value to people in your field, or even just looking over the code and documents to see if they address the challenges you might have had developing interoperable services. 

    We look forward to getting your comments and ideas about how to keep this project moving in a direction that meets real people’s needs.


  • Interoperability @ Microsoft

    Open XML made easier for Java developers with Apache POI


    [05/18- Update:
    Apache POI project is highlighted in today's Document Interoperability Inititice (DII) event that just happened in London ]

    When developers are tasked to deal with document file formats it might be challenging to do the right thing if you don’t have a good experience with a particular format, and need to crack it open and understand all the details.

    For Java developers and Microsoft Office file formats there’s a very interesting solution with the Apache POI project, which provides a Java API to access Microsoft Office formats. Last year Microsoft and Sourcesence announced that they would collaborate to add support of the Open XML file format to the Apache POI project, and the resulting Open XML support has been integrated as part of POI 3.5 beta 5.

    The end result: Good news for Java developers who need to manipulate the Office Open XML files (.XLSX, .DOCX, .PPTX), because it really makes it easier for them to do the job!

    To illustrate the point, let me walk you through a demo scenario that uses Apache POI Java Libraries and actually combines it with the PHPExcel project (for PHP developers) and the Open XML Format SDK 2.0 (for .NET developers). My goal is just to give you a sense of the type of scenarios you can easily develop using multiple languages and multiple platforms.

    We will make that demo available with more explanation in an article on Before we get into the demo itself I want to thank Julien Chable and Maarten Balliauw for their help in building this demo.

    For now, let me walk you through the scenario. For the sake of our demonstration we are going to show how raw data can be consumed by a Java web application using the Apache POI, to create an .XLSX file from scratch. How that file can then be accessed and modified by a PHP application (with PHPExcel). And finally how the resulting file can be digitally signed and finalized via the .NET framework using the Open XML Format SDK.

    Here’s the data flow:


    Step 1 of the scenario starts in the Java Web applications:


    Once the “Create Spreadsheet” button is pressed, it creates the files:


    And does some processing to inject the initial XML data and formatting. The result looks like this:


    Most of the Java code required to do this fits in this code snippet:


    Step 2, moving to the PHP application, the UI is similar:


    This step adds cell protection, renames the .XLSX file, changes cell formatting, and inserts additional content formatting. The result looks like this:


    And the code to accomplish it looks like this:


    Step 3, finally, from the ASP.NET web applications using the Open XML Format SDK:


    Where the code for adding the digital signature looks like this:


    Easy, don’t you think?
    Stay tuned, as I said earlier, we will follow up on with a more detailed article.

    Additional background on PHPExcel and the Open XML SDK:

    The PHPExcel project is an open source project available on Codeplex. It consists of a set of classes for PHP that enables PHP applications to read and write to various file formats. These formats include HTML, PDF, and the relevant one for our demonstration…Excel 2007’s .XLSX format. This class set supports features such as setting spreadsheet meta data (author, title, description ...), multiple worksheets, different fonts and font styles, cell borders, fills, gradients, and adding images to spreadsheets. In parallel to this project, there is also the sister project PHPPowerPoint, which is intended to operate along similar lines as the PHPExcel application but with a focus on the .PPTX file formats. Both of these projects are built around the OpenXML standard, and the PHP framework. Read this nice article: Use PHP to create Open XML Spreadsheet reports

    The Open XML Format SDK provides methods for .NET developers to access and manipulate XML content, including XML data contained in OXML document formatted files. It provides strongly typed part classes to manipulate Open XML documents. The SDK also uses the .NET Framework Language-Integrated Query (LINQ) technology to provide strongly typed object access to the XML content inside the parts of Open XML documents. The April 2009 CTP release also adds support for the validation of Open XML documents.
    Read Brian Jones' blog to go deep on Open XML SDK. 

    Jean-Christophe Cimetiere  - Sr. Technical Evangelist

  • Interoperability @ Microsoft

    Kerberos Interoperability Testing Workshop hosted by Microsoft


    A few weeks ago Microsoft’s Kerberos team participated in the Kerberos Interop Workshop organized by the MIT Kerberos Consortium, being hosted here at the Microsoft campus here in Redmond. I had a chance to spend some time with the Microsoft folks (Michiko Short, Jeremy Viegas, Larry Zhu and Yi Zeng from the Microsoft’s Kerberos team) who participated in the event to discuss what happened. We thought it would be interesting to share a quick summary.

    This sort of interoperability workshop is an effort to gather developers together in a single location, to actually plug them into a network environment together and help each other work through the interoperability challenges associated with their current development efforts. In attendance were representatives from Cornell University, Centrify, Microsoft, MIT, Safe Mashups, and Sun Microsystems.

    A bit of background…

    For those of you that aren’t familiar with Kerberos, it is a network authentication protocol developed by MIT as part of a joint project with Digital Equipment Corporation and IBM designed to produce a campus wide distributed computing environment in 1983. Kerberos provides a mutual authentication system, and a high level of encryption, both designed to ensure network and data security. Kerberos was accepted by the Internet Engineering Task Force (IETF) as a standard in 1993. Since its creation Kerberos has become the most widely deployed system for authentication and authorization in modern computing networks.

    In September of 2007, MIT founded the MIT Kerberos Consortium to help establish Kerberos as the universal authentication platform for the world’s computer networks and many organizations joined since then (full list here). The consortium hopes that by opening up ongoing development of Kerberos to other interested parties, it will be possible to expand the scope of work being performed, enhance the evolution of Kerberos, and to help engage potential adopters.
    The MIT Kerberos has also a group on Facebook.

    Microsoft’s collaborative efforts regarding MIT and the Kerberos Consortium are nothing new. Microsoft was one of the original sponsors, and is represented on the board of directors by Microsoft’s Director of Development Slava Kavsan. To help standardize the testing processes for Kerberos developers, Microsoft contributed the GSS Monger interoperability testing framework to the consortium. It is now available on Codeplex using MS_PL, as an ongoing open source project.

    You may not know, but Microsoft has been using Kerberos as the default authentication package since Windows 2000. You may actually be using Kerberos authentication today in your solutions without even realizing it since it is part of negotiated authentication.

    Back to the interoperability plug fest…

    How does an interoperability plug fest like this work? Each participant prepares a desired test plan based on their own current projects and challenges, but beyond that the lab is very ad-hoc. All of the participants bring systems with their code/applications to the event; then everybody hooks up to the network and starts testing out scenarios against each other’s applications using MIT realms or Microsoft domains. This collaborative environment allows participants with different implementations of the same standard to test their interoperability in a real world environment, helping to identify and solve the road blocks that might otherwise cause them problems.

    One of the scenarios for the plug fest consisted of MIT & Microsoft collaborating on testing efforts for their next release. MIT has developed an implementation of a new Kerberos RFC (jointly defined by MS/MIT, and the IETF standards body). Since it was the first implementation there were no other implementations to be tested against. So, the Microsoft team developed a second implementation for the event for validation/comparison/interoperability testing.

    Cornell University came prepared with two scenarios to investigate. The network environment that both scenarios operate under consists of a mixed MIT realm with an Active Directory domain. This results in certain complications when it comes to integrating a Single Sign-on solution. The first of their scenarios was built around integrating CUWebAuth, the open source, Kerberos based, web authentication application they have built, with key IIS services that are connected to a central Active Directory. This integrates single sign-on for Microsoft applications such as Outlook Web Access with other campus web services that require a login. The second of their scenarios centered on integrating WebDav with the Kerberos based login across their network. Complicating matters, the systems used across this network are very diverse and heterogeneous, including desktops running Windows, Linux, and Mac. The Cornell University team has had trouble implementing Kerberos with WebDav on Windows machines that are not part of a domain. Initially, they were uncertain that support for the desired functionality was even possible for Windows based systems. The Microsoft developers attending the plug-fest were able to provide the necessary insights regarding how the problem could be solved on Windows Vista and higher machines.

    Peter Bosanko of Cornell University had this to say about the event:

    “At the KC Interop we worked side by side with an impressive group of Kerberos experts from MIT and Microsoft. This was extremely fortunate for us because our interoperability issues were all about tying together Microsoft systems with an MIT KDC. By the end of our first day we had already accomplished more than we expected to accomplish over the three day Interop.”


    What’s in it for Microsoft and other participants?

    Interoperability is a key pillar for the Kerberos team. Knowing that many customers are going to have a heterogeneous environment, ensuring that Microsoft’s implementation of Kerberos works with other implementations is considered a key to success. By getting all the people together at events like this gives developers an opportunity to really dig into how we work together in an efficient way, solving problems in real time. Also it allows us to see how our applications interoperate with all sorts of other systems and applications that we normally don’t get the opportunity to see. Finally, it allows us to help explore, expand on, and develop standards while learning from a diverse group of experts.

    We were delighted to see the turnout for this event, and wanted to extend a thank you to the MIT Kerberos Consortium for putting this together, and to the Kerberos team here at Microsoft for sharing it with us. With any luck the collaborative efforts of the participants will enable the ongoing development work on the various Kerberos implementations to proceed unhindered.



    Jean-Christophe Cimetiere - Sr. Technical Evangelist

Page 1 of 1 (6 items)