Beruflich Dokumente
Kultur Dokumente
CWP1496E1206-1A
BEA White Paper – BEA microService Architecture
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Footprint optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Separation of concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Product packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .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
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
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.
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.
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.
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
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
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.
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:
• 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.
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.
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.
bea.com CWP1496E1206-1A