bea micro service architecture wp

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 LegendThis 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 MarksCopyright © 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


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


Evolution of Service-Oriented Architecture

First wave: Services transform applicationsService-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.

2

Figure 1

Traditional application architecture.

Billing

ContactManagement

AccountManagement

Usage

Pricing

Presentment

Provisioning

ContactManagement

OrderManagement

TechnicianManager

NetworkManager

ProductConfiguration


3

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 middlewareMiddleware 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?

Figure 2

Service-Oriented Architecture.

AccountManagement

BillingProvisioning

ContactManagement

Metering

ProductCatalog

Pricing

Presentment

OrderManagement

TechnicianManager

NetworkManager

ProductConfiguration


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 optimizationMiddleware 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.

4

Figure 3

Traditional middleware architecture.

Middleware

Other

Framework

Enterprise

Container

VirtualMachine


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 middlewareIn 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.

5

Figure 4

microService architecture withexample microServices.

WSRP MyFaces

Search

JSF

Spring Struts

Real Time Core EJB 3.0 Core

Real Time JVM Std JVM

Platform 3

Platform 2

PresentationServices

ActivityServices

ApplicationFrameworks

InfrastructureServices

BackplaneComponents


Minimally disruptive upgradesFine-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 concernsJust 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


7

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 managementTwo 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 packagingAs 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


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

http://www.bea.com

http://www.bea.com/register

CWP1496E1206-1A

BEA Systems, Inc.

2315 North First Street San Jose, CA 95131+1.800.817.4232+1.408.570.8000

bea.com

bea micro service architecture wp

Documents