BEA’s SOA Reference Architecture

A Foundation for Business Agility

Copyright

Copyright © 1995–2008 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–2008 BEA Systems, Inc. All Rights Reserved. BEA, BEA AquaLogic, BEA eLink, BEA WebLogic,
BEA WebLogic Portal, BEA WebLogic Server, Connectera, Compoze Software, Jolt, JoltBeans, JRockit, SteelThread,
Think Liquid, Top End, Tuxedo, and WebLogic are registered trademarks of BEA Systems, Inc. BEA Blended
Application Development, BEA Blended Development Model, BEA Blended Strategy, BEA Builder, BEA Guardian,
BEA Manager, BEA MessageQ, BEA microServices Architecture, BEA Workshop, BEA Workspace 360, Signature
Editor, Signature Engine, Signature Patterns, Support Patterns, Arch2Arch, Arch2Arch Advisor, Dev2Dev, Dev2Dev
Dispatch, Exec2Exec, Exec2Exec Voice, IT2IT, IT2IT Insight, Business LiquidITy, and Liquid Thinker are trademarks of
BEA Systems, Inc. BEA Mission Critical Support, BEA Mission Critical Support Continuum, BEA SOA Self
Assessment, and Fluid Framework are service marks of BEA Systems, Inc. All other company and product names
may be the subject of intellectual property rights reserved by third parties. All other trademarks are the property of
their respective companies.

CWP1718E0108-1A
BEA White Paper – BEA’s SOA Reference Architecture

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

Part I: The Existing Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Service Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Part II: SOA Infrastructure and Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Presentation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Business-Oriented Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Integration-Oriented Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Vertical Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Benefits of the SOA Reference Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Serves as a Blueprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Clarifies Tradeoffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Improves Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Promotes Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

About BEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Join the BEA community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

BEA White Paper – BEA’s SOA Reference Architecture

Introduction
According to the 2007 Evans Data Corporate Enterprise Development Survey, adoption of Service Oriented
Architecture (SOA) will double by 2009. Why? Because SOA focuses on business agility. This business focus
may seem odd for a set of Information Technology (IT) principles, but it’s what sets SOA apart from other
approaches to enterprise software.

The goal of SOA is to align IT capabilities with business objectives. Instead of building and deploying rigid
monolithic applications, enterprises construct reusable services and compose fluid applications. Enterprises
can continuously adapt to new business conditions by creating and updating services, by adjusting business
rules and policies, and by composing new applications. Of course, focusing such tremendous power directly
on business objectives presents challenges of its own. To reap the business benefits of SOA, enterprises need
a set of conceptual blueprints and guiding principles.

An SOA Reference Architecture provides this critical foundation. It offers an architectural framework for planning
SOA-based projects that maximize interoperability and reuse. It defines a consistent vision of SOA throughout
the enterprise. It supplies the context for imposing best practices on development and deployment. It represents
IT’s architectural alignment with the business objectives for SOA and thus helps drives decisions associated with
the implementation of SOA, including infrastructure requirements and investment priorities. With an appropriate
SOA Reference Architecture, enterprises can manage the expansion of SOA within their organizations from pilot
projects and grassroots efforts to comprehensive adoption.

BEA has refined a proven SOA Reference Architecture based on years of working with leading enterprise customers
to deploy SOA. Gradually, lessons learned with customers diffused into BEA’s general consulting practice. The clear
success that came from leveraging these lessons led to the creation of a formal SOA Reference Architecture within
BEA. Today, this SOA Reference Architecture guides both product development and customer implementations.

BEA’s SOA Reference Architecture is very straightforward. It takes existing Service Consumers and Providers
as given. The goal of the rest of the architecture is to give Service Consumers the capabilities they need by
leveraging existing Service Providers and facilitating the deployment of new ones. This “embrace and extend”
philosophy recognizes the reality that IT will remain a heterogeneous environment. The foundation of BEA’s
SOA Reference Architecture consists of Connectivity and Data Services that provide flexible access to diverse
applications and data sources. Business-Oriented Services comprise a logical layer above Connectivity and
Data Services, adding business rules and coordinating business process execution. Presentation Services
package these business capabilities and data for reuse across multiple delivery channels. Layering functionality
along these lines enables IT to efficiently offer tailored capabilities to a wide variety of Service Consumers.

By using BEA’s SOA Reference Architecture, enterprises can scale SOA development across the entire organi-
zation and ensure that investments continue to pay off over long time horizons. Anyone can just go out and
start building a shed, but delivering a skyscraper requires tremendous planning. Enterprise IT infrastructures are
skyscrapers and the SOA Reference Architecture is the first step in planning. It clarifies the definition and vision
of SOA, describes architectural principles and guidelines, promotes best practices, and enables more effective
long-term governance. These benefits make the SOA Reference Architecture a crucial piece of BEA’s efforts to
maximize the enterprise benefits of SOA.

1
BEA White Paper – BEA’s SOA Reference Architecture

Part 1: The Existing Landscape

BEA’s SOA Reference Architecture embraces the practical reality that every enterprise already has an existing
landscape of heterogeneous "clients" and "servers". The goal is to enhance, rather than replace, this landscape.
Therefore, the SOA Reference Architecture takes existing client and server technologies as given. However, it uses
the more general term "Service Consumer" to describe actors that primarily request capabilities from the rest of the
infrastructure, and uses the term "Service Provider" to describe actors that primarily provide capabilities to the rest
of the infrastructure.

Conceptually, Service Providers are the starting point of the SOA supply chain, and Service Consumers are the
ending point. As shown in Figure 1, the rest of the SOA, known as "SOA Infrastructure and Shared Services", sits
in between. SOA Infrastructure improves flexibility and robustness by coordinating the complex logistics of moving
information between Providers and Consumers. Shared Services refine existing Provider capabilities and add new
capabilities to fulfill Consumer requirements.

Figure 1 shows how the Existing Landscape encompasses a wide variety of different component types. While
Figure 1 and the sections below discuss some types in more detail, these examples are by no means required
or exhaustive. Some enterprises may have only a few of these components types while others may have types
not listed here. Furthermore, new types will undoubtedly arise over time. None of these differences affects the
big picture. The SOA Reference Architecture offers the flexibility necessary to accommodate any type of
Service Consumer or Service Provider.

Figure 1
User Interaction Channels System Consumers
Fitting SOA into the
Existing Landscape. Browsers Client UI Cell PDA IVR Applications Edge Events Partners

Composite Applications

Web Apps Portals Mashups Workflow Business Fat Clients

Processes

SOA Infrastructure & Shared Services

Non-Service Enabled Assets Service Enabled Assets

Legacy Packaged Databases Partners Content Collaboration Search

2
BEA White Paper – BEA’s SOA Reference Architecture

Service Consumers
Composite Applications
Composite Applications are standalone applications that are composed of shared services. They draw some, or
all, of their functions and capabilities from the SOA Infrastructure and Shared Services layers. Developers can
program and build them using traditional programming tools or compose and configure them using specialized
service assembly tools. Either way, composite applications follow a service composition engineering model.

Composite Applications usually combine some of their own dedicated functionality with shared functionality
provided by the rest of the SOA. Such applications may be small and simple, such as a basic Web site or small
Java applet, or large and complex, such as a customer-facing portal or a complete process workflow. They
may even include desktop productivity applications such as spreadsheets that interact directly with enterprise
data. All Composite Applications are independent applications that address specific business requirements.

Composite Applications deliver agility by enabling enterprises to quickly and efficiently create and deploy new
capabilities that address specific business requirements. They achieve these benefits by enabling developers to
focus on the dedicated functionality required to meet business goals, and then reusing all the existing functionality
provided by SOA Infrastructure and Shared Services. This flexibility increases exponentially as the SOA expands—
the amount of dedicated functionality required decreases as the amount of reusable functionality increases. Very
quickly, projects that would have been too expensive to deliver because they required too much custom develop-
ment become cost-effective with the advent of so many reusable capabilities. For example, an enterprise could
quickly leverage social computing as a composite application by using an off-the-shelf solution and connecting it
to all the business capabilities available through the SOA infrastructure.

Composite Applications dramatically shift cost and productivity curves. Costs shift down because the SOA
Infrastructure already provides the necessary service logistics—security, data, and server administration, to
name just a few. Productivity shifts up because developers can build on top of Shared Services—encapsulated
data, functions, and processes. Thus the barrier to entry for a Composite Application is quite low. A team of
developers can crank out dozens of small applications instead of just one large application, even though each
small application adds as much value as the large one. Developers can even deliver applications to support
very short-term opportunities. Implementing a project with a one-month lifespan when it takes two weeks to
develop doesn't make much sense. But investing one day of development is easily justified. So in addition to
making traditional application development more efficient, adopting the Composite Application model opens up
an entirely new realm of "long tail" opportunities.

User Interaction Channels

User Interaction Channels allow people to interact with Composite Applications and Shared Services. They include
software devices like Web browsers and native interfaces, as well as hardware devices like PDAs and mobile
browsers. In general, the presence or absence of specific interaction devices will not directly affect the rest of the
SOA because each Composite Application can theoretically support any User Interaction Channel. However, certain
devices may work better with certain Composite Applications because the devices require a particular interaction
style. For example, an IVR or SMS channel naturally results in a very fine-grained set of interactions, while those for
Web browsers are usually more coarse-grained. Obviously, the granularity of interaction assumed by a Composite
Application may restrict which devices can effectively access it in practice.

3
BEA White Paper – BEA’s SOA Reference Architecture

System Consumers
Internal applications and business partners can also interact with the SOA. They may participate fully as Shared
Services themselves. However, they may also operate at arm’s length from the rest of the SOA through a Composite
Application. From the perspective of the SOA, such arm’s-length relationships make these applications and partners
System Consumers. They are, in essence, standalone applications that draw from the portfolio of shared services,
but are not themselves organized in a way that enables reuse of their internal capabilities by the SOA.

Service Providers
The Existing Landscape includes systems that provide services required by the SOA, and systems that consume
services offered by the SOA. Service Providers include custom, packaged, and legacy applications as well as
databases. Content repositories and collaboration solutions can also act as Service Providers. Of course, just as a
partner can consume services from an enterprise’s SOA, that enterprise’s SOA may in turn rely on other partners
to provide services.

Enterprises want to leverage these existing assets across as many different business solutions as possible to
maximize return-on-investment and minimize time-to-market. In some cases, existing assets may already offer
service interfaces. Such Service-Enabled Assets can interact directly with the rest of the SOA through the
Service Mediation and Messaging infrastructure. In other cases, existing assets may only offer a native propri-
etary interface, or partners may want to interact at arm’s length. Such Non-Service-Enabled Assets will require
Connectivity Services to make their capabilities available to the rest of the SOA.

4
BEA White Paper – BEA’s SOA Reference Architecture

Part II: SOA Infrastructure and Shared Services

The core of BEA’s SOA Reference Architecture consists of the shared services and infrastructure that enable
business agility and foster reuse. It is designed to work like modular building blocks, offering the foundation nec-
essary to deliver loose coupling. Each block is a reusable runtime service. Enterprises can snap them together,
swap them out, and insert new layers without rebuilding the entire structure. As Figure 2 shows, the SOA
Reference Architecture imposes a conceptual layering that helps organize services into several basic categories.

The horizontal layers build upon each other, bottom to top, to create greater levels of service abstraction. At the
lowest layer, Connectivity Services provide access to legacy systems in a way that is compatible with SOA. This
is the service-enablement layer. Each layer above adds greater business value. At the top, Presentation Services
expose all of these capabilities in a reusable form for consumption by the various Composite Applications and
Delivery Channels. Of course, all of these layers are optional, and individual services may encapsulate capabilities
that span multiple layers. For each specific case, an enterprise need only define the layers it needs.

In addition to the horizontal layers, there are also vertical facilities. These facilities supply capabilities required at
all layers of the SOA Reference Architecture. As the horizontal layers flex to provide adaptability, the vertical
facilities serve as pillars of consistency. That way, enterprises don’t have to sacrifice qualities like manageability,
security, and governance to achieve agility.

Figure 2
User Interaction Channels System Consumers
SOA Infrastructure and
Consumers

Browsers Client UI Cell PDA IVR Applications Edge Events Partners

Shared Services.
Service

Composite Applications

Web Apps Portals Mashups Workflow Business Fat Clients

Processes

Presentation Services

Consistent User Interaction Shared Portlets

Business Process Services

Service Mediation & Messaging

Shared Business Business Process System & Human

Processes Rationalization Centric Processes
SOA Event Processing

SOA Management

SOA Governance
SOA Security

Business Activity Services

Services
Shared

Atomic Business Process Custom Business

Services Integration Logic

Data Services

Logical Data Data Data

Data Model Aggregation Synchronization Access

Connectivity Services

System Messaging Adapters Data Partner

Access Access Integration

Non-Service Enabled Assets Service Enabled Assets

Providers
Service

Legacy Packaged Databases Partners Content Collaboration Search

5
BEA White Paper – BEA’s SOA Reference Architecture

Presentation Services
Obviously, the ultimate goal of all Shared Services and infrastructure is to support interactions with Service
Consumers. The role of Presentation Services is to enable a consistent user experience when interacting with
Shared Services across different Composite Applications and user interaction channels. Presentation Services
are reusable blocks of UI logic that provide presentation and interaction services. While certain Service
Consumers may want to access Business- and Integration-Oriented Services directly, others may want the
convenience and conformity that come from reusable Presentation Services.

Remember that some User Interaction Channels tend toward coarse-grained interaction, while others tend
towards fine-grained interaction. Coarse-grained channels often require reusability of interface components.
Modular portlets, for example, may be used in a variety of different portal applications to visually represent the
same capabilities, thus providing a consistent user experience across the different portals. The SOA Reference
Architecture categorizes services that provide such reusable chunks as Consistent User Interaction services.

Fine-grained channels often require common interaction sequences. For example, IVR, DTMF, and WAP channels
often follow similar logic trees. The SOA Reference Architecture categorizes services that supply such abstract
sequences as Common Utilization Pattern services. Also consider the case of AJAX applications. A set of such
applications may share a set of XML message exchanges. Architects can abstract these shared exchanges into
Common Utilization Pattern services.

Business-Oriented Services
Business-Oriented Services provide business capabilities to Service Consumers, either directly or via Presentation
Services, as discussed above. There are two types of Business-Oriented Services: Business Process Services
and Business Activity Services. Business Process Services automate the execution of logical business processes.
Within Business Process Services, there may be layers representing the decomposition of complete processes,
such as “Fulfill Order”, down to common sequences such as “Update Contact Information”.

Business managers and analysts are responsible for driving Business Process Services. Their job is to define
processes that support overall business objectives within the context of the greater business environment.
Typically, they use SOA-oriented Business Process Management (BPM) solutions that allow them to specify
models that invoke the necessary supporting services.

However, once they decompose business processes into their smallest coherent units, they must share responsibility
for these Atomic Business Activities with IT staff. Business and IT staff work together, with business staff primarily
drafting the business-level functional and interface requirements of these activities, while IT staff primarily evaluate the
business activities as potential service candidates, refine the interface and deliver the implementation. Both groups
must arrive at a consensus view of the definition of business activities and the functionality and interfaces of the
services that implement them. Atomic Business Activities simultaneously represent the lowest level of development
responsibility for the business and the highest level of development responsibility for IT. Over time, as the library of
such services proliferates, business staff will often be able to orchestrate new business processes entirely from
existing Atomic Business Activities, reducing the development, testing, and deployment effort needed for IT to roll out
the new business process orchestrations.

6
BEA White Paper – BEA’s SOA Reference Architecture

Integration-Oriented Services
In order to implement Atomic Business Activities, IT staff must do two things. First, they must implement the
business logic specific to the particular service. Second, they must invoke or develop the Integration-Oriented
Services on which this business logic depends. The difference between Atomic Business Activities and
Integration-Oriented Services is that the former have a specific business context while the latter do not. For
example, “process payment” would have a specific business context in most enterprises, while “customer
update” would not.

There are two types of Integration-Oriented Services: Data Services and Connectivity Services. Data Services
provide an aggregated, real-time view of logical business entities contained in disparate databases and applica-
tions. The canonical example is the delivery of a single logical view of “customer” entities. Data Services map
the logical data model, and associated manipulation operations for an aggregated entity, to the underlying data
schemas and application functions. Higher-level data consumers can therefore interact with enterprise data at
an abstract business level rather than worry about the detailed operations necessary to maintain consistent
data models across all the underlying systems.

If an enterprise already has canonical data models, architects can use them as the basis for Data Services. If not,
Data Services can be defined based on current business processes needs. With this pragmatic approach, busi-
ness needs define localized data models, which in turn are implemented as services. Later, IT staff can take the
opportunity to modify, transform, or aggregate these models as necessary to deliver broad consistency across
processes. But in the interim, the data needs of individual processes will be met in a service-oriented manner.

Connectivity Services provide the application-level access to backend systems. They comprise all the adapters,
bridges, and glue code necessary to perform useful work with such systems. Individual services in this layer
can vary widely in functionality. In some cases, such as modern service-enabled packaged applications and
well-designed XA-capable SQL databases, Connectivity Services may be unnecessary. Data Services can
access the former directly and all higher layers can access the latter through the Service Mediation and
Messaging facility. In other cases, a simple off-the-shelf adapter may be all that is required. The purpose of the
Connectivity Services layer is to insulate the rest of the architecture from whatever machinations are necessary.

Vertical Facilities
In addition to the horizontal layers that provide a clean gradation of abstraction, the SOA Reference
Architecture has Vertical Facilities that provide a set of consistent capabilities across the layers. Whereas the
Shared Services provide support analogous to beams, Vertical Facilities provide support analogous to pillars.

Service Mediation & Messaging

Service Mediation and Messaging is an important foundational facility. Typically provided by an Enterprise
Service Bus, this facility manages the flow of SOA messages among all services. It’s much more than just a
transport. It’s an intelligent router, translator, and monitor. It’s what makes services “plug-and-play”.

This facility acts as an intermediary — instead of a consumer communicating directly with a provider, the con-
sumer communicates with a proxy and the proxy, in turn, communicates with the provider. The proxy can apply
operational logic to the communication without impacting either the consumer or the provider. For example, it

7
BEA White Paper – BEA’s SOA Reference Architecture

could route requests to different implementations based on the application Service Level Agreement. It could
fail-over to a secondary implementation if there is an outage at the primary. It could even choose among alter-
native versions of a provider or automatically transform requests to a new version.

Because the Service Mediation and Messaging facility acts as an intermediary for all communication among
services, it also provides the point of leverage for other Vertical Facilities, such as Event Processing.

Event Processing
The Event Processing facility in the SOA Reference Architecture focuses on two major types of events: edge
events and SOA events. Edge events occur at the boundary that separates the SOA environment from other
environments. Components of the Event Processing facility collect and analyze edge events in order to identify
relevant patterns and produce new business level events to signal situations that require a logical business
response. For example, an event in a dedicated financial trading system may signal a precipitous decrease in
portfolio value, or an event in an RFID-based inventory application may signal unexpectedly rapid consumption.
In both cases, the Event Processing facility would detect the incoming event, correlate that event with other
relevant events in a business context, and then potentially trigger one or more business process responses in
the SOA.

In contrast to edge events, SOA events occur either between Service Consumers and Shared Services or among
multiple Shared Services. Service Consumers and Shared Services may produce or consume events. The Service
Mediation and Messaging facility provides event identification, messaging, and notification infrastructure. The
Service Mediation facility may also generate SOA events to surface the result of service interactions as a new
business level event. For example, data elements from request and reply messages to multiple backend systems
may be used to produce a business event indicating that an order has been re-routed.

Events can be broadly categorized as either simple or complex. A simple event typically represents a single inde-
pendent fact; “something” has happened. In contrast, complex events represent a higher-level event derived
from a combination of other, simpler events. A Complex Event Processor (CEP) or Event Stream Processor (ESP)
monitors edge and SOA events comparing the contents of all these events against pre-defined event patterns.
These patterns often include aggregation, correlation, and temporal conditions. When a set of events matches a
pattern, the event processor generates a complex event to represent the situation and forwards the event to the
Service Mediation and Messaging facility for delivery to consumers of the event—which may be either be Service
Consumers or Providers—to apply the appropriate processing.

From the perspective of the SOA, Service Consumers handle events in an ad hoc fashion—for example, users
respond to text messages, and partners handle EDI messages. Within the SOA, Shared Services can use BPM-
enabled event handlers to kick off the appropriate Business Activity or Business Process services in response.

8
BEA White Paper – BEA’s SOA Reference Architecture

SOA Management
Ensuring the efficient and robust execution of services requires operational management of the SOA environment.
The SOA Management facility provides the necessary capabilities within the SOA Reference Architecture. The
most basic capabilities are service discovery and service monitoring. Service discovery comprises all the tasks
associated with understanding which services are deployed, where they are deployed, and how they are transac-
tionally linked. Service monitoring comprises all tasks involved in assessing the health of the SOA environment,
such as monitoring performance, handling exceptions, and tracking message flow.

Advanced capabilities include managing failover and loading to ensure reliability and scalability, setting and monitor-
ing service level agreements, and auditing service execution to support compliance requirements. Managing service
versioning is perhaps the most sophisticated SOA Management capability. As the enterprise SOA evolves, opera-
tions staff need sophisticated tools to handle service upgrades, including maintaining multiple service versions and
establishing the routing rules that determine which version responds to which types of requests. Otherwise, the
flexibility that comes with loose coupling would quickly evaporate over the typical application enhancement cycle.

SOA Security
In addition to robust and efficient execution, all layers of the SOA require security. The SOA Security facility provi-
sions end-to-end security across the SOA. The first step in ensuring comprehensive security is establishing user
and system identities. Because most enterprises already have extensive identity management infrastructure, the
SOA must integrate with existing solutions rather than imposing its own. It must also support the propagation of
identity between Service Consumers, Service Providers, and the various layers of Shared Services.

The second step is managing user entitlements. These entitlements define both the service capabilities that are
accessible to a given user, and the conditions under which that accessibility is granted. The SOA needs a
mechanism for specifying various levels of entitlements, such as the ability to access a certain group of servic-
es, a specific service type, and a particular function of a service type. The SOA also needs a mechanism for
mapping user characteristics, such as “role” or “department”, to function sensitivities such as “manager only”
and “human resources only”. Establishing entitlement management as a vertical facility in the SOA Reference
Architecture means entitlements can be managed centrally and enforced locally at each horizontal layer with
the result of a lower cost of maintenance without sacrificing performance or flexibility.

Once the SOA has identity information and user entitlements in place, it can begin authenticating and authorizing
service requests. Authentication is a two-step process that works in conjunction with the Service Mediation and
Messaging facility. First, this facility authenticates the requesting server or gateway to ensure that it is allowed to
connect to the SOA. Then the SOA Security facility accepts the propagated credential of the original requestor,
authenticates it, and binds it to an identity. Finally, it compares the entitlement of that identity to that required for
satisfying the request.

Of course, the SOA Security Facility also works in conjunction with the Service Mediation and Messaging facility
to implement message-level security such as encryption and signatures.

9
BEA White Paper – BEA’s SOA Reference Architecture

SOA Governance
SOA Governance is very broad topic that could conceivably cover all aspects of the SOA Reference
Architecture. In this case, the SOA Governance Facility refers specifically to the Repository and Registry that
together are the single source of truth that provides visibility and control across the SOA.

The Repository provides service control and visibility into the development environment. It is a central repository of
SOA development artifacts: requirements, design policies, best practices, service interfaces and contract definitions,
service implementations (or links to the appropriate source code control systems), test plans & results, ownership,
and recommendations on when & how to use the services. By exposing services for reuse, the Repository plays an
important role in the SOA development process as architects and developers can easily and quickly understand
what existing services are available. Enterprises can use the Repository to analyze how changes to requirements
will affect implementations, to trace implementation details back to specific requirements, and to compare similar
artifacts, such as all service interfaces. The Repository gives the enterprise complete situational and historical
awareness of every SOA development task. The Repository also governs the lifecycle of services. For example, it
can enforce a policy that forbids the publication of services to the Registry until they are approved for test, staging,
or production.

The Registry provides control and visibility into the run-time environment. It knows all the deployed services,
their property settings, and metrics measuring their behavior. Selected operational information from the Registry
may be posted to the Repository to inform service reuse and service portfolio management decisions—thus
closing the loop between the operational and development environments.

Benefits of the SOA Reference Architecture

The first step in leveraging BEA’s SOA Reference Architecture is to replace the generic component types
described earlier in this document with components specific to the enterprise. The generic “Portals” might
become the specific “Employee HR Portal” and “Customer Service Portal”. “Packaged Applications” might
become “SAP” and “Oracle Financials”. “Atomic Business Activities” might include “Order Shipping” and
“Payment Processing.”. The enterprise can also identify how new projects fit into the larger puzzle, such as
specifying a shared “Add New Product” business process or providing a consistent “Customer” data service.

The result is a concrete instance of the SOA Reference Architecture—an enterprise-specific blueprint that is the
authoritative definition of the SOA architecture. It provides the framework to classify SOA Infrastructure and
Shared Services. It defines the relationship between the desired SOA and existing architectures. It specifies the
architecture vision and drives the roadmap for achieving that vision. Finally, it serves as a crucial communication
vehicle and compliance tool.

10
BEA White Paper – BEA’s SOA Reference Architecture

Serves as a Blueprint
The primary benefit of an SOA Reference Architecture instance is that it serves as an architectural blueprint,
both within a single project and across projects. Within a single project there are two aspects to this blueprint,
both analogous to the use of blueprints in building construction. First, architects work upwards to clarify the
business requirements and goals by conducting a "visual conversation". In the construction world, this conver-
sation formalizes the client's building requirements and aesthetic goals. In the SOA world, this conversation
formalizes the business staff's representation of user interaction with the SOA, and the execution of business
processes within the SOA.

Second, architects work downwards with developers to verify that the implementation follows the plans by
ensuring that every finished piece fully corresponds to a blueprint definition. In the construction world, this
correspondence occurs between the blueprint, the building materials, and the physical terrain. In the SOA
world, this correspondence occurs between the blueprint, the software code, and the IT infrastructure.

Across projects, the blueprint provided by an SOA Reference Architecture instance helps achieve consistency
of both exposure and implementation. Consistency of exposure means that service interfaces at the same
abstraction layer should share a similar look and feel. Such similarity facilitates the identification and incorpora-
tion of services that are good candidates for reuse. Otherwise, architects and developers have to familiarize
themselves with the idiosyncrasies of every different service, increasing search times and slowing the imple-
mentation. The SOA Reference Architecture helps architects enforce this consistency across the organization
as different services are created by different teams.

Consistency of implementation means that similar services should be implemented using similar tools, technologies,
and patterns. Such similarity reduces both development costs and time-to-market by allowing developers to focus
on perfecting their knowledge of fewer paradigms. It also reduces acquisition and training costs for software tools
and execution infrastructure by decreasing the number of necessary products.

Clarifies Tradeoffs
As a blueprint, the SOA Reference Architecture helps to clarify tradeoffs. All enterprises have limited resources.
This forces them to focus on projects that will deliver the most value. They must build certain low-level services
before they can build valuable high-level services. They must acquire different types of products to support
service development at different layers. The SOA Reference Architecture enables architects to work effectively
with business staff to evaluate the tradeoffs inherent in alternative roadmaps.

Identifying the highest priority efforts in a complex environment with these competing imperatives would be
extremely difficult without a conceptual framework like the SOA Reference Architecture. What if an enterprise’s
top concern were decreasing the amount of time it takes to roll out new products? It might already have a
model of an improved process, but implementing it obviously requires new underlying capabilities. Using the
SOA Reference Architecture, an enterprise might identify the need for Connectivity Services for Product
Information Management and Project Management systems. It might also identify necessary Data Services
such as “Product” and “Rollout Schedule”. By revealing the full scope required to implement a process,
architects can better communicate the full impact to business staff.

Priorities can develop bottom-up as well as top-down. A major source of outages at one enterprise might be
conflicting updates to backend applications and databases. The SOA Reference Architecture suggests a solu-
tion—Data Services that sit between Atomic Business Activities and Adapters. Architects can show business

11
BEA White Paper – BEA’s SOA Reference Architecture

staff how acquiring the products required to provide that layer and implementing Data Services for the most
commonly used entities would improve process efficiency. Business staff can then compare this benefit to
alternative uses of the same resources.

Users can also drive priorities. What if surveys indicate that difficulties in using all the application interfaces
necessary to handle customer interactions create a major drain on customer service productivity? The SOA
Reference Architecture offers an alternative—the ability to improve user experience by redesigning the inter-
faces so they access Consistent User Interaction services through the Service Mediation and Messaging facility.
Again, architects can effectively communicate the potential advantages of this approach and work with
business staff to perform a cost-benefit analysis.

Improves Project Management

In addition to focusing development resources on solving the most important challenges, enterprises need to
manage the resulting projects. The SOA Reference Architecture can serve as a blueprint for an individual project
as well as the blueprint for the entire SOA. An architect can use it to break down the overall business functionality
into a set of distinct service blocks, assign responsibility for each block to the appropriate development team, and
monitor implementation. It also helps ensure that different groups can reach efficient cost-sharing arrangements.

As noted in the previous example illustrating the product rollout process, implementing this new process will require
additional Connectivity Services. It will probably also require additional Presentation Services to interface with the
new process capabilities. The SOA Reference Architecture shows that development at these two separate layers
can be assigned to different team members who specialize in those areas. Those specialists can then proceed in
parallel. This parallelism will reduce time to deployment and avoid idling development resources. An architect can
monitor the implementation of both services to ensure that they will cooperate effectively with each other and with
the rest of the Shared Services necessary to support the product rollout business process.

What if there is also a high-priority manufacturing process improvement project? Looking at the vertical slice of
service dependencies, the SOA Reference Architecture would probably detect that Data Services such as
“Product” and “Rollout Schedule” overlap the two projects. The enterprise could eliminate duplication and
improve synchronization by unifying these sub-projects and assigning them to team members who specialize in
Data Services implementation. An architect can leverage the SOA Reference Architecture to ensure that the
resulting Data Services will actually meet the needs of both projects.

As an added benefit, using the SOA Reference Architecture to guide the assignment of responsibility also clarifies
cost-sharing issues. Obviously, in the example of overlapping “Product” and “Rollout Schedule” Data Services, the
rollout and manufacturing process improvement projects should share the cost. In general, using the SOA Reference
Architecture to identify service requirements and plan service implementations reveals which services are the most
likely to deliver high levels of reuse. Therefore, the enterprise can build mechanisms into the budgeting process for
the corresponding projects that account for and encourage reuse.

Promotes Best Practices

The SOA Reference Architecture can help enterprises leverage SOA to improve software quality. One of the most
important lessons to come out of SOA projects is that the development, application, and refinement of best practices
is crucial to the delivery of robust services. The paradigm provides so much flexibility that architects need guidance in
choosing among alternative approaches. The goal is to solve the same problem the same way every time.

12
BEA White Paper – BEA’s SOA Reference Architecture

But how can architects pinpoint the type of problem? The SOA Reference Architecture can help. Developers
can establish a context based on the layer at which they are working and the structure of dependencies on
other layers. They can examine the alternative practices used in similar situations and determine which ones
produce the best outcomes. Over time, a generally accepted best practice emerges.

Obviously, new problems will continually arise. By leveraging the SOA Reference Architecture, developers can
identify situations where there’s no precedent for a best practice. They can then raise the new issue with a
broader community. The SOA Reference Architecture helps define the groups of people working on similar
services. Specialist communities can then establish lines of communication to disseminate experience and
collaborate on addressing new challenges.

Conclusion
BEA’s SOA Reference Architecture delivers long term benefits to enterprises by providing a blueprint for scalable
enterprise-wide SOA. The power of SOA is its flexibility. Each enterprise can adapt its particular IT assets to its
unique business. However, this power is useless without direction. Each enterprise needs a seamless fabric of
automation, not isolated patches. The SOA Reference Architecture offers the necessary guidance.

By leveraging the SOA Reference Architecture, enterprises can see what services they should build, and when.
They can increase parallelism and reduce duplication across their portfolios of development projects. They can
identify the commonalities necessary to promote and refine best practices. They can impose effective governance
though policies that appropriately apply general principles to specific circumstances.

The key to all these benefits is the knowledge of where each project and service fits within the grander scheme
of enterprise-wide SOA. Using the SOA Reference Architecture, both business and IT staff can pinpoint the role
of any existing or proposed service. Dependencies, gaps, and duplication are revealed. Planning, cooperation,
and procurement become simpler. Enterprises can finally make agility a manageable process. BEA leads the
way with a SOA Reference Architecture based on years of real world experience.

About BEA
BEA Systems, Inc. (NASDAQ: BEAS) is a world leader in enterprise infrastructure software. BEA® Enterprise 360°,
the industry’s most advanced SOA-based offering, is a comprehensive approach to delivering business results
that includes technology, professional services, best practices, and world-class partners. Information about how
BEA helps customers build a Liquid Enterprise™ that transforms their business can be found at bea.com.

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.

13
BEA Systems, Inc.

2315 North First Street

San Jose, CA 95131
+1.800.817.4232
+1.408.570.8000

bea.com CWP1718E0108-1A