Service Oriented Arquitechture - Guide

SERVICE-ORIENTED
ARCHITECTURE
SOLUTION ACCELERATOR
GUIDE
Platform Solution Accelerators
VERSION1.0 REVISION 2.12

COPYRIGHT
Copyright © 2004 BEA Systems, Inc. All Rights Reserved
RESTRICTED RIGHTS LEGEND
This document may not, in whole or in part, be photocopied, reproduced, translated, or reduced to any
electronic medium or machine readable form 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, Inc.
TRADEMARKS
BEA, Tuxedo, and WebLogic are registered trademarks and BEA WebLogic Enterprise Platform, BEA WebLogic
Server, BEA WebLogic Integration, BEA WebLogic Portal, BEA WebLogic Platform, BEA WebLogic Express,
BEA WebLogic Workshop, BEA WebLogic Java Adapter for Mainframe, and BEA eLink are trademarks of BEA
Systems, Inc. All other company and product names may be the subject of intellectual property rights reserved by
third parties.
BEA Systems, Inc. BEA PROPRIETARY

2315 North First Street
San Jose, CA 95131 U.S.A.
Telephone: +1.408.570.8000
Facsimile: +1.408.570.8901
WWW.BEA.COM SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - ii
CONTENTS
1.0 INTRODUCTION .......................................................................................... 9
1.1 THE SOLUTION ACCELERATOR GUIDES .............................................................. 9
1.2 AUDIENCE ............................................................................................... 10
2.0 PROBLEM .................................................................................................. 11
2.1 APPLICATION DEVELOPMENT AND INTEGRATION .................................................... 11
2.2 TRADITIONAL METHODOLOGIES....................................................................... 11
2.2.1 Point-to-Point Integration ................................................................... 11
2.2.2 Enterprise Application Integration ........................................................ 12
2.2.3 Business Process-Based Integration ..................................................... 13
2.2.4 Disadvantages .................................................................................. 13
2.3 WHY SOA?.............................................................................................. 14
3.0 SERVICE-ORIENTED ARCHITECTURE (SOA) ..................................................... 17
3.1 SOA SERVICES ......................................................................................... 17
3.1.1 Data Access Services ......................................................................... 19
3.1.2 Component Services .......................................................................... 19
3.1.3 Business Services .............................................................................. 19
3.1.4 Composite Applications....................................................................... 20
3.1.5 Shared or Enterprise Infrastructure Services ......................................... 20
3.1.6 Service Granularity ............................................................................ 20
3.2 CHARACTERISTICS AND BENEFITS OF SOA ......................................................... 22
3.3 HIGH-LEVEL SOA SOLUTION MODEL ................................................................ 26
3.4 SOA AND WEB SERVICES ............................................................................. 27
3.5 SOA AND ENTERPRISE SERVICE BUS (ESB) ....................................................... 28
3.6 SOA AND EVENT DRIVEN ARCHITECTURE (EDA).................................................. 29
3.7 APPLICABILITY AND DISADVANTAGES OF SOA ..................................................... 29
4.0 SOLUTION ................................................................................................. 31
4.1 THE BEA PLATFORM ................................................................................... 31
4.1.1 WebLogic Server ............................................................................... 32
4.1.2 WebLogic Integration ......................................................................... 33
4.1.3 Liquid Data for WebLogic .................................................................... 33
4.1.4 WebLogic Portal................................................................................. 34
4.1.5 WebLogic Workshop ........................................................................... 35
4.1.6 WebLogic Enterprise Security Framework .............................................. 36
4.2 SOA AND THE BEA PLATFORM ....................................................................... 36
4.3 CATEGORIZING SOA-BASED PROJECTS ............................................................. 41
BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - iii

4.3.1 Project Complexity............................................................................. 41
4.3.2 Project Phases................................................................................... 41
4.3.3 Project Types Matrix .......................................................................... 43
4.4 SERVICE IMPLEMENTATION PATTERNS ............................................................... 44
4.4.1 New Application Development ............................................................. 44
4.4.2 Adapting or Legacy Wrapping .............................................................. 44
4.4.3 Integration ....................................................................................... 44
4.5 WEB SERVICES PATTERNS ............................................................................ 44
5.0 BEST PRACTICES FOR IMPLEMENTING SOA ...................................................... 45
5.1 ARCHITECTURAL BEST PRACTICES ................................................................... 45
5.2 TECHNICAL BEST PRACTICES ......................................................................... 46
5.2.1 Coupling: Tight, Loose, or Decoupled ................................................... 46
5.2.2 Binding: Static, Brokered, or Dynamic .................................................. 46
5.2.3 Granularity: Fine or Coarse ................................................................. 47
5.2.4 Invocation: Synchronous or Asynchronous ............................................ 47
5.2.5 Shared or Common Services ............................................................... 48
5.2.6 Integration and Interoperability ........................................................... 49
5.3 ORGANIZATIONAL AND OPERATIONAL BEST PRACTICES .......................................... 49
6.0 EXAMPLE SOA PROJECT – SIMPLE, PHASE 1 .................................................... 51
6.1 CURRENT STATE AND CHALLENGES .................................................................. 51
6.2 REQUIREMENTS ......................................................................................... 52
6.3 RECOMMENDED PATH .................................................................................. 52
6.3.1 Assumptions ..................................................................................... 52
6.3.2 Project Steps .................................................................................... 52
6.3.3 Implementation................................................................................. 53
7.0 EXAMPLE SOA PROJECT – COMPLEX, PHASE 3 ................................................. 55
7.1 CURRENT STATE ........................................................................................ 55
7.2 CHALLENGES ............................................................................................ 55
7.3 REQUIREMENTS ......................................................................................... 56
7.4 RECOMMENDED PATH .................................................................................. 57
7.5 IMPLEMENTATION ....................................................................................... 58
8.0 DEPLOYMENT AND AFTER ............................................................................. 60
8.1 DEPLOYMENT ............................................................................................ 60
8.2 OPERATIONS, ADMINISTRATION, AND MANAGEMENT (OA&M) .................................. 60
9.0 SUMMARY ................................................................................................. 61
GLOSSARY ....................................................................................................... 62
INDEX ............................................................................................................. 64
BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - iv

TO LEARN MORE ............................................................................................... 66
ABOUT BEA ..................................................................................................... 67
BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - v

LIST OF FIGURES
FIGURE 1: POINT-TO-POINT INTEGRATION ..................................................................................... 12
FIGURE 2: EAI CONCEPTUAL ARCHITECTURE ............................................................................... 13
FIGURE 3: TRADITIONAL ENTERPRISE INFORMATION INTEGRATION .............................................. 14
FIGURE 4: ENTERPRISE APPLICATION USING SERVICE-BASED INTEGRATION ................................. 16
FIGURE 5: SOA ROLES AND INTERACTIONS .................................................................................. 18
FIGURE 6: PARTS OF A SERVICE .................................................................................................... 18
FIGURE 7: SERVICE GRANULARITY ............................................................................................... 21
FIGURE 8: SOA SOLUTION MODEL ............................................................................................... 26
FIGURE 9: EXPANDED SERVICES LAYERS ...................................................................................... 27
FIGURE 10: BEA PLATFORM ......................................................................................................... 31
FIGURE 11: BEA PLATFORM PRODUCTS ....................................................................................... 32
FIGURE 12: ENTERPRISE SOA USING BEA PLATFORM.................................................................. 40
FIGURE 13: OPTIMAL PROJECT PATH ............................................................................................ 43
FIGURE 14: INITIAL USER SYSTEM (SIMPLE)................................................................................. 51
FIGURE 15: WEB SERVICES-BASED SOLUTION – SIMPLE PHASE 1 CASE ........................................ 54
FIGURE 16: INITIAL ENTERPRISE SYSTEM (COMPLEX) .................................................................. 55
FIGURE 17: WEB SERVICES-BASED SOLUTION – COMPLEX PHASE 3 CASE...................................... 59
BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - vi

LIST OF TABLES
TABLE 1: DISTRIBUTED VS. SERVICE-ORIENTED ARCHITECTURES ................................................ 17
TABLE 2: SOA CHARACTERISTICS ................................................................................................ 22
TABLE 3: SOA CHARACTERISTICS AND THE BEA PLATFORM....................................................... 36
TABLE 4: SOLUTION/APPLICATION COMPLEXITY .......................................................................... 41
TABLE 5: SOA PROJECT PHASES ................................................................................................... 42
BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - vii

IMPORTANT NOTE TO USERS
While every effort has been made to ensure the accuracy of all information in this document,
BEA assumes no liability for any loss or damage caused by errors, omissions, or statements
of any kind in this document (including updates, supplements, or special editions), whether
from negligence, accident, or any other cause. BEA further assumes neither liability arising
out of the application or use of any product or system described herein, nor any liability for
incidental or consequential damages arising from the use of this document. BEA disclaims
all warranties regarding the information contained herein, whether expressed, implied, or
statutory, including (but not limited to) implied warranties of merchantability or fitness for a
particular purpose.
BEA makes no representation that the interconnection of products in the manner described
herein will not infringe on existing or future patent rights, nor do the descriptions contained
herein imply the granting or license to make, use or sell equipment constructed in accordance
with this description.
BEA reserves the right to make changes without further notice to any products herein to
improve reliability, function, or design.
All company and product names in this document may be trademarks of the company with
which they are associated.
BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - viii

1.0 INTRODUCTION
This document describes Service-Oriented Architecture (SOA), its advantages and
disadvantages, and gives example customer implementations.
1.1 THE SOLUTION ACCELERATOR GUIDES

BEA Solution Accelerator Guides provide insight into key functional requirements and
technical approaches that typically arise in enterprise and integration projects. These guides
are intended for the project teams implementing these solutions.
The Solution Accelerator series includes the following titles:

• Customer Synchronization Using WebLogic Integration 8.1
• Multi-source Synchronization Integration Patterns
• RosettaNet B2B Integration Using WebLogic Integration 8.1
• Custom Adapter Development – Best Practices Guide
• Dynamic Key Cross-reference Using WebLogic Integration 8.1
• Business Integration in the Telecom Industry
• WLI Capacity Estimate
• WLI Project Estimate
• Human Workflow using WLI 8.1
• Upgrading to WebLogic Integration 8.1
• WebLogic Workshop Team Development
Other documents are being developed for this series.
Each Solution Accelerator addresses the following key points:

• A typical customer problem
o Problems and associated business processes
o Typical industry solutions
o Pros and cons for each approach
• BEA 8.1-specific issues (and how to address them)

o Setup & configuration
o Error handling and logging
o Transactional integrity
o Performance optimization
o Other platform issues
BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 9

• One or more BEA 8.1-specific examples
o A complete scenario and use case walk-through using WLI 8.1
o Illustration of key design issues
o A complete illustration of platform architecture
BEA Solution Accelerators provide patterns and code samples from numerous successful
field engagements. These patterns and samples provide a starting point for actual projects.
Obviously, more complex projects may require field customization.
1.2 AUDIENCE
This document is aimed at the medium to advanced level, intended for Solution Architects
and Technical Consultants who need to design and implement an SOA Solution using
WebLogic Platform 8.1.
This information is also useful for Project Managers involved in orchestrating projects
requiring an SOA Solution.

2.0 PROBLEM
Enterprises use many different custom-built and off-the-shelf packaged applications to run
their business processes. Applications must be integrated, to share information and to create
new applications.
Application integration is one of the most critical issues faced by enterprise information
technology managers. Traditional application development and integration approaches have
been inflexible and have not been standards-based; they have not, therefore, facilitated an
agile enterprise IT environment which can support the changing needs of a dynamic
organization.
This chapter discusses traditional application development and integration methodologies,

and introduces service-oriented architecture (SOA). The following chapter gives a detailed
overview of SOA.
2.1 APPLICATION DEVELOPMENT AND

INTEGRATION
In large enterprises, applications must interact with business data from one or more sources,
some of which may be other applications. In other words, applications cannot be developed
without integration.
On the other hand, application integration requires certain application development tasks,
such as developing and assembling components, connecting them to back-end systems,
implementing process flows and work flows, developing user interfaces, testing and
debugging.
It is no longer useful to consider application development and application integration

separately.
2.2 TRADITIONAL METHODOLOGIES

Application development and integration methodologies have evolved to allow IT to keep
pace with the rapid growth and change of businesses. However, the rate of technology
change lags behind the rate of business change. In most enterprises, the IT department’s lack
of agility impedes the enterprise from changing according to customers’ needs.
Three of the most common application integration methodologies were point-to-point

integration, enterprise message bus or middleware integration (known as EAI), and business
process-based integration.
2.2.1 Point-to-Point Integration

In point-to-point (or peer-to-peer) integration methodology, applications integrate with other
applications as needed. The following diagram shows a typical point-to-point integration:

FIGURE 1: POINT-TO-POINT INTEGRATION
The interconnections shown could also be built with Web Services. That would not make this
an SOA-based system, because it lacks other characteristics such as loose coupling,
intermediary based, and shared infrastructure.
2.2.2 Enterprise Application Integration

Because point-to-point integration was complex, costly, and difficult to maintain, another
approach was introduced. This approach was called Enterprise Application Integration (EAI),
which was based on a message bus/broker or middleware. In this case, connectivity between
the applications and the message bus was developed using proprietary bus APIs and
application APS.
The following diagram shows the high-level conceptual architecture for EAI:

FIGURE 2: EAI CONCEPTUAL ARCHITECTURE
2.2.3 Business Process-Based Integration

The business process-based approach improves on EAI. In this case, a business process flow
engine is used in conjunction with the message bus or middleware to run process flows that
execute multi-step transactions with various systems.
2.2.4 Disadvantages
None of the traditional approaches described above is ideal. Some of the problems are:
• Custom or proprietary integration between message bus and applications. Both EAI and
business process-based integration reduce the number of integration points compared
with the peer-to-peer approach. However, all three approaches require custom or
proprietary integration between the message bus and each application, and different and
proprietary data formats were involved at each integration point.
• Tight coupling between message bus and applications. All the applications need to know
the inner workings of the other applications they are integrated with. The integration
between systems is granular and tightly coupled by message type. The business process
management (BPM) tools used in traditional EAI implementations were proprietary.
This prevented the use of best of breed products.

• Programmatic rather than abstracted data access. The challenge of accessing, integrating
and transforming data (enterprise information integration) has largely been left to
developers to perform using manual coding. The presence of disparate data sources is a
fact of life in enterprise IT environments. Developers have adapters for accessing data
sources, transformation engines for reformatting data, and replication for physically
consolidating the data. To integrate data sources, developers use these tools to program
the integration requirements into applications. Although this approach works, it is neither
efficient nor flexible, for these reasons:
o Lack of abstraction. Programmers must use low-level API’s to implement
integration requirements, which greatly increases development and maintenance
costs.
o Multiple data formats. Each data source has its own API and data format. The
developer must understand each data source in sufficient detail to manage the data
integration. This often requires multiple specialists to implement and maintain the
integration, driving up complexity and cost.
o Custom information integration framework. The developer has to manage all the
integration issues such as the relationships between data sources and data formats.
This leads to one-off solutions and inconsistencies that are difficult to maintain.
o Tight coupling. Programming creates hardcoded dependencies between applications

and data sources. Updating a data source can break many applications, which
hampers maintenance.
o Limited reusability. The integration code tends to be specific to each application and
data source, making it difficult to reuse.
FIGURE 3: TRADITIONAL ENTERPRISE INFORMATION INTEGRATION
2.3 WHY SOA?

All three traditional application integration approaches are complex, costly, and inflexible.
These approaches don’t support the needs of business changes. Service-Oriented

Architecture (SOA) based application development and integration, however, solves many of
these problems.
A set of standards based interaction patterns defined by SOA enable a consumer application
to utilize services. These approaches define how services are described, advertised,
discovered, and communicate with services.
Unlike the approaches described earlier, in SOA, all patterns around a service are
implemented on standards-based technologies. Most communication middleware systems,
such as RPC, CORBA, DCOM, EJB, and RMI, rely on similar patterns. No implementation
is perfect; issues exist with interoperability as well as defining acceptable standards.
SOA attempts to eliminate these weaknesses. For example, each middleware system has a
fixed granularity: functions for RPC, objects for CORBA, and so on. Services, however, can
be defined as functions, objects, applications, or other things. This makes SOA adaptable to
any existing system, and does not force the system to conform to any particular level of
granularity.
SOA helps information systems move toward a “leave-and-layer” architecture, meaning that
instead of altering existing systems to provide a Web Services interface, they are wrapped
with a layer that provides the Web Services interface. Instead of replacing existing
architectures, SOA transforms systems and applications into agile services. SOA covers not
only the information from packaged applications, custom applications and legacy systems,
but also the functionality and data from IT infrastructure such as security, content
management, search, and so on. SOA-based applications are faster to build because they can
easily add functionality from these infrastructure services.
The following figure provides a high-level view of enterprise applications using service-
based integration. Note the resemblance to Figure 2: EAI Conceptual Architecture.
However, the key differences are that this system uses standards-based services and includes
process/data services, orchestration, and composition. The standards-based services become
the integration points between applications. Orchestration and composition of services add
flexibility, reuse, and integration of services.

FIGURE 4: ENTERPRISE APPLICATION USING SERVICE-BASED INTEGRATION

3.0 SERVICE-ORIENTED ARCHITECTURE
(SOA)
A Service-Oriented Architecture (SOA) is a software design approach that allows enterprises
to focus on business processes in their application development, rather than focusing at a
lower level on integration or application issues. An SOA is a collection of reusable
networked services, communicating through well-defined, platform-independent interfaces.
These services provide access to data, business processes, and IT infrastructure, and they
allow for service provision, consumption, and lifecycle management.
The following table highlights the differences between distributed component architectures
and SOA:
TABLE 1: DISTRIBUTED VS. SERVICE-ORIENTED ARCHITECTURES
Distributed Component Architecture Service-Oriented Architecture

Functionality oriented Process oriented
Designed to last Designed to change
Long development cycle Interactive and iterative development
Cost-centered Business-centered
Application block Services orchestration
Tightly coupled Agile and adaptive
Homogeneous technology Heterogeneous technology
Object-oriented Message-oriented
Known implementation Abstraction
SOA provides many advantages over traditional approaches; it is:
• Standards-based
• Loosely coupled
• Shared services
• Coarse grained
• Federated control
These attributes are discussed in detail in later sections.
3.1 SOA SERVICES

The following diagram shows the three fundamental roles in an SOA – service providers,
consumers, and brokers – and some of their artifacts and operations.

FIGURE 5: SOA ROLES AND INTERACTIONS
Services are software resources available on the network. Service providers expose services
via standard mechanisms, and service consumers consume services programmatically over a
network. Service brokers publish the whereabouts of services, and locate services when
requested by a consumer. The consumer and provider roles are not exclusive; service
providers can also be consumers, and vice versa.
Providers describe their services in standard language in a service contract and publish it with
a broker. Clients query service brokers (or registries) for the services they want, and receive
the contract and information on accessing the service. The client or consumer then binds to
the service and calls the provider directly.
A service has two parts: the interface and the implementation.
Service
Interface Implementation
FIGURE 6: PARTS OF A SERVICE

The interface defines the programmatic access contract between the consumer and the
provider. A service interface must contain:
• Identity of the service

• Input and output data details of the service
• Metadata on service’s functionality and purpose
The service implementation contains the functional or business logic of the service. The
implementation should be a “black box” to the service consumer; the consumer doesn’t need
to know the functional implementation of the service.

There are five types of service:
• Data Access – allows uniform access to different data sources.

• Component – provides access to the services of packaged applications such as ERP.
• Business – provides complex services that use more than one function of packaged or
custom applications.
• Composite – uses the three above types to create a new service that includes both new
and existing functionality.
• Shared or Enterprise Infrastructure Services – lower-level services, such as message
logging, whose reuse allows rapid creation of new higher-level services.
3.1.1 Data Access Services

Data access services allow users to access, integrate, translate and transform data from
various relational and non-relational data resources across the enterprise. These services
typically hide the direct access to the resource, the complexity of the underlying formats, and
the direct transformation and manipulation of data. They provide a uniform API, loose
coupling, a common data model and re-use of consistent information across applications.
Services for data access are the most common, widely used, and easily implemented services
in an SOA architecture; separating the data layer and the application layer is generally
straightforward. As data resources are widely accessed and shared, they become the first
target for implementation as services.
XML is widely used for application data exchange. An infrastructure that provides abstract,
uniform data access, regardless of the source, is valuable in SOA implementations. XML
Data Services (XDS) supplies access to multiple types of data resources, data modeling
capabilities, translation and transformation of physical data to logical data, and XML-based
access to logical data.
3.1.2 Component Services

Component services are coarse-grained services that are published from a single enterprise
resource, whether it is a packaged application (for example, ERP, CRM, or SCM). An
example of a component service might be “Add Customer in ERP.” These services are
considered valuable enough to be published directly.
Component services are implemented by using individual application APIs to expose reusable
functionality. These services can be implemented using distributed computing technologies
such as J2EE EJB, COM/DCOM, and CORBA.
3.1.3 Business Services

Business services are functionality, exposed from business applications, which perform one
or more business operations. Business services are usually composed of multiple business
transactions across multiple applications. They may be end-to-end business processes, for
example, Process New Hire, or they may need to be part of a larger business context, as in the
following examples:

• Provision New DSL Line
• Add New Employee
Provision New DSL Line needs to be part of a larger context such as DSL Order Processing,
requiring information from that process to complete its business function.
3.1.4 Composite Applications

Composite applications are created by combining brand-new logic with transactions that have
been exposed by existing applications as, for example, business or component services.
Application integration technologies and business process management tools play key parts in
creating composite applications.
Function-specific portals such as Sales Portal and Employee Portal are examples of
composite applications; these would require business, component, and data services.
3.1.5 Shared or Enterprise Infrastructure Services

The greatest value provided by an SOA is the ability to compose applications rapidly and
consistently by reusing existing services. These can be called Shared Services, Common
Services, or Enterprise Infrastructure Services.
Infrastructure services can be categorized into four types:
• Shared Application Services

• Messaging and Brokering Services
• Portal Services
• Shared Business Services
Some examples of infrastructure services are:
• Service Repository
• Service Finder and Broker
• Single Sign-on
• Content Brokering
• Logging Service
• Monitoring
• Unique ID Generator
• Data Services
• Security Services
3.1.6 Service Granularity

Services can be defined, based on their functionality and the amount of data they send and
receive, as fine-grained, coarse-grained, or composite.

Granularity of service has two related meanings in SOA: how the services are implemented,
and how much data, or how many messages, are consumed and returned by the service. Fine-
grained services implement minimum functionality and send and receive small amounts of
data. Coarse-grained services implement larger business functions and exchange larger
amounts of data.
Fine-grained services are best consumed by coarse-grained or composite services rather than
directly by end applications. If an application is built using fine-grained services, the
application will have to invoke multiple services over the network, each of which exchanges
small amounts of data. Consumers of coarse-grained services are not exposed to the fine-
grained services that they use. However, coarse-grained services can’t provide granular level
security and access control, as they may use multiple fine-grained services.
Composite services can be assembled using coarse-grained and fine-grained services.
Composite services can be assembled from coarse-grained and fine-grained services.

Between coarse-grained services and composite services, the amount of data is not the
differentiator.
A coarse-grained service might be Create New Customer, which would need to validate the
customer with some external service and create the customer record in a CRM application.
A composite service might be Provision New DSL Line, requiring a service call to validate
the order, creating or verifying a customer, checking for product availability and allocating
the resources for the line.
The following diagram depicts the different levels of service granularity and their
relationships.
FIGURE 7: SERVICE GRANULARITY

3.2 CHARACTERISTICS AND BENEFITS OF SOA
An SOA-based solution requires a certain set of characteristics from an SOA infrastructure;
these are listed in the following table, along with attributes required to manage and support an
SOA infrastructure.
TABLE 2: SOA CHARACTERISTICS
Characteristics Description Benefits, Applicability and Notes

Loose Service providers and Loose coupling removes the need for tight control of
Coupling consumers can be developed both ends of systems. Each system can be
independently using well- independently managed for performance, scalability,
defined interfaces. and high availability.
Service implementers can It does not remove any run-time dependencies. It
change interface, data, or could divide the dependencies over a number of
message versions in the service providers, but if the runtime system needs
service without impacting 24x7 availability and 50000 throughputs per second,
consumers. then these are requirements on the service providers
and must be met.
Implementation changes are hidden.
Loose coupling gives providers and consumers
independence, but requires standards-based interfaces
and an intermediary to actively manage and broker
requests between end systems.

TABLE 2 (CONTINUED): SOA CHARACTERISTICS

Industry “True” industry standards are Using standards-based technologies breaks
Standards-based endorsed by technology leaders such vendor lock-in and facilitates best-of-breed
BEA, IBM, Microsoft, Sun, Oracle, combination of vendor products.
W3C, and Oasis. SOA is widely The concept of loosely coupled layers
accepted because it can be depends upon broad support for standards
implemented using standards-based both internally and externally.
technologies.
Prevents the need to have
proprietary clients.
Reusable As services are published in a Reuse of services eliminates duplicate
Services directory and available over a development efforts and promotes
network, they become more easily consistency in implementation.
discoverable and reusable. If a Reuse of services is easier to accomplish
service cannot be reused, it may not than component or class reuse, which have
require a service interface at all. been tried without much success in the past.
Services can be reused by re-
combining them for different
purposes.
Synchronous In a synchronous service call, the Synchronous service calls provide
Service Calls caller makes the call, passes the immediate response to a request if the
(RPC Style) required parameters, blocks, and service provider is available.
waits for the response. Synchronous services are essential for
applications requiring real-time response, for
example, Portal or Query.
Asynchronous In asynchronous service calls, the With the use of coarse-grained messages and
Service Calls caller posts a message with full a messaging service, service requests can be
(Document Style) context to a messaging service that queued and processed at the optimum
delivers it to the recipient. The system speed. This approach provides high
recipient processes the message and scalability as the messaging system can
returns the response to the caller via queue as many requests as its queue depth
the message bus. The caller does not allows (tunable). Callers do not hold
block while the message is being network connections for the processing
processed. duration, and as callers don’t block, they are
not negatively impacted by processing
delays and problems in the execution of an
asynchronous service.
This implementation assumes support for
callbacks, which is not part of Web Services
standards.


Non-intrusive Existing software components Eliminates the need for modifying, testing, and
Development don’t need to be modified to maintaining existing software.
(developing expose their functionality as With composite services, the functionality
services by using services. Services are developed from existing investments can be reused and
existing software or generated using the interface recombined to create new value for the
components) definition of a component. enterprise.
An example is creating WebLogic Workshop
controls for existing EJBs.
Policy When shared services are used Policy-based computing promotes the creation
Management in applications, the rules specific of generic reusable services. As customization
to each application are of services for specific applications is
externalized as policies. externalized, application implementation
Policies must be managed and changes are minimized.
applied for each service at An organization’s operations and support
design and run time. group rather than the development group
typically enforces policies. Without the use of
policies, application developers and operations
and support groups have to work together
during development time to implement and test
policies. Using policies, allows developers to
focus on application logic while the operations
and support group focuses on rules.
Data Access Data access, integration, Hides data source complexity and enforces
Services transformation and reuse consistency, integrity and security across data
services. sources.
Composite Composite services combine Leverages existing IT investments. Suitable for
Services new and existing application green-field and legacy implementations.
logic and transactions. Assembly or orchestration products simplify
the integration of heterogeneous systems.
Shared or Common services used by all Using shared infrastructure services provides
Enterprise applications built using SOA are consistency and allows a single point of
Infrastructure called shared infrastructure administration.
Services services. Using a shared Other shared services, such as security related
infrastructure to provide services, can be built by exposing existing
common services prevents each products as services.
application from building
similar services.
See Error! Reference source not
found. in the previous section
for examples.


Fine-grained A fine-grained service implements minimum Fine-grained services have the
Services functionality and consumes and returns a benefit of imposing strict security
minimum amount of data. and access policies at a granular
Fine-grained services can be implemented level.
using Web Services, or distributed objects Implementation and unit testing
using RMI, .NET, or CORBA. are simple and independent.
See 3.1.6 Service Granularity in the previous
section for examples.
Coarse-grained Coarse-grained services implement more Coarse-grained services do not
Services functionality than fine-grained services, and require multiple calls over the
consume different amounts of structured data network to provide meaningful
or messages. They return similar data or business functionality.
messages, possibly with embedded context.
See 3.1.6 Service Granularity in the previous
section for examples.

3.3 HIGH-LEVEL SOA SOLUTION MODEL
Enterprise infrastructure or shared services add great value in an SOA. Shared services are
typically implemented in logical layers based on their functionality and locality. The
following diagram shows a high-level view of an SOA solution model applying the SOA
characteristics discussed in the previous section. The characteristics are implemented by a
shared services layer, which is logically grouped into several service layers. The figure uses
some of the applications and services developed by the BEA Information Technology group
as an example. The next diagram expands each services layer.
FIGURE 8: SOA SOLUTION MODEL

This diagram shows some of the common services for each service layer; obviously these will
differ for each enterprise. These are examples of services implemented and envisioned by the
BEA Information Technology group.
FIGURE 9: EXPANDED SERVICES LAYERS
3.4 SOA AND WEB SERVICES

SOA does not require Web Services for implementation, and Web Services deployment does
not result in an SOA. Web Services, however, are a good example of a service, and are a
component (not a necessary component) of an enterprise SOA.
SOA provides conceptual design patterns for service-based distributed systems. Web
Services provide standards-based technology to implement an SOA in a cost-effective
manner using communication methods available everywhere today. When the Web Services
Definition Language (WSDL) is used to define the service interface, then the service is a
Web Service.
CORBA IDL, Tuxedo FML (more of a data format definition than an interface definition
language), COM/DCOM Microsoft IDL, and CICS common area (COMMAREA) were the
other service definition languages prior to the wide acceptance of WSDL.
In the past, CORBA, EJB, COM/DCOM, CICS, and Tuxedo provided service-based
application development and integration technologies for implementing an SOA. CORBA,

EJB and COM/DCOM provided object-based distributed systems, in which the objects
provided functions or methods that performed certain services.
SOA provides an architecture to manage the many loosely coupled services developed using
Web Services or other similar technologies. Web Services can be implemented using J2EE
based application servers, Enterprise Service Bus (ESB), or the .NET framework.
J2EE application server-based Web Services implementations use components and

applications developed using J2EE specifications, such as EJBs, Servlets, and JDBC, and
expose (JAX-RPC) them as Web Services using SOAP over HTTP or over JMS.
Asynchronous, coarse-grained Web Services are implemented using JMS services provided
by the application server.
In addition to pure J2EE-based Web Services implementations, BEA Platform provides

value-added and abstracted, controls-based, process flow-based Web Services
implementations with WS-Acknowledgement specification support.
3.5 SOA AND ENTERPRISE SERVICE BUS (ESB)

Web Services-based SOA can also be implemented using an Enterprise Service Bus. An ESB
combines publish/subscribe messaging, synchronous (RPC) and asynchronous messaging,
basic transformation, content-based routing, and native Web Services support. In addition,
ESBs support a range of application servers. An ESB acts as a shared messaging layer for
connecting applications and other services throughout an enterprise. Originally defined by
analysts at Gartner, ESB is increasingly seen as a core component in a service-oriented
infrastructure.
J2EE Connector Architecture (J2EE CA) based adapters are usually used to integrate ESBs
with enterprise systems. The ESB supplements its core asynchronous messaging backbone
with intelligent transformation and routing to ensure that messages are passed reliably.
Services participate in the ESB using either Web Services messaging standards or the Java
Message System (JMS).
An important distinction between JMS and Web Services is that JMS is a Java programming
API, whereas Web Services provide a standard wire-level protocol (SOAP over HTTP). This
means that JMS does not remove the interoperability problems associated with proprietary
messaging solutions. Every JMS provider (e.g. WebLogic, Sonic, Firano) implements a
proprietary protocol between the JMS client and the JMS server. Therefore, there is no
interoperability between JMS clients and servers; for example, a Sonic JMS server can only
be accessed by a Sonic JMS client.
ESBs can provide global messaging with location transparency; however, an ESB by itself
can’t provide the complete infrastructure for SOA. For example, it is difficult or impossible
to implement application logic, components, process flow logic, and workflows using an
ESB, but those can be implemented and service-enabled rapidly by the BEA Platform. For an
enterprise that is not geographically distributed, an ESB is not required to implement SOA.

3.6 SOA AND EVENT DRIVEN ARCHITECTURE (EDA)
In enterprises, systems go through state changes. An event is triggered by a state change and
carries data about that change to other systems or people.
Businesses can benefit from handling events due to real-time system state changes. For
example, instead of periodically checking to reorder items for a warehouse, the warehouse
management system can trigger an event when a threshold for low item count is reached.
That event can then kick off alerts to re-ordering systems.
According to Gartner, the fundamental architectural pattern of modern, agile enterprise IT is

service-oriented and event-driven.
Event-Driven Architecture is an approach for designing and building applications in which

events trigger message to be sent between independent, decoupled modules that are unaware
of each other. An event source typically sends messages to a middleware or message broker
that has subscribers registered for that message. Since the event messages are delivered
through a message broker using the publish/subscribe approach, it is possible for one event to
be delivered to multiple consumers. This is the main difference between EDA and SOA: in an
SOA the producer and the consumer have a one-to-one relationship, and in an EDA an event
producer can eventually deliver one message to any number of consumers based on the
subscription rules registered with the message broker.
Advanced EDA implementations must support complex event processing, in which multiple
related events are aggregated using policy-based rules and a single business event or service
is triggered. iSpheres, a BEA partner, provides an example implementation of this feature. It
is also possible to custom-build this feature using the BEA Platform.
EDA and SOA are complementary architectures. An EDA source can be an SOA consumer
or server application, and an EDA consumer can be an SOA client program. BEA WLI’s
Message Broker, various Event Generators and Adapters, along with BPM, are fully capable
of tying EDA-based and SOA-based implementations together.
SOA is used when a business problem requires a request/response or real-time solution, and
the client knows the service provider ahead of time. EDA is suitable when business requires
one-way messaging, involves long-running asynchronous process, and the event source
doesn’t need to know who the event receivers are.
3.7 APPLICABILITY AND DISADVANTAGES OF SOA

Use of SOA requires additional design and development efforts and infrastructure, which
translates into additional IT costs. Therefore SOA may not be a viable architecture for all
cases.
For the following applications, SOA and Web Services may not be the recommended
architecture:
• Stand-alone, non-distributed applications that do not require component or application

integration; for example, a word processing application does not require
request/response-based calls.

• Limited scope or short-lived applications; for example, an application that is built as an
interim solution, not intended to provide functionality or reuse for future applications.
• Applications where one-way asynchronous communication is required, and where loose
coupling is unnecessary and undesirable.
• A homogeneous application environment; for example, in a environment where all the
applications are built using J2EE components. In this case it is not optimal to introduce
XML over HTTP for inter-component communications instead of using Java RMI.
• Applications that require rich, GUI based functionality; for example, a map manipulation
application with lots of geographical data manipulation is not suitable for service based
heavy data exchange.
Most of the above scenarios do not apply to enterprise applications. As SOA is network-
centric, it requires complex monitoring and auditing of services. As service reuse and sharing
are key characteristics of SOA, the number of consumers of services will be very high, which
raises versioning, change management, and metering issues. These issues require a
management infrastructure that may be too expensive for some projects.
SOA is a strategic solution with significant tactical applications and benefits; however, there
is a threshold to be passed to get the full benefit of SOA. SOA usually requires analysis of
costs and benefits.

4.0 SOLUTION
This chapter defines what types of SOA projects need to be implemented using the BEA
Platform, and provides some implementation solutions. First it gives a brief overview of the
BEA Platform, and then maps SOA characteristics onto BEA Platform features. Later it
classifies SOA projects according to complexity and phase, with a typical project for each
classification.
From here, Web Services will be used as the default SOA implementation. Some popular
Web Services patterns are discussed and used in the solution implementation.
4.1 THE BEA PLATFORM

The BEA Platform consists of WebLogic Portal, WebLogic Integration, WebLogic Liquid
Data, WebLogic Workshop, WebLogic Enterprise Security, and WebLogic Application
Server. The following diagram gives a high-level representation of the Platform.
FIGURE 10: BEA PLATFORM

This figure illustrates the high-level features of each of the products in the Platform. A brief
description of each product follows.
FIGURE 11: BEA PLATFORM PRODUCTS
4.1.1 WebLogic Server

WebLogic Server, the world’s leading industrial-strength application server underlying the
WebLogic Platform, enables customers to deliver enterprise-class applications in less time at
lower cost while simplifying infrastructure complexity.
• Speed development - Any developer can be immediately productive building enterprise-

class applications faster than ever before.
• Leverage existing assets - Out of the box interoperability with existing infrastructure and
frameworks unifies the enterprise and reduces cost.

• Secure applications - Design and implement real-time, real-world security policies at
runtime with no application coding.
• Simplify management - Simplify and automate operations, gain visibility into
applications and infrastructure.
• Deploy with confidence – Enterprise-grade foundation.
WebLogic Server also includes WebLogic JRockit™, the first JVM uniquely optimized for
server-side applications on the Intel platform. It allows Java applications to run with
increased reliability and performance on lower-cost, standard-based platforms.
4.1.2 WebLogic Integration

WebLogic Integration delivers a robust, unified application integration framework that
enables customers’ operations to fit business goals by delivering rapid, open integration. It
provides:
• Business process management - Boosts efficiency with an environment for defining,

executing, and managing business processes that are optimized from end to end.
• Enterprise resource access - Improves organizational responsiveness by opening up siloed
and proprietary data; and by supplying secure, rapid and consistent access to information,
applications, partners and users.
• Dynamic integration services - Enhances business adaptability by dramatically reducing
the time IT needs to reliably and securely meet changing business requirements.
4.1.3 Liquid Data for WebLogic

BEA Liquid Data for WebLogic is an Enterprise Information Integration (EII) solution that
allows all enterprise information to be operated on as if it came from one global data source.
To access information, the user can develop Web Services or write queries against this
unified view, instead of writing custom code to directly access underlying sources, manually
coding data transformations, and joining data from multiple sources.
Liquid Data uses existing connectivity tools (JDBC drivers, adapters etc.), and provides
access, transformation, joins, cache and security functionality needed by enterprise-class
portal and web applications for accessing multiple data sources.
• Cheaper, better, faster development – an IT developer can write simple queries against a
logical view that hides the complexity of heterogeneous sources, and can automatically
access, transform and join data from multiple sources. Queries are faster to write, easier
to maintain, and can be written by project teams rather than relying on expensive
integration resources.
• IT responsiveness and adaptability - IT can be more responsive to changes in business
requirements because they can easily create or change queries on existing unified views.
• Data consistency across applications and business processes - enables standardized views
of business information across systems.
• Application ease of maintenance - the abstraction layer isolates applications from
changes to underlying data sources. This eliminates the need to modify and test
potentially hundreds of portlets and applications that would have been impacted by

changes in the schema definition of an underlying data source.
• Responsiveness/time to value - reduces latency and increases use of information
previously hidden in distributed systems, enabling more responsive organizations and
services. For example:
o Customer service representatives want a single view of the customer.
o Executives want up-to-date sales and revenue information.
One of the key benefits is the ability to provide a single view of business information (a
single view of customer, product, or trade etc.) in one standard way, significantly reducing
development and operational costs across multiple projects.
4.1.4 WebLogic Portal

A portal is a Web site that simplifies and personalizes access to content, applications, and
processes. Customers may host many sites within a single WebLogic Portal server. Portals
are becoming more and more important to companies, which have an ever-increasing need to
provide employees, partners, and customers with an integrated view of applications,
information, and business processes.
WebLogic Portal delivers the first enterprise portal infrastructure for streamlined portal
development. WebLogic Portal is the only enterprise portal platform that also simplifies the
production and management of custom-fit portals (Employee Self Service and Options
Center).
WebLogic Portal allows companies to build portals that combine functionality and resources
into a single interface. It also allows companies to enforce business policies, processes, and
security requirements, and provides personalized views of information to end users. To the
end user, a portal is a Web site with pages that are organized by tabs or some other form of
navigation. Each page may contain nested sub-pages, and does include one or more portlets—
individual windows that display anything from static HTML content to complex Web
Services.
A page can contain multiple portlets, giving users access to different information and tools in
a single place. Users can customize their view of a portal by adding their own pages, adding
the portlets they want to those pages, and changing the look and feel of the interface.
• Lower cost of ownership - the industrial strength foundation includes a flexible

deployment architecture that drives maximum portal value at minimum cost. At the same
time, enterprise integration capabilities extend portals to leverage current and future
application investments.
• Simplified production - the end-to-end portal lifecycle management simplifies production
and management. The development framework extends BEA WebLogic Workshop for
rapid portal development while intelligent administration simplifies and distributes portal
assembly and management.
• Accelerated business solution delivery - modular, pre-integrated services include content
management, collaboration, search, commerce, and interaction management. These
services help minimize risk and meet specialized requirements.

4.1.5 WebLogic Workshop
BEA WebLogic Workshop 8.1 enables any developer – even those new to Java or J2EE – to
build service-oriented, enterprise-class Web applications and Web Services with productivity
levels never seen in the Java world before.
Once you can build Web applications and Web Services with Workshop, you can build any
WebLogic Platform application – including Portals and Integration applications – using the
same simplified Workshop approach of visual development, events, properties, and controls.
BEA WebLogic Workshop enables you to:
• Dramatically simplify application development

• Use one development approach across IT
• Build enterprise-class Web applications faster than ever before
• Build powerful, enterprise-class Web Services
• Begin building an SOA today
• Drive dramatic productivity gains for XML developers
• Enjoy world-class IDE features
In short, Workshop combines visual development with a simplified development model and a
runtime framework to make J2EE development easier than ever before.
BEA WebLogic Workshop 8.1 capabilities:
• Dramatically simplified development with a single approach across IT

o Visual Development: WebLogic Workshop 8.1 simplifies J2EE development with a
visual development environment and simplified programming model.
o Runtime Framework: The Workshop application framework abstracts infrastructure

complexities and creates applications using standard J2EE components.
• Begin building an SOA today

o WebLogic Workshop 8.1 enables any developer to connect to and use any IT asset as
a reusable service with Java Controls, including databases, systems, custom or
vendor applications, and Web Services.
o Java Controls hide the J2EE complexity in connecting to any asset, and can be used
in any Workshop application, from Web applications and Web Services to portal and
integration applications.
• Now, with WebLogic Workshop 8.1, developers can create custom Java Controls or use a
host of new Java Controls from BEA partners.

4.1.6 WebLogic Enterprise Security Framework
BEA WebLogic Enterprise Security (WLES) allows applications across an enterprise to
leverage (through the Common Security Mechanism) common security functions such as
authentication, SSO, role mapping, authorization, and auditing.
• Strengthens security and increases efficiency by providing unified and sophisticated

security policy administration.
• Delivers an “enabling” user access experience while still ensuring the necessary levels of
application security through patented distributed computing security architecture.
• Increases efficiency and strengthens application security by allowing applications across
the enterprise to leverage security services provided by a common, consistent application
security infrastructure.
• Allows 3rd party security technologies to be easily integrated into the application security
infrastructure through open, interoperable Security Service Provider Interfaces (SSPIs)
that are partner, customer and integrator friendly.
4.2 SOA AND THE BEA PLATFORM

This section describes SOA characteristics and how they map onto the BEA Platform. These
characteristics have been categorized into three levels – Basic, Intermediate, and Advanced.
Levels are determined by the number of characteristics used in an SOA implementation.
Basic characteristics were described in more detail in 3.2 Characteristics and Benefits of
SOA. Intermediate and Advanced characteristics are explained below.
TABLE 3: SOA CHARACTERISTICS AND THE BEA PLATFORM
Category SOA Characteristics BEA Platform Notes

SOA Basic Standards-based Supports: WSDL, HTTP(S), JMS, SOAP,
UDDI, RMI
Reuse of services Controls and UDDI enable reuse of service.
Controls provide a common façade for
reusing programming constructs such as
EJBs, Database access, EIA (Application
Views), Sub process flows, and Web
Services.
Data access services Provided by Liquid Data Data Views (App
Views are at the connectivity layer that are
used just like WS or JDBC), and Adapters.
Fine-grained services EJBs, Servlets, Controls, Web Services
Coarse-grained services Controls, Web Services, Process Flows
(JPD), Tuxedo
Composite services Process Flows

TABLE 3 (CONTINUED): SOA CHARACTERISTICS AND THE BEA PLATFORM

SOA Basic Synchronous service calls (RPC HTTP(s), JRMP (RMI), CORBA (IIOP)
style)
Asynchronous service calls JMS, WS-Acknowledgement,
(Document style) Conversational Web Services
Non-intrusive reuse of software Controls, Web Services, Adapters
components
Loose coupling UDDI, SOAP over JMS (Coarse-grained,
asynchronous)
Shared infrastructure services The BEA Platform includes a large number
of infrastructure services including security,
database connection pooling, transactions,
logging, monitoring, messaging, etc.
BEA Platform’s security service provides
policy-based security control through
WLES. For example, WLS supports Web
Services Security, and roles allowed can be
specified for each method on a Web Service.
WLES adds even greater policy flexibility
for security services.
Most of the other common services in the
Platform do not have policy-based service
control.
SOA Policy-based control of services WLES provides policy-based security
Intermediate services. Policy-based control for other
services requires a service management
product.
Versioning of services It is possible to do some process flow
versioning. However, SOA service
versioning requires a partner service
management product.
Automated registration, A development-use UDDI is provided with
discovery, and provisioning of the WebLogic server; it is not recommended
services for production deployment.
A simple UDDI does not provide the rich set
of features required for an enterprise SOA.
A partner service management product
would provide these features.

Guaranteed delivery For an asynchronous message-based SOA
implementation, guaranteed message
delivery is critical.
WebLogic server provides JMS messaging
capability with guaranteed delivery.
WebLogic Integration provides Message
Broker, an abstract messaging layer on top
of JMS, with guaranteed delivery.
Policy-based SLA, QoS, routing Other than security policy-based SLA, QoS,
or routing is not available with WebLogic
Platform. However, policy-like attributes for
SLA can be set for WLI process flows using
the WLI Administration Console.
Transparent distribution of A clustered WebLogic server with a
services software or hardware load balancer can
provide this service.
SOA Extensible alerts and notification The WebLogic Platform supports JMX.
Advanced for monitoring and management Built-in notifications and alerts can be used
for monitoring, and custom alerts can be
built using JMX as well.
Statistics of services for analysis WebLogic Platform consoles provide basic
monitoring and tracking data. The
WebLogic server only keeps monitoring
data for the current server run; it does not
archive the data. WebLogic Integration logs
monitoring-related data to a database.
The WebLogic Platform does not provide
tools to analyze the collected monitoring
data. Analytical and reporting tools are
available from BEA partners.
XML firewalls With the wide use of XML as the messaging
standard, an increased amount of network
traffic carries XML data. Specialized
network firewalls for XML are required to
ensure security and integrity of messages.
An XML firewall intercepts traffic, inspects
the XML data, and redirects and transforms
data according to policies. Depending on the
message content, it can make security and
routing decisions as well.

High-speed XML processing XML is verbose, which increases data size.
High-speed XML processing features are
required to process large and high-volume
XML messages.
WebLogic Platform’s XQuery engine can
provide high-speed XML transformation.
However, large XML messages could
benefit from hardware-based XML
processors.
The current BEA Platform can enable an SOA and support most of the characteristics listed.
While the advanced features can be implemented using BEA Platform, as our services
management product partners are doing, they are not available out of the box.

FIGURE 12: ENTERPRISE SOA USING BEA PLATFORM

4.3 CATEGORIZING SOA-BASED PROJECTS
SOA-based projects can be classified into separate groups based on two attributes –
complexity and phase. These classifications are based on experiences with customers who
are considering implementing, or have implemented, SOA-based projects.
4.3.1 Project Complexity

Here, complexity – simple, medium, or complex – refers to the complexity of the technical
solution, and the type of application(s) developed in the project.
TABLE 4: SOLUTION/APPLICATION COMPLEXITY
Complexity Areas
• Departmental
• Typically a single tactical solution for a business problem
Simple • Web Services-based integration and service enablement – basic connectivity to
important resources (mostly services-based data access layer)
(Level 1)
• Provides an Application Platform Suite (Portal, Integration, Messaging) that allows
development of fine-grained and coarse-grained services
• Service-oriented development of applications (SODA)
• Inter-departmental
• Provides a framework for composite application development with more than one
application involved
Medium
• Promotes policy-based computing, policy management/SLA management
(Level 2)
• ESB Support/distributed large deployment support (manage/deploy/administer)
• Registers, discovers, manages, and monitors all shared WS across the enterprise
platform
• Enterprise-wide
• Control & management of large distributed enterprise – agent based/fan-out
technologies
Complex
• Policy-directed command-control fabric/uptime requirements/performance
(Level 3) requirements
• Built in governance models for specific business processes
• Federated management (Level 4, most advanced, globally distributed)
4.3.2 Project Phases

The phase of the project refers to the project’s growth over time. Typically, enterprises
embarking on SOA go through three phases of growth: Phase 1 – Initiation, Phase 2 –
Intermediate, and Phase 3 – Advanced.

The phases are characterized by the increasing number of applications, and by the
development, business, operational, and technical issues triggered by the increase.
TABLE 5: SOA PROJECT PHASES
Phase Characteristics
• Initial stages of a long-term SOA plan
• Introduction of a SOA Platform
• 12-24 week projects
Phase 1 • Reusable solution for a tactical problem using SODA for the first time
• Some reuse of services within a business unit
• Quick integration to legacy applications using Web Services
• Data accessed via services
• Additional applications for multiple business units/functions are built-on the Phase 1
SOA platform
• Wider reuse of services among business functions/units
Phase 2 • Visibility into issues of reuse, discovery, publication, duplicate efforts, and policy-
based control of services
• Identification of shared services for security, registration, policy enforcement (QoS,
SLA, routing etc.)
• Many enterprise-wide applications built and deployed on the SOA platform
• Company-wide participation in defining the infrastructure (for interoperability, reuse,
common services)
Phase 3 • Reduce e-business application development and maintenance costs
• Enterprise level discovery, reuse, and publication of services
• Wide sharing of services among business units, partners, and customers
• Policy-based control of services

4.3.3 Project Types Matrix
Based on the three complexity levels and three phases of an enterprise SOA process, all
projects can be grouped into one of nine project types. The following matrix shows the nine
different points at which each project can be placed. The diagram shows brief characteristics
of two SOA-based projects.
FIGURE 13: OPTIMAL PROJECT PATH
The recommended path for an enterprise to reach SOA Nirvana follows the green arrow; it
shows that as the project timeline grows, complexity levels can increase.

4.4 SERVICE IMPLEMENTATION PATTERNS
How services are implemented makes a significant difference to an SOA solution. Services
are implemented differently based on the applications required and the available
infrastructure. Some of the widely used implementation patterns, which can transition an
organization to an SOA, are shown below.
4.4.1 New Application Development

Typically, new applications provide tactical solutions for business problems with a strategic
SOA-based infrastructure, and have little or no need for legacy integration.
4.4.2 Adapting or Legacy Wrapping

This pattern exposes legacy applications by packaging them with service-oriented interfaces
such as Web Services. You can wrap the application interfaces with a layer of code (façade
pattern) or packaged software that performs the protocol and data translation and
transformation between a Web Services interface and the legacy interface.
Wrapping applications to provide a Web Services interface allows the applications’

functionality to be accessed by other applications and services using standard technologies. In
the cases where a vendor does not provide an “adapted” Web Services interface to their
packaged applications, J2EE CA-based adapters could be used.
4.4.3 Integration
This pattern is applicable for providing coarse-grained functionality to service interfaces by
combining a multitude of applications (new, legacy, and packaged), components, processes,
and other services. These pieces are integrated using service composition and process
orchestration software. This pattern uses both of the previous two patterns.
4.5 WEB SERVICES PATTERNS

Web Services are the widely accepted and used implementation technology of SOA. While
Service Implementation Patterns described different approaches for enabling services in an
SOA environment, those implementations used Web Services technology. Individual Web
Services implementation can be approached using several patterns.
Some of the common Web Services patterns are native web services, web service proxy,
document-centric web services, and orchestration web services.

5.0 BEST PRACTICES FOR IMPLEMENTING
SOA
So far we have discussed SOA characteristics, project types, and implementation patterns.
This chapter describes the “best practices” path for different types of SOA implementations.
First, SOA design goals are discussed, giving direction to the desired SOA state. The
recommended path is specific to the different end states of SOA, as specified in 4.3.3 Project
Types Matrix.
5.1 ARCHITECTURAL BEST PRACTICES

While a Service-Oriented Architecture is conceptually simple, and its value reasonably
evident, realizing a shared services infrastructure within a distributed enterprise can still be
difficult. Building the right architecture and adopting the following five best practices needed
to achieve a shared services vision can ease the transition, and help ensure both short-term
and long-term success.
1. Think SOA. Standards-based shared services ensure interoperability regardless of

platform, while loose coupling makes services easy to discover, assemble, and adapt.
It's easy to give lip service to SOA principles, but critical to take these principles to
heart.
2. Encourage adoption. It's important to articulate the value and benefits of shared
services to application developers and IT managers throughout a distributed
enterprise to spur adoption. Nobody benefits more in the long term from shared
services than application developers, who can be freed to focus on higher-value
applications. Convince them to leverage shared services first rather than building
redundant functionality, and to build great service interfaces.
3. Get the governance right. Architecture is important, but the gating factor in
realizing a shared services infrastructure is often having the correct IT governance
model. Shared services only work when centralized IT and distributed business units
agree on a federated governance model. The model must give business units the
flexibility to adapt their applications to meet changing needs, and give IT the control
to ensure that these rapidly changing systems meet enterprise reliability, security, and
interoperability standards.
4. Ensure control. Loosely coupled, network-addressable resources that are easily

accessible over Internet protocols form the basis of shared services as well as their
biggest impediment. Ultimately, shared services only work when their use is
effectively controlled and managed by the right infrastructure. Deploying a
distributed control layer ensures that a shared services vision can be realized without
any sacrifice of IT control.
5. Avoid architectural pitfalls. Shared services drive efficiency by bringing as much

as possible into the shared infrastructure. Many service management solutions today
continue to push complexity back into service end points, reducing the opportunities
for reuse. While attractive for individual projects, proxy and agent-based solutions
that treat each end point as a separate domain should be avoided.

5.2 TECHNICAL BEST PRACTICES
Design for applications to be deployed on an SOA-based infrastructure should meet some or
all of the characteristics of an SOA. These characteristics are listed and described in
Characteristics and Benefits of SOA earlier in this document. This section does not repeat
the benefits of these characteristics; it discusses key characteristics, design considerations,
and implementation choices.
5.2.1 Coupling: Tight, Loose, or Decoupled

Coupling refers to the relationship (interrelatedness and dependency) between two software
artifacts (applications, components, modules, methods, services). Coupling can be
categorized as tight, loose, or decoupled. The degree of coupling between two services
mainly depends on two factors: the implementation and invocation of the service provider,
and the consumer’s knowledge of how to find and invoke the service. For services, location
and interface definition (including data type definition) forms the coupling. It is necessary to
handle levels of coupling of different versions of services as well.
• In computer or software systems it is practically impossible to have two related systems

completely decoupled from one another. As long as one system depends on the other
system for data, function, service, or connectivity at any level, they can’t function as
decoupled.
• In loose coupling, a service provider defines and publishes its service interface, using a
standard definition language, for use by consumers. The interface defines the invocation
contract between a service consumer and a service provider. A service provider’s
implementation can be modified as long as the service interface remains same.
• A consumer’s knowledge of the location of the service provider also introduces coupling.
If two services need to interact, they can’t be decoupled, and have 100% location
dependency. In contrast, if the consumer carries the exact location of the calling service
then it is tightly coupled by location. As location decoupling is not possible (between two
known entities, but possible in an EDA architecture), and tight coupling of location is
inflexible, an intermediate loose coupling of location is desirable. Loose coupling of
location can be achieved by using service intermediaries such as service brokers or
directory services.
• Loose coupling for Web Services is achieved by using WSDL for service definitions, and
by using UDDI, WLI Service Broker/Service Control.
• Using network load balancers (hardware and software) and/or WebLogic clusters, it is
possible to achieve non-policy-based simple location-based loose coupling without the
use of an intermediary. As long as the service endpoint specified in the WSDL is a DNS
name and not an IP address, the Web service request can be redirected and proxied via
standard HTTP mechanisms. The request could be serviced by any number of end-points
on any number of physical servers (including different data centers).
5.2.2 Binding: Static, Brokered, or Dynamic

The choice of service binding methodology determines the flexibility and performance of the
service invocation.

• Static binding assumes that the service definition and interface do not change frequently.
Static binding between service consumer and service provider tightly couples both
participants of the service invocation.
• In broker binding, a service consumer sends its request to a service broker, which routes
that request to one or more of the service providers, based on its policies for that service.
The service consumer needn’t be aware of the service provider in this mode.
• Dynamic binding assumes that the service definition and interface change frequently.
Dynamic binding requires that, for every call, the service consumer contact a service
directory or broker to request the service definition. Based on the information returned by
the service broker, the consumer binds to the service provider. As dynamic binding
performs a lookup followed by the binding, it will not perform as well as the static
binding approach.
• The choice of dynamic or static binding depends on the performance and flexibility
requirements of the application. Dynamism of Web service definition can be achieved by
using a UDDI or WSM intermediary service.
5.2.3 Granularity: Fine or Coarse

The number of service invocations made to the service provider by the consumer to complete
a business operation determines granularity of a service. When many service calls need to be
made, the service provider is implementing fine-grained services. If only one or very few
calls need to be made, then that service provider is implementing coarse-grained services.
• The number of service calls is related to the amount of information passed during each
call. While fine-grained services take few native type or object parameters, coarse-
grained services take documents as parameters, which contain all the data to complete a
business transaction.
• Coarse-grained services can be created by composing or assembling fine-grained
services; by using methods such as Tuxedo, J2EE EJBs, Servlets, and JDBC; or by
invoking services on back-end systems via an adapter, APIs or Web Services. Composing
coarse-grained services using fine-grained services provides the same benefits as using
SOA for the application. However, that does not mean exposing every single method in
an EJB as a Web Service; that is not required and may not be an appropriate solution. For
example, EJBs can be reused as Controls in WLI and used to compose coarse-grained
services. Making all fine-grained services into Web Services and accessing those services
via a service interface would have performance overhead.
• Choose coarse-grained, document-oriented service to match the higher-level business
process requirement. Fine-grained services can be implemented using Web Services, or
J2EE components, or Controls. Coarse-grained services should be composed using fine-
grained services as much as possible to take advantage of the overall services benefits. It
is also recommended that a services management layer is applied for coarse-grained as
well as fine-grained services.
5.2.4 Invocation: Synchronous or Asynchronous

SOA supports two models of service invocation: Synchronous (RPC), and Asynchronous
(publish/subscribe). The choice of synchronous or asynchronous service call depends on the

availability and performance capabilities of the service provider and on the needs of the
consumers.
• Synchronous service calls should be used when an immediate response is required and
the consumer is waiting for the response for a predetermined period. For this model to be
successful, the service provider should be implemented to respond in real time for the
maximum request loads. Also the service should always be available. As the synchronous
model is implemented to handle predetermined loads, it is not capable of handling
unexpected higher-priority requests. The server needs to be designed to handle all the
requests simultaneously. If the service provider starts to respond more slowly, it will be
unable to accept additional consumers. Such characteristics can be implemented by
service management policies or using server virtualization techniques.
• In the asynchronous model, consumers send requests to the server and continue to do
other processing. The server returns the response whenever it completes the service, and
the elapsed time depends on the server’s load. The server should be implemented to
queue the maximum expected number of requests, and it need not process all the service
requests simultaneously.
• If high-volume service requests are expected and the server can only handle a limited
number of services simultaneously, then asynchronous service invocation is
recommended. Asynchronous service can be easily scaled up or down by adjusting the
request queue length.
• If real-time response is required, then the synchronous model is the obvious choice.
However, the system should be implemented to handle a predetermined number of
service requests. Adding more servers is the only way to scale up this implementation.
• In most composite services, numerous applications will be involved. It is almost
impossible to guarantee request/response between many applications in a synchronous
service call. In such cases, asynchronous publish/subscribe or point-to-point messaging
model guarantees delivery of messages and responses between multiple applications.
• The asynchronous service invocation model is best suited for highly reliable, coarse-
grained, document-oriented services. Synchronous service invocation is more suited for
fine-grained, lightweight service calls. One drawback of asynchronous messaging is that
the response order may not match the request order.
WebLogic Platform is capable of supporting both synchronous and asynchronous service call
models. Synchronous Web service calls use SOAP over HTTP, and the asynchronous model
uses SOAP over JMS. WebLogic Integration supports synchronous, asynchronous and WS-
Acknowledgement service invocation models.
5.2.5 Shared or Common Services

SOA promotes reuse, division of development and operational logic and tasks, and policy-
based computing. These characteristics of SOA can be only achieved by designing services
for reuse and by externalizing the operational policies.
• Services that are useful to more than one application can be reused by being identified,
implemented, and published. Reusable services can be identified by finding commonly
used services, and must be implemented with special consideration for reuse. But

promotion of reuse and duplication avoidance depends on sharing knowledge of the
available services, and on encouraging reuse within an organization.
• To make services more easily reusable, don’t embed application-specific policies such as
security (authentication, authorization), SLA, QoS, and audit. Since policies are common
across applications, policies should be configured and applied outside of the application.
• Web Services Management (WSM) products provide common or shared infrastructure to
manage services, policy configuration and administration. To realize the full benefit of
SOA, the appropriate WSM infrastructure could be utilized.
• Examples of shared services:
o Shared Utilities: Security, Business Process Orchestration (cross-company)
o Resource Management: Directory, Broker
o Service Management: Provisioning, Monitoring, Quality of Service, Versioning
o Transport Management: Reliable Messaging, Metering, Routing, Auditing
5.2.6 Integration and Interoperability

• Establish enterprise SOA standards for interoperability, data (common data model, meta-
data management), semantics, and security.
• Encapsulate legacy systems as services.
• Adopt Service-Oriented Development for Applications (SODA).
• Use service-oriented integration for application integration.
5.3 ORGANIZATIONAL AND OPERATIONAL BEST

PRACTICES
• Get business buy-in.
• Train architects, developers and business analysts in SOA best practices.
• Establish a Center of Excellence:
o Staffed with cross-functional architects and business analysts with strong technical,
communication and business expertise.
o Fosters business-technical feedback loop.
o Publishes design principles, guidelines, best practices, patterns, and templates.
o Provides cross-organizational co-ordination.
o Centralizes architecture and standards for federated implementation and

management.
o Markets services and promotes reuse.

o Manages assets.
o Provides a Portal for communication within the organization and a services catalog.
• Use SOA for evolutionary growth of agile IT. Related benefits of SOA are incremental
development and deployment of business applications, reuse of business components in
multiple experiences, and low-cost assembly of some new business processes.
• Plan for shared infrastructure cost recovery, metering and charging for services.
• Fund shared services infrastructure, remembering that ROI is realized in the long-term
rather than in the short-term. SOA is strategic solution with solution realization for
tactical problems. Business units share the infrastructure and leverage common
investments.
• Implement data services early.
• Use a business service perspective for selecting and implementing coarse-grained
services. Business processes with high maintenance and operational costs are ideal
candidates for the benefits of SOA.
• Follow the recommended implementation path shown in the SOA Project Type Matrix:
start small with a pragmatic use case, plan ahead, grow SOA infrastructure, and add
applications/projects in an evolutionary approach.
• The network-centric, policy-based, distributed nature of SOA-based applications requires
IT support and operations groups to understand the differences between traditional
applications and SOA-based applications. Support and operations groups need to
understand and learn the new administrative tools for the SOA platform and services
management vendor products.

6.0 EXAMPLE SOA PROJECT – SIMPLE,
PHASE 1
The next two chapters describe sample scenarios for two SOA projects. In 4.3 Categorizing
SOA-Based Projects, SOA projects were defined by complexity and timeline. In this chapter,
a system categorized as simple and phase 1 is described; the next chapter describes a complex
phase 3 project. These project descriptions are based on real-world customer experiences,
with some modifications to match the complexity/phase criteria.
6.1 CURRENT STATE AND CHALLENGES

In this example, the initial system has Oracle, DB2 and a custom application on the back end,
and two different end-user Web applications on the front end. The data in the DB2 database
is shared between the two Web applications, so a change to the schema requires changes to
both applications. In addition, the Web applications don’t share consistent look-and-feel and
behavior. This inconsistency means additional training when users switch between
applications.
FIGURE 14: INITIAL USER SYSTEM (SIMPLE)

6.2 REQUIREMENTS
The business wants minimal turn-around time for application changes when database changes
are made. They also want a consolidated and consistent user interface-based Web application
for both business functions.
6.3 RECOMMENDED PATH

Based on that information and on SOA design goals, here are the steps to reach the desired
future state. The steps listed below are specific to SOA, and are in addition to typical IT
project steps, such as requirements gathering, analysis, design, and quality assurance.
Though still part of a SOA project, those steps are not listed here.
6.3.1 Assumptions
SOA is the long term strategic solution for the enterprise Many more enterprise-wide
applications will be deployed using the shared SOA infrastructure.
6.3.2 Project Steps

1. Analyze the current implementation and determine commonly accessed data.
2. Identify use cases and usage patterns.
3. Define portal and portlets based on user interface requirements.
4. Expose data resources as services and define their interfaces.
5. Wrap legacy and custom applications as services and define their interfaces.
6. Identify, define, and implement common services such as logging, security, data
transformation, and encryption.
7. Define a common or conceptual data model for commonly accessed data.
8. Select or implement a common user interface framework.
9. Implement application and shared services identified above, and test in development
and staging environments.
10. Plan for application deployment. The shared services layer and application layer can
be deployed in separate servers or on the same server. Deployment planning should
consider the following: high-availability of services, service virtualization using load
balancers, performance requirements and server capabilities.

6.3.3 Implementation
The previous section describes the steps for reaching the solution; this section describes the
solution architecture.
Non-functional requirements determine application architecture. Here are the most common
non-functional requirements (NFR) for a software application:
• Security
• Scalability
• Performance
• Manageability
• High availability
• Extensibility
• Flexibility
The BEA Platform satisfies almost all of the above architecture requirements.
SOA adds the following NFRs:
• Loose coupling
• Dynamic discovery of services
• Availability of services as needed
The required solution is a data access portal with multiple data sources. BEA’s Portal and
Liquid Data products provide the features required to implement this solution.
BEA Liquid Data provides Control and Web Services-based conceptual data access to Portal.
Back-end data resources are accessed by Liquid Data, using JDBC for databases and Web
Services for the custom application.
Note that the requirements do not require data updates from the Portal. The proposed high-
level Web Services-based solution for these requirements is shown in this diagram.

FIGURE 15: WEB SERVICES-BASED SOLUTION – SIMPLE PHASE 1 CASE

7.0 EXAMPLE SOA PROJECT – COMPLEX,
PHASE 3
This chapter builds on the information from the previous chapter to describe the
implementation of a complex phase 3 SOA project. For a description of SOA project
complexity and phases, please see 4.3 Categorizing SOA-Based Projects earlier in this
document. This project description is based on real-world customer experiences, with some
modifications to match the complexity/phase criteria.
7.1 CURRENT STATE

In this example, the enterprise has determined that SOA is their strategic solution for IT.
Current enterprise application silos include order fulfillment, sales and marketing, field
service, the call center, and billing. Enterprise systems include B2B file transfers with
partners; Web-based applications used by partners to search catalogs and order items; several
back-end systems including Siebel CRM, SAP R/3 Order Management, a mainframe-based
custom billing system, Oracle Financials, and MQ Series. The following diagram illustrates
this complex (but typical) enterprise at a very high level:
FIGURE 16: INITIAL ENTERPRISE SYSTEM (COMPLEX)
7.2 CHALLENGES
Overall the enterprise lacks agility and is unable to keep up with growing and dynamic
business needs. Key challenges faced by this organization are:
• Growing demand for multi-channel user interface to applications.

• Growing end-user community including internal, external, partner, and public users.
• Extensive UI customization based on user roles and authorization.
• Very long time-to-market for new applications due to integration and customization
issues.

• Integration, operational and administrative issues due to application silos being owned
and operated by functional units.
• Lack of consistent best-practices and policy enforcement across the enterprise.
• Very long partner ramp-up time due to interfacing, connectivity, and data issues.
• Lack of data consistency due to duplication of functionality and data. For example, the
call center and billing systems have their own customer records with varying details.
• Some processes involve manual tasks because all the systems are not fully integrated. For
example, the order fulfillment system and the billing system are not integrated.
• Processing delays due to the lack of application interface integration, as users have to
launch and view multiple applications for each business process.
7.3 REQUIREMENTS
In order to resolve these challenges and make the enterprise IT more agile, the enterprise
chose SOA as their strategic IT solution. In order to resolve their application needs and to
enable SOA, the enterprise listed the following requirements:
• Portal solution, external, internal, partners

• Service virtualization
• Ability to incorporate security services from Netegrity using policies
• Content-based routing using policies
• SOAP XML and raw data support
• SLA monitoring
• Policy-based QoS enforcement
• Declared application policies (file compression, PGP decryption)
• Granular visibility for process details (metering per-process activity)
• Operational best practices applied by configuration, not by coding
• Compliance and governances: schema validation against enterprise dictionary,
auditability, regulatory and security enforcement
• Policy enforcement points deployed without modifying applications or processes
• Policies changed at runtime without recompilation/restart of applications
• Real-time collection, analysis, and reporting of application SLA metrics (for example,
performance, availability, and security)
• Real-time delivery of alerts to systems management monitors and WSM Policy Manager
for active management
• Heterogeneous system connectivity via Web service
• Seamless support of multiple channel UI or interface (mobile, Web, internal, external)
• Business process development and management capability to create coarse-grained,
orchestrated business processes
• Standards-based solution to support interoperability, and best-of-breed plug and play
solution

7.4 RECOMMENDED PATH
Based on that information and on SOA design goals, here are the steps to reach the desired
future state. The steps listed below are specific to SOA, and are in addition to typical IT
project steps, such as requirements gathering, analysis, design, and quality assurance.
Though still part of a SOA project, those steps are not listed here.
Unlike the previous simple example, this implementation is for a very large enterprise with
many applications and numerous challenges. This enterprise has chosen SOA and Portal-
based UI as their strategic solution. These considerations have been accounted for by
prescribing the following steps:
1. Establish a Center of Excellence for SOA composed of architects and business

analysts from different functional and applications groups. The role of the COE is
specified in 5.0 Best Practices for Implementing SOA.
2. The COE should draw the current enterprise architecture and list business processes
and use cases.
3. Using BEA’s SteelThread methodology, determine the best use case for pilot SOA-
based application implementation. The SteelThread methodology identifies the use
case that covers more depth (end-to-end, complex) than functionality. The remainder
of the steps apply to the selected business processes and their use cases.
4. Identify enterprise systems and applications that need to be integrated and determine
how they will provide service-oriented integration.
5. Interview application end users and determine application interface integration

(consolidation) requirements. Design Portal-based UIs that can be personalized using
role-based and user-based rules.
6. Based on that information, determine data integration and consolidation

requirements. Design and implement a common data model schema for the whole
enterprise. Enable service-based common data access. Using the SteelThread
methodology, implement the enterprise data model (EDM) iteratively. Loose
coupling in SOA-based applications makes iterative development of EDM and
applications more viable.
7. Collect and define common services and specify policies for enforcement.
8. Maintain a portal for best practices, common services specifications, policy

information, accepted standards and their versions, and so on.
9. Specify real-time monitoring requirements and an exception handling process.
10. As this enterprise’s applications are accessed from both inside and outside the
firewall, it requires both agent-based and gateway (fabric) based Web Services
management solutions.
11. Define application specific policies (routing, security, decryption methods,

decompression algorithms).

12. Implement applications and shared services, and test with the policies in development
and staging environments. Service development and policy configuration can be
performed by developers and administrators respectively.
13. Plan for application deployment. The shared services layer and the application layer
can be deployed on separate servers or the same server. Deployment planning should
consider the following: high availability of services, service virtualization using load
balancers, performance requirements, and server capabilities. In addition, use of a
WSM product or fabric in the solution requires planning for their deployment, and
integrating those products with the network infrastructure and application platform.
7.5 IMPLEMENTATION
The previous section describes the steps for reaching the solution; this section describes the
solution architecture. The required solution is an enterprise SOA with multiple applications
and back-end systems. BEA Platform provides all basic features required to implement this
solution.
Here are the most common non-functional requirements (NFR) for a software application:
• Security
• Scalability
• Performance
• Manageability
• High availability
• Extensibility
• Flexibility
The BEA Platform satisfies almost all of the above architecture requirements.
SOA adds the following NFRs:
• Loose coupling
• Dynamic discovery of services
• Availability of services as needed
JDBC and Controls calls are not going through WSM components. As per best practices, not
all component integration needs to go through a WSM component if the components are not
all Web Services-based. Other interconnection protocols are Java RMI, JDBC, and Adapters
(native EIS protocols). The next figure shows the proposed high-level Web Services-based
solution for these requirements.

FIGURE 17: WEB SERVICES-BASED SOLUTION – COMPLEX PHASE 3 CASE

8.0 DEPLOYMENT AND AFTER
In this chapter, typical deployment issues and considerations, and post-deployment topics
such as operations, administration, and management (OA&M), are discussed. The
discussions are based on WLI 8.1.
SOA has many benefits, due to its flexibility and policy-based computing. By the same
token, it increases the responsibility of the OA&M staff, because they have to manage
additional components, servers, and policies related to SOA (WSM). The following sections
discuss deployment and OA&M from the SOA perspective.
8.1 DEPLOYMENT
The choice of deployment model depends on the network architecture, and on how, logically
and physically, applications and operations and management need to be separated. This is
typically dictated by an organization’s IT policies. BEA provides the flexibility of co-
deployment or separate deployment, so it is possible to choose any deployment model to
support the IT policies.
Separate applications by tiers (presentation, integration, process, and data) and separate
applications from administration and management. This gives the best control and flexibility,
but additional hardware servers and software licenses do add cost. Use of WSM products
increases the number of components that need to be deployed in the same server, or the
number of servers that need be managed.
8.2 OPERATIONS, ADMINISTRATION, AND

MANAGEMENT (OA&M)
However, SOA separates development and OA&M, which reduces the number of interfaces
used by different type of users. With the addition of policy-based computing, most control is
transferred to the OA&M staff. This means that they use the WSM product UIs rather than
the WebLogic consoles.

9.0 SUMMARY
This document has explained the pros and cons of a Service-Oriented Architecture, and
contrasted it with traditional application development and integration methodologies. It has
covered different types of SOA solutions, in terms of complexity and timeframe, presented
example SOA solutions, and discussed best practices for implementing SOA solutions.

GLOSSARY
Application integration. Designing or modifying applications so that they can communicate
with one another, within or between enterprises, request services, and share data. The
WebLogic Integration solution provides a means to integrate applications by defining
communication endpoints, either in custom code or in a business process defined with
WebLogic Workshop.
Asynchronous. In distributed application architectures such as Web services, clients send

messages to servers and servers respond. If a client is blocked from performing other work
while waiting for a server to respond, the interaction is described as synchronous because the
client is synchronized with the server. If an interaction is designed such that a client can
continue performing other work while the server prepares its response, and the server can
notify the client when the response is ready, the interaction is described as asynchronous. An
asynchronous architecture is useful in event-driven scenarios, in which an event can arrive at
any time and the receiver can handle it whenever it arrives.
Coarse-grained service. A service that implements more functionality and returns more data
than a fine-grained service, for example, Create New Customer.
Composite service. A service that implements an entire business function by calling other
services, which may be fine-grained or coarse-grained, for example, Provision New DSL
Line.
Data access service. A service that accesses data, which may reside in a legacy or other
custom system, and provides a uniform API and loose coupling for that access.
Enterprise Service Bus (ESB). A message broker which combines publish/subscribe

messaging, synchronous and asynchronous messaging, basic transformation, content-based
routing, and native Web Services support.
Fine-grained service. A service that implements a minimum of functionality and returns a

minimum of data, for example, Get Customer Number.
Portal. A Web site providing a single, unified point of access for varied applications and
information. Access to portals and their associated resources is dictated by the user’s role,
allowing administrators to easily manage the site’s contents.
Portlet. A component or area of a browser window on a portal, displaying specialized

content, which may be static or dynamic. Typically a JSP file or Java Page Flow, portlets
make up the basic building blocks of the WebLogic Platform.
Project complexity. In this document, the technical complexity of a project, where 1 is the
simplest and 3 the most complex. A project with complexity level 1 would be a departmental
project with a single application, and complexity level 3 would indicate an enterprise-wide
project with multiple heterogeneous applications.
Project phase. In this document, the growth over time of a project, where phase 1 is the
earliest and simplest and phase 3 is the latest and most complex. A project in phase 1 might
be in the initial stages of implementing a long-term SOA plan, with some rapid integration

with legacy services being done. A project in phase 3 might have multiple enterprise-wide
applications deployed on the SOA, with wide sharing of services between organizations and
partners.
QoS – Quality of Service. A requested level of service from a function or application; for
example, in a networking application, QoS values might be exactly-once, at-most-once, and
duplicate-okay.
SLA – Service Level Assurance or Agreement. A contract between a service provider and
a consumer that states what services will be provided, and in what timeframe, by the
provider.
Service. A well-defined, self-contained function that does not rely on context from other
functions. In a WebLogic Integration environment, a service is a named business function
within an Enterprise Information System (EIS), implemented in terms of interactions
provided by the adapter for the EIS. Services provide a communication mechanism to an
EIS.
In a WebLogic Portal environment, a service may be data processing and storage, data
interchange, or data presentation provided by a Web application. For example, a service
called Shipping may perform three functions: it records the shipping information related to a
customer's order; it calculates shipping costs; and it tracks the shipping status of the order.
Service consumer. A software artifact that consumes or uses services by contacting a

service provider, generally through a broker of some sort, and requesting it to perform a
service or function. A service consumer can also be a service provider.
Service provider. A service that advertises itself, publishing its offered services, generally
through a service broker, and performs services for consumers. A service provider can also
be a service consumer.
Service broker. A program that takes and retains information about provided services, their
locations and how to call them, and routes requests from consumers to the correct providers.
SOA – Service-Oriented Architecture. Basically, a collection of services that communicate

with each other. More generally, an architecture solution based on using services to
accomplish business functions.
SOAP (Simple Object Access Protocol). Set of standard rules for formatting an XML
message so that it can be interpreted by different Web services.
Synchronous. An attribute of a service; a caller to a synchronous service must wait for the
called service to return before continuing: the caller is synchronized with the service. See
also asynchronous.

INDEX
Application integration, 11, 12, 13, 14, 20, Services, 17
29, 33, 44, 49 coarse-grained, 21, 23, 28, 36, 47
Asynchronous services, 23, 28, 29, 37, 48 coarse-grained, example, 21
BEA Platform, 28, 31, 32, 37, 39, 40, 58 common. See Shared services
BEA SteelThread, 57 composite. See Composite services
Best practices, 45, 57 data access. See Data access services
architectural, 45 deployment, 58
organizational/operational, 49 discovery, 37
technical, 46 enterprise infrastructure. See Shared
Binding services
brokered, 47 fine-grained, 21, 25, 36, 47
dynamic, 47 granularity, 20, 21, 25
static, 47 implementation, 18
Business services, 19 implementation patterns, 44
Center of Excellence (COE), 49, 57 interface, 18
Component reuse, 37 provisioning, 37
Component services, 19 registration, 37
Composite applications. See Composite reuse, 23, 24, 36
services service broker, 17, 46
Composite services, 20, 21, 24, 36 service consumer, 17, 22, 46, 47
example, 21 service provider, 17, 22, 46, 47
CORBA, 27 shared. See Shared services
Data access services, 19, 24, 36, 52 types, 19
Deployment, 60. See Services: deployment versioning, 37
Enterprise Infrastructure Services. See Services layer, 27
Shared services Shared services, 20, 24, 27, 37, 48
Enterprise Service Bus (ESB), 28, 41 SLA (Service Level Assurances), 41, 42
Event Driven Architecture (EDA), 29 SOA (Service-Oriented Architecture), 15, 17
J2EE, 28, 30, 35, 47 and BEA Platform, 36
JMS (Java Message System), 28 and Enterprise Service Bus, 28
Legacy applications, 44, 52 and Event Driven Architecture, 29
Liquid Data. See WebLogic Liquid Data and Web Services, 27
Loose coupling, 22, 37, 46, 53 characteristics, 22, 36
Orchestration, 24, 44, 49 complex phase 3 example, 55
Policy-based computing, 24, 37, 38, 42, 56, disadvantages, 29
57, 60 implementation, 53, 58
Portal, 20, 23, 41, 50 project complexity, 41, 51, 55
Project complexity. See SOA (Service- project phases, 41
Oriented Architecture): project project types matrix, 43, 45
complexity simple phase 1 example, 51
Project phases. See SOA (Service-Oriented solution model, 26
Architecture): project phases SOAP, 28, 56
Reuse. See Services: reuse, Component SODA (Service-oriented development of
reuse applications), 41

SODA (Service-Oriented Development of WebLogic Integration, 31, 32
Applications), 49 WebLogic JRockit, 33
Synchronous services, 23, 37, 48 WebLogic Liqud Data, 33
Tight coupling, 46 WebLogic Liquid Data, 31, 32, 53
Versioning, 49 WebLogic Portal, 31, 32, 34, 53
Web Services, 23, 27, 28, 31, 44, 46, 47, 53, WebLogic Server, 32
54, 57 WebLogic Workshop, 31, 35
when not to use, 29 WSDL, 27, 46
WebLogic Application Server, 31 XML, 19, 30, 35, 38, 39, 56
WebLogic Enterprise Security, 31, 36

TO LEARN MORE
For further information, please contact:
• Your BEA account manager
• Best-Practices@bea.com
This document will be updated every quarter based on feedback from the field.

ABOUT BEA
BEA Systems, Inc. (Nasdaq: BEAS) is the world’s leading application infrastructure software
company, providing the enterprise software foundation for more than 13,500 customers
around the world, including the majority of the Fortune Global 500. BEA and its WebLogic®
brand are among the most trusted names in business. Headquartered in San Jose, California,
BEA has 81 offices in 34 countries and is on the Web at www.bea.com.
BEA Systems, Inc.

2315 North First Street
San Jose, CA 95131 U.S.A.
Telephone: +1.408.570.8000
Facsimile: +1.408.570.8901
WWW.BEA.COM

Service Oriented Arquitechture - Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Service Oriented Arquitechture - Guide

Transféré par

Droits d'auteur :

Formats disponibles

SERVICE-ORIENTED

Platform Solution Accelerators

VERSION1.0 REVISION 2.12

RESTRICTED RIGHTS LEGEND

BEA Systems, Inc. BEA PROPRIETARY

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - iii

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - iv

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - v

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - vi

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - vii

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - viii

1.1 THE SOLUTION ACCELERATOR GUIDES

The Solution Accelerator series includes the following titles:

Each Solution Accelerator addresses the following key points:

o Typical industry solutions

o Pros and cons for each approach

• BEA 8.1-specific issues (and how to address them)

o Error handling and logging

o Other platform issues

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 9

o Illustration of key design issues

o A complete illustration of platform architecture

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 10

This chapter discusses traditional application development and integration methodologies,

2.1 APPLICATION DEVELOPMENT AND

It is no longer useful to consider application development and application integration

2.2 TRADITIONAL METHODOLOGIES

Three of the most common application integration methodologies were point-to-point

2.2.1 Point-to-Point Integration

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 11

2.2.2 Enterprise Application Integration

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 12

2.2.3 Business Process-Based Integration

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 13

o Tight coupling. Programming creates hardcoded dependencies between applications

FIGURE 3: TRADITIONAL ENTERPRISE INFORMATION INTEGRATION

2.3 WHY SOA?

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 14

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 15

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 16

TABLE 1: DISTRIBUTED VS. SERVICE-ORIENTED ARCHITECTURES

Distributed Component Architecture Service-Oriented Architecture

SOA provides many advantages over traditional approaches; it is:

3.1 SOA SERVICES

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 17

A service has two parts: the interface and the implementation.

FIGURE 6: PARTS OF A SERVICE

• Identity of the service

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 18

• Data Access – allows uniform access to different data sources.

3.1.1 Data Access Services

3.1.2 Component Services

3.1.3 Business Services

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 19

3.1.4 Composite Applications

3.1.5 Shared or Enterprise Infrastructure Services

Infrastructure services can be categorized into four types:

• Shared Application Services

3.1.6 Service Granularity

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 20

Composite services can be assembled using coarse-grained and fine-grained services.

Composite services can be assembled from coarse-grained and fine-grained services.

FIGURE 7: SERVICE GRANULARITY

BEA PROPRIETARY SERVICE ORIENTED ARCHITECTURE SOLUTION ACCELERATOR GUIDE - 21