Interoperability

We Live in a Heterogeneous world,

don’t we?John Whiteway, Astra ZenecaSaksham Gautam, AWSSimon Thurman, Microsoft

• Discuss the considerations when making a platform, development strategy, … decision.

Objectives of this session

• John, shares his experiences • Saksham, adds another dimension to the

decision

Agenda

Delivering a major new component of an Enterprise System

John Whiteway

Heterogonous and Homogenous – no Greek Myth…

Takeaway Key Point

Please ensure that tool and technical stack choices are the result of Architectural Processes

( i.e. do your Architecture Stuff, and viable choices should be systematically derived for technologies to use )

Executive Summary

Achieving an appropriate set of project tools should be a reasoned, systematic exercise, based on project facts, company rules, project specifics

Whatever *ilities you require, and whatever NFR’s to support, YOUR choice of tools / software stack must deliver

Real world projects often depend on interoperability as a key mechanism – more so in future

Interoperability is a complex, multifaceted issue, it’s not just a technical issue Build as many interop characteristics into an application as your Service /

Application / System Roadmap may indicate

Scene Setting

Enterprise critical system Formed of major components / subsystems

user client (40MB of VB6…), utility client, config client, publishing subsystem, content management subsystem

10,000 users, worldwide use, terabytes of data, 24/7 If it breaks, the company are obliged to inform stock market

investors…it’s an A* critical system

“John, we note that the User Client is reaching its end-of-life…can you advise on a solution to this please…”

Top Level Architectural Ponderings…

We must not break it – the system, with our new work They’ll want the solution as soon as Better not spend too much There is the company IS standards to comply with If we provide a lower performance solution, we’re in trouble

/ jail The users have seen all this Bing / Office / Web /

SharePoint stuff…will our solution pass muster ? We’ve got to work with / interop with all the other

subsystems…

…and in the future…

We’ll need better application “characteristics” Flexibility, lower cost of ownership, versionable

components ( less down time ) Ensure we can interoperate not just with the other

components / subsystems AS THEY ARE NOW, but with those subsystems WHEN THEY ARE UPGRADED

Ensure the future roadmap of the system is supported by our solution…we’re about to spend several million dollars, we’re in the future proofing business for sure !

As many *ilities as we can muster…

A little detail – Interoperability as example Clearly many many issues to consider, in fact TOO many

for my humble discussion, so we can look at interoperability as an area which is representative of those to be tackled, so a little more detail…

“Two separate things, working together” ?

- not originally designed to do so - some defined boundary or separation between

things ( so two classes belonging to the same context in a single memory

space are not really interop…)

- some protocol or communication- hard to achieve the result of the interop by

other means-Eg. DOM in Office, Drag and Drop @OS level,

sending files between apps, XML, interop solutions of many sophistications of course

What we mean by Interop ?

Interoperability – Definitions

Diagram from http://cyrusxp.com/images/gph_Interoperability.png

Some numbers…

Some Interops we required SO MANY

interops…and the tools are pivotal in many cases

…described

The team have to be able to work the tools ! – hey, that’s interop !?!

The tools themselves have to interface / interop / supply their clients – other systems, plug-in’s, end-user views

Don’t forget standards, the tools and technologies must support the protocols / interfaces / languages ( grammar ) etc. which allow any heterogeneous system to exist

…and don’t forget that ANY COMPONENT has an intrinsic Architecture Profile, find / derive / record that as required

How to do the magic – heuristics ? No single simple answer, but try: Ensure you have a good profile of what the new subsystem must provide Using known solutions, architectures, stacks, tools, i.e. don’t be too proud to

nick something which works, that’s a massive risk mitigation Get MEASURES ( ho ho ), for each subsystem, what’s its capacity, protocol,

latency, SLA etc ? Get maps – what technologies, what interop to they support, what protocols /

interfaces, what expandability ( plug in / introspection etc ) Build and test candidate stacks, and test key *ilities Don’t be afraid to create LOADS of checklists of Architecture characteristics of

interest – security, performance, published specifications and other capability information

Similarly, simple weighting tables can be very handy to – weigh – up various options…if the process you’re using MAKES THE CHOICE FOR YOU – excellent ! ( if things are problematic e.g. during performance testing, systematic choice shows due diligence AND aids problem resolution )

Some Client Stack Permutations

…Interop, here and there !

Office

eCTD

.NET / JAVA

SuppotTool FutureClient

Across application stack

Microsoft says…

http://www.microsoft.com/interop/principles/default.mspx Open Connections, Standards Support, Data

Portability Principle I: Open Connections to Microsoft Products Principle II: Support for Standards Principle III: Data Portability Principle IV: Open Engagement

JW says…

Most project sticking points are not PURE tech, but appropriate tech helps to resolve

Great PURE tech <> Tech to get a job done ( oft made mistake )

Toolset must support a clean approach, don’t mix Meccano and Lego unless necessary ( and you may have to create some MeGo to connect them ! )

Great tech solutions are consumed as Capabilities / Features, not tech per se

I DON’T want to “fiddle with my tools” during the project, lashing tools together, prototyping untried combinations if avoidable, hunting for tech support route…

Microsoft Interop Supporting Technologies…

Easy – BizTalk, WCF, <etc> Stated strategy .NET framework AZURE platform Does the technology support / enable an interop intention

that we have ? Interop is a MAJOR focus for Microsoft currently – find and

use the many excellent resources available SIMILAR MATERIALS EXIST FOR OTHER *ILITIES !!!

Developer ExperienceUse existing skills and tools.

The Windows Azure Platform

Compute Storage Management Relational data Management Connectivity Access control

platform AppFabric

Windows Azure & Interoperability

Saksham Gautam, Developer

© Copyright AWS 2010

ukinterop.cloudapp.net

Architecture

© Copyright AWS 2010

Queue Processor

Azure Queue

Azure Table

• Written in Java using the Restlet framework

• Uses Windows Azure Queues and Tables for Storage

• Running in Windows Azure Compute

ukinterop.cloudapp.net

© Copyright AWS 2010

Demo..

• Work in Progress ...• Written in Ruby on Rails• Uses Windows Azure Queues and

Tables for Storage• Running in Mongrel on Windows

Azure Compute

rubyukinterop.cloudapp.net

© Copyright AWS 2010

Demo..

Anatomy of a Java Worker RoleWorker Role

JRE

Worker.class

.NET

Worker.dll

Run() Process.Start()

http://microsoftpdc.com/Sessions/SVC50

Azure RunMe

• http://azurerunme.codeplex.com • Allows Java apps to run on Windows

Azure (or Ruby, Python ... etc)• Just ZIP your app and put it in Blob

storage• Your app must

– run on Windows as non-admin user– be self contained– have no traditional install or setup– “Run from a BAT file”

© Copyright AWS 2010

© Copyright AWS 2010

© Copyright AWS 2010

Tracing over Service Bus

© Copyright AWS 2010

Demo…

.cscfg File

<ConfigurationSettings> <Setting name="DataConnectionString" value="..." /> <Setting name="TraceConnectionString" value="..." /> <Setting name="Packages" value="packages\jre.zip;packages\

dist.zip" /> <Setting name="Commands" value="runme.bat"/> ………</ConfigurationSettings>

© Copyright AWS 2010

Storage Client Libraries

• http://www.windowsazure4j.org/• http://github.com/johnnyhalife/waz-storage

• Allow Java/Ruby apps to access Windows Azure Storage.

© Copyright AWS 2010

Tables BlobsQueues

Conclusions

• Windows Azure Compute and Storage is interoperable with Java.(& Ruby, Python etc).

• App fabric service bus provides scalable network infrastructure

• Windows Azure actually *makes sense* for some Java apps

• http://ukinterop.cloudapp.net

© Copyright AWS 2010

Links and Resources

• Resources:– http://ukinterop.cloudapp.net– http://www.windowsazure4j.org/ – http://azurerunme.codeplex.com

• Active Web Solutions– http://aws.net– http://blogs.aws.net/atc

• saksham.gautam@aws.net

© Copyright AWS 2010

© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.

The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions,

it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.