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: http://svn.apache.org/viewvc/incubator/stonehenge/contrib/stocktrader/)

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:

StonehengeM1_high_level_architecture

 

  • 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 http://cwiki.apache.org/confluence/display/STONEHENGE/Index. The PHP and Java implementations were contributed by WSO2 using their Web Services Frameworks (http://wso2.org/projects).

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):

StonehengeM1-labscenario

A detailed “interoperability walkthrough” explaining all the different configurations has been posted at http://cwiki.apache.org/confluence/display/STONEHENGE/Stonehenge+Interoperability+Walk-through

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

StonehengeM1_user_scenario_buy_dotNET

 

StonehengeM1_user_scenario_buy_PHP

Transaction confirmation

StonehengeM1_user_scenario_transaction_dotNET

 

StonehengeM1_user_scenario_transaction_PHP

Portfolio summary information

StonehengeM1_user_scenario_portfolio_dotNET

 

StonehengeM1_user_scenario_portfolio_PHP

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.