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
BEA White Paper – A BEA Enterprise Architecture Guide
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
BEA White Paper – A BEA Enterprise Architecture Guide
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
BEA White Paper – A BEA Enterprise Architecture Guide
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
Data WarehouseERP.NetMainframedB
Presentation Business Data
BEA White Paper – A BEA Enterprise Architecture Guide
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
Data WarehouseERP.NetMainframedB
Presentation Business Data
Service Registry
Data Services Layer
Data WarehouseERP.NetMainframedB
Enterprise Service Bus
Presentation Business Data
Service Registry
BEA White Paper – A BEA Enterprise Architecture Guide
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.
BEA White Paper – A BEA Enterprise Architecture Guide
• 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
Presentation Business Data
BEA White Paper – A BEA Enterprise Architecture Guide
7
BEA White Paper – A BEA Enterprise Architecture Guide
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
BEA White Paper – A BEA Enterprise Architecture Guide
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
CWP1478E1106-1A
BEA Systems, Inc.
2315 North First Street San Jose, CA 95131+1.800.817.4232+1.408.570.8000
bea.com