Notes for OOPSLA Panel

App Servers: One Size Fits All … Not?

AbstractEnterprises today must recognize and accommodate a diversity of requirements in their systems.

These requirements are appear at many levels: from the choice of hardware platforms through the delivery of application-supporting enterprise services, such as identity management and content management. This diversity presents a rich opportunity for software vendors, but also presents significant challenges: how do we accommodate the small business, the medium-sized business and the global enterprise, in manufacturing, entertainment, financial services, retail and government (to name but a few)? How do we enable and facilitate enterprise schematization, a must-have for any effective integrated application delivery process?

 At the lowest level, the response is that one size does fit all. We place our bets on a programming

model and a supporting infrastructure that realizes that programming model at run-time. We argue that this model and infrastructure provide the most cohesive, productive, and performant choice in the marketplace. Unfortunately, when we begin to focus on addressing the business processes and capabilities of an enterprise, within a vertical domain, we discover that we don't even know how to measure fit. It's this understanding that we, as an industry, must strive to achieve. Our solutions need to feel tailor-made, but be sewn from consistent patterns at every level, from object lifecycle management and messaging to business frameworks and process definition.

 There's one occasion where one size must fit all, however: standards for interoperability. Every

vendor today recognizes that interoperability is the key to our successful co-existence. No system is greenfield, no environment is legacy-free, no enterprise runs on homogeneous infrastructure. To operate in today's IT climate, standards-based interoperation is a set-in-stone requirement in every domain.

Introduction

• My role – Architecture – Listening to the needs of Microsoft's enterprise customers – Focused on the architect, best practices, IT alignment – Pat Helland was supposed to participate in panel– Was at PDC – announcement of Longhorn, Whitehorse (part of

DSI, modeling, DSL for system definition) – more later

• Spin – Mostly going to talk about IT problems, rather than application

server features– And how complete programming environments, from tools to

run-times, solve these problems – Not to divert panel but rather to contextualize

Challenges

• For our customers 1. Managing complexity 2. Managing cost

• 70/30 50/50 (Accenture IT Value survey)• Development, deployment, management

3. Delivering new capabilities to grow business

• For us as vendors – Selling the value of integration as the key to our customer’s

problems– Selling the need to spend money to save money– More broadly, we have the problem of serving customers large

and small, in a breadth of industries

The Naïve Solution

• The historical product vendor perspective (Microsoft infamous)

• At one level, we do argue that one size fits all: Windows plus .NET; unified programming model, toolset, run-time – So what is the Microsoft application server? Is it .NET? Is it

COM+? No - it's Windows - that's the platform; .NET is the programming model

• Services that you expect from an application server – Transactions– Security – Lifecycle management: pooling, activation

• So the term is ill-defined, particularly because it's not all-or-nothing on the Microsoft platform - you can use capabilities, or not

• Important: runs on the client

But,

• J2EE containers and Windows/.NET are pretty much equivalent in terms of functions and features – We argue differentiation in terms of quality properties:

• Value of integrated stack • Better productivity• Most mature and integrated web services support • Cost/performance

– But not trying to pitch the platform • You can build great applications on Windows/.NET and

J2EE; you can build bad applications on Windows/.NET and J2EE – Almost every customer I work with has deployed both

• So it's clearly not the application server that determines whether or not an application delivers business value

So …

• What is important is how the whole programming environment - from early lifecycle analysis through implementation, test, deployment and management - supports building effective systems – The "application platform" – Tools – Architecture/DSLs/frameworks/models

• Reuse is derived from consistency or "conceptual integrity" (Brooks); consistency is derived from architecture, frameworks

– These, in turn, derive from effective decomposition of capabilities

Punchline• So now the question becomes one of determining "fit" - knowing

when you've got the right "size" solution for the problem – Identification of appropriately-decomposed services, assembled in well-

defined ways, helps us categorize our sizes – Construction of systems with architecture, frameworks, models using

appropriate tools, is the key to sustainable development • DSI – focus on connecting services, mapping to logical data center

– Architecture evaluation is a mechanism to assess fit • Codification of best practices, specialization of horizontal

capabilities in vertical domains – Embodied in architecture, frameworks – Capabilities exposed as services

• We need to figure out what size means– Customers are desperate to understand this

Final Note

• There is one place where one size must fit all: standards for interoperability

• The evolution of web services has been proving a demonstration that we, as an industry, have achieved something fundamentally different from efforts of the past: we can integrate heterogeneous technologies into systems that deliver on collaborative business processes – We're enabling new value chains – But web services are about protocols - we need the guidance,

the best practices, the tools, the frameworks to allow them to deliver business value

• We also have a great deal of infrastructural work to do

Q1

• What are the features you consider important that are common amongst the various application servers, and what are the features that differentiate them?

– A great deal of commonality these days – Basically there is substantial feature alignment between J2EE

vendors and Microsoft with .NET – Differentiation is largely coming outside the run-time – These days, fast XML serialization has become a big deal as

a feature– Support for more flexible messaging topologies (i.e. a

message-based, rather than RPC-based model) for services– Manageability

Q2

• I work at a (small, medium, large ... pick one) company and we are considering using (J2EE, .NET, BEA, Websphere, ... pick one) on our application. What should we look for in making the final decision?

– Do architecture analysis – Assess TCO - training, development cost,

operations cost, maintenance cost

Q3

• What are the advantages to using an application server? What are some other ways of developing without one? – Some application types don't need complete

gamut of application server capabilities – With Windows, you mix-and-match; the OS is

the application server, including transaction support (COM+), queuing (MSMQ), pooling and so on  

Q4

• When is it necessary to use an application server? When is it better to avoid it?

– Resource management is the key thing: lifecycle control, pooling, etc. are things you don't want to build yourself

• Also don't want to build reliable messaging • Also don't want to build a DTC

– If you don't need these capabilities, you don't need an "application server"

– Applications using J2EE often just deploy servlets – no EJBs, no transactions

Q5

• How can I find out more about application servers on the market without having to buy each one and build something with it? – No substitute for actual practical experience,

but can build something bite-sized to get the point, as long as the something is aligned with the business

– Can almost always evaluate for free– Microsoft funds bake-offs and POCs

.NET Single-OS

• Yes, no apologies– Again, this comes down to the definition of

platform – it’s not .NET (that’s the programming model); it’s Windows

• Microsoft delivers value across the technology stack, in an integrated way

• But not to the exclusion of interoperability, which is a key strategic direction today

Indigo

• Secure, reliable, transacted web services

• New programming model– Transparent messaging in-process, cross-

process and cross-host

• Just announced at PDC; part of Longhorn wave

Yukon

• In service-oriented architecture, multiple message request/response pairs participate in a single business transaction– Need correlation– Need transient (activity) data

• Manages idempotence

– Multiple traditional ACID transactions

• Yukon offers built-in support for this – Service Broker

Whitehorse

• Service-oriented modeling• Multiple viewpoints across lifecycle and from

business to IT– SDM is multi-DSL

• Service Definition Model connects design time to deployment time (logical data center)– Key to manageability – probably the most interesting

new “app server” capability to consider

• Framework population/code generation from SDM - roundtrip

Services - 1

• Not activated, stateful like objects• Not forward-deployed (no shared code)• Large-grained• Autonomous• Fundamental driver:

– Allow independent evolution of client and server

• Appropriate within application boundaries (platform, deployment, trust) and across

Services - 2• Object Orientation

– Assume homogeneous platform and execution environment– Share types, not schemas– Assume cheap, transparent communication– Are linked: Object identity and lifetime maintained by infrastructure– Typically require deployment of both client and server

in sync– Are easy to talk about and become a natural path for customers to follow– Customers have 20+ years of experience and great intuition about what

“object oriented is”• Service Orientation

– Assume heterogeneous platform and execution environment– Share schemas, not types– Assume variable cost, explicit communication– Are autonomous: Security and failure isolation are a must– Ease “continuous deployment” of client and server separately– Builds on ideas from component software, distributed objects, and MOM– Dominant theme is to manage/reduce sharing between services

• Object Orientation– Assume homogeneous platform and execution environment– Share types, not schemas– Assume cheap, transparent communication– Are linked: Object identity and lifetime maintained by infrastructure– Typically require deployment of both client and server

in sync– Are easy to talk about and become a natural path for customers to follow– Customers have 20+ years of experience and great intuition about what

“object oriented is”• Service Orientation

– Assume heterogeneous platform and execution environment– Share schemas, not types– Assume variable cost, explicit communication– Are autonomous: Security and failure isolation are a must– Ease “continuous deployment” of client and server separately– Builds on ideas from component software, distributed objects, and MOM– Dominant theme is to manage/reduce sharing between services