BEA White Paper

BEA microService Architecture™

Making Enterprise Middleware as Flexible as
the Applications It Runs
Copyright

Copyright © 1995–2006 BEA Systems, Inc. All Rights Reserved.

Restricted Rights Legend

This software is protected by copyright, and may be protected by patent laws. No copying or other use of this soft-
ware is permitted unless you have entered into a license agreement with BEA authorizing such use. This document is
protected by copyright and may not be copied, photocopied, reproduced, translated, or reduced to any electronic
medium or machine readable form, in whole or in part, without prior consent, in writing, from BEA Systems, Inc.
Information in this document is subject to change without notice and does not represent a commitment on the part of
BEA Systems. THE DOCUMENTATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND INCLUDING
WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
FURTHER, BEA SYSTEMS DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING
THE USE, OR THE RESULTS OF THE USE, OF THE DOCUMENT IN TERMS OF CORRECTNESS, ACCURACY,
RELIABILITY, OR OTHERWISE.

Trademarks and Service Marks

Copyright © 1995–2006 BEA Systems, Inc. All Rights Reserved. BEA, BEA JRockit, BEA WebLogic Portal, BEA
WebLogic Server, BEA WebLogic Workshop, Built on BEA, Jolt, JoltBeans, SteelThread, Top End, Tuxedo, and
WebLogic are registered trademarks of BEA Systems, Inc. BEA AquaLogic, BEA AquaLogic Data Services Platform,
BEA AquaLogic Enterprise Security, BEA AquaLogic Service Bus, BEA AquaLogic Service Registry, BEA Builder, BEA
Campaign Manager for WebLogic, BEA eLink, BEA Liquid Data for WebLogic, BEA Manager, BEA MessageQ, BEA
WebLogic Commerce Server, BEA WebLogic Communications Platform, BEA WebLogic Enterprise, BEA WebLogic
Enterprise Platform, BEA WebLogic Enterprise Security, BEA WebLogic Express, BEA WebLogic Integration, BEA
WebLogic Java Adapter for Mainframe, BEA WebLogic JDriver, BEA WebLogic Log Central, BEA WebLogic Network
Gatekeeper, BEA WebLogic Personalization Server, BEA WebLogic Personal Messaging API, BEA WebLogic
Platform, BEA WebLogic Portlets for Groupware Integration, BEA WebLogic Server Process Edition, BEA WebLogic
SIP Server, BEA WebLogic WorkGroup Edition, Dev2Dev, Liquid Computing, and Think Liquid are trademarks of BEA
Systems, Inc. BEA Mission Critical Support, BEA Mission Critical Support Continuum, and BEA SOA Self Assessment
are service marks of BEA Systems, Inc. All other names and marks are property of their respective owners.

CWP1496E1206-1A
BEA White Paper – BEA microService Architecture

Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Evolution of Service-Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

First wave: Services transform applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Second wave: microServices transform middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Benefits of microServices to the enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Footprint optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Fine-grained best-of-breed middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Minimally disruptive upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

BEA microService Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Separation of concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Security and management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Product packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Join the BEA Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

About BEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
BEA White Paper – BEA microService Architecture

Introduction
For years, middleware vendors have exhorted enterprises to adopt Service-Oriented Architecture (SOA). They
claimed that transforming monolithic application silos into flexible service assemblies would increase flexibility
and decrease costs. They were right.

Ironically, the very middleware these vendors provided to support SOA suffered from the same monolithic silo
mentality. Each vendor provided a mostly fixed “stack” that included all the features necessary for running any
set of mission-critical services. While feature-rich stacks delivered a tremendous amount of value, they could be
unwieldy. Enterprises couldn’t adapt a stack to meet the needs of specific installations, such as front-end Web,
network edge, and remote office.

The solution to this contradiction is for middleware vendors to take their own advice and transform monolithic
infrastructure stacks into flexible microService assemblies—meaning no more “one size fits all” installations. By
using microService assemblies tailored to specific purposes, companies save on hardware, maintenance, and
management. They get a richer middleware ecology that can supply best-of-breed assemblies to meet special-
ized needs. Upgrades to individual microServices arrive more quickly and cause less disruption.

BEA is leading the charge to deliver microService-based middleware, and has already begun to move every
product line—BEA AquaLogic™, BEA WebLogic®, and BEA Tuxedo®—to microServices. As this process continues,
BEA enterprise customers will encounter increasing levels of flexibility in the way they purchase, deploy, and main-
tain these products. By the time this process finishes—sometime in 2008—they will find these products poised to
deliver a whole new generation of increased value.

Services provide flexibility, and companies have adopted Service-Oriented Architecture so that their information
systems can respond to a more rapidly changing business environment. Of course, this adoption results in a
more rapidly changing application environment. Companies need infrastructure that is just as flexible, including
services all the way down to the operating system.

1
BEA White Paper – BEA microService Architecture

Evolution of Service-Oriented Architecture

First wave: Services transform applications
Service-Oriented Architecture (SOA) represents the latest evolution of distributed enterprise computing. As in all
distributed computing models, software components communicate with each other over a network. But unlike
other enterprise approaches, SOA does not view an application as a monolithic block of functionality. Instead, it
views applications as dynamic assemblies of smaller, yet individually coherent, services.

For example, consider Figure 1’s greatly simplified version of a traditional architecture in a telecommunications
company. There are two applications here, Provisioning and Billing. Each has a silo of functions. Some of them,
such as Contact Management, are nearly identical, requiring tight data synchronization. In other cases, there are
dependencies such as that of Usage on Technician Manager and Network Manager. The monolithic approach
implicitly assumes that only other functions in the Provisioning application will invoke the Technician Manager
function and thus be privy to the details of its internal implementation. Therefore, fulfilling external dependencies
on functions like Technician Manager often requires that same detailed understanding of the internals. Finally,
Product Configuration and Pricing require more subtle integration that takes into account complex process flow.
The underlying problem here is that both applications are responsible for different aspects of the “product”
concept, so coordinating them requires handling all the possible product management cases.

Of course, most companies have more than two applications, and synchronizing and integrating them all can
require tremendous effort. Unfortunately, this initial effort doesn’t complete the challenge, since any enhancement
or upgrade to one application may destabilize all the others. As a result, a bundle of monolithic applications can-
not evolve as fast as the business processes they support.

Provisioning Billing

Figure 1 Contact Contact

Management Management
Traditional application architecture.
Order Account
Management Management

Technician Usage
Manager

Network
Pricing
Manager

Product
Presentment
Configuration

2
BEA White Paper – BEA microService Architecture

SOA addresses these challenges, as shown in Figure 2. For this example, it eliminates duplication by allowing
both “applications” to use the same Contact Management service. It provides flexibility by inserting a level of
indirection between raw usage data and pricing, in the form of a Metering service. It eliminates artificial separa-
tions by introducing the Product Catalog Service. Most importantly, all components communicate through a set
of well-defined interfaces, separate from their specific implementations. Such clean interfaces decrease the
amount of time necessary to connect services and insulate consuming services from changes in producing
services. Thousands of companies have already realized these benefits of SOA.

Second wave: microServices transform middleware

Middleware enables the execution of these flexible SOA components. Ironically, the internal architecture of this
middleware currently resembles that of inflexible monolithic applications. As shown in Figure 3, a middleware
instance has a silo of infrastructure components. Just as in the monolithic application approach, this monolithic
infrastructure approach has drawbacks.

Companies must purchase, install, and maintain the entire silo for every server instance. However, many
instances don’t actually require every component. Java Enterprise Edition (Java EE) is an excellent example; it
delivers all the capabilities necessary to run the most sophisticated and demanding enterprise applications. But
instances executing Web front ends really only need Servlets, JSP, and JDBC. Instances running services on
the edge of the network typically don’t require clustering or JMS. Why should a company have to provision
hardware and administration resources for functionality it doesn’t need? If it has a specific business need to
upgrade one middleware component, why should the company have to upgrade the entire silo? And when it
needs a highly specialized middleware component, why can’t it simply add the necessary capability?

Provisioning Billing

Figure 2
Contact
Service-Oriented Architecture. Management

Order Account
Management Management

Technician
Metering
Manager

Pricing
Network
Manager

Product Product
Presentment
Configuration Catalog

3
BEA White Paper – BEA microService Architecture

What companies need is a modular middleware architecture, like the simplified example for Java EE shown in
Figure 3. Instead of silos, there are microServices. Companies can choose different configurations of microServices
to suit the deployment needs of different application-level services. They can upgrade individual microServices
independently. Under certain circumstances, they could even add new microServices to an existing configuration.
This approach aligns the philosophy of the infrastructure with the philosophy of the applications.

Benefits of microServices to the enterprise

Obviously, bringing service-oriented principles down to the infrastructure level provides middleware vendors
with similar benefits to those realized by enterprises at the application level. However, these vendor benefits
bubble up to the enterprise as well, including footprint optimization, fine-grained best-of-breed middleware, and
minimally disruptive upgrades.

Footprint optimization
Middleware has been enormously successful. Where every project used to reinvent the minimal set of compo-
nent services, these services are now available off-the-shelf. Moreover, because the installed base covers such
a wide variety of industries and requirements, packaged middleware is far more robust and complete than any
company could afford to build on its own. But this broad deployment has a downside: bloat.

The aggregate needs of the enterprise customer base require vendors to deliver feature-packed solutions. Of
course, few individual middleware instances actually require every single feature. With traditional approaches,
the distribution of a single software package was more efficient and reliable, but with microServices, vendors
can finally offer tailored configurations.

In practice, vendors cannot offer completely à la carte menus of microServices. Just as with application-level
services, only some configurations make sense, and vendors can only reasonably test and support a finite
number of combinations. Nevertheless, microServices enable a much greater variety of middleware configura-
tions to accommodate the correspondingly large variety of installation requirements.

Middleware

Figure 3
Other
Traditional middleware architecture.

Framework

Enterprise

Container

Virtual
Machine

4
BEA White Paper – BEA microService Architecture

This flexibility pays off immediately for companies by enabling them to optimize the footprint of each installation.
The Java EE APIs provide a range of functionality, from serving simple interactive Web pages to executing
complex, long-running transactions. Now companies can adjust their deployments to support the amount of
this functionality required by individual applications. For servers that simply provide front-end Web processing,
companies can choose to deploy without an EJB container, JTA manager, or JMS. For installations on the
edge of their networks, they can opt out of clustering and JMS. As a result, companies can decrease licensing
costs, deploy cheaper hardware, and reduce administrative overhead. A streamlined footprint also presents a
lower surface area of potential security vulnerabilities and reliability defects.

Fine-grained, best-of-breed middleware

In addition to optimizing their middleware footprints, companies can also optimize middleware capabilities. Every
company is different, and every application is different, but with past approaches, the choice of middleware product
was “all or nothing.” There were always a few instances that stretched the preferred platform’s capabilities. With the
advent of microServices, however, companies can work with vendors to create best-of-breed configurations.

There are limits to this idea, however. Theoretically, companies could mix and match any microServices together,
but practically, such flexibility raises difficult questions. Who supports a given assembly of services? What other
services are compatible with it? How can the company trust the services’ performance and reliability? Answering
these questions creates the need for mechanisms like certification programs.

Even with such practical constraints, microServices fundamentally enrich the middleware ecology. Independent
developers aren’t limited to offering their specialized infrastructure components only for open-source platforms.
They don’t have to bear the burden of supporting the entire package; instead, they can deliver a point solution
that benefits from a proven, supported platform.

As a result, companies can adapt their infrastructure to meet unique requirements without sacrificing their pre-
ferred platform. They work with new components only to the extent dictated by business objectives and get
the best of both worlds: flexibility and familiarity.

Presentation
Services
JSF WSRP MyFaces
Figure 4

microService architecture with Activity

Services
example microServices. Search

Application
Frameworks Spring Struts

Infrastructure
Services Real Time Core EJB 3.0 Core

Backplane
Components Real Time JVM Std JVM

Platform 2

Platform 3

5
BEA White Paper – BEA microService Architecture

Minimally disruptive upgrades

Fine-grained flexibility is not just an advantage when working with a primary platform vendor and a specialist
component vendor; it is also a plus when working solely within a primary platform. As noted previously, most
middleware solutions are packed with features. Traditionally, companies had to wait for upgrades to the entire
package to get the few enhanced features they really wanted.

With microServices, however, middleware vendors can offer upgrades to individual microServices. This capability
offers three advantages: First, because vendors don’t have to synchronize the release cycle of an entire platform,
companies get access to upgrades more quickly. As soon as the vendor completes a new version of a particular
microService, it can deliver that update to customers. Second, vendors are freer to target enhancements at
specific customer needs, and can afford to rapidly release new microServices in response to particular requests.
Third, companies can upgrade running instances dynamically, which means an end to bringing down the entire
stack just to get a few new features.

BEA microService Architecture

To provide these benefits to its enterprise customers, BEA is moving rapidly to adopt a microService Architecture
(mSA) across all of its middleware products. The primary challenge in this effort is to factor existing functionality
into discrete packages and then wrap them with the appropriate modular interfaces. These packages then plug
into a common software “backplane.” Individual microServices can be plugged and unplugged into this back-
plane, and as long as two microServices implement the same interface, they are completely substitutable.

Every piece of existing product functionality will move into a microService. In many cases, this factoring
process will immediately eliminate duplicative capabilities such as security and management functions. With a
single implementation of each basic function, customers will get a more consistent and reliable experience
when developing and deploying their applications.

Separation of concerns
Just as companies face the challenge of precisely how to factor their business-level software capabilities into
services, vendors face the challenge of factoring their infrastructure-level software capabilities into microServices.
The guiding principle for BEA in factoring is “separation of concerns.” Edsger W. Dijkstra originally defined
separation of concerns in 1974 as a complementary design principle to abstraction. Whereas abstraction divides
a piece of software into “horizontal” levels of increasing generality, separation of concerns organizes functionality
within a particular level of abstraction.

In analyzing middleware capabilities, BEA has identified five separate areas of concern. The first is the back-
plane, which includes the Java Virtual Machine (JVM) and the OSGi framework. The OSGi framework provides
standard module packaging, lifecycle management, and service registration. This framework is analogous to
the various Web services standards for capabilities such as interface definition, registration, discovery, invoca-
tion, and security. The key difference is that the OSGi framework deals with local Java mechanisms rather than
remote protocol mechanisms.

6
BEA White Paper – BEA microService Architecture

microServices in the remaining four areas of concern plug into the backplane:

• Infrastructure services include containers, such as BEA WebLogic Server®.

• Application frameworks include frameworks such as Spring and Struts.

• Activity services comprise an emerging area of concern that includes common cross-application activities
such as search.
• Presentation services include all the mechanisms for publishing user interfaces.

Security and management

Two groups of services are worth special mention: security and management. The backplane provides a perfectly
good mechanism for microServices to leverage standard security and management facilities. The question is,
“Which security and management facilities should be standard?” Integrating microServices with security and
management requires a great deal of care. Companies expect the overall package to work smoothly with specific
security and management mechanisms, but they don’t want microServices tightly coupled to these mechanisms
because then they won’t be able to take advantage of advances in security and management.

Luckily, BEA has extensive experience walking this fine line; it already provides a common framework across all its
products for binding abstract security requirements to very concrete implementation. There are generic services such
as authentication, role entitlements, authorization, credential mapping, and auditing. When a microService wants to
use a security service, the framework dispatches invocations to one or more security providers that implement that
service. One security-service implementation can be replaced by a completely different implementation, as long as it
provides the necessary service interface and the semantics of that service. By abstracting the details of the imple-
mentation, customers can compose capabilities that were never designed to work together, such as authentication
by a commercial vendor or custom authorization based on industry-specific compliance requirements.

For management, BEA will implement a similarly designed framework. As with security, there will be a set of
generic services such as deployment, provisioning, configuration, statistics, and alerts built around a federated
management infrastructure. Customers will access the results of this framework through different facades, such as
SNMP, JMX, and Web services. It will even be possible to include these management services under a higher-
level management console. By using this type of framework for security and management, companies will acquire
both the new flexibility of mSA and the traditional infrastructure’s robustness.

Product packaging
As noted previously, it is impractical to offer customers à la carte choices of microServices for their installations,
but mSA allows BEA to have a series of configurations for each product. Every configuration will be tested,
certified, and supported to the same high level of quality as current BEA offerings. These configurations will be
organized in a fashion roughly analogous to automobiles: a series of “models,” each of which has “options.”

For example, for BEA WebLogic Server there could be “economy,” “mid-size,” and “luxury” models. The economy
model would be targeted primarily at front-end Web applications, and would come standard with Servlets, JSP, and
JDBC. It might have a Struts and Tile option as well as a JMS option. The mid-size model would support the Java
EE APIs, except perhaps for clustering and JMS. (These might be options.) The luxury model would include all of
the bells and whistles currently available on BEA WebLogic Server. In the future, select third-party microServices

7
BEA White Paper – BEA microService Architecture

might be options for specific models, and it is also possible that BEA would release a “sports” model targeted at
the embedded market and designed explicitly for high-performance, real-time, or embedded applications.

Conclusion
Services are a philosophy applicable to any layer of software development: SOA applies it at the application
level, while mSA applies it at the infrastructure level.

BEA is applying its deep experience with service-oriented principles to its own products. While this transforma-
tion obviously makes internal product development more flexible and efficient, it also delivers direct benefits to
enterprise customers.

Companies will be able to optimize the footprint of each instance, saving on licensing, hardware, and adminis-
tration. They will get an even greater range of capabilities from the richer ecology of available microServices.
They will benefit from more frequent and less intrusive upgrades. In short, mSA will deliver the same benefits at
the infrastructure level that SOA delivers at the application level.

Join the BEA community

At BEA, we understand that developers need different kinds of resources than IT managers. And that architects
face different challenges than executives. That’s why we’ve created four unique communities that give you
exclusive access to a formidable group of your peers, to a world of shared thinking, and to the kind of mean-
ingful information that can make you more effective and more competitive. To join one or more of the BEA
communities, simply register online at bea.com/register.

About BEA
BEA Systems, Inc. (Nasdaq: BEAS) is a world leader in enterprise infrastructure software. The BEA SOA 360TM
platform, the industry’s most unified SOA platform for business transformation and optimization, is designed to
improve cost structures and grow new revenue streams. Information about how BEA is enabling customers to
achieve Business LiquidITyTM can be found at bea.com.

8
BEA Systems, Inc.

2315 North First Street

San Jose, CA 95131
+1.800.817.4232
+1.408.570.8000

bea.com CWP1496E1206-1A