Recently, some of my colleagues and I were on the Microsoft campus discussing developer trends. Here's our conversation with Burley Kawasaki, who's the director of product management for the developer platform. My colleagues here are Mike Otey, Jeff James, and Michele Crockett.

So, just to kick it off Burley—Can you give us an overview of app tier development?

Burley Kawasaki: Sure. When I talk about the application tier, I think about it, in very simple words, as what the application developer builds on top of to really support their efforts. And when we think about how applications have evolved over the last few decades, applications are getting more and more distributed by nature. Even when you had mainframe-based apps, you typically had a couple of mainframes, either in different regions or different departments that had to somehow distribute a logic across them. As we've seen applications evolve from the mainframe world, to client/server, to the web (service oriented), and now to the cloud, the common theme is that applications are much more highly distributed, and that means in some ways they are getting much more complex to manage. It's not all moving in a single place; now the bits and pieces of the application are distributed across multiple machines, multiple organizations potentially. When you're running these cloud-based apps, you don't even have control over the parts of the application that may be given.

Sheila Molnar: So are these applications built using the new Azure services?

Burley Kawasaki: Well, they certainly can be. When I talk about the application tier, I think about this really stretching across both the on-premises world and the cloud. I think that's one of the principles of our Software+Services vision is that you as an app developer can build in a consistent way using a consistent set of tools. So if I build an application today that I may want to target the Azure service platform, that's great, I can take advantage of all the exciting new things that are available, and I may have advantages in that I can get it running faster, because I don't have to provision a lot of IT infrastructure. At some point you know that that may change—you might want to bring part or all of that app in house. So, what I don't want to do as an app developer is have to rewrite my app, or rearchitect it, because I now want to run it on my own hardware, as opposed to running it in the cloud.

So, the application tier should really hide or distract a lot of the runtime away, so that the logic app model we've implemented really is agnostic to where it's being run. And that's part of the investments we're making in the app tier in the .NET framework itself, and in the layers that build on top of the .NET framework.

Michael Otey: You mentioned a new type of application called a composite application. Can you explain a little bit about what they are and what makes a composite application?

Burley Kawasaki: A composite application, simply put, is combining multiple bits and pieces—typically services—to form a new app. It's a style that I think is particularly of interest to customers these days, because they have a lot of existing investments—their package apps, their mainframe apps—and given the current economic situation, they are reluctant to rewrite them or replace them anytime soon. At the same time, their users are asking for new capabilities, better usability, better access to information, and so leaving your existing, mature applications in place—running on the mainframe, running on SAP—but then being able to compose those services into a new user-centered application is very compelling and powerful, so we're seeing a ton of interest from our customers right now in creating them. You don't see them as mashups—you're combining existing logic into a business process to support a new user need.

Sheila Molnar: And how do IT pros work with all of these applications?

Burley Kawasaki: Well historically, very painfully. They haven't had a lot of the tools that existed for the more traditional applications. They've had a lot of resources available for managing and scaling web applications and the like, so part of the investments we're making are not just in the platforms and tools, but also in technologies that will ship inside Windows Server.

One of the projects that we have under way is code-named Dublin. It's a sort of extension to the Windows Server application server role. And it really targets the IT professional in helping them give the same kind of management and control and visibility to these much more complex, composite apps.

Michael Otey: You mentioned that there's a CTP for Dublin that's available?

Burley Kawasaki: That's right—we first announced it in the fall, and at PDC we released the first community technology preview for Dublin. We also, same time, offered a number of other related technologies from the composite apps perspective, such as new things in the .NET Framework around Windows Communication Foundation and also Windows Workflow Foundation.

Sheila Molnar: Could you say a little more about how Communication Foundation and Workflow Foundation work together, helping a developer create a composite app?

Burley Kawasaki: Sure. Well one of the things we typically see is, you want to build an app that combines all these services together, and the services probably aren't in the same format—certainly weren't written by the same vendor, and probably not even in the same language. So, you can use any sort of mix of services—it could be based on standards, it could be using some of the new Web 2.0 protocols like REST or POX, or it could be a proprietary API to a package vendor. WCF, Windows Communication Foundation, gives you a universal way to describe and enable these services for a composite app, regardless of what the underlying technologies are. Even if it's cross-platform, you can expose things in the mainframe as a WCF service.

So WCF—think of it as the sort of common language or way to bring all these services together. And then how you bring them together is usually in terms of some type of process or workflow—you want to assemble them to first check to see if they're an existing customer, then you want to do a credit check, then you want to update their record. And so there's this whole set of steps—called services—across different apps across different platforms. So Windows Workflow Foundation is a companion part of .NET Framework, which helps you describe as a developer the sequencing and order of the services that are part of the composite app.

Sheila Molnar: What would you say the business value of creating composite apps is?

Burley Kawasaki: I think a lot of it has to do with end-user productivity, and also end-user satisfaction. You're really creating an application that is more directly aligned with the way they do their work. So if the business is under more pressure to cut costs and get more done with less, you want to make it as easy for, say, the call center rep to do their job, or the sales  person out in the field to get access to information. So rather than them having to navigate back and forth between four, five, ten different applications that they normally have to use today, a composite app brings it all to their fingertips and allows them to really use the process and workflow that is most natural to them.

Sheila Molnar: I understand that Oslo is now part of the .NET Framework?

Burley Kawasaki: Yeah, we also at PDC released a CTP of Oslo, which is a code name for the next generation set of investments in modeling technologies. Modeling has been around for decades as a concept, but really is applied mostly to up-front design and requirements. We're trying to connect modeling now down to the developer space, to really make it friendly for developers, so that they can describe an app and actually have it be part of their app, not simply a piece of paper that they print out. And so this sort of use all the time internally is the model, is the application. So if I as a developer change the model, it should instantly change the behavior of that running application.

So we think it builds on top and extends on a lot of existing skills they already have with .NET and Visual Studio, but it adds a much more hands-level of productivity, because they get to change a higher level description of the business logic, as opposed to having to get down into the plumbing and writing lots and lots of implementation code.

Jeff James: How would a LAMP developer, someone that's using a LAMP stack, integrate and take advantage of some of the services that you talked about?

Burley Kawasaki: Well, it's a great question, and there's a number of ways they can. And certainly going back to some of the standards and protocols that we provide through the Windows Communication Foundation, whether you're building an app on-premises or in the cloud, you can take advantage of WS-*-type standards, or Web 2.0 standards like REST, there's a lot you can do at the Web services standards level. But if you're trying to even directly program it, we also offer SDKs that target the Java world, the Ruby community, so for example as part of the .NET services component of the Azure services platform, we offer SDKs so a lot of app developers who are fluent with other languages or tools can also take advantage of these capabilities.

Sheila Molnar: We understand that there's a new language called M?

Burley Kawasaki: Yes—M. M as in model. It's part of our overall Oslo investments. It's a way to really reach out to the developer community—in a lot of the usability testing that we did early on, we found that modeling was not being accepted as broadly by developers, because many of them preferred to be at a command line, or a textual metaphor, as when they write code today. So, giving them the ability to stay inside their developer tools, and write down in text their description, is an important way to reach that community.

So, M is one of the ways that you can experience Oslo. You can also choose to use visual tools. So, it's a part of broadening out the types of uses.

Sheila Molnar: I had a question on collaboration, and I guess this might be our last question. How does modeling improve collaboration across the whole development life cycle?

Burley Kawasaki: Well, it's a great benefit I think of taking a model and then being able to store that model inside a repository. So part of the Oslo investments are around a repository, based on SQL Server, that allows teams of people to interact with, edit, and modify the same model. So everyone might have a slightly different view—if I'm a developer, I might want to see maybe more detail than a business analyst or an IT pro may want to see. But we can all interact with the same model and collaborate and have a different experience, but it's the same source of truth, so that if I change it as a developer, that's the same thing that an IT pro would see, or the same thing that a business analyst would see.

Sheila Molnar: Well thank you very much Burley, we've really appreciated talking with you today.

Burley Kawasaki: My pleasure.