We Live in a Heterogeneous world dont we

We Live in a Heterogeneous world, don’t we? John Whiteway, Astra Zeneca Saksham Gautam, AWS Simon Thurman, Microsoft Interoperability

Objectives of this session • Discuss the considerations when making a platform, development strategy, … decision.

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

Heterogonous and Homogenous – no Greek Myth… Delivering a major new component of an Enterprise System John Whiteway

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 (40 MB of VB 6…), 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-oflife…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 / Share. Point 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 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…

What we mean by Interop ? “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

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 ! Suppot. Tool Across application stack Office e. CTD. NET / JAVA Future. Client

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 Me. Go 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 – Biz. Talk, 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 !!!

The Windows Azure Platform Developer Experience Use existing skills and tools.

Windows Azure & Interoperability Saksham Gautam, Developer

ukinterop. cloudapp. net © Copyright AWS 2010

Architecture Azure Queue Processor Azure Table © Copyright AWS 2010

ukinterop. cloudapp. net • Written in Java using the Restlet framework • Uses Windows Azure Queues and Tables for Storage • Running in Windows Azure Compute Demo. . © Copyright AWS 2010

rubyukinterop. cloudapp. net • Work in Progress. . . • Written in Ruby on Rails • Uses Windows Azure Queues and Tables for Storage • Running in Mongrel on Windows Azure Compute Demo. . © Copyright AWS 2010

http: //microsoftpdc. com/Sessions/SVC 50

Azure Run. Me • 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 Demo… © Copyright AWS 2010

. cscfg File <Configuration. Settings> <Setting name="Data. Connection. String" value=". . . " /> <Setting name="Trace. Connection. String" value=". . . " /> <Setting name="Packages" value="packagesjre. zip; packagesdist. zip" /> <Setting name="Commands" value="runme. bat"/> ……… </Configuration. Settings> © Copyright AWS 2010

Storage Client Libraries • http: //www. windowsazure 4 j. org/ • http: //github. com/johnnyhalife/waz-storage • Allow Java/Ruby apps to access Windows Azure Storage. © Copyright AWS 2010

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. windowsazure 4 j. org/ – http: //azurerunme. codeplex. com • Active Web Solutions – http: //aws. net – http: //blogs. aws. net/atc • saksham. gautam@aws. net © Copyright AWS 2010