For those that have managed to avoid the pitfall of SOA for SOA’s sake, composite applications are one of the biggest driving forces behind deployments.  The reason for service enablement in the first place is so that you can compose them into new applications more easily and richly. As a byproduct, you tend to get more abstraction, and therefore control, over the application logic.  Yet, there are some dirty-little secrets about composite apps – compared with your old-fashioned “monolithic app” they introduce some new challenges:

1.       Composite apps are more complex for IT to deploy, manage and evolve.  The fact that pieces of the composite app may be distributed across servers, platforms and possibly organizational boundaries creates a need for more sophisticated management solutions than exist today. 

2.       Composite apps present new challenges around scalability, performance and reliability.  With classic monolith apps there are tried-and-true strategies for optimizing apps to scale in demanding environments.  But how can you predict the way that a composite app will perform, when the underlying services may have been built for much different levels of scale? How can you make a composite app resilient to failure, so that if one service stops working it doesn’t bring the whole app down?

3.       Composite apps often require much greater cross-vendor interoperability.  The benefits of reusing services for new apps can’t be limited to services you’ve created on a single vendor platform, since most enterprises live in a fundamentally heterogeneous world.  Therefore composite apps need to be able to easily interop across.NET, Java and legacy mainframe environments.

Despite what some vendors might tell you (which tend to be driven by their monetization goals), solutions to the above problems are challenging.  Customers often avoid these issues with initial SOA deployments, but as they start to pursue enterprise-wide initiatives and develop numerous new composite apps these challenges become more apparent.

However, there are existing architectural patterns for addressing these concerns.  Think about how the world’s largest distributed, service-oriented application - the Internet - addresses the above challenges.  Every second of the day the Internet gains more scale and power as new nodes are added to the fabric of the internet.  All nodes on the Internet are virtualized – I don’t need to know machine addresses, or know how many boxes any website is running on. You can dynamically add new computing resources without having to take down the Internet, and if any failure occurs the Internet is resilient enough to route traffic around individual points of failure.  The Internet is also fundamentally interoperable – you can add computing nodes of any vendor platform as long as you adhere to standards-based protocols.

I’ll apply these characteristics of the Internet to the world of SOA, and describe something that I’ll call a distributed “Service Network”.  The Service Network should be able to automatically detect when you’ve added new computing nodes to the network and take advantage of scaling out with greater power (without requiring complex setup or configuration – it should auto-detect that more resources are available for use).  A Service Network should allow you to add new services without having to worry about physically deploying bits on servers or taking down machines – it should dynamically be “virtualized” against the underlying physical resources.  The Service Network should also let you mix/match services across vendors, as long as you stick to open standards.  And most importantly, the Service Network should keep the composite application from knowing about failure of hardware, automatically redirecting access to new services somewhere on the network without the app ever skipping a beat.

Last week I wrote about how Greg Leake was going on tour to talk about his latest work on both StockTrader and the new Configuration Service.    Greg’s configuration service is one of the first examples of a general purpose Service Network built using .NET managed code.  These code libraries can be leveraged as part of your SOA projects to develop new composite application that mix/match services across both .NET and Java.  And you can take advantage of the Config Service with your existing services and apps, requiring only 20 lines of code to reap all of the advantages of the Service Network concept. 

For more on this, check out a recent article by Redmond Magazine that describes how Greg’s efforts are helping shape the future of SOA and composite applications.  We’ll be using the feedback we get from this initial work to drive requirements and patterns into our on-going product development efforts.

And remember, if a vendor tells you that you have to open a PO to “do SOA” and the money isn’t for training, start asking hard questions.

So check out Greg’s blog for good stories from the tour, updates to the code and more. Oh, and if you’re interested in how many cups of coffee Greg drinks in a day…the Twitter section is especially interesting.

This week is an exciting one for Microsoft, particularly those of us who work on the Server & Tools Business—today we’re launching new versions of three cornerstone technologies—Windows Server 2008, Visual Studio 2008 and SQL Server 2008. The theme is “Heroes Happen Here”—meant to recognize the valiant efforts of our IT Pros and Developers every day. These are the individuals who help make real, meaningful connections between IT and the business.

One of folks on my team who is making heroes happen is Greg Leake, who is a technical marketing director. In his own  words, Greg’s purpose is to “improve the lives of developers.” To do this, he has created a lab, and spends time on interoperability testing for Web Services as well as performance testing. No matter the time of day or night, it’s likely that you will find Greg in his lab, which means he probably also holds the record for most cups of coffee in one day.

Once again Greg jumped in the ring to find out just how far we could push the perf boundaries for Windows Server and .NET against other publicly available apps like IBM’s J2EE StockTrader perf application.

My favorite findings:

·         Microsoft Windows Server 2008 with .NET Framework 3.5 delivers 117% better throughput than IBM WebSphere 6.1 on Red Hat Linux for the Web Application Server test using the IBM-designed Trade 6.1 benchmark as well as delivers 93% better throughput for the remote services test.

·         On the Sun Microsystems’ WSTest Web Services benchmark, .NET StockTrader demonstrates 94% better throughput on Windows Server on processing Web Service requests and 86% better throughput performance for the EchoStruct operation.

The paper on MSDN presents the benchmark results of two key application server workloads:

1.     Trade 6.1 Application Server Benchmark created by IBM – This benchmark serves as IBM’s primary capacity planning tool for WebSphere, and as their primary performance sample application for Java Enterprise applications. The benchmarks detail throughput results for the IBM implementation vs. the functionally equivalent of the .NET Framework 3.5 implementation.

2.     WSTest Web Services 1.5 Benchmark, created by Sun Microsystems – This benchmark tests an application server’s performance as a Web Service Host, measuring the platforms ability to process Web Service operations involving HTTP/SOAP requests, isolating the networking stack, Web server integration, and XML serialization engines within the application server.

For more information and complete results, check out http://msdn.microsoft.com/stocktrader! You can also download the application with the benchmark tests and try it yourself! Also, look out for the upcoming .NET StockTrader 2.0 in the next few weeks!

We’re officially through day 2 of the SOA & Business Process Conference!  For me it was great to hear all the hallway conversations between attendees doing real-world SOA today, and sharing tips for success. In fact, Day 2 was all about the ecosystem, and we had some key announcements from partners including:

JNBridge: Announced their JMS Adapters for the .NET Framework and the JNBridge Adapter for BizTalk Server. The new adapters provide a streamlined and automated method to connect JMS (Java Messaging Service) capabilities to Microsoft .NET Framework applications and BizTalk Server.

IDS Scheer: Announced the 2008 availability of its integration of the ARIS Platform with Microsoft BizTalk Server.  As a preferred BPM modeling and monitoring partner for Microsoft’s Business Process Alliance, IDS Scheer is previewing the integration at the conference this week.

SOA Software: One of our key partners for SOA governance, did a session detailing the topic and helping customer use their .NET assets to deliver a first class governance experience.

We also talked about the availability of the Managed Services Engine, available today on CodePlex. Time to go Trick Or Treating! But first, and check out the Video recap of the conference today: http://channel9.msdn.com/Showpost.aspx?postid=352776

On the heels of the BizTalk Server 2006 R2 launch, this morning we shared some news at the Microsoft SOA & Business Process Conference. Robert Wahbe, VP of the Connected Systems Division, outlined a vision for the future of SOA and Business Process Management which highlights the increased role that Services and Models will play in the next generation of applications. Robert also talked about "Oslo" which is a codename for a set of technical investments which will help take model driven design mainstream.

Why is this set of investments needed? Boundaries. Boundaries exist in today's business that limit productivity and the role IT plays in solving business problems. These include examples such as the following:

• Boundaries between business and IT - the inability to work as seamlessly as they would like because they lack a common language
• Boundaries between technologies – the alphabet soup of protocol, and standards used to connect businesses and apps.
• Boundaries across the web - the inability to easily cross the firewall due to security and identity constraints
• Boundaries between an organization, its suppliers, and its customers – leveraging SaaS where it makes sense
• Boundaries in time – as soon as a system is deployed, like it or not, its legacy

While modeling technology is not new, it is far from mainstream. The vision for modeling tools is the same now that it has been for years - to allow a broad set of users participate in the design of applications. The relationship between business and IT might be best described in a simple language analogy. Business speaks English, IT speaks German. They both speak a little Spanish. When the scenario is reasonable simple, they communicate without issue using Spanish. When things become increasingly complex, they both default to their native language. They didn't go wrong speaking two languages; they went wrong using a subset of a third language to try to communicate. Modeling technology today is the "third language" in this scenario. There are two major limitations with the current approach.

First, models represent the application or business logic at a specific moment in time; therefore they are rarely in synch, and generally lack the richness that the full application provides. In the finance world, this would be the equivalent of a balance sheet—that is correct when it is printed, but quickly becomes outdated as financial transactions take place. By the very nature of this type of modeling, there is a hand-off where the model leaves the designer, and is sent to the developer to be built in the form of an application. This handoff is imprecise and causes errors. Programmers are brilliant and incredibly hard workers. However, they have to make guesses in interpreting models and translating them into code. Additionally, business professionals change their mind often and tweak models—sometimes without communicating their changing needs to the IT side of the fence.

Second, having models live in isolation means that no one has a single view of the application end to end. For example, business analysts might model requirements, processes, and policy; architects might model schemas, services contracts, and high level designs; developers might create executable models for workflow and rules; IT professionals might model deployment maps and application health.

Each model is critical, but they are all trapped in silos.  This is really inefficient. There is only one way to solve this — the tools need to be unified, and the models need to be the application. No more import / export. No more silos.

So hopefully this gives you a view into what we see as the problems and stumbling blocks the industry is facing, which brings us to the announcement of something we are really excited about. "Oslo"

Oslo is the codename for a set of technical investments that will be delivered through the next versions of our application platform products such as Visual Studio, System Center, BizTalk Server, BizTalk Services, and .NET Framework. Oslo will take model driven design mainstream. To make this real, we are investing in two key areas.

First, we will continue to invest deeply in our SOA platform. We will invest to make sure customers can easily span client, server, and cloud through BizTalk Server and BizTalk Services.  We want to enable organizations to build applications that use web-based infrastructure, premises infrastructure or both.

The second investment area is to make modeling a mainstream part of application development.  We are building a general purpose modeling language, tools, and repository to bridge across all the models within an application, moving models to the center of application development. Models will no longer just describe the application, they will be the application.

"Oslo" will surface through the products our customers already know. We are announcing investments in five key areas across the Server and Tools business.

• Server: BizTalk Server "6" will continue to provide a core foundation for distributed and highly scalable SOA and BPM solutions, and deliver the capability to develop, manage and deploy composite applications.
• Services: BizTalk Services "1" will offer a commercially supported release of web-based services enabling hosted composite applications that cross organizational boundaries. This release will include advanced messaging, identity and workflow capabilities.
• Framework: The .NET Framework "4" (not to be confused with 4.0) release will further enable model-driven development with Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF).
• Tools: New technology planned for Visual Studio "10" will make significant strides in end-to-end application lifecycle management through new tools for model-driven design of distributed applications.
• Repository: There will also be investments aligning the metadata repositories across the Server and Tools product sets.  System Center "5", Visual Studio "10" and BizTalk Server "6" will utilize a common repository technology for managing, versioning, and deploying models.

While the dream of model driven design is not new, our approach to solving it is. The technology investment we are making will make this real. While we are proud of our early efforts, we are even more proud that our partners share this vision with us. Having our Business Process Alliance partners see the value in this technology and commit to using it in their own offerings is a testament to its value. Having a broad ecosystem around this technology will drive additional productivity gains for customers.

So excited you want to learn more? Feel free to check out the following sites for everything from paterns and practices, to videos highlighting today's news:

www.microsoft.com/soa

www.microsoft.com/presspass/events/soa-bpm

We've had a ton of interest in the detail behind the .NET Stock Trader application.  With both Interoperability and performance information, it seems like there is something for everyone.

Last week Greg Leake (developer of the application) took time with Channel 9 to go through the application and answer several questions we have received thus far.