BEA White Paper A BEA Enterprise Architecture Guide€¦ · BEA White Paper – A BEA Enterprise Architecture Guide Step 3: loosely coupling consumers from producers Although services

BEA White Paper

A BEA Enterprise Architecture GuideCreating SOA from a Monolithic Portal Environment

Copyright

Copyright © 1995 - 2006 BEA Systems, Inc. All Rights Reserved.

Restricted Rights LegendThis software is protected by copyright, and may be protected by patent laws. No copying or other use of this soft-

ware is permitted unless you have entered into a license agreement with BEA authorizing such use. This document is

protected by copyright and may not be copied photocopied, reproduced, translated, or reduced to any electronic

medium or machine readable form, in whole or in part, without prior consent, in writing, from BEA Systems, Inc.

Information in this document is subject to change without notice and does not represent a commitment on the part of

BEA Systems. THE DOCUMENTATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND INCLUDING

WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

FURTHER, BEA SYSTEMS DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING

THE USE, OR THE RESULTS OF THE USE, OF THE DOCUMENT IN TERMS OF CORRECTNESS, ACCURACY,

RELIABILITY, OR OTHERWISE.

Trademarks and Service MarksCopyright © 1995-2006 BEA Systems, Inc. All Rights Reserved. BEA, BEA JRockit, BEA WebLogic Portal, BEA

WebLogic Server, BEA WebLogic Workshop, Built on BEA, Jolt, JoltBeans, SteelThread, Top End, Tuxedo, and

WebLogic are registered trademarks of BEA Systems, Inc. BEA AquaLogic, BEA AquaLogic Data Services Platform,

BEA AquaLogic Enterprise Security, BEA AquaLogic Service Bus, BEA AquaLogic Service Registry, BEA Builder, BEA

Campaign Manager for WebLogic, BEA eLink, BEA Liquid Data for WebLogic, BEA Manager, BEA MessageQ, BEA

WebLogic Commerce Server, BEA WebLogic Communications Platform, BEA WebLogic Enterprise, BEA WebLogic

Enterprise Platform, BEA WebLogic Enterprise Security, BEA WebLogic Express, BEA WebLogic Integration, BEA

WebLogic Java Adapter for Mainframe, BEA WebLogic JDriver, BEA WebLogic Log Central, BEA WebLogic Network

Gatekeeper, BEA WebLogic Personalization Server, BEA WebLogic Personal Messaging API, BEA WebLogic

Platform, BEA WebLogic Portlets for Groupware Integration, BEA WebLogic Server Process Edition, BEA WebLogic

SIP Server, BEA WebLogic WorkGroup Edition, Dev2Dev, Liquid Computing, and Think Liquid are trademarks of BEA

Systems, Inc. BEA Mission Critical Support, BEA Mission Critical Support Continuum, and BEA SOA Self Assessment

are service marks of BEA Systems, Inc. All other names and marks are property of their respective owners.

CWP1478E1106-1A

BEA White Paper – A BEA Enterprise Architecture Guide

Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Achieving the strategic goals of SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Step 1: decoupling of data logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Step 2: controlling service proliferation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Step 3: loosely coupling consumers from producers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Step 4: decoupling presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Step 5: consuming other services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

About BEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Join the BEA community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9


Executive summary SOA is an IT strategy that organizes the discrete functions contained in enterprise applications into interopera-

ble, standards-based services that can be combined and reused quickly to meet business needs. IT and line-

of-business managers and administrators often want to realize the benefits of SOA. Doing so can be simple, if

a few maxims are kept in mind:

• Plan strategically but implement tactically. While long-term goals are important, a “big bang” approach tostrategic goals can be problematic. The success of an SOA implementation depends on the ability toimplement transitional architectures over weeks and months yet preserving goals which may take a period ofyears to achieve completely. With SOA, IT can remain agile, staying close to business requirements over thecourse of successive changes and enhancements.

• Treat the service infrastructure as a toolbox. The service infrastructure is the first of the critical capabilitiesthat determine the success of an SOA. Over time, the service infrastructure should provide the ability to addnew “tools” to an environment that complement existing tools and provide new capabilities withoutnecessitating rework or affecting other tools already in use. This allows an architecture to mature over timeand is a key factor in maintaining an organization’s business agility and fiscal constraints.

This paper documents one path to an SOA given a particular starting point, the monolithic portal.

1


2

Achieving the strategic goals of SOA

Getting startedTo start down a strategic path, one must first understand the current environment. This paper assumes as a

starting point an existing monolithic portal environment.

As shown in figure 1, a monolithic portal environment, which exists in many IT environments, can be defined as

a portal that encapsulates presentation, business, data, and security logic into the same container. The chal-

lenge of a Monolithic portal environment is that it is tightly coupled to its data feeds. Because a company’s

investment in portals can be substantial, IT personnel are faced with the question, “How can we leverage the

current environment and at the same time achieve an SOA?”

Figure 1

Monolithic portal environment.

Presentation Business Data

Data WarehouseERP.NetMainframedB


Step 1: decoupling of data logicDecoupling of the architecture’s data logic is the first step in transitioning from a monolithic portal to a SOA-

based environment. As shown in figure 2, creating a data services layer and abstracting its data logic from the

current portal infrastructure can be leveraged for the future. Creating a data service layer makes it possible to

create and expose common views of key information and to utilize data as a service.

The data service layer must have the following capabilities:

• The ability to interact with, and consume data from, heterogeneous data sources and environments as thedata moving into and out of an enterprise will be from many sources.

• The ability to provide data virtualization. Otherwise, heterogeneous data, schematics, or ownership issues canmake physically merging data difficult or even impossible.

• The ability to perform dynamic data transformation since data from disparate sources and environments rarelyare homogeneous in format or accessibility.

• The ability to handle security through data redaction and participation of data security in the largerenterprise’s SOA security implementation.

• The ability to handle complex data read and write requirements in a heterogeneous environment.

• The ability to do all the above with minimal or no hand-coding, so the service infrastructure can deliver on require-ments in weeks rather than months and remove programmer expertise or availability as potential bottlenecks.

3

F igure 2

The Data Service layer enablesabstaction and de-coupling of thePresentation Business Data layerfrom the physical data feeds.

Data Services Layer




Step 2: controlling service proliferationAs successive sets of data services are built and deployed, the service infrastructure must be able to control

service proliferation, service creation, service consumption, and service reuse. If it cannot, there is the risk of

creating numerous services that are never consumed or reused; even worse is a declining ability to satisfactori-

ly monitor and manage the environment in the event that the most popular services are unplanned successes

without adequate infrastructure to support demand.

Controlling service proliferation during design and at runtime requires the addition of a service registry to the

environment. A successful service registry, should have the following capabilities:

• Configurable user interface: It should be easy to configure how information is displayed, edited, and searchedwithout the need for coding changes. Mapping a Service Registry to an organization’s specific requirementsimproves SOA adoption and productivity.

• Service classifications including configurable taxonomy support and validation to promote discovery of services.

• Search and navigation. There should be a simple, easy-to-understand user experience for business services.

• Streamlined approval process: A Service Registry should enable users to quickly and easily submit publishedbusiness services for one-step approval. This dramatically simplifies new service publication and can notablyimprove the rate of service contribution.

• Standards support: The registry should support industry standards such as the UDDI v3 standard, includingsupport for subscriptions and automatic notifications of changes to Web services.

• Policy support (publication and assignment): The registry should publish and associate policies in compliancewith service level agreements.

• WS-Policy Attachments: This enables policy reuse, improving efficiency and reducing risk; it also ensuresconsistency in an organization’s SOA.

• Federation should be supported through UDDI-level replication.

4

Figure 3

Enterprise architecture

after the addition of a

service registry. Service Registry

Data Services Layer



Service Registry

Data Services Layer


Enterprise Service Bus


Service Registry


Step 3: loosely coupling consumers from producersAlthough services have been created at this point in the process, the architecture still has tightly coupled point-

to-point services. Moving to a more loosely coupled environment will improve agility and prevent the develop-

ment of “spaghetti architecture.” At this point, it would be wise to introduce an enterprise service bus-which

not only simplifies the existing architecture and lowers maintenance costs but also allows for quick and inex-

pensive expansion of services. The use of an enterprise service bus creates a classic design known as a

façade pattern.

A successful enterprise service bus should have the following capabilities:

• Configuration-driven intelligent routing.

• Message routing according to XQuery-based policies or callouts to external Web services, to supportcomplex routing steps.

• Support for both point-to-point and one-to-many routing scenarios, enabling both request-response andpublish-subscribe models.

• Support for heterogeneous transports.

• Support for routing transport protocols between service endpoints File, FTP, HTTP(s), multiple JMS providers,JMS/XA, and email (POP/SMTP/IMAP).

• Intelligent messaging brokering.

• Support for multiple messaging models including synchronous, asynchronous, and publish and subscribe.

• Support for synchronous-to-asynchronous bridging.

• Support for multiple message formats including SOAP, SOAP with attachments, XML, structured non-XMLdata, raw data, text, and email with attachments.

• WS-I compliance for SOAP/HTTP messaging.

• Interoperability with Cyclone Interchange for business-to-business and EDI support.

5

F igure 4

Service infrastructure afterthe addition of an enterpriseservice bus.


• Dynamic message transformation.

• Dynamic service selection based on message content or headers, with the ability to transform messagesbased on the target service.

• Message transformations based on XQuery or XSLT.

• Multiple formats-XML and structured non-XML data.

• Message enrichment.

• Callouts to Web services to gather additional data for transformations.

• Proactive infrastructure health.

• Service monitoring, logging, and auditing availability monitoring with search capabilities.

• Capture of key statistics for message and transport attributes including message invocations, errors,performance, volume, success/failure ratios, failover/retry counts, and SLA violations.

• Local gathering of statistics and central aggregation, for cluster-wide views with minimal impact onperformance.

• Logging of alerts to support SNMP-based integration with enterprise management systems.

• A flexible, graphical administration console.

• Cluster-wide view of service status and statistics as well as management dashboard SLA violations.

• Configuration of console data to user-defined time intervals for flexible SLA management.

Step 4: decoupling presentation Presentation as a service is an important step in creating a true SOA. Existing monolithic portals are usually

based on standards such as JSR 168.

Although JSR 168 (which is important for portlet portability across platforms, preventing vendor lock-in) will

continue to play a role in modern enterprise architectures, it does not provide enough isolation and flexibility in

a heterogeneous environment to excel alone as a methodology for deploying portlets. However, coupling

WSRP (Web Services Remote Portlets) with JSR 168 offers the portability of JSR 168 with the dynamic con-

sumption available via WSRP-allowing developers to treat presentation as a service.

6

F igure 5

Inner design patterns of WSRPimplementation.

Portal (consumer)

Users

Community of interest

Community of interest

SOAP over http/https

SOAP over http/https

http/httpshttp/https

Portal (producer)

Enterprise

Portal (consumer)

Web Service (producer)

F igure 6

Service infrastructure withbusiness services.

Data Services Layer

Data Warehouse

Service Registry

Service Registry

ERP.NetMainframedB

Enterprise Service Bus

Business Management



7


Step 5: consuming other servicesOnce WSRP Services are available in a given architecture, one gains the ability to consume presentation arti-

facts such as Microsoft Teamsites and other third-party or home-grown portals using WSRP. Many enterprises

have numerous “departmental” implementations of .NET and Teamsites that they wish to leverage in an enter-

prise effort.

Leveraging WSRP while adding a .NET accelerator and other capabilities to the service infrastructure makes it

possible to consume, crawl, index, and manage the .NET environment through and with the existing J2EE

enterprise environment.

8

F igure 7

Consumption of .NETapplication into BEAWebLogic portal.

BEA WebLogic Portal

Framework

.NET Control

BEA Portal.NET Application

Accelerator

.NET Web Form

WSRP REST


ConclusionThe approach laid out in this paper allows for the quick ability to transform architecture of a monolithic portal

environment into an SOA with all the desired characteristics. In short, implementing a successful SOA involves,

first, following the two principles outlined at the beginning of this paper-“plan strategically but implement tacti-

cally,” and “treat the service infrastructure as a toolbox.” Then functionalities and capabilities should be added

in order of their priority to the enterprise, never loosing sight of or straying from the ultimate business goals ini-

tially set in place.

About BEABEA Systems, Inc. (Nasdaq: BEAS) is a world leader in enterprise infrastructure software. The BEA SOA 360º™

platform, the industry’s most unified SOA platform for business transformation and optimization, is designed to

improve cost structures and grow new revenue streams. Information about how BEA is enabling customers to

achieve Business LiquidITy™ can be found at bea.com.

Join the BEA communityAt BEA, we understand that developers need different kinds of resources than IT managers. And that architects

face different challenges than executives. That’s why we’ve created four unique communities that give you

exclusive access to a formidable group of your peers, to a world of shared thinking, and to the kind of mean-

ingful information that can make you more effective and more competitive. To join one or more of the BEA

communities, simply register online at bea.com/register.

9

www.bea.com/register

www.bea.com

CWP1478E1106-1A

BEA Systems, Inc.

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

bea.com

Documents

BEA White Paper A BEA Enterprise Architecture Guide€¦ · BEA White Paper – A BEA Enterprise Architecture Guide Step 3: loosely coupling consumers from producers Although services