Transcript Introduction

Notes for OOPSLA Panel
App Servers: One Size Fits All …
Not?
Abstract
Enterprises 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 runtimes, solve these problems
– Not to divert panel but rather to contextualize
Challenges
•
For our customers
1.
2.
Managing complexity
Managing cost
•
•
3.
•
70/30  50/50 (Accenture IT Value survey)
Development, deployment, management
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 welldefined 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, crossprocess 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