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 Legend This software is protected by copyright, and may be protected by patent laws. No copying or other use of this software 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 specialized 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 maintain 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 cannot evolve as fast as the business processes they support.

Figure 1

Provisioning

Billing

Contact Management

Contact Management

Order Management

Account Management

Technician Manager

Usage

Network Manager

Pricing

Product Configuration

Presentment

Traditional application architecture.

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 separations 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 Figure 2

Billing Contact Management

Service-Oriented Architecture.

Order Management Technician Manager

Account Management

Metering Pricing

Network Manager

Product Configuration

Product Catalog

Presentment

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 component 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 configurations 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 preferred 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

Figure 4 microService architecture with example microServices.

JSF

WSRP

MyFaces

Activity Services Application Frameworks Infrastructure Services Backplane Components

Search Spring

Struts

Real Time Core

EJB 3.0

Real Time JVM

Core

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 backplane, 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 backplane, 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, invocation, 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 implementation, 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 higherlevel 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 transformation 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 administration. 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 meaningful 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